獲取負面測試用例的技術(2)

　　這些測試可能不可能在沒有一個有效的測試工具或應用驅動下執行。這樣的工具通常是自定制的，并且可能需要在代碼的已提交版本里運行。

　　然而，象Canned HEAT和Holodeck (都出自the Florida Institute of Technology, [6])這樣的工具允許將普通性故障引入到運行在Windows的軟件中。

　　2.4.1. 故障家族

　　有很多來源可以幫助你開發故障模式的家族。既有故障的根本原因分析，系統設計文檔，基礎設施特有問題的知識能夠幫助識別故障模式，并且因此為獲取測試提供來源。

　　以下列表雖不詳盡，但或許可以幫助引發更多的關于可能的故障想法。

　　外部資源：反應遲鈍或緩慢的，莫明其妙或不恰當的反應。

　　協處理器故障：獨特的間斷處理器，多任務和遞歸

　　并發使用：資源鎖定，請求已拒絕的鎖定，死鎖，鎖定響應延遲

　　犧牲處理器Sacrificial processes：允許失敗的處理器并且用可控方式恢復

　　文件系統：文件不能被找到，打開，讀，寫，權限變更，文件系統識別介質錯誤，介質移除，介質裝滿

　　網絡：網絡中斷，網絡忙碌/緩慢，傳輸段丟失、損壞、無序，處理器之間的對話被中斷

　　內存：不足以給請求的分配，碎片

　　已達到的限制：排隊，licences，線程，連接，數組大小，資源分配

　　2.5. 并發

　　測試對資源的并發使用可以是一個非常富有成效的找bug方法。初始分析包括鑒別也許會嘗試同時使用的數據，數據庫條目，文件、連接和超過一個處理器的硬件。通過允許測試者在系統之前利用資源，簡單，定制的工具可能有些幫助, 并且在他們選擇的時候發布它。測試也應該檢查第二個請求者最終得到了資源。更加復雜的測試將著眼于二個以上的請求, 排隊, 超時和死鎖。

　　2.6. 用例和誤用的用例

　　用例，在實踐中趨向于處理系統的‘happy path’。各種錯誤輸入的覆蓋，拒絕的循環和部分轉換通常是很稀少的。‘誤用的用例’術語，雖然不是偏僻的標準，但是能夠幫助明確地識別和區分他們。執行這些路徑地用例可以通過圖解期望結果正常范圍外的用戶的活動來幫助提高設計，并且允許一個正式的方法來測試選擇和覆蓋.

原文轉自：http://www.kjueaiud.com