1. 概述
黑盒測試用例設計方法包括等價類划分法、邊界值分析法、錯誤推測法、因果圖法、判定表驅動法、正交試驗設計法、功能圖法等。
2. 等價類划分法
2.1. 概念
等價類划分法是把程序的輸入域划分成若干部分（子集），然后從每個部分中選取少數代表性數據作為測試用例。每一類的代表性數據在測試中的作用等價於這一類中的其他值。
2.2. 等價類划分法的應用
- 等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對於揭露程序中的錯誤都是等效的，並合理地假定：測試某等價類的代表值就等於對這一類其它值的測試.因此,可以把全部輸入數據合理划分為若干等價類,在每一個等價類中取一個數據作為測試的輸入條件,就可以用少量代表性的測試數據.取得較好的測試結果.等價類划分可有兩種不同的情況:有效等價類和無效等價類。
- 有效等價類:是指對於程序的規格說明來說是合理的,有意義的輸入數據構成的集合.利用有效等價類可檢驗程序是否實現了規格說明中所規定的功能和性能。
- 無效等價類:與有效等價類的定義恰巧相反。
設計測試用例時,要同時考慮這兩種等價類.因為,軟件不僅要能接收合理的數據,也要能經受意外的考驗.這樣的測試才能確保軟件具有更高的可靠性。
- 划分等價類的六大原則：
- 在輸入條件規定了取值范圍或值的個數的情況下,則可以確立一個有效等價類和兩個無效等價類.
例：輸入值是學生成績，范圍是0～100：
- 在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下,可確立一個有效等價類和一個無效等價類.
- 在輸入條件是一個布爾量的情況下,可確定一個有效等價類和一個無效等價類. 布爾量是一個二值枚舉類型, 一個布爾量具有兩種狀態: true 和 false 。
- 在規定了輸入數據的一組值（假定n個）,並且程序要對每一個輸入值分別處理的情況下,可確立n個有效等價類和一個無效等價類.
例：輸入條件說明輸入字符為:中文、英文、阿拉伯文三種之一，則分別取這三種這三個值作為三個有效等價類，另外把三種字符之外的任何字符作為無效等價類。
- 在規定了輸入數據必須遵守的規則的情況下,可確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）
- 在確知已划分的等價類中各元素在程序處理中的方式不同的情況下,則應再將該等價類進一步的划分為更小的等價類
- 將等價類轉化成測試用例：
- 按照[輸入條件][有效等價類][無效等價類] 建立等價類表,列出所有划分出的等價類
- 為每一個等價類規定一個唯一的編號.
- 設計一個新的測試用例,使其盡可能多地覆蓋尚未被覆蓋地有效等價類,重復這一步.直到所有的有效等價類都被覆蓋為止.
- 設計一個新的測試用例,使其僅覆蓋一個尚未被覆蓋的無效等價類,重復這一步.直到所有的無效等價類都被覆蓋為止.
2.3. 等價類划分實例
- 某程序規定："輸入三個整數 a 、 b 、 c 分別作為三邊的邊長構成三角形。通過程序判定所構成的三角形的類型，當此三角形為一般三角形、等腰三角形及等邊三角形時，分別作計算 … "。用等價類划分方法為該程序進行測試用例設計。（三角形問題的復雜之處在於輸入與輸出之間的關系比較復雜。）
分析題目中給出和隱含的對輸入條件的要求：
（1）整數 （2）三個數 （3）非零數 （4）正數 （5）兩邊之和大於第三邊 （6）等腰 （7）等邊 如果 a 、 b 、 c 滿足條件（ 1 ） ~ （ 4 ），則輸出下列四種情況之一： 1)如果不滿足條件（5），則程序輸出為 " 非三角形 " 。 2)如果三條邊相等即滿足條件（7），則程序輸出為 " 等邊三角形 " 。 3)如果只有兩條邊相等、即滿足條件（6），則程序輸出為 " 等腰三角形 " 。 4)如果三條邊都不相等，則程序輸出為 " 一般三角形 " 。 列出等價類表並編號
覆蓋有效等價類的測試用例：
a b c 覆蓋等價類號碼
3 4 5 （1）--（7）
4 4 5 （1）--（7），（8）
4 5 5 （1）--（7），（9）
5 4 5 （1）--（7），（10）
4 4 4 （1）--（7），（11）
覆蓋無效等價類的測試用例：
- 設有一個檔案管理系統，要求用戶輸入以年月表示的日期。假設日期限定在1990年1月~2049年12月，並規定日期由6位數字字符組成，前4位表示年，后2位表示月。現用等價類划分法設計測試用例，來測試程序的"日期檢查功能"。（不考慮2月的問題）
1)划分等價類並編號,下表等價類划分的結果
| 輸入等價類 |
有效等價類 |
無效等價類 |
| 日期的類型及長度 |
①6位數字字符 |
②有非數字字符 ③少於6位數字字符 ④多於6位數字字符 |
| 年份范圍 |
⑤在1990~2049之間 |
⑥小於1990 ⑦大於2049 |
| 月份范圍 |
⑧在01~12之間 |
⑨等於00 ⑩大於12 |
2)設計測試用例，以便覆蓋所有的有效等價類在表中列出了3個有效等價類，編號分別為①、⑤、⑧，設計的測試用例如下：
測試數據 期望結果 覆蓋的有效等價類 200211 輸入有效 ①、⑤、⑧ 3)為每一個無效等價類設計一個測試用例，設計結果如下： 測試數據 期望結果 覆蓋的無效等價類 95June 無效輸入 ② 20036 無效輸入 ③ 2001006 無效輸入 ④ 198912 無效輸入 ⑥ 200401 無效輸入 ⑦ 200100 無效輸入 ⑨ 200113 無效輸入 ⑩
- NextDate 函數包含三個變量：month 、 day 和 year ，函數的輸出為輸入日期后一天的日期。 例如，輸入為 2006年3月 7日，則函數的輸出為 2006年3月8日 。要求輸入變量 month 、 day 和 year 均為整數值，並且滿足下列條件： ①1≤month≤12 ②1≤day≤31 ③1920≤year≤2050 1)有效等價類為： M1＝{月份：1≤月份≤12} D1＝{日期：1≤日期≤31} Y1＝{年：1812≤年≤2012} 2)若條件 ① ~ ③中任何一個條件失效，則 NextDate 函數都會產生一個輸出，指明相應的變量超出取值范圍，比如 "month 的值不在 1-12 范圍當中 " 。顯然還存在着大量的 year 、 month 、 day 的無效組合， NextDate 函數將這些組合作統一的輸出： " 無效輸入日期 " 。其無效等價類為： M2＝{月份：月份<1} M3＝{月份：月份>12} D2＝{日期：日期<1} D3＝{日期：日期>31} Y2＝{年：年<1812} Y3＝{年：年>2012} 弱一般等價類測試用例 月份 日期 年 預期輸出 6 15 1912 1912年6月16日 強一般等價類測試用例同弱一般等價類測試用例 注：弱--有單缺陷假設；健壯--考慮了無效值 (一)弱健壯等價類測試 用例ID 月份 日期 年 預期輸出 WR1 6 15 1912 1912年6月16日 WR2 -1 15 1912 月份不在1～12中 WR3 13 15 1912 月份不在1～12中 WR4 6 -1 1912 日期不在1～31中 WR5 6 32 1912 日期不在1～31中 WR6 6 15 1811 年份不在1812～2012中 WR7 6 15 2013 年份不在1812～2012中
(二)強健壯等價類測試 用例ID 月份 日期 年 預期輸出 SR1 -1 15 1912 月份不在1～12中 SR2 6 -1 1912 日期不在1～31中 SR3 6 15 1811 年份不在1812～2012中 SR4 -1 -1 1912 兩個無效一個有效 SR5 6 -1 1811 兩個無效一個有效 SR6 -1 15 1811 兩個無效一個有效 SR7 -1 -1 1811 三個無效
- 佣金問題等價類測試用例，它是根據佣金函數的輸出值域定義等價類，來改進測試用例集合。 輸出銷售額≤1000元 佣金10％ 1000<銷售額≤1800 佣金=100+(銷售額-1000)*15% 銷售額>1800 佣金=220+(銷售額-1800)*20% 測試用例 槍機(45) 槍托(30) 槍管(25) 銷售額 佣金 1 5 5 5 500 50 2 15 15 15 1500 175 3 25 25 25 2500 360 根據輸出域選擇輸入值，使落在輸出域等價類內，可以結合弱健壯測試用例結合。
3. 邊界值分析法
3.1. 概念
邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類划分法的補充，這種情況下，其測試用例來自等價類的邊界。
3.2. 邊界值分析法的應用
根據大量的測試統計數據，很多錯誤是發生在輸入或輸出范圍的邊界上，而不是發生在輸入/輸出范圍的中間區域。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。
使用邊界值分析方法設計測試用例，首先應確定邊界情況。通常輸入和輸出等價類的邊界，就是應着重測試的邊界情況。應當選取正好等於，剛剛大於或剛剛小於邊界的值作為測試數據，而不是選取等價類中的典型值或任意值作為測試數據。
- 邊界值分析法與等價類分析法的區別：
1) 邊界值分析不是從某等價類中隨便挑一個作為代表，而是使這個等價類的每個邊界都要作為測試條件。
2) 邊界值分析不僅考慮輸入條件，還要考慮輸出空間產生的測試情況。
例：測試計算平方根的函數
--輸入：實數
--輸出：實數
--需求說明：當輸入一個0或比0大的數的時候，返回其正平方根；當輸入一個小於0的數時，顯示錯誤信息"平方根非法-輸入值小於0"並返回0；庫函數Print-Line可以用來輸出錯誤信息。
- 等價類划分： I.可以考慮作出如下划分： a、輸入 (i)<0 和 (ii)>=0 b、輸出 (a)>=0 和 (b) Error II.測試用例有兩個： a、輸入4，輸出2。對應於 (ii) 和 (a) 。 b、輸入-10，輸出0和錯誤提示。對應於 (i) 和 (b) 。
- 邊界值分析：
划分(ii)的邊界為0和最大正實數；划分(i)的邊界為最小負實數和0。由此得到以下測試用例： a、輸入 {最小負實數} b、輸入 {絕對值很小的負數} c、輸入 0 d、輸入 {絕對值很小的正數} e、輸入 {最大正實數}
- 通常情況下，軟件測試所包含的邊界檢驗有幾種類型：數字、字符、位置、重量、大小、速度、方位、尺寸、空間等。
- 相應地，以上類型的邊界值應該在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、 最短/最長、 空/滿等情況下。利用邊界值作為測試數據
| 項 |
邊界值 |
測試用例的設計思路 |
| 字符 |
起始-1個字符/結束+1個字符 |
假設一個文本輸入區域允許輸入1個到255個 字符，輸入1個和255個字符作為有效等價類；輸入0個和256個字符作為無效等價類，這幾個數值都屬於邊界條件值。 |
| 數值 |
最小值-1/最大值+1 |
假設某軟件的數據輸入域要求輸入5位的數據值，可以使用10000作為最小值、99999作為最大值；然后使用剛好小於5位和大於5位的 數值來作為邊界條件。 |
| 空間 |
小於空余空間一點/大於滿空間一點 |
例如在用U盤存儲數據時，使用比剩余磁盤空間大一點（幾KB）的文件作為邊界條件。 |
- 內部邊界值分析： 在多數情況下，邊界值條件是基於應用程序的功能設計而需要考慮的因素，可以從軟件的規格說明或常識中得到，也是最終用戶可以很容易發現問題的。然而，在測試用例設計過程中，某些邊界值條件是不需要呈現給用戶的，或者說用戶是很難注意到的，但同時確實屬於檢驗范疇內的邊界條件，稱為內部邊界值條件或子邊界值條件。 內部邊界值條件主要有下面幾種：
1) 數值的邊界值檢驗：計算機是基於二進制進行工作的，因此，軟件的任何數值運算都有一定的范圍限制。
| 項 |
范圍或值 |
| 位（bit） |
0 或 1 |
| 字節（byte） |
0 ~ 255 |
| 字（word） |
0~65535（單字）或 0~4294967295（雙字） |
| 千（K） |
1024 |
| 兆（M） |
1048576 |
| 吉（G） |
1073741824 |
2) 字符的邊界值檢驗：在計算機軟件中，字符也是很重要的表示元素，其中ASCII和Unicode是常見的編碼方式。如下列出了一些常用字符對應的ASCII碼值。
| 字符 |
ASCII碼值 |
| 空 (null) |
0 |
| 空格 (space) |
32 |
| 可輸入的字符 |
33~126 |
| 0~9 |
48~57 |
| A~Z |
65~90 |
| a~z |
97~122 |
3) 其它邊界值檢驗：在不同的行業應用領域，依據硬件和軟件的標准不同而具有各自特定的邊界值。如下列出部分手機相關的邊界值：
| 硬件設備 |
范圍或值 |
| 手機鋰電池電壓 |
工作電壓：3.6~4.2V； 保護電壓：2.5~3V不等 |
| 手機正常使用溫度 |
-25°C~+60°C |
- 基於邊界值分析方法選擇測試用例的原則
1) 如果輸入條件規定了值的范圍,則應取剛達到這個范圍的邊界的值,以及剛剛超越這個范圍邊界的值作為測試輸入數據。
- 例如，如果程序的規格說明中規定："重量在10公斤至50公斤范圍內的郵件，其郵費計算公式為……"。作為測試用例，我們應取10及50，還應取10.01,49.99,9.99及50.01等。
2) 如果輸入條件規定了值的個數,則用最大個數,最小個數,比最小個數少一,比最大個數多一的數作為測試數據。
- 例如，一個輸入文件應包括1~255個記錄，則測試用例可取1和255，還應取0及256等。
3) 將規則1）和2）應用於輸出條件，即設計測試用例使輸出值達到邊界值及其左右的值。
- 例如，某程序的規格說明要求計算出"每月保險金扣除額為0至1165.25元"，其測試用例可取0.00及1165.24、還可取一0.01及1165．26等。
- 再如一程序屬於情報檢索系統，要求每次"最少顯示1條、最多顯示4條情報摘要"，這時我們應考慮的測試用例包括1和4，還應包括0和5等。
4) 如果程序的規格說明給出的輸入域或輸出域是有序集合,則應選取集合的第一個元素和最后一個元素作為測試用例。
5) 如果程序中使用了一個內部數據結構,則應當選擇這個內部數據結構的邊界上的值作為測試用例。
6) 分析規格說明,找出其它可能的邊界條件。
3.3. 實例
- 現有一個學生標准化考試批閱試卷,產生成績報告的程序。其規格說明如下:程序的輸入文件由一些有80個字符的記錄組成,如右圖所示，所有記錄分為3組：
1) 標題：這一組只有一個記錄，其內容為輸出成績報告的名字。
2) 試卷各題標准答案記錄：每個記錄均在第80個字符處標以數字"2"。該組的第一個記錄的第1至第3個字符為題目編號（取值為1一999）。第10至第59個字符給出第1至第50題的答案（每個合法字符表示一個答案）。該組的第2，第3……個記錄相應為第51至第100，第101至第150，…題的答案。
3) 每個學生的答卷描述：該組中每個記錄的第80個字符均為數字"3"。每個學生的答卷在若干個記錄中給出。如甲的首記錄第1至第9字符給出學生姓名及學號，第10至第59字符列出的是甲所做的第1至第50題的答案。若試題數超過50，則第2，第3……紀錄分別給出他的第51至第100，第101至第150……題的解答。然后是學生乙的答卷記錄。
4) 學生人數不超過200，試題數不超過999。
5) 程序的輸出有4個報告： a)按學號排列的成績單，列出每個學生的成績、名次。 b)按學生成績排序的成績單。 c)平均分數及標准偏差的報告。 d)試題分析報告。按試題號排序，列出各題學生答對的百分比。
解答：分別考慮輸入條件和輸出條件，以及邊界條件。給出下表所示的輸入條件及相應的測試用例。
輸出條件及相應的測試用例表。
- 三角形問題的邊界值分析測試用例 在三角形問題描述中，除了要求邊長是整數外，沒有給出其它的限制條件。在此，我們將三角形每邊邊長的取范圍值設值為[1, 100] 。
| 測試用例 |
a |
b |
c |
預期輸出 |
| Test1 Test2 Test3 Test4 Test5 |
60 60 60 50 50 |
60 60 60 50 50 |
1 2 60 99 100 |
等腰三角形 等腰三角形 等邊三角形 等腰三角形 非三角形 |
| Test6 Test7 Test8 Test9 |
60 60 50 50 |
1 2 99 100 |
60 60 50 50 |
等腰三角形 等腰三角形 等腰三角形 非三角形 |
| Test10 Test11 Test12 Test13 |
1 2 99 100 |
60 60 50 50 |
60 60 50 50 |
等腰三角形 等腰三角形 等腰三角形 非三角形 |
- NextDate函數的邊界值分析測試用例 在NextDate函數中，隱含規定了變量mouth和變量day的取值范圍為1≤mouth≤12和1≤day≤31，並設定變量year的取值范圍為1912≤year≤2050 。
| 測試用例 |
mouth |
day |
year |
預期輸出 |
| Test1 Test2 Test3 Test4 Test5 Test6 Test7 |
6 6 6 6 6 6 6 |
15 15 15 15 15 15 15 |
1911 1912 1913 1975 2049 2050 2051 |
1911.6.16 1912.6.16 1913.6.16 1975.6.16 2049.6.16 2050.6.16 2051.6.16 |
| Test8 Test9 Test10 Test11 Test12 Test13 |
6 6 6 6 6 6 |
-1 1 2 30 31 32 |
2001 2001 2001 2001 2001 2001 |
day超出[1…31] 2001.6.2 2001.6.3 2001.7.1 輸入日期超界 day超出[1…31] |
| Test14 Test15 Test16 Test17 Test18 Test19 |
-1 1 2 11 12 13 |
15 15 15 15 15 15 |
2001 2001 2001 2001 2001 2001 |
Mouth超出[1…12] 2001.1.16 2001.2.16 2001.11.16 2001.12.16 Mouth超出[1…12] |
4. 錯誤推斷法
4.1. 概念
基於經驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法。
4.2. 錯誤推斷法的應用
基本思想：列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例。
- 例如, 輸入數據和輸出數據為0的情況；輸入表格為空格或輸入表格只有一行。 這些都是容易發生錯誤的情況。可選擇這些情況下的例子作為測試用例。
- 例如，前面例子中成績報告的程序，采用錯誤推測法還可補充設計一些測試用例：
1) 程序是否把空格作為回答
2) 在回答記錄中混有標准答案記錄
3) 除了標題記錄外，還有一些的記錄最后一個字符即不是2也不是3
4) 有兩個學生的學號相同
5) 試題數是負數
- 例如，測試一個對線性表（比如數組）進行排序的程序，可推測列出以下幾項需要特別測試的情況：
1) 輸入的線性表為空表；
2) 表中只含有一個元素；
3) 輸入表中所有元素已排好序；
4) 輸入表已按逆序排好；
5) 輸入表中部分或全部元素相同。
- 例如，測試手機終端的通話功能，可以設計各種通話失敗的情況來補充測試用例：
1) 無SIM 卡插入時進行呼出（非緊急呼叫）
2) 插入已欠費SIM卡進行呼出
3) 射頻器件損壞或無信號區域插入有效SIM卡呼出
4) 網絡正常，插入有效SIM卡，呼出無效號碼（如1、888、333333、不輸入任何號碼等）
5) 網絡正常，插入有效SIM卡，使用“快速撥號”功能呼出設置無效號碼的數字
5. 因果圖法
5.1. 概念
因果圖法是一種利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，它適合於檢查程序輸入條件的各種組合情況。
5.2. 因果圖法的應用
等價類划分法和邊界值分析方法都是着重考慮輸入條件，但沒有考慮輸入條件的各種組合、輸入條件之間的相互制約關系。這樣雖然各種輸入條件可能出錯的情況已經測試到了，但多個輸入條件組合起來可能出錯的情況卻被忽視了。
如果在測試時必須考慮輸入條件的各種組合，則可能的組合數目將是天文數字，因此必須考慮采用一種適合於描述多種條件的組合、相應產生多個動作的形式來進行測試用例的設計，這就需要利用因果圖（邏輯模型）。
- 因果圖介紹
1) 4種符號分別表示了規格說明中向4種因果關系。
2) 因果圖中使用了簡單的邏輯符號，以直線聯接左右結點。左結點表示輸入狀態（或稱原因），右結點表示輸出狀態（或稱結果）。
3) C1表示原因，通常置於圖的左部；e1表示結果，通常在圖的右部。C1和e1均可取值0或1，0表示某狀態不出現，1表示某狀態出現。
- 因果圖涉及的概念
1) 關系
- Ø 恆等：若c1是1，則e1也是1；否則e1為0。
- Ø 非：若c1是1，則e1是0；否則e1是1。
- Ø 或：若c1或c2或c3是1，則e1是1；否則e1為0。“或”可有任意個輸入。
- Ø 與：若c1和c2都是1，則e1為1；否則e1為0。“與”也可有任意個輸入。
2) 約束
輸入狀態相互之間還可能存在某些依賴關系，稱為約束。例如, 某些輸入條件本身不可能同時出現。輸出狀態之間也往往存在約束。在因果圖中,用特定的符號標明這些約束。
- Ø 輸入條件的約束有以下4類：
- E約束（異）：a和b中至多有一個可能為1，即a和b不能同時為1。
- I約束（或）：a、b和c中至少有一個必須是1，即 a、b 和c不能同時為0。
- O約束（唯一）；a和b必須有一個，且僅有1個為1。
- R約束（要求）：a是1時，b必須是1，即不可能a是1時b是0。
- Ø 輸出條件約束類型
輸出條件的約束只有M約束（強制）：若結果a是1，則結果b強制為0。
- 采用因果圖法設計測試用例的步驟：
1) 分析軟件規格說明描述中, 那些是原因(即輸入條件或輸入條件的等價類),那些是結果(即輸出條件), 並給每個原因和結果賦予一個標識符。
2) 分析軟件規格說明描述中的語義，找出原因與結果之間, 原因與原因之間對應的關系，根據這些關系,畫出因果圖。
3) 由於語法或環境限制, 有些原因與原因之間,原因與結果之間的組合情況不可能出現，為表明這些特殊情況, 在因果圖上用一些記號表明約束或限制條件。
4) 把因果圖轉換為判定表。
5) 把判定表的每一列拿出來作為依據,設計測試用例。
5.3. 實例
- 某軟件規格說明書包含這樣的要求：第一列字符必須是A或B，第二列字符必須是一個數字，在此情況下進行文件的修改，但如果第一列字符不正確，則給出信息L；如果第二列字符不是數字，則給出信息M。
解答：
1) 根據題意，原因和結果如下：
原因：
1——第一列字符是A；
2——第一列字符是B；
3——第二列字符是一數字。
結果：
21——修改文件；
22 ——給出信息L；
23——給出信息M。
2) 其對應的因果圖如下：
11為中間節點；考慮到原因1和原因2不可能同時為1，因此在因果圖上施加E約束。
3) 根據因果圖建立判定表。
表中8種情況的左面兩列情況中，原因①和原因②同時為1，這是不可能出現的，故應排除這兩種情況。表的最下一欄給出了6種情況的測試用例，這是我們所需要的數據。
- 有一個處理單價為5角錢的飲料的自動售貨機軟件測試用例的設計。其規格說明如下：若投入5角錢或1元錢的硬幣，押下〖橙汁〗或〖啤酒〗的按鈕，則相應的飲料就送出來。若售貨機沒有零錢找，則一個顯示〖零錢找完〗的紅燈亮，這時在投入1元硬幣並押下按鈕后，飲料不送出來而且1元硬幣也退出來；若有零錢找，則顯示〖零錢找完〗的紅燈滅，在送出飲料的同時退還5角硬幣。
1) 分析這一段說明，列出原因和結果
原因：
1——售貨機有零錢找
2——投入1元硬幣
3——投入5角硬幣
4——押下橙汁按鈕
5——.押下啤酒按鈕
結果：
21——售貨機〖零錢找完〗燈亮
22——退還1元硬幣
23——退還5角硬幣
24——送出橙汁飲料
25——送出啤酒飲料
2) 畫出因果圖，如圖所示。所有原因結點列在左邊，所有結果結點列在右邊。建立中間結點，表示處理的中間狀態。中間結點：
11—— 投入1元硬幣且押下飲料按鈕
12——押下〖橙汁〗或〖啤酒〗的按鈕
13——應當找5角零錢並且售貨機有零錢找
14——錢已付清
3) 轉換成判定表：
4) 在判定表中，陰影部分表示因違反約束條件的不可能出現的情況，刪去。第16列與第32列因什么動作也沒做，也刪去。最后可根據剩下的16列作為確定測試用例的依據。
6. 判定表驅動法
6.1. 概念
判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。
6.2. 判定表驅動法
- 判定表的優點
能夠將復雜的問題按照各種可能的情況全部列舉出來，簡明並避免遺漏。因此，利用判定表能夠設計出完整的測試用例集合。
在一些數據處理問題當中，某些操作的實施依賴於多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執行不同的操作。判定表很適合於處理這類問題。
- “閱讀指南”判定表
| 1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
||
| 問題 |
覺得疲倦？ |
Y |
Y |
Y |
Y |
N |
N |
N |
N |
| 感興趣嗎？ |
Y |
Y |
N |
N |
Y |
Y |
N |
N |
|
| 糊塗嗎？ |
Y |
N |
Y |
N |
Y |
N |
Y |
N |
|
| 建議 |
重讀 |
√ |
|||||||
| 繼續 |
√ |
||||||||
| 跳下一章 |
√ |
√ |
|||||||
| 休息 |
√ |
√ |
√ |
√ |
|||||
- 判定表通常由四個部分組成如下圖所示。
1) 條件樁（Condition Stub）：列出了問題得所有條件。通常認為列出的條件的次序無關緊要。
2) 動作樁（Action Stub）：列出了問題規定可能采取的操作。這些操作的排列順序沒有約束。
3) 條件項（Condition Entry）：列出針對它左列條件的取值。在所有可能情況下的真假值。
4) 動作項（Action Entry）：列出在條件項的各種取值情況下應該采取的動作。
- 規則及規則合並
1) 規則：任何一個條件組合的特定取值及其相應要執行的操作稱為規則。在判定表中貫穿條件項和動作項的一列就是一條規則。顯然,判定表中列出多少組條件取值,也就有多少條規則,既條件項和動作項有多少列。
2) 化簡：就是規則合並有兩條或多條規則具有相同的動作，並且其條件項之間存在着極為相似的關系。
- 規則及規則合並舉例
1) 如下圖左端，兩規則動作項一樣，條件項類似，在1、2條件項分別取Y、N時，無論條件3取何值，都執行同一操作。即要執行的動作與條件3無關。於是可合並。“－”表示與取值無關。
2) 與上類似，下圖中，無關條件項“－”可包含其他條件項取值，具有相同動作的規則可合並。
3) 化簡后的讀書指南判定表
| 1 |
2 |
3 |
4 |
||
| 問題 |
你覺得疲倦嗎？ |
- |
- |
Y |
N |
| 你對內容感興趣嗎？ |
Y |
Y |
N |
N |
|
| 書中內容使你胡塗嗎？ |
Y |
N |
- |
- |
|
|
建議 |
請回到本章開頭重讀 |
x |
|||
| 繼續讀下去 |
X |
||||
| 跳到下一章去讀 |
x |
||||
| 停止閱讀，請休息 |
x |
||||
- 判定表的建立步驟：（根據軟件規格說明）
1) 確定規則的個數.假如有n個條件。每個條件有兩個取值（0,1）,故有2n種規則。
2) 列出所有的條件樁和動作樁。
3) 填入條件項。
4) 填入動作項。等到初始判定表。
5) 簡化.合並相似規則（相同動作）。
6.3. 實例
- 問題要求：”……對功率大於50馬力的機器、維修記錄不全或已運行10年以上的機器，應給予優先的維修處理……” 。這里假定，“維修記錄不全”和“優先維修處理”均已在別處有更嚴格的定義 。請建立判定表。
解答：
1) 確定規則的個數：這里有3個條件，每個條件有兩個取值，故應有2*2*2=8種規則。
2) 列出所有的條件茬和動作樁：
3) 填入條件項。可從最后1行條件項開始，逐行向上填滿。如第三行是： Y N Y N Y N Y N，第二行是： Y Y N N Y Y N N等等。
4) 填入動作樁和動作頂。這樣便得到形如圖的初始判定表。
| 1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
||
| 條件 |
功率大於50馬力嗎？ |
N |
Y |
Y |
Y |
N |
N |
N |
N |
| 維修記錄不全嗎？ |
Y |
Y |
N |
N |
Y |
Y |
N |
N |
|
| 運行超過10年嗎？ |
Y |
N |
Y |
N |
Y |
N |
Y |
N |
|
| 動作 |
進行優先處理 |
x |
x |
X |
X |
X |
|||
| 作其他處理 |
X |
x |
x |
||||||
初始判定表
5) 化簡，合並相似規則后得到圖。
| 1 |
2 |
3 |
4 |
5 |
||
| 條件 |
功率大於50馬力嗎？ |
Y |
Y |
Y |
N |
N |
| 維修記錄不全嗎？ |
Y |
N |
N |
- |
- |
|
| 運行超過10年嗎？ |
- |
Y |
N |
Y |
N |
|
| 動作 |
進行優先處理 |
x |
x |
X |
||
| 作其他處理 |
x |
x |
||||
- NextData函數的精簡決策表
M1＝{月份， 每月有30天}
M2＝{月份， 每月有31天}
M3＝{月份， 2月} 有29＝512條規則
D1＝{日期，1～28} 12月末31日和其它31
D2＝{日期，29} 日月份的31日處理不同
D3＝{日期，30} 平年2月28日處理不同
D4＝{日期，31} 於2月27日
Y1 ＝{年：年是閏年}
Y2 ＝{年：年不是閏年}
改進為：
M1＝{月份： 每月有30天}
M2＝{月份： 每月有31天， 12月除外}
M4＝{月份：12月}
M3＝{月份： 2月}
D1＝{日期：1<=日期<=27}
D2＝{日期：28}
D3＝{日期：29}
D4＝{日期：30}
D5＝{日期：31}
Y1 ＝{年：年是閏年}
Y2 ＝{年：年不是閏年}
輸入變量間存在大量邏輯關系的NextData決策表
- 用決策表測試法測試以下程序：該程序有三個輸入變量month、day、year（month、day和year均為整數值，並且滿足：1≤month≤12和1≤day≤31），分別作為輸入日期的月份、日、年份，通過程序可以輸出該輸入日期在日歷上隔一天的日期。
例如，輸入為2004年11月29日，則該程序的輸出為2000年12月1日。
1) 分析各種輸入情況，列出為輸入變量month、day、year划分的有效等價類。
2) 分析程序規格說明，結合以上等價類划分的情況給出問題規定的可能采取的操作（即列出所有的動作樁）。
3) 根據（1）和（2），畫出簡化后的決策表。
案例分析如下：
- month變量的有效等價類：
M1: {month=4,6,9,11} M2: {month=1,3,5,7,8,10}
M3: {month=12 }M4: {month=2}
- day變量的有效等價類：
D1:{1≤day≤26} D2: {day=27} D3: {day=28} D4: {day=29} D5: {day=30} D6: {day=31}
- year變量的有效等價類：
Y1: {year是閏年} Y2: {year不是閏年}
4) 考慮各種有效的輸入情況，程序中可能采取的操作有以下六種：
a1: day+2 a2: day=2 a3: day=1
a4: month+1 a5: month=1 a6: year+1
- 判定表在功能測試中的應用
1) 一些軟件的功能需求可用判定表表達得非常清楚，在檢驗程序的功能時判定表也就成為一個不錯的工具。如果一個軟件的規格說明指出：
- 當條件1和條件2滿足，並且條件3和條件4不滿足，或者當條件1、3和條件4滿足時，要執行操作1。
- 在任一個條件都不滿足時，要執行操作2。
- 在條件1不滿足，而條件4被滿足時，要執行操作3。 根據規格說明得到如下判定表：
這里，判定表只給出了16種規則中的8種。事實上，除這8條以外的一些規則是指當不能滿足指定的條件，執行3種操作時，要執行1個默許的操作。在沒必要時，判定表通常可略去這些規則。但如果用判定表來設計測試用例，就必須列出這些默許規則（如下表）。
| 規則5 |
規則6 |
規則7 |
規則8 |
|
| 條件1 |
- |
N |
Y |
Y |
| 條件2 |
- |
Y |
Y |
N |
| 條件3 |
Y |
N |
N |
N |
| 條件4 |
N |
N |
Y |
- |
| 默許操作 |
x |
x |
x |
x |
默許的規則
2) 判定表的優點和缺點
- 優點：它能把復雜的問題按各種可能的情況一一列舉出來，簡明而易於理解，也可避免遺漏。
- 缺點：不能表達重復執行的動作，例如循環結構。
3) B. Beizer 指出了適合使用判定表設計測試用例的條件：
- 規格說明以判定表形式給出,或很容易轉換成判定表。
- 條件的排列順序不會也不影響執行哪些操作。
- 規則的排列順序不會也不影響執行哪些操作。
- 每當某一規則的條件已經滿足,並確定要執行的操作后,不必檢驗別的規則。
- 如果某一規則得到滿足要執行多個操作,這些操作的執行順序無關緊要。
B. Beizer提出這5個必要條件的目的是為了使操作的執行完全依賴於條件的組合。其實對於某些不滿足這幾條的判定表，同樣可以借以設計測試用例，只不過尚需增加其它的測試用例罷了。
7. 正交試驗法
7.1. 概念
依據Galois理論,從大量的（實驗）數據（測試例）中挑選適量的,有代表性的點（例）,從而合理地安排實驗（測試）的一種科學實驗設計方法.類似的方法有:聚類分析方法,因子方法方法等.
7.2. 正交試驗法
利用因果圖來設計測試用例時, 作為輸入條件的原因與輸出結果之間的因果關系,有時很難從軟件需求規格說明中得到。往往因果關系非常龐大,以至於據此因果圖而得到的測試用例數目多的驚人，給軟件測試帶來沉重的負擔，為了有效地,合理地減少測試的工時與費用,可利用正交實驗設計方法進行測試用例的設計。
利用正交實驗設計測試用例的步驟：
- 提取功能說明,構造因子--狀態表
把影響實驗指標的條件稱為因子.而影響實驗因子的條件叫因子的狀態.利用正交實驗設計方法來設計測試用例時,首先要根據被測試軟件的規格說明書找出影響其功能實現的操作對象和外部因素,把他們當作因子,而把各個因子的取值當作狀態.對軟件需求規格說明中的功能要求進行划分,把整體的概要性的功能要求進行層層分解與展開,分解成具體的有相對獨立性的基本的功能要求.這樣就可以把被測試軟件中所有的因子都確定下來,並為確定個因子的權值提供參考的依據.確定因子與狀態是設計測試用例的關鍵.因此要求盡可能全面的正確的確定取值,以確保測試用例的設計作到完整與有效。
- 加權篩選,生成因素分析表
對因子與狀態的選擇可按其重要程度分別加權.可根據各個因子及狀態的作用大小,出現頻率的大小以及測試的需要,確定權值的大小。
- 利用正交表構造測試數據集
正交表的推導依據Galois理論（這里省略,需要時可查數理統計方面的教材）。
利用正交實驗設計方法設計測試用例,比使用等價類划分,邊界值分析,因果圖等方法有以下優點:節省測試工作工時；可控制生成的測試用例數量；測試用例具有一定的覆蓋率。
8. 功能圖法
8.1. 概念
功能圖由狀態遷移圖和布爾函數組成.狀態遷移圖用狀態和遷移來描述.一個狀態指出數據輸入的位置（或時間）,而遷移則指明狀態的改變.同時要依靠判定表或因果圖表示的邏輯功能.例,一個簡化的自動出納機ATM的功能圖。
8.2. 功能圖法的應用
- 功能圖介紹
一個程序的功能說明通常由動態說明和靜態說明組成.動態說明描述了輸入數據的次序或轉移的次序.
靜態說明描述了輸入條件與輸出條件之間的對應關系.對於較復雜的程序,由於存在大量的組合情況,因此,僅用靜態說明組成的規格說明對於測試來說往往是不夠的.必須用動態說明來補充功能說明.功能圖方法是用功能圖FD形式化地表示程序的功能說明,並機械地生成功能圖的測試用例.
功能圖模型由狀態遷移圖和邏輯功能模型構成.狀態遷移圖用於表示輸入數據序列以及相應的輸出數據.在狀態遷移圖中,由輸入數據和當前狀態決定輸出數據和后續狀態.邏輯功能模型用於表示在狀態中輸入條件和輸出條件之間的對應關系.邏輯功能模型只適合於描述靜態說明,輸出數據僅由輸入數據決定.測試用例則是由測試中經過的一系列狀態和在每個狀態中必須依靠輸入/輸出數據滿足的一對條件組成.功能圖方法其實是是一種黑盒白盒混合用例設計方法。
（功能圖方法中,要用到邏輯覆蓋和路徑測試的概念和方法,其屬白盒測試方法中 的內容.邏輯覆蓋是以程序內部的邏輯結構為基礎的測試用例設計方法.該方法要求測試人員對程序的邏輯結構有清楚的了解.由於覆蓋測試的目標不同,邏輯覆蓋可分為:語句覆蓋,判定覆蓋,判定-條件覆蓋,條件組合覆蓋及路徑覆蓋.下面我們指的邏輯覆蓋和路徑是功能或系統水平上的,以區別與白盒測試中的程序內部的.）
- 測試用例生成方法
從功能圖生成測試用例,得到的測試用例數是可接受的. 問題的關鍵的是如何從狀態遷移圖中選取測試用例. 若用節點代替狀態,用弧線代替遷移,則狀態遷移圖就可轉化成一個程序的控制流程圖形式.問題就轉化為程序的路徑測試問題（如白盒測試）問題了.
- 測試用例生成規則
為了把狀態遷移（測試路徑）的測試用例與邏輯模型（局部測試用例）的測試用例組合起來,從功能圖生成實用的測試用例,須定義下面的規則.在一個結構化的狀態遷移（SST）中,定義三種形式的循環:順序,選擇和重復.但分辨一個狀態遷移中的所有循環是有困難的.（其表示圖形省略）。
- 從功能圖生成測試用例的過程
1) 生成局部測試用例:在每個狀態中,從因果圖生成局部測試用例.局部測試用例由原因值（輸入數據）組合與對應的結果值（輸出數據或狀態）構成。
2) 測試路徑生成:利用上面的規則（三種）生成從初始狀態到最后狀態的測試路徑。
3) 測試用例合成:合成測試路徑與功能圖中每個狀態中的局部測試用例.結果是初始狀態到最后狀態的一個狀態序列,以及每個狀態中輸入數據與對應輸出數據的組合。
- 測試用例的合成算法:采用條件構造樹.
9. 場景法
9.1. 概念
現在的軟件幾乎都是用事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。這種在軟件設計方面的思想也可以引入到軟件測試中，可以比較生動地描繪出事件觸發時的情景，有利於測試設計者設計測試用例，同時使測試用例更容易理解和執行。
9.2. 場景法的應用
基本流和備選流：如下圖所示，圖中經過用例的每條路徑都用基本流和備選流來表示，直黑線表示基本流，是經過用例的最簡單的路徑。備選流用不同的色彩表示，一個備選流可能從基本流開始，在某個特定條件下執行，然后重新加入基本流中（如備選流1和3）；也可能起源於另一個備選流（如備選流2），或者終止用例而不再重新加入到某個流（如備選流2和4）。
9.3. 實例
- 例子描述
下圖所示是ATM例子的流程示意圖。
- 場景設計：下表所示是生成的場景。
表3-8 場景設計
| 場景1——成功提款 |
基本流 |
|
| 場景2——ATM內沒有現金 |
基本流 |
備選流2 |
| 場景3——ATM內現金不足 |
基本流 |
備選流3 |
| 場景4——PIN有誤（還有輸入機會） |
基本流 |
備選流4 |
| 場景5——PIN有誤（不再有輸入機會） |
基本流 |
備選流4 |
| 場景6——賬戶不存在/賬戶類型有誤 |
基本流 |
備選流5 |
| 場景7——賬戶余額不足 |
基本流 |
備選流6 |
注：為方便起見，備選流3和6（場景3和7）內的循環以及循環組合未納入上表。
- 用例設計
對於這7個場景中的每一個場景都需要確定測試用例。可以采用矩陣或決策表來確定和管理測試用例。下面顯示了一種通用格式，其中各行代表各個測試用例，而各列則代表測試用例的信息。本示例中，對於每個測試用例，存在一個測試用例ID、條件（或說明）、測試用例中涉及的所有數據元素（作為輸入或已經存在於數據庫中）以及預期結果。
表3-9 測試用例表
| TCID |
場景/條件 |
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 |
警告消息，卡予保留，用例結束 |
- 數據設計
一旦確定了所有的測試用例，則應對這些用例進行復審和驗證以確保其准確且適度，並取消多余或等效的測試用例。
測試用例一經認可，就可以確定實際數據值（在測試用例實施矩陣中）並且設定測試數據，如表3-10所示。
表3-10 測試用例表
| TCID |
場景/條件 |
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 |
警告消息，卡予保留，用例結束 |
10. 測試用例設計綜合策略
- Myers提出了使用各種測試方法的綜合策略：
1) 在任何情況下都必須使用邊界值分析方法，經驗表明用這種方法設計出測試用例發現程序錯誤的能力最強。】
2) 必要時用等價類划分方法補充一些測試用例。
3) 用錯誤推測法再追加一些測試用例。
4) 對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度，如果沒有達到要求的覆蓋標准，應當再補充足夠的測試用例。
5) 如果程序的功能說明中含有輸入條件的組合情況，則一開始就可選用因果圖法。
- 測試用例的設計步驟】
1) 構造根據設計規格得出的基本功能測試用例；
2) 邊界值測試用例；
3) 狀態轉換測試用例；
4) 錯誤猜測測試用例；
5) 異常測試用例；】
6) 性能測試用例；
7) 壓力測試用例。
- 優化測試用例的方法
1) 利用設計測試用例的8種方法不斷的對測試用例進行分解與合並；
2) 采用遺傳算法理論進化測試用例；
3) 在測試時利用發散思維構造測試用例；