一、異常測試定義
在編寫**的過程中，程式設計師編寫的業務流程和邏輯通常按設計，設計的業務流程通常不會考慮**執行過程中異常處理，僅僅是業務流程中的異常處理會寫一些，設計比較細的系統設計可能會設計業務異常處理的流程要求，比較粗的基本上只寫正常的業務流程，不會設計異常流程，這種情況通常在**階段由編寫**的程式設計師來進行補充實現，所有業界有這樣的說法「軟體好不好，看異常處理的好不好」就是這個意思。
上面描述了兩種容易遺漏的情況，所有在進行測試的過程中，可以通過了解系統中的業務流程和**實現過程中易犯的錯誤，以此為異常測試的出發點來構建測試用例。
二、異常測試如何進行操作
有條件的情況下，可以看一看系統設計的文件，了解業務流程，仔細研究業務流程後可以發現還是有容易導致錯誤的地方，這些地方恰恰是異常測試的重點，可以將此整合到測試用例中。
**的瀏覽，在有的公司可能不好接觸到，有的話更好，可以直接看**，檢查漏洞。多數情況下，**看不到，測試只是進行黑盒測試，通過輸入和輸出來進行判斷執行是否正常，這種測試需要構建大量的測試用例才可以完整覆蓋，特別輸入和輸出比較負責的情況下，而異常測試則是薄弱環節的測試，測試工作小的多，但對整個系統的業務流程和大概的程式實現有比較多的經驗的人或團隊才可以找到這些點，需要的技術能力較高。
如測試個函式介面 int func(char * string1, char *string2)； 函式的功能是比較string1和string2字串有多少相同的字元組合，返回值是相同字元組合的個數，異常失敗返回-1；從測試異常的角度來進行應該如何處理，首先是指標型的資料要進行空指標檢查，另外返回值是否正確也要檢查，正常返回應該是大於等於0，而小於int 型極值，這就要求對string1 和string2的比對完的長度進行判斷，不要越界。根據這幾點在做測試用例就需要針對這幾個地方進行邊界條件測試，同樣是將邊界條件作為異常測試。
三、異常測試的好處
第一，快速找到系統和**中設計薄弱的地方，並加以測試；
第二，彌補程式設計師思維定式產生的**編寫中對異常處理的疏漏；
第三，降低測試的覆蓋的難度；
第四，對於難於進行自動化測試用例的專案，可以減輕發現bug的難度
webrtc QOS 丟包測試發現問題
或者 1 client1 client2 信令伺服器連線在乙個乙太網交換機上。保證client1與client2走p2p。2 在client2上使用network emulator client網損工具，配置固定丟包率為10 或者隨機丟包率為10 另外也說明，webrtc目前的機制，無法解決長時間 ...
軟體測試筆記（十九） 報告發現問題
了解如何報告軟體缺陷，如何整理出重現缺陷的必要步驟，如何描述缺陷是其它人可以理解並願意修改。一 設法修復軟體缺陷 不管計畫和執行測試多麼努力，並非所有軟體缺陷發現了都能修復。以下列舉了不修復軟體缺陷的原因 沒有足夠的時間。不算真正的軟體缺陷。修復的風險太大。不值得修復。無效的軟體缺陷修復報告。注意報...
效能監控命令 06 如何通過top發現問題？
在效能測試時，liunx作業系統，通過top命令來定位問題問題，第一行 顯示系統的執行資訊 系統當前時間，系統執行時間0min,當前登入使用者1個。系統平均負載，1分鐘 0.15 5分鐘 0.06 15分鐘 0.02 針對這行開始畫重點。load erage這個是數值是每隔5秒鐘檢查一次活躍的程序數...