構建高效Presubmit卡點，落地測試左移最佳實踐

樊登有一節課講的挺有意思，說中國有個組織叫績效改進協會，專門研究用技控代替人控的事情。其用麥當勞來舉例子，他說麥當勞其實招人標準很低，高中文憑就能夠，可是培養出來的人，三五年以後，每個都是你們爭搶的對象。爲何呢？由於麥當勞的標準化作的很好。其中有一個例子是說，麥當勞的漢堡，出爐以後，15分鐘以後沒賣掉就扔了。你們想一想，若是你是領導，你如何讓員工遵循這個標準？而麥當勞的解決方案提及來也簡單，漢堡作出來以後就放入保溫箱，15分鐘後保溫箱就會報警，通知餐廳經理該批次的漢堡過時了須要丟棄。

人是組織不肯定性的最大來源，讓人去記每一個漢堡的出爐時間鐵定不行。而咱們作工程效能，質量保障的，也一樣須要思考如何用技術手段消弭不肯定性，以確保更好的作組織升維。

藉此，今天就想談談如何經過強化Presubmit卡點模式，落地實實在在的測試左移，讓提效言之有物。

PS: 針對PR(github叫法)/MR(gitlab叫法)觸發的CI檢查就是Presubmit模式

Presubmit卡點模式能夠包含哪些檢查？

• 單元測試，必需要有。行業內的基本認知，普及度很高。
• 靜態檢查，必需要有。每種語言都有其推薦的檢查工具，建議配上。
• 集成測試/e2e，強烈建議有。
• 系統性能基準測試，若是你在Presubmit階段，可以針對系統的核心KPI，持續自動化的作性能基準測試，用於輔助Code Review階段的代碼合入。恭喜，你當屬於行業領先地位。

相信單測、靜態檢查，大部分項目都有，此處不表。本篇想重點談談爲何要在Presubmit階段引入後幾種測試類型，以及行業參考。

爲何要在Presubmit階段跑集測、e2e、甚至性能基準測試？

筆者有如下幾點認知：

• 提早發現迴歸問題，下降修復成本。Presubmit階段，是研發的編碼階段，在這個階段，若是在測試未介入的狀況下，就能提供充分、即時的質量反饋，必然能夠極大的提升研發迭代效率。要知道不少時候，QA和研發都是在並行工做，手上會有不少事情在排隊處理。而若是一個迴歸缺陷在QA驗收階段才被發現，那可能已通過去一段時間了。研發須要從新將需求拾起，修復並再提測，極可能會浪費不少時間。這種情形下，隱性的成本損耗會很是大。
• 保障提測標準，創建和諧產研關係。不少QA團隊都會要求研發在提測上，要有必定的質量標準。這很好，但人非聖賢，孰能無過。尤爲在時間緊，任務重時，必然會發生研發自測不充分，遺漏低級問題到QA手上的狀況。因此，與其主觀約定，不如用自動化創建標準。
• 強化測試價值，增長曝光度 不少時候，QA同窗寫了不少自動化，可是業務無感，研發無感。這時候，你會發現，自動化就成了QA同窗手裏的玩物，不能有效交付。可是若是在Presubmit階段就充分執行，不斷執行，尤爲是能早早的檢測出bug時，整個團隊必然會更加關注集測產物。久而久之，承認度就會比較高。
• 測試左移，真正優雅的保障入庫代碼質量。談到測試左移，我看到了太多的流程範，意識流。你們不少時候會放大主觀能動性，強調儘早的參與到項目早期。這一點沒錯，但流程仍是依賴於人的值守，但人最是喜新善變。針對迴歸問題，若是可以創建行之有效的檢測手段，必然能夠極大的下降心智負擔。

在Presubmit階段落地複雜測試類型，有哪些挑戰？

好處不少，但落地也非易事。

• 被測系統怎麼建設？ 不論是集成測試仍是e2e，被測對象都是較爲完整的業務系統。而要在Presubmit階段執行起來，就須要經過代碼，自動構建和部署整套系統。另，業務一般會有多個倉庫，多PR/MR同時執行，因此被測環境應該是按需而起，多套並行。
• 資源哪裏來？ 既然是多套環境，必然會涉及到不少資源，資源哪裏來，環境如何有效管理？PR合併以後是否是應該自動回收等等問題。
• 使用什麼樣的系統和姿式來構建？ Presubmit階段對應的是CI系統，而CI的執行必然須要足夠的快。畢竟，提個PR，等十幾分鍾纔有結果反饋，有點不雅。筆者經驗認爲，對於絕大部分的業務，CI要控制在10分鐘之內。

其實深刻分析，問題還會有不少。可是挑戰即機遇，方法總比困難多。只要價值足夠大，收穫才能足夠多。

業界有哪些能夠參考的？

七牛雲

七牛雲比較早的開始圍繞Presubmit階段建設各類質量反饋，落地測試左移。而且還進一步作了測試覆蓋率收集和受影響服務分析,以及devops建設等工做。其使用的方案和工具大部已開源，比較有借鑑價值。

PS:想進一步瞭解細節的同窗，能夠搜索 MTSC2020 Topic: 基於雲原生的測試左移技術實踐 by 儲培

開源工具:

• github.com/qiniu/goc | go語言系統測試覆蓋率收集利器
• github.com/qiniu/go_dep_search | go語言依賴分析

谷歌

谷歌建設Presubmit模式的歷史由來已久，其代碼大倉的工做模式，也讓其在這方面多了一些推陳出新。好比經過Machine Learning / Probabilistic Safety來篩選有效的執行用例，減小Flaky tests等。具體能夠參考:

• https://testing.googleblog.com/2008/09/presubmit-and-performance.html
• https://testing.googleblog.com/2018/09/efficacy-presubmit.html

往期推薦

• 談談測試環境管理與實踐
• 咱們是如何作go系統覆蓋率收集的？
• 聊聊Go代碼覆蓋率技術與最佳實踐

以爲不錯，歡迎關注：