谷歌如何實現10億行代碼的測試覆蓋率？

谷歌研究人員進行了一項分析，這項分析揭示了該公司的工程師如何管理 10 億行代碼的代碼測試覆蓋率。

該圖片來自于谷歌，其中彩色標識的行號（用紅色矩形框突出顯示）用來可視化地查看代碼覆蓋情況。 行號如果被測試覆蓋，則為綠色； 如果沒有被覆蓋，則為橙色； 如果沒有檢測該行，則為白色。

在軟件開發中，一個稱為代碼覆蓋率的常用度量標準，用于度量部署代碼之前，所執行的測試覆蓋到的系統代碼的百分比。代碼覆蓋率通常由單獨的軟件程序自動測量，或者可以從命令行手動啟動某些代碼覆蓋率工具。測試結果準確地顯示了在運行測試套件時執行了哪些代碼行，并且可以揭示哪些代碼行可能需要進一步的測試。

理想情況下，軟件開發團隊的目標是 100% 的代碼覆蓋率。但在現實中，這種情況很少發生，因為有些代碼塊會走到很多不同的執行路徑，也因為各種邊緣情況，基于系統的需求，應該（或不應該）考慮這些邊緣情況。

近年來，越來越多的谷歌項目已經很積極地引入了自動化代碼覆蓋率測試工具

度量代碼覆蓋率已經成為軟件開發和測試團隊的常見實踐，但是這種實踐是否真的提高了代碼質量，這個問題仍然存在爭議。

一些人認為，開發人員可能把焦點放在了數量上，而非質量上，創建測試只是為了滿足代碼覆蓋率，而不是足夠健壯地識別高風險或關鍵的代碼區域。其他人則對它的成本效益提出了擔憂——它需要寶貴的開發人員時間來評審結果，而且不一定能提高測試質量。

對于像谷歌這樣的大型組織（擁有 10 億行代碼，每天接收數萬次提交并支持七種編程語言）來說，度量代碼覆蓋率尤其困難。

谷歌的 AI 研究人員 Marko Ivankovi? and Goran Petrovi?最近的一項研究，提供了這家科技巨頭代碼覆蓋率基礎設施的幕后情況，它由四個核心層組成。底層組合了針對每種編程語言設計的代碼覆蓋率庫，中間層將代碼覆蓋自動化流程集成到了公司的開發和構建工作流中。頂層使用代碼編輯器和其他的定制工具，將代碼覆蓋信息可視化顯示出來。

作為這項研究的一部分,Ivankovi?和 Petrovi?分析代碼覆蓋率在 5 年期間的采用率。他們發現，盡管谷歌沒有強制規定代碼覆蓋率，但自 2014 年以來，采用率卻一直在穩步增長。2018 年第一季度，超過 90% 的項目使用了自動的代碼覆蓋工具。

研究人員還從 3000 名隨機選擇的谷歌開發人員和其他非工程人員中，收集了 512 份關于代碼覆蓋率有用性的調查問卷。在受訪者中，只有 45% 的人在代碼修改時頻繁使用代碼覆蓋率測試，而 40% 的人在進行代碼評審時定期地使用代碼覆蓋率。

圖表示例：來自谷歌谷歌的調查參與者在代碼修改（紅色）、檢查代碼更改（藍色）和瀏覽代碼更改（綠色）時，對代碼覆蓋率的有用性進行了評分。

Ivankovi?向 IEEE Spectrum 談到了他們的這項研究，和代碼覆蓋在軟件開發和測試中的作用。（為了清晰起見，以下采訪記錄經過了編輯和濃縮。）

IEEE Spectrum：為什么你認為代碼覆蓋率很重要?

Marko Ivankovi?：很多人可能期望我們說，“好的覆蓋率減少 bugs 的數量。“這當然是其中的一個原因，但（我們發現的）更令人驚訝的是，即使覆蓋率不能直接作為一種質量信號，它仍然值得計算。”

覆蓋率可能對查看代碼的人沒有直接的幫助，但是對工具仍然有幫助——例如，分析依賴關系的工具。例如，如果代碼 A 聲明它依賴于代碼 B，但是對代碼 A 的測試永遠無法觸及代碼 B，那么這種依賴可能不是真實的，自動化工具可以嘗試刪除它來簡化代碼庫。

當然，實際實現要復雜得多。我們已經發現了許多這樣的工具，它們可以使用我們的基礎設施提供的覆蓋率信息，來改進它們自己的功能。對于許多這些用例，代碼覆蓋率和代碼質量之間的相關性根本不重要。

IEEE Spectrum：是什么激發了你研究谷歌的代碼覆蓋率?

Ivankovi?：因為我們面臨著一個問題。在代碼評審期間，我們花費了大量的時間試圖弄清楚，測試是否真的測試到了這些評審的代碼。那時，代碼構建系統支持覆蓋率計算，但是您必須手動激活它，并手動將覆蓋率結果和您正在審閱的代碼疊加來查看。有一天，我們對自己說，“必須找到一種自動化的方法。“一個星期后，我們有了第一個可運行的原型。其他工程師看到后，問是否他們也能擁有這樣的原型。我們想確保我們為他們提供了最好的體驗，所以我們開始研究這個問題。

IEEE Spectrum：你的調研結果里，你最驚訝的是什么?

Ivankovi?：我們感到驚訝的是，最初懷疑代碼覆蓋率方法，但卻最終發現它很有用的人數非常多。我們調查的一些人基本上是反對覆蓋率的，但他們仍然承認他們有時使用覆蓋率方法，并且發現它很有用。

IEEE Spectrum：你在調研中面臨的最大挑戰是什么？你是如何克服的？

Ivankovi?：從表面上看，代碼覆蓋率似乎是一個簡單的概念：即一行代碼是否被測試覆蓋。但事實證明，當大規模實施時，它充滿了各種邊角情況和意外情況。我們花了幾年的時間，來修復測試的基礎設施中的所有失敗情況。

我們在進行研究時遇到了類似的挑戰。我們調查的大多數工程師對覆蓋率的總體概念是一樣的，但當被問及細節時，他們的回答卻大相徑庭。我們必須對一小部分人群進行幾次調查，才能得到正確答案。

IEEE Spectrum：您認為谷歌的代碼覆蓋基礎設施有哪些優勢？你認為還有什么可以改進的？

Ivankovi?：我們努力確?；A設施資源是有效利用的，并且可以運行在谷歌如此大的代碼規模上。向人們展示這是可能的，這可能是（我們的研究）最大的貢獻。

我們設計我們的基礎設施，以更容易地進行實驗、做 A /B 測試和評估假設。我們還以可訪問的格式導出所有數據，這樣覆蓋率信息就可以可視化，這有助于團隊保持健康的代碼，并準備好修復事件。

當我們在調查工程師的時候，他們中的一些人給了我們改進的建議，其中一些建議值得我們去探索。其中一個比較有趣的方法是，如果代碼覆蓋率測試結果太好，就不要顯示它們，這樣工程師就不會過于自信。

IEEE Spectrum：對于希望部署代碼覆蓋率，或改進現有代碼覆蓋率的軟件開發和測試團隊，您有什么建議?

Ivankovi?：我認為可以給到的最重要的建議，是專注于他們的工作流程。不要只是部署覆蓋率測試，還要確保您將其集成到開發人員工作流的正確位置，只有在這個位置上，覆蓋率結果才是最有用的。在我們的經驗中，代碼評審是代碼健康的基石。

IEEE Spectrum：對于谷歌的代碼覆蓋基礎設施，未來將會有什么發展?

Ivankovi?：目前，我們在更進一步地研究數據使用和開發人員的意見，以便更好地理解如何使用覆蓋率。例如，我們正在研究，人們理解到的有用性與實際的有用性之間的差異。我們想要研究的一個具體問題是，“在代碼評審期間，顯示覆蓋率實際上會加快評審過程嗎?”這項研究的結果，將決定我們下一步的基礎設施如何改進。

原文轉自：https://spectrum.ieee.org/tech-talk/computing/software/qa-how-google-implements-code-coverage-at-massive-scale