異常測試按性質分為應用層的業務邏輯異常測試、系統硬體/網路/檔案/資料庫/快取/中介軟體異常測試，其中包含了許多的場景（單機、分布式），但所有的場景均和這兩項有直接的關係。
業務邏輯異常測試體現在當上述的第二種異常發生時，是否能根據業務的需要或者架構的設計做出合理的業務處理反應，這是建立在第二種異常測試之上的，因此異常測試的關係也已經非常明確了，第一種測試根據業務的不同，範圍和流程有不確定性，第二種測試則是在一些明確的規則和約定下進行。
當架構演進到分布式，往往在測試過程中給人無從下手的錯覺，尤其在異常測試方面，其實不然，前面提到的單機和分布式看似是兩種型別，單獨看，單機的異常影響範圍可能會小一些，但事實上他們在分布式環境中會產生互相影響：
●分布式：分布式是乙個協同工作的應用環境，這種異常往往容易引起其他程序的掛起，或者資料庫、快取、中介軟體的問題，主要有網路呼叫所占用的資源、資料庫訪問等。
單機的異常如果處理不當，會引起整個環境中的資源不可用，從而導致環境中的每個單機都出現異常。根據上述的一些概念，可以列出異常測試中最重要的一些場景：
●系統資源：cpu、記憶體使用率過高，能否能將請求切到到資源利用率低的伺服器上；
●資料量大小和形式：資料到底應該注入多少滿足後續的壓力測試，各服務對資料格式的要求和轉換；
●檔案讀寫：
●本地寫：對同乙個檔案開啟的的數量過多，或者只開啟不關閉，導致檔案控制代碼數超過系統閾值；
●本地讀：開啟乙個不存在的檔案，是否有對應處理邏輯；
●網路儲存：服務不可用；
●應用連線：
●短連線：請求方未設定超時時間，長時間等待響應方的響應，從而導致請求的大量堆積，執行緒池的處理執行緒被用完，導致大量新的使用者請求被拒絕；
●長連線：在網路出現異常狀況後，斷開的連線是否能重新建立，請求方如拿到失效的連線，是否能處理異常；
●資料庫：
●資料來源切換：如果所切換的資料來源連線處於不可用狀態或宕機時，是否會長時間等待或重試；
●表鎖、行鎖：長時間更新操作，導致其他對此表的修改操作被掛起；
●快取：
●key的失效：在獲取不到key後，是否能正常處理；
●鎖的釋放：申請到鎖的一方如果意外重啟，是否能在重啟後釋放鎖；
●快取服務不可用；
●訊息中介軟體：
●訊息記錄表切換：是否丟失；
●清除訊息記錄：是否丟失記錄；
●服務發現：
●服務不可用：是否有其他處理措施；
●單台不可用：是否能重新選舉，重新建立連線；
●應用容器：
●連線數：配置優化；
●請求處理執行緒：配置優化；
●jvm堆疊大小：引數優化；
●前端靜態化頁面：
●後端服務不可用；
●快取不可用；
●資料庫中介軟體：
●資料訪問是否在錯誤發生後進行了正確的轉移；
●對於上層業務來說是否進行了正確的向下隔離。
精彩的內容要和朋友分享哦
Jmeter分布式測試
很多時候，我們測試時，如果進行大資料量的併發測試時，單個電腦的 和記憶體可能無法承受，這個時候，我們需要進行乙個分布式的測試，比如10000個併發，使用三颱電腦來進行併發 jmeter提供了這種功能，你可以很輕鬆的實現jmeter的這種分布式測試 1 首先確何所有的電腦上都安裝jmeter 2 在所...
Jmeter分布式測試
很多時候，我們測試時，如果進行大資料量的併發測試時，單個電腦的 和記憶體可能無法承受，這個時候，我們需要進行乙個分布式的測試，比如10000個併發，使用三颱電腦來進行併發 jmeter提供了這種功能，你可以很輕鬆的實現jmeter的這種分布式測試 1 首先確何所有的電腦上都安裝jmeter 2 在所...
Jmeter分布式測試
使用分布式主要是為了緩解單台機器模擬使用者的壓力，這時候可以使用多個agent 即 準備 主機以及 的計算機上必須安裝 jmeter和jdk，並配置好環境變數 注意 controller以及agent的jmeter和jdk版本盡量保持一致 步驟1.進入控制器controller也就是本機，例如本機的...