如何編寫有效測試用例

轉載

測試用例，是一份關於具體測試步驟的文檔，它描述了測試的輸入參數、條件及配置、預期的輸出結果等，以判斷被測軟件的工作是否正常。

設計、書寫和執行測試案例是測試活動中重要的組成部分，測試案例通常由測試案例管理系統或工具進行管理。

一、編寫測試用例的原則

測試用例的重要性是毋庸置疑的，它是軟件測試全部過程的核心，是測試執行環節的基本依據。測試用例編寫應該遵循的原則：

1. 測試用例要達到最大覆蓋軟件系統的功能點。

2. 測試用例對測試功能點、測試條件、測試步驟、輸入值和預期結果應該有準確的定義。

3. 測試用例的設計應包括各種類型的測試用例。在設計測試用例的時候，除了滿足系統基本功能需求外，還應該考慮各種異常情況、邊界情況和承受壓力的能力等。

4. 測試用例的管理。使用測試用例管理系統對測試用例進行管理。

特性：

一個好的測試用例應該具有較高的發現某個尚未發現的錯誤的可能性，而一個成功的測試案例能夠發現某個尚未發現的錯誤，通常一個好的測試案例有以下特性：

1. 具有高的發現錯誤的概率

2. 沒有冗餘測試和冗餘的步驟

3. 測試是 “最佳類別”

4. 既不太簡單也不太複雜

5. 案例是可重用和易於跟蹤的

6. 確保系統能夠滿足功能需求

測試用例不可能設計得天衣無縫，也不可能完全滿足軟件需求的覆蓋率，測試執行過程裏肯定會發現有些測試路徑或數據在用例裏沒有體現，那麼事後該將其補充到用例庫裏，以方便他人和後續版本的測試。

二、如何編寫測試用例

測試用例的信息有很多，可以根據實際的情況進行增刪，一般來說一個優秀的測試用例應該包含以下信息：

1.產品相關信息

1. 軟件產品或項目的名稱

2. 軟件產品或項目的版本

3. 功能模塊名

4. 功能描述

5. 測試平臺這些信息建議可以在測試案例手工選擇。

2.基本記錄信息

1. 測試用例入庫者

2. 測試用例入庫時間

3. 測試用例更新者

4. 測試用例更新時間

這些信息建議可以由測試案例自動生成。

3.測試用例的屬性

1. 測試用例ID：測試用例的ID（由案例管理系統自動生成，方便跟蹤管理）

2. 測試用例名稱：測試用例的名稱

3. 測試功能點：測試的功能檢查點

4. 測試目的：該測試功能點的測試目的

5. 測試級別：主路徑測試、煙霧測試、基本功能測試、詳細功能測試。

測試級別進行說明：

• 主路徑測試：對照需求中重要模塊和功能的最主要功能路徑，主路徑測試爲設計探針模塊，快速檢查程序的可測試性（可測試性還包括安裝測試是否成功）的主要依據的測試案例

• 煙霧測試：對照需求中所有模塊的主要功能路徑，主路徑測試案例爲煙霧測試案例的子集，煙霧測試爲做迴歸測試的主要依據的測試案例。

• 基本功能測試：對照需求和總體設計中所有模塊和功能的基本功能路徑，基本功能測試爲測試軟件產品的非重要級別模塊，書寫完全的自動測試腳本的主要依據。

• 詳細功能測試：對照總體設計中所有模塊和功能的功能路徑，測試各個模塊及功能各個層次，各種類型。詳細功能測試案例爲對重點模塊，易發生錯誤的模塊的主要依據

6.測試類型：功能測試、邊界測試、異常測試、性能測試、壓力測試、兼容測試、安全測試、恢復測試、安裝測試、界面測試、啓動/停止 測試、文檔測試、配置測試、可靠性測試、易用性測試、多語言測試。 
7.預置條件：對測試的特殊條件或配置進行說明 
8.測試步驟：詳細描述測試過程，案例的操作步驟建議少於15個。 
9.預期結果：預期的測試結果

實例說明

例如：假設目前測試中國移動互聯短信網關是否能正確發送短信給中國聯通互聯網關，測試用例的設計如下： 
（1）測試用例ID：TC000001 
（2）測試用例名稱：中國移動全球通手機用戶成功發送短信給中國聯通手機用戶 
（3）測試功能點：中國移動全球通手機用戶成功短信給中國聯通手機用戶，中國聯通網關返回成功的狀態報告 
（4）測試目的： 
A、中國移動互聯短信網關能否正確處理全球通用戶發送給中國聯通用戶的短信； 
B、中國移動互聯短信網關能否正確處理中國聯通互聯短信網關返回成功的狀態報告的情況。 
（5）測試級別：基本功能測試 
（6）測試類型：功能測試 
（7）預置條件：各網關實體按照組網圖中的關係連接好，各實體之間的連接和通信正常。 
（8）測試步驟： 
A、中國移動全球通手機用戶（13901000001）給中國聯通手機用戶（13001000001）發送MO短信，內容爲“測試”，目的號碼填爲中國聯通手機號碼； 
B、中國聯通互聯短信網關把短信下發給中國聯通用戶成功後，給中國移動互聯短信網關返回一個標識成功的狀態報告。 
（9）預期結果： 
A、中國聯通手機用戶（13001000001）接收到了短信，內容爲“測試”，源號碼爲中國移動全球通的用戶號碼（13901000001）； 
B、在中國移動互聯短信網關上產生SMO話單，其中“短消息發送狀態”填0（表示成功），“源手機號碼”13001000001，“目的手機號碼”爲13001000001。

三、測試案例的模版

下面是一個完整的測試用例的模版：

四.測試用例設計過程

對一個全新的產品來說，首先需要了解的是產品需求文檔和產品模塊之間的關係。然後需要從需求文檔中書寫與所有需求相對應的主路徑測試案例和煙霧測試案例， 這個時候也同時會包括一定的基本路徑測試案例甚至是詳細測試案例。在這個時候，因爲對產品沒有直接的使用感受，書寫測試案例要考慮面廣而不要太過精細。繼 續閱讀產品功能定義文檔，將所有的功能定義直接對應寫相關的測試案例，這個時候，最好能夠對程序的本身有一定的接觸，加深對程序的瞭解，以便寫出更好，更 全面的測試案例。最後，在實際測試中，還需要不斷擴充，修改以前的測試案例，得到完整的基本功能測試案例和詳細測試案例。如果對於一個已有一定或大部分案 例的產品來說，不管測試者是否本身熟悉這個產品，其主要的任務就是閱讀，檢查需求及相關的變更，然後對原有的案例進行理解，擴充和修改。這就是案例的重用 /複用。設計測試案例的時候，需要有清晰的測試思路，對要測試什麼，按照什麼順序測試，覆蓋哪些需求做到心中有數。測試用例編寫者不僅要掌握軟件測試的技 術和流程，而且要對被測軟件的設計、功能規格說明、用戶試用場景以及程序/模塊的結構都有比較透徹的理解。

測試用例設計一般包括以下幾個步驟： 
1、測試需求分析從軟件需求文檔中，找出待測試軟件/模塊的需求，通過自己的分析、理解，整理成爲測試需求，清楚被測試對象具有哪些功能。測試需求的特點是：包含軟件需求，具有可測試性。

測試需求應該在軟件需求基礎上進行歸納、分類或細分，方便測試用例設計。測試用例中的測試集與測試需求的關係是多對一的關係，即一個或多個測試用例集對應一個測試需求。 
2、業務流程分析軟件測試，不單純是基於功能的黑盒測試，還需要對軟件的內部處理邏輯進行測試。爲了不遺漏測試點，需要清楚的瞭解軟件產品的業務流程。建 議在做複雜的測試用例設計前，先畫出軟件的業務流程。如果設計文檔中已經有業務流程設計，可以從測試角度對現有流程進行補充。如果無法從設計中得到業務流 程，測試工程師應通過閱讀設計文檔，與開發人員交流，最終畫出業務流程圖。業務流程圖可以幫助理解軟件的處理邏輯和數據流向，從而指導測試用例的設計。

從業務流程上，應得到以下信息：

A、主流程是什麼 
B、條件備選流程是什麼 
C、數據流向是什麼 
D、關鍵的判斷條件是什麼 
3、測試用例設計 
完成了測試需求分析和軟件流程分析後，開始着手設計測試用例。測試用例設計的類型包括功能測試，邊

界測試，異常測試，性能測試，壓力測試等。在用例設計中，除了功能測試用例外，應儘量考慮邊界、異

常、性能的情況，以便發現更多的隱藏問題。

黑盒測試的測試用例設計方法有：等價類劃分、邊界值劃分、因果圖分析和錯誤猜測，白盒測試的測試用

例設計方法有：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。在這裏主要討論黑盒測

試。在設計測試用例的時候可以使用軟件測試用例設計方法，結合前面的需求分析和軟件流程分析進行設

計：

功能測試：測試某個功能是否滿足需求的定義，功能是否正確，完備。

適合的技術：由業務需求和設計說明導出的功能測試、等價類劃分

邊界測試：對某個功能的邊界情況進行測試。

適合的技術：邊界值劃分

異常測試：對某些功能來說，其邊界情況無法簡單的瞭解或某些操作不完全是正確的但又是可能發生的，

類似這樣的情況需要書寫相關的異常測試。

適合的技術：由業務需求和設計說明導出的特殊業務流程、錯誤猜測法、邊界值分析、內部邊界值測試、

性能測試：檢查系統是否滿足在需求中所規定達到的性能，性能主要包括瞭解程序的內外部性能因素。內部性能因素包括測試環境的配置，系統資源使用狀況；外部因素包括響應時間，吞吐量等。

適合的技術：業務需求和設計說明導出的測試

壓力測試：壓力測試又稱強度測試，主要是檢查系統運行環境在極限情況下軟件運行的能力，比如說給一個相當大的負荷或網絡流量給應用軟件兼容測試：測試軟件產品在不同的平臺，不同的工具，相同工具的不同版本下功能的兼容性。

4、測試用例評審

測試用例設計完成後，爲了確認測試過程和方法是否正確，是否有遺漏的測試點，需要進行測試用例的評審。

測試用例評審一般是由測試leader安排，參加的人員包括：測試用例設計者、測試leader、項目經理、開發工程師、其它相關開發測試工程師。測試用例評審完畢，測試工程師根據評審結果，對測試用例進行修改，並記錄修改日誌。

5、測試用例更新完善

測試用例編寫完成之後需要不斷完善，軟件產品新增功能或更新需求後，測試用例必須配套修改更新；在測試過程中發現設計測試用例時考慮不周，需要對測試用例 進行修改完善；在軟件交付使用後客戶反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善。一般小的修改完善可在原測試用例文檔 上修改，但文檔要有更改記錄。軟件的版本升級更新，測試用例一般也應隨之編制升級更新版本。測試用例是“活”的，在軟件的生命週期中不斷更新與完善。