測試環境困局

測試環境治理專項是在我入職2個月接手的活，用“爛攤子”來形容一點也不為過。年久失修，需求基本沒有在測試環境使用，想用也有很多問題。人員缺乏信心，之前負責測試環境的同學抱怨極多，外部推不動，內部又沒有技術能力支撐，負能量已經蔓延到整個團隊。當然，我也是其中一員，這事確實難搞。在技術部測試環境平臺化的大方向下，需要每個組出一個介面人來牽頭，考慮到我以前寫過測試平臺，亂七八糟的事都整過，老闆就指定了我。

What，測試環境是什麼？

測試環境是一套能夠支撐業務系統執行的環境，是相對於預發環境和生產環境來說完全隔離的環境。測試環境=應用+資料+配置+依賴服務。應用包含系統應用和中介軟體等，資料就是測試物料，配置針對測試環境應該有單獨的一套，依賴服務要跟外部聯調好以後整個環境才是可用的。測試環境治理就是通過內部搭建和外部聯調，保障業務系統能夠在完全隔離的環境中執行。

Why，為什麼要做測試環境？

測試環境是為了隔離。如果只有一套生產環境，那麼開發、測試、上線等活動，可能會對線上系統穩定性造成影響，可能會汙染線上使用者資料，可能引起客戶投訴甚至資產損失，所以需要有一套完全隔離的測試環境。

Who，誰來負責測試環境？

每個測試人員都需要具備測試環境搭建能力。當然可以推動運維或研發來搭建測試環境，但是測試人員需要具備搭建能力，能夠自主編譯，構建，部署，遇到問題能夠根據日誌做初步定位，將問題丟擲推動研發或外部依賴方解決。

When，什麼時間做測試環境？

測試環境治理需要前置到研發自測階段。在實踐過程中，測試同學暴露出來最多的問題是，沒有時間投入到測試環境搭建中，一方面是缺乏動力，不肯邁出艱難的第一步，另一方面也是跟專案節奏有關，研發就算用測試環境自測，也會在預發聯調好以後再提測，到測試手上時，已經有可用的預發環境了，就不會再去用測試環境。“專案時間緊，測試環境不好用，直接用預發測吧”，順理成章的就成為了很合理的藉口。所以需要從提測，前置到，研發自測，做測試環境治理：

Where，從哪裡入手測試環境？

測試環境治理需要從上往下才能推動，先有文化，才有行動。假如只有某個部門想做測試環境治理，外部依賴基本上是推不動的，一個人吶喊得再憤怒其他人也可能無動於衷。所以得先把測試環境治理這件事，跟老闆溝通，從高層入手，把它定義為一項政治任務，從上往下層層遞進。

How，怎麼做測試環境？

工欲善其事，必先利其器，公司的基建比較完善，給測試人員搭建測試環境降低了很大難度。設想一下，假如只能折騰Docker和K8S，那可能需要專門的運維才能搞得定環境，對測試來說門檻就會比較高了，除了少數技術能力強的，其他同學基本沒有什麼可操作性。測試環境平臺化就是武器。公司有個部署平臺叫做JDOS，日常運維都是在這上面操作，沒有運維人員，環境全靠開發人員和測試人員自己整。JDOS已經是頁面化操作了，但它對測試環境沒有特殊的應用場景，是個大而全的平臺，所以二級部門開了一個測試環境平臺，Env，"一款全流程自動化測試環境搭建的利器"。

Env的核心思想是1+N。1代表穩定分組（分組≈Pod），搭建穩定分組需要經過建立系統，建立應用，建立叢集，申請機器，程式碼編譯構建，部署映象，修改配置等操作，需要選取master穩定版本，這樣才能對外提供穩定服務。N是克隆1產生的多個分組，相互隔離，能讓開發同學複用測試搭建好的環境，完成冒煙自測等過程；也能在多業務聯調測試時，通過平臺快速搭建一套全鏈路測試環境。

Env提供了環境監控的功能。對於搭建好的穩定環境，它可以每天監控機器是否可用，服務是否正常，映象是否老舊，等等等，讓你及時維護環境，保障穩定性。

Env提供了一鍵搭建的功能。新克隆的環境，只要點一下“一鍵搭建”，就會基於穩定分組，自動化搭建一套新環境，大大節約了時間成本。

Env提供了拓撲畫圖的功能。將多個應用拖到一張拓撲圖裡面，根據依賴關係連線，能夠直觀瞭解到應用之間的依賴關係。基於拓撲來克隆新環境，也能批量克隆多個應用。假如多專案需求並行迭代，想要多套聯調的測試環境，就可以克隆多套新環境。

Env還解決了一個資源浪費的問題，以前搭建測試環境比較隨意，申請資源也很容易，其實會導致很多機器用過後，一直空置在那裡。Env收攏了申請資源入口，基於Env來建立穩定分組，只能有1個，想要更多必須走審批。而對於克隆的新環境，也會有期限，14天以後會自動釋放，想要延期也必須走審批。

我所負責的第一件事，就是用Env來搭建一張拓撲圖，把組內所有應用都從JDOS遷移到Env上，維持穩定環境對外提供支撐對接，克隆環境對內支援多專案並行。

搭建測試環境只是起步，測試環境治理的目標是需求能夠使用測試環境。對於外部依賴少的業務模組來說，這相對容易。對於外部依賴很多的業務模組來說，這就很難了。那麼該如何推動這件事呢？

第1個策略是共建，讓研發和測試一起來搭建和維護測試環境。

第2個策略是做功能驗證，梳理出鏈路用例，跟蹤驗證結果，識別卡點問題：

對於卡點問題的處理，把干係人單獨拉群對，響應超過3天就往上拋，一定會遇到推不動的問題，那麼辦法只能找自己的上游負責人，層層向上反饋，讓上面的負責人去找對方負責人，然後推動對方的下游同學來協助解決。卡點問題記錄後需要做問題分類，做好統計，這既是工作量的體現，也是每週進度彙報的依據：

第3個策略就是制定kpi，強制大家使用測試環境完成績效。

How much，測試環境做到什麼程度？

測試環境的kpi能反應出測試環境應該做到什麼程度，可以使用需求使用測試環境佔比和測試環境bug佔比。需求使用測試環境佔比的計算公式是打標了測試環境的提測卡片數/總的提測卡片數，測試在點選開始測試時，選擇是否使用測試環境進行打標。測試環境bug佔比的計算公式是測試環境bug/(測試環境bug+預發環境bug+生產環境bug)，在提交缺陷時選擇環境型別進行打標。測試環境bug佔比的意義更大，因為使用測試環境與否，最終的體現還是落在缺陷上面的，比較容易量化，需求使用測試環境佔比不是很確定，需求多少功能在測試環境使用了，相對來說不是很好度量，但也可以作為輔助指標進行觀察。

測試環境破局

測試環境關聯了很多東西，比如物料、自動化、精準、流水線等，都可以圍繞測試環境來做文章。測試環境既是團隊重點，也是是我個人的大案例，目前已經解決了部分困難，要想做出一鳴驚人的成績，還需要站在更高的角度去看待整個事情，這也是一個全新的挑戰，需要不斷重新整理自己，突破。