從業5年，一直開發Windows平臺上的程序，客戶端爲主，間或網絡、驅動。對於測試總結出一些經驗，自認爲有助於提高開發生產效率，目前的感覺在30%左右。具體數據隨着這些方法的使用逐漸清晰。也請參考這些方法的兄弟們參與討論，指正或提出更好的辦法，共同讓程序員（當然也包括測試、客戶）的生活變得輕鬆些。
每段先提出問題，再說下針對的測試方法。
第一，一個看似簡單的模塊往往需要超過預期的時間。我們來分析一下爲什麼，開發人員寫代碼時是正向思維，考慮的是如何實現功能，走通正常流程。自測不能考慮特殊情況，比如邊界、用戶習慣性、涉及網絡時的延時、斷網等。相信帶過項目的人都有過類似經驗，開發人員提交結果時，經常說我完成了，自測通過。實際上還是漏洞百出，只能作爲原型。必須測試跟進，迭代幾次之後才整體完工。有時是因爲測試工作週期與開發不配套，導致開發等待測試（這裏是時間浪費），等測試反饋結果後，開發重新熟悉整個流程（因爲多數開發人員——無論公司規模大小——身兼數職，這時早把幾天前的項目忘到腦後了）。結果造成基本模塊開發時間過長。模塊之於整個項目，就像細胞之於身體，每個細胞都有問題，身體怎麼能輕鬆愉快呢？
再深入看一下時間到底花在什麼地方。其實開發測試的迭代過程中，小問題，或者說很容易觀察到、並且也很好改的問題居多，且佔用了大量迭代時間，比如輸入框字符數過多，突然斷網崩潰等等。真正需要開發人員花精力和大塊時間解決的問題，往往只佔小部分。
至此，我們可以說，如果喫掉小問題佔用的時間，完成一個模塊的時間將縮短1/3（在測試周期與開發週期錯位不太多的情況下）。那麼怎麼喫掉這段時間？我的方案是開發人員的test case。舉個例子吧。
實現自動更新功能。看到自動更新，會想到什麼？Web服務器上放版本文件，自動發現新版本，下載新文件，覆蓋本地文件。差不多是這樣了，哦，也許還要加上覆蓋之前關閉佔用文件的進程，不然會導致覆蓋不了。這下功能齊全了，開工。3天以後，完成了。現在來看看測試同志發現了什麼問題。
1.
可借用TDD，即Test Drive Develop（測試驅動開發）。結合實際，目前多數程序員還不太能接受這種做法。有時候TDD也不太容易操作，軟件的大功能提前知道，但細微功能，比如操作，流程要等開發到一定程度才知道。
待整理。