自動化測試之-測試用例設計方法總結

時間 2019-11-12

原文原文鏈接

黑盒、白盒、接口測試一系列用例設計方法。html

黑盒測試用例設計方法包括等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、斷定表驅動法、正交試驗設計法、功能圖法、場景圖法等。mysql

（一）等價類劃分法程序員

定義：等價類劃分法是把全部可能輸入的數據，即程序的輸入域劃分策劃國內若干部分（子集），而後從每個子集中選取少數具備表明性的數據做爲測試用例。方法是一種重要的、經常使用的黑盒測試用例設計方法。算法

等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對於揭露程序中的錯誤都是等效的，併合理地假定：測試某等價類的表明值就等於對這一類其餘值的測試，所以，能夠把所有輸入數據合理劃分爲若干等價類，在每個等價類中取一個數據做爲測試的輸入條件就能夠用少許表明性的測試數據取得較好的測試結果。等價類劃分有兩種不一樣的狀況：有效等價類和無效等價類。sql

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

無效等價類指對程序的規格說明是不合理的或無心義的輸入數據所構成的集合。對於具體的問題，無效等價類至少應有一個，也可能多個。編程

劃分標準：小程序

1) 完備測試、避免冗餘api

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＜＝month＜＝12

二、1＜＝day<=31

三、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.2四、還可取一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]。

測試用例

預期輸出

Test1

Test2

Test3

Test4

Test5

100

等腰三角形

等邊三角形

等腰三角形

非三角形

Test6

Test7

Test8

Test9

100

等腰三角形

非三角形

Test10

Test11

Test12

Test13

100

等腰三角形

非三角形

實例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卡，呼出無效號碼（如一、88八、33333三、不輸入任何號碼等）

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) 以下圖左端，兩規則動做項同樣，條件項相似，在一、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）簡化，合併類似規則（相同動做）

實例1，機器維修

問題要求：「。。。。。。對功率大於50馬力的機器，維修記錄不全或已運行10以上的機器，應給予優先的維修處理。。。。。。」，這裏假定，「維修記錄不全」和「優先維修處理」均已在別處有更嚴格的定義。請創建斷定表。

解答：

一、肯定規則的個數：這裏有3個條件，每一個條件有兩個取值，故應有2*2*2=8種規則。

二、列出全部的條件樁和動做樁：

條件	功率大於50馬力嗎？
	維修記錄不全嗎？
	運行超過10年嗎？
動做	進行優先處理

三、填入條件項。可從最後1行條件項開始，逐行向上填滿。

四、填入動做樁和動做項。這樣便獲得以下圖的初始斷定表


條件		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

五、

初始斷定表化簡。合併類似規則後獲得


條件		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不知足，或者當條件一、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）。

9.3. 實例

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樓 2018-04-10 15:23 Elsie-Y

內容很好，借參考，謝謝啦，已關注

支持(0) 反對(0)

白盒測試常見的用例設計方法有：代碼檢查法、靜態結構分析法、靜態質量度量法、邏輯覆蓋法、基本路徑覆蓋測試法、域測試、符號測試。

（一）代碼檢查法

代碼檢查包括桌面檢查、代碼審查和走查等，主要檢查代碼和設計的一致性，代碼對標準的遵循、可讀性，代碼邏輯表達的正確性，代碼結構的合理性等方面；發現違背程序編寫標準的問題，程序中不安全、不明確和模糊的部分，找出程序中不可移植部分、違背程序編程風格的內容，包括變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結構檢查等內容。

代碼檢查方法：

一、代碼檢查法

（1）桌面檢查：這是一種傳統的檢查方法，由程序員檢查本身編寫的程序。程序員在程序經過編譯以後，對源程序代碼進行分析、檢驗，並補充相關文檔，目的是發現程序中的錯誤。因爲程序員熟悉本身的程序及其程序設計風格，桌面檢查由程序員本身進行能夠節省不少的檢查時間，但應避免主觀片面性

（2）代碼審查

由若干程序員和測試員組成一個審查小組，經過閱讀、討論和爭議，對程序進行靜態分析的過程。代碼審查分兩步：第一步，小組負責人提早把設計規格說明書、控制流程圖、程序文本及有關要求、規範等分發給小組成員，做爲審查的依據。小組成員在充分閱讀這些材料後，進入審查的第二步，召開程序審查會。在會上，首先由程序員逐句簡介程序的邏輯。在此過程當中，程序員或其餘小組成員能夠提出問題，展開討論，審查錯誤是否存在。實踐代表，程序員在講解過程當中能發現許多原來本身沒有發現的錯誤，而討論和爭議則促進了問題的暴露。

在會前，應當給審查小組每一個成員準備一份常見錯誤的清單，把以往全部可能發生的常見錯誤羅列出來，供與會者對照檢查，以提升審查的失效。這個常見的錯誤清單也成爲檢查表，它把程序中可能發生的各類錯誤進行分類，對每一類錯誤列出儘量多的典型錯誤，而後把它們製成表格，供再審查時使用

（3）走查

與代碼審查基本相同，分爲兩步，第一步也是把材料分給走查小組的每一個成員，讓他們認真研究程序，而後再開會。開會的程序與代碼審查不一樣，不是簡單地讀程序和對照錯誤檢查表進行檢查，而是讓與會者「充當」計算機，即首先由測試組成員爲所測試程序準備一批有表明性的測試用例，提交給走查小組。走查小組開會，集體扮演計算機角色，讓測試用例沿程序的邏輯運行一遍，隨時記錄程序的蹤影，供分析和討論用。

人們藉助測試用例的媒介做用，對程序的邏輯和功能提出各類疑問，結合問題開展熱烈的討論和爭議，可以發現更多的問題。

代碼檢查應在編譯和動態測試以前進行，在檢查前，應準備好需求描述文檔、程序設計文檔、程序的源代碼請當、代碼編譯標準和代碼缺陷檢查表等。在實際使用中，代碼檢查能快速找到缺陷，發現30%～70%的邏輯設計和編碼缺陷，並且代碼檢查看到的問題自己而非徵兆。可是代碼檢查很是耗費時間，並且代碼檢查須要知識和經驗的積累。代碼檢查可使用測試軟件進行自動化測試，以利於提升測試效率，下降勞動強度，或者使用人工進行測試，以充分發揮人力的邏輯思惟能力

二、代碼檢查項目

變量交叉引用表；標號的交叉引用表；檢查子程序、宏、函數；等價性檢查；常量檢查；標準檢查；風格檢查；比較控制流；選擇、激活路徑；補充文檔

根據檢查項目能夠編制代碼規則、規範和檢查表等做爲測試用例，如編碼規範、代碼檢查規範、缺陷檢查表等

三、編碼規範

編碼規範是指程序編寫過程當中必須遵循的規則，通常會詳細制定代碼的語法規則、語法格式等

四、代碼檢查規範

在代碼檢查中，須要依據被測軟件的特色，選用適當的標準與規則規範。在使用測試軟件進行自動化代碼檢查時，測試工具通常會內置許多的編碼規則。在自動化測試基礎上使用桌面檢查、代碼走查、代碼審查等人工檢查的方法仔細檢查程序的結構、邏輯等方面的缺陷

五、缺陷檢查表

在進行人工代碼檢查時，代碼缺陷檢查表是咱們用到的測試用例。

代碼缺陷檢查表中通常包括容易出錯的地方和在以往的工做中遇到的典型錯誤

（二）靜態結構分析法

程序的結構形式是白盒測試的主要依據。研究代表程序員38%的時間花費在理解軟件系統上，由於代碼以文本格式被寫入多重文件中，這是很難閱讀理解的，須要其它一些東西來幫助人們閱讀理解，如各類圖表等，而靜態結構分析知足了這樣的需求。

在靜態結構分析中，測試者經過使用測試工具分析程序源代碼的系統結構、數據結構、內部控制邏輯等內部結構，生成函數調用關係圖、模塊控制流圖、內部文件調用關係圖、子程序表、宏和函數參數表等各種圖形圖標，能夠清晰地標識整個軟件系統的組成結構，使其便於閱讀和理解，而後能夠經過分析這些圖標，檢查軟件有沒有存在缺陷或錯誤。

其中函數調用關係圖經過應用程序中各函數之間的調用關係展現了系統的結構。經過查看函數調用關係圖，能夠檢查函數之間的調用關係是否符合要求，是否存在遞歸調用，函數的調用曾是是否過深，有沒有存在獨立的沒有被調用的函數。從而能夠發現系統是否存在結構缺陷，發現哪些函數是重要的，哪些是次要的，須要使用什麼級別的覆蓋要求......

模塊控制流圖是與程序流程圖相相似的由許多節點和鏈接節點的邊組成的一種圖形，其中一個節點表明一條語句或數條語句，邊表明節點間控制流向，它顯示了一個函數的內部邏輯結構。模塊控制流圖能夠直觀地反映出一個函數的內部邏輯結構，經過檢查這些模塊控制流圖，可以很快發現軟件的錯誤與缺陷

（三）靜態質量度量法

根據ISO/IEC 9126質量模型做爲基礎，咱們能夠構造質量度量模型，用於評估軟件的各個方面。該模型從上到下分爲3層：質量因素（Factors）、分類標準（Criteria）和度量規則（metrics）。其中質量因素對應ISO 9126質量模型的質量特性，分類標準對應ISO 9126質量模型的子特性，度量規則用於規範軟件的各類行爲屬性。如下例子按照可維護性進行分析。

一、度量規則

度量規則使用了代碼行數、註釋頻度等參數度量軟件的各類行爲屬性

二、分類標準

軟件的可維護性採用如下四個分類標準來評估：可分析性（ANALYZABILITY）、可修改性（CHANGEABILITY）、穩定性（STABILITY）、可測性（TESTABILITY）。每一個分類標準由一系列度量規則組成，各個規則分配一個權重，由規則的取值與權重值計算出每一個分類標準的取值。

function_TESTABILITY_DRCT_CALLS+LEVL+PATH+PARA

三、質量因素

質量因素的取值與分類標準的計算方式相似：依據各分類標準取值組合權重方法計算.

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爲謂詞結點的個數。在流圖中，結點二、三、五、六、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;

　　指望結果：根據輸入的有效分數算出正確的分數個數n一、總分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 ;

　指望結果：根據輸入的有效分數算出正確的分數個數n一、總分sum和平均分average。

鏈接權爲「1」表示存在一個鏈接，在圖中若是一行有兩個或更多的元素「1」，則這行所表明的結點必定是一個斷定結點，經過鏈接矩陣中有兩個以上(包括兩個)元素爲「1」的個數，就能夠獲得肯定該圖圈複雜度的另外一種算法。

（六）域測試法

域測試是一種基於程序結構的測試方法，基於對程序輸入空間（域）的分析，選擇測試點進行測試。

域測試主要測試以下錯誤：

1）域錯誤：程序的控制流存在錯誤，對於某一特定的輸入可能執行的是一條錯誤路徑，這種錯誤稱爲路徑錯誤，也叫作域錯誤。

2）計算型錯誤：對於特定輸入執行的路徑正確，但賦值語句的錯誤致使輸出結果錯誤，稱爲計算型錯誤。

3）丟失路徑錯誤：因爲程序中的某處少了一個斷定謂詞而引發的丟失路徑錯誤。

（七）符號測試

符號測試的基本思想是容許程序的輸入不只僅是具體的數值數據，並且包括符號值，符號值能夠是基本的符號變量值，也能夠是符號變量值的表達式。

接口測試用例實際

設計思路

1) 優先級--針對全部接口

一、暴露在外面的接口，由於一般該接口會給第三方調用；

二、供系統內部調用的核心功能接口；

三、供系統內部調用非核心功能接口；

2) 優先級--針對單個接口

一、正向用例優先測試,逆向用例次之(一般狀況，非絕對)；

二、是否知足前提條件 > 是否攜帶默認參值參數 > 參數是否必填 > 參數之間是否存在關聯 > 參數數據類型限制 >參數數據類型自身的數據範圍值限制

3) 設計分析

一般，設計接口測試用例須要考慮如下幾個方面：

一、是否知足前提條件

有些接口須要知足前置條件，纔可成功獲取數據。常見的，須要登錄Token。

逆向用例：

針對是否知足前置條件(假設爲n個條件)，設計0~n條用例

二、是否攜帶默認值參數

正向用例：

帶默認值的參數都不填寫、不傳參，必填參數都填寫正確且存在的「常規」值，其它不填寫，設計1條用例；

三、業務規則、功能需求

這裏根據實際狀況，結合接口參數說明，可能須要設計n條正向用例和逆向用例

五、參數是否必填

逆向用例：

針對每一個必填參數，都設計1條參數值爲空的逆向用例

四、參數之間是否存在關聯

有些參數彼此之間存在相互制約的關係

逆向用例：

根據實際狀況，可能須要設計0~n條用例

五、參數數據類型限制

逆向用例：

針對每一個參數都設計1條參數值類型不符的逆向用例

六、參數數據類型自身的數據範圍值限制

正向用例：

針對全部參數，設計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		否	線上支付