談談測試環境管理與實踐

測試環境這個話題對於開發和測試同窗必定不陌生，你們幾乎天天都會接觸。可是說到對測試環境的印象，卻鮮有好評:

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

這些問題在行業內其實家常便飯。我甚至有聽過運維同窗"髒亂差"的評價。這裏先不說他的評價是否有偏見，可是起碼我認爲，針對測試環境的管理有較大的改進空間，這是不爭的事實。

而本文將重拾這個看起來老生常談的話題，但願能系統化的闡述個人認知，以期與你們對齊。若是不對或者不完善的地方，歡迎提出，筆者將很是樂於與你們討論。

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

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

很明顯，測試環境的定位就是知足產研側的測試需求，保障產品迭代質量。因此從使用類型上，通常要支撐集成測試，系統測試，壓力測試，甚至故障測試等。

而這些環境背後，其實都伴隨着 非功能性要求 ，重點體如今:

• 從使用者角度
  • 想用就有，不要等待
  • 要低維護，高穩定
    • 維護角度 - 我只關心個人測試需求，我不想幹其餘維護性工做
    • 穩定角度 - 我依賴的其餘服務和業務要穩定，不要影響我測試
• 從企業角度
  • 低成本，高效率
    • 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代碼覆蓋率技術與最佳實踐

以爲不錯，歡迎關注：