越來越重要的破壞性測試

持續傳遞中涉及到的與測試相關的内容，包括了單元測試、自動化測試、冒煙測試等測試方法和理念，我為什麼我把破壞性測試拿出來，和你詳細讨論呢?

原因無非包括兩個方面:

其一，單元測試等傳統測試方法，已經非常成熟了，而且你肯定也非常熟悉了;

其二，破壞性測試，變得越來越重要了。

那麼，破壞性測試到底是因為什麼原因變得原來越重要呢?

随着SOA、微服務等架構的演進，分布式系統對測試的要求越來越高，不再像傳統的單體應用測試一樣，可以很容易地無縫嵌入到持續傳遞體系中。因為分布式系統的測試不僅需要大量的前提準備，還存在着非常嚴重的服務依賴問題。

這就使得分布式系統的測試工作，除了要關注運作的應用本身外，還要考慮測試環境的因素。

很快，我們就發現，破壞性測試可以解決分布式系統測試的這些難題，而且還可以幫助我們解決更多的問題。它可以彌補傳統持續傳遞體系隻關注代碼或應用本身，而忽略其他外部因素影響運作中代碼的問題。而且，破壞性測試還能很好地證明整個分布式系統的健壯性。

是以，與其老生長談一些傳統的測試方法，不如我們一起看看更新鮮、更好用的破壞性測試。

什麼是破壞性測試?

顧名思義，破壞性測試就是通過有效的測試手段，使軟體應用程式出現奔潰或失敗的情況，然後測試在這樣的情況下，軟體運作會産生什麼結果，而這些結果又是否符合預期。

這裡需要注意的是，我們需要使用的測試手段必須是有效的。為什麼這樣說呢，有兩點原因：

第一，破壞性測試的手段和過程，并不是無的放矢，它們是被嚴格設計和執行的。不要把破壞性測試和探索性測試混為一談。也就是說，破壞性測試不應該出現，“試試這樣會不會出問題”的假設，而且檢驗破壞性測試的結果也都應該是有預期的。

第二，破壞性測試，會産生切實的破壞作用，你需要權衡破壞的量和度。因為破壞不僅僅會破壞軟體，還可能會破壞硬體。通常情況下，軟體被破壞後的修複成本不會大大，而硬體部分被破壞後，修複成本就不好說了。是以，你必須要事先考慮好破壞的量和度。

破壞性測試的流程與用例設計

說到底，破壞性測試還是一種人為，事先設計的測試方法，是以它的流程與普通的軟體測試流程基本一緻:都包括設計測試用例，開發測試腳本，執行測試腳本，捕獲缺陷，報告缺陷的過程。

破壞性測試與普通測試流程，唯一不同的是，絕大部分普通測試可以在測試失敗後，繼續進行其他的測試:而破壞性測試，則有可能無法恢複到待測狀态，隻能停止後續的測試。

是以，在持續傳遞的哪個步驟和階段執行破壞性測試，就非常講究了，你需要經過嚴密地設計和預判。

是以，在設計破壞性測試的測試用例時，我們通常會考慮兩個次元:

第一個次元是，一個破壞點的具體測試，即設計一個或一組操作，能夠導緻應用或系統奔潰或異常。此時，你需要注意兩個問題:

1.出現問題後的系統或軟體是否有能力按預期捕獲和處理異常;

2.确認被破壞的系統是否有能力按照預期設計進行必要的修複，以確定能夠繼續處理後續内容。

第二個次元是，整個系統的破壞性測試，我們通常會采用壓力測試、暴力測試、阻斷鍊路去除外部依賴等方法，試圖找到需要進行破壞性測試的具體的點。

這兩個次元的測試方法、流程基本一緻，差別隻是第二次元的測試通常不知道具體要測試的點是以破壞範圍會更大，甚至可能破壞整個系統。

破壞性測試的執行政策

由于具有切實的破壞力這個特點，我們在執行破壞性測試時需要考慮好執行政策，以避免發生不可挽回的局面。

一般情況下，在釋出前執行破壞性測試相對比較安全。但這也不是絕對的，比如你一不小心把 UAT等大型聯調環境搞壞了，其代價還是很可觀的。

是以，絕大部分破壞性測試都會在單元測試、功能測試階段執行。而執行測試的環境也往往是局部的測試子環境。

那麼問題又來了，真實環境要比測試子環境更複雜多變，在測試子環境進行的破壞性測試真的有效嗎?這真是一個極好的問題。

是以，最近幾年，技術圈衍生出一個很流行的理論:混沌工程。

混沌工程

随着分布式系統架構的不斷進步，傳統的破壞性測試也越發捉襟見肘，最主要的問題有兩個:

第一，它被設計得太嚴格，以至于失真了。而真正有破壞力的故障，都是随機的、并行的、胡亂的。

第二，它覆寫不了生産環境，隻能做到類似抽樣檢驗的能力，且很難重複和持續。

是以，混沌工程的理論就應運而生了。

混沌工程是在分布式系統上建立的實驗，其目的是建立對系統承受混亂沖擊能力的信心。鑒于分布式系統固有的混亂屬性，也就是說即使所有的部件都可以正常工作，但把它們結合後，你還是很難預知會發生什麼。

是以，我們需要找出分布式系統的這些弱點。我把這些弱點歸為了以下幾類:

當服務不可用時，不可用或不完整的回退能力;

不合理的設定逾時時間引起的重試風暴;

依賴服務接收過多的流量，進而導緻中斷;

由單個故障點引起的級聯故障;

我們要避免這些弱點在生産過程中影響客戶，是以需要一種方法來探知和管理這些系統固有的混亂，經實踐證明，通過一些受控實驗，我們能夠觀察這些弱點在系統中的行為。這種實驗方法，就被叫作混沌工程。

說到具體的實驗方法，需要遵循以下4個步驟，即科學實驗都必須遵循的4個步驟:

1.将正常系統的一些正常行為的可測量資料定義為“穩定态”;

2.建立一個對照組，并假設對照組和實驗組都保持“穩定态”

3.引入真實世界的變量，如伺服器崩潰、斷網、磁盤損壞等等;

4.嘗試尋找對照組和實驗組之間的差異，找出系統弱點。

“穩定态”越難被破壞，則說明系統越穩固:而發現的每一個弱點，則都是一個改進目标，

混沌工程也有幾個進階原則:

1.使用改變現實世界的事件，就是要在真實的場景中進行實驗，而不要想象和構造一些假想和假設的場景;

2.在生産環境運作，為了發現真實場景的弱點，是以更建議在生産環境運作這些實驗;

3自動化連續實作，人工的手工操作是勞動密集型的，不可持續的，是以要把混沌工程自動化建構到系統中;

4最小爆破半徑，與第二條配合，要盡量減少對使用者的負面影響，即使不可避免，也要盡力減少範圍和程度。

這樣，就更符合持續傳遞的需求和胃口了。

Netflix公司的先驅實踐

Netflix為了保證其系統在AWS上的健壯性，創造了ChaosMonkey，可以說是混沌工程真正的先驅者。

Chaos Monkey會在工作日期間，随機地殺死一些服務以制造混亂，進而檢驗系統的穩定性。

而工程師們不得不停下手頭工作去解決這些問題，并目保證它們不會再現，久而久之，系統的健壯性就可以不斷地被提高。

總結