1. 場景描述
某郵件系統的黑盒測試。該系統主要由Java語言編寫，包含一個主進程、十個郵件發送子線程和完成其他功能的若干子線程。每個郵件發送線程均會定時輪詢內存緩存中的郵件隊列，若隊列不爲空，則從中讀取一條郵件數據，經過處理後調用郵件服務商的接口完成郵件的發送。
單條郵件數據由一個JSON字符串構成，該字符串包含了所有郵件發送需要的相關信息。郵件發送線程在處理郵件數據前必須先對JSON字符串進行解析才能獲取郵件數據的內容。
2. 問題說明
郵件發送線程存在一個缺陷：它沒有捕獲JSON字符串的解析錯誤。因此當郵件隊列中出現異常數據時（例如一個非JSON格式的字符串），處理這條數據的發送線程將拋出異常並自動退出。由於郵件系統並未建立監控和恢復子線程的機制，所以將導致的問題是：如果對系統的異常數據測試次數小於十次，儘管已有部分發送線程死亡，但是系統仍然能維持表層的正常工作，最終使得該缺陷難以被直接發現。
當然，我們可以採用最粗暴的方式，設計大量的異常數據對系統做連續性的破壞測試。但是此類測試存在問題：不能確定測試用例的數量。比如對於更大型的系統來說，它可能會啓動更多的線程來處理數據，我們沒法取得一個用例量值使得本次測試是100%可靠的，因此我們仍然有必要尋找一個能夠確定測試用例數量的方法。
3. 測試方法
在Linux環境下，進程的線程信息是可以被獲取的，因此可以通過觀察線程數來找到類似的問題。相關的命令如下：
pstree -p [pid]
pstree的功能是將所有進程以樹狀圖形式顯示，-p參數則用於指定要查看的進程號。所以可以先使用ps工具找到Java進程的進程號，再使用pstree工具列出此進程的所有線程信息，如下所示：
上圖的命令執行結果可能包含了我們在本次測試中不關心的線程，在此也可以使用另一個工具jstack配合grep命令來達到更進一步的目的，如下所示：
