動態回歸VS精準回歸

動態回歸 vs. 精準回歸

關於GTAC

Google Test Automation Conference (GTAC) 是谷歌舉辦的每年測試領域盛會，從2006年以來已經舉辦了10屆。每屆都會邀請各個行業測試領域的牛人來做分享，也會有很多亮眼的測試框架平台在這裡走向了全世界(包括走進阿里)。

本期主題

本期是來自著名遊戲引擎公司Unity的QA leader分享，他主要講了在動態決定回歸範圍上面的嘗試。做法有些大膽和激進，當然他們也是剛開始，所以減少用例數的標準可能有些拍腦袋， 但是思路還是可以去嘗試的，尤其是精確的根據開發修改的代碼動態決定回歸範圍。 這個其實業界還是有不少類似的實踐，本人之前的公司也有參與開發和使用過類似的工具，但是在集團好像還沒有好的實踐。

主要內容

一句話

其實分享的核心就是這頁，綜合成一句話就是： 除主幹外，如果用例上個月在所有分支回歸時至少跑過一百次，且每次都通過了，那回歸時就不要再跑了。

現狀問題是什麼

主講人開始先分享了Unity是做什麼的，也有些廣告的意思。Unity作為暢銷的遊戲引擎，2D和3D都支持，同時支持25個平台，所以他們測試時要回歸很多平台，有點像APP手機適配性測試的情況。同時他們的用例也比較多，具體數據如下：

按照金字塔理論，他們的測試分層比例還是很好的。比較好奇的是他們每天都有170W次執行，3W多自動化用例的話，差不多每天要做57輪的回歸。這應該是整個公司的所有團隊觸發的次數，但也挺多的了。

因為他們的Build資源有限，所以打包到回歸完成還是比較漫長的，大概要3-6個小時。

解決方案

所以，他們產生了開始分享的一句話解決方案，嘗試之後縮短時間>50%，效果還是比較明顯的。

這個時間的減少是可以預期的，很大程度上取決於一年來產品的規劃，如果總是做某一塊兒，那麼改動到的會有失敗用例的，也就那麼一塊兒，其他的部分確實回歸不回歸意義就不大了。但是這種條件的選取還是有一些盲目性，因為如果這次改動是比較底層的，那麼可以預計很多之前ever green的測試集也還是要回歸的。所以，測試和開發共同討論的回歸範圍肯定要更智能和精確一些，再輔助這個條件做一些減少，可能是比較穩妥的做法，畢竟回歸的有效性才是回歸的本質意義。

接下來

然後是他們接下來可能想去優化的，但是視頻中，除了第一點 "要去回顧哪些遺漏到主幹失敗了" 之外，主講人其實主要講了他們接下來想去做 精確的動態選取回歸範圍，這個智能是根據修改的代碼決定哪些用例影響到了，從而精確的決定哪些去回歸，這樣就不會遺漏。

個人感受

• 其實很多時候，回歸全部的用例都是低效的，但是硬體資源越來越便宜的情況下，晚上跑個全回歸也是可行的，最起碼比較的穩妥。但是動輒三四個小時的回歸，會大大阻礙回歸的使用頻率。和極品飛車：讓回歸從3小時加速到3分鐘 描寫的一樣，當全回歸只需要3分鐘時，將會使得情況帶來質變。為了加速，將回歸分層也是一個很好的手段。比如像主講人說的，日常的回歸可以選取某些測試集，而主幹上的回歸可以維持全回歸，從而達到提速的目的。
• 真正精確的回歸是更加有效的，也會更安全，避免遺漏。之前接觸過基於C++和Erlang的開發代碼和測試用例映射的框架(一般需要執行)，從而達到精確的回歸開發代碼，如果測試框架也有修改，比如公共函數，那麼再加上測試代碼影響的用例(一般是靜態代碼分析)，就可以得出一個完整而精確的回歸範圍。這樣的精確回歸好處顯而易見，但是也有一些壞處，例如演講最後的提問人就指出了他們做精確回歸遇到的問題。比如是一個新產品，大部分項目都會重構，那麼很多時候就和全回歸差別不大了，而如果是按照主講人這種"非精確"的策略，卻是仍然可以減少很多回歸範圍，雖然有些用例也被動到了，這種可能性在於如果一個公共函數的驗證只需要驗證等價類的其中一個就可以了，那麼的確不需要把所有"精確"影響到的用例都跑一遍了。
• 除此之外， 精確回歸的重要意義其實不只是回歸，他是聯繫了開發代碼，測試代碼和測試用例三者的橋樑。有了這樣的mapping關係數據，還可以衍生出很多事情，比如有個用例失敗了，我們可以很快找出影響這個用例的所有代碼(開發+測試)，然後根據此次提交的代碼修改縮小範圍，快速定位到可能是因為哪些人的哪些次commit導致了問題產生。
• 不知道集團有沒有做類似JAVA和介面、UI用例mapping的框架，單元測試如果一個工程里應該更好做一些，其實還是一個有意思的方向，當然前提是你有初具規模的自動化回歸測試集。

原始資料（原作者：觀山）

• 視頻
• PPT原文

推薦閱讀：