覆蓋率測試工具的分層

許多軟件都有分層。C/C++代碼的覆蓋率工具亦如此。

最底層是GCC支持的編譯和收集兩個底層:

  • 編譯選項:-g -fprofile-arcs -ftest-coverage
  • 收集工具:gcov, gcov-tool

往上一層是覆蓋率報告生成工具,有幾種:

  • lcov, Linux 的覆蓋率報告就是用這個生成的,有1.x版本和2.0版本。這個都是用perl 寫的,但是它 2.0版本只有預編譯了centos的rpm包,沒有ubuntu的dep包,安裝非常慢。而且,這個工具只輸出html 格式,不利於結構化處理。
  • gcovr,使用Python寫的,內部也是對 gcov 處理結果的二次處理。這個工具可以輸出 html、cvs、json等豐富的格式。Python項目也更有利於按需修改。缺點是官方對於bug的修復不是很積極。

用戶層,如果用戶要做覆蓋率統計,多半是需要基於 lcov/gcor > gcov 做進一步的封裝,得到一個自己的 xxx_cov 工具或者系統。分層結構是: xxx_cov > gcovr/lcov > gcov/gcov-tool

這就是工具的分層。和 CMake > Makefile/Ninja > gcc/clang/msvc 的編譯工具鏈分層一個道理,構建系統,用戶這層也會有自己的套裝和系統,xxx_build_sytem > conan > cmake > makefile, ninja > gcc/clang/msvc

進一步,用戶的研發系統裏面會有下游的流水線,例如自動化編譯、測試、報表平臺,這些平臺:

  1. 帶有服務化的能力
  2. 背後有數據庫來存儲各環節元數據
  3. 有可視化平臺顯示編譯、測試、查詢視圖
  4. 進一步應該有一系列的 Web API 方便編程的方式來集成。

把這樣的服務化系統看作是 Build & Test Server。那麼整體的分層結構是: build+test-server > continue integration, continue test suite, build system manager view, build system api > xxx_build_system + xxx_cov > ...

這裏面有一個問題是:

  • 越底層的工具鏈,一般是直接的命令行或者腳本系統,屬於可編程部分。
  • 越上層的管理系統,一般是可視化的UI系統,如果沒有強制在設計中貫徹「功能都應該有開放API」,那麼上層可視化UI系統的可編程能力弱,到上層做自動化工作反而變的困難,需要涉及很多與不同小組的人之間的「走流程」的部分。反之,如果設計上貫徹「重要功能都有可編程API」,那麼整個系統的自動化編程能力就會有很大不同,單個人就能完成某個自動化功能從底層到上層的全鏈路開發。

--end--

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章