除了在床上，我們一天中大概最多的時間就是在測試環境上戰斗和工作了。
最近在梳理測試環境和一些測試流程，在這里順手記錄一下，幾年以后看過來，應該是會顯得幼稚和貽笑大方的吧。
測試環境的責任邊界
因為測試環境基本上是屬於測試同學安身立命之本了，很多時候由於環境問題造成的漏測和事故是屢見不鮮的，因此測試環境的重要性不言而喻。
那么測試環境應該誰來管理呢？
目前看來比較好的方案是所有的測試環境都由測試同學管理，測試同學掌控發布策略，准入准出規則等等。
另外有條件的話，建議測試同學可以自行搭建測試環境。盡管很難，不過值得一試，因為這種做有如下好處
-
全面了解系統的架構。搭建了環境之后，你可能對數據庫，服務器軟件，各種中間件和一系列的配置有了一定程度的感性認識。記得我們當年新人來了之后有條件的話都會讓他們搭建一下開發或者測試環境，這是熟悉系統架構的快捷方式。
-
了解數據源。很多時候數據源差異也會引起潛在問題。搭建測試環境的時候基本上會准備一些基礎數據和小規模的業務數據，如果這些數據跟線上數據相似度高，比如有一定比例的臟數據，那么的話發現缺陷的概率相應的也會高一點把。
-
學習開發技能。這點不用展開了吧。
-
理解環境之前的差異。生產環境和測試環境之間或多或少都會有差異，這些差異其實有可能是缺陷的溫床。如果我們能理解這些差異，針對這些差異做一些驗證，比如線上環境有集群，而測試環境是單機，可以在集群上驗證一下數據一致性的問題，這會使我們的測試用例更加的完善和高效。
綜上，還是建議測試環境測試同學負責，好處還是顯而易見的。卧榻之側，豈容他人鼾睡，不是么？
准入准出規則及流程
准入准出其實跟測試環境的分層有一定的關系。不過原則上，我們可以建議在准入之前做一下簡單的冒煙測試，提升准入門檻。
提升准入門檻有下面一些好處。
-
給開發敲警鍾。很多低級問題其實都是開發質量意識低下所導致的。當然質量意識跟能力是成正比的，能力強的開發往往質量意識比較好。提升准入門檻實際上就是讓大部分平均水准的開發多花點心思在功能的質量上，畢竟他們才是質量保障的源頭。開發慎重一些，勝過測試點到吐血。
-
節約溝通成本。如果讓質量很差的版本輕易的發布到測試環境，那么各種阻塞性的問題是會相當耗費溝通成本的，如果版本打回的話，大家都不開心，所以嚴格一點，你好我也好。
測試環境分層
有條件的話，建議可以給測試環境分層，層層隔離，每層承擔不同的使命。一般來說，測試環境可以分為
- 開發聯調測試環境。開發協作進行測試和聯調的環境。這個環境可以讓開發隨便玩，也可以作為下一層環境的准入測試環境。
- 功能或模塊測試環境。測試維護的某個功能或者模塊的測試環境。可以直接部署分支代碼。
- 集成測試環境。所有的功能都合入該環境進行測試，就是一般意義上的測試環境。前兩個環境沒有其實可以接受，但這個環境是一定需要穩定和可控的。
- uat環境。可以從主干拉uat分支到該環境進行uat測試，缺陷解決后可以合回主干。
- 類生產環境。與生產環境盡量一致。包括代碼，軟硬件以及數據高度一致。正式發布之前回歸策略執行的地方。
- 灰度環境。有條件可以有灰度環境，用來進行灰度策略的實施。
- 獨立的性能測試環境。這種環境可能是臨時的，性能測試結束之后資源可以釋放掉。
一般來說，測試環境的層級越多就代表着越多的角色會參與到測試活動中去，提前發現問題的概率相對會高一點點。
測試環境與自動化
-
多層級的測試環境要求發布過程盡可能高度自動化。如果每次發布都很手工，都很痛苦，那么團隊可能會選擇維護盡可能少的測試環境來降低工作量，這顯然不是我們想要的結果。
-
穩定的測試環境可以進行周期性的自動化回歸測試。比如可以在集成測試環境跑接口或ui的自動化。
測試環境與測試及發布流程
測試環境與測試及發布流程強相關，什么樣的測試環境分層從客觀上會影響整體的測試開發及發布流程。
綜上，每個團隊不同，所采用的測試環境分層策略也不盡相同，另外作者的水平有限，上面內容僅供參考，歡迎斧正。