黑盒、白盒、接口測試一系列用例設計方法。
黑盒測試用例設計方法包括等價類划分法、邊界值分析法、錯誤推測法、因果圖法、判定表驅動法、正交試驗設計法、功能圖法、場景圖法等。
（一）等價類划分法
定義：等價類划分法是把所有可能輸入的數據，即程序的輸入域划分策划國內若干部分（子集），然后從每一個子集中選取少數具有代表性的數據作為測試用例。方法是一種重要的、常用的黑盒測試用例設計方法。
等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對於揭露程序中的錯誤都是等效的，並合理地假定：測試某等價類的代表值就等於對這一類其他值的測試，因此，可以把全部輸入數據合理划分為若干等價類，在每一個等價類中取一個數據作為測試的輸入條件就可以用少量代表性的測試數據取得較好的測試結果。等價類划分有兩種不同的情況：有效等價類和無效等價類。
有效等價類，是指對於程序的規格說明來說是合理的、有意義的輸入數據構成的集合。利用有效等價類可檢驗程序是否實現了規格說明所規定的功能和性能。
無效等價類 指對程序的規格說明是不合理的或無意義的輸入數據所構成的集合。對於具體的問題，無效等價類至少應有一個，也可能多個。
划分標准：
1) 完備測試、避免冗余
2) 划分等價類重要的是：集合的划分、划分為互不相交的一組子集，而子集的並是整個集合
3) 並是整個集合：備性
4) 子集互不相交：保證一種形式的無冗余性
5) 同一類中標識（選擇）一個測試用例，同一等價類中，往往處理相同，相同處理映射到“相同的執行路徑”。
划分方法：
1) 在輸入條件規定了取值范圍或值的個數的情況下，則可以確立一個有效等價類和兩個無效等價類。如：輸入值是學生成績，范圍是0~100
2）在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下，可確立一個有效等價類和一個無效等價類：
3）在輸入條件是一個布爾量的情況下，可確定一個有效等價類和一個無效等價類。布爾量是一個二值枚舉類型, 一個布爾量具有兩種狀態: true 和 false 。
4）在規定了輸入數據的一組值（假定n個），並且程序要對每一個輸入值分別處理的情況下，可確立n個有效等價類和一個無效等價類。
例：輸入條件說明學歷可為：專科、本科、碩士、博士四種之一，則分別取這四種的四個值作為四個有效等價類，另外把四種學歷之外的任何學歷作為無效等價類。
5）在規定了輸入數據必須遵守的規則情況下，可確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）；
6）在確知已划分的等價類中各元素在程序處理中的方式不同的情況下，則應在將該等價類進一步的划分為更小的等價類。
轉化為測試用例：
在確立了等價類后，可建立等價類表，列出所有划分出的等價類輸入條件：有效等價類、無效等價類，然后從划分出的等價類中按以下三個原則設計測試用例：
1）為每一個等價類規定一個唯一的編號；
2）設計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋地有效等價類，重復這一步，直到所有的有效等價類都被覆蓋為止；
3）設計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步，直到所有的無效等價類都被覆蓋為止。
實例1：三角形問題
某程序規定：“輸入三個整數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）
覆蓋無效等價類的測試用例：
覆蓋有效等價類的測試用例：
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）
覆蓋無效等價類的測試用例：
實例2，NextDate
NextDate函數包含三個變量：month、day、year，函數的輸出為輸入日期后一天的日期。
例如，輸入2006年3月7日，則函數的輸出為2006年3月8日。要求輸入變量month、day、year均為整數值，並且滿足下列條件：
1、1＜＝month＜＝12
2、1＜＝day<=31
3、1812<=year<=2012
1）有效等價類為：
M1=｛月份：1<=月份<=12｝
D1={日期：1<=日期<=31}
Y1=｛年份：1812<=年<=2012｝
2）若條件1~3中任何一個條件失效，則NextDate函數都會產生一個輸出，指明相應的變量超出取值范圍，比如“month的值不在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 |
|
0 |
1 |
1912 |
月份不在1~12中 |
| WR3 |
|
15 |
1 |
1912 |
月份不在1~12中 |
| WR4 |
|
1 |
0 |
1912 |
日期不在1~31中 |
| WR5 |
|
1 |
32 |
1912 |
日期不在1~31中 |
| WR6 |
|
1 |
1 |
1811 |
年不在1812~2012中 |
| WR7 |
|
1 |
1 |
2013 |
年不在1812~2012中 |
（二）強健壯等價類測試
| 用例 |
ID |
月份 |
日期 |
年 |
預期輸出 |
| SR1 |
|
15 |
1 |
1912 |
月份不在1~12中 |
| SR2 |
|
1 |
32 |
1912 |
日期不在1~31中 |
| SR3 |
|
1 |
1 |
1811 |
年份不在1812~2012中 |
| SR4 |
|
0 |
0 |
1912 |
兩個無效一個有效 |
| SR5 |
|
0 |
1 |
1811 |
兩個無效一個有效 |
| SR6 |
|
1 |
0 |
1811 |
兩個無效一個有效 |
| SR7 |
|
0 |
0 |
1811 |
三個無效 |
（二）邊界值分析法
定義：邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類划分法的補充，這種情況下，其測試用例來自等價類的邊界。
與等價類區別：
1）邊界值分析不是從某等價類中隨便挑一個作為代表，而是使這個等價類的每個邊界都要作為測試條件。
2）邊界值分析不僅考慮輸入條件，還要考慮輸出空間產生的測試情況。
分析方法：
大量的錯誤是發生在輸入或輸出范圍的邊界上，而不是發生在輸入輸出范圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。使用邊界值分析方法設計測試用例，首先應確定邊界情況。通常輸入和輸出等價類的邊界，就是應着重測試的邊界情況。應當選取正好等於，剛剛大於或剛剛小於邊界的值作為測試數據，而不是選取等價類中的典型值或任意值作為測試數據。
常見邊界值：
1）對16Bit的整數而言，32767和32768是邊界
2）屏幕上光標在最左上、最右下位置
3）報表的第一行和最后一行
4）數組元素的第一個和最后一個
5）循環的第0次、第1次和倒數第2次、最后一次
邊界值分析：
1）邊界值分析使用與等價類划分法相同的划分，只是邊界值分析假定錯誤更多地存在於划分的邊界上，因此在等價類的邊界上以及兩側的情況設計測試用例。
例：測試計算平方根的函數
輸入：實數
輸出：實數
規格說明：當輸入一個0或比0大的數的時候，返回其正平方根；當輸入一個小於0的數時，顯示錯誤信息“平方根非法，輸入值小於0”並返回0；庫函數printLine可以用來輸出錯誤信息。
2）等價類划分：
i. 可以考慮做出如下划分：
A、輸入(i)<0 和(ii)>=0
B、輸出(a)>=0和(b)Error
ii. 測試用例有兩個
A、輸入4，輸出2.對應(ii)和(a)。
B、輸入10，輸出0和錯誤提示。對應與(i)和(b)
3）邊界值分析
划分(ii)的邊界為0和最大正實數；划分(i)的邊界為最小負實數和0.由此得到一下測試用例：
A、輸入｛最小負實數｝
B、輸入｛絕對值很小的負數｝
C、輸入0
D、輸入｛絕對值很小的正數｝
E、輸入｛最大正實數｝
4）通常情況下，軟件測試所包含的邊界檢驗有幾種類型：數字、字符、位置、重量、大小、速度、方位、尺寸、空間等。
5）相應地，以上類型的邊界值應該在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最長、空/滿等情況下。
6）利用邊界值作為測試數據
| 項 |
邊界值 |
測試用例的設計思路 |
| 字符 |
起始1個字符/結束+1個字符 |
假設一個文本輸入區域允許輸入1個到255個字符，輸入1個和255個字符作為有效等價類；輸入0個和256個字符作為無效等價類，這幾個數值都屬於邊界條件值 |
| 數值 |
最小值1/最大值+1 |
假設某軟件的數據輸入域要求輸入5位的數據值，可以使用10000作為最小值、9999作為最大值；然后使用剛好小於5位和大於5位的數值作為邊界條件。 |
| 空間 |
小於空余空間一點/大於滿空間一點 |
例如在用U盤存儲數據時，使用比剩余磁盤空間大一點（幾KB）的文件作為邊界條件 |
7）內部邊界值分析
在多數情況下，邊界值條件是基於應用程序的功能設計而需要考慮的因素，可以從軟件的規格說明或常識中得到，也是最終用戶可以很容易發現問題的。然而，在測試用例設計過程中，某些邊界值條件是不需要呈現給用戶的，或者說用戶是很難注意到的，但同時確實屬於檢驗范疇內的邊界條件，稱為內部邊界值條件或子邊界值條件。
內部邊界值條件主要有下面幾種：
1）數值的邊界值檢驗：計算機是基於二進制進行工作的，因此，軟件的任何數值運算都有一定的范圍限制。
| 項 |
范圍或值 |
| 位（Bit） |
0或者1 |
| 字節（byte） |
0~255 |
| 字（Word） |
0~65535（單字）或0~4294967295（雙字） |
| 千（K） |
1024 |
| 兆（M） |
1048576 |
| 吉（G） |
1073741824 |
2）字符的邊界值檢驗：在計算機軟件中，字符也是很重要的表示元素，其中ASCII和Unicode是常見的編碼方式。下表中列出了一些常用字符對應的ASCII碼值。
| 字符 |
ASCII碼值 |
字符 |
ASCII碼值 |
| 空（Null） |
0 |
A |
65 |
| 空格（Space） |
32 |
a |
97 |
| 斜杠（/） |
47 |
z |
122 |
| 0 |
48 |
Z |
90 |
| 冒號（：） |
58 |
單引號（’） |
96 |
| @ |
64 |
|
|
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) 分析規格說明,找出其它可能的邊界條件。
實例1，批閱試卷
現有一個學生標准化考試批閱試卷,產生成績報告的程序。其規格說明如下:程序的輸入文件由一些有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)試題分析報告。按試題號排序，列出各題學生答對的百分比。
解答：分別考慮輸入條件和輸出條件，以及邊界條件。給出下表所示的輸入條件及相應的測試用例。
輸出條件及相應的測試用例表。
實例2，三角形的邊界問題分析測試用例
在三角形問題描述中，除了要求邊長是整數外，沒有給出其它的限制條件。在此，我們將三角形每邊邊長的取范圍值設值為[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 |
等腰三角形 等腰三角形 等腰三角形 非三角形 |
實例3，NextDate函數邊界值分析測試用例
在NextDate函數中，隱含規定了變量mouth和變量day的取值范圍為1≤mouth≤12和1≤day≤31，並設定變量year的取值范圍為1912≤year≤2050。
（三）錯誤推測法
定義：基於經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法。
基本思想：列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例。
1. 例如,輸入數據和輸出數據為0的情況；輸入表格為空格或輸入表格只有一行。這些都是容易發生錯誤的情況。可選擇這些情況下的例子作為測試用例。
2. 例如，前面例子中成績報告的程序，采用錯誤推測法還可補充設計一些測試用例：
1) 程序是否把空格作為回答
2) 在回答記錄中混有標准答案記錄
3) 除了標題記錄外，還有一些的記錄最后一個字符即不是2也不是3
4) 有兩個學生的學號相同
5) 試題數是負數
3. 例如，測試一個對線性表（比如數組）進行排序的程序，可推測列出以下幾項需要特別測試的情況：
1) 輸入的線性表為空表；
2) 表中只含有一個元素；
3) 輸入表中所有元素已排好序；
4) 輸入表已按逆序排好；
5) 輸入表中部分或全部元素相同。
4. 例如，測試手機終端的通話功能，可以設計各種通話失敗的情況來補充測試用例：
1) 無SIM 卡插入時進行呼出（非緊急呼叫）
2) 插入已欠費SIM卡進行呼出
3) 射頻器件損壞或無信號區域插入有效SIM卡呼出
4) 網絡正常，插入有效SIM卡，呼出無效號碼（如1、888、333333、不輸入任何號碼等）
5) 網絡正常，插入有效SIM卡，使用“快速撥號”功能呼出設置無效號碼的數字
（四）因果圖法
定義：因果圖法是一種利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，它適合於檢查程序輸入條件的各種組合情況。
應用：
等價類划分法和邊界值分析方法都是着重考慮輸入條件，但沒有考慮輸入條件的各種組合、輸入條件之間的相互制約關系。這樣雖然各種輸入條件可能出錯的情況已經測試到了，但多個輸入條件組合起來可能出錯的情況卻被忽視了。
如果在測試時必須考慮輸入條件的各種組合，則可能的組合數目將是天文數字，因此必須考慮采用一種適合於描述多種條件的組合、相應產生多個動作的形式來進行測試用例的設計，這就需要利用因果圖（邏輯模型）。
1. 因果圖介紹
1) 4種符號分別表示了規格說明中向4種因果關系。
2) 因果圖中使用了簡單的邏輯符號，以直線聯接左右結點。左結點表示輸入狀態（或稱原因），右結點表示輸出狀態（或稱結果）。
3) C1表示原因，通常置於圖的左部；e1表示結果，通常在圖的右部。C1和e1均可取值0或1，0表示某狀態不出現，1表示某狀態出現。
2. 因果圖涉及的概念
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。
3. 采用因果圖法設計測試用例的步驟：
1) 分析軟件規格說明描述中,那些是原因(即輸入條件或輸入條件的等價類),那些是結果(即輸出條件),並給每個原因和結果賦予一個標識符。
2) 分析軟件規格說明描述中的語義，找出原因與結果之間,原因與原因之間對應的關系，根據這些關系,畫出因果圖。
3) 由於語法或環境限制,有些原因與原因之間,原因與結果之間的組合情況不可能出現，為表明這些特殊情況,在因果圖上用一些記號表明約束或限制條件。
4) 把因果圖轉換為判定表。
5) 把判定表的每一列拿出來作為依據,設計測試用例。
實例1，字符
某軟件規格說明書包含這樣的要求：第一列字符必須是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種情況的測試用例，這是我們所需要的數據。
實例2，自動售貨機
有一個處理單價為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列作為確定測試用例的依據。
（五）判定表驅動法
定義：判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。
優點：能夠將復雜的問題按照各種可能的情況全部列舉出來，簡明並避免遺漏。因此，利用判定表能夠設計出完整的測試用例集合。在一些數據處理問題當中，某些操作的實施依賴於多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執行不同的操作。判定表適合於處理這類問題。
閱讀指南，判定表：
|
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
|
| 問題 |
覺得疲倦嗎？ |
Y |
Y |
Y |
Y |
|
|
|
|
| 感興趣嗎？ |
Y |
Y |
|
|
Y |
Y |
|
|
|
| 糊塗嗎？ |
Y |
|
Y |
|
Y |
|
Y |
|
|
| 建議 |
重讀 |
|
|
|
|
Y |
|
|
|
| 繼續 |
|
|
|
|
|
Y |
|
|
|
| 跳下一章 |
|
|
|
|
|
|
Y |
Y |
|
| 休息 |
Y |
Y |
Y |
Y |
|
|
|
|
|
判定表由四部分組成，如下圖：
1) 條件樁（Condition Stub）：列出了問題的所有條件。通常認為列出的條件的次序無關緊要。
2) 動作樁（Action Stub）：列出了問題規定可能采取的操作。這些操作的排列順序沒有約束。
3) 條件項（Condition Entry）：列出針對它左列條件的取值。在所有可能情況下的真假值。
4) 動作項（Action Entry）：列出在條件項的各種取值情況下應該采取的動作。
規則及規則合並：
1） 規則：任何一個條件組合的特定取值及其相應要執行的操作稱為規則。在判定表中貫穿條件項和動作項的一列就是一條規則。顯然判定表中列出多少組條件取值，也就有多少條規則，既條件項和動作項有多少列。
2） 化簡：就是規則合並有兩條或多條規則具有相同的動作，並且其條件項之間存在着極為相似的關系。
合並舉例：
1) 如下圖左端，兩規則動作項一樣，條件項類似，在1、2條件項分別去Y、N時，無論條件3取何值，都執行同一操作。即要執行的動作與條件3無關。於是可合並。“-”表示與取值無關
2) 與上類似，下圖中，無關條件項“-”可包含其他條件項取值，具有相同動作的規則可合並。
3)
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） 簡化，合並相似規則（相同動作）
實例1，機器維修
問題要求：“。。。。。。對功率大於50馬力的機器，維修記錄不全或已運行10以上的機器，應給予優先的維修處理。。。。。。”，這里假定，“維修記錄不全”和“優先維修處理”均已在別處有更嚴格的定義。請建立判定表。
解答：
1、確定規則的個數：這里有3個條件，每個條件有兩個取值，故應有2*2*2=8種規則。
2、列出所有的條件樁和動作樁：
| 條件 |
功率大於50馬力嗎？ |
| 維修記錄不全嗎？ |
|
| 運行超過10年嗎？ |
|
| 動作 |
進行優先處理 |
3、填入條件項。可從最后1行條件項開始，逐行向上填滿。
4、填入動作樁和動作項。這樣便得到如下圖的初始判定表
|
|
|
|
|
|
|
|
|
|
|
| 條件 |
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
| 功率大於50馬力嗎？ |
Y |
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 |
|
X |
實例2，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決策表
3. 用決策表測試法測試以下程序：該程序有三個輸入變量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
4. 判定表在功能測試中的應用
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個必要條件的目的是為了使操作的執行完全依賴於條件的組合。其實對於某些不滿足這幾條的判定表，同樣可以借以設計測試用例，只不過尚需增加其它的測試用例罷了。
（六）正交試驗法
定義：從大量的（實驗）數據（測試例）中挑選適量的,有代表性的點（例）,從而合理地安排實驗（測試）的一種科學實驗設計方法.類似的方法有:聚類分析方法,因子方法方法等.
利用正交實驗設計測試用例的步驟：
1. 提取功能說明,構造因子--狀態表
把影響實驗指標的條件稱為因子.而影響實驗因子的條件叫因子的狀態.利用正交實驗設計方法來設計測試用例時,首先要根據被測試軟件的規格說明書找出影響其功能實現的操作對象和外部因素,把他們當作因子,而把各個因子的取值當作狀態.對軟件需求規格說明中的功能要求進行划分,把整體的概要性的功能要求進行層層分解與展開,分解成具體的有相對獨立性的基本的功能要求.這樣就可以把被測試軟件中所有的因子都確定下來,並為確定個因子的權值提供參考的依據.確定因子與狀態是設計測試用例的關鍵.因此要求盡可能全面的正確的確定取值,以確保測試用例的設計作到完整與有效。
2. 加權篩選,生成因素分析表
對因子與狀態的選擇可按其重要程度分別加權.可根據各個因子及狀態的作用大小,出現頻率的大小以及測試的需要,確定權值的大小。
3. 利用正交表構造測試數據集
正交表的推導依據Galois理論（這里省略,需要時可查數理統計方面的教材）。
利用正交實驗設計方法設計測試用例,比使用等價類划分,邊界值分析,因果圖等方法有以下優點:節省測試工作工時；可控制生成的測試用例數量；測試用例具有一定的覆蓋率。
（七）功能圖法
定義：功能圖由狀態遷移圖和布爾函數組成.狀態遷移圖用狀態和遷移來描述.一個狀態指出數據輸入的位置（或時間）,而遷移則指明狀態的改變.同時要依靠判定表或因果圖表示的邏輯功能.例,一個簡化的自動出納機ATM的功能圖。
應用：
1. 功能圖介紹
一個程序的功能說明通常由動態說明和靜態說明組成.動態說明描述了輸入數據的次序或轉移的次序.
靜態說明描述了輸入條件與輸出條件之間的對應關系.對於較復雜的程序,由於存在大量的組合情況,因此,僅用靜態說明組成的規格說明對於測試來說往往是不夠的.必須用動態說明來補充功能說明.功能圖方法是用功能圖FD形式化地表示程序的功能說明,並機械地生成功能圖的測試用例.
功能圖模型由狀態遷移圖和邏輯功能模型構成.狀態遷移圖用於表示輸入數據序列以及相應的輸出數據.在狀態遷移圖中,由輸入數據和當前狀態決定輸出數據和后續狀態.邏輯功能模型用於表示在狀態中輸入條件和輸出條件之間的對應關系.邏輯功能模型只適合於描述靜態說明,輸出數據僅由輸入數據決定.測試用例則是由測試中經過的一系列狀態和在每個狀態中必須依靠輸入/輸出數據滿足的一對條件組成.功能圖方法其實是是一種黑盒白盒混合用例設計方法。
（功能圖方法中,要用到邏輯覆蓋和路徑測試的概念和方法,其屬白盒測試方法中 的內容.邏輯覆蓋是以程序內部的邏輯結構為基礎的測試用例設計方法.該方法要求測試人員對程序的邏輯結構有清楚的了解.由於覆蓋測試的目標不同,邏輯覆蓋可分為:語句覆蓋,判定覆蓋,判定-條件覆蓋,條件組合覆蓋及路徑覆蓋.下面我們指的邏輯覆蓋和路徑是功能或系統水平上的,以區別與白盒測試中的程序內部的.）
2. 測試用例生成方法
從功能圖生成測試用例,得到的測試用例數是可接受的. 問題的關鍵的是如何從狀態遷移圖中選取測試用例. 若用節點代替狀態,用弧線代替遷移,則狀態遷移圖就可轉化成一個程序的控制流程圖形式.問題就轉化為程序的路徑測試問題（如白盒測試）問題了.
3. 測試用例生成規則
為了把狀態遷移（測試路徑）的測試用例與邏輯模型（局部測試用例）的測試用例組合起來,從功能圖生成實用的測試用例,須定義下面的規則.在一個結構化的狀態遷移（SST）中,定義三種形式的循環:順序,選擇和重復.但分辨一個狀態遷移中的所有循環是有困難的.（其表示圖形省略）。
4. 從功能圖生成測試用例的過程
1) 生成局部測試用例:在每個狀態中,從因果圖生成局部測試用例.局部測試用例由原因值（輸入數據）組合與對應的結果值（輸出數據或狀態）構成。
2) 測試路徑生成:利用上面的規則（三種）生成從初始狀態到最后狀態的測試路徑。
3) 測試用例合成:合成測試路徑與功能圖中每個狀態中的局部測試用例.結果是初始狀態到最后狀態的一個狀態序列,以及每個狀態中輸入數據與對應輸出數據的組合。
5. 測試用例的合成算法:采用條件構造樹.
（八）場景圖法
定義：現在的軟件幾乎都是用事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。這種在軟件設計方面的思想也可以引入到軟件測試中，可以比較生動地描繪出事件觸發時的情景，有利於測試設計者設計測試用例，同時使測試用例更容易理解和執行。
應用：
基本流和備選流：如下圖所示，圖中經過用例的每條路徑都用基本流和備選流來表示，直黑線表示基本流，是經過用例的最簡單的路徑。備選流用不同的色彩表示，一個備選流可能從基本流開始，在某個特定條件下執行，然后重新加入基本流中（如備選流1和3）；也可能起源於另一個備選流（如備選流2），或者終止用例而不再重新加入到某個流（如備選流2和4）。
1. 例子描述
下圖所示是ATM例子的流程示意圖。
2. 場景設計：下表所示是生成的場景。
表3-8 場景設計
| 場景1——成功提款 |
基本流 |
|
| 場景2——ATM內沒有現金 |
基本流 |
備選流2 |
| 場景3——ATM內現金不足 |
基本流 |
備選流3 |
| 場景4——PIN有誤（還有輸入機會） |
基本流 |
備選流4 |
| 場景5——PIN有誤（不再有輸入機會） |
基本流 |
備選流4 |
| 場景6——賬戶不存在/賬戶類型有誤 |
基本流 |
備選流5 |
| 場景7——賬戶余額不足 |
基本流 |
備選流6 |
注：為方便起見，備選流3和6（場景3和7）內的循環以及循環組合未納入上表。
3. 用例設計
對於這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 |
警告消息，卡予保留，用例結束 |
4. 數據設計
一旦確定了所有的測試用例，則應對這些用例進行復審和驗證以確保其准確且適度，並取消多余或等效的測試用例。
測試用例一經認可，就可以確定實際數據值（在測試用例實施矩陣中）並且設定測試數據，如表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 |
警告消息，卡予保留，用例結束 |
測試用例設計綜合策略
1. Myers提出了使用各種測試方法的綜合策略：
1) 在任何情況下都必須使用邊界值分析方法，經驗表明用這種方法設計出測試用例發現程序錯誤的能力最強。
2) 必要時用等價類划分方法補充一些測試用例。
3) 用錯誤推測法再追加一些測試用例。
4) 對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度，如果沒有達到要求的覆蓋標准，應當再補充足夠的測試用例。
5) 如果程序的功能說明中含有輸入條件的組合情況，則一開始就可選用因果圖法。
2. 測試用例的設計步驟
1) 構造根據設計規格得出的基本功能測試用例；
2) 邊界值測試用例；
3) 狀態轉換測試用例；
4) 錯誤猜測測試用例；
5) 異常測試用例；
6) 性能測試用例；
7) 壓力測試用例。
3. 優化測試用例的方法
1) 利用設計測試用例的8種方法不斷的對測試用例進行分解與合並；
2) 采用遺傳算法理論進化測試用例；
3) 在測試時利用發散思維構造測試用例；
代碼檢查方法：
1、代碼檢查法
（1）桌面檢查：這是一種傳統的檢查方法，由程序員檢查自己編寫的程序。程序員在程序通過編譯之后，對源程序代碼進行分析、檢驗，並補充相關文檔，目的是發現程序中的錯誤。由於程序員熟悉自己的程序及其程序設計風格，桌面檢查由程序員自己進行可以節省很多的檢查時間，但應避免主觀片面性
（2）代碼審查
由若干程序員和測試員組成一個審查小組，通過閱讀、討論和爭議，對程序進行靜態分析的過程。代碼審查分兩步：第一步，小組負責人提前把設計規格說明書、控制流程圖、程序文本及有關要求、規范等分發給小組成員，作為審查的依據。小組成員在充分閱讀這些材料后，進入審查的第二步，召開程序審查會。在會上，首先由程序員逐句簡介程序的邏輯。在此過程中，程序員或其他小組成員可以提出問題，展開討論，審查錯誤是否存在。實踐表明，程序員在講解過程中能發現許多原來自己沒有發現的錯誤，而討論和爭議則促進了問題的暴露。
在會前，應當給審查小組每個成員准備一份常見錯誤的清單，把以往所有可能發生的常見錯誤羅列出來，供與會者對照檢查，以提高審查的失效。這個常見的錯誤清單也成為檢查表，它把程序中可能發生的各種錯誤進行分類，對每一類錯誤列出盡可能多的典型錯誤，然后把它們制成表格，供再審查時使用
（3）走查
與代碼審查基本相同，分為兩步，第一步也是把材料分給走查小組的每個成員，讓他們認真研究程序，然后再開會。開會的程序與代碼審查不同，不是簡單地讀程序和對照錯誤檢查表進行檢查，而是讓與會者“充當”計算機，即首先由測試組成員為所測試程序准備一批有代表性的測試用例，提交給走查小組。走查小組開會，集體扮演計算機角色，讓測試用例沿程序的邏輯運行一遍，隨時記錄程序的蹤跡，供分析和討論用。
人們借助測試用例的媒介作用，對程序的邏輯和功能提出各種疑問，結合問題開展熱烈的討論和爭議，能夠發現更多的問題。
代碼檢查應在編譯和動態測試之前進行，在檢查前，應准備好需求描述文檔、程序設計文檔、程序的源代碼請當、代碼編譯標准和代碼缺陷檢查表等。在實際使用中，代碼檢查能快速找到缺陷，發現30%～70%的邏輯設計和編碼缺陷，而且代碼檢查看到的問題本身而非征兆。但是代碼檢查非常耗費時間，而且代碼檢查需要知識和經驗的積累。代碼檢查可以使用測試軟件進行自動化測試，以利於提高測試效率，降低勞動強度，或者使用人工進行測試，以充分發揮人力的邏輯思維能力
2、代碼檢查項目
變量交叉引用表；標號的交叉引用表；檢查子程序、宏、函數；等價性檢查；常量檢查；標准檢查；風格檢查；比較控制流；選擇、激活路徑；補充文檔
根據檢查項目可以編制代碼規則、規范和檢查表等作為測試用例，如編碼規范、代碼檢查規范、缺陷檢查表等
3、編碼規范
編碼規范是指程序編寫過程中必須遵循的規則，一般會詳細制定代碼的語法規則、語法格式等
4、代碼檢查規范
在代碼檢查中，需要依據被測軟件的特點，選用適當的標准與規則規范。在使用測試軟件進行自動化代碼檢查時，測試工具一般會內置許多的編碼規則。在自動化測試基礎上使用桌面檢查、代碼走查、代碼審查等人工檢查的方法仔細檢查程序的結構、邏輯等方面的缺陷
5、缺陷檢查表
在進行人工代碼檢查時，代碼缺陷檢查表是我們用到的測試用例。
代碼缺陷檢查表中一般包括容易出錯的地方和在以往的工作中遇到的典型錯誤
（二）靜態結構分析法
程序的結構形式是白盒測試的主要依據。研究表明程序員38%的時間花費在理解軟件系統上，因為代碼以文本格式被寫入多重文件中，這是很難閱讀理解的，需要其它一些東西來幫助人們閱讀理解，如各種圖表等，而靜態結構分析滿足了這樣的需求。
在靜態結構分析中，測試者通過使用測試工具分析程序源代碼的系統結構、數據結構、內部控制邏輯等內部結構，生成函數調用關系圖、模塊控制流圖、內部文件調用關系圖、子程序表、宏和函數參數表等各類圖形圖標，可以清晰地標識整個軟件系統的組成結構，使其便於閱讀和理解，然后可以通過分析這些圖標，檢查軟件有沒有存在缺陷或錯誤。
其中函數調用關系圖通過應用程序中各函數之間的調用關系展示了系統的結構。通過查看函數調用關系圖，可以檢查函數之間的調用關系是否符合要求，是否存在遞歸調用，函數的調用曾是是否過深，有沒有存在獨立的沒有被調用的函數。從而可以發現系統是否存在結構缺陷，發現哪些函數是重要的，哪些是次要的，需要使用什么級別的覆蓋要求......
模塊控制流圖是與程序流程圖相類似的由許多節點和連接節點的邊組成的一種圖形，其中一個節點代表一條語句或數條語句，邊代表節點間控制流向，它顯示了一個函數的內部邏輯結構。模塊控制流圖可以直觀地反映出一個函數的內部邏輯結構，通過檢查這些模塊控制流圖，能夠很快發現軟件的錯誤與缺陷
（三）靜態質量度量法
根據ISO/IEC 9126質量模型作為基礎，我們可以構造質量度量模型，用於評估軟件的各個方面。該模型從上到下分為3層：質量因素（Factors）、分類標准（Criteria）和度量規則（metrics）。其中質量因素對應ISO 9126質量模型的質量特性，分類標准對應ISO 9126質量模型的子特性，度量規則用於規范軟件的各種行為屬性。以下例子按照可維護性進行分析。
1、度量規則
度量規則使用了代碼行數、注釋頻度等參數度量軟件的各種行為屬性
2、分類標准
軟件的可維護性采用以下四個分類標准來評估：可分析性（ANALYZABILITY）、可修改性（CHANGEABILITY）、穩定性（STABILITY）、可測性（TESTABILITY）。每個分類標准由一系列度量規則組成，各個規則分配一個權重，由規則的取值與權重值計算出每個分類標准的取值。
function_TESTABILITY_DRCT_CALLS+LEVL+PATH+PARA
3、質量因素
質量因素的取值與分類標准的計算方式類似：依據各分類標准取值組合權重方法計算.
function_MAINTAINABILITY=function_ANALYZABILITY
+function_CHANGEABILITY
+function_ATABILITY
+function_TESTABILITY
（四）邏輯覆蓋法
邏輯覆蓋是以程序內部的邏輯結構為基礎的設計測試用例的技術。
根據覆蓋目標的不同和覆蓋源程序語句的詳盡程度，邏輯覆蓋又可分為：
1. 語句覆蓋(SC)
2. 判定覆蓋(DC)
3. 條件覆蓋(CC)
4. 條件/判定覆蓋(CC)
5. 條件組合覆蓋(MCC)
6. 修正判定條件覆蓋(MCDC)
7. 點覆蓋
8. 邊覆蓋
9. 路徑覆蓋
幾種邏輯覆蓋標准發現錯誤的能力呈由弱至強的變化。
下面我們來逐一舉例詳解：
1語句覆蓋（SC）：
語句覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每一個語句至少執行一次，其覆蓋標准無法發現判定中邏輯運算的錯誤.
我們看下面的被測試代碼：
int foo(int a, int b)
{
return a / b;
}
假如我們的測試人員編寫如下測試案例：
TeseCase: a = 10, b = 5
測試人員的測試結果會告訴你，他的代碼覆蓋率達到了100%，並且所有測試案例都通過了。然而遺憾的是，我們的語句覆蓋率達到了所謂的100%，但是卻沒有發現最簡單的 Bug，比如，當我讓b=0時，會拋出一個除零異常。
簡言之，語句覆蓋，就是設計若干個測試用例，運行被測程序，使得每一可執行語句至少執行一次。這里的“若干個”，意味着使用測試用例越少越好。
語句覆蓋率的公式可以表示如下：
語句覆蓋率=可執行的語句總數/被評價到的語句數量 x 100%
2判定覆蓋(DC)
判定覆蓋是設計足夠多的測試用例，使得程序中的每一個判斷至少獲得一次“真”和一次“假”，即使得程序流程圖中的每一個真假分支至少被執行一次。
但若程序中的判定是有幾個條件聯合構成時，它未必能發現每個條件的錯誤。
例：
int a,b;
if(a || b)
執行語句1
else
執行語句2
要達到這段程序的判斷覆蓋,我們采用測試用例:
1)a = true , b = false;
2)a = false, b = false
3條件覆蓋(CC)
條件覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，判定中每個條件的所有可能結果至少出現一次，但未必能覆蓋全部分支.
例：
int a,b;
if(a || b)
執行語句1
else
執行語句2
要達到這段程序的條件覆蓋,我們采用測試用例:
1)a = true , b = false ;
2)a = false, b = true
4判定/條件覆蓋（CDC）
判定/條件覆蓋是使判定中每個條件的所有可能結果至少出現一次，並且每個判定本身的所有可能結果也至少出現一次。
例：
int a,b;
if(a || b)
執行語句1
else
執行語句2
要達到這段程序的判定/條件覆蓋,我們采用測試用例:
1)a = true , b = true;
2)a = false, b = false
5條件組合覆蓋（MCC）
選擇足夠的測試用例，使得每個判定中條件的各種可能組合都至少出現一次。顯然，滿足“條件組合覆蓋”的測試用例是一定滿足“判定覆蓋”、“條件覆蓋”和“判定/條件覆蓋”的。
例：
int a,b;
if(a || b)
執行語句1
else
執行語句2
要達到這段程序的判定/條件覆蓋,我們采用測試用例:
1)a = true , b = true;
2)a = false, b = false
3)a = true, b = false
4)a = false, b = ture
6修正判定條件覆蓋（MC/DC）
MC/DC首先要求實現條件覆蓋、判定覆蓋，在此基礎上，對於每一個條件C，要求存在符合以下條件的兩次計算：
1）條件C所在判定內的所有條件，除條件C外，其他條件的取值完全相同；
2）條件C的取值相反；
3）判定的計算結果相反。
核心意思是每個條件都要獨立影響判定結果。為什么說“兩次計算”，而不是“兩個用例”呢？當循環中有判定時，一個用例下同一判定可能被計算多次，每次的條件值和判定值也可能不同，因此，一個用例就可能完成循環中判定的MC/DC。
MC/DC是條件組合覆蓋的子集。條件組合覆蓋要求覆蓋判定中所有條件取值的所有可能組合，需要大量的測試用例，實用性較差。MC/DC具有條件組合覆蓋的優勢，同時大幅減少用例數。滿足MC/DC的用例數下界為條件數+1，上界為條件數的兩倍，例如，判定中有三個條件，條件組合覆蓋需要8個用例，而MC/DC需要的用例數為4至6個。如果判定中條件很多，用例數的差別將非常大，例如，判定中有10個條件，條件組合覆蓋需要1024個用例，而MC/DC只需要11至20個用例。
下面是MC/DC的示例：
代碼：
int func(BOOL A, BOOL B, BOOL C)
{
if(A && (B || C))
return 1;
return 0;
}
用例：
對於條件A，用例1和用例2，A取值相反，B和C相同，判定結果分別為1和0；
對於條件B，用例1和用例3，B取值相反，A和C相同，判定結果分別為1和0；
對於條件C，用例3和用例4，C取值相反，A和B相同，判定結果分別為0和1。
9路徑覆蓋（PC）
MC/DC被稱為“最嚴格的標准”，但這種說法是將條件組合覆蓋和路徑覆蓋排除在外為基礎的。MC/DC顯然不如條件組合覆蓋嚴格，但是條件組合覆蓋需要太多用例，實際應用中難以做到，所以排除，那么，路徑覆蓋是否也難以做到？使用先進的工具，對於一般的代碼，實現路徑覆蓋還是可能的。另外，路徑代表了從函數入口到出口的所有可能的代碼組合，這些組合會不會出問題？只有路徑覆蓋能發現，這與MC/DC側重於判定內的條件的組合關系是完全不同的。
ＭC/DC與路徑覆蓋的側重點不同，兩者都有其優勢和局限性，如果組合起來，優勢互補，形成“MC/DC-路徑覆蓋”，就是真正意義上的“最嚴格的標准”了。
有些程序，路徑數量可能大得驚人，可用以下規則和方法減少路徑數量：
計算路徑時，不考慮循環的次數，將循環結構視為循環體“至少執行一次”和“從不執行”兩個分支；
不考慮條件的計算結果只考慮判定的計算結果，條件間的組合關系由條件覆蓋、C/DC和MC/DC負責；
一個分支如果不可達，通過該分支的所有路徑也不可達，可以讓工具自動排除；
當代碼很復雜時，理想的處置方式是將部分代碼獨立為函數，如果做不到，可以讓工具來模擬，即在邏輯結構圖中，將部分代碼臨時屏蔽，被屏蔽的代碼視為一個函數調用。交替屏蔽可以既減少路徑數量，又保證路徑覆蓋的效果。
對於一般復雜度的代碼，采用以上規則和方法后，路徑數量和用例數量可以維持在一個現實可覆蓋的的范圍內。
路徑覆蓋的主要缺陷是：不相關的邏輯塊會組合出大量沒有意義的路徑。一個函數的路徑，可能達到幾萬條甚至幾百萬條。如果路徑超過100條，通常路徑覆蓋就沒有意義了。對於一般企業來說，建議用MC/DC作為統一的覆蓋標准，只有特別關鍵的代碼，才要求完成“MC/DC-路徑覆蓋”。
路徑覆蓋要求設計足夠多的測試用例，在白盒測試法中，覆蓋程度最高的就是路徑覆蓋，因為其覆蓋程序中所有可能的路徑。
對於比較簡單的小程序來說，實現路徑覆蓋是可能的，但是如果程序中出現了多個判斷和多個循環，可能的路徑數目將會急劇增長，以致實現路徑覆蓋是幾乎不可能的。
（五）基本路徑測試法
基本路徑測試法是在程序控制流圖的基礎上，通過分析控制構造的環路復雜性，導出基本可執行路徑集合，從而設計測試用例的方法。
設計出的測試用例要保證在測試中程序的語句覆蓋100%，條件覆蓋100%。
在程序控制流圖的基礎上，通過分析控制構造的環路復雜性，導出基本可執行路徑集合，從而設計測試用例。包括以下4個步驟和一個工具方法：
1.程序的控制流圖：描述程序控制流的一種圖示方法。
2.程序圈復雜度：McCabe復雜性度量。從程序的環路復雜性可導出程序基本路徑集合中的獨立路徑條數，這是確定程序中每個可執行語句至少執行一次所必須的測試用例數目的上界。
3.導出測試用例：根據圈復雜度和程序結構設計用例數據輸入和預期結果。
4.准備測試用例：確保基本路徑集中的每一條路徑的執行。
工具方法：
圖形矩陣：是在基本路徑測試中起輔助作用的軟件工具，利用它可以實現自動地確定一個基本路徑集。
程序的控制流圖：描述程序控制流的一種圖示方法。
圓圈稱為控制流圖的一個結點，表示一個或多個無分支的語句或源程序語句
流圖只有二種圖形符號：
圖中的每一個圓稱為流圖的結點，代表一條或多條語句。
流圖中的箭頭稱為邊或連接，代表控制流
任何過程設計都要被翻譯成控制流圖。
如何根據程序流程圖畫出控制流程圖?
在將程序流程圖簡化成控制流圖時，應注意：
1）在選擇或多分支結構中，分支的匯聚處應有一個匯聚結點。
2）邊和結點圈定的范圍叫做區域，當對區域計數時，圖形外的區域也應記為一個區域。
如下圖所示
3）如果判斷中的條件表達式是由一個或多個邏輯運算符 (OR, AND, NAND, NOR)連接的復合條件表達式，則需要改為一系列只有單條件的嵌套的判斷。
例如：
1 if a or b
2 x
3 else
4 y
對應的邏輯為：
獨立路徑：至少沿一條新的邊移動的路徑
基本路徑測試法的步驟：
第一步：畫出控制流圖
流程圖用來描述程序控制結構。可將流程圖映射到一個相應的流圖(假設流程圖的菱形決定框中不包含復合條件)。在流圖中，每一個圓，稱為流圖的結點，代表一個或多個語句。一個處理方框序列和一個菱形決測框可被映射為一個結點，流圖中的箭頭，稱為邊或連接，代表控制流，類似於流程圖中的箭頭。一條邊必須終止於一個結點，即使該結點並不代表任何語句(例如：if-else-then結構)。由邊和結點限定的范圍稱為區域。計算區域時應包括圖外部的范圍。
畫出其程序流程圖和對應的控制流圖如下
第二步：計算圈復雜度
圈復雜度是一種為程序邏輯復雜性提供定量測度的軟件度量，將該度量用於計算程序的基本的獨立路徑數目，為確保所有語句至少執行一次的測試數量的上界。獨立路徑必須包含一條在定義之前不曾用到的邊。
有以下三種方法計算圈復雜度：
流圖中區域的數量對應於環型的復雜性;
給定流圖G的圈復雜度V(G)，定義為V(G)=E-N+2，E是流圖中邊的數量，N是流圖中結點的數量;
給定流圖G的圈復雜度V(G)，定義為V(G)=P+1，P是流圖G中判定結點的數量。
第三步：導出測試用例
根據上面的計算方法，可得出四個獨立的路徑。(一條獨立路徑是指，和其他的獨立路徑相比，至少引入一個新處理語句或一個新判斷的程序通路。V(G)值正好等於該程序的獨立路徑的條數。)
ü路徑1：4-14
ü路徑2：4-6-7-14
ü路徑3：4-6-8-10-13-4-14
ü路徑4：4-6-8-11-13-4-14
根據上面的獨立路徑，去設計輸入數據，使程序分別執行到上面四條路徑。
o第四步：准備測試用例
為了確保基本路徑集中的每一條路徑的執行，根據判斷結點給出的條件，選擇適當的數據以保證某一條路徑可以被測試到，滿足上面例子基本路徑集的測試用例是：
舉例說明：
例：下例程序流程圖描述了最多輸入50個值(以–1作為輸入結束標志)，計算其中有效的學生分數的個數、總分數和平均值。
步驟1：導出過程的流圖。
步驟2:確定環形復雜性度量V(G)：
1)V(G)= 6 (個區域)
2)V(G)=E–N+2=16–12+2=6
其中E為流圖中的邊數，N為結點數;
3)V(G)=P+1=5+1=6
其中P為謂詞結點的個數。在流圖中，結點2、3、5、6、9是謂詞結點。
步驟3：確定基本路徑集合(即獨立路徑集合)。於是可確定6條獨立的路徑：
路徑1：1-2-9-10-12
路徑2：1-2-9-11-12
路徑3：1-2-3-9-10-12
路徑4：1-2-3-4-5-8-2…
路徑5：1-2-3-4-5-6-8-2…
路徑6：1-2-3-4-5-6-7-8-2…
步驟4：為每一條獨立路徑各設計一組測試用例，以便強迫程序沿着該路徑至少執行一次。
1)路徑1(1-2-9-10-12)的測試用例：
score[k]=有效分數值，當k < i ;
score[i]=–1, 2≤i≤50;
期望結果：根據輸入的有效分數算出正確的分數個數n1、總分sum和平均分average。
2)路徑2(1-2-9-11-12)的測試用例：
score[ 1 ]= – 1 ;
期望的結果：average = – 1，其他量保持初值。
3)路徑3(1-2-3-9-10-12)的測試用例：
輸入多於50個有效分數，即試圖處理51個分數，要求前51個為有效分數;
期望結果：n1=50、且算出正確的總分和平均分。
4)路徑4(1-2-3-4-5-8-2…)的測試用例：
score[i]=有效分數，當i<50;
score[k]<0， k< i ;
期望結果：根據輸入的有效分數算出正確的分數個數n1、總分sum和平均分average。
連接權為“1”表示存在一個連接，在圖中如果一行有兩個或更多的元素“1”，則這行所代表的結點一定是一個判定結點，通過連接矩陣中有兩個以上(包括兩個)元素為“1”的個數，就可以得到確定該圖圈復雜度的另一種算法。
（六）域測試法
域測試是一種基於程序結構的測試方法，基於對程序輸入空間（域）的分析，選擇測試點進行測試。
域測試主要測試如下錯誤：
1）域錯誤：程序的控制流存在錯誤，對於某一特定的輸入可能執行的是一條錯誤路徑，這種錯誤稱為路徑錯誤，也叫做域錯誤。
2）計算型錯誤：對於特定輸入執行的路徑正確，但賦值語句的錯誤導致輸出結果錯誤，稱為計算型錯誤。
3）丟失路徑錯誤：由於程序中的某處少了一個判定謂詞而引起的丟失路徑錯誤。
（七）符號測試
符號測試的基本思想是允許程序的輸入不僅僅是具體的數值數據，而且包括符號值，符號值可以是基本的符號變量值，也可以是符號變量值的表達式。
接口測試用例實際
設計思路
1) 優先級--針對所有接口
1、暴露在外面的接口，因為通常該接口會給第三方調用；
2、供系統內部調用的核心功能接口；
3、供系統內部調用非核心功能接口；
2) 優先級--針對單個接口
1、正向用例優先測試,逆向用例次之(通常情況，非絕對)；
2、是否滿足前提條件 > 是否攜帶默認參值參數 > 參數是否必填 > 參數之間是否存在關聯 > 參數數據類型限制 >參數數據類型自身的數據范圍值限制
3) 設計分析
通常，設計接口測試用例需要考慮以下幾個方面：
1、是否滿足前提條件
有些接口需要滿足前置條件，才可成功獲取數據。常見的，需要登陸Token。
逆向用例：
針對是否滿足前置條件(假設為n個條件)，設計0~n條用例
2、是否攜帶默認值參數
正向用例：
帶默認值的參數都不填寫、不傳參，必填參數都填寫正確且存在的“常規”值，其它不填寫，設計1條用例；
3、業務規則、功能需求
這里根據實際情況，結合接口參數說明，可能需要設計n條正向用例和逆向用例
5、參數是否必填
逆向用例：
針對每個必填參數，都設計1條參數值為空的逆向用例
4、參數之間是否存在關聯
有些參數彼此之間存在相互制約的關系
逆向用例：
根據實際情況，可能需要設計0~n條用例
5、參數數據類型限制
逆向用例：
針對每個參數都設計1條參數值類型不符的逆向用例
6、參數數據類型自身的數據范圍值限制
正向用例：
針對所有參數，設計1條每個參數的參數值在數據范圍內為最大值的正向用例
逆向用例：
針對每個參數(假設n個)，設計n條每個參數的參數值都超出數據范圍最大值的逆向用例
針對每個參數(假設n個)，設計n條每個參數的參數值都小於數據范圍最小值的逆向用例
以上幾個方面考慮全的話，基本可以做到如下幾個方面的覆蓋：
主流程測試用例：正常的主流程功能校驗；
分支流測試用例：正常的分支流功能校驗。
異常流測試用例：異常容錯校驗
4) 編寫描述
盡量邏輯化，這樣方便后續的維護
5) 實踐操作
接口樣例
獲取訂單列表接口（多條件）
獲取店鋪指定期間的所有訂單列表(多種條件組合)，默認根據日期倒序排序。
接口方向
客戶端 -> 服務端
接口協議
接口地址：$xxx_Home/xxx/鑒權前綴/xxxxx/getAllOrderList
接口協議：JSON
HTTP請求方式：GET
消息請求
字段列表如下：
| 字段名 |
數據類型 |
默認值 |
必填項 |
備注 |
| shopId |
int |
|
是 |
商鋪編號 |
| token |
string |
|
條件 |
設備令牌。Token鑒權方式必填 |
| dateType |
int |
1 |
否 |
訂單查詢時間字段。 1：下單時間（order_time） 2：訂單完成時間（order_finish_time） 3：結算時間（shop_settle_time） |
| startDate |
date |
|
是 |
查詢日期 |
| endDate |
Date |
|
否 |
查詢結束日期。 |
| orderStatus |
String |
|
否 |
訂單狀態。 不填表示所有狀態 多個狀態之間以英文逗號分割 0:已預定 1:已開單 2:派送中 3:已完成（原已結帳） 4:退單中 5:已退單 8:自助下單 9:待確認 |
| orderTransactionType |
Int |
|
否 |
訂單交易狀態。 不填表示所有。 1:未完成， 2:已完成(3:已完成, 5:已退單) |
| payType |
int |
|
否 |
支付方式。 不填表示所有。 1:現金 2:POS 3:線上 |
| cashierId |
int |
|
否 |
收銀員 |
| billerId |
int |
|
否 |
導購員 |
| pNo |
int |
|
否 |
頁碼,從第1頁開始，默認為1 |
| pSize |
int |
|
否 |
每頁記錄數，默認為10 |
消息請求樣例：
?shopId=1111111111&token=123411nmk515155&queryDate=2015-10-10
消息響應
字段元素如下：
| 字段名 |
數據類型 |
默認值 |
必填項 |
備注 |
| orderTotalPriceTotal |
double |
|
是 |
實收金額合計（已完成的合計） |
| platformTotalIncomePriceTotal |
double |
|
是 |
平台服務費合計 |
| cashPayTotal |
double |
|
否 |
現金支付（已完成的合計） |
| posPayTotal |
double |
|
否 |
POS支付（已完成的合計） |
| onLinePayTotal |
double |
|
否 |
線上支付（已完成的合計） |
| lst |
object |
|
是 |
明細列表 |
明細列表對象字段元素定義：
| 字段名 |
數據類型 |
默認值 |
必填項 |
備注 |
| orderId |
string |
|
是 |
訂單ID |
| orderTitle |
string |
|
是 |
訂單標題 |
| mobile |
string |
|
否 |
會員賬號,如果是會員則顯示手機號，為空時表示“非會員” |
| settlePrice |
double |
|
是 |
交易金額 |
| orderTime |
datetime |
|
是 |
下單時間 |
| serviceAmount |
double |
|
是 |
平台服務費 |
| Status |
Int |
|
是 |
訂單狀態。 0:已預定 1:已開單 2:派送中 3:已完成（原已結帳） 4:退單中 5:已退單 8:自助下單 9:待確認 |
| cashPay |
double |
|
否 |
現金支付 |
| posPay |
double |
|
否 |
POS支付 |
| onLinePay |
double |
|
否 |
線上支付 |
成功時，返回JSON數據包：
{
"code": 0,
"msg": "查詢訂單列表成功！",
"data": {
"pNo": 1,
"rCount": 5,
"orderTotalPriceTotal": 23.3,
"platformTotalIncomePriceTotal": 0,
"lst": [
{
"orderTitle": "kouxiangtang",
"settlePrice": 15.89,
"cashTotal": 15.89,
"posTotal": 0,
"onLineTotal": 0,
"orderTime": "2015-09-29 13:44:26",
"orderId": "12345679282015092913440268141",
"mobile": "13424183952"
},
{
"orderTitle": "紅塔山",
"settlePrice": 7.5,
"cashTotal": 7.5,
"posTotal": 0,
"onLineTotal": 0,
"orderTime": "2015-09-29 11:37:58",
"orderId": "12345679282015092911370588273"
}
]
}
}
用例設計
存在問題：
如上，還沒寫完就有40幾條用例了，要是接口參數再多點，接口數量再增加點，工作量可想而知，所以，問題來了，咋辦呢？
個人見解：
1、根據接口的使用對象(外部，系統內部)，有選擇的去、留部分用例
2、根據接口的是否核心接口，有選擇的去、留部分用例
3、根據參數說明，及實際情況，有選擇的去、留部分用例
實例：
上例這個接口，是供app、商鋪后台調用的，且為系統內部調用，所以，以下用例可酌情略去：
test-E-按商鋪id查詢-商鋪id非int型
test-E-按設備token查詢-token非string類型
test-E-按訂單時間類型查詢-時間類型非int型
test-E-按起始日期查詢-時間類型非date型
test-E-按結束日期查詢-時間類型非date型
test-E-按訂單狀態查詢-訂單狀態非string類型
test-E-按交易狀態查詢-交易狀態非int型
test-E-按支付方式查詢-支付方式非int值
test-E-按收銀員查詢-收銀員id非int值
test-E-按導購員查詢-導購員id非int值
test-E-按頁碼查詢-頁碼非int值
理由：
這個接口是給其它開發於系統內部調用的，開發過程中，開發者肯定需要調用這些接口，如果類型錯了，他們也就獲取不到預期的數據，這些錯誤，他們肯定可以發現，所以，他們傳遞的參數值一般能保證類型正確。
test-N-按參數類型最大值查詢 所有參數
test-E-按商鋪id查詢-商鋪id超過類型范圍值
test-E-按訂單狀態查詢-訂單狀態值超過類型最大值
test-E-按交易狀態查詢-交易狀態值超過int類型最大值
略去的用例部分（參數值超過類型最大值）
理由：
1、內部調用，參數值不是外部手動輸入的，輸入數據長度、值大小可控，當然如果數據一直增長，那再大的類型可能都無法保證不超出，比如自動增長的商鋪id
2、部分參數的參數值是自定義的，比如 訂單時間類型，就那幾種，除非傳錯了，不然不可能超出范圍
最后簡化后的用例數差不多28條，如果是手工測試，對於正向用例，根據等價類原理，可以制造一條數據，覆蓋多條用例，當然，也可以冗余處理，即一條用例一條數據，這樣的好處就是每次的驗證點比較單一一點，比較有針對性。