【tool】軟體測試中擷取負面測試的技術

標籤：des   io   ar   使用   sp   檔案   資料   on   art   

一個測試案例用於證明該需求已經滿足，通常稱作正面測試案例； ·另一個測試案例反映某個無法接受、反常或意外的條件或資料，用於論證只有在所需條件下才能夠滿足該需求，這個測試案例稱作負面測試案例。

1.負面測試的目的
負面測試在BS7925-1中的英國標準定義是採用Beizer的定義，其定義負面測試為“旨在說明 軟體不能工作的測試”（原文：Testing aimed at showing software does not work）。它可以帶出一系列補充性的和競爭性的目的。
•發現導致重大失效、崩潰、破壞和安全性漏洞的故障
•觀察和度量系統對外界問題的響應
•揭露軟體的弱點和開發的潛力
雖然有個一個公正的定義，但是它離被普遍接受還差的很遠。負面測試是一個緊跟著被重新定義的術語，有時甚至是各小組的。一個常見的方法，其實踐和英國標準定義不同的是它包括旨在使用專門對付失效的功能的測試。
• 輸入驗證，拒絕和重新請求的功能（人工輸入和外界系統）
• 內部資料驗證和拒絕
• 應付缺乏的，緩慢的或壞掉的外界資源
• 錯誤處理功能，例如訊息，日誌，監視功能
• 恢複功能，例如故障恢複，復原和恢複
 
2.擷取測試案例的技術
負面測試不是一種測試設計技術，說是一種方法或分類更加合適。使用許多正式的測試設計技術來擷取那些能夠被劃分為‘負面測試’的測試是很有可能。這一節詳述了各種各樣的知名技術的應用。
• 邊界值分析和等價類別劃分Boundary Value Analysis and Equivalence Class Partitioning
• 狀態轉換測試State Transition testing
• 逆著已知的約束測試Test against known constraints
• 故障模式和結果分析Failure Mode and Effects analysis
• 並發Concurrency
• 用例和誤用的用例Use cases and mis-use cases
 
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 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’。各種錯誤輸入的覆蓋，拒絕的迴圈和部分轉換通常是很稀少的。‘誤用的用例’術語，雖然不是偏僻的標準，但是能夠協助明確地識別和區分他們。執 行這些路徑地用例可以通過圖解期望結果正常範圍外的使用者的活動來協助提高設計，並且允許一個正式的方法來測試選擇和覆蓋 

【tool】軟體測試中擷取負面測試的技術