Categories
程式開發

聊聊Go代碼覆蓋率技術與最佳實踐


“聊點乾貨”

覆蓋率技術基礎

截止到Go1.15.2以前,關於覆蓋率技術底層實現,以下知識點您應該知道:

go語言採用的是插樁源碼的形式,而不是待二進制執行時再去設置breakpoints。這就導致了當前go的測試覆蓋率收集技術,一定是侵入式的,會修改目標程序源碼。曾經有同學會問,插過樁的二進制能不能放到線上,所以建議最好不要。

到底什麼是”插樁”?這個問題很關鍵。大家可以任意找一個go文件,試試命令go tool cover -mode=count -var=CoverageVariableName xxxx.go,看看輸出的文件是什麼?

筆者以這個文件為例

https://github.com/qiniu/goc/blob/master/goc.go, 得到以下結果:

聊聊Go代碼覆蓋率技術與最佳實踐 1

可以看到,執行完之後,源碼裡多了個CoverageVariableName變量,其有三個比較關鍵的屬性:

Count uint32數組,數組中每個元素代表相應基本塊(basic block)被執行到的次數CoverageVariableName變量會在每個執行邏輯單元設置個計數器,比如CoverageVariableName.Count[0]++, 而這就是所謂插樁了。通過這個計數器能很方便的計算出這塊代碼是否被執行到,以及執行了多少次。相信大家一定見過表示go覆蓋率結果的coverprofile數據,類似下面: github.com/qiniu/goc/goc.go:21.13,23.2 1 1這裡的內容就是通過類似上面的變量CoverageVariableName得到。其基本語義為”文件:起始行.起始列,結束行.結束列該基本塊中的語句數量該基本塊被執行到的次數”Pos 代表的各個基本塊在源碼文件中的位置,三個為一組。比如這裡的21代表該基本塊的起始行數,23代表結束行數,0x2000d比較有趣,其前16位代表結束列數,後16位代表起始列數。通過行和列能唯一確定一個點,而通過起始點和結束點,就能精確表達某基本塊在源碼文件中的物理範圍NumStmt 代表相應基本塊範圍內有多少語句(statement)

依託於go語言官方強大的工具鏈,大家可以非常方便的做單測覆蓋率收集與統計。但是集測/E2E就不是那麼方便了。不過好在我們現在有了https://github.com/qiniu/goc。

集測覆蓋率收集利器- Goc原理

關於單測這塊,深入go源碼,我們會發現go test -cover命令會自動生成一個_testmain.go 文件。這個文件會Import各個插過樁的包,這樣就可以直接讀取插樁變量,從而計算測試覆蓋率。實際上goc也是類似的原理(PS: 關於為何不直接用go test -c -cover 方案,可以參考這裡: 開源啦| go語言系統測試覆蓋率收集利器goc“。

不過集測時,被測對象通常是完整產品,涉及到多個long running的後端服務。所以goc在設計上會自動化會給每個服務注入HTTP API,同時通過服務註冊中心goc server來管理所有被測服務。如此的話,就可以在運行時,通過命令goc profile實時獲取整個集群的覆蓋率結果,當真非常方便。

整體架構參見:

聊聊Go代碼覆蓋率技術與最佳實踐 2

代碼覆蓋率的最佳實踐

技術需要為企業價值服務,不然就是在耍流氓。可以看到,目前玩覆蓋率的,主要有以下幾個方向:

度量- 深度度量,各種包,文件,方法度量,都屬於該體系。其背後的價值在於反饋與發現。反饋測試水平如何,發現不足或風險並予以提高。比如常見的作為流水線准入標準,發布門禁等等。度量是基礎,但不能止步於數據。覆蓋率的終極目標,是提高測試覆蓋率,尤其是自動化場景的覆蓋率,並一以貫之。所以基於此,業界我們看到,做的比較有價值的落地形態是增量覆蓋率的度量。 goc diff 結合Prow平台也落地了類似的能力,如果您內部也使用Kubernetes,不妨嘗試一下。當然同類型的比較知名的商業化服務,也有CodeCov/Coveralls等,不過目前她們多數是局限在單測領域。精準測試方向- 這是個很大的方向,其背後的價值邏輯比較清晰,就是建立業務到代碼的雙向反饋,用於提升測試行為的精準高效。但這裡其實含有悖論,懂代碼的同學,大概率不需要無腦反饋;不能深入到代碼的同學,你給代碼級別的反饋,也效果不大。所以這裡落地姿勢很重要。目前業界沒還看到有比較好的實踐例子,大部分都是解決特定場景下的問題,有一定的局限。

而相較於落地方向,作為廣大研發同學,下面這些最佳實踐可能對您更有價值:

高代碼覆蓋率並不能保證高產品質量,但低代碼覆蓋率一定說明大部分邏輯沒有被自動化測到。後者通常會增加問題遺留到線上的風險,當引起注意。沒有普適的針對所有產品的嚴格覆蓋率標準。實際上這更應該是業務或技術負責人基於自己的領域知識,代碼模塊的重要程度,修改頻率等等因素,自行在團隊中確定標準,並推動成為團隊共識。低代碼覆蓋率並不可怕,能夠主動去分析未被覆蓋到的部分,並評估風險是否可接受,會更加有意義。實際上筆者認為,只要這一次的提交比上一次要好,都是值得鼓勵的。

谷歌有篇博客(見參考資料)提到,其經驗表明,重視代碼覆蓋率的團隊通常會更加容易培養卓越工程師文化,因為這些團隊在設計產品之初就會考慮可測性問題,以便能更輕鬆的實現測試目標。而這些措施反過來會促使工程師編寫更高質量的代碼,更注重模塊化。

最後,歡迎加入七牛雲Goc交流群,我們一起聊聊goc,聊聊研發效能那些事。

參考資料:

https://testing.googleblog.com/2020/08/code-coverage-best-practices.html

系列文章

https://xie.infoq.cn/article/0d1b06597b8345708606fc073

覺得不錯,歡迎關注公眾號: 大卡爾

點個贊、在看和轉發是最大的支持