比喻來說，這就好像是修建一條鐵道線，得先把鐵路軌道的標準定了、軌道先鋪上，然后再在鐵路上運行與軌道寬度標準相符合、專門為它而造的火車。鐵路軌道的寬度標準決定了所用的火車必須遵循的寬度。所以可以說，軌道寬度標準是一個制約了火車合格標準的框架。先有了這個框架可以很容易地證實造出來的火車是否符合要求。當然，你也許可以不顧寬度標準先造個火車再說，但這樣造出來的火車不見得能在軌道上跑：要是輪距寬度不符合軌道標準，你就得返工重做。TDD的管理模式就是這個先造檢測標準的理念在軟件開發上的運用，就好像是你先定好軌道的寬度，然后說：按照這個標準造火車，不能在這個軌道上跑的火車就自動不合格；TDD的管理模式使開發人員建立同樣的思路：按照這個測試標準去開發程序，通不過這些測試的軟件就自動不合格。
這樣的開發方法有很多好處，最明顯的好處是“強迫”開發人員在設計程序的同時，并列進行必須進行的單元測試設計，催促你去思考如何驗證你的程序單元的邏輯正確性和單元的完整性。更重要的是，這樣的開發模式有助于推動進行自動化測試的工具程序的開發、提高測試的效率，因為那些事先設計好的的單元測試程序，在單元的功能程序編寫過程中，可以被隨時使用，來驗證所開發的功能程序部分是否符合要求。
這樣的開發項目管理模式和理念，很明顯地是將軟件測試的作用和重要性提高到一個開發戰略的層面。 測試不再是簡單的開發完畢后再考慮使用的質量管理的輔助手段而已，而是衡量軟件在開發過程中每個單元組件是否能夠通過，可以說是掌握了項目進度的“生殺大權”。
這個開發管理模式相對來說是一個比較新穎的方法，它對傳統的開發流程的項目管理造成了不可避免的沖擊，因此并不是很容易被開發團隊接受，特別在絕大多數的在開發人員說了算的企業文化里，這樣的開發方法的使用和推廣很容易受到開發團隊的阻力，因為它不僅用開發流程的改革來承認測試的重要性，并且由于開發人員被要求進行單元測試的開發和執行的額外工作 ，開發人員的工作量和習慣也都需要作一定的改變。
但是毫無疑問，這個項目管理模式所能夠帶來的巨大好處是有目共睹的。這也是為什么這幾年來在業界中像敏捷模式、TDD模式等新型管理方法在軟件開發的項目管理上被越來越廣泛地利用。就拿微軟本身來說，我們目前也正在進行一場內部的改革項目管理的“革命”：兩年前，總部產品開發部門有少數一些項目經理們自愿組成一個推廣敏捷模式的興趣社團，在少數幾個開發團隊開始推動敏捷模式和TDD等。他們有點像個“地下組織”，因為絕大多數的產品開發團隊還是在使用傳統的方法，公司也沒有人正式倡導敏捷模式等。但是近兩年來，采用TDD等模式來充分發揮測試對質量管理起到的好處，很快就得到很多團隊的共識，因為那些采用了這些模式的團隊在軟件質量的增進上有明確的數據可以證實，這種尊重測試的方法為提高軟件質量、降低Bug Count（缺陷數）、最終幫助開發項目的成功所能帶來的巨大好處。在好幾次公司的經驗交流會上，一些采用了敏捷模式和TDD等方法的團隊公布詳細的質量管理的數據比較，來證明這些新方法的優越性。微軟快速適應變化的特性使得公司很快地也學會支持對新型模式的采用，現在全公司對技術員工進行開發工程教育的部門也開辟相關的課程，幫助一起來推廣對敏捷模式和TDD等管理改革的采用，頗有“星星之火快要燎原”的氣勢。有的團隊甚至采用配對的兩人坐在一起開發的工作模式：一個人開發進行單元測試的程序，另一個人接著開發功能程序、并馬上進行測試。兩個人來回使用同一臺計算機來完成對某個組件的開發。
完善的測試依賴全面的測試計劃
前面講述了測試對軟件開發的重要性。那么在開發項目管理的運作中，究竟如何執行具體的測試呢？答案是：每個軟件都有它的功能設計，通過它們為用戶解決某些問題或提供某些服務。測試的目的有兩個：第一是要確證這些為用戶解決某些問題的功能設計被正確無誤地開發出來了，也就是說，如果用戶按照所設計的使用方法和過程（我們稱為User Scenario，即使用方案），的確能夠利用這些功能所提供的服務和解決問題；第二是保證軟件在被使用的情況下，如果使用者并不按照所設計的使用方案在使用軟件，它不應該由于任意的使用、或其它外部影響造成任何問題，包括出現差錯，比如數據遺失、數據錯誤、 甚至造成系統崩潰等等。
為了達到這兩個不同的測試目的，在執行具體的測試時就要采用不同的測試方法。為達到第一個目的、也是最主要的目的，最佳的方法是根據所設計的每個功能和使用方案，設計一個相對應的測試執行過程，去驗證這個功能或使用方案是能夠從頭到尾完成的。這個測試執行過程的定義和描述我們稱它為測試方案或測試案例（Test Case）。要能夠確證所有功能的確是準確地被開發出來了，唯一的辦法就是為每一個使用方案都設計出大量的、一套完整的測試案例（在微軟的產品開發中往往都是幾百甚至上千的測試案例在測試中被使用），然后通過對這些測試案例的按部就班的執行來證明軟件的確可以完成所設計的功能。測試案例的全面性和完整性最終決定了為達到第一個目的測試的質量。
要能夠做到制定完整的測試案例，就需要有一個可以作為依據的綱領性指南，幫助測試人員設計這些案例。這樣的綱領性指南是由一份叫做測試計劃的文件來總結的。測試計劃在軟件的設計規范書的基礎上進行總結和撰寫，根據具體的軟件和使用要求，制定出整個軟件產品的總體測試構思和設想、測試總體范圍、對測試方法和測試自動化工具的要求和定義等等。在測試計劃的基礎之上，測試工程師們根據它再進一步制定詳細的具體測試方案。至于測試計劃該怎樣寫，該包括什么內容，我在《軟件開發項目管理》一書的第十一章里有詳細的測試計劃文件的模版你可以參照使用，這里我就不再重復了。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
