我們是如何做 go 語言系統測試覆蓋率收集的？

工程效能領域，測試覆蓋率度量總是繞不開的話題，我們也不例外。在七牛雲，我們主要使用go語言構建雲服務，在考慮系統測試覆蓋率時，最早也是通過圍繞原生go test -c -cover的能力來構建。這個方案，筆者還曾在 MTSC2018大會上有過專項分享。其實我們當時已經做了很多型別的優化，能夠針對很多型別的程式碼庫，自動插樁服務，自動生成TestMain()等方法，但隨著接入專案越來越多，以及後面使用場景的不斷複雜化，我們發現這套還是有其先天侷限，會讓後面越來越難受：

• 程式必須關閉才能收集覆蓋率。如果將這套系統僅定位在收集覆蓋率資料上，這個痛點倒也能忍受。但是如果想進一步做精準測試等方向，就很受侷限。
• 因為不想汙染被測程式碼庫，我們採取了自動化的方式，在編譯階段給每個服務生成類似main_test.go檔案。但這種方式，其最難受的地方在於flag的處理，要知道go test命令本身會呼叫flag.Parse方法，所以這裡需要自動化的修改原始碼，保證被測程式的flag定義，要先於go test呼叫flag.Parse之前。但是，隨著程式自己使用flag姿勢的複雜化，我們發現越來越難有通用方案來處理這些flag，有點難受。
• 受限於go test -c命令的先天缺陷，它會給被測程式注入一些測試專屬的flag，比如-test.coverprofile, -test.timeout等等。這個是最難受的，因為它會破壞被測程式的啟動姿勢。我們知道系統測試面對是完整被測叢集，如果你需要專門維護一套測試叢集來做覆蓋率收集時，就會顯得非常浪費。好鋼就應該用在刀刃上，在七牛雲，我們倡導極客文化，追求用工程師思維解決重複問題。而作為業務效率部門，我們自己更應該走在前列。

也是因為以上的種種考量，我們內部一直在優化這一套系統，到今天這一版，我們已從架構和實現原理上完成了顛覆，能夠做到無損插樁，執行時分析覆蓋率，當屬非常優雅。

Goc - A Comprehensive Coverage Testing System for The Go Programming Language

一圖勝千言:

使用goc run .的姿勢直接執行被測程式，就能在執行時，通過goc profile命令方便的得到覆蓋率結果。是不是很神奇？是不是很優雅？

這個系統就是goc, 設計上希望完全相容go命令列工具核心命令(go buld/install/run)。使用體驗上，也希望向go命令列工具靠攏：

以下是goc 1.0版本支援的功能:

系統測試覆蓋率收集方案

有了goc，我們再來看如何收集go語言系統測試覆蓋率。整體比較簡單，大體只需要三步：

a) 首先通過goc server命令部署一個服務註冊中心，它將會作為樞紐服務跟所有的被測服務通訊。

b) 使用goc build --center="<server>" 命令編譯被測程式。goc不會破壞被測程式的啟動方式，所以你可以直接將編譯出的二進位制釋出到整合測試環境。

c）環境部署好之後，就可以做執行任意的系統測試。而在測試期間，可以在任何時間，通過goc profile --center="<server>"拿到當前被測叢集的覆蓋率結果。
是不是很優雅？

goc 核心原理及未來

goc在設計上，拋棄老的go test -c -cover模式，而是直接與go tool cover工具互動，避免因go test命令引入的一系列弊端。goc同樣沒有選擇自己做插樁，也是考慮go語言的相容性，以及效能問題，畢竟go tool cover工具，原生採用結構體來定義counter收集器，每個檔案都有單獨的結構體，效能相對比較可靠。goc旨在做go語言領域綜合性的覆蓋率工具以及精準測試系統，其還有很長的路要走:

1. 基於PR的單測/集測/系統覆蓋率增量分析
2. 精準測試方向，有一定的產品化設計體驗，方便研發與測試日常使用
3. 擁抱各種CICD系統

當前goc已經開源了，歡迎感興趣的同學，前往程式碼倉庫檢視詳情並Star支援。當然，我們更歡迎有志之士，能夠參與貢獻，和我們一起構建這個有意思的系統。

最後，父親節快樂！

關注公眾號: 大卡爾