雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
背景
結合代碼設計測試用例能夠有效提高測試精準度，為此我們研發了一種可以實時收集代碼覆寫率的工具 Timon。Timon 與公司容器化建構系統 ZAE 打通；支援 Java、 Python 和 Golang 三種語言的覆寫率統計；能夠産出全量和增量代碼覆寫率報告；支援合并覆寫率資料；可以在接口測試和內建測試等場景使用。Timon 工具支援 90% 以上自動化接口用例的覆寫率統計；使用 Timon 輔助功能測試的 QA，增量代碼覆寫率平均達到 80% 以上。在以下的内容中，文章将介紹工具的原理和使用實踐。
測試覆寫率工具選擇
我們選擇的測試覆寫率工具包括 Jacoco、Coverage.py 和 go test 指令。 各工具的詳細介紹可以在官網中檢視，文章不再贅述。表 2.1 對比了三種工具。 其中 Jacoco 使用 On-the-fly 的模式插樁已滿足使用需求。 Coverage.py 和 go test 需要殺掉應用程序才能擷取報告。 go test 需要在編譯階段進行插樁。
原理和子產品設計
在編譯階段， 我們對代碼進行插樁。部署階段，Timon 用戶端被部署到容器當中。 開啟應用時，ZAE 将自動修改應用啟動指令，以啟動 Timon 用戶端。Timon 工具包括兩個大的子產品： 用戶端和服務端。 用戶端又有三個子子產品，分别對應三種語言。主要職責是上傳容器資訊、監聽端口、請求配置檔案、生成覆寫率原始資料檔案、 上傳代碼 diff 資訊等。服務端的主要功能包括增量代碼覆寫率計算、生成配置檔案、曆史資料管理、報告展示界面等。詳細的子產品清單可以檢視系統子產品圖 （ 圖 3.1 ）。 下面将介紹工具重點功能的實作方法。
1、編譯階段插樁
Golang 應用需要在編譯階段進行代碼插樁才可以統計覆寫率資料。開發在 CI 配置檔案中加入如下配置後，ZAE 平台自動完成插樁過程。配置檔案包含的資訊包括項目源碼、目标檔案以及各服務入口的路徑。ZAE 在檢測到插樁配置後，首先将 Timon 用戶端提供的 test 檔案放到服務入口所在的目錄中，然後在生成的 Jenkinsfile 中插入編譯指令。Python 和 Java 語言的項目不需要在編譯階段插樁。
2、部署階段初始化
Timon 用戶端在啟動的時候，會進行上傳容器資訊、監聽端口、請求配置檔案等操作。圖 3.2 展示了用戶端的初始化過程。
Timon 用戶端啟動之後的主要任務是監聽覆寫率報告請求、容器銷毀資訊并上傳覆寫率報告。因為代碼更新後，測試聯調環境會自動部署新版本的代碼并銷毀目前容器，是以 Timon 用戶端需要在容器銷毀前上傳覆寫率資料。Java 語言覆寫率檢測工具采用的方案是每 10 分鐘上傳一次覆寫率資料。但是 Go 和 Python 語言的覆寫率檢測工具需要重新開機應用才能上傳，為了不讓服務程序頻繁重新開機，我們采用了另一種方案：Timon 用戶端監聽系統發給容器的銷毀信号，收到信号後用戶端上傳覆寫率資料。除此之外使用者請求生成覆寫率報告時，Timon 用戶端也會實時上傳覆寫率報告。
3、上傳覆寫率資料
一個使用者從請求目前部署版本覆寫率報告到獲得報告的時序圖見圖 3.3。 假設某個測試環境當中隻有一個應用，這個應用有三個容器提供服務，Timon 伺服器等待容器一和二上傳原始資料後，向容器三發送原始資料集合，最後容器三合并資料後，生成 html 格式的全量代碼覆寫率報告。如果測試環境有多個應用，那麼時序圖當中的過程是并行進行的。在容器銷毀前，儲存覆寫率原始資料的方案也是類似的。
4、計算覆寫率資料
統計覆寫率的方式有分支覆寫率和可執行代碼覆寫率等。在實踐中通常通過可執行代碼來計算覆寫率，Timon 也是如此。增量代碼覆寫率的計算需要代碼與主分支的 diff 資料和全量代碼覆寫率報告。分子是增量代碼且已經覆寫的執行代碼行數，其中會去除測試檔案等非業務代碼檔案。分母是增量代碼部分執行代碼的行數。為了能夠幫助使用者及時找到增量代碼，我們對第三方工具生成的報告做了一些修改。比如 Java 的增量代碼覆寫率報告中隻顯示有增量代碼的檔案，在浏覽器直接搜尋 「新增代碼」 即可跳轉到增量代碼位置。Golang 和 Python 語言的覆寫率報告也有類似的功能。
如果是計算 MR 整體的增量代碼覆寫率，那麼還需要合并多個 Commit 的覆寫率資料。假設有 Commit A、Commit B、Commit C 三個版本的覆寫率報告，Commit C 是最後一次送出，Commit C 有增量代碼的檔案是 c。下面介紹一下合并過程。
- 找到 Commit A 檔案 c 中被執行的代碼内容
- 在 Commit C 中尋找相同的代碼内容
-
在 Commit C 的覆寫率報告中标注該行被執行
重複以上三個過程，其他 Commit 代碼與 Commit C 的代碼比對
合并後生成的覆寫率報告能夠輔助 QA 分析，未覆寫的部分是因為測試用例遺漏，還是測試環境無法覆寫，又或者備援代碼等其他問題。
使用者使用流程
我們做到了零成本接入，使用者在測試聯調環境加入應用時，打開 「啟動覆寫率檢測環境」按鈕即可。使用者可以在工具的前端界面檢視報告，也可以在 MR 中添加評論擷取覆寫率資料報表。使用者使用流程圖（ 圖 2.1 ) 展示了使用覆寫率報告分析測試用例的流程 。如果使用自動化腳本進行測試，單版本的的代碼覆寫率報告可以幫助分析。如果是手工測試，由于代碼持續更新，MR 整體的增量代碼覆寫率報告能夠幫助查找遺漏的測試用例。
業務實踐
在 Timon 工具出現之前，黑盒測試無從保證覆寫所有邏輯和異常情況；跟進自動化測試腳本的開發進度，一般是比較用例完成百分比；自動化測試用例的品質評估也大多靠測試經驗。Timon 幫助測試人員快速找到遺漏測試場景，提高了工作效率，且推動測試人員更加關注代碼本身。Timon 也為評估自動化測試用例提供了新的方法。除此以外，我們在實踐過程中發現覆寫率工具也能夠幫助測試人員發現其他問題，比如開發送出了非需求相關的代碼，手工測試環境當中無法制造某些異常情況等。Timon 工具是知乎品質保障體系的一個子產品，為精準測試舔磚加瓦。 QA 因為使用 Timon 工具改變了測試習慣。我們将持續尋找 Timon 覆寫率工具在産研體系中的最佳實踐，同時與其他品質保障平台關聯，發揮它的最大價值。
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/zhibo立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-03-27
本文作者：小果果
本文來自：“
InfoQ”，了解相關資訊可以關注“
”