談談測試環境管理與實踐

大卡爾發表於2021-05-06

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

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

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

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

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

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

很明顯，測試環境的定位就是滿足產研側的測試需求，保障產品迭代質量。所以從使用型別上，一般要支撐整合測試，系統測試，壓力測試，甚至故障測試等。

而這些環境背後，其實都伴隨著 非功能性要求 ，重點體現在:

  • 從使用者角度
    • 想用就有，不要等待
    • 要低維護，高穩定
      • 維護角度 - 我只關心我的測試需求，我不想幹其他維護性工作
      • 穩定角度 - 我依賴的其他服務和業務要穩定，不要影響我測試
  • 從企業角度
    • 低成本，高效率
      • 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: 切勿圖省事，無腦部署最簡單模式用於測試驗收)

  • 謹記使用規範 - 改動一定要 入庫, 入庫, 入庫

您覺得呢？

參考資料

往期推薦

覺得不錯，歡迎關注：

相關文章