獲取負面javascript.:tagshow(event, '%B2%E2%CA%D4%D3%C3%C0%FD');" href="javascript.:;" target=_self>測試用例的技術
http://www.51testing.com/?action_viewnews_itemid_71451.html(轉自)
1.負面測試的目的
負面測試在BS7925-1中的英國標準定義是采用Beizer的定義，其定義負面測試為“旨在說明軟件不能工作的測試”（原文：Testing aimed at showing software does not work）。它可以帶出一系列補充性的和競爭性的目的。
發現導致重大失效、崩潰、破壞和安全漏洞的故障
觀察和度量系統對外界問題的響應
揭露軟件的弱點和開發的潛力
雖然有個一個公正的定義，但是它離被普遍接受還差的很遠。負面測試是一個緊跟著被重新定義的術語，有時甚至是各小組的。一個常見的方法，其實踐和英國標準定義不同的是它包括旨在使用專門對付失效的功能的測試。
輸入驗證，拒絕和重新請求的功能（人工輸入和外界系統）
內部數據驗證和拒絕
應付缺乏的，緩慢的或壞掉的外界資源
錯誤處理功能，例如消息，日志，監視功能
恢復功能，例如故障恢復，回滾和恢復
2.獲取測試用例的技術
負面測試不是一種測試設計技術，說是一種方法或分類更加合適。使用許多正式的測試設計技術來獲取那些能夠被劃分為‘負面測試’的測試是很有可能。這一節詳述了各種各樣的知名技術的應用。
邊界值分析和等價類劃分Boundary Value Analysis and Equivalence Class Partitioning
狀態轉換測試State Transitiontesting
逆著已知的約束測試Test against known constraints
故障模式和結果分析Failure Mode and Effects analysis
并發Concurrency
用例和誤用的用例Use cases and mis-usecases
2.1.邊界值分析和等價類劃分
有兩種基于輸入和輸出數據和系統行為期望的技術。
邊界值分析（BVA：Boundary Value Analysis）利用關于預知系統行為轉換位置的邊界的需求和設計來檢查那些能夠帶出一連貫范圍數值的數據元素。
這個方法用于產生三個數值－一個就是邊界本身，另外兩個在前者的兩邊（盡可能的和數字相接近）。如果邊界在有效和無效范圍之間，使用無效數值的測試用例將成為一個負面測試用例。例如，使用66在只接受從18～65數值的年齡字段。
等價類劃分（ECP：Equivalence Class Partitioning）著眼于邊界之間的范圍。給出的等價類中的每個成員應該在一個已知測試的環境里，使系統做同樣的事情－這樣測試員不必要測試在等價類中每一個數值。無效輸入數據的范圍可以被看成為負面測試－例如，一個年齡字段可能被期望用相同的方法拒絕所有的負數。
ECP一般被延伸到包括非連續數值的集合，勝于連續的數值范圍。要注意一些輸入可能看上去等價，但是實際上出現很多不同的行為。例如，一個簡單web的表單的輸入是為空或者太長時可能會被拒絕，但是控制字符的正確組合可能危害潛在web服務器的安全。
2.2.狀態轉換測試
假設有一個狀態轉換圖或者一個與其等價的理解，那么就很容易獲得可以明確地檢查不可到達的狀態是否真的不可到達的測試用例。與這種方法相同的變種稱為n-switch測試，在一套已知的轉換之后，那些不可到達的狀態仍然是不可到達嗎？圖形工具，例如Compendium-TA[4]能夠幫助你獲得這樣的測試。
2.3.逆著已知的約束測試
大多數的系統有明確的和含蓄的限制和約束。如同需求一樣對待這些約束（參加Robinson+Robinson,[5])）就可以得到各種負面測試。例如：
“The site is designed to be viewed with Internet Explorer4.5 or later”–負面測試可以使用IE3.0或Netscape.
“No more than five users will use the system at the same time”–負面測試可以嘗試6個，然后8。
概括來說，測試包括度量和觀察系統的行為勝于直接逆著期望結果測試。這只能在系統的操作參數之外工作時被使用，并且這種觀察可能導致對系統的進一步了解。
2.4.故障模式和結果分析
從對潛在的技術，實現和已知故障的分析來預見系統特有的故障是很有可能的。這種分析是觀察在故障條件下系統行為的測試基礎。捕獲和文檔化這種信息是非常重要的－特別是如果他們允許診斷數據和環境。對于那些監視他們系統并且擁有在系統被使用時（例如銀行，電話公司）可以采取行動的技術專家的組織而言，這些文檔通常是測試的必要輸出。另一方面，對于更廣泛的分布式軟件包來說，這些信息也可以成為FAQ或故障診斷指南的一部分。
這些測試可能不可能在沒有一個有效的測試工具或應用驅動下執行。這樣的工具通常是自定制的，并且可能需要在代碼的已提交版本里運行。
然而，象CannedHEAT和Holodeck(都出自the Florida Institute of Technology,[6])這樣的工具允許將普通性故障引入到運行在Windows');" href="javascript.:;" target=_self>Windows的軟件中。
6.4.1.故障家族
有很多來源可以幫助你開發故障模式的家族。既有故障的根本原因分析，系統設計文檔，基礎設施特有問題的知識能夠幫助識別故障模式，并且因此為獲取測試提供來源。
以下列表雖不詳盡，但或許可以幫助引發更多的關于可能的故障想法。
外部資源：反應遲鈍或緩慢的，莫明其妙或不恰當的反應。
協處理器故障：獨特的間斷處理器，多任務和遞歸
并發使用：資源鎖定，請求已拒絕的鎖定，死鎖，鎖定響應延遲
犧牲處理器Sacrificialprocesses：允許失敗的處理器并且用可控方式恢復
文件系統：文件不能被找到，打開，讀，寫，權限變更，文件系統識別介質錯誤，介質移除，介質裝滿
網絡：網絡中斷，網絡忙碌/緩慢，傳輸段丟失、損壞、無序，處理器之間的對話被中斷
內存：不足以給請求的分配，碎片
已達到的限制：排隊，licences，線程，連接，數組大小，資源分配
2.5.并發
測試對資源的并發使用可以是一個非常富有成效的找bug方法。初始分析包括鑒別也許會嘗試同時使用的數據，數據庫條目，文件、連接和超過一個處理器的硬件。通過允許測試者在系統之前利用資源，簡單，定制的工具可能有些幫助,并且在他們選擇的時候發布它。測試也應該檢查第二個請求者最終得到了資源。更加復雜的測試將著眼于二個以上的請求,排隊,超時和死鎖。
2.6.用例和誤用的用例
用例，在實踐中趨向于處理系統的‘happypath’。各種錯誤輸入的覆蓋，拒絕的循環和部分轉換通常是很稀少的�！`用的用例’術語，雖然不是偏僻的標準，但是能夠幫助明確地識別和區分他們。執行這些路徑地用例可以通過圖解期望結果正常范圍外的用戶的活動來幫助提高設計，并且允許一個正式的方法來測試選擇和覆蓋．
