測試是開發中必不可少的工作
首先，一個軟件產品或系統的開發成功，不僅僅是編寫完為使用者提供服務功能的程序而已。軟件程序編寫的完成，其實只是完成了開發任務中的一半。與程序的開發相配合的、具有同樣重要性的另一半工作，是對開發完畢的軟件所進行必要的測試。對測試的管理和執行，其重要性不亞于對程序本身的開發。你可以花費巨大的資源和努力進行程序的開發，可是你要是沒有與此配套的完善的測試，所開發出來的軟件往往會因為質量問題無法滿足客戶的要求和幫助你贏得市場的競爭。
近幾年來國內信息業界的軟件開發的成熟程度大大提高，很多公司都開始重視軟件測試的重要性、并建立了與此相關的組織結構來保證測試工作得以執行。但是忽視或輕視測試工作的不良習慣和企業文化仍舊普遍存在。在中國項目管理俱樂部的網站上有業界的同仁們反映了這樣的情況：他的公司居然還采用所有的軟件開發人員都只做程序編寫、只有一個人擔任軟件測試工作這樣一種組織結構，而且這個公司的領導認為只有程序的編寫才屬于實際的開發工作，因此只知道夸獎程序編寫人員的工作成果、完全忽視測試人員的貢獻。雖然這樣的近于荒唐的例子可能是極少數的極端現象，但在相當大比例的軟件企業中測試人員往往仍舊是被當作“二等公民”看待，好像他們只是開發人員的配角而已，對軟件最終是否合格和能否發行的判決，并沒有實際的影響力。
一個成熟和高效的開發組織應該、也必須采取與此完全相反的做法：將軟件的測試和開發放到同等重要的位置上，對軟件的測試和開發給予同樣程度的重視。這種項目管理的理念就要求對軟件測試給予與軟件開發相同的資源和支持，用同等的組織結構和人才來保證軟件測試得到嚴格的執行。
微軟公司就是用組織結構來保證產品開發的運作流程充分體現對軟件測試的尊重、承認測試的重要性。微軟總部各個產品部門的所有開發組織都有與程序開發團隊并列的測試團隊 – 任何開發組織都是由項目管理、軟件程序開發、和軟件測試三個并列的團隊組成。這樣的“三駕馬車”的組織結構，保證了測試團隊是一個獨立于程序開發團隊之外的機構，軟件測試的結果和測試人員的觀點在這樣的組織結構中不會被程序開發人員隨意推翻或踐踏，測試人員能夠大膽申訴測試結果、堅持測試的判決、包括阻止不合格的軟件發行。我在Windows操作系統部門進行視窗嵌入式操作系統的開發工作時，就碰到過好幾起因為測試團隊堅持測試結果的審判，從而阻止了開發團隊能夠按時發行開發完畢的軟件的情況。
敏捷模式中的測試驅動開發
事實上，現在最新的軟件開發項目管理的模式之一甚至將軟件測試的優先權提高到高于軟件功能本身的開發之上。在敏捷模式（Agile Model）實踐范圍中的測試驅動開發模式（Test Driven Development，簡稱TDD）要求將軟件的測試機制和可測性首先開發到軟件中去，把對軟件進行測試的功能作為軟件功能開發的不可缺少的一部分來對待。它要求所有軟件功能組件都必須有自己的進行自我的單元測試的機能、并且要求程序編寫人員在開發軟件的功能程序編碼之前，先開發進行這些功能自我測試的程序。測試的程序編寫完成之后，就開始進行單元測試的運行。這時候，由于提供功能的程序源代碼都還沒有編寫，所以剛開始的時候這樣的自我單元測試當然都是通不過的。當這些單元測試都能運行之后，開發團隊然后才開始編寫每個單元里面的具體功能的程序。
由于進行自我測試的程序已經完成了，每個功能開發完了之后，開發人員就馬上可以啟動單元的自我測試程序。要是單元的功能程序開發得完善，這時單元的自我測試就能通過，單元的開發就算完成了，測試人員再進一步進入到下一步的其它測試，比如使用案例的測試和系統整合的測試，等等；要是單元的功能程序在開發中有問題或缺陷，這時單元測試就還是無法通過，那么開發人員和測試人員就先集中精力來分析到底是什么缺陷和錯誤造成單元組件的功能程序無法通過那些自我測試，然后可以根據測試失敗的癥狀進行單元功能程序的糾錯工作。
舉例來說，如果我們需要開發一個進行文檔選擇的功能組件。采用傳統的開發方法的話，就是開發人員先將文檔選擇的功能程序開發出來，然后進行黑箱效應測試，證實文檔能被選擇之后就完了 。采用TDD的開發方法，我們就不是先開發如何選擇文檔的功能程序，而是先考慮這個組件該如何進行單元測試。所以開發人員先編寫在文檔選擇的使用過程中進行檢測可能出現差錯的測試程序。這些測試檢驗代碼的白箱效應的測試，比如進行文檔選擇后的數據檢查、以及程序的邏輯檢查等等。等到這些單元測試程序完成并能夠運行之后，再開始編寫實際的文檔選擇的功能程序。每個局部功能程序編寫完畢就立即運行單元測試，直到單元測試全部通過為止。這時開發人員也可以根據軟件構架設計的有求，對功能代碼中的一些運算方程函數進行模塊優化性的分解（也叫Refactor），除去任何重復的代碼等等。任何源代碼改動和分解之后，必須再次運行所有的單元測試，直到全部通過后才進行證實使用方案的黑箱效應測試，比如檢測文檔選擇正確的結果、選擇錯誤的結果、文檔打不開的結果、文檔找不到的結果等等。
這樣的開發運作流程和管理的理念是，所有的程序都應該有它的可隨時啟動和利用的測試機制（Test Harness），而且這種測試機制應該是每個軟件功能組件單元的不可分割的一個組成部分。我們首先開發這些提供測試機制的程序，建立一個可供測試的框架。然后通過先測試失敗、加上功能后然后造成測試成功這樣一種反面性的驗證，來證實開發出來的軟件是符合所設計的測試要求的。所以你可以看得出來，測試驅動開發的模式的主導思想是為滿足測試而開發。
比喻來說，這就好像是修建一條鐵道線，得先把鐵路軌道的標準定了、軌道先鋪上，然后再在鐵路上運行與軌道寬度標準相符合、專門為它而造的火車。鐵路軌道的寬度標準決定了所用的火車必須遵循的寬度。所以可以說，軌道寬度標準是一個制約了火車合格標準的框架。先有了這個框架可以很容易地證實造出來的火車是否符合要求。當然，你也許可以不顧寬度標準先造個火車再說，但這樣造出來的火車不見得能在軌道上跑：要是輪距寬度不符合軌道標準，你就得返工重做。TDD的管理模式就是這個先造檢測標準的理念在軟件開發上的運用，就好像是你先定好軌道的寬度，然后說：按照這個標準造火車，不能在這個軌道上跑的火車就自動不合格；TDD的管理模式使開發人員建立同樣的思路：按照這個測試標準去開發程序，通不過這些測試的軟件就自動不合格。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
