軟件測試用例的設計

軟件測試用例的設計

作者：王靜蘭

摘  要

一個項目最終呈現在用戶面前的質量，與測試執行的程度與力度是密不可分的。測試用例設計的基本目的，是確定一組最有可能發現某個錯誤或者某類錯誤的一組測試數據。測試用例構成了設計和制定測試過程的基礎，因此測試用例的質量在一定程度上決定了測試工作有效程度。一個好的測試用例使得測試工作的效果事半功倍，並且能儘早的發現一些隱藏的BUG，測試用例的設計是軟件開發中的重中之重。

關鍵詞：軟件測試，測試用例，TESTCASE，用例設計

A test case is a series of tests used to determine whether one particular thing works properly. Often that means trying the same operation over and over again with little in the procedure.

A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results.

 1  引言

1.1  測試用例在軟件產品中的作用和意義

軟件產品化之後給人們日常生活和工作帶來了極大的便利。同樣的，也使人們對軟件產品的質量重視上升到了更進一步的高度。隨着軟件危機的不斷出現以及人們對於軟件更進一步的認識，測試的地位得到了前所未有的提高，並且人們意識到：測試開始的時間越早，軟件的缺陷將越早被發現，帶來整個軟件開發中的成本也下降越多。軟件測試是發現軟件中缺陷的主要手段和唯一有效的方法。軟件質量的重視度越高，軟件測試工作在軟件開發過程中就越重要。

完全覆蓋測試又要求測試工作的力度和深度以及每一種現實中可能發生的操作都要保證正確，很多人覺得這個似乎是矛盾的。軟件測試中永遠不可能做到窮舉測試，又想使得測試工作的效率達到最高，那麼該如何兼顧工作量和效率的問題，往往成爲測試工作中的瓶頸問題所在。如何測試，用什麼方式來測試，在什麼環境和什麼樣的條件下進行測試，測試的工作量和如何避免重複的測試，等等各種應該考慮的因素在測試工作中如何協調和同步，在測試用例中應該充分描述這些問題。

因此，軟件測試工作中處於重中之重的測試用例的設計要求也隨之上升到了更高的層次。測試用例不但構成了設計和制定測試過程的基礎，而且測試的深度與測試用例的數量成正比。一般來講，判斷測試是否完全的一個主要評測方法是基於需求的覆蓋，而這個又是以確定、實施和（或）執行的測試用例的數量爲依據的；測試工作量與測試用例的數量成比例；測試設計和開發的類型以及所需的資源主要都受控於測試用例。這些使得測試用例在整個的軟件開發過程中處於更加重要的地位。

1.2  測試用例的定義

測試用例是爲某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或覈實是否滿足某個特定需求。

Robert V.Binder是這樣描述的，測試實例：輸入、執行條件，及爲一個特殊目標所開發的預期結果的集合。一個定義IUT（被測實現，即被測代碼）及其環境、測試輸入或條件，及預期結果的測試前狀態的表示或實現。

1.3  測試用例應該包含的要素

首先測試用例應該包含軟件或者項目名稱、所服務的範圍、背景、作者、編寫時間等文檔類信息；根據測試用例的定義和目的，測試用例的內容應該有：標題和用例編號、版本號、修改記錄，針對目標和假設前提/可能發現的錯誤，輸入數據/代碼，測試步驟，預期輸出和錯誤發現方法。

1.4  測試用例中需要注意的問題

每個測試用例清楚地闡述了正在進行評估的用例、用例場景、測試目標或條件的有關說明。每個測試用例都描述了預期結果和評估該結果的方法。

對於每個測試需求，在測試用例中需要考慮在正面測試和負面測試的條件下的測試，或者通過確定兩個測試用例來實現，一個測試用例代表預期的條件，它可用於覈實行爲是否正確或符合預期（正面測試）。另一個測試用例代表不可接受的、異常的或意外的條件，它可用於覈實測試需求是否未以非預期方式執行（負面測試）。

在一般情況下，對於測試的每個需求來說，至少要有一個正面測試用例和爲數較多的負面測試用例，以此來檢查在異常情況下系統能否正常處理，或者用戶進行了錯誤的操作時的友好提示等等。

測試用例已被確定用來執行測試目標中所有的產品需求行爲，包括（視情況而定）： 功能 、數據確認 、業務規則實施 、測試目標工作流程或控制 、數據流 、對象狀態 、性能（包括工作量、配置和強度） 、安全性/可訪問性 、兼容性。每個測試用例都說明或者/代表一個唯一的輸入集或事件順序，它能夠產生唯一的測試目標行爲，複審那些產生相同行爲的測試用例並判定它們是否等同，即它們是否都執行測試目標中的路徑。

每個測試用例（或每組相關的測試用例）確定初始的測試目標狀態和測試數據狀態。測試用例名稱和/或 ID 與測試工件命名約定一致。

2  測試用例的設計方法概述

根據測試的方法分爲黑盒測試和白盒測試，相應的測試用例的設計方法也可以分爲針對黑盒測試的用例設計和針對白盒測試的用例設計。

至今提出的測試用例設計方法有許多，下面簡要的介紹一些比較重要的、常用的方法。

2.1  白盒測試的測試用例設計方法

2.1.1 邏輯覆蓋

邏輯覆蓋包括：語句覆蓋、判定覆蓋、條件覆蓋、判定－條件覆蓋、條件組合覆蓋、路徑覆蓋，各自的定義簡略描述如下：

語句覆蓋就是設計若干個測試用例，運行被測程序，使得每一可執行語句至少執行一次。

判定覆蓋就是設計若干個測試用例，運行被測程序，使得程序中每個判斷的取真分支和取假分支至少經歷一次。

條件覆蓋就是設計若干個測試用例，運行被測程序，使得程序中每個判斷的每個條件的可能取值至少執行一次。

判定－條件覆蓋就是設計足夠的測試用例，使得判斷中每個條件的所有可能取值至少執行一次，每個判斷中的每個分支至少執行一次。

條件組合覆蓋就是設計足夠的測試用例，運行被測程序，使得每個判斷的所有可能的條件取值組合至少執行一次。

路徑測試就是設計足夠的測試用例，覆蓋程序中所有可能的路徑。

2.1.2 基本路徑測試

基本路徑測試方法把覆蓋的路徑數壓縮到一定限度內，程序中的循環體最多隻執行一次。

它是在程序控制流圖的基礎上，分析控制構造的環路複雜性，導出基本可執行路徑集合，設計測試用例的方法。設計出的測試用例要保證在測試中，程序的每一個可執行語句至少要執行一次。

2.2  黑盒測試的測試用例設計方法

2.2.1 等價劃分

所謂等價類劃分是指一套被選擇的值，這些值分別代表了許多衆多的可能輸入值，程序對其處理的方式都是一樣的。

等價類劃分的方法作爲繼邊界值分析方法之後補充的測試用力設計試用的一種方法。劃分等價類、確定測試用例

等價類劃分是一種典型的黑盒測試方法，使用這一方法時，完全不考慮程序的內部結構，只依據程序的規格說明來設計測試用例。

等價類劃分方法把所有可能的輸入數據，即程序的輸入域劃分成若干部分，然後從每一部分中選取少數有代表性的數據做爲測試用例

等價類的劃分有兩種不同的情況：
有效等價類：是指對於程序的規格說明來說，是合理的，有意義的輸入數據構成的集合。

無效等價類：是指對於程序的規格說明來說，是不合理的，無意義的輸入數據構成的集合。

在設計測試用例時，要同時考慮有效等價類和無效等價類的設計。

2.2.2 邊界值分析

在設計測試用例確定輸入和輸出參數時，大多數情況下都是用邊界值分析方法，採用邊界值分析設計的測試用例發現程序錯誤能力最強。

邊界值分析也是一種黑盒測試方法，是對等價類劃分方法的補充。

人們從長期的測試工作經驗得知，大量的錯誤是發生在輸入或輸出範圍的邊界上，而不是在輸入範圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。

2.2.3 錯誤推測法

人們也可以靠經驗和直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的例子。這就是錯誤推測法。

錯誤推測法的基本想法是：列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據它們選擇測試用例。

2.2.4 因果圖

如果程序的功能說明中含有輸入條件的組合情況，則一開始就可以選用因果圖法。如果在測試時必須考慮輸入條件的各種組合，可使用一種適合於描述對於多種條件的組合，相應產生多個動作的形式來設計測試用例，這就需要利用因果圖。

因果圖方法最終生成的就是判定表。它適合於檢查程序輸入條件的各種組合情況。

3  測試用例的評審及維護

3.1 測試用例的評審

測試用例在設計之後需要經過評審，需要評審的內容如下：

用例是否完整？是否每一個需求都有其對應的測試用例來驗證？

是否每一個設計元素都有其對應的測試用例來驗證？

事件順序，能否產生唯一的測試目標行爲？

是否每隔測試用例都闡述了預期結果？

是否每個測試用例（或每組相關的測試用例）都確定了初始的測試目標狀態和測試數據狀態？

測試用例是否包含了所有單一的邊界？

測試用例是否包含了所有的業務數據流？

是否所有的測試用例名稱，ID都與測試工件命名約定一致？

測試用例評審時需要參加的人員：項目經理，系統分析員，測試設計員，測試員

3.2  用例庫的更新維護

隨着軟件項目的開發，用例庫的數據隨着項目的進展動態變化也是需要維護的，主要包括：不合適用例的修改、冗餘用例的刪除、測試用例的增加，並對進行的操作在備註中署名修改者以及修改時間和改動原因。

4  測試用例實例

該測試案例是以一個B/S結構的登錄功能點位被測對象, 該測試用例爲黑盒測試用例。假設用戶使用的瀏覽器爲IE6.0 SP4。

功能描述如下：

1.    用戶在地址欄輸入相應地址，要求顯示登錄界面；

2.    輸入用戶名和密碼，登錄，系統自動校驗，並給出相應提示信息；

3.    如果用戶名或者密碼任一信息未輸入，登錄後系統給出相應提示信息；

4.    連續3次未通過驗證時，自動關閉IE。

圖4-1登錄界面

表4-1 登錄界面測試用例

用例ID		XXXX-XX-XX	用例名稱		系統登錄
用例描述		系統登錄 用戶名存在、密碼正確的情況下，進入系統 頁面信息包含：頁面背景顯示 用戶名和密碼錄入接口，輸入數據後的登入系統接口
用例入口		打開IE，在地址欄輸入相應地址 進入該系統登錄頁面
測試用例ID	場景			測試步驟		預期結果	備註
TC1	初始頁面顯示			從用例入口處進入		頁面元素完整，顯示與詳細設計一致
TC2	用戶名錄入－驗證			輸入已存在的用戶：test		輸入成功
TC3	用戶名－容錯性驗證			輸入：aaaaabbbbbcccccdddddeeeee		輸入到藍色顯示的字符時，系統拒絕輸入	輸入數據超過規定長度範圍
TC4	密碼－密碼錄入			輸入與用戶名相關聯的數據：test		輸入成功
TC5	系統登錄－成功			TC2，TC4，單擊登錄按鈕		登錄系統成功
TC6	系統登錄－用戶名、密碼校驗			沒有輸入用戶名、密碼，單擊登錄按鈕		系統登錄失敗，並提示：請檢查用戶名和密碼的輸入是否正確
TC7	系統登錄－密碼校驗			輸入用戶名，沒有輸入密碼，單擊登錄按鈕		系統登錄失敗，並提示：需要輸入密碼
TC8	系統登錄－密碼有效性校驗			輸入用戶名，輸入密碼與用戶名不一致，單擊登錄按鈕		系統登錄失敗，並提示：錯誤的密碼
TC9	系統登錄－輸入有效性校驗			輸入不存在的用戶名、密碼，單擊登錄按鈕		系統登錄失敗，並提示：用戶名不存在
TC10	系統登錄—安全校驗			連續3次未成功		系統提示：您沒有使用該系統的權限，請與管理員聯繫！
…	…					…	…

 參考文獻：

[1] 鄭人傑，殷人昆，陶永雷，實用軟件工程（第二版），清華大學出版社，2001.10

[2] 楊文龍，姚淑珍，吳芸，軟件工程；電子工業出版社，1997.11

[3] Robert V.Binder 著，華慶一，王斌君，陳莉 譯，人民郵電出版社，2001.4

-----------------------------------------------------------------------------------

[作者簡介]

姓名：王靜蘭，女，2002年畢業於西安電子科技大學，計算機信息管理專業。

研究方向：軟件測試管理

Email：[email protected]    

業餘愛好：聽音樂、爬山