軟件測試中測試用例基本概念

軟件測試中測試用例基本概念
測試用例（Test Case）是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。 　　測試用例（Test Case）目前沒有經典的定義。比較通常的說法是：指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。 　　不同類別的軟件，測試用例是不同的。不同于諸如系統、工具、控制、游戲軟件，管理軟件的用戶需求更加不統一，變化更大、更快。筆者主要從事企業管理軟件的測試。因此我們的做法是把測試數據和測試腳本從測試用例中劃分出來。測試用例更趨于是針對軟件產品的功能、業務規則和業務處理所設計的測試方案。對軟件的每個特定功能或運行操作路徑的測試構成了一個個測試用例。 　　隨著中國軟件業的日益壯大和逐步走向成熟，軟件測試也在不斷發展。從最初的由軟件編程人員兼職測試到軟件公司組建獨立專職測試部門。測試工作也從簡單測試演變為包括：編制測試計劃、編寫測試用例、準備測試數據、編寫測試腳本、實施測試、測試評估等多項內容的正規測試。測試方式則由單純手工測試發展為手工、自動兼之，并有向第三方專業測試公司發展的趨勢。 　　要使最終用戶對軟件感到滿意,最有力的舉措就是對最終用戶的期望加以明確闡述，以便對這些期望進行核實并確認其有效性。測試用例反映了要核實的需求。然而，核實這些需求可能通過不同的方式并由不同的測試員來實施。例如，執行軟件以便驗證它的功能和性能，這項操作可能由某個測試員采用自動測試技術來實現；計算機系統的關機步驟可通過手工測試和觀察來完成；不過，市場占有率和銷售數據（以及產品需求），只能通過評測產品和競爭銷售數據來完成。 　　既然可能無法（或不必負責）核實所有的需求，那么是否能為測試挑選最適合或最關鍵的需求則關系到項目的成敗。選中要核實的需求將是對成本、風險和對該需求進行核實的必要性這三者權衡考慮的結果。 　　確定測試用例之所以很重要，原因有以下幾方面。 　　測試用例構成了設計和制定測試過程的基礎。 測試的“深度”與測試用例的數量成比例。由于每個測試用例反映不同的場景、條件或經由產品的事件流，因而，隨著測試用例數量的增加，您對產品質量和測試流程也就越有信心。 判斷測試是否完全的一個主要評測方法是基于需求的覆蓋，而這又是以確定、實施和/或執行的測試用例的數量為依據的。類似下面這樣的說明：“95 % 的關鍵測試用例已得以執行和驗證”，遠比“我們已完成 95 % 的測試”更有意義。 測試工作量與測試用例的數量成比例。根據全面且細化的測試用例，可以更準確地估計測試周期各連續階段的時間安排。 測試設計和開發的類型以及所需的資源主要都受控于測試用例。 測試用例通常根據它們所關聯關系的測試類型或測試需求來分類，而且將隨類型和需求進行相應地改變。最佳方案是為每個測試需求至少編制兩個測試用例： 　　·一個測試用例用于證明該需求已經滿足，通常稱作正面測試用例； ·另一個測試用例反映某個無法接受、反?；蛞馔獾臈l件或數據，用于論證只有在所需條件下才能夠滿足該需求，這個測試用例稱作負面測試用例。

測試用例是為特定的目的而設計的一組測試輸入、執行條件和預期的結果。測試用例是執行的最小實體。簡單地說，測試用例就是設計一個場景，使軟件程序在這種場景下，必須能夠正常運行并且達到程序所設計的執行結果。

測試用例的粒度：每個測試用例所覆蓋的測試范圍或者期望結果的多少。

測試用例的特征

  1.最有可能抓住錯誤的；

 2.不是重復的、多余的；

  3.一組相似測試用例中最有效的；

  4.既不是太簡單，也不是太復雜；

 5.有效的，可執行的，有期望結果。

測試用例組成元素

  1.用例ID Test Case ID      

  2.用例名稱 Test Case Name

  3.測試目的 Test Objective

  4.測試級別 Test Level (Test Phase, ST, SIT, UAT…)

  5.參考信息

  6.測試環境 Test Environment

  7.前提條件 Prerequisites/Dependencies/Assumptions

  8.測試步驟 Test Steps/test script

  9.預期結果 Expected Result

  10.設計人員 Designer

11.執行人員 Tester

12.實際的結果/測試的結果 Actual Result/Test result

可能還有

13. 相關的需求和功能模塊，需求描述 requirement description

14. 測試數據 Test Data

15. 測試結果的狀態（反應測試是否成功） Test case status (passed, failed, hold, attention; also case use colors)

測試用例的組織方式

Test case ID
 Test case description
 Test steps
 Expected result
 Actual result
 Tester
 status
 
CR001
 Test user login with right user and password
 1,

2,

3,
 …should…
 
 Tester1
 passed
 
CR002
 Test user login with wrong password
 1,

2,

3,
 …shoud…
 
 Tester2
 failed
 
CR003
 Test user logout
 1,

2,

3,
 …shoud…
 
 Tester2
 hold
 

測試用例設計原則

  1.測試用例的代表性：能夠代表并覆蓋各種合理的和不合理的、合法的和非法的、邊界的和越界的以及極限的輸入數據、操作和環境設置等。

  2.測試結果的可判定性：即測試執行結果的正確性是可判定的，每一個測試用例都應有相應的期望結果。

  3.測試結果的可再現性：即對同樣的測試用例，系統的執行結果應當是相同的。

===============================================================

測試用例的特點：

完整
完整性是對測試用例最基本的要求，尤其是一些基本功能項上，如果有遺漏，那將是不可原諒的。完整性還體現在中斷測試、臨界測試、壓力測試、性能測試等方面，這方面測試用例也要能夠涉及到。
準確
   測試者按照測試用例的輸入一步步測試完成后，要能夠根據測試用例描述的輸出得出正確的結論,不能出現模糊不清的語言。
簡潔 
好的測試用例每一步都應該有響應的作用，有很強的針對性，不應該出現一些冗繁無用的操作步驟。測試用例不應該太簡單，也不能夠太過復雜，最大操作步驟最好控制在10-15步之間。
清晰  
清晰包括描述清晰,步驟條理清晰,測試層次清晰(由簡而繁,從基本功能測試到破壞性測試)。清晰簡潔對測試用例編寫者的邏輯思維和文字表達能力提出了較高的要求。
可維護性
由于軟件開發過程中需求變更等原因的影響，常常需要對測試用例進行修改、增加、刪除等，以便測試用例符合相應測試要求。測試用例應具備這方面的功能

適當性
測試例應該適合特定的測試環境以及符合整個團隊的測試水平，如純英語環境下的測試用例最好使用英文編寫。
可復用性
要求不同測試者在同樣測試環境下使用同樣測試用例都能得出相同結論。
其他
如可追朔性、可移植性也是對編寫測試用例的一個要求

原文轉自：http://www.anti-gravitydesign.com