通常詳細設計文檔有兩種形式，一種是流程圖的形式，另一種是偽碼的形式。用流程圖表達的優點是直觀，利于單元測試用例設計，缺點是描述性比較差，文檔寫作麻煩，不利于文檔的變更和修改;偽碼的方式可能正好相反，文檔變更修改簡單，可以方便地在任何地方增加文字說明，而且翻譯成代碼更加便捷，但不直觀，不利于進行單元測試用例設計。
詳細設計和單元測試設計一定要分離。如果單元測試由測試人員承擔，這一點不會有什么問題;如果單元測試由開發人員承擔，那么實際操作時可以讓項目組內做相同或者相近任務的成員相互交換，根據對方的詳設設計對方的單元測試。這樣在單元測試開始之前的詳細設計評審階段就要考慮到后面的分工，安排相關的單元測試設計人員參與相關詳細設計的評審。
如果代碼沒有對應的經過評審后的詳細設計文檔，建議不進行單元測試，而是用代碼審查替代單元測試。
開發人員在編碼的過程中，可能會發現詳設中的問題，并對代碼進行修改，這種修改應該回溯到詳設，并對詳設進行相應的修改，否則到單元測試執行的時候，會發現代碼和詳設根本對不上，無法執行下去。詳設的修改要受控制，要走變更控制流程，它的變更也要經過評審。因為單元測試是詳細設計的下游活動，如果詳細設計隨意更改，單元測試文檔很難和其保持一致，這樣單元測試也就失去了依據和意義。只有詳設也納入配置管理，才能保證單元測試和詳設的一致性。
• 單元測試者技能的提高
1 .加強對單元測試人員的技能培訓
單元測試的質量很大程度上決定于進行單元測試的人的技術水平。如果測試者不具備單元測試的知識，那么應該對測試者進行相關的培訓。一個沒有做過單元測試人，不經過培訓初次是很難做好單元測試的。單元測試在詳設階段結束時開始，但是單元測試相關培訓應該盡早準備和計劃，培訓可以分兩個階段，每個階段的內容類似。第一階段是寫單元測試方案前，培訓對象為測試方案的寫作者和詳設的寫作者，這樣可以在設計時多考慮可測試性，培訓的內容為單元測試基本概念、單元測試分析方法、單元測試用例的寫作、單元測試標準的明確;第二階段為單元測試執行前，對象為測試執行者，培訓內容為具體單元測試的執行，包括驅動函數、樁函數的構造、覆蓋率測試工具的使用( TrueCoverage 、 Logiscope 等)、利用自動化單元測試框架構造單元測試自動化( TCL 、 CppUnit 、 JUnit 等)。培訓過程中最好結合實例穿插其中，會比較生動，而且增強理解。
通過以上的系統培訓，可以統一單元測試方法、明確單元測試的標準、掌握單元測試基本技能，為后期單元測試的順利開展掃平道路。
2 .必須引入工具進行輔助
單元測試非常需要工具的幫助，特別是覆蓋率工具不能缺少，否則用例執行后無法得到測試質量如語句覆蓋、路徑覆蓋等情況，也就無法對被測對象進行進一步的分析。應用較廣的分析覆蓋率的工具有 Logiscope 、 TrueCoverage 、 PureCoverage 等，它們的功能有強有弱，可以根據實際情況采用。
為了提高單元測試的效率，特別是提高進行回歸測試時的效率，需要在單元測試中引入自動化。目前常用的方法是采用 TCL 語言編寫擴展指令，構造自己的單元測試自動化。也可以直接采用開源的自動化測試框架如 CppUnit 、 JUnit 等。
此外，在單元測試之前，還需要利用 PC_Lint 對被測代碼進行檢查，排除代碼語法錯誤，確保進行單元測試的代碼已經具備了基本質量，保證單元測試能夠順利進行，提高單元測試執行效率。
3 .單元測試者加強對被測軟件的全面了解
單元測試的目的除了要發現編碼中引入的錯誤和發現代碼與詳細設計不一致的地方之外，還有一個目的是為了保證詳細設計的質量。因為測試分析和測試用例設計需要依據詳細設計來進行，這個過程實際上是對詳細設計的重新檢視，在這個過程中會發現以前評審中沒有發現的問題。
無論是在單元測試的設計活動中還是在單元測試的執行過程中，都需要測試者了解軟件的需求和概要，加強對被測軟件的全面了解。否則對被測對象了解不深，只能就被測單元的流程而測流程，而對于該流程是否正確就無法保證了。
測試者要注重與開發的交流，這樣能對被測單元有更深的了解;同時因為進度的原因，包括詳設在內的文檔往往來不及更新，所以最新最正確的思想往往存在于開發人員的腦袋里，及時與他們交流才會獲得最及時的信息，減少將來更新用例的工作量。
結尾
單元測試是軟件開發過程中非常重要的質量保證手段，加強單元測試對提高軟件質量具有非常重要的意義。而做好單元測試不是只要掌握單元測試方法就可以了的，這需要從組織、流程和技術三個方面來保證。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
