小步前進。軟件開發是個復雜性非常高的工作，開發過程中要考慮很多東西，包括代碼的正確性、可擴展性、性能等等，很多問題都是因為復雜性太大導致的。極限編程提出了一個非常好的思路就是小步前進。把所有的規模大、復雜性高的工作，分解成小的任務來完成。對于一個類來說，一個功能一個功能的完成，如果太困難就再分解。每個功能的完成就走測試代碼-功能代碼-測試-重構的循環。通過分解降低整個系統開發的復雜性。這樣的效果非常明顯。幾個小的功能代碼完成后，大的功能代碼幾乎是不用調試就可以通過。一個個類方法的實現，很快就看到整個類很快就完成啦。本來感覺很多特性需要增加，很快就會看到沒有幾個啦。你甚至會為這個速度感到震驚。(我理解，是大幅度減少調試、出錯的時間產生的這種速度感)
5. 測試技術
5.1. 測試范圍、粒度
對哪些功能進行測試?會不會太繁瑣?什么時候可以停止測試?這些問題比較常見。按大師 Kent Benk 的話，對那些你認為應該測試的代碼進行測試。就是說，要相信自己的感覺，自己的經驗。那些重要的功能、核心的代碼就應該重點測試。感到疲勞就應該停下來休息一下。感覺沒有必要更詳細的測試，就停止本輪測試。
測試驅動開發強調測試并不應該是負擔，而應該是幫助我們減輕工作量的方法。而對于何時停止編寫測試用例，也是應該根據你的經驗，功能復雜、核心功能的代碼就應該編寫更全面、細致的測試用例，否則測試流程即可。
測試范圍沒有靜態的標準，同時也應該可以隨著時間改變。對于開始沒有編寫足夠的測試的功能代碼，隨著bug的出現，根據bug補齊相關的測試用例即可。
小步前進的原則，要求我們對大的功能塊測試時，應該先分拆成更小的功能塊進行測試，比如一個類A使用了類B、C，就應該編寫到A使用B、C功能的測試代碼前，完成對B、C的測試和開發。那么是不是每個小類或者小函數都應該測試哪?我認為沒有必要。你應該運用你的經驗，對那些可能出問題的地方重點測試，感覺不可能出問題的地方就等它真正出問題的時候再補測試吧。
5.2. 怎么編寫測試用例
測試用例的編寫就用上了傳統的測試技術。
操作過程盡量模擬正常使用的過程。
全面的測試用例應該盡量做到分支覆蓋，核心代碼盡量做到路徑覆蓋。
測試數據盡量包括：真實數據、邊界數據。
測試語句和測試數據應該盡量簡單，容易理解。
為了避免對其他代碼過多的依賴，可以實現簡單的樁函數或樁類(Mock Object)。
如果內部狀態非常復雜或者應該判斷流程而不是狀態，可以通過記錄日志字符串的方式進行驗證。
6. Tips
很多朋友有疑問，“測試代碼的正確性如何保障?是寫測試代碼還是寫測試文檔?”這樣是不是會陷入“雞生蛋，蛋生雞”的循環。其實是不會的。通常測試代碼通常是非常簡單的，通常圍繞著某個情況的正確性判斷的幾個語句，如果太復雜，就應該繼續分解啦。而傳統的開發過程通常強調測試文檔。但隨著開發節奏的加快，用戶需求的不斷變化，維護高層(需求、概要設計)的測試文檔可以，更低層的測試文檔的成本的確太大了。而且可實時驗證功能正確性的測試代碼就是對代碼最好的文檔。
軟件開發過程中，除了遵守上面提到的測試驅動開發的幾個原則外，一個需要注意的問題就是，謹防過度設計。編寫功能代碼時應該關注于完成當前功能點，通過測試，使用最簡單、直接的方式來編碼。過多的考慮后期的擴展，其他功能的添加，無疑增加了過多的復雜性，容易產生問題。應該等到要添加這些特性時在進行詳細的測試驅動開發。到時候，有整套測試用例做基礎，通過不斷重構很容易添加相關特性。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
