做單元測試的過程，我們興奮過，低落過，冷靜過，改革過，現在良性發展中，剛開始做的時候很興奮，一天只知道寫啊寫啊，到頭來寫了很多單元測試用例，但到現在扔掉的也很多。
當然原因也很多，主要還是測試目的的不明確，測試范圍的不明確，測試標準不明確，對模塊本向在產品中為何存在，為什么是這樣存在沒有弄清楚，走了很多灣路。
當然接到一個模塊的測試任務時，應該與開發人員，系統測試人員和產品人員，了觖這個模塊為什么存在，有什么功能，在產品中是怎么樣的一個位置和作用。
要多讀開發的代碼，測試用例寫完后，一定要調試一次測試案例，跟到開發的代碼里面去，一行一行的看狀態是不是正確，一般都會發現很多bug的。
測試一個模塊不光要看是否正確實現了想要的功能，還要看開發這樣寫是不是合理，有沒有改進的地方，并提出改進方案，開心的就是我們周圍的一群同事常常在測試一個模塊的時候就會寫一封改進方案的郵件發給開發人員，并抄送給相關上級，在算法的簡單，性能的提高，成本的減少都引到了很好的作用。這也是人們的開發人員很尊重我們測試人員提出的任務意見的原因，原因他們知道這個模塊還有一個測試人員和他們自己一樣對這個模塊里的每一行代碼都很熟悉。
測試的標準很難，怎么樣才算這個模塊測試好了，因為上級不用看你寫的測試用例，他只要數據，但是給什么他才有說服力，我們在案例數，bug數等很多數據里選了代碼覆蓋率做為標準，雖然這個數據也不能充分說明測試的完整性，但相對來說還是比較有信服性。
測試用例在后期維護的時候，我們就頭疼過，而且是很頭疼，模塊內部實現變了，接口變了，在產品里的位置變了，數據結構變了，我們的用例就天天跟著開發也在變。目前沒有特別好的辦法，只能看具體問題具體處理，在寫用例的時候還是有一點點技巧的。
可恨的setup和teardown，之前對它的理解就是測試前的事情和測試后做的事情，所以不太注意這個地方，就引起測試用例一個一個運行是正常的，一批一批運行就失敗了；一個人寫的案例運行是正常的，兩個寫的案例在一起運行就失敗了。一失敗就是幾百個，要找出是那個用例引起的測試環境的破壞，很痛苦。真的很痛苦！！！“吃掉自己的狗食”這句話用到這里絕對合適，不要僅把自己的setup做好，自己的teardown比setup更重要。
測試用例常失敗的幾個原因：
1、行為敏感性 如果系統的行為發生變化，如需求變了，這時測試就會失敗。
2、接口敏感性
3、數據敏感性測試
4、上下文敏感。
突然想寫，寫的比較亂多見涼。