除了在床上，我們一天中大概最多的時間就是在測試環境上戰鬥和工作了。

最近在梳理測試環境和一些測試流程，在這裡順手記錄一下，幾年以後看過來，應該是會顯得幼稚和貽笑大方的吧。

測試環境的責任邊界

因為測試環境基本上是屬於測試同學安身立命之本了，很多時候由於環境問題造成的漏測和事故是屢見不鮮的，因此測試環境的重要性不言而喻。

那麼測試環境應該誰來管理呢？

目前看來比較好的方案是所有的測試環境都由測試同學管理，測試同學掌控釋出策略，准入準出規則等等。

另外有條件的話，建議測試同學可以自行搭建測試環境。儘管很難，不過值得一試，因為這種做有如下好處

• 全面瞭解系統的架構。搭建了環境之後，你可能對資料庫，伺服器軟體，各種中介軟體和一系列的配置有了一定程度的感性認識。記得我們當年新人來了之後有條件的話都會讓他們搭建一下開發或者測試環境，這是熟悉系統架構的快捷方式。

• 瞭解資料來源。很多時候資料來源差異也會引起潛在問題。搭建測試環境的時候基本上會準備一些基礎資料和小規模的業務資料，如果這些資料跟線上資料相似度高，比如有一定比例的髒資料，那麼的話發現缺陷的概率相應的也會高一點把。

• 學習開發技能。這點不用展開了吧。

• 理解環境之前的差異。生產環境和測試環境之間或多或少都會有差異，這些差異其實有可能是缺陷的溫床。如果我們能理解這些差異，針對這些差異做一些驗證，比如線上環境有叢集，而測試環境是單機，可以在叢集上驗證一下資料一致性的問題，這會使我們的測試用例更加的完善和高效。

綜上，還是建議測試環境測試同學負責，好處還是顯而易見的。臥榻之側，豈容他人鼾睡，不是麼？

准入準出規則及流程

准入準出其實跟測試環境的分層有一定的關係。不過原則上，我們可以建議在准入之前做一下簡單的冒煙測試，提升准入門檻。

提升准入門檻有下面一些好處。

• 給開發敲警鐘。很多低階問題其實都是開發質量意識低下所導致的。當然質量意識跟能力是成正比的，能力強的開發往往質量意識比較好。提升准入門檻實際上就是讓大部分平均水準的開發多花點心思在功能的質量上，畢竟他們才是質量保障的源頭。開發慎重一些，勝過測試點到吐血。

• 節約溝通成本。如果讓質量很差的版本輕易的釋出到測試環境，那麼各種阻塞性的問題是會相當耗費溝通成本的，如果版本打回的話，大家都不開心，所以嚴格一點，你好我也好。

測試環境分層

有條件的話，建議可以給測試環境分層，層層隔離，每層承擔不同的使命。一般來說，測試環境可以分為

• 開發聯調測試環境。開發協作進行測試和聯調的環境。這個環境可以讓開發隨便玩，也可以作為下一層環境的准入測試環境。
• 功能或模組測試環境。測試維護的某個功能或者模組的測試環境。可以直接部署分支程式碼。
• 整合測試環境。所有的功能都合入該環境進行測試，就是一般意義上的測試環境。前兩個環境沒有其實可以接受，但這個環境是一定需要穩定和可控的。
• uat環境。可以從主幹拉uat分支到該環境進行uat測試，缺陷解決後可以合回主幹。
• 類生產環境。與生產環境儘量一致。包括程式碼，軟硬體以及資料高度一致。正式釋出之前回歸策略執行的地方。
• 灰度環境。有條件可以有灰度環境，用來進行灰度策略的實施。
• 獨立的效能測試環境。這種環境可能是臨時的，效能測試結束之後資源可以釋放掉。

一般來說，測試環境的層級越多就代表著越多的角色會參與到測試活動中去，提前發現問題的概率相對會高一點點。

測試環境與自動化

• 多層級的測試環境要求釋出過程儘可能高度自動化。如果每次釋出都很手工，都很痛苦，那麼團隊可能會選擇維護儘可能少的測試環境來降低工作量，這顯然不是我們想要的結果。

• 穩定的測試環境可以進行週期性的自動化迴歸測試。比如可以在整合測試環境跑介面或ui的自動化。

測試環境與測試及釋出流程

測試環境與測試及釋出流程強相關，什麼樣的測試環境分層從客觀上會影響整體的測試開發及釋出流程。

綜上，每個團隊不同，所採用的測試環境分層策略也不盡相同，另外作者的水平有限，上面內容僅供參考，歡迎斧正。