如何做好單元測試
單元測試是對軟件基本組成單元進行的測試，是屬于白盒測試的范疇，它主要通過對代碼的邏輯結構進行分析來設計測試用例。在動態測試手段中，單元測試是一種非常高效的測試方法，并且是軟件測試周期中第一個進行的測試。從成本角度考慮，缺陷發現越早越好，加強單元測試力度有利于降低缺陷定位和修復難度，從而降低缺陷解決成本，同時加強單元測試也減輕了后續集成測試和系統測試的負擔。根據業界的統計，一個 BUG 在單元測試階段發現花費是 1 的話，到集成測試就變為 10 ，到系統測試就高達 100 ，到實際推向市場量產后就高達 1000 。但單元測試在目前國內軟件企業中開展得并不好，一方面是由于對單元測試重視程度不夠，測試投入不足，另一方面是由于在單元測試實踐方面積累得也不夠，單元測試處于一種摸索狀態。
軟件的質量由組織、流程和技術三個維度來決定，任何一個維度都不能單獨決定軟件的質量。好的組織結構可以保證流程的順利實施，好的流程能提高軟件開發的規范性和可控性，從而提高軟件開發的效率和質量，而采用了好的技術和有好的技術的載體 —— 人，則從根本上保證了軟件的質量。
總而言之，組織、流程和技術是軟件質量三角，本文將從這三個方面對如何做好單元測試進行論述。
組織結構應該保證測試組參與單元測試
目前無論是工業界還是學術界都認為單元測試應該由開發人員開展，這是因為從單元測試的過程看，單元測試普遍采用白盒測試的方法，離不開深入被測對象的代碼，同時還需要構造驅動模塊、樁函數，因此開展單元測試需要較好的開發知識。從人員的知識結構、對代碼的熟悉程度考慮，開發人員具有一定的優勢。
單元測試由開發人員進行能帶來一些特別的收益。我們知道，在實踐中開發人員進行單元測試一般推薦采用交叉測試的方法，例如由被測單元的調用方進行該單元的測試，即盡量避免對自己的代碼進行單元測試。這種交叉的測試安排可以避免測試受開發思路影響太大，局限于原來的思路不容易發現開發過程中制造的問題;二來也達到一個技術備份或充分交流的目的，這對組織非常有利。即使不采用交叉測試的方法，而安排單元的生產者自行開展單元測試，也是有很大的優越性的，其最大的優點是快速，且能更好的實現 “ 預防錯誤 ” 。在人員緊張的情況下這種自行測試的安排也是不錯的選擇。
從經驗值來看，單元測試投入和編碼投入相比基本上是一比一，如果由專職測試隊伍來進行單元測試，維持這樣龐大的單一任務隊伍顯然是不合適的。
以上談的是由開發人員進行單元測試的優點，其中主要是從單元測試的效率角度來考慮。但是從單元測試效果的角度考慮，必須從組織結構上保證測試組參與單元測試，這是因為：
首先，從目前國內企業普遍現狀來看，測試人員質量意識要高于開發人員，測試人員參與單元測試能夠提高測試質量。
其次，對被測系統越了解，測試才有可能越深入，測試人員參與單元測試，將使得測試人員能夠從代碼級熟悉被測系統，這對測試組后期集成測試和系統測試活動非常有幫助，會很大的提升集成測試和系統測試質量。
測試組以何種方式參與單元測試，應該結合軟件組織的實際情況來定。如果軟件組織測試資源充分，測試人員對開發人員的比例較高，那么可以由測試人員獨立承擔部分重要模塊的單元測試工作;如果測試資源不足，測試人員對開發人員的比例較低，那么可以采取由測試人員進行單元測試計劃、單元測試設計的工作，而單元測試的實現和執行由開發人員來完成;而如果測試資源非常缺乏，連單元測試計劃、單元測試設計都無法承擔，那么測試組至少應該參與開發組的各相關單元測試文檔、單元測試報告的評審，保證單元測試的質量。
加強單元測試流程規范性
● 制訂單元測試的過程定義
軟件質量的提高需要規范的流程，對軟件開發過程進行管理也需要依據規范的過程定義。過程定義包含階段的劃分、階段的入口 / 出口準則、階段的輸入 / 輸出、角色和職責、模板和查檢表等等。將單元測試劃分為幾個階段便于對單元測試過程進行控制，體現軟件測試可控性。要提高單元測試的質量，首先要制定規范的單元測試過程，開發組、測試組、 SCM 組、 SQA 組等可以依據單元測試過程定義開展各自的工作，共同保證單元測試的質量。
單元測試過程的定義需要參照企業的實際情況，例如階段劃分可以分為四個階段：計劃、設計、實現、執行。其中計劃階段應當考慮整個單元測試過程的時間表，工作量，任務的劃分情況，人員和資源的安排情況，需要的測試工具和測試方法，單元測試結束的標準及驗收的標準等，同時還應當考慮可能存在的風險，以及針對這些風險的具體處理辦法，并輸出《單元測試計劃》文檔，作為整個單元測試過程的指導。設計階段需要具體考慮對哪些單元進行測試，被測單元之間的關系以及同其他模塊之間單元的關系，具體測試的策略采用哪一種、如何進行單元測試用例的設計、如何進行單元測試代碼設計、采用何種工具等，并輸出《單元測試方案》文檔，用來指導具體的單元測試操作。實現階段需要完成單元測試用例設計、腳本的編寫，測試驅動模塊的編寫，測試樁模塊的編寫工作，輸出《單元測試用例》文檔、相關測試代碼。執行階段的主要工作是搭建單元測試環境，執行測試腳本，記錄測試結果，如果發現錯誤，開發人員需要負責錯誤的修改，同時進行回歸測試，該階段結束需要提交《單元測試報告》。
具體進行單元測試過程定義的時候，可以進行一定的裁減，例如可以裁減為設計和執行兩個階段，將《單元測試方案》和《單元測試用例》合二為一。
● 單元測試工作產品必須納入配置管理
單元測試工作產品指單元測試完成后應交付的測試文檔、測試代碼及測試工具等，一般包括但不限于如下工作產品，可以根據實際情況進行適當裁剪：
● 單元測試計劃
● 單元測試方案
● 單元測試用例
● 單元測試規程
● 單元測試日報
● 單元測試問題單
● 單元測試報告
● 單元測試輸入及輸出數據
● 單元測試工具
● 單元測試代碼及設計文檔
為了保證單元測試工作產品的準確性，需要對測試代碼和腳本進行走讀或檢視，對測試文檔進行評審。這些工作產品應該納入到配置管理，對于其修改要走配置變更流程，并及時發布其配置狀態，這樣可以保持單元測試工作產品的一致性和可回溯性。
● 必須制訂覆蓋率指標和質量目標來指導和驗收單元測試
單元測試必須制訂一定的覆蓋率指標和質量目標，來指導單元測試設計和執行，同時作為單元測試驗收的標準。設計用例時，可針對要達到的覆蓋率指標來設計用例，而在測試執行時，可以依據覆蓋率分析工具分析測試是否達到了覆蓋率指標，如果沒達到，需要分析哪些部分沒有覆蓋到，從而補充用例來達到覆蓋率指標。而單元測試質量目標的制訂，需要符合軟件企業的實際過程能力，這依賴于軟件企業以前單元測試過程度量數據的積累，不能憑空制造出來。有了以前度量數據的積累，完全可以了解當前組織的單元測試能力，例如單元測試每千行代碼發現的缺陷數是多少。如果單元測試統計結果沒有落到這個質量目標范圍內，說明單元測試過程中某些方面存在一些問題，需要對過程進行審計后找出問題原因進行改進。
這些指標確定下來后，一定要嚴格推行。會有一些測試人員找出各種理由證明覆蓋率指標達不到等等，這需要 QA 根據實際情況分析指標是否合理。實際證明有一個相對簡單的標準也比沒有標準要好得多，我們的實踐發現，通過推行硬性指標，單元測試發現的問題數目比沒有標準前至少增加了 2 倍。
● 加強詳細設計文檔評審
詳細設計是單元測試的主要輸入，詳細設計文檔的質量將直接影響到單元測試的質量，所以一定要加強詳細設計文檔的評審，特別是要寫相關測試方案和進行測試用例設計的人員，一定要從寫測試用例的角度看這個詳設是否符合要求，否則后期進行單元測試設計時會發現無法依據詳細設計進行單元測試設計。軟件組織可以將詳細設計評審的要點以查檢表的形式固化下來，這樣在詳細設計評審的時候依據查檢表一項項檢查，既提高了評審效率，也能保證評審效果。評審流程需要確定如果不滿足查檢表 n% 以上的條件，被評審詳細設計文檔就不能通過，需要重新設計。
通常詳細設計文檔有兩種形式，一種是流程圖的形式，另一種是偽碼的形式。用流程圖表達的優點是直觀，利于單元測試用例設計，缺點是描述性比較差，文檔寫作麻煩，不利于文檔的變更和修改;偽碼的方式可能正好相反，文檔變更修改簡單，可以方便地在任何地方增加文字說明，而且翻譯成代碼更加便捷，但不直觀，不利于進行單元測試用例設計。
詳細設計和單元測試設計一定要分離。如果單元測試由測試人員承擔，這一點不會有什么問題;如果單元測試由開發人員承擔，那么實際操作時可以讓項目組內做相同或者相近任務的成員相互交換，根據對方的詳設設計對方的單元測試。這樣在單元測試開始之前的詳細設計評審階段就要考慮到后面的分工，安排相關的單元測試設計人員參與相關詳細設計的評審。
如果代碼沒有對應的經過評審后的詳細設計文檔，建議不進行單元測試，而是用代碼審查替代單元測試。
開發人員在編碼的過程中，可能會發現詳設中的問題，并對代碼進行修改，這種修改應該回溯到詳設，并對詳設進行相應的修改，否則到單元測試執行的時候，會發現代碼和詳設根本對不上，無法執行下去。詳設的修改要受控制，要走變更控制流程，它的變更也要經過評審。因為單元測試是詳細設計的下游活動，如果詳細設計隨意更改，單元測試文檔很難和其保持一致，這樣單元測試也就失去了依據和意義。只有詳設也納入配置管理，才能保證單元測試和詳設的一致性。
單元測試者技能的提高
1 .加強對單元測試人員的技能培訓
單元測試的質量很大程度上決定于進行單元測試的人的技術水平。如果測試者不具備單元測試的知識，那么應該對測試者進行相關的培訓。一個沒有做過單元測試人，不經過培訓初次是很難做好單元測試的。單元測試在詳設階段結束時開始，但是單元測試相關培訓應該盡早準備和計劃，培訓可以分兩個階段，每個階段的內容類似。第一階段是寫單元測試方案前，培訓對象為測試方案的寫作者和詳設的寫作者，這樣可以在設計時多考慮可測試性，培訓的內容為單元測試基本概念、單元測試分析方法、單元測試用例的寫作、單元測試標準的明確;第二階段為單元測試執行前，對象為測試執行者，培訓內容為具體單元測試的執行，包括驅動函數、樁函數的構造、覆蓋率測試工具的使用( TrueCoverage 、 Logiscope 等)、利用自動化單元測試框架構造單元測試自動化( TCL 、 CppUnit 、Junit等)。培訓過程中最好結合實例穿插其中，會比較生動，而且增強理解。
通過以上的系統培訓，可以統一單元測試方法、明確單元測試的標準、掌握單元測試基本技能，為后期單元測試的順利開展掃平道路。
2 .必須引入工具進行輔助
單元測試非常需要工具的幫助，特別是覆蓋率工具不能缺少，否則用例執行后無法得到測試質量如語句覆蓋、路徑覆蓋等情況，也就無法對被測對象進行進一步的分析。應用較廣的分析覆蓋率的工具有 Logiscope 、 TrueCoverage 、 PureCoverage 等，它們的功能有強有弱，可以根據實際情況采用。
為了提高單元測試的效率，特別是提高進行回歸測試時的效率，需要在單元測試中引入自動化。目前常用的方法是采用 TCL 語言編寫擴展指令，構造自己的單元測試自動化。也可以直接采用開源的自動化測試框架如 CppUnit 、 JUnit 等。
此外，在單元測試之前，還需要利用 PC_Lint 對被測代碼進行檢查，排除代碼語法錯誤，確保進行單元測試的代碼已經具備了基本質量，保證單元測試能夠順利進行，提高單元測試執行效率。
3 .單元測試者加強對被測軟件的全面了解
單元測試的目的除了要發現編碼中引入的錯誤和發現代碼與詳細設計不一致的地方之外，還有一個目的是為了保證詳細設計的質量。因為測試分析和測試用例設計需要依據詳細設計來進行，這個過程實際上是對詳細設計的重新檢視，在這個過程中會發現以前評審中沒有發現的問題。
無論是在單元測試的設計活動中還是在單元測試的執行過程中，都需要測試者了解軟件的需求和概要，加強對被測軟件的全面了解。否則對被測對象了解不深，只能就被測單元的流程而測流程，而對于該流程是否正確就無法保證了。
測試者要注重與開發的交流，這樣能對被測單元有更深的了解;同時因為進度的原因，包括詳設在內的文檔往往來不及更新，所以最新最正確的思想往往存在于開發人員的腦袋里，及時與他們交流才會獲得最及時的信息，減少將來更新用例的工作量。
結語
單元測試是軟件開發過程中非常重要的質量保證手段，加強單元測試對提高軟件質量具有非常重要的意義。而做好單元測試不是只要掌握單元測試方法就可以了的，這需要從組織、流程和技術三個方面來保證。
原文地址：http://www.guojf.com/cat_4/17.html
【編輯推薦】
