要做好測試可不是一件容易的事情。測試工作和軟件開發密切相關，卻又自成體系。測試并不是一個單獨的階段或活動，測試本身就是一個過程，具有自己的生命周期，從測試計劃開始，到測試用例的制定，測試的結構設計，測試代碼的編寫。測試的生命周期和軟件開發生命周期擰在一起，相互影響。當然，我們還是那句老話，羅馬不是一天建成的。對我們來說，還是從簡單的開始。
在我們談及精益編程理論的時候，曾經討論過全面質量管理的概念：生產過程的每一個環節都需要為質量負責，而不是把質量問題留給最后的質檢員。這對于軟件開發有著很好的借鑒。軟件開發中最頭疼的就是質量問題，因為人的行為過于不確定了。在經過漫長的軟件開發周期之后，軟件漸漸成型，但是缺陷也慢慢增多，試圖在最后的關頭解決長期積累的問題并不是一個好的做法。軟件開發到了這種時候，發現和修改缺陷需要付出很大的代價。
我們說，最后關頭的測試并不是不重要，但是，軟件質量問題應該在整個軟件過程中予以重視。
測試的最小單位
測試問題的很重要的思路在于測試的管理上，如何管理一個項目中所有的測試，以及它們相關的文檔，相關的代碼，如何定義測試人員的職責，如何協調測試人員和開發人員之間的關系？
XP的測試優先和自動化測試實踐是一個非常優秀的實踐，我們也曾不止一次的提到該實踐，但是對XP強調的單元測試，很多人都有一些誤解：
XP中提供的例子過于簡單，無法和生產環境相結合。XP中的單元測試只是為測試提供了一個具體的操作思路，但是它并不能取代其它的測試原理。如何進行測試，如何組織測試，如何管理測試，這些都要由不同的軟件組織自己來進行定義。
測試代碼本身不能夠適應變化。黑盒測試的理想狀況是外部行為不因為內部行為的改變而改變。當需求或是設計發生變化的時候，一段代碼的內部行為需要改變，但是外部行為卻不需要變化，這樣，針對外部接口進行的單元測試同樣不需要改變，但是這個規則一旦被違反，我們就需要付出同時改變測試代碼的雙重代價了。因此，測試代碼的設計本身就是很講究的。
單元測試（有時候也稱為類測試）是代碼級別的測試，是測試的最小單位。XP非�？粗剡@個最小單位。我們觀察測試優先框架XUnit，發現它使用組合模式將大量的最小單位的單元測試組織起來，形成完整的測試網。所以，XP的思路非常的簡單：最小單位的測試能夠做好，全系統的測試就能夠做好。這個思路未必就正確，但是注重最小單位的測試的思路是絕對正確的。每個部件都正確，最后的軟件未必正確，但任何一個部件不正確，最后的軟件一定是不正確的。
測試優先
文章來源于領測軟件測試網 http://www.kjueaiud.com/
