測試覆蓋率
（test coverage）是衡量軟體測試
完整性
的一個重要指標。掌握測試覆蓋率資料，有利於客觀認識軟體質量，正確瞭解測試狀態，有效改進測試工作。
當然，要發揮這些作用，前提是我們掌握了真實的測試覆蓋率資料。通常這並不是一件很直接的事情。那麼，如何
度量
測試覆蓋率呢？
在度量測試覆蓋率之前，我們需要明確測試覆蓋率的
定義
。畢竟，不同的定義會產生完全不同的覆蓋率資料。這裡，我基於個人認知和經驗，總結
三種
最常見的測試覆蓋率定義及度量方法。
最著名的測試覆蓋率就是程式碼覆蓋率
。這是一種
面向軟體開發和實現
的定義。它關注的是在執行測試用例時，有哪些軟體程式碼被執行到了，有哪些軟體程式碼沒有被執行到。
被執行的程式碼數量與程式碼總數量之間的比值，就是程式碼覆蓋率
。
這裡，根據
程式碼粒度
的不同，程式碼覆蓋率可以進一步分為原始檔覆蓋率，類覆蓋率，函式覆蓋率，分支覆蓋率，語句覆蓋率等。它們形式各異，但本質是相同的。
如何度量程式碼覆蓋率呢？一般可以透過
第三方工具
完成。不同程式語言，有不同的工具。例如Java語言有Jacoco，Go語言有GoCov，Python語言有Coverage。py。
這些度量工具有個特點，那就是它們一般只適用於白盒測試，尤其是
單元測試
。對於黑盒測試（例如功能測試/系統測試）來說，度量它們的程式碼覆蓋率則相對困難多了。
主流程式語言一般都有現成的單元測試工具，拿過來稍作配置即可使用。但是，如果想更進一步去了解這些工具背後的實現原理，就需要花費一些功夫了。
以Python覆蓋率工具Coverage。py為例，它包括執行，分析和生成報告三大模組。
最核心
的執行模組依賴Python內建的trace函式。這是一個由Python直譯器提供的，當每一行Python程式碼被執行時所啟用的函式。
基於trace函式，我們可以得到每一行被執行的程式碼所在的檔案和行數。然後，結合軟體原始碼，我們就可以分析出測試的程式碼覆蓋情況，最後生成覆蓋報告。
對於黑盒測試，例如功能測試/整合測試/系統測試等來說，測試用例通常是
基於軟體需求而不是軟體實現
所設計的。因此，度量這類測試完整性的手段一般是
需求覆蓋率
，即
測試所覆蓋的需求數量與總需求數量的比值
。
視
需求粒度
的不同，需求覆蓋率的具體表現也有不同。例如，系統測試針對的是比較粗的需求，而功能測試針對的是比較細的需求。當然，它們的本質是一致的。
如何度量需求覆蓋率呢？通常沒有現成的工具可以使用，而需要
依賴人工計算
，尤其是需要依賴人工去
標記
每個測試用例和需求之間的
對映關係
。
對於黑盒測試來說，由於測試是基於使用者場景而不是軟體實現設計的。因此，這個時候去度量軟體程式碼覆蓋率，其意義並不顯著，至少是不如需求覆蓋率的。
程式碼覆蓋率和需求覆蓋率有一個共同點，即它們都是
面向測試過程
的指標。因此有個不足之處，即
覆蓋率資料可能無法完全反映真實的測試狀態和水平
。
對於程式碼覆蓋率來說，
廣為詬病
的一點就是100%的程式碼覆蓋率並不能說明程式碼就被完全覆蓋沒有遺漏了。因為程式碼的執行順序和函式的引數值，都可能是千變萬化的。一種情況被覆蓋到，不代表所有情況被覆蓋到。
對於需求覆蓋率來說，100%的覆蓋率也不能說“萬事大吉”。因為需求可能有遺漏或存在缺陷，測試用例與需求之間的對映關係，尤其是用例是否真正能夠覆蓋對應的測試需求，也可能是存在疑問的。
測試的目的是發現軟體缺陷。因此，衡量測試完整性的
終極指標
應該是
面向測試結果的缺陷覆蓋率
，即
測試所實際發現的缺陷數量與測試所應該發現的缺陷總量的比值
。
軟體測試一般是分為多個測試階段的。每個階段有每個階段的任務。對於當前測試階段來說，在後續階段發現的缺陷中，屬於當前階段（而不是更早階段）
遺漏
出去的缺陷是我們需要重點關注的。
雖然討論缺陷覆蓋率有一種“事後諸葛亮”的感覺，但是它的意義是不容忽視的。一方面它提供了評價某一階段測試工作成效的重要指標，另一方面它為我們改進測試工作提供了重要參考。例如，針對每一個遺漏缺陷深入挖掘，舉一反三，可以避免同類問題在未來再次發生。
總結一下，這裡介紹了三種常見的測試覆蓋率的定義和度量方法，分別是
程式碼覆蓋率，需求覆蓋率和缺陷覆蓋率
。它們適用於不同的場景，有各自的優勢與不足。需要注意的是，它們不是互相排斥，而是
相互補充
的。
關於測試覆蓋率，最重要的一點應該是邁出第一步，即
有意識地去收集這種資料
。沒有覆蓋率資料，測試工作會有點像在“黑燈瞎火”中走路。有了覆蓋率資料，並持續監測，利用和改進這個資料，才是一條讓測試工作越來越好的光明大道。
我是肖哥shelwin，一個高質量軟體工程實踐者和推動者。歡迎新增我的個人公眾號測試不將就或關注同名部落格，謝謝，獲得更多
自動化測試, 持續整合, 軟體工程實踐, Python程式設計
等領域原創文章。
