引子

傳統的軟體測試大多是在測試環境下進行的。人們普遍認為生產環境是服務於終端使用者的，只有在測試環境下進行充分測試後才會釋出給使用者。

基於非生產環境的測試-單元測試、整合測試、功能測試等，很多都是基於預期結果的測試，測試人員一般是帶著這樣的思路來工作 “如果這樣做會發生什麼呢” -屬於known-unknowns。而生產環境往往充滿了驚喜-屬於unknown-unknowns。我們不知道終端使用者怎麼操作(參考同事琪琳的文章‘被踢出去的使用者’)，資料是什麼樣的，基礎設施有什麼差異等。

Stage作為類生產環境，是和生產環境最接近的一個測試環境。然而每一次新的釋出都是一組程式碼和環境的組合，只有真正部署到了對應的環境，我們才能確定到底有沒有問題。Stage環境也是測試環境，是抱著一定目的進行的操作，並不能完全反應真實使用者的行為。

專案背景

我們當前的測試流程如下:

產品經受了多個測試環境的考驗，但是在部署生產環境後依然暴露出很多意想不到的問題，初步分析後歸結為下面兩個因素：

1. 生產環境下資料複雜多樣

我們對客戶報過來的production問題進行了分析，下圖可以看出由於資料問題導致的功能/效能問題在10%左右的區間波動。

軟體系統的靈活性給與了使用者各種各樣的操作可能，程式碼/指令碼的不確定性也會造成資料的不一致。這些都賦予了生產環境下資料的多樣性，是其他環境無法模擬的。

2. 軟體配置的集中化

ThoughtWorks團隊主要負責軟體的開發，而Stage和Prod環境部署在雲平臺上，這些訪問許可權嚴格控制在客戶手中，基礎設施嚴重依賴於客戶。

專案即將大規模將配置由原來的SVN遷移到ZooKeeper實現集中管理。作為一個技術的改進，同時也蘊含著風險 - Stage和Prod的配置將由客戶進行單點手工維護，對ThoughtWorks團隊不可見，因此我們無法預知某個配置是否已經被新增/修改以及是否賦予了正確的值。

Testing in Production如何做

環境的特殊性帶來了產品的不確定性，我們希望把測試的觸角向前延伸，到生產環境去做測試，提前暴露產品的潛在問題，提高使用者的滿意度。

由於各種因素的約束，在生產環境能做的事情往往有限。比如我們專案的安全等級很高，開發團隊是不能夠訪問生產環境的伺服器的，甚至連脫敏的資料也接觸不到。Stage環境下的資料也僅僅是客戶的測試資料，不能把生產環境下的資料遷移過來。

業界實踐

TiP並不是一個全新的事物，業界已經有了很多成熟實踐：藍綠部署、金絲雀測試、A/B測試等。

藍綠部署是在有兩個一樣環境的前提下，不停老版本，部署新版本進行測試。測試沒問題之後直接把流量切到新版本上，再把老版本也升級到新版本。一般適用於對使用者體驗有一定的忍耐度、機器資源豐富的團隊。

“金絲雀測試”得名於以前曠工下井前會先放一隻金絲雀去看是否有有毒氣體，以金絲雀能否存活進行判斷。一般是部署新版本到很小比例的伺服器上，並允許小部分使用者來使用新版本，測試通過則把剩餘的服務都升級為新版本。一般適用於對新版本缺乏信心的團隊。

A/B測試主要用於產品功能對比，版本A和版本B分別部署在不同的伺服器上並開放給不同的使用者使用，一般適用於收集使用者反饋輔助產品功能設計。

藍綠部署

基於當前產品環境的複雜架構，構建另一套相同的生產環境來實現藍綠部署作為第一方案被提出來。藍綠部署的思路如圖：

在同一個時間段，藍作為當前的生產環境供線上使用者使用，綠作為部署新功能的測試環境供部分使用者使用。兩個環境的基礎設施相同，配置一樣，資料都是真實的生產環境資料。綠環境下發現的問題可以隨時診斷修復，確認滿足上線需求後即可把線上使用者引流到綠環境，實現了最小化的宕機時間。

藍綠部署的這個優勢看似極好的契合了專案當前的訴求，但是準備一套同樣的生產環境需要的成本在可視化出來之後也是令人震驚的！新的伺服器就需要7臺，而且每個月還需要預留出足夠的時間來同步資料。在功能交付的壓力之下，客戶是不會為這樣一個昂貴且成果未知的方案買單的，我們連自己都說服不了。

改進的方案

就在焦灼的時候，在一次頭腦風暴中我們獲取到一條線索-客戶的災備環境(Disaster Recovery)在定期從生產環境同步資料，但也僅僅是同步資料，程式碼已經很久沒有部署過。也就是說災備環境沒有真正起到它應有的災難備份和恢復，只是一個數據的備份而已。

方案就此而得到轉機 - 是否可以復活災備環境，利用它可以訪問生產環境資料的天然優勢來解決前面的痛點呢？在藍綠部署方案的基礎上，改進的方案如下：

鑑於災備環境的基礎設施不足以支撐其作為線上環境供所有使用者使用，但是它的配置是等同於產品環境的。DR的定位為分時的災備和測試環境 - 大部分時間用於災備，小部分時間作為金絲雀進行新版本的測試。

災備環境測試通過後的版本按照當前的部署流程進行生產環境的部署。這樣一來不僅能恢復其本來的災備作用，也解決了之前資料和配置集中化問題帶來的痛點。

展望

從當前的測試流程來看，QA和Stage環境承擔的工作有很大一部分重疊，帶來了一定的浪費。希望未來有一天能去掉Stage環境，直接把這些server用在生產環境下構建一套新的環境，做到充分的基於生產環境的測試，實現新老版本的無縫切換。
期待測試流程會變成如下所示：

當今軟體的部署越來越多的基於第三方的雲平臺，給團隊帶來了不可控因素。Testing in Production是基於生產環境下真實使用者的行為和資料進行的一系列QA活動。傳統的基於測試環境進行的測試活動，輔助以生產環境下的QA活動為提高軟體的質量注入了新的活力。

文/ThoughtWorks胡志芳
更多精彩洞見，請關注微信公眾號：思特沃克