測試用例:特定的軟件産品進行測試任務的描述-中文百科頻道

概述

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

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

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

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

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

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

測試用例構成了設計和制定測試過程的基礎。

測試的“深度”與測試用例的數量成比例。由于每個測試用例反映不同的場景、條件或經由産品的事件流，因而，随着測試用例數量的增加，您對産品質量和測試流程也就越有信心。

判斷測試是否完全的一個主要評測方法是基于需求的覆蓋，而這又是以确定、實施和/或執行的測試用例的數量為依據的。類似下面這樣的說明：“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%左右的時間，測試設計工程師能夠根據項目的需要自行确定用例的詳細程度，在測試用例的評審階段由參與評審的相關人對其把關。

·測試用例設計是一勞永逸的事情；

這句話擺在這裡，我想沒有一個人會認可，但在實際情況中，卻經常能發現這種想法的影子。我曾經參與過一個項目，軟件需求和設計已經變更了多次，但測試用例卻沒有任何修改。導緻的直接結果是新加入的測試工程師在執行測試用例時不知所措，間接的後果是測試用例成了廢紙一堆，開發人員在多次被無效的缺陷報告打擾後，對測試人員不屑一顧。

這個例子可能有些極端，但測試用例與需求和設計不同步的情況在實際開發過程中确是屢見不鮮的，測試用例文檔是“活的”文檔，這一點應該被測試工程師牢記。

·測試用例不應該包含實際的數據；

測試用例是“一組輸入、執行條件、預期結果”、毫無疑問地應該包括清晰的輸入數據和預期輸出，沒有測試數據的用例最多隻具有指導性的意義，不具有可執行性。當然，測試用例中包含輸入數據會帶來維護、與測試環境同步之類的問題，關于這一點，《EffectiveSoftwareTest》一書中提供了詳細的測試用例、測試數據的維護方法，可以參考。

·測試用例中不需要明顯的驗證手段；

我見過很多測試工程師編寫的測試用例中，“預期輸出”僅描述為程序的可見行為，其實，“預期結果”的含義并不隻是程序的可見行為。例如，對一個訂貨系統，輸入訂貨數據，點擊“确定”按鈕後，系統提示“訂貨成功”，這樣是不是一個完整的用例呢？是不是系統輸出的“訂貨成功”就應該作為我們唯一的驗證手段呢？顯然不是。訂貨是否成功還需要查看相應的數據記錄是否更新，因此，在這樣的一個用例中，還應該包含對測試結果的顯式的驗證手段：在數據庫中執行查詢語句進行查詢，看查詢結果是否與預期的一緻。

七、從用例中生成測試用例

用于功能性測試的測試用例來源于測試目标的用例。應該為每個用例場??路徑來确定，這個流經過程要從用例開始到結束遍曆其中所有基本流和備選流。

例如，下圖中經過用例的每條不同路徑都反映了基本流和備選流，都用箭頭來表示。

基本流用直黑線來表示，是經過用例的最簡單的路徑。每個備選流自基本流開始，之後，備選流會在某個特定條件下執行。備選流可能會重新加入基本流中（備選流1和3），還可能起源于另一個備選流（備選流2），或者終止用例而不再重新加入某個流（備選流2和4）。

注：為方便起見，場景5、6和8隻描述了備選流3指示的循環執行一次的情況。

生成每個場景的測試用例是通過确定某個特定條件來完成的，這個特定條件将導緻特定用例場景的執行。

例如，假定上圖描述的用例對備選流3規定如下：

“如果在上述步驟2‘輸入提款金額’中輸入的美元量超出當前帳戶餘額，則出現此事件流。系統将顯示一則警告消息，之後重新加入基本流，再次執行上述步驟2‘輸入提款金額’，此時銀行客戶可以輸入新的提款金額。”

據此，可以開始确定需要用來執行備選流3的測試用例：

TCy

場景4

步驟2-提款金額<帳戶餘額

不執行備選流3，執行基本流

場景4

步驟2-提款金額<帳戶餘額

不執行備選流3，執行基本流

注：由于沒有提供其他信息，以上顯示的測試用例都非常簡單。測試用例很少如此簡單。

下面是一個由用例生成測試用例的更符合實際情況的示例。

示例：

一台ATM機器的主角和用例。

場景1-成功的提款

基本流

場景2-ATM内沒有現金

基本流

備選流2

場景3-ATM内現金不足

基本流

備選流3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

為性能測試生成測試用例

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

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

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

除了以上性能标準以外，确保已确定影響響應時間的特定條件，包括：

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

對于強度測試：

SCW1.

（1,000個同時運行的ATM）

數據庫鎖定-2個ATM請求同一帳戶

ATM請求排成隊列

SCW2.

（1,000個同時運行的ATM）

無法實現銀行系統的通信

交易排成隊列或超時

SCW3.

（1,000個同時運行的ATM）

在交易過程中，銀行系統通信被終止

顯示警告消息

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

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

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

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

為配置測試生成測試用例

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

采用下列指南來生成用于配置測試的測試用例：

确保對每個關鍵配置，應至少存在一個測試用例可用于對其進行确定。這是通過确定測試目标的環境所要求的硬件和軟件配置以及确定這些配置的優先級來完成的。應确保最先測試最常見的配置，包括：

打印機支持

網絡連接-局域網和廣域網

服務器配置-服務器驅動程序、服務器硬件

台式機和/或服務器上安裝的其他軟件

所有已安裝軟件的軟件版本

确保對于每個可能有問題的配置至少存在一個測試用例。這些配置可能包括：

具有最低性能的硬件。

曆史上存在兼容性問題的共駐内存的軟件。

通過最慢的LAN/WAN連接訪問服務器的客戶機。

資源不足（緩慢的CPU速度、最小的内存或分辨率，磁盤空間不足等等）

為安裝測試生成測試用例

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

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

分發介質，例如磁盤、CD-ROM或文件服務器。

首次安裝。

完全安裝。

自定義安裝。

升級安裝。

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

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

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

示例如下：

操作測試（用以檢驗在某次故障發生後以及在下一次故障發生前“較長時間”内軟件的運行情況）的測試用例。

對性能瓶頸、系統容量或測試目标的強度承受能力進行調查的測試用例。

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

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

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

白盒測試

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

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

每個布爾表達式的求值結果為true和false。例如，表達式(a<3)OR(b>4)的求值結果為true/false的四種組合

每一個無限循環至少要執行零次、一次和一次以上。

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

示例：

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

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

理論上，對于徹底測試的某個操作，測試用例應遍曆代碼内路徑的所有組合情況。在member函數的while-loop中存在三個可選擇的路徑。測試用例可以多次遍曆該循環，或是根本就不遍曆。如果測試用例根本就沒有遍曆循環，則在代碼中隻能找到一條路徑。如果遍曆循環一次，您将發現有三條路徑。

如果遍曆兩次，則您将發現存在六條路徑，如此類推。因而，路徑的總數應該是：1+3+6+12+24+48+...，在實際情況中，這個路徑組合總數根本無法無法處理。這就是為什麼必須選擇所有這些路徑的子集的原因。本示例中，可以采用兩個測試用例來執行所有的語句。其中一個測試用例中，您可以選擇SetofIntegers={1,5,7,8,11}，而且測試數據t=3。在另一個測試用例中，您可以選擇SetofIntegers={1,5,7,8,11}，且t=8。

黑盒測試

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

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

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

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

基于輸入參數的測試用例

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

每個等價類的正常值。

每個等價類的邊界值。

等價類之外的值。

非法值。

請記住要将對象狀态視作輸入參數。例如：如果在對集合這個對象測試添加操作，您必須使用集合内所有等價類的值來測試添加操作。所有等價類的值指的是：充滿元素的集合、有若幹元素的集合、以及空集合。