完美的測試是不存在的，但是測試可以越來越完美。我們在文章一開始就提到了全面質量管理（TQM）的思路，TQM認為，產品生產的每個過程都會對最后的產品質量產生影響，每個人都需要對質量負責。對于軟件開發也是一樣，開發過程的任何步驟都會對軟件質量產生影響，要提高軟件質量，并不是加強測試力量就能夠做到的，需要在整個過程中保證軟件的質量。構建測試并不斷改進測試的行為貫穿于整個開發過程，為質量提供了基礎的保證。
自動化測試
自動化測試是XP測試活動的另一個優秀思路。在我們討論迭代的時候，曾經簡單討論過回歸和自動化測試。只有測試實現了自動化，回歸測試才能實現，重構才能夠貫徹，而迭代也才能夠進行。所以XP一直強調它的實踐就像是拼圖，只有全部實現才能夠完全展現其魅力。單單從這個角度，我們就能夠體會到這句話的含義了。
對于一個自動化測試系統而言，有幾個部分是特別重要的：
數據準備：對于一個簡單的TestCase而言，數據準備的工作在Setup中就完成了處理（參見JUnit），但是現實開發過程中的測試數據通常比較復雜，因此有必要準備單獨的數據提供類。對于一個完整的企業應用系統而言，往往包含數千的測試用例，而相應的測試數據量也極為龐大，這時候，我們還需要有專門的機制來生成和管理測試數據。
測試數據和特定的項目有關，因此不存在一個標準的建立測試數據的規范。所以我們在XUnit框架中看到，框架僅僅只是把建立數據這個活動給抽象出來，并未做額外的處理。但對于自動化測試而言，為各個單元測試建立獨立的測試數據是很有必要的。測試數據的獨立性是測試用例獨立性的前提。測試數據大部分采用腳本的形式建立，包括輸入數據和輸出數據兩個部分。例如，對于一個業務實體，就可以使用一個腳本來對它的屬性賦值。腳本文件的形式有很多，例如配置文件、數據庫數據腳本等。
驗證：驗證是將待測試的方法返回的結果值和預定的結果值進行比較，以判斷該方法是否成功執行。結果值總是和輸入值相匹配，因此，我們經常將結果值和輸入值放在同樣的腳本中處理。比較通用的驗證方式是采用斷言機制，此外，還包括錯誤記錄、瀏覽測試結果，產生測試報告等功能。
樁：樁（Stub）是自動化測試中常用的一種技巧。在OO設計中，類和類之間往往都有關系，我們如何對一個依賴于其它類的類進行單獨的測試呢？很多的軟件設計中都存在難以模擬錯誤的現象。例如對磁盤出錯、網絡協議出錯的情況就難以模擬。測試樁的思路就是為了解決這些問題，一個樁并不是真正的對象，但是能夠提供待測對象感興趣的數據或狀態，這樣，待測試對象就能夠順利的使用依賴對象，或是模擬事件。
(六)強化溝通
結對編程是本系列文章討論的最后一個主題，也是備受爭議的一個主題。為什么一個人的工作要兩個人來完成，這對于老板來說簡直就是犯罪。和前面的主題類似的，我們要學習和應用一項實踐，關鍵的還是要把握其實質。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
