代碼覆蓋率（Code Coverage）是反映測試用例對被測軟件覆蓋程度的重要指標，也是衡量測試工作進展情況的重要指標。它也是對測試工作進行量化的重要指標之一，測試工作往往不如開發那樣激動人心，一個重要原因之一就是測試難于量化，而代碼覆蓋率恰恰是解決著一問題的重要指標。根據其覆蓋內容的不同，又可以細分為：語句覆蓋、判定覆蓋、條件覆蓋、路徑覆蓋以及循環覆蓋等等，這里有一篇很好的博客《代碼覆蓋率淺談》介紹了各種不同覆蓋率的定義。有的理解起來還是蠻拗口的，但其實不難，用到了再看就成！在所有這些覆蓋中語句覆蓋（Statement coverage）是最簡單的，也是最常用的、最有效的覆蓋率，Visual Studio采用的是語句覆蓋中的基本塊覆蓋（Basic block coverage）。
對于敏捷開發團隊而言，代碼覆蓋率是每個Sprint要完成的硬性質量標準（Exit Criteria）之一，覆蓋率高低根據項目的不同而不同：75%，80%甚至100%都是可能的。代碼覆蓋率是一個白盒概念，畢竟它最終還是要落實到代碼。既然代碼覆蓋率如此重要，那么什么時候該用它？該如何用它？
有人認為代碼覆蓋率重要，所以從項目的一開始就要進行代碼覆蓋率的檢查和分析，即 獲取覆蓋率 –> 發現未覆蓋的代碼 –> 添加新測試用例。這樣的使用方式，我把它命名為“代碼覆蓋率驅動的測試（CCDT，Code Coverage Driven Test）”。CCDT看起來很美，理論上無懈可擊，但實際操作則完全不是那么回事兒。先不說這種方式是否正確，單就由此引入的開銷來說，就夠項目組喝一壺的，呵呵！之所這樣說，是因為CCDT需要經歷：獲取覆蓋率、分析覆蓋率和添加測試用例這三步，每一步都存在著很多潛在“副產品”開銷，尤其是前兩步。要獲取覆蓋率，需要執行所有的測試用例，而你知道現在業界70%的測試仍然是手動的，僅為了覆蓋率就頻繁的執行測試用例，顯然是不現實的；頻繁分析覆蓋率結果也是一件耗時的工作，無論開發人員還是測試人員做都是如此，尤其是對于采用敏捷開發方法的團隊，短迭代不允許引入如此勞神的工作內容。胡凱在他的博客中稱這種唯覆蓋率論癥狀為“測試覆蓋率強迫癥”，其中有一句描述很精彩：
“ 測試覆蓋率僅僅能夠告訴團隊什么沒有被測試，根本就回答不了軟件是否經過了有效測試！”
我認為對于測試團隊而言，測試的過程應該是用戶場景覆蓋驅動的測試（USCDT，User Scenario Coverage Driven Test） ，即測試人員應該從用戶真實使用場景出發，思考要測試的內容和設計測試用例。代碼覆蓋率是對USCDT的必要補充，以發現其中未覆蓋的場景（Test Hole）。代碼覆蓋應該是在項目/迭代的中后期引入，不用很頻繁，點到為止，例如對一個3-4周的迭代，3次的覆蓋率檢查就已經足夠了。當然，如果你的自動化測試比例比較高，采用持續集成（Continuous Integration）的方式，例如：Visual Studio 2010中持續集成的構建功能，每次都能自動的進行代碼覆蓋率的統計，則可以更早，更頻繁進行代碼覆蓋率，但前提一定是這不會帶來過多的開銷。
說了這么多，下面來點兒實際的吧，看看Visual Studio 2010中如何獲取代碼覆蓋率數據！在Visual Studio的集成開發環境中獲自動化測試用例的碼覆蓋率數據是最簡單的（采用命令行方式則稍復雜一些，但它還可以用來獲取手動測試用例的覆蓋數據），只需要下面三步:
步驟一 ：在Test Settings配置中選擇Code Coverage
(Updated 2011/6/1) 這里需要注意，當選擇Code Coverage項時，還要選擇“Configure”按鈕去配置一下要針對哪一個文件（.exe/.dl）收集覆蓋數據，Visual Studio會自動對這個文件進行instrument操作，否則是不會收集到覆蓋數據的。
步驟二 ：執行自動化測試用例
步驟三 ：查看代碼覆蓋率結果
隨著編程語言和開發工具的現代化和傻瓜化，現在獲取和分析代碼覆蓋率工作越來越簡單了，但人們對代碼覆蓋數據的使用卻仍然停留在比較原始的階段。其中還有很多值得去深入發掘的好東東，用于幫助測試團隊優化測試過程和測試用例的設計。《代碼覆蓋從簡到繁 (四) – 為代碼簽入把門兒 》一文中介紹了，如何在代碼簽入的流程中引入覆蓋率檢查。
文章列表
留言列表
