2.3. 逆著已知的約束測試
大多數的系統有明確的和含蓄的限制和約束。如同需求一樣對待這些約束（參加Robinson+Robinson, [5])）就可以得到各種負面測試。例如：
• “The site is designed to be viewed with Internet Explorer 4.5 or later” – 負面測試可以使用IE3.0或Netscape.
• “No more than five users will use the system at the same time” –負面測試可以嘗試6個，然后8。
概括來說，測試包括度量和觀察系統的行為勝于直接逆著期望結果測試。這只能在系統的操作參數之外工作時被使用，并且這種觀察可能導致對系統的進一步了解。
2.4. 故障模式和結果分析
從對潛在的技術，實現和已知故障的分析來預見系統特有的故障是很有可能的。這種分析是觀察在故障條件下系統行為的測試基礎。捕獲和文檔化這種信息是非常重要的－特別是如果他們允許診斷數據和環境。對于那些監視他們系統并且擁有在系統被使用時（例如銀行，電話公司）可以采取行動的技術專家的組織而言，這些文檔通常是測試的必要輸出。 另一方面，對于更廣泛的分布式軟件包來說，這些信息也可以成為FAQ或故障診斷指南的一部分。
這些測試可能不可能在沒有一個有效的測試工具或應用驅動下執行。這樣的工具通常是自定制的，并且可能需要在代碼的已提交版本里運行。
然而，象Canned HEAT和Holodeck (都出自the Florida Institute of Technology, [6])這樣的工具允許將普通性故障引入到運行在Windows的軟件中。
6.4.1. 故障家族
有很多來源可以幫助你開發故障模式的家族。既有故障的根本原因分析，系統設計文檔，基礎設施特有問題的知識能夠幫助識別故障模式，并且因此為獲取測試提供來源。
以下列表雖不詳盡，但或許可以幫助引發更多的關于可能的故障想法。
• 外部資源：反應遲鈍或緩慢的，莫明其妙或不恰當的反應。
• 協處理器故障：獨特的間斷處理器，多任務和遞歸
• 并發使用：資源鎖定，請求已拒絕的鎖定，死鎖，鎖定響應延遲
• 犧牲處理器Sacrificial processes：允許失敗的處理器并且用可控方式恢復
• 文件系統：文件不能被找到，打開，讀，寫，權限變更，文件系統識別介質錯誤，介質移除，介質裝滿
• 網絡：網絡中斷，網絡忙碌/緩慢，傳輸段丟失、損壞、無序，處理器之間的對話被中斷
• 內存：不足以給請求的分配，碎片
• 已達到的限制：排隊，licences，線程，連接，數組大小，資源分配
2.5. 并發
測試對資源的并發使用可以是一個非常富有成效的找bug方法。初始分析包括鑒別也許會嘗試同時使用的數據，數據庫條目，文件、連接和超過一個處理器的硬件。通過允許測試者在系統之前利用資源，簡單，定制的工具可能有些幫助, 并且在他們選擇的時候發布它。測試也應該檢查第二個請求者最終得到了資源。更加復雜的測試將著眼于二個以上的請求, 排隊, 超時和死鎖。
2.6. 用例和誤用的用例
用例，在實踐中趨向于處理系統的‘happy path’。各種錯誤輸入的覆蓋，拒絕的循環和部分轉換通常是很稀少的�！`用的用例’術語，雖然不是偏僻的標準，但是能夠幫助明確地識別和區分他們。執行這些路徑地用例可以通過圖解期望結果正常范圍外的用戶的活動來幫助提高設計，并且允許一個正式的方法來測試選擇和覆蓋．
文章來源于領測軟件測試網 http://www.k11sc111.com/
