軟件測試中獲取負面測試用例的技術(shù)
測試用例（Test Case）是為某個(gè)特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個(gè)程序路徑或核實(shí)是否滿(mǎn)足某個(gè)特定需求。
測試用例（Test Case）目前沒(méi)有經(jīng)典的定義。比較通常的說(shuō)法是：指對一項特定的軟件產(chǎn)品進(jìn)行測試任務(wù)的描述，體現測試方案、方法、技術(shù)和策略。內容包括測試目標、測試環(huán)境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。
不同類(lèi)別的軟件，測試用例是不同的。不同于諸如系統、工具、控制、游戲軟件，管理軟件的用戶(hù)需求更加不統一，變化更大、更快。筆者主要從事企業(yè)管理軟件的測試。因此我們的做法是把測試數據和測試腳本從測試用例中劃分出來(lái)。測試用例更趨于是針對軟件產(chǎn)品的功能、業(yè)務(wù)規則和業(yè)務(wù)處理所設計的測試方案。對軟件的每個(gè)特定功能或運行操作路徑的測試構成了一個(gè)個(gè)測試用例。
隨著(zhù)中國軟件業(yè)的日益壯大和逐步走向成熟，軟件測試也在不斷發(fā)展。從最初的由軟件編程人員兼職測試到軟件公司組建獨立專(zhuān)職測試部門(mén)。測試工作也從簡(jiǎn)單測試演變?yōu)榘ǎ壕幹?FONT color=#136ec2>測試計劃、編寫(xiě)測試用例、準備測試數據、編寫(xiě)測試腳本、實(shí)施測試、測試評估等多項內容的正規測試。測試方式則由單純手工測試發(fā)展為手工、自動(dòng)兼之，并有向第三方專(zhuān)業(yè)測試公司發(fā)展的趨勢。
要使最終用戶(hù)對軟件感到滿(mǎn)意,最有力的舉措就是對最終用戶(hù)的期望加以明確闡述，以便對這些期望進(jìn)行核實(shí)并確認其有效性。測試用例反映了要核實(shí)的需求。然而，核實(shí)這些需求可能通過(guò)不同的方式并由不同的測試員來(lái)實(shí)施。例如，執行軟件以便驗證它的功能和性能，這項操作可能由某個(gè)測試員采用自動(dòng)測試技術(shù)來(lái)實(shí)現；計算機系統的關(guān)機步驟可通過(guò)手工測試和觀(guān)察來(lái)完成；不過(guò)，市場(chǎng)占有率和銷(xiāo)售數據（以及產(chǎn)品需求），只能通過(guò)評測產(chǎn)品和競爭銷(xiāo)售數據來(lái)完成。
既然可能無(wú)法（或不必負責）核實(shí)所有的需求，那么是否能為測試挑選最適合或最關(guān)鍵的需求則關(guān)系到項目的成敗。選中要核實(shí)的需求將是對成本、風(fēng)險和對該需求進(jìn)行核實(shí)的必要性這三者權衡考慮的結果。
確定測試用例之所以很重要，原因有以下幾方面。
測試用例構成了設計和制定測試過(guò)程的基礎。 測試的“深度”與測試用例的數量成比例。由于每個(gè)測試用例反映不同的場(chǎng)景、條件或經(jīng)由產(chǎn)品的事件流，因而，隨著(zhù)測試用例數量的增加，您對產(chǎn)品質(zhì)量和測試流程也就越有信心。 判斷測試是否完全的一個(gè)主要評測方法是基于需求的覆蓋，而這又是以確定、實(shí)施和/或執行的測試用例的數量為依據的。類(lèi)似下面這樣的說(shuō)明：“95 % 的關(guān)鍵測試用例已得以執行和驗證”，遠比“我們已完成 95 % 的測試”更有意義。 測試工作量與測試用例的數量成比例。根據全面且細化的測試用例，可以更準確地估計測試周期各連續階段的時(shí)間安排。 測試設計和開(kāi)發(fā)的類(lèi)型以及所需的資源主要都受控于測試用例。 測試用例通常根據它們所關(guān)聯(lián)關(guān)系的測試類(lèi)型或測試需求來(lái)分類(lèi)，而且將隨類(lèi)型和需求進(jìn)行相應地改變。最佳方案是為每個(gè)測試需求至少編制兩個(gè)測試用例：
·一個(gè)測試用例用于證明該需求已經(jīng)滿(mǎn)足，通常稱(chēng)作正面測試用例； ·另一個(gè)測試用例反映某個(gè)無(wú)法接受、反�；蛞馔獾臈l件或數據，用于論證只有在所需條件下才能夠滿(mǎn)足該需求，這個(gè)測試用例稱(chēng)作負面測試用例。
1. 負面測試的目的
負面測試在BS7925-1中的英國標準定義是采用Beizer的定義，其定義負面測試為“旨在說(shuō)明軟件不能工作的測試”（原文：Testing aimed at showing software does not work）。它可以帶出一系列補充性的和競爭性的目的。
•發(fā)現導致重大失效、崩潰、破壞和安全漏洞的故障
•觀(guān)察和度量系統對外界問(wèn)題的響應
•揭露軟件的弱點(diǎn)和開(kāi)發(fā)的潛力
雖然有個(gè)一個(gè)公正的定義，但是它離被普遍接受還差的很遠。負面測試是一個(gè)緊跟著(zhù)被重新定義的術(shù)語(yǔ)，有時(shí)甚至是各小組的。一個(gè)常見(jiàn)的方法，其實(shí)踐和英國標準定義不同的是它包括旨在使用專(zhuān)門(mén)對付失效的功能的測試。
• 輸入驗證，拒絕和重新請求的功能（人工輸入和外界系統）
• 內部數據驗證和拒絕
• 應付缺乏的，緩慢的或壞掉的外界資源
• 錯誤處理功能，例如消息，日志，監視功能
• 恢復功能，例如故障恢復，回滾和恢復
2. 獲取測試用例的技術(shù)
負面測試不是一種測試設計技術(shù)，說(shuō)是一種方法或分類(lèi)更加合適。使用許多正式的測試設計技術(shù)來(lái)獲取那些能夠被劃分為‘負面測試’的測試是很有可能。這一節詳述了各種各樣的知名技術(shù)的應用。
• 邊界值分析和等價(jià)類(lèi)劃分Boundary Value Analysis and Equivalence Class Partitioning
• 狀態(tài)轉換測試State Transition testing
• 逆著(zhù)已知的約束測試Test against known constraints
• 故障模式和結果分析Failure Mode and Effects analysis
• 并發(fā)Concurrency
• 用例和誤用的用例Use cases and mis-use cases
2.1. 邊界值分析和等價(jià)類(lèi)劃分
有兩種基于輸入和輸出數據和系統行為期望的技術(shù)。
邊界值分析（BVA：Boundary Value Analysis）利用關(guān)于預知系統行為轉換位置的邊界的需求和設計來(lái)檢查那些能夠帶出一連貫范圍數值的數據元素。
這個(gè)方法用于產(chǎn)生三個(gè)數值－一個(gè)就是邊界本身，另外兩個(gè)在前者的兩邊（盡可能的和數字相接近）。如果邊界在有效和無(wú)效范圍之間，使用無(wú)效數值的測試用例將成為一個(gè)負面測試用例。例如，使用66在只接受從18～65數值的年齡字段。
等價(jià)類(lèi)劃分（ECP：Equivalence Class Partitioning）著(zhù)眼于邊界之間的范圍。給出的等價(jià)類(lèi)中的每個(gè)成員應該在一個(gè)已知測試的環(huán)境里，使系統做同樣的事情－這樣測試員不必要測試在等價(jià)類(lèi)中每一個(gè)數值。無(wú)效輸入數據的范圍可以被看成為負面測試－例如，一個(gè)年齡字段可能被期望用相同的方法拒絕所有的負數。
ECP一般被延伸到包括非連續數值的集合，勝于連續的數值范圍。要注意一些輸入可能看上去等價(jià)，但是實(shí)際上出現很多不同的行為。例如，一個(gè)簡(jiǎn)單web的表單的輸入是為空或者太長(cháng)時(shí)可能會(huì )被拒絕，但是控制字符的正確組合可能危害潛在web服務(wù)器的安全。
2.2. 狀態(tài)轉換測試
假設有一個(gè)狀態(tài)轉換圖或者一個(gè)與其等價(jià)的理解，那么就很容易獲得可以明確地檢查不可到達的狀態(tài)是否真的不可到達的測試用例。與這種方法相同的變種稱(chēng)為n-switch 測試，在一套已知的轉換之后，那些不可到達的狀態(tài)仍然是不可到達嗎？圖形工具，例如Compendium-TA [4]能夠幫助你獲得這樣的測試。
2.3. 逆著(zhù)已知的約束測試
大多數的系統有明確的和含蓄的限制和約束。如同需求一樣對待這些約束（參加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個(gè)，然后8。
概括來(lái)說(shuō)，測試包括度量和觀(guān)察系統的行為勝于直接逆著(zhù)期望結果測試。這只能在系統的操作參數之外工作時(shí)被使用，并且這種觀(guān)察可能導致對系統的進(jìn)一步了解。
2.4. 故障模式和結果分析
從對潛在的技術(shù)，實(shí)現和已知故障的分析來(lái)預見(jiàn)系統特有的故障是很有可能的。這種分析是觀(guān)察在故障條件下系統行為的測試基礎。捕獲和文檔化這種信息是非常重要的－特別是如果他們允許診斷數據和環(huán)境。對于那些監視他們系統并且擁有在系統被使用時(shí)（例如銀行，電話(huà)公司）可以采取行動(dòng)的技術(shù)專(zhuān)家的組織而言，這些文檔通常是測試的必要輸出。 另一方面，對于更廣泛的分布式軟件包來(lái)說(shuō)，這些信息也可以成為FAQ或故障診斷指南的一部分。
這些測試可能不可能在沒(méi)有一個(gè)有效的測試工具或應用驅動(dòng)下執行。這樣的工具通常是自定制的，并且可能需要在代碼的已提交版本里運行。
然而，象Canned HEAT和Holodeck (都出自the Florida Institute of Technology, [6])這樣的工具允許將普通性故障引入到運行在Windows的軟件中。
6.4.1. 故障家族
有很多來(lái)源可以幫助你開(kāi)發(fā)故障模式的家族。既有故障的根本原因分析，系統設計文檔，基礎設施特有問(wèn)題的知識能夠幫助識別故障模式，并且因此為獲取測試提供來(lái)源。
以下列表雖不詳盡，但或許可以幫助引發(fā)更多的關(guān)于可能的故障想法。
• 外部資源：反應遲鈍或緩慢的，莫明其妙或不恰當的反應。
• 協(xié)處理器故障：獨特的間斷處理器，多任務(wù)和遞歸
• 并發(fā)使用：資源鎖定，請求已拒絕的鎖定，死鎖，鎖定響應延遲
• 犧牲處理器Sacrificial processes：允許失敗的處理器并且用可控方式恢復
• 文件系統：文件不能被找到，打開(kāi)，讀，寫(xiě)，權限變更，文件系統識別介質(zhì)錯誤，介質(zhì)移除，介質(zhì)裝滿(mǎn)
• 網(wǎng)絡(luò )：網(wǎng)絡(luò )中斷，網(wǎng)絡(luò )忙碌/緩慢，傳輸段丟失、損壞、無(wú)序，處理器之間的對話(huà)被中斷
• 內存：不足以給請求的分配，碎片
• 已達到的限制：排隊，licences，線(xiàn)程，連接，數組大小，資源分配
2.5. 并發(fā)
測試對資源的并發(fā)使用可以是一個(gè)非常富有成效的找bug方法。初始分析包括鑒別也許會(huì )嘗試同時(shí)使用的數據，數據庫條目，文件、連接和超過(guò)一個(gè)處理器的硬件。通過(guò)允許測試者在系統之前利用資源，簡(jiǎn)單，定制的工具可能有些幫助, 并且在他們選擇的時(shí)候發(fā)布它。測試也應該檢查第二個(gè)請求者最終得到了資源。更加復雜的測試將著(zhù)眼于二個(gè)以上的請求, 排隊, 超時(shí)和死鎖。
2.6. 用例和誤用的用例
用例，在實(shí)踐中趨向于處理系統的‘happy path’。各種錯誤輸入的覆蓋，拒絕的循環(huán)和部分轉換通常是很稀少的�！`用的用例’術(shù)語(yǔ)，雖然不是偏僻的標準，但是能夠幫助明確地識別和區分他們。執行這些路徑地用例可以通過(guò)圖解期望結果正常范圍外的用戶(hù)的活動(dòng)來(lái)幫助提高設計，并且允許一個(gè)正式的方法來(lái)測試選擇和覆蓋
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
