引子
傳統(tǒng)的軟件測試大多是在測試環(huán)境下進行的。人們普遍認為生產(chǎn)環(huán)境是服務于最終用戶的，只有在測試環(huán)境下進行充分測試后才會發(fā)布給用戶。
基于非生產(chǎn)環(huán)境的測試-單元測試路操、集成測試、功能測試等千贯，很多都是基于預期結果的測試屯仗，測試人員一般是帶著這樣的思路來工作 “如果這樣做會發(fā)生什么呢” -屬于known-unknowns。而生產(chǎn)環(huán)境往往充滿了驚喜-屬于unknown-unknowns搔谴。我們不知道最終用戶怎么操作(參考同事姚琪琳的文章《被踢出去的用戶》)魁袜，數(shù)據(jù)是什么樣的，基礎設施有什么差異等敦第。
Stage作為類生產(chǎn)環(huán)境峰弹，是和生產(chǎn)環(huán)境最接近的一個測試環(huán)境。然而每一次新的發(fā)布都是一組代碼和環(huán)境的組合芜果，只有真正部署到了對應的環(huán)境鞠呈，我們才能確定到底有沒有問題。Stage環(huán)境也是測試環(huán)境右钾，是抱著一定目的進行的操作蚁吝，并不能完全反應真實用戶的行為。
項目背景
我們當前的測試流程如下:
產(chǎn)品經(jīng)受了多個測試環(huán)境的考驗舀射，但是在部署生產(chǎn)環(huán)境后依然暴露出很多意想不到的問題窘茁，初步分析后歸結為下面兩個因素：
1. 生產(chǎn)環(huán)境下數(shù)據(jù)復雜多樣
我們對客戶報過來的production問題進行了分析，下圖可以看出由于數(shù)據(jù)問題導致的功能/性能問題在10%左右的區(qū)間波動脆烟。
軟件系統(tǒng)的靈活性給與了用戶各種各樣的操作可能山林，代碼/腳本的不確定性也會造成數(shù)據(jù)的不一致。這些都賦予了生產(chǎn)環(huán)境下數(shù)據(jù)的多樣性邢羔，是其他環(huán)境無法模擬的驼抹。
2. 軟件配置的集中化
ThoughtWorks團隊主要負責軟件的開發(fā)桑孩，而Stage和Prod環(huán)境部署在云平臺上，這些訪問權限嚴格控制在客戶手中砂蔽，基礎設施嚴重依賴于客戶洼怔。
項目即將大規(guī)模將配置由原來的SVN遷移到ZooKeeper實現(xiàn)集中管理。作為一個技術的改進左驾，同時也蘊含著風險 - Stage和Prod的配置將由客戶進行單點手工維護，對ThoughtWorks團隊不可見极谊，因此我們無法預知某個配置是否已經(jīng)被添加/修改以及是否賦予了正確的值诡右。
Testing in Production如何做
環(huán)境的特殊性帶來了產(chǎn)品的不確定性，我們希望把測試的觸角向前延伸轻猖，到生產(chǎn)環(huán)境去做測試帆吻，提前暴露產(chǎn)品的潛在問題，提高用戶的滿意度咙边。
由于各種因素的約束猜煮，在生產(chǎn)環(huán)境能做的事情往往有限。比如我們項目的安全等級很高败许，開發(fā)團隊是不能夠訪問生產(chǎn)環(huán)境的服務器的王带，甚至連脫敏的數(shù)據(jù)也接觸不到。Stage環(huán)境下的數(shù)據(jù)也僅僅是客戶的測試數(shù)據(jù)市殷，不能把生產(chǎn)環(huán)境下的數(shù)據(jù)遷移過來愕撰。
業(yè)界實踐
TiP并不是一個全新的事物，業(yè)界已經(jīng)有了很多成熟實踐：藍綠部署醋寝、金絲雀測試搞挣、A/B測試等。
藍綠部署是在有兩個一樣環(huán)境的前提下音羞，不停老版本囱桨，部署新版本進行測試。測試沒問題之后直接把流量切到新版本上嗅绰，再把老版本也升級到新版本舍肠。一般適用于對用戶體驗有一定的忍耐度、機器資源豐富的團隊办陷。
“金絲雀測試”得名于以前曠工下井前會先放一只金絲雀去看是否有有毒氣體貌夕，以金絲雀能否存活進行判斷唇跨。一般是部署新版本到很小比例的服務器上寸五，并允許小部分用戶來使用新版本，測試通過則把剩余的服務都升級為新版本霍衫。一般適用于對新版本缺乏信心的團隊制圈。
A/B測試主要用于產(chǎn)品功能對比们童，版本A和版本B分別部署在不同的服務器上并開放給不同的用戶使用畔况，一般適用于收集用戶反饋輔助產(chǎn)品功能設計。
藍綠部署
基于當前產(chǎn)品環(huán)境的復雜架構慧库，構建另一套相同的生產(chǎn)環(huán)境來實現(xiàn)藍綠部署作為第一方案被提出來跷跪。藍綠部署的思路如圖：
在同一個時間段，藍作為當前的生產(chǎn)環(huán)境供線上用戶使用齐板，綠作為部署新功能的測試環(huán)境供部分用戶使用吵瞻。兩個環(huán)境的基礎設施相同，配置一樣甘磨，數(shù)據(jù)都是真實的生產(chǎn)環(huán)境數(shù)據(jù)橡羞。綠環(huán)境下發(fā)現(xiàn)的問題可以隨時診斷修復，確認滿足上線需求后即可把線上用戶引流到綠環(huán)境济舆，實現(xiàn)了最小化的宕機時間卿泽。
藍綠部署的這個優(yōu)勢看似極好的契合了項目當前的訴求，但是準備一套同樣的生產(chǎn)環(huán)境需要的成本在可視化出來之后也是令人震驚的滋觉！新的服務器就需要7臺签夭，而且每個月還需要預留出足夠的時間來同步數(shù)據(jù)。在功能交付的壓力之下椎侠，客戶是不會為這樣一個昂貴且成果未知的方案買單的第租，我們連自己都說服不了。
改進的方案
就在焦灼的時候肺蔚，在一次頭腦風暴中我們獲取到一條線索-客戶的災備環(huán)境(Disaster Recovery)在定期從生產(chǎn)環(huán)境同步數(shù)據(jù)煌妈，但也僅僅是同步數(shù)據(jù)，代碼已經(jīng)很久沒有部署過宣羊。也就是說災備環(huán)境沒有真正起到它應有的災難備份和恢復璧诵，只是一個數(shù)據(jù)的備份而已。
方案就此而得到轉(zhuǎn)機 - 是否可以復活災備環(huán)境仇冯，利用它可以訪問生產(chǎn)環(huán)境數(shù)據(jù)的天然優(yōu)勢來解決前面的痛點呢之宿？在藍綠部署方案的基礎上，改進的方案如下：
鑒于災備環(huán)境的基礎設施不足以支撐其作為線上環(huán)境供所有用戶使用苛坚，但是它的配置是等同于產(chǎn)品環(huán)境的比被。DR的定位為分時的災備和測試環(huán)境 - 大部分時間用于災備，小部分時間作為金絲雀進行新版本的測試泼舱。
災備環(huán)境測試通過后的版本按照當前的部署流程進行生產(chǎn)環(huán)境的部署等缀。這樣一來不僅能恢復其本來的災備作用，也解決了之前數(shù)據(jù)和配置集中化問題帶來的痛點娇昙。
展望
從當前的測試流程來看尺迂，QA和Stage環(huán)境承擔的工作有很大一部分重疊，帶來了一定的浪費。希望未來有一天能去掉Stage環(huán)境噪裕，直接把這些server用在生產(chǎn)環(huán)境下構建一套新的環(huán)境蹲盘，做到充分的基于生產(chǎn)環(huán)境的測試，實現(xiàn)新老版本的無縫切換膳音。 期待測試流程會變成如下所示：
當今軟件的部署越來越多的基于第三方的云平臺召衔，給團隊帶來了不可控因素。Testing in Production是基于生產(chǎn)環(huán)境下真實用戶的行為和數(shù)據(jù)進行的一系列QA活動祭陷。傳統(tǒng)的基于測試環(huán)境進行的測試活動苍凛，輔助以生產(chǎn)環(huán)境下的QA活動為提高軟件的質(zhì)量注入了新的活力。
文/ThoughtWorks胡志芳
