淺談測試環境

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

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

測試環境的責任邊界

由於測試環境基本上是屬於測試同窗安身立命之本了，不少時候因爲環境問題形成的漏測和事故是家常便飯的，所以測試環境的重要性不言而喻。

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

目前看來比較好的方案是全部的測試環境都由測試同窗管理，測試同窗掌控發佈策略，准入準出規則等等。

另外有條件的話，建議測試同窗能夠自行搭建測試環境。儘管很難，不過值得一試，由於這種作有以下好處

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

• 瞭解數據源。不少時候數據源差別也會引發潛在問題。搭建測試環境的時候基本上會準備一些基礎數據和小規模的業務數據，若是這些數據跟線上數據類似度高，好比有必定比例的髒數據，那麼的話發現缺陷的機率相應的也會高一點把。

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

• 理解環境以前的差別。生產環境和測試環境之間或多或少都會有差別，這些差別其實有多是缺陷的溫牀。若是咱們能理解這些差別，針對這些差別作一些驗證，好比線上環境有集羣，而測試環境是單機，能夠在集羣上驗證一下數據一致性的問題，這會使咱們的測試用例更加的完善和高效。

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

准入準出規則及流程

准入準出其實跟測試環境的分層有必定的關係。不過原則上，咱們能夠建議在准入以前作一下簡單的冒煙測試，提高准入門檻。

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

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

• 節約溝通成本。若是讓質量不好的版本輕易的發佈到測試環境，那麼各類阻塞性的問題是會至關耗費溝通成本的，若是版本打回的話，你們都不開心，因此嚴格一點，你好我也好。

測試環境分層

有條件的話，建議能夠給測試環境分層，層層隔離，每層承擔不一樣的使命。通常來講，測試環境能夠分爲

• 開發聯調測試環境。開發協做進行測試和聯調的環境。這個環境可讓開發隨便玩，也能夠做爲下一層環境的准入測試環境。
• 功能或模塊測試環境。測試維護的某個功能或者模塊的測試環境。能夠直接部署分支代碼。
• 集成測試環境。全部的功能都合入該環境進行測試，就是通常意義上的測試環境。前兩個環境沒有其實能夠接受，但這個環境是必定須要穩定和可控的。
• uat環境。能夠從主幹拉uat分支到該環境進行uat測試，缺陷解決後能夠合回主幹。
• 類生產環境。與生產環境儘可能一致。包括代碼，軟硬件以及數據高度一致。正式發佈以前回歸策略執行的地方。
• 灰度環境。有條件能夠有灰度環境，用來進行灰度策略的實施。
• 獨立的性能測試環境。這種環境多是臨時的，性能測試結束以後資源能夠釋放掉。

通常來講，測試環境的層級越多就表明着越多的角色會參與到測試活動中去，提早發現問題的機率相對會高一點點。

測試環境與自動化

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

• 穩定的測試環境能夠進行週期性的自動化迴歸測試。好比能夠在集成測試環境跑接口或ui的自動化。

測試環境與測試及發佈流程

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

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