最近兩年還真做了不少的測試。現(xiàn)在發(fā)現(xiàn)測試的重要性，是自己吃過虧。你覺得已經(jīng)找不出錯誤的地方，居然還真有；你覺得不會有影響的地方，居然還牽扯上了。還是那句老話：
測試只能證明問題的存在，而不能證明問題不存在。
回想對待測試的態(tài)度，已經(jīng)做了一個準備。以前真的看不起測試，這在國內(nèi)是普遍現(xiàn)象，現(xiàn)在逐漸認識到測試活動，不管是對個人，還是對項目公司，都是非常重要的：
1、TDD是測試與開發(fā)的融合。基本上很少有機會有專門的測試團隊來驗證你的代碼，自己得測試，而且得詳盡辦法找到盡可能多的問題。
2、測試要是可復用的。這個問題比較難解決，測試的粒度太小的話，代碼的變動，很容易破壞測試用例。一個方向是，測試輸入和輸出，而不要過分關注執(zhí)行流。測試的復用能夠保證每個Release都不會破壞既有的行為。
3、測試盡量自動化。這個跟應用緊密聯(lián)系，千差萬別，發(fā)揮聰明才智，總能找到自動化的解決方案。
4、測試適可而止。需要在投入和產(chǎn)出之間做出衡量。應該沒有公司對待UT像對待代碼一樣嚴謹。可以用往往是成功產(chǎn)品的第一步。
5、還有一點需要注意，質(zhì)量是規(guī)劃出來的，而不是測試出來的。不要對測試期待太高。一個拙劣的架構(gòu)或者設計，注定就是Bug的聚集地。前期不重視，沒有提供測試的支持，臨時抱佛腳，也是回天無力的。
我們不應該排斥測試，領導安排你做測試，應該高興才對。一是可以找別人的茬；二是很好偷懶。當然這樣的態(tài)度不推薦。測試跟開發(fā)是緊密聯(lián)系在一起的，需要的是溝通，而不是相互指責。因為很難衡量測試的效果，以及對需求的理解偏差，所以測試很好偷懶。可以用下面的公式來衡量測試的效率：
測試效率 = 歷史測試效率 × Bug數(shù)量 / （需求項目數(shù) × 時間）
找茬偷懶都不好。好的是測試可以幫助熟悉系統(tǒng)。碼農(nóng)的出路中，兩條很重要的就是領域?qū)＜液图軜?gòu)師，他們都需求對業(yè)務非常熟悉和了解。閱讀需求文檔不正是給你了解產(chǎn)品，了解用戶，了解領域的機會么。實效點的作用，會在編碼過程中潛移默化的提升考慮問題的廣度和深度。
調(diào)整心態(tài)，測試的目的是保證產(chǎn)品的質(zhì)量，為用戶提供安全可靠的服務。只有將自己重新定位，才能正視自己的工作，為公司創(chuàng)造價值，為個人開辟蹊徑。
測試是需要方法的。前面說了測試需要適可而止，需要平衡投入和產(chǎn)出，那么測試就應該有針對性，好鋼用在剛韌上。兩個指導性原則：
1、保證基本功能可用，基本測試。
2、識別出風險高的部分，比如交互，邊界，順序啊。
最后，找出來Bug是不是很有成就感？但請把成就感放在為客戶提供高質(zhì)量高可靠的產(chǎn)品上吧！
原文地址：http://my.oschina.net/sulliy/blog/87766