談談測試環境管理與實踐

測試環境這個話題對于開發和測試同學一定不陌生，大家幾乎每天都會接觸。但是說到對測試環境的印象，卻鮮有好評:

• 環境不穩定，測試五分鐘，排查兩小時
• 功能建設不全，導緻驗證不充分，遺漏缺陷
• 多人共用，互相踩踏
• 随手改動不入庫，消極對待，缺乏敬畏之心

這些問題在行業内其實屢見不鮮。我甚至有聽過運維同學"髒亂差"的評價。這裡先不說他的評價是否有偏見，但是起碼我認為，針對測試環境的管理有較大的改進空間，這是不争的事實。

而本文将重拾這個看起來老生常談的話題，希望能系統化的闡述我的認知，以期與大家對齊。如果不對或者不完善的地方，歡迎提出，筆者将非常樂于與大家讨論。

首先我們要清晰的認知到，測試環境管理做的不好，不光有嚴重的品質風險，還會非常影響疊代效率，是以這件事情很重要。那在解決它之前，我們首先要去想想，對于測試環境我們到底有哪些訴求？

我們對測試環境的本質訴求是什麼？

很明顯，測試環境的定位就是滿足産研側的測試需求，保障産品疊代品質。是以從使用類型上，一般要支撐內建測試，系統測試，壓力測試，甚至故障測試等。

而這些環境背後，其實都伴随着 非功能性要求 ，重點展現在:

• 從使用者角度
  • 想用就有，不要等待
  • 要低維護，高穩定
    • 維護角度 - 我隻關心我的測試需求，我不想幹其他維護性工作
    • 穩定角度 - 我依賴的其他服務和業務要穩定，不要影響我測試
• 從企業角度
  • 低成本，高效率
    • PS: 測試環境管理追求的是更高的研發疊代效率，但是成本是底線

除此之外，其實還有個非常關鍵的問題就是，要定義清楚測試環境管理的主體責任人是誰。這點很關鍵，沒有責任人自然會滋生亂象。

• 研發 雖經常使用測試環境，但從投入産出比上，組織一般還是希望研發同學能多投入精力做更多創造性的事情
• 運維 本身負責線上環境的運維，可能有企業也會覺得把測試環境交給他們運維會順水渠成，且現實确實是有不少企業就是這麼幹的。不過從人性的角度去分析，相比于線上環境，運維同學對測試環境的重視程度一定不夠。而這也是為什麼，很多企業的測試環境管理，也隻是達到将就能用的水準的原因。
• 測試 測試同學算是測試環境的主要使用者，對測試環境的管理理應負有直接責任。不過現實中，經常看到的是，測試同學因本身測試任務較多，且測試環境管理也要求具備一定的系統運維能力。導緻相對而言，測試同學要想做好測試環境管理，也不容易。

不過，不管是哪個角色負責，其實症結還在ROI上。隻要有充足的預算和人力，這些都不是問題。反之，就需要不斷的優化和調整。

當然人力成本是組織層面的考量，今天我們先按下不表。這裡重點聊聊如何從技術上解決這些問題。

業界的思路？

先來看看業界是怎麼玩的。

阿裡

阿裡講測試環境的文章不少，其中有一篇來自雲效的文章，挺有借鑒價值。其重點聚焦了兩個方向:

• 通過項目環境複用公共基礎環境的模式，來解決資源問題

  

• 通過鍊路識别，請求染色，做到聯調測試不串流量

  

當然，這些是借助阿裡内部中間件實作的。不過在雲原生環境下，其也開源了兩個工具kt-connect和virtual-environment，雖産品化程度做的不夠，但整體還是比較有想法的。

百度

百度有篇檔案介紹了其中間件技術在測試中的應用。文章說的比較清晰，這個中間件的架構是類似istio的模式，本質是通過代理來托管系統流量，進而實作控制鍊路的能力。而有了這個能力，對測試聯調和環境複用自然就不在話下。同樣的，對于錄制/回放/mock/混沌等測試場景的能力實作上也能順水渠成。

不過這個平台看起來有濃濃的背景局限，尤其是其控制平面的邏輯設計，感覺要玩轉起來，需要一系列的基礎設施的配合。是以這個應該是強百度業務和技術環境背景下的産物，對于使用者，也應該有一定的學習和了解成本。

商業化？

其他企業如有贊、喜馬拉雅等，基本上也都是采用改造服務，通過路由政策來實作隔離組，進而達到環境複用的能力。

不過以上都是技術人的玩法，我在想測試環境管理這個方向有沒有商業化價值呢？

大家看下圖，來自站點www.testenvironmentmanagement.com:

(PS: 2019年4月釋出)

見名識意，這些都是國外主打Test Environment Management(TEM)方向的企業，其中Plutora在2011年創立，2016年融了1340萬$. Enov8 始于2008年，正式創立于2014年。整體感覺活的都還不錯。

研究這些企業會發現，他們會把價值重點落地在操作自動化，過程Visibility，以及自服務和降低成本上。尤其是降低成本這塊，會推出電腦，讓企業主一目了然的看到，使用了他們的TEM方案會降低多少人力成本，多少資源成本等等。

另外，在TEM方向上，這些企業都會比較重視測試環境資源的自動或預約回收能力，以達到節約成本。這一點，感覺國内的玩家重視程度不夠。

當然，目前國内網際網路ToB Saas企業也開始方興未艾，比如我前老大的創業公司www.koderover.com，其拳頭産品雲原生持續傳遞平台，也有關注TEM方向，值得推薦。

認知自醒，我們需要堅守哪些原則？

測試環境抛開全局管理一說，我認為作為使用者，最重要的還是堅守以下原則:

• 重視服務部署環節，盡可能的遵循線上部署模式，比如：
  • 基礎系統一緻(系統版本，核心版本等)
  • 中間件版本和部署姿勢一緻 - 千萬不要想當然
  • 部署工具一緻(PS: 堅決抵制那種通過apt-get install在機器上随意安裝的行為)。
  • 部署邏輯一緻 - 模拟真實場景，避免測試遺漏(The wider the gap between test and production, the greater the probability that the delivered product will have more bugs/defects.), 包括:
    • 服務版本
    • 配置寫法
    • 執行個體個數
    • 機房or區域情況等等
  (PS: 切勿圖省事，無腦部署最簡單模式用于測試驗收)
• 謹記使用規範 - 改動一定要 入庫, 入庫, 入庫

您覺得呢？

參考資料

• https://developer.aliyun.com/article/755512
• https://mp.weixin.qq.com/s/rjToB9qxv47rUrwcBhzpjA
• https://tech.youzan.com/web-https-engineering-2/
• https://www.heguang-tech.com/2020/solution/ximalaya/
• https://www.testenvironmentmanagement.com/test-environment-management-tools-compared/
• https://www.enov8.com/roicalculator/

往期推薦

• 我們是如何做go系統覆寫率收集的？
• 聊聊Go代碼覆寫率技術與最佳實踐

覺得不錯，歡迎關注：