代碼測試覆蓋率分析

kevin 發布于2019-08-20 18:55 / 2779人閱讀

摘要：背景最近我們前端團隊在重構大量的組件，為了保證代碼質量，我要求團隊中的成員必須編寫單元測試，并且測試覆蓋率達到以上。總結對一個持續集成的項目來說，單元測試非常重要，同時最好具有較高的測試覆蓋率。

背景

最近我們前端團隊在重構大量的 UI 組件，為了保證代碼質量，我要求團隊中的成員必須編寫單元測試，并且測試覆蓋率達到 80% 以上。那么問題來了，為什么是 80% 的覆蓋率？這是一個硬性的考核指標嗎？

這里所說的測試覆蓋率，是指的是開發人員寫的單元測試的覆蓋率，不是測試人員的功能測試的覆蓋率。

哪些地方需要寫單元測試？

為什么需要寫單元測試就不再闡述，我相信大家都知道，特別是在持續集成過程中的重要性。但是，從我的經歷來看，當前的軟件市場環境中，不管是用的瀑布模式，還是螺旋模式，還是敏捷模式，很多軟件沒有寫單元測試。

我也是一個程序員，每天需要寫一些的業務代碼，對于寫單元測試來說，確實需要我很多時間和精力，因為它也需要設計用例和一些體力活。所以在我們的一些項目中也存在很多功能沒有單元測試，主要原因有以下幾個點:

業務邏輯更新太快，單元測試不可復用；

業務時間緊急，迭代周期時間短，沒有時間寫單元測試；

UI 上很多測試，通過單元測試代碼無法覆蓋。

在《軟件測試》一書中講測試的原則，第一條就是：“完全測試程序是不可能的”。所以對于以上部分需不需測試，取決于你軟件性質，時間和團隊。但是對于滿足以下幾點代碼我建議需要編寫單元測試：

和安全相關的代碼邏輯；

核心的功能模塊，函數；

短期不會發生變化的 UI 組件；

提供外部調用的接口。

測試覆蓋率報告

如果完全通過測試覆蓋作為質量標準是存在問題的，我們在檢查一個測試覆蓋了的時候往往會通過一些工具去檢查，程序員是可以通過一些方式讓數字看上去漂亮，但是這沒有意義。我們應該把它作為一種發現未被測試覆蓋的代碼的手段，同時也是一種學習的手段，為什么這段代碼沒有覆蓋到？如果這個函數的參數發生了變化會怎么樣？這段代碼邏輯怎么這么復雜？

通過分析未被測試覆蓋的代碼，找到是設計問題，還功能理解有問題，還是說著就是一段廢代碼，它可以幫助開發者能夠更好的理解背后的事情，可以檢查程序中的廢代碼，然后在以后的設計中做很好的抽象，做可測試的代碼。

各種開發語言都有對應的測試框架，可以生成測試報告，在本文中我以前端的 javascript 為示例， karma + istanbul 工具生成報告。

karma 是一個測試框架；

istanbul 是 JavaScript 程序的代碼覆蓋率工具。

怎么生成測試報告這里就不講，有很多教程，也可以查看官方文檔 istanbul。這里我們先來看一下生成出來的測試報告。以下是 rsuite src/utils 目錄下文件的測試報告, 這是打開的一個生成 html 格式的測試報告：

{% asset_img 1.png RSUITE 測試覆蓋率 %}

從圖中我們可以看到它有四個指標：

Statements: 語句覆蓋率，執行到每個語句；

Branches: 分支覆蓋率，執行到每個if代碼塊；

Functions: 函數覆蓋率，調用到程式中的每一個函數；

Lines: 行覆蓋率, 執行到程序中的每一行。

每一個指標都列出了覆蓋的比例和數量情況，其中 Statements 與 Lines 比例和數量是一致的，那它們有什么不同呢？
在代碼中往往存在一些書寫不規范的情況，比如一行多個語句，這個時候它們統計的覆蓋率就會有差異。這里又有一個值得思考的問題就是，代碼覆蓋率工具是怎么統計一行多個語句這種代碼的？后面講到統計原理的時候會講到。

另外，我們通過圖中可以看出 decorate.js 這個文件相對來說測試覆蓋率較低，我們進入再具體分析一下，在那些地方沒有覆蓋到：

{% asset_img 2.png decorate.js 測試覆蓋率 %}

從圖中我們可以看到紅色部分和黃色, 都是在測試用例中沒有覆蓋到的地方:

getProps 函數，該函數式 export 出去的一個函數，但是在測試用例中沒有覆蓋到；

typeof size === "object" 代碼塊沒有覆蓋到；

Component.propTypes={}.. 這里黃色部分，是一個默認值設置，說明這個默認值一直沒有被使用過；

在圖中左側，顯示行號的地方有一個 12x、9x、4x，這個代表了該行語句被執行的次數，通過這個清晰的報告，我們可以在代碼中看出那些函數，那些代碼塊沒有被執行，從而去分析原因，修正測試用例，完善代碼邏輯，提高質量。

生成測試報表原理

我先來看一下 istanbul 生成的測試報告中有個 lcov.info 文件, 這里我只貼出關于 decorate.js 文件這部分的內容:

SF:/Users/simonguo/workspace/rsuite/src/utils/decorate.js
FN:25,getClassNames
FN:39,getProps
FN:41,(anonymous_2)
FN:50,decorate
FN:51,(anonymous_4)
FNF:5
FNH:3
FNDA:237,getClassNames
FNDA:0,getProps
FNDA:0,(anonymous_2)
FNDA:12,decorate
FNDA:12,(anonymous_4)
DA:4,1
DA:11,1
DA:18,1
DA:27,237
DA:28,237
DA:30,237
DA:32,237
DA:40,0
DA:41,0
DA:42,0
DA:44,0
DA:51,12
DA:52,12
DA:53,12
DA:54,12
DA:56,12
...

FN 代表函數，
25,39,41,50,51 這些行分布對應源代碼中的函數開始的行號，
FNF:5 代表一共有5個函數
FNH:3 其實 3 個函數被測試所覆蓋，
FNDA:237,getClassNames 代表了 getClassNames 這個函數被執行了 237 次。
...

等等，在文件中詳細記載了行號，以及代碼的執行情況，大家可以再對照前面的那張“測試覆蓋率”圖片進行分析，可以詳細的看出整個 lcov.info 文件中記錄內容。有了這樣一份記錄信息就能夠生成出一份可視化的測試報告，也可以上傳到 coveralls，展示給大家。那么這里需要思考的問題是，這樣一份數據統計記錄是怎么統計出來的呢？

如果希望有些代碼被忽略，不進入覆蓋統計，istanbul 提供注釋語法，查看Ignoring code for coverage purposes

javascript 覆蓋率統計的核心思想，是在源代碼相應的位置注入設定的統計代碼，當執行測試代碼的時候，代碼運行到注入的地方，就會執行對應的統計代碼，生成覆蓋率統計報告。大概步驟如下：

第一步：生成語法樹，對源代碼進行語法分析，解析，然后生成語法樹。

生成出來的結構如下，這段代碼來自 esprima， A simple example on Node.js REPL:

> var esprima = require("esprima");
> var program = "const answer = 42";

> esprima.tokenize(program);
[ { type: "Keyword", value: "const" },
  { type: "Identifier", value: "answer" },
  { type: "Punctuator", value: "=" },
  { type: "Numeric", value: "42" } ]

> esprima.parse(program);
{ type: "Program",
  body:
   [ { type: "VariableDeclaration",
       declarations: [Object],
       kind: "const" } ],
  sourceType: "script" }

第二步：注入統計代碼，在語法樹相應的位置注入統計代碼，在程序執行到這個位置的時候對相應的全局變量賦值，確保執行之后能夠根據全局變量知道代碼的執行流程。到這里就解決了前面說的“一行如果有多個語句怎么統計？”的問題。

第三步：再把注入統計代碼的語法樹，生成對應的 javascript 代碼。

以下是 escodegen 的一段示例代碼

// A simple example: the program

escodegen.generate({
    type: "BinaryExpression",
    operator: "+",
    left: { type: "Literal", value: 40 },
    right: { type: "Literal", value: 2 }
});

// produces the string "40 + 2".

第四步：將生成好的 javascript 代碼交給執行環境（nodejs或者瀏覽器）運行。

第五步：執行單元測試，產生的統計信息，放到全局標量中。

第六步：根據全局標量中的覆蓋率信息生成特定格式的報告，這樣我們就看到了 lcov.info 文件和 .html 文件。

這個步驟是依據 istanbul 統計 javasript 的原理，其他語言的一些統計工具沒有接觸過，但是基本的思想應該都是大同小異的。在 javasript 對語法分析，生產語法樹再還原 javasript 代碼是有一些開源工具的，所以如果有興趣的童鞋要自己實現一套代碼覆蓋率的功能，只需要寫好注入的統計代碼邏輯和運行環境的處理。

總結

對一個持續集成的項目來說，單元測試非常重要，同時最好具有較高的測試覆蓋率。再次強調測試覆蓋率是一種發現未被測試覆蓋的代碼的手段，它不是一個考核質量的目標。

另外，我們維護的開源項目 rsuite ,是一套 React 的 UI 組件庫，如果你對此感興趣，或者使用中遇到任何問題，可以聯系我們 Discord: join chat

本文作者：郭小銘

云服務器 GPU云服務器單元測試覆蓋率 webrtc測試代碼在線測試代碼測試async代碼

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/84880.html

測試基本面試知識

測試基本知識1、請你分別介紹一下單元測試、集成測試、系統測試、驗收測試、回歸測試：（1）單元測試：完成最小的軟件設計單元（模塊）的驗證工作，目標是確保模塊被正確的編碼，使用過程設計描述作為指南，對重要的控制路徑進行測試以發現模塊內的錯誤，通常情況下是白盒的，對代碼風格和規則、程序設計和結構、業務邏輯等進行靜態測試，及早的發現和解決不易顯現的錯誤。（2）集成測試：通過測試發現與模塊接口有關的問題。目...

不知名網友 2021-11-26 11:10 評論0 收藏0
軟件測試考前復習

摘要：在軟件開發過程中，開發小組的人員應該少而精對測試人員在軟件開發過程中的任務主要是尋找并修正該錯尋找避免軟件開發過程中的缺陷，衡量軟件的品質，關注用戶的需求軟件工程這個名詞是在年北大西洋公約組織的計算機科學家在美國召開的國際會在軟件開發過程中，開發小組的人員應該少而精（對）測試人員在軟...

layman 2021-10-12 10:11 評論0 收藏0
使用Gradle做Java代碼質量檢查

摘要：使用做代碼質量檢查是一個開源的代碼質量管理系統，支持超過種編程語言，提供重復代碼編碼標準單元測試單元測試覆蓋率，代碼復雜度，潛在注釋和軟件設計的報告等。 Maven --> Gradle 首先安裝gradle:Mac安裝 brew install gradle Ubuntu安裝 apt install gradle Maven項目切換Gradle項目,再Maven根目錄下運行: gr...

wushuiyong 2019-08-16 15:51 評論0 收藏0
開發者測試-采用精準測試工具對Spring Boot應用進行測試

摘要：，整合剛才已經下載好了，現在我們添加文件標簽加一行如下然后是和在文件中添加數據源配置連接本地，新建數據庫，查詢執行項目頁面列出來的語句自動建立該項目需要的數據庫內容。簡介：本文主要介紹把現今主流的springboot框架項目和精準測試工具進行結合和應用，通過精準測試的數據穿透、數據采集、測試用例與代碼的雙向追溯、數據分析等一系列精準測試的特有功能，達到對項目質量的保證。　本次環境搭...

galois 2019-08-16 13:56 評論0 收藏0
Python代碼覆蓋率分析工具Coverage

摘要：簡介是一種用于統計代碼覆蓋率的工具，通過它我們可以檢測測試代碼的有效性，即測試對被測代碼的覆蓋率如何。支持分支覆蓋率統計，可以生成報告。 Coverage簡介 Coverage是一種用于統計Python代碼覆蓋率的工具，通過它我們可以檢測測試代碼的有效性，即測試case對被測代碼的覆蓋率如何。Coverage支持分支覆蓋率統計，可以生成HTML/XML報告。XML報告可以集成入Jenk...

zombieda 2019-07-24 18:09 評論0 收藏0