黑盒測試案例設計技術篇

1 ?概述

本章介紹黑盒測試的概念和進行黑盒測試的目的與意義，及關于等價類劃分、邊界值分析、因果圖法、判定表法、正交試驗法、功能圖法等測試用例設計方法的原理與實現，并從測試設計說明、測試用例說明、測試程序說明三個方面介紹如何編寫測試用例，最后結合一個ATM的例子體現如何設計測試用例。

2 ?測試用例設計方法

初涉軟件測試者可能認為拿到軟件后就可以立即進行測試，并希望馬上找出軟件的所有缺陷，這種想法就如同沒有受過工程訓練的開發工程師急于去編寫代碼一樣。軟件測試也是一個工程，也需要按照工程的角度去認識軟件測試，在具體的測試實施之前，我們需要明白我們測試什么，怎么測試等，也就是說通

過制定測試用例指導測試的實施。

2.1 ?什么是測試用例

所謂的測試用例設計就是將軟件測試的行為活動，作一個科學化的組織歸納。軟件測試是有組織性、步驟性和計劃性的，而設計軟件測試用例的目的，就是為了能將軟件測試的行為轉換為可管理的模式。軟件測試是軟件質量管理中最實際的行動，同時也是耗時最多的一項。基于時間因素的考慮，軟件測試行為必須能夠加以量化，才能進一步讓管理階層掌握所需要的測試過程，而測試用例就是將測試行為具體量化的方法之一。

簡單地說，測試用例就是設計一個情況，軟件程序在這種情況下，必須能夠正常運行并且達到程序所設計的執行結果。如果程序在這種情況下不能正常運行，而且這種問題會重復發生，那就表示軟件程序人員已經測出軟件有缺陷，這時候就必須將這個問題標示出來，并且輸入到問題跟蹤系統內，通知軟件開發人員。軟件開發人員接獲通知后，將這個問題修改完成于下一個測試版本內，軟件測試工程師取得新的測試版本后，必須利用同一個用例來測試這個問題，確保該問題已修改完成。

因為我們不可能進行窮舉測試，為了節省時間和資源、提高測試效率，必須要從數量極大的可用測試數據中精心挑選出具有代表性或特殊性的測試數據來進行測試。

使用測試用例的好處主要體現在以下幾個方面。

① 在開始實施測試之前設計好測試用例，可以避免盲目測試并提高測試效率。

② 測試用例的使用令軟件測試的實施重點突出、目的明確。

③ 在軟件版本更新后只需修正少部分的測試用例便可展開測試工作，降低工作強度，縮短項目周期。

④ 功能模塊的通用化和復用化使軟件易于開發，而測試用例的通用化和復用化則會使軟件測試易于開展，并隨著測試用例的不斷精化其效率也不斷攀升。

具體的黑盒測試用例設計方法包括等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、判定表驅動法、正交試驗設計法、功能圖法等。應該說，這些方法是比較實用的，但采用什么方法，在使用時自然要針對開發項目的特點對方法加以適當的選擇。下面我們討論幾種常用的方法。

2.2 ?等價類劃分法

等價類劃分是一種典型的黑盒測試方法，用這一方法設計測試用例完全不考慮程序的內部結構，只根據對程序的要求和說明，即需求規格說明書。我們必須仔細分析和推敲說明書的各項需求，特別是功能需求。把說明中對輸入的要求和輸出的要求區別開來并加以分解。

由于窮舉測試工作量太大，以至于無法實際完成，促使我們在大量的可能數據中選取其中的一部分作為測試用例。例如，在不了解等價分配技術的前提下，我們做計算器程序的加法測試時，測試了1+1，1+2，1+3和1+4之后，還有必要測試1+5和1+6嗎，能否放心地認為它們是正確的？我們感覺1+5和1+6，與前面的1+1，1+2都是很類似的簡單加法。

等價類劃分的辦法是把程序的輸入域劃分成若干部分，然后從每個部分中選取少數代表性數據作為測試用例。每一類的代表性數據在測試中的作用等價于這一類中的其他值，也就是說，如果某一類中的一個例子發現了錯誤，這一等價類中的其他例子也能發現同樣的錯誤；反之，如果某一類中的一個例子沒有發現錯誤，則這一類中的其他例子也不會查出錯誤（除非等價類中的某些例子屬于另一等價類，因為幾個等價類是可能相交的）。使用這一方法設計測試用例，首先必須在分析需求規格說明的基礎上劃分等價類，列出等價類表。

1．劃分等價類和列出等價類表

等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對于揭露程序中的錯誤都是等效的。并合理地假定：測試某等價類的代表值就等于對這一類其他值的測試。

因此，可以把全部輸入數據合理地劃分為若干等價類，在每一個等價類中取一個數據作為測試的輸入條件，就可以用少量代表性的測試數據取得較好的測試結果。等價類劃分有兩種不同的情況：有效等價類和無效等價類。

有效等價類：指對于程序的規格說明來說是合理的、有意義的輸入數據構成的集合。利用有效等價類可檢驗程序是否實現了規格說明中所規定的功能和性能。

無效等價類：與有效等價類的定義恰巧相反。

設計測試用例時，要同時考慮這兩種等價類。因為軟件不僅要能接收合理的數據，也要能經受意外的考驗。這樣的測試才能確保軟件具有更高的可靠性。

下面給出6條確定等價類的原則：

① 在輸入條件規定了取值范圍或值的個數的情況下，可以確立一個有效等價類和兩個無效等價類。

② 在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下，可以確立一個有效等價類和一個無效等價類。

③ 在輸入條件是一個布爾量的情況下，可確定一個有效等價類和一個無效等價類。

④ 在規定了輸入數據的一組值（假定n個），并且程序要對每一個輸入值分別處理的情況下，可確立n個有效等價類和一個無效等價類。

⑤ 在規定了輸入數據必須遵守的規則的情況下，可確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）。

⑥ 在確知已劃分的等價類中，各元素在程序處理中的方式不同的情況下，則應再將該等價類進一步地劃分為更小的等價類。

在確立了等價類之后，建立等價類表，列出所有劃分出的等價類如表5-1所示。

表5-1??等價類表示例

輸入條件有效等價類無效等價類輸入條件有效等價類無效等價類

………………

2．確定測試用例

根據已列出的等價類表，按以下步驟確定測試用例：

① 為每個等價類規定一個惟一的編號。

② 設計一個新的測試用例，使其盡可能多地覆蓋尚未覆蓋的有效等價類。重復這一步，最后使得所有有效等價類均被測試用例所覆蓋。

③ 設計一個新的測試用例，使其只覆蓋一個無效等價類。重復這一步使所有無效等價類均被覆蓋。

在尋找等價區間時，想辦法把軟件的相似輸入、輸出、操作分成組。這些組就是等價區間。請看一些例子。

在兩數相加用例中，測試1+13和1+99999999似乎有點不同。這是一種直覺，一個是普通加法，而另一個似乎有些特殊，這個直覺是對的。程序對1和最大數值相加的處理和對兩個小一些的數值相加的處理有所不同。后者必須處理溢出情況。因為軟件操作可能不同，所以這兩個用例屬于不同的等價區間。

如果具有編程經驗，就可能會想到更多可能導致軟件操作不同的“特殊”數值。如果不是程序員，也不用擔心，你很快就會學到這種技術，無須了解代碼細節就可以運用。

如圖5-1

如圖5-1所示是復制的多種方法，給出了選中編輯菜單后顯示復制和粘貼命令的計算器程序。每一項功能（即復制和粘貼）有5種執行方式。要想復制，可以單擊復制菜單命令，鍵入C，按Ctrl+C或Ctrl+Shift+C組合鍵。任何一種輸入途徑都會把當前數值復制到剪貼板中，一一執行同樣的輸出操作，產生同樣的結果。

如果要測試復制命令，可以把這5種輸入途徑劃分減為3個，單擊菜單命令，鍵入C和按Ctrl+C組合鍵。對軟件質量有了信心之后，知道無論以何種方式激活復制功能都工作正常，甚至可以進一步縮減為1個區間，例如按Ctrl+C組合鍵。

再看下一個例子。看一下在標準的另存為對話框（如圖5-2所示）中輸入文件名稱的情形。

Windows文件名可以包含除了“、”、“/”、“：”、“·”、“?”、“<>”和“”之外的任意字符。文件名長度是1～255個字符。如果為文件名創建測試用例，等價區間有合法字符、非法字符、合法長度的名稱、過長名稱和過短名稱。

例題：根據下面給出的規格說明，利用等價類劃分的方法，給出足夠的測試用例。“一個程序讀入3個整數，把這3個數值看作一個三角形的3條邊的長度值。這個程序要打印出信息，說明這個三角形是不等邊的、是等腰的、還是等邊的”。

我們可以設三角形的3條邊分別為A，B，C。如果它們能夠構成三角形的3條邊，必須滿足：

A>0，B>0，C>0，且A+B>C，B+C>A，A+C>B。

圖5-2 ?存盤對話框

如果是等腰的，還要判斷A=B，或B=C，或A=C。

如果是等邊的，則需判斷是否A=B，且B=C，且A=C。

列出等價類表，如表5-2所示。

表5-2 ?等 價 類 表

輸 入 條 件有效等價類無效等價類

是否三角形的3條邊（A>0）， ? ? ?（1）

（B>0）， ? ? ?（2）

（C>0）， ? ? ?（3）

（A+B>C）， ? （4）

（B+C>A）， ? （5）

（A+C>B） ? ?（6）

（A≤0）， ? ? ? （7）

（B≤0）， ? ? ? （8）

（C≤0）， ? ? ? （9）

（A+B≤C）， ? ?（10）

（B+C≤A）， ? ?（11）

（A+C≤B） ? ? （12）

是否等腰三角形（A=B）， ? ? （13）

（B=C）， ? ? （14）

（C=A）， ? ? （15）

（A≠B）and（B≠C）and（C≠A），

（16）

是否等邊三角形（A=B）and（B=C）and（C=A），

（17）

（A≠B）， ? ? ? （18）

（B≠C）， ? ? ? （19）

（C≠A）， ? ? ? （20）

設計測試用例：輸入順序是【A，B，C】，如表5-3所示。

表5-3 ?測 試 用 例

序號【A，B，C】覆蓋等價類輸 ? ?出

1【3，4，5】（1），（2），（3），（4），（5），（6）一般三角形

2【0，1，2】（7）不能構成三角形

3【1，0，2】（8）

4【1，2，0】（9）

5【1，2，3】（10）

6【1，3，2】（11）

7【3，1，2】（12）

8【3，3，4】（1），（2），（3），（4），（5），（6），（13）等腰三角形

9【3，4，4】（1），（2），（3），（4），（5），（6），（14）

10【3，4，3】（1），（2），（3），（4），（5），（6），（15）

11【3，4，5】（1），（2），（3），（4），（5），（6），（16）非等腰三角形

12【3，3，3】（1），（2），（3），（4），（5），（6），（17）是等邊三角形

13【3，4，4】（1），（2），（3），（4），（5），（6），（14），（18）非等邊三角形

14【3，4，3】（1），（2），（3），（4），（5），（6），（15），（19）

15【3，3，4】（1），（2），（3），（4），（5），（6），（13），（20）

請記住，等價分配的目標是把可能的測試用例組合縮減到仍然足以滿足軟件測試需求為止。因為，選擇了不完全測試，就要冒一定的風險，所以必須仔細選擇分類。

關于等價分配最后要講的一點是，這樣做有可能不客觀。科學有時也是一門藝術。測試同一個復雜程序的兩個軟件測試員，可能會制定出兩組不同的等價區間。只要審查等價區間的人都認為它們足以覆蓋測試對象就可以了。

2.3 ?邊界值分析法

人們從長期的測試工作經驗得知，大量的錯誤是發生在輸入或輸出范圍的邊界上的，而不是在輸入范圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。例如，在做三角形計算時，要輸入三角形的3個邊長A、B和C。這3個數值應當滿足A>0、B>0、C>0、A+B>C、A+C>B、B+C>A，才能構成三角形。但如果把6個不等式中的任何一個大于號“>”錯寫成大于等于號“≥”，那就不能構成三角形。問題恰恰出現在容易被疏忽的邊界附近。這里所說的邊界是指相當于輸入等價類和輸出等價類而言，稍高于其邊界值及稍低于其邊界值的一些特定情況。

1．邊界條件

我們可以想象一下，如果在懸崖峭壁邊可以自信地安全行走，平地就不在話下了。如果軟件在能力達到極限時能夠運行，那么在正常情況下一般也就不會有什么問題。

邊界條件是特殊情況，因為編程從根本上說不懷疑邊界有問題。奇怪的是，程序在處理大量中間數值時都是對的，但是可能在邊界處出現錯誤。下面的一段源代碼說明了在一個極簡單的程序中是如何產生邊界條件問題的。

rem create a 10 element integer array

rem initialize each element to–1

dim data（10）as integer

dim i as integer

for i=1 to 10

data（i）=–1

next i

end

這段代碼的意圖是創建包含10個元素的數組，并為數組中的每一個元素賦初值–1。看起來相當簡單。它建立了包含10個整數的數組data和一個計數值i。For循環是從1～10，數組中從第1個元素到第10個元素被賦予數值–1。那么邊界問題在哪兒呢？

在大多數開發語言腳本中，應當以聲明的范圍定義數組，在本例中定義語句是dim data（10）as interger，第一個創建的元素是data（0），而不是data（1）。該程序實際上創建了一個從data（0）～ data（10）共11個元素的數組。程序從1～10循環將數組元素的值初始化為-1，但是由于數組的第一個元素是data（0），因此它沒有被初始化。程序執行完畢，數組值如下：

data(0)=?0data(6)=?–1

data(1)=?–1data(7)=?–1

data(2)=?–1data(8)=?–1

data(3)=?–1data(9)=?–1

data(4)=?–1data(10)=?–1

data(5)=?–1

注意data（0）的值是0，而不是–1。如果這位程序員以后忘記了，或者其他程序員不知道這個數據數組是如何初始化的，那么他就可能會用到數組的第1個元素data（0），以為它的值是–1。諸如此類的問題很常見，在復雜的大型軟件中，可能導致極其嚴重的軟件缺陷。

2．次邊界條件

上面討論的普通邊界條件是最容易找到的。它們在產品說明書中有定義，或者在使用軟件的過程中確定。而有些邊界在軟件內部，最終用戶幾乎看不到，但是軟件測試仍有必要檢查。這樣的邊界條件稱為次邊界條件或者內部邊界條件。

尋找這樣的邊界不要求軟件測試員具有程序員那樣閱讀源代碼的能力，但是要求大體了解軟件的工作方式。2的乘方和ASCII表就是這樣的例子。

（1）2的乘方

計算機和軟件的計數基礎是二進制數，用位（bit）來表示0和1，一個字節（byte）由8位組成，一個字（word）由兩個字節組成等。表5-4中列出了常用的2的乘方單位及其范圍或值。

表5-4 ?軟件中2的乘方

術 ? ?語范圍或值術 ? ?語范圍或值

位0或1千1,024

雙位0～15兆1,048,576

字節0～255億1,073,741,824

字0～65,535萬億1,099,511,627,776

表5-4中所列的范圍和值是作為邊界條件的重要數據。除非軟件向用戶提出這些范圍，否則在需求文檔中不會指明。然而，它們通常由軟件內部使用，外部是看不見的，當然，在產生軟件缺陷的情況下可能會看到。

在建立等價區間時，要考慮是否需要包含2的乘方邊界條件。例如，如果軟件接受用戶輸入1～1000范圍內的數字，誰都知道在合法區間中包含1和1000，也許還要有2和999。為了覆蓋任何可能的2的乘方次邊界，還要包含臨近雙位邊界的14、15和16，以及臨近字節邊界的254、255和256。

（2）ASCII表

另一個常見的次邊界條件是ASCII字符表。如表5-5所示是部分ASCII值表的清單。

表5-5 ?部分ASCII值表

字符ASCII值字符ASCII值字符ASCII值字符ASCII值

Null0B66250a97

Space32Y89957b98

/47Z90:58y121

048[91@64z122

149'96A65{123

注意，表5-5不是結構良好的連續表。0～9的后面ASCII值是48～57。斜杠字符（/）在數字0的前面，而冒號字符“：”在數字9的后面。大寫字母A～Z對應65～90。小寫字母對應97～122。這些情況都代表次邊界條件。

如果測試進行文本輸入或文本轉換的軟件，在定義數據區間包含哪些值時，參考一下ASCII表是相當明智的。例如，如果測試的文本框只接受用戶輸入字符A～Z和a～z，就應該在非法區間中包含ASCII表中這些字符前后的值@、[?、和{?。

（3）其他一些邊界條件

另一種看起來很明顯的軟件缺陷來源是當軟件要求輸入時（比如在文本框中）,不是沒有輸入正確的信息，而是根本沒有輸入任何內容，只按了Enter鍵。這種情況在產品說明書中常常被忽視，程序員也可能經常遺忘，但是在實際使用中卻時有發生。程序員總會習慣性地認為用戶要么輸入信息，不管是看起來合法的或非法的信息，要么就會選擇Cancel鍵放棄輸入，如果沒有對空值進行好的處理的話，恐怕程序員自己都不知道程序會引向何方。

正確的軟件通常應該將輸入內容默認為合法邊界內的最小值，或者合法區間內的某個合理值，否則，返回錯誤提示信息。

因為這些值通常在軟件中進行特殊處理，所以不要把它們與合法情況和非法情況混在一起，而要建立單獨的等價區間。

3．邊界值的選擇方法

邊界值分析是一種補充等價劃分的測試用例設計技術，它不是選擇等價類的任意元素，而是選擇等價類邊界的測試用例。實踐證明，為檢驗邊界附近的處理專門設計測試用例，常常取得良好的測試效果。邊界值分析法不僅重視輸入條件邊界，而且也適用于輸出域測試用例。

對邊界值設計測試用例，應遵循以下幾條原則：

① 如果輸入條件規定了值的范圍，則應取剛達到這個范圍的邊界的值，以及剛剛超越這個范圍邊界的值作為測試輸入數據。

② 如果輸入條件規定了值的個數，則用最大個數、最小個數、比最小個數少1、比最大個數多1的數作為測試數據。

③ 根據規格說明的每個輸出條件，使用前面的原則①。

④ 根據規格說明的每個輸出條件，應用前面的原則②。

⑤ 如果程序的規格說明給出的輸入域或輸出域是有序集合，則應選取集合的第一個元素和最后一個元素作為測試用例。

⑥ 如果程序中使用了一個內部數據結構，則應當選擇這個內部數據結構邊界上的值作為測試用例。

⑦ 分析規格說明，找出其他可能的邊界條件。

2.4 ?錯誤推測法

錯誤推測法就是基于經驗和直覺推測程序中所有可能存在的各種錯誤，有針對性地設計測試用例的方法。

錯誤推測法的基本思想是列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據它們選擇測試用例。例如，設計一些非法、錯誤、不正確和垃圾數據進行輸入測試是很有意義的。如果軟件要求輸入數字，就輸入字母。如果軟件只接受正數，就輸入負數。如果軟件對時間敏感，就看它在公元3000年是否還能正常工作。還有，例如，在單元測試時曾列出的許多在模塊中常見的錯誤，以前產品測試中曾經發現的錯誤等，這些就是經驗的總結。另外，輸入數據和輸出數據為0的情況，或者輸入表格為空格或輸入表格只有一行，這些都是容易發生錯誤的情況。可選擇這些情況下的例子作為測試用例。

2.5 ?因果圖法

前節介紹的等價類劃分方法和邊界值分析法都是著重考慮輸入條件，并沒有考慮到輸入情況的各種組合，也沒考慮到各個輸入情況之間的相互制約關系。如果在測試時必須考慮輸入條件的各種組合，可能的組合數將是天文數字。因此必須考慮描述多種條件的組合，相應地產生多個動作的形式來考慮設計測試用例，這就需要利用因果圖。在軟件工程中，有些程序的功能可以用判定表的形式來表示，并根據輸入條件的組合情況規定相應的操作。很自然，應該為判定表中的每一列設計一個測試用例，以便保證測試程序在輸入條件的某種組合下，操作是正確的。

1．因果圖設計方法

因果圖法是從用自然語言書寫的程序規格說明的描述中找出因（輸入條件）和果（輸出或程序狀態的改變），通過因果圖轉換為判定表。

利用因果圖導出測試用例需要經過以下幾個步驟：

① 分析程序規格說明的描述中，哪些是原因，哪些是結果。原因常常是輸入條件或是輸入條件的等價類，而結果是輸出條件。

② 分析程序規格說明的描述中語義的內容，并將其表示成連接各個原因與各個結果的“因果圖”。

③ 標明約束條件。由于語法或環境的限制，有些原因和結果的組合情況是不可能出現的。為表明這些特定的情況，在因果圖上使用若干個標準的符號標明約束條件。

④ 把因果圖轉換成判定表。

⑤ 為判定表中每一列表示的情況設計測試用例。

因果圖生成的測試用例（局部，組合關系下的）包括了所有輸入數據的取TRUE與取FALSE的情況，構成的測試用例數目達到最少，且測試用例數目隨輸入數據數目的增加而增加。

事實上，在較為復雜的問題中，這個方法常常是十分有效的，它能有力地幫助我們確定測試用例。當然，如果哪個開發項目在設計階段就采用了判定表，也就不必再畫因果圖了，而是可以直接利用判定表設計測試用例了。

通常在因果圖中，用Ci表示原因，Ei表示結果，其基本符號如圖5-3所示。各結點表示狀態，可取“0”或“1”值。“0”表示某狀態不出現，“1”表示某狀態出現。

圖5-3 ?因果圖的基本圖形符號

① 恒等：若原因出現，則結果出現；若原因不出現，則結果也不出現。

② 非（～）：若原因出現，則結果不出現；若原因不出現，則結果出現。

③ 或（∨）：若幾個原因中有1個出現，則結果出現；若幾個原因都不出現，則結果不出現。

④ 與（∧）：若幾個原因都出現，結果才出現。若其中有1個原因不出現，則結果不出現。

為了表示原因與原因之間、結果與結果之間可能存在的約束條件，在因果圖中可以附加一些表示約束條件的符號。從輸入（原因）考慮，有4種約束，例如：（a）、（b）、（c）、（d）。從輸出（結果）考慮，還有1種約束，例如：（e），如圖5-4所示。

圖5-4 ?因果圖的約束符號

① E（互斥）：表示a、b兩個原因不會同時成立，兩個中最多有一個可能成立。

② I（包含）：表示a、b、c這3個原因中至少有一個必須成立。

③ O（惟一）：表示a和b當中必須有一個，且僅有一個成立。

④ R（要求）：表示當a出現時，b必須也出現。a出現時不可能b不出現。

⑤ M（屏蔽）：表示當a是1時，b必須是0。而當a為0時，b的值不定。

2．因果圖測試用例

例如：有一個處理單價為1元5角錢的盒裝飲料的自動售貨機軟件。若投入1元5角硬幣，按下“可樂”、“雪碧”或“紅茶”按鈕，相應的飲料就送出來。若投入的是兩元硬幣，在送出飲料的同時退還5角硬幣。

分析這一段說明，我們可以列出原因和結果。

原因：① 投入1元5角硬幣；② 投入2元硬幣；

原因：③ 按“可樂”按鈕；④ 按“雪碧”按鈕；⑤ 按“紅茶”按鈕。

中間狀態：① 已投幣；② 已按鈕。

結果：① 退還5角硬幣；② 送出“可樂”飲料；

原因：③ 送出“雪碧”飲料；④ 送出“紅茶”飲料。

根據原因和結果，我們可以設計這樣一個因果圖（如圖5-5所示。）

圖5-5 ?因果圖

轉換為測試用例，如表5-6所示，每一列可作為確定測試用例的依據。

表 ?5-6

1234567891011

輸

入

投入1元5角硬幣（1）11110000000

投入2元硬幣（2）00001111000

按“可樂”按鈕（3）10001000100

按“雪碧”按鈕（4）01000100010

按“紅茶”按鈕（5）00100010001

中間

結點

已投幣（11）11111111000

已按鈕（12）11101110111

輸

出

退還5角硬幣（21）00001110000

送出“可樂”飲料（22）10001000000

送出“雪碧”飲料（23）01000100000

送出“紅茶”飲料（24）00100010000

2.6 ?判定表驅動法

前面因果圖方法中已經用到了判定表。判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。在程序設計發展的初期，判定表就已被用作編寫程序的輔助工具了。它可以把復雜的邏輯關系和多種條件組合的情況表達得較明確。

1．判定表組成

判定表通常由4個部分組成，如圖5-6所示。

圖5-6 ?判定表

??條件樁（condition stub）：列出了問題的所有條件。通常認為列出的條件的次序無關緊要。

??動作樁（action stub）：列出了問題規定可能采取的操作。這些操作的排列順序沒有約束。

??條件項（condition entry）：列出針對它所列條件的取值，在所有可能情況下的真假值。

??動作項（action entry）：列出在條件項的各種取值情況下應該采取的動作。

??規則：任何一個條件組合的特定取值及其相應要執行的操作。在判定表中貫穿條件項和動作項的一列就是一條規則。顯然，判定表中列出多少組條件取值，也就有多少條規則，條件項和動作項就有多少列。

2．判定表建立

判定表的建立因該依據軟件規格說明，步驟如下：

① 確定規則的個數。假如有n個條件，每個條件有兩個取值（0，1），故有2n種規則。

② 列出所有的條件樁和動作樁。

③ 填入條件項。

④ 填入動作項。制定初始判定表。

⑤ 簡化。合并相似規則或者相同動作。

Beizer指出了適合使用判定表設計測試用例的條件：

① 規格說明以判定表的形式給出，或很容易轉換成判定表。

② 條件的排列順序不影響執行哪些操作。

③ 規則的排列順序不影響執行哪些操作。

④ 當某一規則的條件已經滿足，并確定要執行的操作后，不必檢驗別的規則。

⑤ 如果某一規則要執行多個操作，這些操作的執行順序無關緊要。

2.7 ?正交試驗法

利用因果圖來設計測試用例時，作為輸入條件的原因與輸出結果之間的因果關系，有時很難從軟件需求規格說明中得到。往往因果關系非常龐大，導致利用因果圖而得到的測試用例數目多得驚人，給軟件測試帶來沉重的負擔。為了有效地、合理地減少測試的工時與費用，可利用正交試驗法進行測試用例的設計。

1．正交試驗設計方法

依據Galois理論，正交試驗設計方法是從大量的試驗數據中挑選適量的、有代表性的點，從而合理地安排測試的一種科學的試驗設計方法。

正交試驗法，就是使用已經造好了的表格“——”正交表來安排試驗并進行數據分析的一種方法。它簡單易行并且計算表格化，應用性較好。下邊通過一個例子來說明正交試驗法。

例題：為提高某化工產品的轉化率，選擇了三個有關因素進行條件試驗，反應溫度（A），反應時間（B），用堿量（C），并確定了它們的試驗范圍如下。

??A：80～90℃；

??B：90～150分鐘；

??C：5%～7%。

試驗目的是搞清楚因子A、B、C對轉化率有什么影響，哪些是主要的，哪些是次要的，從而確定最適生產條件，即溫度、時間及用堿量各為多少才能使轉化率最高。這里，對因子A、B和C，在試驗范圍內都選了三個水平，如下所示。

??A：A1=80℃，A2=85℃，A3=90℃；

??B：B1=90分鐘，B2=120分鐘，B3=150分鐘；

??C：C1=5%，C2=6%，C3=7%。

當然，在正交試驗設計中，因子可以是定量的，也可以是定性的。而定量因子各水平間的距離可以相等，也可以不相等。這個三因子三水平的條件試驗，通常有兩種試驗方法：

① 取三因子所有水平之間的組合，即A1B1C1，A1B1C2，A1B2C1，……，A3B3C3，共有33=27次試驗。用圖5-7表示立方體的27個節點。這種試驗法叫做全面試驗法。

圖5-7 ?全面試驗法取點

全面試驗對各因子與指標間的關系剖析得比較清楚。但試驗次數太多。特別是當因子數目多，每個因子的水平數目也很多時，試驗量非常大。如選6個因子，每個因子取5個水平時，如欲做全面試驗，則需56＝15625次試驗，這實際上是不可能實現的。如果應用將要介紹的正交試驗法，只做25次試驗就行了。而且在某種意義上講，這25次試驗代表了15625次試驗。

② 簡單對比法，即變化一個因素而固定其他因素，如首先固定B、C于Bl、Cl，使A變化：

? ?↗A1

B1C1 →A2

? ?↘A3（好結果）

如得出結果A3最好，則固定A于A3，C還是Cl，使B變化：

? ?↗B1

A3C1 →B2 （好結果）

? ?↘B3

得出結果以B2為最好，則固定B于B2，A于A3，使C變化：

? ?↗C1

A3B2→C2 （好結果）

? ?↘C3

試驗結果以C2為最好。于是就認為最好的工藝條件是A3B2C2。

這種方法一般也有一定的效果，但缺點很多。首先這種方法的選點代表性很差，如按上述方法進行試驗，試驗點完全分布在一個角上，而在一個很大的范圍內沒有選點，因此這種試驗方法不全面，所選的工藝條件A3B2C2不一定是27個組合中最好的。其次，用這種方法比較條件好壞時，是把單個的試驗數據拿來，進行數值上的簡單比較，而試驗數據中必然包含著誤差成分，所以單個數據的簡單比較不能剔除誤差，必然造成結論的不穩定。

簡單對比法的最大優點就是試驗次數少，例如，6因子5水平試驗，在不重復時，只用5+（6–1）×（5–1）＝5+5×4＝25次試驗就可以了。

考慮兼顧這兩種試驗方法的優點，從全面試驗的點中選擇具有典型性、代表性的點，使試驗點在試驗范圍內分布得很均勻，能反映全面情況。但我們又希望試驗點盡量地少，為此還要具體考慮一些問題。 如上例，對應于A有Al、A2、A3 3個平面，對應于B、C也各有3個平面，共9個平面。則這9個平面上的試驗點都應當一樣多，即對每個因子的每個水平都要同等看待。具體來說，每個平面上都有3行、3列，要求在每行、每列上的點一樣多。這樣，作出如圖5-8所示的設計，試驗點用⊙表示。我們看到，在9個平面中每個平面上都恰好有3個點，而每個平面的每行每列都有1個點，而且只有1個點，總共9個點。這樣的試驗方案，試驗點的分布很均勻，試驗次數也不多。

當因子數和水平數都不太大時，尚可通過作圖的辦法來選擇分布很均勻的試驗點。但是因子數和水平數多了，作圖的方法就不行了。試驗工作者在長期的工作中總結出一套辦法，創造出所謂的正交表。按照正交表來安排試驗，既能使試驗點分布得很均勻，又能減少試驗次數，而且計算分析簡單，能夠清晰地闡明試驗條件與指標之間的關系。用正交表來安排試驗及分析試驗結果，這種方法叫正交試驗設計法。

一般用L代表正交表，常用的有L8（27）、L9（34）、L16（45）、L8（4×24）等。此符號各數字的意義如下。

例如：L8（27），其中，7為此表列的數目（最多可安排的因子數）；2為因子的水平數；8為此表行的數目（試驗次數）。

又例如：L18（2×37），有7列是3水平的，有1列是2水平的，L18（2×37）的數字告訴我們，用它來安排試驗，做18個試驗最多可以考察1個2水平因子和7個3水平因子。

在行數為mn型的正交表中（m，n是正整數），試驗次數（行數）＝（每列水平數–1）+l，如L8（27），8＝7×（2–1）+l，利用上述關系式可以從所要考察的因子水平數來決定最低的試驗次數，進而選擇合適的正交表。比如要考察5個3水平因子及一個2水平因子，則起碼的試驗次數為5×（3–1）+1×（2–1）+1＝12（次），這就是說，要在行數不小于12，既有2水平列又有3水平列的正交表中選擇，L18（2×37）適合。正交表具有兩條性質：每一列中各數字出現的次數都一樣多；任何兩列所構成的各有序數對出現的次數都一樣多。所以稱之為正交表。

例如，在L9（34）中（如表5-7所示），各列中的l、2、3都各自出現3次；任何兩列，例如第3、4列，所構成的有序數對從上向下共有9種，既沒有重復也沒有遺漏。其他任何兩列所構成的有序數對也是這9種各出現一次。這反映了試驗點分布的均勻性。

表5-7 ?L9（34）正交表

行 ? ?號列 ? ?號

1234

水 ? ?平

11111

21222

31333

42123

52231

62312

73132

83213

93321

試驗方案應該如何設計呢？安排試驗時，只要把所考察的每一個因子任意地對應于正交表的一列（一個因子對應一列，不能讓兩個因子對應同一列），然后把每列的數字“翻譯”成所對應因子的水平。這樣，每一行的各水平組合就構成了一個試驗條件（不考慮沒安排因子的列）。對于上例，因子A、B、C都是3水平的，試驗次數要不少于3× ? ? ? （3–1）+1＝7（次），可考慮選用L9（34）。因子A、B、C可任意地對應于L9（34）的某三列，例如A、B、C分別放在l、2、3列，然后試驗按行進行，順序不限，每一行中各因素的水平組合就是每一次的試驗條件，從上到下就是這個正交試驗的方案，如表5-8所示。這個試驗方案的幾何解釋正好是正交試驗設計圖例。

3個3水平的因子，做全面試驗需要33＝27次試驗，現用L9（34）來設計試驗方案，只要做9次，工作量減少了2/3，而在一定意義上代表了27次試驗。

2．正交試驗測試用例設計步驟

利用正交試驗設計測試用例的步驟如下。

??提取功能說明，構造因子“——”狀態表。把影響實驗指標的條件稱為因子，而影響實驗因子的條件叫做因子的狀態。利用正交試驗設計方法來設計測試用例時，首先要根據被測試軟件的規格說明書找出影響其功能實現的操作對象和外部因素，把它們當作因子，而把各個因子的取值當做狀態。對軟件需求規格說明中的功能要求進行劃分，把整體的、概要性的功能要求進行層層分解與展開，分解成具體的、有相對獨立性的基本的功能要求。這樣就可以把被測試軟件中所有的因子都確定下來，并為確定因子的權值提供參考的依據。確定因子與狀態是設計測試用例的關鍵。因此，要求盡可能全面地、正確地確定取值，以確保測試用例的設計做到完整與有效。

??加權篩選，生成因素分析表。對因子與狀態的選擇可按其重要程度分別加權。可根據各個因子及狀態作用的大小、出現頻率的大小以及測試的需要，確定權值的大小。

??利用正交表構造測試數據集，正交表的推導依據Galois理論。

利用正交試驗設計方法設計測試用例，與使用等價類劃分、邊界值分析、因果圖等方法相比，有以下優點：節省測試工作工時；可控制生成的測試用例的數量；測試用例具有一定的覆蓋率。

正交試驗法在軟件測試中是一種有效的方法，例如在平臺參數配置方面，我們要選擇哪種組合方式是最好的，每個參數可能就是一個因子，參數的不同取值就是水平，這樣我們可以采用正交試驗法設計出最少的測試組合，達到有效的測試目的。

2.8 ?功能圖法

一個程序的功能說明通常由動態說明和靜態說明組成。動態說明描述了輸入數據的次序或轉移的次序。靜態說明描述了輸入條件與輸出條件之間的對應關系。對于較復雜的程序，由于存在大量的組合情況，因此，僅用靜態說明組成的規格說明對于測試來說往往是不夠的，必須用動態說明來補充功能說明。

1．功能圖設計方法

功能圖方法是用功能圖形象地表示程序的功能說明，并機械地生成功能圖的測試用例。功能圖模型由狀態遷移圖和邏輯功能模型構成。

??狀態遷移圖用于表示輸入數據序列以及相應的輸出數據。在狀態遷移圖中，由輸入數據和當前狀態決定輸出數據和后續狀態。

??邏輯功能模型用于表示在狀態中輸入條件和輸出條件之間的對應關系。邏輯功能模型只適合于描述靜態說明，輸出數據僅由輸入數據決定。測試用例則是由測試中經過的一系列狀態和在每個狀態中必須依靠輸入/輸出數據滿足的一對條件組成。

功能圖方法實際上是一種黑盒、白盒混合用例設計方法。

功能圖方法中要用到邏輯覆蓋和路徑測試的概念和方法，屬白盒測試方法中的內容。邏輯覆蓋是以程序內部的邏輯結構為基礎的測試用例設計方法，該方法要求測試人員對程序的邏輯結構有清楚的了解。由于覆蓋測試的目標不同，邏輯覆蓋可分為：語句覆蓋、判定覆蓋、判定-條件覆蓋，條件組合覆蓋及路徑覆蓋。下面我們指的邏輯覆蓋和路徑是功能或系統水平上的，以區別于白盒測試中的程序內部的，如圖5-9及表5-9所示。

圖5-9 ?功能圖

表5-9 ?判 ?定 ?表

輸 ?入口令＝記錄YNN

錯輸入＝3次NYN

輸 ?出M2—

M3—

M4—

消去卡—

續表

狀 ?態S1—

S2—

S3—

2．功能圖法生成測試用例

功能圖由狀態遷移圖和布爾函數組成。狀態遷移圖用狀態和遷移來描述一個狀態，指出數據輸入的位置（或時間），而遷移則指明狀態的改變，同時要依靠判定表和因果圖表示的邏輯功能。

采用什么樣的方法生成測試用例？從功能圖生成測試用例，得到的測試用例數是可接受的。問題的關鍵是如何從狀態遷移圖中選取測試用例。若用節點代替狀態，用弧線代替遷移，狀態遷移圖就可轉化成一個程序的控制流程圖形式。問題就轉化為程序的路徑測試問題（白盒測試范疇概念）了。

測試用例生成規則：為了把狀態遷移（測試路徑）的測試用例與邏輯模型的測試用例組合起來，從功能圖生成實用的測試用例，需定義下面的規則。一個結構化的狀態遷移中，定義3種形式的循環：順序、選擇和重復。但分辨一個狀態遷移中的所有循環是有困難的。

從功能圖生成測試用例的過程如下。

??生成局部測試用例：在每個狀態中，從因果圖生成局部測試用例。局部測試庫由原因值（輸入數據）組合與對應的結果值（輸出數據或狀態）構成。

??測試路徑生成：利用上面的規則生成從初始狀態到最后狀態的測試路徑。

??測試用例合成：合成測試路徑與功能圖中每個狀態的局部測試用例。結果是視狀態到最后狀態的一個狀態序列，以及每個狀態中輸入數據與對應輸出數據組合。

??測試用例的合成算法：采用條件構造樹。

2.9 ?場景法

現在的軟件幾乎都是用事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。這種在軟件設計方面的思想也可引入到軟件測試中，可以比較生動地描繪出事件觸發時的情景，有利于測試設計者設計測試用例，同時使測試用例更容易理解和執行。

提出這種測試思想的是Rational公司，并在RUP2000中文版中有詳盡的解釋和應用。

用例場景用來描述流經用例的路徑，從用例開始到結束遍歷這條路徑上所有基本流和備選流。

1．基本流和備選流

如圖5-10所示，圖中經過用例的每條路徑都用基本流和備選流來表示，直黑線表示基本流，是經過用例的最簡單的路徑。備選流用不同的彩色表示，一個備選流可能從基本流開始，在某個特定條件下執行，然后重新加入基本流中（如備選流1和3）；也可能起源于另一個備選流（如備選流2），或者終止用例而不再重新加入到某個流（如備選流2和4）。

按照如圖5-10中所示的每個經過用例的路徑，可以確定以下不同的用例場景。

場景1：基本流；

場景2：基本流、備選流1；

場景3：基本流、備選流1、備選流2；

場景4：基本流、備選流3；

場景5：基本流、備選流3、備選流1；

場景6：基本流、備選流3、備選流1、備選流2；

場景7：基本流、備選流4；

場景8：基本流、備選流3、備選流4。

注：為方便起見，場景5、6和8只考慮了備選流 3循環執行一次的情況。

需要說明的是，為了能清晰地說明場景，我們所舉的例子都非常簡單，在實際應用中，測試用例很少如此簡單。

2．ATM例子

（1）例子描述

如圖5-11所示是ATM例子的流程示意圖。

?? 圖5-10 ?基本流和備選流圖

? ?5-11 ?ATM流程示意圖

如表5-10所示，包含了如圖5-11中所示提款用例的基本流和某些備用流。

表5-10 ?用 ?例 ?流

基本流本用例的開始是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——賬面金額不足

（2）場景設計

如表5-11所示是生成的場景。

表5-11 ?場 景 設 計

場 景 描 述基 ?本 ?流備 ?選 ?流

場景1——成功的提款基本流

場景2——ATM內沒有現金基本流備選流2

場景3——ATM內現金不足基本流備選流3

場景4——PIN有誤（還有輸入機會）基本流備選流4

場景5——PIN有誤（不再有輸入機會）基本流備選流4

場景6——賬戶不存在/賬戶類型有誤基本流備選流

場景7——賬戶余額不足基本流備選流

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

（3）用例設計

對于這7個場景中的每一個場景都需要確定測試用例，一般采用矩陣或決策表來確定和管理測試用例。如表5-12所示是一種通用格式，其中行代表各個測試用例，列代表測試用例的信息。本例中的測試用例包含測試用例ID、場景/條件、測試用例中涉及的所有數據元素和預期結果等項目。首先確定執行用例場景所需的數據元素，然后構建矩陣，最后要確定包含執行場景所需的適當條件的測試用例。在下面的矩陣中，V表示這個條件必須是有效的才可執行基本流，I表示這種條件下將激活所需備選流 ，n/a表示這個條件不適用于測試用例。

表5-12 ?測試用例表

TC（測試用例）ID號場景/條件PIN賬號輸入（或選擇）的金額賬面金額ATM內的金額預期結果

CW1場景1——成功的提款VVVVV成功的提款

CW2場景2——ATM內沒有現金VVVVI提款選項不可用，用例結束

CW3場景3——ATM內現金不足VVVVI警告消息，返回基本流步驟6-輸入金額

CW4場景4 ——PIN有誤（還有不止一次輸入機會）IVn/aVV警告消息，返回基本流步驟4，輸入PIN

CW5場景4——PIN有誤（還有一次輸入機會）IVn/aVV警告消息，返回基本流步驟4，輸入PIN

CW6場景4——PIN有誤（不再有輸入機會）IVn/aVV警告消息，卡予保留，用例結束

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

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

① 輸入了錯誤的PIN，但仍存在輸入機會，此備選流重新加入基本流中的步驟 ? ? ? ?3-輸入PIN。

② 輸入了錯誤的PIN，而且不再有輸入機會，則此備選流將保留銀行卡并終止用例。

③ 最后一次輸入時輸入了“正確”的 PIN。備選流在步驟5-輸入金額處重新加入基本流。

注意，在上面的矩陣中，無需為條件輸入任何實際的值。以這種方式創建測試用例矩陣的一個優點在于容易看到測試的是什么條件。由于只需要查看 V和 I，這種方式還易于判斷是否已經確定了充足的測試用例。從表5-12中可發現存在幾個無效的條件I，這表明測試用例還不完全，如場景6-不存在的賬戶/賬戶類型有誤和場景7-賬戶余額不足就缺少測試用例。

（4）數據設計

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

表5-13 ?測試數據表

TC（測試用例）ID號場景/條件PIN賬號輸入的金額（或選擇的金額）賬面

金額（元）

ATM內的金額（元）預期結果

CW1場景1——成功的提款4987809-49850.00500.002?000成功的提款。賬戶余額被更新為450.00

CW2場景2——ATM內沒有現金4987809-498100.00500.000.00提款選項不可用，用例結束

CW3場景3——ATM內現金不足4987809-498100.00500.0070.00警告消息，返回基本流步驟6輸入金額

CW4場景4——PIN有誤（還有不止一次的輸入機會）4978809-498n/a500.002?000警告消息，返回基本流步驟4，輸入PIN

CW5場景4——PIN有誤（還有一次輸入機會）4978809-498n/a500.002?000警告消息，返回基本流步驟4，輸入PIN

CW6場景4——PIN有誤（不再有輸入機會）4978809-498n/a500.002?000警告消息，卡予保留，用例結束

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

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

場景6——賬戶不存在/賬戶類型有誤：未找到賬戶或賬戶不可用；

場景6——賬戶不存在/賬戶類型有誤：禁止從該賬戶中提款；

場景7——賬戶余額不足：請求的金額超出賬面金額。

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

① 無效卡（所持卡為掛失卡、被盜卡、非承兌銀行發卡、磁條損壞等）；

② 無法讀卡（讀卡機堵塞、脫機或出現故障）；

③ 賬戶已消戶、凍結或由于其他方面原因而無法使用；

④ ATM內的現金不足或不能提供所請求的金額（與CW3不同，在CW3中只是一種幣值不足，而不是所有幣值都不足）；

⑤ 無法聯系銀行系統以獲得認可；

⑥ 銀行網絡離線或交易過程中斷電。

結論：所有從事軟件測試和即將從事軟件測試的人大都是從黑盒測試做起的，每種類型的軟件有各自的特點，每種測試用例設計的方法也有各自的特點，針對不同軟件如何利用這些黑盒方法是非常重要的，它能極大地提高測試效率和測試覆蓋度，認真掌握這些方法的原理，有效提高測試水平，積累更多的測試經驗，這是測試人員最寶貴的財富。

2.10 ?測試方法選擇的綜合策略

測試用例的設計方法不是單獨存在的，具體到每個測試項目里都會用到多種方法，每種類型的軟件有各自的特點，每種測試用例設計的方法也有各自的特點，針對不同軟件如何利用這些黑盒方法是非常重要的，在實際測試中，往往是綜合使用各種方法才能有效地提高測試效率和測試覆蓋度，這就需要認真掌握這些方法的原理，積累更多的測試經驗，以有效地提高測試水平。

以下是各種測試方法選擇的綜合策略，可供讀者在實際應用過程中參考。

① 首先進行等價類劃分，包括輸入條件和輸出條件的等價劃分，將無限測試變成有限測試，這是減少工作量和提高測試效率最有效的方法。

② 在任何情況下都必須使用邊界值分析方法。經驗表明，用這種方法設計出的測試用例發現程序錯誤的能力最強。

③ 可以用錯誤推測法追加一些測試用例，這需要依靠測試工程師的智慧和經驗。

④ 對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度。如果沒有達到要求的覆蓋標準，應當再補充足夠的測試用例。

⑤ 如果程序的功能說明中含有輸入條件的組合情況，則一開始就可選用因果圖法和判定表驅動法。

⑥ 對于參數配置類的軟件，要用正交試驗法選擇較少的組合方式達到最佳效果。

⑦ 功能圖法也是很好的測試用例設計方法，我們可以通過不同時期條件的有效性設計不同的測試數據。

⑧ 對于業務流清晰的系統，可以利用場景法貫穿整個測試案例過程，在案例中綜合使用各種測試方法。

3 ?測試用例的編寫

3.1 ?測試用例計劃的目的

仔細計劃測試用例，是達成測試目標的必由之路。這樣做的重要性體現如下。

即使在小型軟件項目上，也可能有數千個測試用例。建立用例可能需要一些測試員經過幾個月甚至幾年的時間。正確的計劃會組織好用例，以便全體測試員和其他項目小組成員有效地審查和使用。

我們已經知道，在項目期間有必要多次執行同樣的測試，以尋找新的軟件缺陷，保證老的軟件缺陷得以修復。假如沒有正確的計劃，就不可能知道需要執行哪個測試用例，原有的測試是否得到重復。

有時我們需要回答整個項目期間的重要問題。例如，計劃執行多少個測試用例；在軟件最終版本上執行多少個測試用例；多少個通過，多少個失敗；有忽略的測試用例嗎，等等。如果沒有測試用例計劃，就不能回答這些問題。

在少數高風險行業中，軟件測試小組必須證明確實執行了計劃執行的測試。發布忽略某些測試用例的軟件是危險的。正確的測試用例計劃和跟蹤提供了一種證實測試的手段。

3.2 ?測試設計說明

大家知道，項目整體測試計劃的級別非常高。它雖然把軟件拆分為具體特性和可測試項，并將其分派到每個測試員頭上，但是它并沒有指明如何對這些特性進行測試，可能僅僅對使用自動化測試還是黑盒測試或者白盒測試有一些提示，但是并不會涉及如何使用以及在哪里使用這些工具。

為了更好地進行測試，我們需要為單個軟件特性定義具體的測試方法，這就是測試設計說明。ANSI/IEEE 829中對測試設計說明的解釋是：測試設計說明就是在測試計劃中提煉測試方法，要明確指出設計包含的特性以及相關的測試用例和測試程序，并指定判斷特性通過/失敗的規則。

測試設計說明的目的是組織和描述針對具體特性需要進行的測試。然而，它并不給出具體的測試用例或者執行測試的步驟。以下內容來自于ANSI/IEEE 829標準，應該作為測試設計說明的部分內容。

??標識符：用于引用和定位測試設計說明的惟一標識符。該說明還應該引用整個測試計劃，還應該包含任何其他計劃或者說明的引用。

??要測試的特性：對測試設計說明所包含的軟件特性的描述。例如“計算器程序的加法功能”、“寫字板程序中的字體大小選擇和顯示”、“QuickTime軟件的視頻卡配置測試”。該部分還將明確指出要間接測試的特性，它通常作為主特性的輔助特性。例如，文件打開對話框的用戶界面雖然不在測試設計說明中重點指出，但是在測試讀寫功能的過程中要間接測試。

??方法：描述測試的通用方法。如果方法在測試計劃中列出，就應該在此詳細描述要使用的技術，并給出如何驗證測試結果的方法。例如，我們這樣描述一種方法，開發一種測試工具，順序讀寫不同大小的數據文件，數據文件的數目和大小及包含的內容由程序員提供的示例來確定。用文件比較工具比較輸出的文件和源文件，如果相同，則認為通過；如果不同，則認為失敗。

??測試用例信息：用于描述所引用的測試用例的相關信息。應該列出所選的等價區間，給出測試用例的引用信息以及用于執行測試用例的測試程序說明。例如：“檢查最大值 ?測試用例ID#15326”、“檢查最小值 ?測試用例ID#15327”，在這部分不定義實際測試用例。

??通過/失敗規則：描述用什么規則來判定某項特性的測試結果是通過還是失敗。這種描述有可能非常簡單和明確，例如“通過是指當執行全部測試用例時沒有發現軟件缺陷”。也有可能不是非常明確，例如“失敗是指10%以上的測試用例沒有通過”。

3.3 ?測試用例說明

如何記錄和記載創建的測試用例？如果你已經開始進行一些軟件測試了，就可能采用過一些用例描述格式。本節講解編寫測試用例的有關內容，指出將要考慮的重點。

ANSI/IEEE 829標準稱測試用例說明為編寫用于輸入輸出的實際數值和預期結果，同時還明確指出，使用具體測試用例產生的測試程序的限制。一個測試用例的編寫可參考表5-14。

表5-14 ?測 試 用 例

編號：

編制人審定人時間

軟件名稱編號/版本

測試用例

用例編號

參考信息（參考的文檔及章節號或功能項）：

輸入說明（列出選用的輸入項，覆蓋正常、異常情況）：

輸出說明（逐條與輸入項對應，列出預期輸出）：

環境要求（測試要求的軟、硬件、網絡要求）：

特殊規程要求：

用例間的依賴關系：

用例產生的測試程序限制：

測試用例應該解釋要向軟件發送什么值或者條件，以及預期結果。一個測試用例說明可以由多個測試用例說明來引用，也可以引用多個測試程序。ANSI/IEEE 829標準還列出了一些應該包含在內的重要信息，如下所示。

??標識符：由測試設計過程說明和測試程序說明引用的惟一標識符。

??測試項：描述被測試的詳細特性、代碼模塊等，應該比測試設計說明中所列的特性更加具體。如果測試設計說明提到“計算器程序的加法功能”，那么測試用例說明就會相應地提到“加法運算的上限溢出處理”。它還要指出引用的產品說明書或者測試用例所依據的其他設計文檔。

??輸入說明：該說明列舉執行測試用例的所有輸入內容或者條件。如果測試計算器程序，輸入說明可能簡單到“1+1”。如果測試蜂窩電話交換軟件，輸入說明可能是成百上千種輸入條件。如果測試基于文件的產品，輸入說明可能是文件名和內容的描述。

??輸出說明：描述進行測試用例預期的結果。例如，1+1等于2嗎？在蜂窩軟件中上千個輸出變量設置正確嗎？讀取文件的全部內容和預想的一樣嗎？

??環境要求：是指執行測試用例必要的硬件、軟件、測試工具、人員等。

??特殊要求：描述執行測試必須的特殊要求。測試寫字板程序也許不需要任何特殊條件，但是測試一些特殊的軟件（如核電站軟件）就有特殊要求。

??用例之間的依賴性：如果一個測試用例依賴于其他用例，或者受其他用例的影響，就應該在此注明。

如果按照這里推薦的文檔格式，對于每一個測試用例至少都要寫上一頁的描述文字，數千個測試用例可能要形成幾千頁文檔。所以我們經常把ANSI/IEEE 829標準當作規范而不是標準使用（除非必須這樣做，許多政府項目和某些行業要求按照此規格編寫測試用例，但是在大多數情況下可以采用簡便方法）。

采用簡便方法并不是說放棄或者忽視重要的信息，而是意在找出一個更有效的方法對這些信息進行精簡，例如，沒有必要刻意要求不能用書面段落形式表述測試用例。如表5-15給出了一個打印機兼容性簡單列表的例子。

表5-15??打印機兼容性簡單列表

測試用例序列號型 ?號模 ?式黑 ?白選 ?項

WP0001CanonBJC-7000黑白文字

WP0002CanonBJC-7000黑白超級照片

WP0003CanonBJC-7000黑白自動

WP0004CanonBJC-7000黑白草稿

WP0005CanonBJC-7000彩色文字

WP0006CanonBJC-7000彩色超級照片

WP0007CanonBJC-7000彩色自動

WP0008CanonBJC-7000彩色草稿

WP0009HPLaserJet Ⅳ高

WP0010HPLaserJet Ⅳ中

WP0011HPLaserJet Ⅳ低

表中的每一行是一個測試用例，有自己的標識符。伴隨測試用例的所有其他信息，例如測試項、輸入說明、輸出說明、環境要求、特殊要求和依賴性等對所有這些用例都必須有，可以一并編寫，附加到表格中。審查測試用例的人可以快速看完測試用例信息，然后審查表格，檢查其范圍。

表述測試用例的其他選擇有大綱、狀態表或數據流程圖等方式。

3.4 ?測試程序說明

編寫完測試設計和測試用例之后，就要說明執行測試用例的程序。什么是測試程序呢？ANSI/IEEE 829標準把測試程序定義為“明確指出為實現相關測試設計而執行具體測試用例和操作軟件系統的全部步驟”。

測試程序，有時也叫“測試腳本說明”，詳細定義了執行測試用例的每一步操作。以下是需要定義的內容。

??標識符：用來把測試程序與相關測試用例和測試設計相聯系的惟一標識。

??目的：本程序描述的目的以及將要執行的測試用例的引用信息。

??特殊要求：執行測試所需的其他程序、特殊測試技術或者特殊設備。

??程序步驟：執行測試用例的詳細描述。它包含以下內容。

① 日志：指出用什么方法記錄測試結果和現象。

② 設置：說明如何準備測試。

③ 啟動：說明啟動測試的步驟。

④ 程序：描述運行測試的步驟。

⑤ 衡量標準：描述如何判斷結果。

⑥ 關閉：描述因意外原因而推遲測試的步驟。

⑦ 終止：描述正常停止測試的步驟。

⑧ 重置：說明如何把環境恢復到測試前的狀態。

⑨ 偶然事件：說明如何處理計劃之外的情況。

如果我們把測試程序只理解成“嘗試執行所有的測試用例并報告發現的問題”是不夠的。這雖然簡單、容易，但是無法告訴新加入的測試員如何進行測試，不能重復而且無法證明哪些步驟執行了。使用詳細的程序說明，則把要測試什么、如何測試等問題都表述得一目了然。如圖5-12所示是“Windows計算器”的測試程序說明的例子片斷。

俗話說“做什么都要適可而止”，測試用例計劃也一樣。測試用例計劃包括四個目標，即組織性、重復性、跟蹤和測試證實。開發測試用例的軟件測試工程師要力爭實現這些目標，但是其實現程度取決于行業、公司、項目和測試組的具體情況，通常也不太可能按照最細致的程度去編寫測試用例。

我們設計的測試用例計劃要力求達到最佳的詳細程度，比如，在一個測試程序中要求在PC機上安裝Windows?2000來執行測試，測試程序在其設置部分聲明需要 ? ? ?Windows?2000，但是未聲明Windows 2000的哪個版本。那么一兩年內出現新版本會怎樣？測試程序需要升級來反映這個變化嗎？為了避免這個問題，可以省略具體的版本，而用“可用的最新版本”這樣的說明來替代。

無比詳細的測試用例說明減少了測試的隨意性，使測試可以很好地重復，使得無經驗的測試人員按照測試用例說明也能執行測試。但是編寫如此細致的測試用例說明要花費相當多的時間和精力，并且由于細節繁多，也會阻滯測試工作，造成測試執行時間變長

。

開始編寫測試用例時，最好是采用當前項目的標準，同時需要根據ANSI/IEEE 829標準定義的格式，看什么符合項目要求，并可以做適當的調整。

不同的測試工程師設計的測試用例也會有所不同。通常有經驗的測試工程師設計出來的測試用例，在深度及廣度上會比經驗少的測試工程師的完整，這也是所謂的測試經驗值。舉例來講，客戶反應前一版V1.3的軟件在Windows 98的環境下運行時，在屏幕保護程序激活后會產生問題，開發工程師將這問題解決并且已提交修正版本供客戶網絡下載，并且目前開發工程師所開發的軟件最新版本為V1.5版，軟件測試工程師就必須在V1.5版的測試用例內，加入屏幕保護程序激活測試用例，甚至將這個用例增加至其他的測試平臺。

西邊人，西說測試，軟件測試資源站公眾號作者