模板
教程
環境
性能
功能
管理
怎樣才能做好單元測試(2)
單元測試計劃
單元測試方案
單元測試用例
單元測試規程
單元測試日報
單元測試問題單
單元測試報告
單元測試輸入及輸出數據
單元測試工具
單元測試代碼及設計文檔
為了保證單元測試工作產品的準確性，需要對測試代碼和腳本進行走讀或檢視，對測試文檔進行評審。這些工作產品應該納入到配置管理，對于其修改要走配置變更流程，并及時發布其配置狀態，這樣可以保持單元測試工作產品的一致性和可回溯性。
必須制訂覆蓋率指標和質量目標來指導和驗收單元測試
單元測試必須制訂一定的覆蓋率指標和質量目標，來指導單元測試設計和執行，同時作為單元測試驗收的標準。設計用例時，可針對要達到的覆蓋率指標來設計用例，而在測試執行時，可以依據覆蓋率分析工具分析測試是否達到了覆蓋率指標，如果沒達到，需要分析哪些部分沒有覆蓋到，從而補充用例來達到覆蓋率指標。而單元測試質量目標的制訂，需要符合軟件企業的實際過程能力，這依賴于軟件企業以前單元測試過程度量數據的積累，不能憑空制造出來。有了以前度量數據的積累，完全可以了解當前組織的單元測試能力，例如單元測試每千行代碼發現的缺陷數是多少。如果單元測試統計結果沒有落到這個質量目標范圍內，說明單元測試過程中某些方面存在一些問題，需要對過程進行后找出問題原因進行改進。
這些指標確定下來后，一定要嚴格推行。會有一些測試人員找出各種理由證明覆蓋率指標達不到等等，這需要 QA 根據實際情況分析指標是否合理。實際證明有一個相對簡單的標準也比沒有標準要好得多，我們的實踐發現，通過推行硬性指標，單元測試發現的問題數目比沒有標準前至少增加了 2 倍。
下面是印度 SASKEN 公司的質量目標：
| 階段 | 組織目標 | 目標上限 | 目標下限 |
| HLD （概要設計） | 50 Major Defects / 100 pages | 55 Major Defects/100 pages | 45 Major Defects /100 pages |
| LLD（詳細設計） | 40 Major Defects / 100 pages | 44 Major Defects/100 pages | 36 Major Defects / 100 pages |
|
Unit Test Plan （單元測試計劃） |
25 Major Defects / 100 pages | 27.5 Major Defects /100 pages | 22.5 Major Defects / 100 pages |
| Code Review （代碼走讀） | 20 Major Defects / KLOC | 22 Major Defects / KLOC Www.Syue.Com | 18 Major Defects / KLOC |
| Defects during Unit test（單元測試） | 15 Major Defects / KLOC | 16.5 Major Defects / KLOC | 13.5 Major Defects / KLOC |
| Defects during Integration test（集成測試） | 6 Major Defects / KLOC | 6.6 Major Defects / KLOC | 5.4 Major Defects / KLOC |
加強詳細設計文檔評審
詳細設計是單元測試的主要輸入，詳細設計文檔的質量將直接影響到單元測試的質量，所以一定要加強詳細設計文檔的評審，特別是要寫相關測試方案和進行測試用例設計的人員，一定要從寫測試用例的角度看這個詳設是否符合要求，否則后期進行單元測試設計時會發現無法依據詳細設計進行單元測試設計。軟件組織可以將詳細設計評審的要點以查檢表的形式固化下來，這樣在詳細設計評審的時候依據查檢表一項項檢查，既提高了評審效率，也能保證評審效果。評審流程需要確定如果不滿足查檢表 n% 以上的條件，被評審詳細設計文檔就不能通過，需要重新設計。
通常詳細設計文檔有兩種形式，一種是流程圖的形式，另一種是偽碼的形式。用流程圖表達的優點是直觀，利于單元測試用例設計，缺點是描述性比較差，文檔寫作麻煩，不利于文檔的變更和修改;偽碼的方式可能正好相反，文檔變更修改簡單，可以方便地在任何地方增加文字說明，而且翻譯成代碼更加便捷，但不直觀，不利于進行單元測試用例設計。
詳細設計和單元測試設計一定要分離。如果單元測試由測試人員承擔，這一點不會有什么問題;如果單元測試由開發人員承擔，那么實際操作時可以讓項目組內做相同或者相近任務的成員相互，根據對方的詳設設計對方的單元測試。這樣在單元測試開始之前的詳細設計評審階段就要考慮到后面的分工，安排相關的單元測試設計人員參與相關詳細設計的評審。
如果代碼沒有對應的經過評審后的詳細設計文檔，建議不進行單元測試，而是用代碼審查替代單元測試。
開發人員在編碼的過程中，可能會發現詳設中的問題，并對代碼進行修改，這種修改應該回溯到詳設，并對詳設進行相應的修改，否則到單元測試執行的時候，會發現代碼和詳設根本對不上，無法執行下去。詳設的修改要受控制，要走流程，它的變更也要經過評審。因為單元測試是詳細設計的下游活動，如果詳細設計隨意更改，單元測試文檔很難和其保持一致，這樣單元測試也就失去了依據和意義。只有詳設也納入配置管理，才能保證單元測試和詳設的一致性。
單元測試者技能的提高
1 .加強對單元測試人員的技能
單元測試的質量很大程度上決定于進行單元測試的人的技術水平。如果測試者不具備單元測試的知識，那么應該對測試者進行相關的培訓。一個沒有做過單元測試人，不經過培訓初次是很難做好單元測試的。單元測試在詳設階段結束時開始，但是單元測試相關培訓應該盡早準備和計劃，培訓可以分兩個階段，每個階段的內容類似。第一階段是寫單元測試方案前，培訓對象為測試方案的寫作者和詳設的寫作者，這樣可以在設計時多考慮可測試性，培訓的內容為單元測試基本概念、單元測試分析方法、單元測試用例的寫作、單元測試標準的明確;第二階段為單元測試執行前，對象為測試執行者，培訓內容為具體單元測試的執行，包括驅動函數、樁函數的構造、覆蓋率測試工具的使用( TrueCoverage 、 Logiscope 等)、利用自動化單元測試框架構造單元測試自動化( TCL 、 CppUnit 、 JUnit 等)。培訓過程中最好結合實例穿插其中，會比較生動，而且增強理解。
