在分散式系統中，軟體測試工程師如何測試你不知道的東西？

在最簡單的C/S模型當中，一次網路通訊會發生這樣的過程： 加我VX：atstudy-js 回覆“測試”，進入 自動化測試學習交流群~~

1.客戶端將訊息傳送到網路上。

2.網路向伺服器傳送訊息。

3.伺服器驗證訊息。

4.如果需要，伺服器更新其狀態。

5.伺服器將回復傳送到網路上。

6.網路向客戶端傳送回覆。

7.客戶端驗證回覆。

8.如果需要，客戶端更新其狀態。

但隨著分散式系統變得越來越複雜，測試已經達到極限。它通常無法解決生產環境的複雜性，例如發生在網路上的隨機故障和其他奇怪的間歇性錯誤；配置限制和配置漂移；未知的呢？你怎麼能測試你不知道的東西？

例如，在例項動態啟動和停止的系統中，如果任何例項磁碟空間不足會發生什麼情況？如果一個例項沒有剩餘空間來寫入日誌，它在大多數情況下會快速失敗，這是一個真正的問題，因為快速失敗會產生一個黑洞。因為它失敗得很快，通常會欺騙負載均衡器，認為該例項可以自由地接收更多請求，而這反過來也會導致更多的失敗。

如果我們能更早地發現這一點，我們就可以事先進行改進並避免中斷。例如：

1 — 使用日誌輪換。

2 — 使用集中式日誌服務。

3 — 監控磁碟空間。

4 — 在每週運營會議上審查指標。

5 — 當裝置上只剩下 10% 的磁碟空間時發出一些警報。

幸運的是，有一種實踐可以幫助解決這種未知數——正如你可能猜到的，混沌工程。

混沌工程是一個過程：

1、通過建立破壞性事件（例如伺服器中斷或 API 限制）來對測試或生產環境中的應用程式施加壓力。

2、觀察系統如何響應。

3、實施改進。

我們這樣做是為了證明或反駁我們對系統處理這些破壞性事件的能力的假設。與其讓這些破壞性事件發生在凌晨 1 點、週末和生產環境中，我們不如在受控環境中在工作時間建立它們。混沌工程不是無目的地隨機注入故障而是通過精心計劃的實驗在受控環境中注入故障，以建立對應用程式和工具的信心，以承受動盪的條件。

雖然混沌工程是一個很好的選擇，但事實是它很難開始，因為在大多數情況下，你必須將不同的工具、指令碼和庫拼接在一起，以涵蓋可以在系統中注入的所有故障。基礎設施、網路、應用程式——每個目標都有不同的工作工具，無論是庫、代理還是要安裝的容器。客戶通常不想在他們的應用程式中安裝任何額外的東西——要安裝的東西越多，就越複雜。或者，如果必須安裝東西，它們需要集中管理和統一。

為此我們選擇將 ChaosBlade 封裝成一個統一的網頁工具，選擇 ChaosBlade 的原因是它支援目前主流的故障注入場景，相對其他幾個故障注入工具，ChaosBlade 故障注入覆蓋的場景最全，支援四大類、幾十種常用的故障注入能力。

該網頁工具的執行方式是提供一個對於使用者非常友好的介面，注入故障時只需要點選相應故障的按鈕，該故障會以 HTTP 請求的方式傳送到測試環境的 ChasosBlade 中，ChaosBlade 以命令列的方式來執行具體的故障注入請求，同時將返回執行的結果。

由於作者版權要求，僅展示文章的一部分，如需閱讀完整版文章，可以私信下方V獲取。

最後：

可以我的個人V：atstudy-js，可以免費領取一份10G軟體測試工程師面試寶典文件資料。以及相對應的視訊學習教程免費分享！，其中包括了有基礎知識、Linux必備、Mysql資料庫、抓包工具、介面測試工具、測試進階-Python程式設計、Web自動化測試、APP自動化測試、介面自動化測試、測試高階持續整合、測試架構開發測試框架、效能測試等。

這些測試資料，對於做【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！