引子
傳統的軟件測試大多是在測試環境下進行的。人們普遍認為生產環境是服務於最終用戶的，只有在測試環境下進行充分測試後才會發佈給用戶。
基於非生產環境的測試-單元測試、集成測試、功能測試等，很多都是基於預期結果的測試，測試人員一般是帶著這樣的思路來工作 “如果這樣做會發生什麼呢” -屬於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活動為提高軟件的質量注入了新的活力。
原文：https://insights.thoughtworks.cn/testing-in-production/
閱讀更多 ThoughtWorks 的文章
