測試用例（Test Case）是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程式路徑或核實是否滿足某個特定需求。
基本介紹
- 中文名：測試用例
- 外文名：Test Case
- 作用：測試輸入、執行條件以及預期結果
- 類型：測試程式
類別,重要原因,設計,設計誤區,從用例中生成,編制,作用,相關問題,
類別
測試用例（Test Case）是將軟體測試的行為活動做一個科學化的組織歸納，目的是能夠將軟體測試的行為轉化成可管理的模式；同時測試用例也是將測試具體量化的方法之一，不同類別的軟體，測試用例是不同的。不同於諸如系統、工具、控制、遊戲軟體，管理軟體的用戶需求更加不同的趨勢。
測試用例
測試用例要使最終用戶對軟體感到滿意，最有力的舉措就是對最終用戶的期望加以明確闡述，以便對這些期望進行核實並確認其有效性。測試用例反映了要核實的需求。然而，核實這些需求可能通過不同的方式並由不同的測試員來實施。例如，執行軟體以便驗證它的功能和性能，這項操作可能由某個測試員採用自動測試技術來實現；計算機系統的關機步驟可通過手工測試和觀察來完成；不過，市場占有率和銷售數據（以及產品需求），只能通過評測產品和競爭銷售數據來完成。
既然可能無法（或不必負責）核實所有的需求，那么是否能為測試挑選最適合或最關鍵的需求則關係到項目的成敗。選中要核實的需求將是對成本、風險和對該需求進行核實的必要性這三者權衡考慮的結果。
重要原因
確定測試用例之所以很重要，原因有以下幾方面。
測試用例構成了設計和制定測試過程的基礎。
測試用例
測試用例測試的“深度”與測試用例的數量成比例。由於每個測試用例反映不同的場景、條件或經由產品的事件流，因而，隨著測試用例數量的增加，您對產品質量和測試流程也就越有信心。
判斷測試是否完全的一個主要評測方法是基於需求的覆蓋，而這又是以確定、實施和/或執行的測試用例的數量為依據的。類似下面這樣的說明：“95 % 的關鍵測試用例已得以執行和驗證”，遠比“我們已完成 95 % 的測試”更有意義。
測試工作量與測試用例的數量成比例。根據全面且細化的測試用例，可以更準確地估計測試周期各連續階段的時間安排。
測試設計和開發的類型以及所需的資源主要都受控於測試用例。
測試用例通常根據它們所關聯關係的測試類型或測試需求來分類，而且將隨類型和需求進行相應地改變。最佳方案是為每個測試需求至少編制兩個測試用例：
·一個測試用例用於證明該需求已經滿足，通常稱作正面測試用例；
·另一個測試用例反映某個無法接受、反常或意外的條件或數據，用於論證只有在所需條件下才能夠滿足該需求，這個測試用例稱作負面測試用例。
一、測試用例是軟體測試的核心
軟體測試的重要性是毋庸置疑的。但如何以最少的人力、資源投入，在最短的時間內完成測試，發現軟體系統的缺陷，保證軟體的優良品質，則是軟體公司探索和追求的目標。每個軟體產品或軟體開發項目都需要有一套優秀的測試方案和測試方法。
影響軟體測試的因素很多，例如軟體本身的複雜程度、開發人員（包括分析、設計、編程和測試的人員）的素質、測試方法和技術的運用等等。因為有些因素是客觀存在的，無法避免。有些因素則是波動的、不穩定的，例如開發隊伍是流動的，有經驗的走了，新人不斷補充進來；一個具體的人工作也受情緒等影響，等等。如何保障軟體測試質量的穩定？有了測試用例，無論是誰來測試，參照測試用例實施，都能保障測試的質量。可以把人為因素的影響減少到最小。即便最初的測試用例考慮不周全，隨著測試的進行和軟體版本更新，也將日趨完善。
測試用例
測試用例因此測試用例的設計和編制是軟體測試活動中最重要的。測試用例是測試工作的指導，是軟體測試的必須遵守的準則。更是軟體測試質量穩定的根本保障。
設計
（一）白盒技術
⒈邏輯覆蓋
⑴語句覆蓋。
如圖7-1是一個被測試程式流程圖：
⑵判定覆蓋。
⑶條件覆蓋。
⑷判定條件覆蓋。
該覆蓋標準指設計足夠的測試用例，使得判定表達式的每個條件的所有可能取值至少出現一次，並使每個判定表達式所有可能的結果也至少出現一次。
⑸條件組合覆蓋。
條件組合覆蓋是比較強的覆蓋標準，它是指設計足夠的測試用例，使得每個判定表達式中條件的各種可能的值的組合都至少出現一次。
⑹路徑覆蓋。
⒉循環覆蓋
⒊基本路徑測試
（二）黑盒技術
⒈等價類劃分
⑴劃分等價類。
①在輸入條件規定了取值範圍或值的個數的情況下，則可以確立一個有效等價類和兩個無效等價類。
②在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下，可確立一個有效等價類和一個無效等價類。
③在輸入條件是一個布爾量的情況下，可確定一個有效等價類和一個無效等價類。
⑤在規定了輸入數據必須遵守的規則的情況下，可確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）。
⑥在確知已劃分的等價類中各元素在程式處理中的方式不同的情況下，則應再將該等價類進一步的劃分為更小的等價類。
⑵確定測試用例。
①為每一個等價類編號。
②設計一個測試用例，使其儘可能多地覆蓋尚未被覆蓋過的合理等價類。重複這步，直到所有合理等價類被測試用例覆蓋。
③設計一個測試用例，使其只覆蓋一個不合理等價類。
⒉邊界值分析
使用邊界值分析方法設計測試用例時一般與等價類劃分結合起來。但它不是從一個等價類中任選一個例子作為代表，而是將測試邊界情況作為重點目標，選取正好等於、剛剛大於或剛剛小於邊界值的測試數據。
⑴如果輸入條件規定了值的範圍，可以選擇正好等於邊界值的數據作為合理的測試用例，同時還要選擇剛好越過邊界值的數據作為不合理的測試用例。如輸入值的範圍是[1，100]，可取0，1，100，101等值作為測試數據。
⑵如果輸入條件指出了輸入數據的個數，則按最大個數、最小個數、比最小個數少1、比最大個數多1等情況分別設計測試用例。如，一個輸入檔案可包括1--255個記錄，則分別設計有1個記錄、255個記錄，以及0個記錄的輸入檔案的測試用例。
⑶對每個輸出條件分別按照以上原則⑴或⑵確定輸出值的邊界情況。如，一個學生成績管理系統規定，只能查詢95--98級大學生的各科成績，可以設計測試用例，使得查詢範圍內的某一屆或四屆學生的學生成績，還需設計查詢94級、99級學生成績的測試用例（不合理輸出等價類）。
由於輸出值的邊界不與輸入值的邊界相對應，所以要檢查輸出值的邊界不一定可能，要產生超出輸出值之外的結果也不一定能做到，但必要時還需試一試。
⒊錯誤推測
在測試程式時，人們可能根據經驗或直覺推測程式中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試用例，這就是錯誤推測法。
⒋因果圖
等價類劃分和邊界值方法分析方法都只是孤立地考慮各個輸入數據的測試功能，而沒有考慮多個輸入數據的組合引起的錯誤。
⒌綜合策略
每種方法都能設計出一組有用例子，用這組例子容易發現某種類型的錯誤，但可能不易發現另一類型的錯誤。因此在實際測試中，聯合使用各種測試方法，形成綜合策略，通常先用黑盒法設計基本的測試用例，再用白盒法補充一些必要的測試用例。
設計誤區
·能發現到目前為止沒有發現的缺陷的用例是好的用例。
首先要申明，其實這句話是十分有道理的，但我發現很多人都曲解了這句話的原意，一心要設計出發現“難於發現的缺陷”而陷入盲目的片面中去，忘記了測試的目的所在，這是十分可怕的。我傾向於將測試用例當作一個集合來認識，對它的評價也只能對測試用例的集合來進行，測試本身是一種“V&AMp;V”的活動，測試需要保證以下兩點：
程式做了它應該做的事情
程式沒有做它不該做的事情
因此，作為測試實施依據的測試用例，必須要能完整覆蓋測試需求，而不應該針對單個的測試用例去評判好壞。
·測試用例應該詳細記錄所有的操作信息，使一個沒有接觸過系統的人員也能進行測試。
在討論這個問題之前，我們可以先考慮一下測試的目的。測試的目的是儘可能發現程式中存在的缺陷，測試活動本身也可以被看作是一個ProjECt，也需要在 給定的資源條件下儘可能達成目標，根據我個人的經驗，大部分的國內軟體公司在測試方面配備的資源都是不足夠的，因此我們必須在測試計畫階段明確測試的目 標，一切圍繞測試的目標進行。
除了資源上的約束外，測試用例的詳細程度也需要根據需要確定。如果測試用例的執行者、測試用例設計者、測試活動相關人對系統了解都很深刻，那測試用例就沒有必要太詳細了，文檔的作用本來就在於溝通，只要能達到溝通的目的就OK。在我擔任測試經理的項目中，在測試計畫階段，一般給予測試設計30% - 40%左右的時間，測試設計工程師能夠根據項目的需要自行確定用例的詳細程度，在測試用例的評審階段由參與評審的相關人對其把關。
·測試用例設計是一勞永逸的事情。
這句話擺在這裡，我想沒有一個人會認可，但在實際情況中，卻經常能發現這種想法的影子。我曾經參與過一個項目，軟體需求和設計已經變更了多次，但測試用例 卻沒有任何修改。導致的直接結果是新加入的測試工程師在執行測試用例時不知所措，間接的後果是測試用例成了廢紙一堆，開發人員在多次被無效的缺陷報告打擾 後，對測試人員不屑一顧。
這個例子可能有些極端，但測試用例與需求和設計不同步的情況在實際開發過程中卻是屢見不鮮的，測試用例文檔是“活的”文檔，這一點應該被測試工程師牢記。
·測試用例不應該包含實際的數據。
測試用例是“一組輸入、執行條件、預期結果”、毫無疑問地應該包括清晰的輸入數據和預期輸出，沒有測試數據的用例最多只具有指導性的意義，不具有可執行 性。當然，測試用例中包含輸入數據會帶來維護、與測試環境同步之類的問題，關於這一點，《Effective Software TeST》一書中提供了詳細的測試用例、測試數據的維護方法，可以參考。
·測試用例中不需要明顯的驗證手段。
我見過很多測試工程師編寫的測試用例中，“預期輸出”僅描述為程式的可見行為，其實，“預期結果”的含義並不只是程式的可見行為。例如，對一個訂貨系統， 輸入訂貨數據，點擊“確定”按鈕後，系統提示“訂貨成功”，這樣是不是一個完整的用例呢？是不是系統輸出的“訂貨成功”就應該作為我們唯一的驗證手段呢？ 顯然不是。訂貨是否成功還需要查看相應的數據記錄是否更新，因此，在這樣的一個用例中，還應該包含對測試結果的顯式的驗證手段：在資料庫中執行查詢語句進行查詢，看查詢結果是否與預期的一致。
從用例中生成
用於功能性測試的測試用例來源於測試目標的用例。應該為每個用例場景編制測試用例。用例場景要通過描述流經用例的路徑來確定，這個流經過程要從用例開始到結束遍歷其中所有基本流和備選流。
例如，下圖中經過用例的每條不同路徑都反映了基本流和備選流，都用箭頭來表示。基本流用直黑線來表示，是經過用例的最簡單的路徑。每個備選流自基本流開始，之後，備選流會在某個特定條件下執行。備選流可能會重新加入基本流中（備選流 1 和 3），還可能起源於另一個備選流（備選流 2），或者終止用例而不再重新加入某個流（備選流 2 和 4）。
用例的事件流示例
遵循上圖中每個經過用例的可能路徑，可以確定不同的用例場景。從基本流開始，再將基本流和備選流結合起來，可以確定以下用例場景：
場景 1 基本流
場景 2 基本流 備選流 1
場景 3 基本流 備選流 1 備選流 2
場景 4 基本流 備選流 3
場景 5 基本流 備選流 3 備選流 1
場景 6 基本流 備選流 3 備選流 1 備選流 2
場景 7 基本流 備選流 4
場景 8 基本流 備選流 3 備選流 4
註：為方便起見，場景 5、6 和 8 只描述了備選流 3 指示的循環執行一次的情況。
生成每個場景的測試用例是通過確定某個特定條件來完成的，這個特定條件將導致特定用例場景的執行。
例如，假定上圖描述的用例對備選流 3 規定如下：
“如果在上述步驟 2‘輸入提款金額’中輸入的美元量超出當前帳戶餘額，則出現此事件流。系統將顯示一則警告訊息，之後重新加入基本流，再次執行上述步驟 2‘輸入提款金額’，此時銀行客戶可以輸入新的提款金額。”
據此，可以開始確定需要用來執行備選流 3 的測試用例：
測試用例ID 場景 條件 預期結果
TC x 場景 4 步驟 2 - 提款金額 > 帳戶餘額 在步驟 2 處重新加入基本流
TC y 場景 4 步驟 2 - 提款金額 < 帳戶餘額 不執行備選流 3，執行基本流
TC z 場景 4 步驟 2 - 提款金額 = 帳戶餘額 不執行備選流 3，執行基本流
註：由於沒有提供其他信息，以上顯示的測試用例都非常簡單。測試用例很少如此簡單。
下面是一個由用例生成測試用例的更符合實際情況的示例。
示例：
一台 ATM 機器的主角和用例。
下表包含了上圖中提款用例的基本流和某些備用流：
本用例的開端是 ATM 處於準備就緒狀態。
準備提款 - 客戶將銀行卡插入 ATM 機的讀卡機。
驗證銀行卡 - ATM 機從銀行卡的磁條中讀取帳戶代碼，並檢查它是否屬於可以接收的銀行卡。
輸入 PIN - ATM 要求客戶輸入 PIN 碼（4 位）
驗證帳戶代碼和 PIN - 驗證帳戶代碼和 PIN 以確定該帳戶是否有效以及所輸入的 PIN 對該帳戶來說是否正確。對於此事件流，帳戶是有效的而且 PIN 對此帳戶來說正確無誤。
ATM 選項 - ATM 顯示在本機上可用的各種選項。在此事件流中，銀行客戶通常選擇“提款”。
輸入金額 - 要從 ATM 中提取的金額。對於此事件流，客戶需選擇預設的金額（10 美元、20 美元、50 美元或 100 美元）。
授權 - ATM 通過將卡 ID、PIN、金額以及帳戶信息作為一筆交易傳送給銀行系統來啟動驗證過程。對於此事件流，銀行系統處於在線上狀態，而且對授權請求給予答覆，批准完成提款過程，並且據此更新帳戶餘額。
出鈔 - 提供現金。
返回銀行卡 - 銀行卡被返還。
收據 - 列印收據並提供給客戶。ATM 還相應地更新內部記錄。
用例結束時 ATM 又回到準備就緒狀態。
備選流 1 - 銀行卡無效 在基本流步驟 2 中 - 驗證銀行卡，如果卡是無效的，則卡被退回，同時會通知相關訊息。
備選流 2 - ATM 內沒有現金 在基本流步驟 5 中 - ATM 選項，如果 ATM 內沒有現金，則“提款”選項將無法使用。
備選流 3 - ATM 內現金不足 在基本流步驟 6 中- 輸入金額，如果 ATM 機內金額少於請求提取的金額，則將顯示一則適當的訊息，並且在步驟 6 - 輸入金額處重新加入基本流。
備選流 4 - PIN 有誤 在基本流步驟 4 中- 驗證帳戶和 PIN，客戶有三次機會輸入 PIN。
如果 PIN 輸入有誤，ATM 將顯示適當的訊息；如果還存在輸入機會，則此事件流在步驟 3 - 輸入 PIN 處重新加入基本流。
如果最後一次嘗試輸入的 PIN 碼仍然錯誤，則該卡將被 ATM 機保留，同時 ATM 返回到準備就緒狀態，本用例終止。
備選流 5 - 帳戶不存在 在基本流步驟 4 中 - 驗證帳戶和 PIN，如果銀行系統返回的代碼表明找不到該帳戶或禁止從該帳戶中提款，則 ATM 顯示適當的訊息並且在步驟 9 - 返回銀行卡處重新加入基本流。
備選流 6 - 帳面金額不足 在基本流步驟 7 - 授權中，銀行系統返回代碼表明帳戶餘額少於在基本流步驟 6 - 輸入金額內輸入的金額，則 ATM 顯示適當的訊息並且在步驟 6 - 輸入金額處重新加入基本流。
備選流 7 - 達到每日最大的提款金額 在基本流步驟 7 - 授權中，銀行系統返回的代碼表明包括本提款請求在內，客戶已經或將超過在 24 小時內允許提取的最多金額，則 ATM 顯示適當的訊息並在步驟 6 - 輸入金額上重新加入基本流。
備選流 x - 記錄錯誤 如果在基本流步驟 10 - 收據中，記錄無法更新，則 ATM 進入“安全模式”，在此模式下所有功能都將暫停使用。同時向銀行系統傳送一條適當的警報信息表明 ATM 已經暫停工作。
備選流 y - 退出 客戶可隨時決定終止交易（退出）。交易終止，銀行卡隨之退出。
備選流 z - “翹起” ATM 包含大量的感測器，用以監控各種功能，如電源檢測器、不同的門和出入口處的測壓器以及動作檢測器等。在任一時刻，如果某客戶做出暴力舉動，便啟用適當的措施。
編制
著重介紹一些編制測試用例的具體做法。
⒈測試用例文檔
編寫測試用例文檔應有文檔模板，須符合內部的規範要求。測試用例文檔將受制於測試用例管理軟體的約束。
測試用例文檔由簡介和測試用例兩部分組成。簡介部分編制了測試目的、測試範圍、定義術語、參考文檔、概述等。測試用例部分逐一列示各測試用例。每個具體測試用例都將包括下列詳細信息：版本號、模組名稱、用例編號、用例名稱、用例級別、預知條件、驗證步驟、期望結果（含判斷標準）、測試結果、測試時間、測試人員等。
⒉測試用例的設定
按功能測試是最簡捷的，按用例規約遍歷測試每一功能。
對於複雜操作的程式模組，其各功能的實施是相互影響、緊密相關、環環相扣的，可以演變出數量繁多的變化。沒有嚴密的邏輯分析，產生遺漏是在所難免。路徑分析是一個很好的方法，其最大的優點是在於可以避免漏測試。
但路徑分析法也有局限性。在一個非常簡單字典維護模組就存在十餘條路徑。一個複雜的模組會有幾十到上百條路徑是不足為奇的。筆者以為這是路徑分析比較合適的使用規模。若一個子系統有十餘個或更多的模組，這些模組相互有關聯。再採用路徑分析法，其路徑數量成幾何級增長，達5位數或更多，就無法使用了。那么子系統模組間的測試路徑或測試用例還是要靠傳統方法來解決。這是按功能、路徑混合模式設定用例的由來。
⒊設計測試用例
測試用例可以分為基本事件、備選事件和異常事件。設計基本事件的用例，應該參照用例規約（或設計規格說明書），根據關聯的功能、操作按路徑分析法設計測試用例。而對孤立的功能則直接按功能設計測試用例。基本事件的測試用例應包含所有需要實現的需求功能，覆蓋率達100%。
設計備選事件和異常事件的用例，則要複雜和困難得多。例如，字典的代碼是唯一的，不允許重複。測試需要驗證：字典新增程式中已存在有關字典代碼的約束，若出現代碼重複必須報錯，並且報錯文字正確。往往在設計編碼階段形成的文檔對備選事件和異常事件分析描述不夠詳盡。而測試本身則要求驗證全部非基本事件，並同時儘量發現其中的軟體缺陷。
可以採用軟體測試常用的基該方法：等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、邏輯覆蓋法等設計測試用例。視軟體的不同性質採用不同的方法。如何靈活運用各種基該方法來設計完整的測試用例，並最終實現暴露隱藏的缺陷，全憑測試設計人員的豐富經驗和精心設計。
作用
⒈指導測試的實施
測試用例主要適用於集成測試、系統測試和回歸測試。在實施測試時測試用例作為測試的標準，測試人員一定要按照測試用例嚴格按用例項目和測試步驟逐一實施測試。並對測試情況記錄在測試用例管理軟體中，以便自動生成測試結果文檔。
⒉規劃測試數據的準備
在我們的實踐中測試數據是與測試用例分離的。按照測試用例配套準備一組或若干組測試原始數據，以及標準測試結果。尤其像測試報表之類數據集的正確性，按照測試用例規劃準備測試數據是十分必須的。
除正常數據之外，還必須根據測試用例設計大量邊緣數據和錯誤數據。
⒊編寫測試腳本的"設計規格說明書"
⒋評估測試結果的度量基準
⒌分析缺陷的標準
通過收集缺陷，對比測試用例和缺陷資料庫，分析確證是漏測還是缺陷復現。漏測反映了測試用例的不完善，應立即補充相應測試用例，最終達到逐步完善軟體質量。而已有相應測試用例，則反映實施測試或變更處理存在問題。
相關問題
⒈測試用例的評審
測試用例是軟體測試的準則，但它並不是一經編制完成就成為準則。測試用例在設計編制過程中要組織同級互查。完成編制後應組織專家評審，需獲得通過才可以使用。評審委員會可由項目負責人、測試、編程、分析設計等有關人員組成，也可邀請客戶代表參加。
⒉測試用例的修改更新
測試用例在形成文檔後也還需要不斷完善。主要來自三方面的緣故：第一、在測試過程中發現設計測試用例時考慮不周，需要完善；第二、在軟體交付使用後反饋的軟體缺陷，而缺陷又是因測試用例存在漏洞造成；第三、軟體自身的新增功能以及軟體版本的更新，測試用例也必須配套修改更新。
一般小的修改完善可在原測試用例文檔上修改，但文檔要有更改記錄。軟體的版本升級更新，測試用例一般也應隨之編制升級更新版本。
⒊測試用例的管理軟體
運用測試用例還需配備測試用例管理軟體。它的主要功能有三個：第一、能將測試用例文檔的關鍵內容，如編號、名稱等等自動導入管理資料庫，形成與測試用例文檔完全對應的記錄；第二、可供測試實施時及時輸入測試情況；第三、最終實現自動生成測試結果文檔，包含各測試度量值，測試覆蓋表和測試通過或不通過的測試用例清單列表。
有了管理軟體，測試人員無論是編寫每日的測試工作日誌、還是出軟體測試報告，都會變得輕而易舉。
