3.2.3 詳細設計、編碼、測試階段
對上述幾個需求點進行詳細設計、編碼和測試。最后對單元模塊的具體實現方案如下：
圖1 測試驅動單元模塊的基本結構
如圖所示，整個系統分為兩個部分：實現產品功能等需求的“應用模塊（Application Module）”、實現測試驅動開發的“測試模塊（Test Mt，dule）”。
測試模塊又分為3個子模塊：輸入子模塊、輸出子模塊、處理子模塊。“輸入子模塊”主要是接收外部的一些命令；“處理子模塊”主要是接收已經經過“輸入子模塊”過濾、解析的命令，然后與應用模塊進行信息的查詢、收集、控制等操作，再把一些信息傳遞給“輸出予模塊”；“輸出子模塊”就接收“處
理子模塊”傳遞過來的信息，并把它呈現出來。由這個測試模塊來實現前面總結四個方面的17條測試驅動需求。比如“自動化測試腳本支持”這一需求：如果后期測試人員要做一個自動化測試，就可以在測試模塊的界面輸入測試腳本，這些測試腳本由“輸入子模塊”進行處理后傳達到“處理子模塊”；“處理子模塊”對這些腳本逐條進行解析轉化成應用模塊“認識”的命令，然后去向應用模塊進行查詢信息、對應用模塊進行控制下達操作命令......這樣處理完之后，把一些需要輸出的信息，比如執行結果、成功失敗等信息傳遞給“輸出子模塊”；最后經過“輸出子模塊”把結果、信息給測試人員看。這樣設計的優點在于，不管應用如何升級、如何改變，只要應用模塊與測試模塊之間的接口不變，這個測試模塊就都可以起作用。
4、效果分析
該項目總代碼行為15．3K，其中測試驅動代碼行為6．6K（測試模塊的代碼量），測試驅動代碼占總代碼的43％。
（1）通過測試驅動開發可以提高測試效率、定位bug效率
用“測試并定位1個bug所需人天”作為測算指標，這個指標的計算公式。3 o如下：（測試所投入的人員天數+定位bug所投人人員天數）／測試階段所發現的全部bug，得到“測試并定位1個bug所需人天”這個指標。選取了一個沒有實現測試驅動的項目作比較，該項目的測試效率：
測試并定位1個問題所需人天=2．93人天
而在這個實現了測試驅動的項目的系統測試投入人天及定位bug投人人天共368人時=46人天，共發現并定位bu932個，測試效率如下：
測試并定位1個問題所需人天=46人天／32=1．44人天
這個測試效率明顯提高很多，在發現的32個bug中，大部分的bug是可以根據系統所提供的測試驅動手段很快定位的。
（2）通過測試驅動開發可以降低測試成本
開發設計的投入成本相比測試成本是要低的，開發投入的成本主要是人員、PC機；而測試投入的成本主要是人員、設備，設備是測試成本中占比重最大的。測試環境要包括所有組網設備、還有測試所需的設備，都是非常昂貴的。對于沒有實現測試驅動開發的項目，測試人員往往需要自行開發一些測試工具，對系統進行測試，而且首先要先熟悉該系統去了解開發人員的設計和開發思路，然后才能進行完善的測試，而這是很浪費時間和人力。而實現測試驅動開發的項目就可以把這一步簡化為只需要測試人員寫測試腳本、甚至可以把這一步完全略去。所以可以通過前期測試驅動的投入來降低后期測試所需要投入的成本，效果非常明顯。
（3）通過測試驅動開發可以降低“不可重現／隨機重現”bug的比例
實踐證明，通過測試驅動開發，大大降低了“不可重現／隨機重現”bug的比例。這類問題是系統的很大隱患。通過測試驅動開發，因為很多會出現問題的地方都打印了相關信息、同時也提供很多方法來進一步的定位控制，大部分以前認為是“不可重現／隨機重現”的bug都可以抓到蛛絲馬跡，最后來定位和解決。
（4）通過測試驅動開發可以提高開發設計文檔的質量
以前系統開發的模式，是開發人員進行開發，測試人員根據開發人員完成的各種文檔進行各類測試計劃的撰寫、進行測試，這樣的模式下，開發與測試是完全獨立甚至對立的立場。在整個測試驅動項目開發的過程中，對于測試驅動需求的實現都是由開發人員來完成的，這樣就有兩方面優點：
（1）促使開發人員從測試的角度來考慮問題、來進行設計。
（2）當開發人員在對測試需求進行設計時，也會促使他對已經完成的sRS、HLD等設計文檔進一步的進行反思，進而促進設計文檔的正確性、完備性，提高前期設計的質量。經驗證明，大型軟件的問題多是前期設計不當引起的，所以提高前期設計的質量尤為關鍵。
摘要：介紹測試驅動開發（TDD），以某通訊系統中測試驅動開發實現為例，從理論與實踐上論證了在復雜系統中測試驅動開發可提高測試的效率，在整體上確保系統的安全可靠性。
關鍵詞：軟件測試；TDD；測試驅動開發；cMM；軟件能力成熟度；自動測試腳本；
1、簡介
為了在軟件發布前發現盡量多的問題，在開發結束后進行測試，進而為了在軟件開發的前期發現盡量多的問題，而在軟件開發的過程中引入測試。隨著軟件產業的迅猛發展，尤其在通訊、航空、國防等大型復雜系統的研制中，對系統的可靠性、安全性要求尤為重要，為了提高系統的開發效率，在軟件開發的概念階段就把測試作為需求進行設計，即測試優先的理念，也就是測試驅動開發。
2、測試是確保軟件質量的重要手段
軟件工程的發展提出在軟件開發的過程中、在開發的每一個階段對軟件的質量進行監控，以便生產出高質量的軟件產品，測試體現在軟件開發的每一個階段中，這也就是CMM所強調的一種理念。現代的軟件開發工程是將整個軟件開發過程明確的劃分為幾個階段，將復雜問題具體按階段加以解決。在軟件的整個開發過程中，可以對每一階段提出若干明確的監控點，作為各階段目標實現的檢驗標準，從而提高開發過程的可見度和保證開發過程的正確性。實踐證明，軟件的質量不僅是體現在程序的正確性上，它與編碼以前所做的需求分析，軟件設計密切相關。因此，為了保證軟件的質量，應該著眼于整個軟件生存期，特別是著眼于編碼以前的各開發階段的工作。廣義的軟件測試由確認、驗證、測試三個方面組成：
（1）確認：評估將要開發的軟件產品是否是正確無誤、可行和有價值的。包含了對用戶需求滿足程度的評價，確保一個待開發軟件是正確無誤的，是對軟件開發構想的檢測。
（2）驗證：是檢測軟件開發的每個階段、每個步驟的結果是否正確無誤，是否與軟件開發各階段的要求或期望的結果相一致。驗證意味著確保軟件開發過程的正確無誤。
（3）測試：與普通的測試概念統一。通常經過單元測試、集成測試、系統測試三個環節。
在整個軟件生存期，確認、驗證、測試相輔相成，分別有其側重的階段。確認無疑會產生驗證和測試的標準，而驗證和測試通常又會幫助完成一些確認，特別是在系統測試階段。
3、測試驅動開發
3.1 測試驅動開發的提出
測試驅動開發的理念強調把測試作為開發過程的一個主要部分，比如在軟件的需求階段，把測試作為需求的一部分，在軟件開發的每一個階段，都有一部分的設計和代碼是專門為測試而服務的。這樣在編碼之前先設計測試方案，從測試的角度驗證設計，推導設計，同時將測試方案作為編碼的準繩，實時驗證其正確性。
下面具體介紹某無線網通訊系統中實現測試驅動開發的過程，以及取得的結果。
3.2 測試驅動開發設計實現
在需求分析階段集合開發設計人員、測試人員討論測試需求，然后在該項目開發的后續每一個階段來對這些測試驅動需求進行設計，最終在編碼階段實現并在測試階段測驗其效果。
3.2.1 需求分析階段
在需求分析階段通過綜合討論與論證，確定了以下4個方面的測試需求：
（1）可觀察性需求：開發出來的軟件是可觀察的。比如發生故障時會以告警、調試信息等方式以供查看。
（2）可控制性需求：開發出來的軟件是可以控制的，并且不影響其正常運行。比如說當發生某一嚴重故障時，可以通過使用某一預留的功能開關來定位、解決。
（3）協議測試需求：要滿足該軟件特定協議的規定和要求。比如要對這個協議進行測試需要一些特定的觀察點，那這個軟件就可以把這些觀察點的值輸出來以供對比、甚至可以自行比較并在最后輸出一個是否符合該協議的測試結果。
（4）業務測試驅動需求：要滿足特定業務流程的規定和要求，把一些特定的階段輸出來以供對比是否符合標準流程、甚至可以自行比較并在最后輸出一個是否符合該標準流程的測試結果。
3.2.2 概要設計階段
在概要設計階段對以上四個方面進行設計，并且討論具體的實施投入產出比，最后確定了以下17個具體的測試驅動實施方案：
（1）可觀察性需求
·告警：主要是提供一些預警的信息。可以分為幾個級別：致命告警、嚴重告警、重要告警、次要告警等。
·日志：主要是把一些運行過程中出現的一些情況等記錄下來，可以在出現問題時供查看。
·調試信息：系統自己打印出來的一些信息，可以給用戶查看系統現在運行的狀況。調試信息要注意可讀性、實用性、規范性。
·出錯信息：系統發現哪個地方出錯，就給出信息以便用戶參考。
·統計信息：主要是一些系統相關的統計信息，如統計在線的用戶個數、掉線的用戶個數等等。
·資源使用情況統計信息：查看系統一些資源的使用情況，如某個現在剩余端口數等信息。
·CPu占用率統計信息：查看系統cPu占用率，比如使用嵌入式操作系統pS0s或者VxWorks，可以提供手段來查看某個進程、各個進程占用CPU的情況。
·接口消息打印等：系統內部各個子模塊之問的接口消息可以打印出來，檢查是否正確。
（2）可控制性需求
·重定向功能：可以選擇輸出方式，例如把要打印到屏幕的信息，通過設置改為打印到某一文件。
·分級調試開關：調試信息分級，設置為某一調試級別就可以看到該級別下用戶可以看到的調試信息；這樣有助于定位問題、也有助于一些內部設計信息的保密陛。
·外部消息模擬：可以實現模擬外部消息的功能，這樣就可以減少對外部的依賴性。
·自動化測試腳本支持：可以通過編寫一些測試腳本，來進行一些自動化測試。
（3）協議測試驅動需求
·協議報文打印：如協議一些關鍵字段的打印。
·協議各消息統計：統計某協議各類消息的數量，尤其是當要跟其他產品進行對接時這個功能很重要。
（4）業務測試驅動需求
·接續跟蹤：具體業務所需的功能，可以讓用戶很直觀的看到系統處理的過程。
·狀態遷移：具體業務所需的功能，比如該系統設計了一個狀態機，那么通過打印狀態遷移過程可以很明顯的判斷處理是否正確、問題出現在哪一步。
·分類的業務相關統計信息：可以根據不同業務類型來進行統汁，這樣可以過濾掉一些所不需要的信息。