黑盒測試案例設計技術篇

1 概述

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

2 測試用例設計方法

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

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

輸入條件

有效等價類

無效等價類

輸入條件

有效等價類

無效等價類

…

…

…

…

…

…

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 等 價 類 表

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

表5-3 測 試 用 例

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

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

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的乘方

表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值表

注意，表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

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）正交表

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

表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 判 定 表

續表

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 用 例 流

續表

（2）場景設計

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

表5-11 場 景 設 計

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

（3）用例設計

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

表5-12 測試用例表

在上面的矩陣中，六個測試用例執行了四個場景。對于基本流，上述測試用例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 測試數據表

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

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

場景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 打印機兼容性簡單列表

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

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

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版的測試用例内，加入屏幕保護程序激活測試用例，甚至将這個用例增加至其他的測試平台。

作者：西邊人

歡迎來到西說測試

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!