鄭子穎：阿裡巴巴研究員，2002年上海交通大學計算機系碩士畢業。2018年3月加入阿裡，負責品質和技術風險。
1. 測試穩定性問題
理想情況下，我們希望每一個失敗的測試用例[1]都是由真正的缺陷引起的。實際情況中，用例失敗的原因大多是一些其他的原因：
- 某個服務的版本部署的不對
- 測試執行機的硬碟滿了，因為上次運作時寫的log沒清掉
- 資料庫裡有髒資料
- 測試用例寫得有問題
- 測試運作時有人手工執行了一次定時任務，把流水撈走了
- 消息串了
- ...
每次排查都是一堆這種問題，時間久了，開發和測試同學也就疲了。有些同學對失敗的用例草草看一眼，就說這是一個“環境問題”，不再排查下去了。如此一來，很多真正的缺陷就被漏過了。
2. 測試穩定性三闆斧
如何治理測試穩定性問題？很多人會說：環境、流程管控、監控、工具化、加機器、專人負責、等等。這些都是對的。不過這些都是解決方案層面的，而不是方法論和理論體系層面的。
在方法論和理論體系層面，我們對安全生産有三闆斧：可灰階、可監控、可復原。類似的，對于測試穩定性，我也有三闆斧：
- 高頻（Frequency）
- 隔離（Isolation）
- 用完即抛（Disposable）
三闆斧之一：高頻
"If it hurts, do it more often"是我說的最多的一句話之一。這句話從Martin Fowler那兒來的，有興趣的可以讀一下他的那篇“Frequency Reduces Difficulty”的原文。
高頻跑測試的好處是：
- 縮短驗證的delay
- 變主動驗證為“消極等待”
- 識别intermittent的問題
- 暴露各層面的不穩定因素
- 倒逼人肉環節的自動化
- 提供更多的資料供分析
高頻不單單是治理測試穩定性的不二法門，也是治理其他工程問題的game changer：
持續打包：以前隻是在部署測試環境前才打包，經常因為打包的問題導緻部署花了很多時間，還影響了後面的測試進度。針對這個問題，我們做了持續打包，每個小時都會對master的HEAD打包，一旦遇到問題（例如：依賴的mvn包缺失、配置缺失、等等），馬上修複。
天天上生産：現在每周發一次生産環境，每次都費事費力。我提出能不能天天上生産。釋出還是按照原來的節奏來，每周發一次新代碼，一周裡的其餘日子，就算沒有新代碼也要走一遍生産釋出。空轉。不為别的，就是為了要用高頻來暴露問題、倒逼人肉環節的自動化、倒逼各種環節的優化。
分支合并很痛苦，那就頻繁合并，一天一次，一天多次。做到極緻就變成了主幹開發，一直在rebase、一直在送出。
螞蟻的SRE團隊也是用的是高頻的思路。為了加強容災能力建設、提高容災演練的成功率，SRE團隊的一個主打思想就是要高頻演練，用高頻演練來充分暴露問題、倒逼能力建設。
高頻也不是那麼容易做到的。
高頻需要基建保障。首先，高頻需要資源。高頻執行還會給基建的各個方面造成前所未有的壓力。高頻還需要能力水準達到一定的基準。就拿SRE的高頻演練來說吧。如果每次演練還有很多問題，那是不可能搞高頻的。能高頻做演練的前提是我們的隔離機制、恢複能力已經到一定的水準了。對于測試運作來說，高頻跑測試要收到效果，需要把隔離和用完即抛做好。
對于高頻跑測試，一個很常見的疑慮是：原來一天隻跑一次，失敗的用例我已經沒有時間一一排查了，現在高頻跑了，我豈不是更沒時間了？我的回答是：實際上，并不會這樣，因為開始高頻跑了以後，很快問題就會收斂的，是以總的需要排查的量可能是差不多的或者反而小了的。
三闆斧之二：隔離
相比起三闆斧裡的其他兩個（高頻、用完即抛），隔離的重要性應該是比較被廣為接受的。隔離的好處包括：
- 避免測試運作彼此影響，減少噪音。
- 提高效率，執行某些破壞性測試的時候不再需要互相協調
隔離無非是兩種：硬隔離、軟隔離。至于到底是走硬隔離路線，還是走軟隔離路線，要根據技術棧、架構、業務形态來具體分析。不過兩條道路都是能通往終局：
- 硬隔離（全隔離環境、實體隔離）要成為終态，關鍵是成本。要在不增加品質盲區的前提下壓縮成本。例如，如果能把整個支付系統都壓縮在一台伺服器裡面跑[2]，而且所有的功能（包括中間件層面的，例如定時任務、消息訂閱、分庫分表規則等）都能很好的覆寫，那是一個理想的終局。每個人都可以随時搞幾套全量環境，那是很爽的。另外，對架構的拆分解耦（例如，我們做的按域獨立釋出）是有助于降低硬隔離的成本的，可以把一整套被測系統部署的scope大大縮小。
- 軟隔離（半共享環境，邏輯隔離，鍊路級别隔離）要成為終局，關鍵是隔離的效果。如果隔離做到完美了，就能把今天的聯調環境部署到生産環境裡去跑。這樣，就不存在stable環境穩定性的問題了。這樣，做到了真正的testing in production，也是個很理想的終局狀态。
這兩種終局狀态，我在我以前的工作中都達到過。的确都能work的。這兩種隔離要通往終局，都是技術挑戰。壓縮成本是技術問題。邏輯隔離做徹底做牢靠也是技術問題。
對于我們今天的支付或電商系統來說，我們未來的終局是硬隔離還是軟隔離呢？現在還很難說。從技術可行性方面判斷，軟隔離更有可能成為我們的終局。硬隔離做到深水區以後就很難做了，因為會遇到架構的實體極限。突破架構的實體極限，有可能産生新的品質盲區。但相當長的一段時間裡，硬隔離會繼續對我們幫助很大。例如，我們要做各種非正常測試的時候，就需要硬隔離。軟隔離要做到能夠支援非正常測試，技術複雜度很高。從上個财年開始，我在我團隊搞一鍵拉全量測試環境（硬隔離）的原因就是：一鍵拉全量環境相對比較容易做，主要就是自動化，而基于路由的軟隔離方案一下子還不太ready，短期内達到我們需要的隔離水準還很難。
硬隔離和軟隔離也不是對立的，是可以一起用的。例如，我們在拉起基于路由的隔離環境的時候，拉會新的資料庫。在資料庫層面是一種硬隔離，是對資料庫層面軟隔離能力欠缺的一種補充。
總之，隔離是必須的。采取何種隔離方案，要階段性的基于複雜度、成本、效果等因素的綜合考量。
三闆斧之三：用完即抛
我最喜歡的另一句話是：Test environment is ephemeral。這句話是我原創的。Ephemeral的意思就是short-living，短暫的，短命的。我對我的QA團隊反複講這句話，希望同學們能在日常工作中時刻記得這個原則。
"Test environment is ephemeral"就意味着：
- 我們的test setup能力要很強。我們今天在搞的一鍵拉起環境，就是這種能力的一部分。而且setup起來以後，要能快速verify。
- 我們的test strategy、test plan、testability design和test automation，必須不依賴一個long living的測試環境。包括：不能依賴一個long living 的test environment裡面的一些老資料。例如，Test automation必須能自己造資料，造自己需要的所有的資料。
有了這些能力，能夠以零人力成本、非常快速且非常repeatable的從無到有建一套“開箱即用”的測試環境，能夠造出來測試需要的所有資料，我們就能做到測試環境的用完即抛：要跑測試了就建立一個環境，測試跑完了就把環境銷毀掉。下次要用再建一個新的。而且，不單單是測試環境，測試執行機也要用完即抛。
對于用完還需要保留一定時間的環境，也要設一個比較短的上限。例如，我以前采用過這樣的做法：
- 聯調測試環境預設生命周期是7天。
- 如果到時間還需要保留，可以延展有效期（expiration date）。每次展期最多可以展7天（相當于是 newExpDate = now + 7，而不是newExpDate = currentExpDate + 7）。
- 最多可以展期到30天（從createDate開始算），需要30天以上的，需要特批（比如，事業群CTO）。
- 這樣的好處就是倒逼。必須一刀切的倒逼，一開始會有點痛苦，但很快大家就會習慣的，自動化什麼的很快就跟上了。不這麼逼一逼，很多改進是不會發生的。
用完即抛的好處是：
- 解決環境腐化問題，減少髒資料
- 提高repeatability，確定每次測試運作的環境都是一緻的
- 倒逼各種優化和自動化能力的建設（測試環境的準備、造資料、等等）
- 提高資源使用的流動性。實際的實體資源不變的前提下，增加流動性就能增加實際容量。
測試環境用完即抛的确會引入一些新的品質風險。如果有一套長期維護的環境，裡面的資料是之前老版本的代碼生成的，部署了新版本代碼後，這些老資料是可以幫我們發現新代碼裡面的資料相容性問題的。現在用完即抛，沒有老資料了，這些資料相容性問題就可能無法發現。
這個風險的确是存在的。解決這個風向的思路是往前看，而不是往回退。我們要探索資料相容性問題是否有其他的解法。有沒有其他的測試或者品質保障手段。甚至要想一想，怎麼做到“從測到不測”，把資料相容性問題通過架構設計來消除掉，讓它不成為一個問題。
3. 落地
上面講的三闆斧，高頻、隔離、用完即抛，的确是有點理想主義的。我們今天的基建、架構、自動化建設，離理想狀态還有不少差距的。
但我們就是要有那麼一點的理想主義的。把這三闆斧做好，技術上的挑戰是非常非常大的，但我們有樂觀主義，相信我們能夠達到目标。我們有現實主義，我們可以分解目标，結合實際情況，一步步的去做。
文章來源：AlibabaTechQA
開發者社群整理