當談論覆蓋率時我們在談什麼？

代碼覆蓋率 vs. 測試覆蓋率

代碼覆蓋率通常指跑完測試後, 由工具自動統計的在跑測試的過程中被測代碼的覆蓋率, 細分的話包括語句覆蓋率, 分支覆蓋率, 函數覆蓋率等. 由於代碼覆蓋率可由工具自動產生, 採集成本非常低, 而又比較直觀, 所以歷來受到開發團隊及管理者的歡迎, 有的組織甚至將其作為 KPI 指標之一。

然而圍繞著代碼覆蓋率, 有很多有趣的事情, 尤其是將其作為 KPI 的時候. 你會發現, 長期在低位徘徊的代碼覆蓋率, 突然之間會有一個比較大的提升. 究其原因, 是開發團隊在短時間內加了」測試」. 「測試」是打引號的, 因為當我們近距離觀察這些」測試」的時候, 會發現通常是調用了某個高層的入口函數, 因而牽出很多底層函數, 覆蓋率就上去了, 然而, 沒有一個斷言(assertion), 或者是區區幾個斷言. 也就是說, 把產品跑了一遍, 但沒有判斷其行為是否符合預期, 而代碼覆蓋率突然就達標了。

儘管對於追求自我改進的團隊來說, 不會這麼掩耳盜鈴, 代碼覆蓋率依然是有價值的反饋指標, 但這從側面說明了代碼覆蓋率並沒有表達出我們對於外部質量真正的關注點. 那麼我們對於質量真正的關注點是什麼呢?

是斷言的覆蓋率, 即測試覆蓋率. 換句話說, 我們真正關心的是, 我們總共應該有多少測試用例/驗收條件/檢查點, 它們中有多少已經被覆蓋了, 即做出了真正的斷言. 但目前為止, 還沒有工具能自動統計跑完測試後, 測試覆蓋率是多少. 代碼覆蓋率僅僅是無法自動統計測試覆蓋率時的一個替代品。

為了統計測試覆蓋率, 需要準備分子和分母的信息. 分母是產品」完整」的測試用例列表, 分子是已經執行的測試用例列表, 包括手工和自動. 如果你關心測試覆蓋率, 而手頭又沒有這兩個東西, 就要開始準備了。

注1: 利用現有的 xUnit 測試框架, 可以在某種程度上得到測試覆蓋率. 比如可以將」完整」的測試用例列表用 xUnit 的測試用例表達出來, 其中對於還沒實現的, 設置為 ignore. 這樣可以從最後的報告中看出總數, 和 ignore 的數量(當然如果你不做斷言, 還是白搭). 現在更多的是藉助管理工具甚至 Excel, 來手工維護」完整」的測試用例列表及狀態. 如果你知道有更好的方式, 請告訴我.

注2: 前面」完整」的測試用例列表, 「完整」一直打著引號, 因為這是一個無法證明的問題, 我們只能根據經驗設計測試用例, 無法保證其完整性, 並且隨著產品的開發, 這個列表也會動態更新. 至於如何讓測試用例儘可能完整, 是組織應該投入的地方。

此測試覆蓋率 vs. 彼測試覆蓋率

基於前面的描述, 那麼當我的測試覆蓋率達到某個比較高的數值, 比如80%, 是不是我就可以比更低的數值比如20%, 對產品更有信心呢? 答案取決於你的測試用例的設計。

我們都聽過80/20原則. 比如用戶80%的時間在使用20%的功能, 20%的功能就可以支撐起用戶最關鍵的業務場景. 那麼, 如果80%的測試覆蓋率, 覆蓋的是那不常用的80%的功能, 而20%的覆蓋率, 覆蓋的恰恰是最常用最關鍵的那20%的功能, 那麼, 你是否還像開始那樣, 相信80%的覆蓋率帶來的安全感呢?

基於測試覆蓋率很難達到100%這個前提, 基於我們的發布時間總是很緊張而又要保證質量這個前提, 我們必須投入精力, 做測試用例的價值分析, 挑選出最有價值的測試用例, 優先安排資源實現和運行。

如果團隊的測試用例沒有經過價值分析, 沒有優先順序劃分, 那麼這就是接下來馬上應該做的事. 這牽扯到一個問題, 測試人員及測試技能的價值。

當我們談論測試技能時我們在談什麼

最近幾年隨著自動化測試框架的流行, 評價一個人員測試能力的標準逐漸變成了是否能寫自動化測試. 如果照這個標準, 所有的開發人員一夜之間都具備了合格的測試能力. 這顯然是一個不成立的結論。

測試至少分測試用例的設計和測試用例的編寫執行兩部分. 自動化測試的長處僅僅在於編寫執行. 使用自動化測試框架並不會自動讓我們的測試更有效, 更完備, 更具洞察力. 而測試的有效性和完備性, 通常是我們更關注的. 然而遺憾的是, 通常組織中這方面的知識比較欠缺, 關注度不夠, 技能交流較少。

如果我們交流測試知識時, 更多的是談論 xUnit, RobotFramework等, 而不是等價類/邊界值, 惡鄰測試法/快遞測試法, 關鍵路徑分析等, 那幾乎可以肯定我們遺漏了更重要的東西。

要在時間資源人力資源有限的情況下保證產品質量, 我們需要提高測試用例的設計能力, 價值分析能力, 安排合理的測試策略。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！