如何減輕軟體開發的回測壓力？Facebook 已經用上了機器學習

雷鋒網 AI 科技評論按

：

如何減輕軟體開發的回測壓力，從而提高工程師的生產效率？MATEUSZ MACHALICA、ALEX SAMYLKIN 等人組成的 Facebook 研究團隊提出使用一個利用機器學習的新系統來建立一個為特定程式碼更改選擇迴歸測試的機率模型，從而更好地執行這種迴歸測試。

為了高效地開發新產品特徵和更新，Facebook 研究團隊使用基於主幹的開發模型來管理對程式碼庫的改動。一旦一位工程師的程式碼更改被接入主分支（主幹），他們試圖讓它對從事該產品或服務的其他工程師快速可見。這種基於主幹的開發模型比使用特徵分支和特徵融合更加有效，因為它使得每個人都能夠在程式碼庫的最新版本上工作。

但是，在被接受到主幹之前，對每項提出的更改進行徹底的迴歸測試很重要（注：迴歸測試是指修改了舊程式碼後， 重新進行測試以確認修改沒有引入新的錯誤或導致其他程式碼產生錯誤的一種測試方法）。在從主幹被部署到生產之前，每項程式碼更改都需要經過徹底的迴歸測試，進入主幹異常程式碼會使得評估新提出的程式碼更改變得更困難得多，並且還會影響工程師的生產效率。

對此，該研究團隊開發了一種更好的方法來執行這項迴歸測試：

使用一個利用機器學習的新系統來建立一個為特定程式碼更改選擇迴歸測試的機率模型。

這種方法需要僅僅執行一個小的測試集，以確保檢測到錯誤的更改。與典型的迴歸測試選擇（RTS）工具不同，

該系統透過從歷史程式碼更改和測試結果的大型資料集中學習，來自動開發測試選擇策略。

這個預測性測試選擇系統已在 Facebook 上部署了一年多，在一段新的程式碼加入到主幹、被其它工程師看到之前，這個系統就可以捕捉超過 99。9% 的迴歸異常，而且它執行的基於修改的程式碼的測試數量也只需要以往的三分之一那麼多。這也讓 Facebook 的基礎測試設施的效率得到翻倍的提升。

隨著程式碼庫的不斷髮展，該系統也幾乎不要求手動除錯。而且經證明，

它還能夠捕捉產生不一致和不確定性結果的片狀測試。

為什麼使用建立依賴項是低效的

迴歸測試的一種常用方法，就是使用從構建元資料中提取的資訊來確定在特定程式碼更改上執行哪些測試。透過分析程式碼單元間的建立依賴項，可以確定傳遞依賴於在程式碼更改中被修正的源的所有測試。例如，在下圖中，圓圈表示測試；正方形表示程式碼的中間單元，如庫；菱形表示儲存庫中的單個原始檔。箭頭連線起實體 A →B，當且僅當 B 直接依賴於 A 時，他們將其解釋為 A 影響 B。藍色的菱形表示在示例程式碼更改中被修正的兩個檔案，所有傳遞依賴於它們的實體也用藍色表示。在這個場景中，基於建立依賴項的測試選擇策略將執行測試 1，2，3 和 4，但不執行測試 5 和 6，因為後兩項測試不依賴於修正的檔案。

這種方法有一個明顯的缺點：它以說「是的，本測試受到影響」告終的次數比實際所需要的要多。平均而言，對於移動程式碼庫的每項更改，該方法都會導致執行多達四分之一的可用測試。如果傳遞依賴於修正檔案的所有測試都真正受到影響，他們將別無選擇，而只能將每項測試都執行一遍。然而，

在他們的單片程式碼庫中，終端產品依賴於許多可重複使用的元件，這些元件使用一小組低階庫

。在實踐中，許多傳遞性依賴實際上與迴歸測試無關。例如，當某個低階庫發生更改時，在使用該庫的每個專案上重新執行所有測試將是低效的。

軟體開發研究領域也開發了其他的迴歸測試選擇方法，例如基於靜態更改-影響分析的方法。然而，由於他們程式碼庫的大小和使用的不同程式語言的數量，這些技術在他們的使用案例中是不現實的。

一種新方法：預測性測試選擇

基於建立依賴項的選擇測試涉及到判斷哪些測試可能受到更改的影響的問題。為了開發更好的方法，Facebook 的研究團隊考慮了一個不一樣的問題：指定的一項測試發現某個程式碼修改中的迴歸問題的可能性有多大？如果他們能估計到這個可能性，就可以做出明智的決定，來排除那些極不可能發現迴歸的測試。這是對傳統測試選擇的重大背離，並且開闢了一種新的、更有效的選擇測試方法。

作為第一步，

該研究團隊建立了一個預測模型

，該模型針對新提出的程式碼更改估計每項測試失敗的機率。

他們透過使用包括歷史程式碼更改上的測試結果在內的大型資料集，然後採用標準的機器學習技術來建立模型，而非手動定義模型。

每個新的程式碼更改總會與之前的情況略有不同，因此模型不能簡單地將新的更改與歷史更改進行比較，來確定哪些測試值得執行。然而，新更改的抽象可以類似於前一個或多個程式碼更改的對應的抽象。

在訓練期間，研究團隊的系統學習基於源自先前程式碼更改和測試的特徵的模型

。然後，當該系統正在分析新的程式碼更改時，他們將學習到的模型應用於基於特徵的程式碼更改的抽象。對於任何特定的測試，該模型接著能夠預測檢測到迴歸的可能性。

為此，該系統使用了標準機器學習演算法的變體——梯度提升決策樹模型。研究團隊雖然可以使用其他機器學習演算法，但其之所以選擇這種方法，有幾個原因：

決策樹是可解釋的、易於訓練的，並且已經是 Facebook 機器學習演算法基礎結構的一部分。

他們可以使用這個模型分析特定的程式碼更改，來找到所有傳遞依賴於修改檔案的可能受影響的測試，然後估計測試檢測到由更改引入的迴歸的機率。基於這些估計，系統選擇對於特定更改最有可能失敗的測試。下圖顯示了將選擇哪些測試（用藍色表示），來更改影響前一示例中的兩個檔案，而在前一示例中，用 0 到 1 之間的數字來表示每個被考慮在內的測試的機率。

評估和校準模型

對於每項程式碼更改，系統選擇的測試數量影響它在檢測迴歸時的可靠性。使用最近程式碼更改的選擇作為驗證集，研究團隊可以評估其在新更改上的準確性。下面的圖表顯示了每次更改所選擇的最大測試數量與這一選擇的準確性之間的關係。在生產中，他們要求其模型能夠正確預測超過 95% 的測試結果，並且能為超過 99。9% 的有問題的更改捕獲至少一個失敗的測試。他們發現，

這種準確度的高標準所帶來的測試訊號的損失可以忽略不計，並且消除了大量不必要的測試執行。

由於程式碼庫結構的不斷演變，測試選擇策略必須適應繼續滿足這些嚴格的正確性要求。然而，他們的系統讓其變得簡單，因為他們可以使用最近提交的程式碼更改的測試結果來定期地重新訓練模型。

處理測試片狀

為了確保他們的測試選擇很好地適用於現實世界的測試，系統需要處理測試片狀問題：當被測試的程式碼沒有真正被更改時，測試結果從透過變為失敗。正如他們在論文中所做的更詳細的解釋，如果他們訓練一個模型而不去識別片狀測試失敗，該模型可能無法學習去一致地預測測試結果。在下面的示例中，兩個測試選擇策略捕獲所有失敗的測試執行的共同部分。如果系統不能區分哪些測試失敗是片狀的以及哪些不是，那麼它將無法知道哪個策略是最好的。策略 A 具有明顯更好的準確性，

因為它捕獲了所有無法發現實際迴歸的測試

。然而，策略 B 選擇了大量由於片狀性而非程式碼的實際問題而失敗的測試。

為了減輕片狀性對所學到的測試選擇模型的影響，研究團隊在收集訓練資料時積極地重新嘗試失敗的測試。這種方法讓他們將連續失敗的測試（指示真實迴歸）與那些呈現片狀、非重現性失敗的測試區分開來。

檢測和固定迴歸：30000 英尺的視角

這個系統是研究團隊建立智慧工具以使程式碼開發過程更加可靠和高效的更廣泛努力的一部分。他們的基於搜尋的自動化軟體測試系統 Sapienz 和自動化缺陷修復工具 Getafix，也可以幫助他們自動檢測和修復迴歸——也就是說，這些工作僅要求工程師們投入很少的注意力甚至不投入注意力。

預測性測試選擇（這篇部落格文章中描述的系統）透過選擇由工程師定義的正確的測試集，來高效地檢測迴歸。Sapienz 生成新的測試序列，來發掘讓移動應用程式崩潰的條件，Getafix 則為他們使用測試和驗證工具所發現的問題推薦補丁，然後由編寫更改的工程師檢驗並選擇接受或拒絕這些補丁。總而言之，這些系統讓工程師能夠為使用 Facebook 產品的數十億人，更快、更有效地建立和部署新特徵。

未來規劃

預測性測試選擇是 Facebook 的數個專案中的一個，它旨在應用統計學方法和機器學習來提高迴歸測試的有效性。隨著研究團隊進一步提高系統的效率和準確性，他們也將應用相關的方法來識別測試範圍中的潛在差距。

機器學習正在變革生活的方方面面。他們相信軟體工程在這方面也一樣。

via：Predictive test selection： A more efficient way to ensure reliability of code changes，https：//code。fb。com/developer-tools/predictive-test-selection/ 雷鋒網 AI 科技評論編譯。雷鋒網