阿里研究員：測試穩定性三板斧，我怎麼用？

阿里妹導讀：如何治理測試穩定性問題？不少人會說：環境、流程管控、監控、工具化、加機器、專人負責、等等。這些都是對的。不過這些都是解決方案層面的，而不是方法論和理論體系層面的。今天，阿里研究員鄭子穎來講說測試穩定性的三板斧。聽說，阿里同窗們都很是認同這三板斧，看完文章感受不少作的事情有了理論基礎。

鄭子穎：阿里巴巴研究員，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"就意味着：

1. 咱們的test setup能力要很強。咱們今天在搞的一鍵拉起環境，就是這種能力的一部分。並且setup起來之後，要能快速verify。
2. 咱們的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. 落地

上面講的三板斧，高頻、隔離、用完即拋，的確是有點理想主義的。咱們今天的基建、架構、自動化建設，離理想狀態還有很多差距的。

但咱們就是要有那麼一點的理想主義的。把這三板斧作好，技術上的挑戰是很是很是大的，但咱們有樂觀主義，相信咱們可以達到目標。咱們有現實主義，咱們能夠分解目標，結合實際狀況，一步步的去作。

Note：
[1] 這裏的用例主要指的是功能性的測試用例，包括：unit test、單系統的接口測試、全鏈路/端到端的測試，等等。
[2] 這樣子作，實操層面的一個可能的負面影響是它可能會discourage微服務化治理（包括，域自治性，獨立測試、獨立發佈能力等）。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。