測試用例

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

概述

測試用例（Test Case）目前沒有經典的定義。比較通常的說法是：指對一項特定的軟體產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，並形成文檔。

不同類別的軟體，測試用例是不同的。不同於諸如系統、工具、控制、遊戲軟體，管理軟體的用戶需求更加不統一，變化更大、更快。筆者主要從事企業管理軟體的測試。因此我們的做法是把測試數據和測試腳本從測試用例中劃分出來。測試用例更趨於是針對軟體產品的功能、業務規則和業務處理所設計的測試方案。對軟體的每個特定功能或運行操作路徑的測試構成了一個個測試用例。

隨著中國軟體業的日益壯大和逐步走向成熟，軟體測試也在不斷發展。從最初的由軟體編程人員兼職測試到軟體公司組建獨立專職測試部門。測試工作也從簡單測試演變為包括：編制測試計畫、編寫測試用例、準備測試數據、編寫測試腳本、實施測試、測試評估等多項內容的正規測試。測試方式則由單純手工測試發展為手工、自動兼之，並有向第三方專業測試公司發展的趨勢。

要使最終用戶對軟體感到滿意,最有力的舉措就是對最終用戶的期望加以明確闡述，以便對這些期望進行核實並確認其有效性。測試用例反映了要核實的需求。然而，核實這些需求可能通過不同的方式並由不同的測試員來實施。例如，執行軟體以便驗證它的功能和性能，這項操作可能由某個測試員採用自動測試技術來實現；計算機系統的關機步驟可通過手工測試和觀察來完成；不過，市場占有率和銷售數據（以及產品需求），只能通過評測產品和競爭銷售數據來完成。

既然可能無法（或不必負責）核實所有的需求，那么是否能為測試挑選最適合或最關鍵的需求則關係到項目的成敗。選中要核實的需求將是對成本、風險和對該需求進行核實的必要性這三者權衡考慮的結果。

確定測試用例之所以很重要，原因有以下幾方面。

測試用例構成了設計和制定測試過程的基礎。
測試的“深度”與測試用例的數量成比例。由於每個測試用例反映不同的場景、條件或經由產品的事件流，因而，隨著測試用例數量的增加，您對產品質量和測試流程也就越有信心。
判斷測試是否完全的一個主要評測方法是基於需求的覆蓋，而這又是以確定、實施和/或執行的測試用例的數量為依據的。類似下面這樣的說明：“95 % 的關鍵測試用例已得以執行和驗證”，遠比“我們已完成 95 % 的測試”更有意義。
測試工作量與測試用例的數量成比例。根據全面且細化的測試用例，可以更準確地估計測試周期各連續階段的時間安排。
測試設計和開發的類型以及所需的資源主要都受控於測試用例。
測試用例通常根據它們所關聯關係的測試類型或測試需求來分類，而且將隨類型和需求進行相應地改變。最佳方案是為每個測試需求至少編制兩個測試用例：

·一個測試用例用於證明該需求已經滿足，通常稱作正面測試用例；
·另一個測試用例反映某個無法接受、反常或意外的條件或數據，用於論證只有在所需條件下才能夠滿足該需求，這個測試用例稱作負面測試用例。

一、測試用例是軟體測試的核心

軟體測試的重要性是毋庸置疑的。但如何以最少的人力、資源投入，在最短的時間內完成測試，發現軟體系統的缺陷，保證軟體的優良品質，則是軟體公司探索和追求的目標。每個軟體產品或軟體開發項目都需要有一套優秀的測試方案和測試方法。

影響軟體測試的因素很多，例如軟體本身的複雜程度、開發人員（包括分析、設計、編程和測試的人員）的素質、測試方法和技術的運用等等。因為有些因素是客觀存在的，無法避免。有些因素則是波動的、不穩定的，例如開發隊伍是流動的，有經驗的走了，新人不斷補充進來；一個具體的人工作也受情緒等影響，等等。如何保障軟體測試質量的穩定？有了測試用例，無論是誰來測試，參照測試用例實施，都能保障測試的質量。可以把人為因素的影響減少到最小。即便最初的測試用例考慮不周全，隨著測試的進行和軟體版本更新，也將日趨完善。

因此測試用例的設計和編制是軟體測試活動中最重要的。測試用例是測試工作的指導，是軟體測試的必須遵守的準則。更是軟體測試質量穩定的根本保障。

二、編制測試用例

著重介紹一些編制測試用例的具體做法。

1、測試用例文檔

編寫測試用例文檔應有文檔模板，須符合內部的規範要求。測試用例文檔將受制於測試用例管理軟體的約束。
軟體產品或軟體開發項目的測試用例一般以該產品的軟體模組或子系統為單位，形成一個測試用例文檔，但並不是絕對的。

測試用例文檔由簡介和測試用例兩部分組成。簡介部分編制了測試目的、測試範圍、定義術語、參考文檔、概述等。測試用例部分逐一列示各測試用例。每個具體測試用例都將包括下列詳細信息：用例編號、用例名稱、測試等級、入口準則、驗證步驟、期望結果（含判斷標準）、出口準則、注釋等。以上內容??，測試輸入，測試操作，預期結果，評價標準。

2、測試用例的設定

我們早期的測試用例是按功能設定用例。後來引進了路徑分析法，按路徑設定用例。目前演變為按功能、路徑混合模式設定用例。

按功能測試是最簡捷的，按用例規約遍歷測試每一功能。

對於複雜操作的程式模組，其各功能的實施是相互影響、緊密相關、環環相扣的，可以演變出數量繁多的變化。沒有嚴密的邏輯分析，產生遺漏是在所難免。路徑分析是一個很好的方法，其最大的優點是在於可以避免漏測試。

但路徑分析法也有局限性。在一個非常簡單字典維護模組就存在十餘條路徑。一個複雜的模組會有幾十到上百條路徑是不足為奇的。筆者以為這是路徑分析比較合適的使用規模。若一個子系統有十餘個或更多的模組，這些模組相互有關聯。再採用路徑分析法，其路徑數量成幾何級增長，達5位數或更多，就無法使用了。那么子系統模組間的測試路徑或測試用例還是要靠傳統方法來解決。這是按功能、路徑混合模式設定用例的由來。

3、設計測試用例

測試用例可以分為基本事件、備選事件和異常事件。設計基本事件的用例，應該參照用例規約（或設計規格說明書），根據關聯的功能、操作按路徑分析法設計測試用例。而對孤立的功能則直接按功能設計測試用例。基本事件的測試用例應包含所有需要實現的需求功能，覆蓋率達100%。

設計備選事件和異常事件的用例，則要複雜和困難得多。例如，字典的代碼是唯一的，不允許重複。測試需要驗證：字典新增程式中已存在有關字典代碼的約束，若出現代碼重複必須報錯，並且報錯文字正確。往往在設計編碼階段形成的文檔對備選事件和異常事件分析描述不夠詳盡。而測試本身則要求驗證全部非基本事件，並同時儘量發現其中的軟體缺陷。

可以採用軟體測試常用的基本方法：等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、邏輯覆蓋法等設計測試用例。視軟體的不同性質採用不同的方法。如何靈活運用各種基本方法來設計完整的測試用例，並最終實現暴露隱藏的缺陷，全憑測試設計人員的豐富經驗和精心設計。

三、測試用例在軟體測試中的作用

1、指導測試的實施

測試用例主要適用於集成測試、系統測試和回歸測試。在實施測試時測試用例作為測試的標準，測試人員一定要按照測試用例嚴格按用例項目和測試步驟逐一實施測試。並對測試情況記錄在測試用例管理軟體中，以便自動生成測試結果文檔。

根據測試用例的測試等級，集成測試應測試那些用例，系統測試和回歸測試又該測試那些用例，在設計測試用例時都已作明確規定，實施測試時測試人員不能隨意作變動。

2、規劃測試數據的準備

在我們的實踐中測試數據是與測試用例分離的。按照測試用例配套準備一組或若干組測試原始數據，以及標準測試結果。尤其象測試報表之類數據集的正確性，按照測試用例規劃準備測試數據是十分必須的。
除正常數據之外，還必須根據測試用例設計大量邊緣數據和錯誤數據。

3、編寫測試腳本的"設計規格說明書"

為提高測試效率，軟體測試已大力發展自動測試。自動測試的中心任務是編寫測試腳本。如果說軟體工程中軟體編程必須有設計規格說明書，那么測試腳本的設計規格說明書就是測試用例。

4、評估測試結果的度量基準

完成測試實施後需要對測試結果進行評估，並且編制測試報告。判斷軟體測試是否完成、衡量測試質量需要一些量化的結果。例：測試覆蓋率是多少、測試合格率是多少、重要測試合格率是多少，等等。以前統計基準是軟體模組或功能點，顯得過於粗糙。採用測試用例作度量基準更加準確、有效。

5、分析缺陷的標準

通過收集缺陷，對比測試用例和缺陷資料庫，分析確證是漏測還是缺陷復現。漏測反映了測試用例的不完善，應立即補充相應測試用例，最終達到逐步完善軟體質量。而已有相應測試用例，則反映實施測試或變更處理存在問題。

四、相關問題

1、測試用例的評審

測試用例是軟體測試的準則，但它並不是一經編制完成就成為準則。測試用例在設計編制過程中要組織同級互查。完成編制後應組織專家評審，需獲得通過才可以使用。評審委員會可由項目負責人、測試、編程、分析設計等有關人員組成，也可邀請客戶代表參加。

2、測試用例的修改更新

測試用例在形成文檔後也還需要不斷完善。主要來自三方面的緣故：第一、在測試過程中發現設計測試用例時考慮不周，需要完善；第二、在軟體交付使用後反饋的軟體缺陷，而缺陷又是因測試用例存在漏洞造成；第三、軟體自身的新增功能以及軟體版本的更新，測試用例也必須配套修改更新。

一般小的修改完善可在原測試用例文檔上修改，但文檔要有更改記錄。軟體的版本升級更新，測試用例一般也應隨之編制升級更新版本。

3、測試用例的管理軟體

運用測試用例還需配備測試用例管理軟體。它的主要功能有三個：第一、能將測試用例文檔的關鍵內容，如編號、名稱等等自動導入管理資料庫，形成與測試用例文檔完全對應的記錄；第二、可供測試實施時及時輸入測試情況；第三、最終實現自動生成測試結果文檔，包含各測試度量值，測試覆蓋表和測試通過或不通過的測試用例清單列表。

有了管理軟體，測試人員無論是編寫每日的測試工作日誌、還是出軟體測試報告，都會變得輕而易舉。

五、測試用例的設計

（一）白盒技術

白盒測試是結構測試，所以被測對象基本上是源程式，以程式的內部邏輯為基礎設計測試用例。
1、邏輯覆蓋
程式內部的邏輯覆蓋程度，當程式中有循環時，覆蓋每條路徑是不可能的，要設計使覆蓋程度較高的或覆蓋最有代表性的路徑的測試用例。下面根據圖7-1所示的程式，分別討論幾種常用的覆蓋技術。
(1)語句覆蓋。
為了個提高發現錯誤的可能性，在測試時應該執行到程式中的每一個語句。語句覆蓋是指設計足夠的測試用例，使是一個被測試程式流程圖：

(2)判定覆蓋。
判定覆蓋指設計足夠的測試用例，使得被測程式中每個判定表達式至少獲得一次“真”值和“假”值，從而使程式的每一個分支至少都通過一次，因此判定覆蓋也稱分支覆蓋。
(3)條件覆蓋。
條件覆蓋是指設計足夠的測試用例，使得判定表達式中每個條件的各種可能的值至少出現一次。
(4)判定/條件測試。
該覆蓋標準指設計足夠的測試用例，使得判定表達式的每個條件的所有可能取值至少出現一次，並使每個判定表達式所有可能的結果也至少出現一次。
(5)條件組合覆蓋。
條件組合覆蓋是比較強的覆蓋標準，它是指設計足夠的測試用例，使得每個判定表達式中條件的各種可能的值的組合都至少出現一次。
(6)路徑覆蓋。
路徑覆蓋是指設計足夠的測試用例，覆蓋被測程式中所有可能的路徑。
在實際的邏輯覆蓋測試中，一般以條件組合覆蓋為主設計測試用例，然後再補充部分用例，以達到路徑覆蓋測試標準。
2.循環覆蓋
3.基本路徑測試

（二）黑盒技術

1.等價類劃分
(1)劃分等價類。
①如果某個輸入條件規定了取值範圍或值的個數。則可確定一個合理的等價類(輸入值或數在此範圍內)和兩個不合理等價類(輸入值或個數小於這個範圍的最小值或大於這個範圍的最大值)。
②如果規定了輸入數據的一組值，而且程式對不同的輸入值做不同的處理，則每個允許輸入值是一個合理等價類，此處還有一個不合理等價類(任何一個不允許的輸入值)。
③如果規定了輸入數據必須遵循的規則，可確定一個合理等價類(符合規則)和若干個不合理等價類(從各種不同角度違反規則)。
④如果已劃分的等價類中各元素在程式中的處理方式不同，則應將此等價類進一步劃分為更小的等價類。
(2)確定測試用例。
①為每一個等價類編號。
②設計一個測試用例，使其儘可能多地覆蓋尚未被覆蓋過的合理等價類。重複這步，直到所有合理等價類被測試用例覆蓋。
③設計一個測試用例，使其只覆蓋一個不合理等價類。
2.邊界值分析
使用邊界值分析方法設計測試用例時一般與等價類劃分結合起來。但它不是從一個等價類中任選一個例子作為代表，而是將測試邊界情況作為重點目標，選取正好等於、剛剛大於或剛剛小於邊界值的測試數據。
(1)如果輸入條件規定了值的範圍，可以選擇正好等於邊界值的數據作為合理的測試用例，同時還要選擇剛好越過邊界值的數據作為不合理的測試用例。如輸入值的範圍是【1，100】，可取0，1，100，101等值作為測試數據。
(2)如果輸入條件指出了輸入數據的個數，則按最大個數、最小個數、比最小個數少1、比最大個數多1等情況分別設計測試用例。如，一個輸入檔案可包括1--255個記錄，則分別設計有1個記錄、255個記錄，以及0個記錄的輸入檔案的測試用例。
(3)對每個輸出條件分別按照以上原則(1)或(2)確定輸出值的邊界情況。如，一個學生成績管理系統規定，只能查詢95--98級大學生的各科成績，可以設計測試用例，使得查詢範圍內的某一屆或四屆學生的學生成績，還需設計查詢94級、99級學生成績的測試用例(不合理輸出等價類)。
由於輸出值的邊界不與輸入值的邊界相對應，所以要檢查輸出值的邊界不一定可能，要產生超出輸出值之外的結果也不一定能做到，但必要時還需試一試。
(4)如果程式的規格說明給出的輸入或輸出域是個有序集合(如順序檔案、線形表、鍊表等)，則應選取集合的第一個元素和最後一個元素作為測試用例。
3.錯誤推測
在測試程式時，人們可能根據經驗或直覺推測程式中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試用例，這就是錯誤推測法。
4.因果圖
等價類劃分和邊界值方法分析方法都只是孤立地考慮各個輸入數據的測試功能，而沒有考慮多個輸入數據的組合引起的錯誤。
5.綜合策略
每種方法都能設計出一組有用例子，用這組例子容易發現某種類型的錯誤，但可能不易發現另一類型的錯誤。因此在實際測試中，聯合使用各種測試方法，形成綜合策略，通常先用黑盒法設計基本的測試用例，再用白盒法補充一些必要的測試用例。

六、測試用例設計的誤區

·能發現到目前為止沒有發現的缺陷的用例是好的用例；

首先要申明，其實這句話是十分有道理的，但我發現很多人都曲解了這句話的原意，一心要設計出發現“難於發現的缺陷”而陷入盲目的片面中去，忘記了測試的目的所在，這是十分可怕的。我傾向於將測試用例當作一個集合來認識，對它的評價也只能對測試用例的集合來進行，測試本身是一種“V&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 包含大量的感測器，用以監控各種功能，如電源檢測器、不同的門和出入口處的測壓器以及動作檢測器等。在任一時刻，如果某個感測器被激活，則警報信號將傳送給警方而且 ATM 進入“安全模式”，在此模式下所有功能都暫停使用，直到採取適當的重啟/重新初始化的措施。
在第一次疊代中，根據疊代計畫，我們需要核實提款用例已經正確地實施。此時尚未實施整個用例，只實施了下面的事件流： 基本流 - 提取預設金額（10 美元、20 美元、50 美元、100 美元） 備選流 2 - ATM 內沒有現金 備選流 3 - ATM 內現金不足 備選流 4 - PIN 有誤 備選流 5 - 帳戶不存在/帳戶類型有誤 備選流 6 - 帳面金額不足

可以從這個用例生成下列場景

場景 1 - 成功的提款	基本流
場景 2 - ATM 內沒有現金	基本流	備選流 2
場景 3 - ATM 內現金不足	基本流	備選流 3
場景 4 - PIN 有誤（還有輸入機會）	基本流	備選流 4
場景 5 - PIN 有誤（不再有輸入機會）	基本流	備選流 4
場景 6 - 帳戶不存在/帳戶類型有誤	基本流	備選流 5
場景 7 - 帳戶餘額不足	基本流	備選流 6

註：為方便起見，備選流 3 和 6（場景 3 和 7）內的循環以及循環組合未納入上表。

對於這 7 個場景中的每一個場景都需要確定測試用例。可以採用矩陣或決策表來確定和管理測試用例。??用例，而各列則代表測試用例的信息。本示例中，對於每個測試用例，存在一個測試用例 ID、條件（或說明）、測試用例中涉及的所有數據元素（作為輸入或已經存在於資料庫中）以及預期結果。

通過從確定執行用例場景所需的數據元素入手構建矩陣。然後，對於每個場景，至少要確定包含執行場景所需的適當條件的測試用例。例如，在下面的矩陣中，V（有效）用於表明這個條件必須是 VALID（有效的）才可執行基本流，而 I（無效）用於表明這種條件下將激活所需備選流。下表中使用的“n/a”（不適用）表明這個條件不適用於測試用例。

TC（測試用例）ID 號	場景/條件	PIN	帳號	輸入的金額 （或選擇的金額）	帳面金額	ATM 內的金額	預期結果
CW1.	場景 1 - 成功的提款	V	V	V	V	V	成功的提款。
CW2.	場景 2 - ATM 內沒有現金	V	V	V	V	I	提款選項不可用，用例結束
CW3.	場景 3 - ATM 內現金不足	V	V	V	V	I	警告訊息，返回基本流步驟 6 - 輸入金額
CW4.	場景 4 - PIN 有誤（還有不止一次輸入機會）	I	V	n/a	V	V	警告訊息，返回基本流步驟 4，輸入 PIN
CW5.	場景 4 - PIN 有誤（還有一次輸入機會）	I	V	n/a	V	V	警告訊息，返回基本流步驟 4，輸入 PIN
CW6.	場景 4 - PIN 有誤（不再有輸入機會）	I	V	n/a	V	V	警告訊息，卡予保留，用例結束

在上面的矩陣中，六個測試用例執行了四個場景。對於基本流，上述測試用例 CW1 稱為正面測試用例。它一直沿著用例的基本流路徑執行，未發生任何偏差。基本流的全面測試必須包括負面測試用例，以確保只有在符合條件的情況下才執行基本流。這些負面測試用例由 CW2 至 6 表示（陰影單元格表明這種條件下需要執行備選流）。雖然 CW2 至 6 對於基本流而言都是負面測試用例，但它們相對於備選流 2 至 4 而言是正面測試用例。而且對於這些備選流中的每一個而言，至少存在一個負面測試用例（CW1 - 基本流）。

每個場景只具有一個正面測試用例和負面測試用例是不充分的，場景 4 正是這樣的一個示例。要全面地測試場景 4 - PIN 有誤，至少需要三個正面測試用例（以激活場景 4）：

• 輸入了錯誤的 PIN，但仍存在輸入機會，此備選流重新加入基本流中的步驟 3 - 輸入 PIN。
• 輸入了錯誤的 PIN，而且不再有輸入機會，則此備選流將保留銀行卡並終止用例。
• 最後一次輸入時輸入了“正確”的 PIN。備選流在步驟 5 - 輸入金額處重新加入基本流。

註：在上面的矩陣中，無需為條件（數據）輸入任何實際的值。以這種方式創建測試用例矩陣的一個優點在於容易看到測試的是什麼條件。由於只需要查看 V 和 I（或此處採用的陰影單元格），這種方式還易於判斷是否已經確定了充足的測試用例。從上表中可發現存在幾個條件不具備陰影單元格，這表明測試用例還不完全，如場景 6 - 不存在的??測試用例。

一旦確定了所有的測試用例，則應對這些用例進行複審和驗證以確保其準確且適度，並取消多餘或等效的測試用例。

測試用例一經認可，就可以確定實際數據值（在測試用例實施矩陣中）並且設定測試數據

TC（測試用例）ID 號	場景/條件	PIN	帳號	輸入的金額 （或選擇的金額）	帳面金額	ATM 內的金額	預期結果
CW1.	場景 1 - 成功的提款	4987	809 - 498	50.00	500.00	2,000	成功的提款。帳戶餘額被更新為 450.00
CW2.	場景 2 - ATM 內沒有現金	4987	809 - 498	100.00	500.00	0.00	提款選項不可用，用例結束
CW3.	場景 3 - ATM 內現金不足	4987	809 - 498	100.00	500.00	70.00	警告訊息，返回基本流步驟 6 - 輸入金額
CW4.	場景 4 - PIN 有誤（還有不止一次輸入機會）	4978	809 - 498	n/a	500.00	2,000	警告訊息，返回基本流步驟 4，輸入 PIN
CW5.	場景 4 - PIN 有誤（還有一次輸入機會）	4978	809 - 498	n/a	500.00	2,000	警告訊息，返回基本流步驟 4，輸入 PIN
CW6.	場景 4 - PIN 有誤（不再有輸入機會）	4978	809 - 498	n/a	500.00	2,000	警告訊息，卡予保留，用例結束

以上測試用例只是在本次疊代中需要用來驗證提款用例的一部分測試用例。需要的其他測試用例包括：

• 場景 6 - 帳戶不存在/帳戶類型有誤：未找到帳戶或帳戶不可用
• 場景 6 - 帳戶不存在/帳戶類型有誤：禁止從該帳戶中提款
• 場景 7 - 帳戶餘額不足：請求的金額超出帳面金額

在將來的疊代中，當實施其他事件流時，在下列情況下將需要測試用例：

• 無效卡（所持卡為掛失卡、被盜卡、非承兌銀行發卡、磁條損壞等）
• 無法讀卡（讀卡機堵塞、脫機或出現故障）
• 帳戶已消戶、凍結或由於其他方面原因而無法使用
• ATM 內的現金不足或不能提供所請求的金額（與 CW3 不同，在 CW3 中只是一種幣值不足，而不是所有幣值都不足）
• 無法聯繫銀行系統以獲得認可
• 銀行網路離線或交易過程中斷電

在確定功能性測試用例時，確保滿足下列條件：

• 已經為每個用例場景確定了充足的正面和負面測試用例。
• 測試用例可以處理用例所實施的所有業務規則，確保對於業務規則，無論是在內部、外部還是在邊界條件/值上都存在測試用例。
• 測試用例可以處理所wiki/%E8%A8%AD%E8%A8%88%E6%A8%A1%E5%9E%8B target="_new">設計模型的序列圖中確定的內容），還應能處理用戶界面對象狀態或條件。
• 測試用例可以處理為用例所指定的任何特殊需求，如最佳/最差性能，有時這些特殊需求會與用例執行過程中的最小/最大負載或數據容量組合在一起。

八、從補充規約中生成測試用例

並不是所有的測試目標需求都將在用例中有所反映。非功能性需求（如性能、安全性和訪問控制）以及配置要求等將會說明測試目標的其他行為或特徵。補充規約是為其他行為生成測試用例的主要來源。

關於如何生成這些其他測試用例的指南說明如下：

• 為性能測試生成測試用例
• 為安全性/訪問控制測試生成測試用例
• 為配置測試生成測試用例
• 為安裝測試生成測試用例
• 為其他非功能性測試生成測試用例

為性能測試生成測試用例

性能測試用例的主要輸入是補充規約，補充規約中包含了非功能性需求（請參見工件：補充規約）。為性能測試生成測試用例時，請使用下列指南：

• 對於補充規約內闡明性能標準的各條說明都應確保至少要確定一個測試用例。性能標準通常表示為時間/事務、事務量/用戶或百分數的形式。
• 對每個關鍵用例，都應確保至少要確定一個測試用例。關鍵用例是在上述說明中和/或在工作量分析文檔中確定的、必須採用性能評測方法來評估的用例（請參見工件：工作量分析文檔）。

與功能性測試的測試用例類似，通常對於每個用例/需求都會存在不止一個測試用例。常見的情況是：存在一個低於性能閾值的測試用例、一個處於閾值上的測試用例，還有一個測試用例高於閾值。

除了以上性能標準以外，確保已確定影響回響時間的特定條件，包括：

• 資料庫的大小 - 存在多少個記錄？
• 工作量 - 同時執行操作的最終用戶的數量和類型，以及要同時執行的事務的數量和類型
• 環境特徵（硬體、網件以及軟體配置）

將用於性能測試的測試用例記錄在類似於功能測試所使用的矩陣中。

以下是各種性能測試的一些示例：

對於負載測試：

TC（測試用例）ID 號	工作量	條件	預期結果
PCW1.	1 （單個 ATM）	完成提款交易	全部交易（不依賴於主角的時間）在 20 秒之內完成
PCW2.	2 （1,000 個同時運行的 ATM）	完成提款交易	全部交易（不依賴於主角的時間）在 30 秒之內完成
PCW3.	3 （10.000 個同時運行的 ATM）	完成提款交易	全部交易（不依賴於主角的時間）在 50 秒之內完成

對於強度測試：

TC（測試用例）ID 號	工作量	條件	預期結果
SCW1.	2 （1,000 個同時運行的 ATM）	資料庫鎖定 - 2 個 ATM 請求同一帳戶	ATM 請求排成佇列
SCW2.	2 （1,000 個同時運行的 ATM）	無法實現銀行系統的通信	交易排成佇列或逾時
SCW3.	2 （1,000 個同時運行的 ATM）	在交易過程中，銀行系統通信被終止	顯示警告訊息

為安全性訪問控制測試生成用例

主角和用例一同說明系統外部用戶與系統所執行的動作之間的互動，以便為特定主角生成測試結果。複雜系統包含許多主角，所以我們編制測試用例時必須確保只有指定執行用例的主角可以進行此操作，這一點非常關鍵。在基於主角類型的用例事件流存在差別時，尤其如此。

例如，在 ATM 用例中，如果主角“銀行客戶”的卡和帳戶有的屬於擁有這個 ATM 機的銀行，有的是競爭銀行的銀行卡（和帳戶），或是企圖使用該 ATM 不支持的銀行卡，則將對該主角“銀行客戶”執行不同的用例事件流。

對於功能性測試用例，請同樣遵循上面列舉的指南。

關於安全性和訪問控制測試用例的示例：

TC（測試用例）ID 號	條件	卡 （V 表明卡有效）	讀卡機 （V 表明讀卡機工作正常）	銀行的網路	預期結果
ACW1.	在銀行網路之內	V	V	V	所有用例都可用
ACW2.	銀行網路之外	V	V	I	只有提款用例可用
ACW3.	無法讀卡	I	V	V	警告訊息，卡被退出
ACW4.	因被盜，卡已掛失	I	V	V	警告訊息，卡予保留
ACW5.	卡已過期	I	V	V	警告訊息，卡予保留

為配置測試生成測試用例

在典型的分散式系統中，允許存在許多種受支持的硬體和軟體組合。為了核實測試目標在不同的配置情況下（如不同的作業系統、瀏覽器或 CPU 的速度）能否正常工作或執行，應該對此進行測試。此外，測試還應涵蓋構件的組合，以便檢測在不同構件的互動中產生的缺陷。例如，確保由應用程式安裝的 DDL 版本不會與另一個應用程式需要的相同 DDL 的版本發生衝突。

採用下列指南來生成用於配置測試的測試用例：

• 確保對每個關鍵配置，應至少存在一個測試用例可用於對其進行確定。這是通過確定測試目標的環境所要求的硬體和軟體配置以及確定這些配置的優先權來完成的。應確保最先測試最常見的配置，包括：
  • 印表機支持
  • 網路連線 - 區域網路和廣域網
  • 伺服器配置 - 伺服器驅動程式、伺服器硬體
  • 台式機和/或伺服器上安裝的其他軟體
  • 所有已安裝軟體的軟體版本
• 確保對於每個可能有問題的配置至少存在一個測試用例。這些配置可能包括：
  • 具有最低性能的硬體。
  • 歷史上存在兼容性問題的共駐記憶體的軟體。
  • 通過最慢的 LAN/WAN 連線訪問伺服器的客戶機。
  • 資源不足（緩慢的 CPU 速度、最小的記憶體或解析度，磁碟空間不足等等）

為安裝測試生成測試用例

安裝測試需要核實測試目標可以在所有可能的安裝情況下安裝。安裝情況可以指首次安裝測試目標，或是在裝有較早版本的機器上安裝測試目標的某個較新的版本或工作版本。安裝測試還應確保在遇到異常情況時（如磁碟空間不足），測試目標的執行情況仍可接受。

測試用例應包含以下各種軟體的安裝情況：

• 分發介質，例如磁碟、CD-ROM 或檔案伺服器。
• 首次安裝。
• 完全安裝。
• 自定義安裝。
• 升級安裝。

客戶機伺服器軟體的安裝程式具備一組特定的測試用例。不同於基於主機的系統，伺服器和客戶機上的安裝程式是有所不同的。因而，安裝測試應執行構成測試目標的所有構件的安裝，包括客戶機、中間層以及伺服器，這一點至關重要。

為其他非功能性測試生成測試用例

理論上,應找到所有必需的輸入來生成測試用例模型、設計模型以及補充規約工件的測試用例。不過，如果此時您需要補充已有的輸入，那也不足為奇。

示例如下：

• 操作測試（用以檢驗在某次故障發生後以及在下一次故障發生前“較長時間”內軟體的運行情況）的測試用例。
• 對性能瓶頸、系統容量或測試目標的強度承受能力進行調查的測試用例。

大多數情況下，您可以通過先前所確定的測試用例生成的某些測試用例來構建其變體或聚合關係體，藉此來查找測試用例。

九、為單元測試生成測試用例

單元測試要求既測試單元的內部結構同時還要測試其行為特徵。測試內部結構要求了解實施單元的方式，基於這種了解的測試被稱為白盒測試。對單元行為特徵的測試側重於從外部可觀察的單元行為，而不需要了解或考慮其實施方式。基於這種方法的測試稱為黑盒測試。基於這兩種方法所生成的測試用例的說明如下。

白盒測試

理論上，應通過代碼測試每一條可能的路徑。在所有這些非常簡單的單元內實現這樣的目標是不切實際或幾乎是不可能的。作為最基本的測試，應將每個決定到決定路徑（DD 路徑）測試至少一次，這樣可確保將所有語句至少執行一次。決定通常是指 if 語句，而 DD 路徑是兩個決定之間的路徑。

要達到這種程度的測試覆蓋，建議您在選擇測試數據時應使每個決定都可以用每種可能的方法來評估。為達到上述目標，測試用例應確保：

每個布爾表達式的求值結果為 true 和 false。例如，表達式 (a<3) OR (b>4) 的求值結果為 true/false 的四種組合
每一個無限循環至少要執行零次、一次和一次以上。
可使用代碼覆蓋工具來確定白盒測試未測試到的代碼。在進行白盒測試的同時應進行可靠性測試。

示例：

假設您對類 Set of Integers 中的 member 函式執行結構測試。該測試在二進制搜尋的幫助下，將檢查該集合是否包含了某個指定的整數。

成員 (member) 函式以及相應的流程圖。虛線箭頭指示出如何通過採用兩個測試用例將所有語句至少執行一次。

理論上，對於徹底測試的某個操作，測試用例應遍歷代碼內路徑的所有組合情況。在 member 函式的 while-loop 中存在三個可選擇的路徑。測試用例可以多次遍歷該循環，或是根本就不遍歷。如果測試用例根本就沒有遍歷循環，則在代碼中只能找到一條路徑。如果遍歷循環一次，您將發現有三條路徑。如果遍歷兩次，則您將發現存在六條路徑，如此類推。因而，路徑的總數應該是：1+3+6+12+24+48+...，在實際情況中，這個路徑組合總數根本無法無法處理。這就是為什麼必須選擇所有這些路徑的子集的原因。本示例中，可以採用兩個測試用例來執行所有的語句。其中一個測試用例中，您可以選擇 Set of Integers = {1,5,7,8,11}，而且測試數據 t = 3。在另一個測試用例中，您可以選擇 Set of Integers = {1,5,7,8,11}，且 t = 8。

黑盒測試

黑盒測試的目的是為了在不了解單元將如何實施指定行為的情況下，對指定行為進行驗證。黑盒測試側重並依賴於單元的輸入和輸出。

等價類劃分是一種用來減少所需測試數量的技術。對於每一個操作都應確定參數和對象狀態的等價類。等價類是一組值的集合，對這組值來說，對象的行為應類似。例如，一個集合可有三個等價類：空、若干元素以及滿。

可使用代碼覆蓋工具來確定白盒測試未測試到的代碼。在進行黑盒測試的同時應進行可靠性測試。

接下來的兩個小節說明了如何通過選擇特定參數的測試數據來確定測試用例。

基於輸入參數的測試用例
輸入參數是由某個操作使用的參數。對於以下每個輸入條件，都應通過使用每個操作的輸入參數來編制測試用例：

每個等價類的正常值。
每個等價類的邊界值。
等價類之外的值。
非法值。
請記住要將對象狀態視作輸入參數。例如：如果在對集合這個對象測試添加操作，您必須使用集合內所有等價類的值來測試添加操作。所有等價類的值指的是：充滿元素的集合、有若干元素的集合、以及空集合。

基於輸出參數的測試用例
輸出參數是某個操作所改變的參數。某個參數既可以是輸入參數也可以是輸出參數。根據以下每個條件選擇輸入，以便獲得輸出。

每個等價類的正常值。
每個等價類的邊界值。
等價類之外的值。
非法值。
請記住將對象狀態視為輸出參數。例如，假設您對某個列表測試刪除操作，您必須選擇輸入值以便執行操作之後，列表為充滿狀態、具有若干元素或為空（採用它的所有等價類的值進行測試）。

如果對象受狀態控制（根據對象的狀態產生不同的反應），您應利用狀態矩陣，如下圖所示：

用於測試的狀態矩陣。您可以在此矩陣的基礎上測試激勵和狀態的所有組合。

十、為產品驗收測試生成測試用例

產品驗收測試是部署軟體前的最後測試操作。驗收測試的目標在於核實軟體是否已經準備就緒，而且可以由最終用戶按軟體設計來執行功能和任務。產品驗收測試通常不僅涉及執行軟體以確認其是否準備就緒，還涉及交付給客戶的所有產品工件，如培訓、文檔和包裝。

為軟體工件生成測試用例是按上文中說明的方式實現的。測試用例可與上面確定的測試用例（正式）或某個子集（非正式）相同或類似，這取決於產品驗收測試的正式程度。不管測試用例的深度如何，應該在實施和執行產品測試之前對測試用例和產品驗收計畫達成共識。

對非軟體工件的評估將隨著被評估工件的不同而相去甚遠。請參見每個特定非軟體工件的指南以及核對清單，查看這些工件的評估內容和評估方式。

十一、為回歸測試編制測試用例

回歸測試比較同一測試目標的兩個工作版本或版本，並將差異確定為潛在缺陷。據此可假定：新版本應該象早先版本一樣操作，並確保並未因為版本的變化而帶來缺陷。

理想狀態下，您可能希望一次疊代內的所有測試用例都能在後續疊代內使用。應遵照下列指導原則來確定、設計並實施測試用例，這些測試用例可以最大限度地發揮回歸測試和復用的價值，同時將維護的成本減至最低：

確保測試用例只確定關鍵的數據元素（創建/支持被測試的條件所需的數據元素）
確保每個測試用例都說明或代表一個唯一的輸入集或事件序列，其結果是獨特的測試目標行為
消除多餘或等效的測試用例
將具有相同的測試目標初始狀態和測試數據狀態的測試用例組合到一起

測試用例設計原則

1.測試用例的代表性：能夠代表並覆蓋各種合理的和不合理的、合法的和非法的、邊界的和越界的以及極限的輸入數據、操作和環境設定等。
2.測試結果的可判定性：即測試執行結果的正確性是可判定的，每一個測試用例都應有相應的期望結果。
3.測試結果的可再現性：即對同樣的測試用例，系統的執行結果應當是相同的。
===============================================================
測試用例的特點：
完整
完整性是對測試用例最基本的要求，尤其是一些基本功能項上，如果有遺漏，那將是不可原諒的。完整性還體現在中斷測試、臨界測試、壓力測試、性能測試等方面，這方面測試用例也要能夠涉及到。
準確
測試者按照測試用例的輸入一步步測試完成後，要能夠根據測試用例描述的輸出得出正確的結論,不能出現模糊不清的語言。
簡潔
好的測試用例每一步都應該有回響的作用，有很強的針對性，不應該出現一些冗繁無用的操作步驟。測試用例不應該太簡單，也不能夠太過複雜，最大操作步驟最好控制在10-15步之間。
清晰
清晰包括描述清晰,步驟條理清晰,測試層次清晰(由簡而繁,從基本功能測試到破壞性測試)。清晰簡潔對測試用例編寫者的邏輯思維和文字表達能力提出了較高的要求。
可維護性
由於軟體開發過程中需求變更等原因的影響，常常需要對測試用例進行修改、增加、刪除等，以便測試用例符合相應測試要求。測試用例應具備這方面的功能
適當性
測試例應該適合特定的測試環境以及符合整個團隊的測試水平，如純英語環境下的測試用例最好使用英文編寫。
可復用性
要求不同測試者在同樣測試環境下使用同樣測試用例都能得出相同結論。
其他
如可追朔性、可移植性也是對編寫測試用例的一個要求