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

大卡爾發表於2021-07-25

樊登有一節課講的挺有意思，說中國有個組織叫績效改進協會，專門研究用技控代替人控的事情。其用麥當勞來舉例子，他說麥當勞其實招人標準很低，高中文憑就可以，但是培養出來的人，三五年之後，每一個都是大家爭搶的物件。為什麼呢？因為麥當勞的標準化做的很好。其中有一個例子是說，麥當勞的漢堡，出爐之後，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分鐘以內。

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