單元測試用例設計

一、概述.................................................1

二、基本概念.............................................1

2.1正面測試(PositiveTesting)..................................................................1

2.2負面測試(NegativeTesting)................................................................2

2.3分支測試..........................................2

2.4黑盒測試..........................................2

2.5白盒測試..........................................2

三、單元測試范圍.........................................3

四、常見測試用例設計方法及舉例...........................3

4.1用于語句覆蓋的基路徑法............................3

4.2用于MC/DC的真值表法............................9

4.3邊界值法.........................................11

4.4等價類法.........................................12

4.5循環(huán)測試法.......................................17

4.6錯誤推測法.......................................18

五、相關注意事項........................................18

5.1獨立性...........................................18

5.2盡量脫離被測代碼的束縛...........................18

5.3面向?qū)ο蟮恼Z言單元測試特點.......................18

5.4單元測試的命名標準...............................19

L單元測試的命名標準.............................19

2.單元測試中的變量命名規(guī)范......................19

3.斷言和操作分離................................19

4.避免濫用setup和teardown............................................19

一、概述

單元測試（模塊測試）是開發(fā)者編寫的一小段代碼，用于檢驗被

測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元

測試是用于判斷某個特定條件（或者場景）下某個特定函數(shù)的行為。

該文檔從測試角度出發(fā)，去討論如何設計單元測試的測試用例。

這里強調(diào)，單元測試用例的設計是進入實際編碼之前的，測試用

例設計在前，更能體現(xiàn)出靈活性，如果已經(jīng)編碼完成再進行測試用例

的補充，這樣很容易進入一個僅僅是測試了被測代碼段功能的怪圈，

所以希望所有的單元測試工作，可以放在前面完成。同時單元測試用

例是一個不斷完善的過程，前期設計好的用例，在代碼已經(jīng)實現(xiàn)完成

后，會發(fā)現(xiàn)覆蓋的并不是很全面，有良好的習慣是需要將對應的測試

用例進行補充，而在提交測試后發(fā)現(xiàn)的重要的bug,也需要進行單元

測試用例的補充，使單元測試和各種測試方法相結合，實現(xiàn)測試質(zhì)量

的充分保證。

二、基本概念

2.1正面測試（PositiveTesting）

測試被測對象的正確功能實現(xiàn)無誤，即正常流程功能。往往需要

根據(jù)設計說明進行用例導出，嚴格按照設計說明編寫即可，用例劃分

注意等價類區(qū)分等方法。

例如：接口返回小于等于24個中文字的offer標題（這里標題控制不

1

會超過24個字)進行頁面展示。

2.2負面測試(NegativeTesting)

測試被測對象的異常功能實現(xiàn)無誤，多在異常流程，異常數(shù)據(jù)中

體現(xiàn)。該部分測試需要對被測對象進行錯誤發(fā)散，常依賴于邊界值區(qū)

分等方法。

例如：接口返回25個中文字的offer標題進行頁面展示。

2.3分支測試

使用流程圖，明確可能出現(xiàn)的每條分支，制造響應的數(shù)據(jù)進行覆

蓋，實現(xiàn)對被測對象的測試。這個過程對于分支可以進行響應的簡化,

可以穿插等價類等方法去除同類分支。

例如：實現(xiàn)。ffer發(fā)布的功能，分別會出現(xiàn)發(fā)布普通產(chǎn)品，代理加盟,

求購，供應等分支，測試。ffer提交模塊的時候，需要區(qū)分這么多重

類型的數(shù)據(jù)，那么假設對于全部供應類型的offer,實現(xiàn)上都是一樣

的，就可以進行等價類劃分，區(qū)分供應和求購即可。

2.4黑盒測試

不關心被測對象內(nèi)部，將其當做一個黑盒，僅僅關注對該模塊的

輸入?yún)^(qū)分和輸出結果校驗。

2.5白盒測試

2

將被測對象的每個實現(xiàn)都充分了解，根據(jù)內(nèi)部實現(xiàn)進行用例設

計■，需要保證每個獨立路徑都完成用例覆蓋，而常規(guī)的對每個獨立路

徑進行真假驗證。

三、單元測試范圍

單元測試范圍的重點包括兩個方面：1.測試代碼實現(xiàn)的功能，這

個可以通過需求文檔進行整理，然后調(diào)整每個功能點的顆粒度，盡量

可以和開發(fā)實現(xiàn)的被測單元進行對應，入口文檔包括需求文檔、設計

文檔；2.外部接口和底層實現(xiàn)。

四、常見測試用例設計方法及舉例

4.1用于語句覆蓋的基路徑法

基路徑法保證設計出的測試用例，使程序的每一個可執(zhí)行語句至

少執(zhí)行一次，即實現(xiàn)語句覆蓋。基路徑法是理論與應用脫節(jié)的典型，

基本上沒有應用價值，讀者稍作了解即可，不必理解和掌握。

基路徑法步驟如下：

1）畫出程序的控制流圖

控制流圖是描述程序控制流的一種圖示方法，主要由結點和邊構

成，邊代表控制流的方向，節(jié)點代表控制流的匯聚處，邊和結點圈定

的空間叫做區(qū)域，下面是控制流圖的基本元素：

3

依序結構?，IF選擇結構”While罐環(huán)結構，CASE多分支結構?,

Until循環(huán)結構.

以下代碼：

voidSort(intiRecordNum,intiType)

{

intx=0；

inty=0；

while(iRecordNum—>0)

{

if(0==iType)

{

x=y+2;

break;

4

}

elseif(1==iType)

x=y+10;

eIse

x=y+20;

}

可以畫出以下控制流圖:

5

2)計算程序環(huán)路復雜度

環(huán)路復雜度V(G)可用以下3種方法求得：

(1)環(huán)路復雜度等于控制流圖中的區(qū)域數(shù)；

上圖中，有4個區(qū)域，V(G)=4。

(2)設E為控制流圖的邊數(shù)，N為結點數(shù)，則環(huán)路復雜度為E—N+

2；

上圖中，V(G)=10(邊)一8(結點)+2=4。

(3)設P為控制流圖中的判定結點數(shù)，環(huán)路復雜度為P+1。

6

上圖中：V(G)=3(判定結點)+1=4。

環(huán)路復雜度是獨立路徑數(shù)的上界，也就是需要的測試用例數(shù)的上界。

3)導出基本路徑集

基本路徑數(shù)等于V(G)。根據(jù)上面的計算方法，可得出需要的基

本路徑數(shù)為4。路徑就是從程序的入口到出口的可能路線，基本路徑

要求每條路徑至少包含一條新的邊，直到所有的邊都被包含。需要提

醒的是：基路徑法和路徑覆蓋是兩回事，用于設計用例的基路徑數(shù)一

般小于全部路徑數(shù)，即基本路徑集不是惟一的。基路徑法完成的是語

句覆蓋，而不是路徑覆蓋。下面選擇四條基本路徑：

路徑1：1-11

路徑2：1-2-3-4-5-1-11

路徑3：1-2-3-6-8-9-10-1-11

路徑4：1-2-3-6-7-9-10-1-11

4)設計用例

根據(jù)上面的路徑，可以設計出以下用例：

7

路徑1:1-11

用例1：iRecordNum=0

路徑2：1-2-3-4-5-1-11

用例2：iRecordNum=1,iType=0

路徑3：1-2-3-6-8-9-10-1-11

用例3：iRecordNum=1,iType=1

路徑4：1-2-3-6-7-9-10-1-11

用例4：iRecordNum=1,iType=2

從上述步驟可以看出，基路徑法工作量巨大，如果用于五十行左

右的函數(shù)，將耗費大量的時間，而五十行代碼的函數(shù)實在是太普通了。

這種成本巨高的方法，其測試效果如何呢？測試效果完全與成本不匹

配，首先，基路徑法完成的只是代碼覆蓋，這是最低級別的覆蓋，其

次，整個設計過程都是依據(jù)已經(jīng)存在的代碼來進行的，沒有考慮程序

的設計功能，是典型的“跟著代碼走”，不足是顯而易見的。綜上所述,

基路徑法沒有實際應用價值。

8

4.2用于MC/DC的真值表法

設計用于MC/DC的用例，可以先將條件值的所有可能組合列出

表格，然后從中選擇用例，稱為真值表法。例如判定A||(B&&C),

條件組合如下表：

ABC判定結果

組合1TTTT

組合2TTFT

組合3TFTT

組合4TFFT

組合5FTTT

組合6FTFF

組合7FFTF

組合8FFFF

為了使A獨立影響判定結果，選擇B和C相同，判定結果相反，且

A相反的組合：組合2和6；

為了使B獨立影響判定結果,選擇A和C相同，判定結果相反，且

B相反的組合：組合5和7；

為了使C獨立影響判定結果,選擇A和B相同，判定結果相反，且

C相反的組合：組合5和6。

9

因此，組合2、5、6、7符合MC/DC要求。符合MC/DC要求的用

例集不是惟一的。

為了提高效率，可以使用工具來生成真值表和找出符合要求的組合，

有些商業(yè)工具具有這種功能。自行開發(fā)難度也不大，下面提出開發(fā)

MC/DC用例設計小工具的思路，有興趣的讀者可以嘗試一下：

1)用一個簡單的詞法和語法分析器解析判定表達式，計算條件數(shù)量;

2)生成真值表；

3)用一個邏輯表達式計算器，針對每個條件C,掃描真值表，找出

符合以下要求的組合：除條件C外，其他條件取值相同；將條件C

的真值和假值分別代入判定表達式，判定的計算結果相反。

4)針對找出的組合，設計兩個用例，條件C分別取真和假。

需要注意的是，判定中可能存在完全相同的條件，例如：

(A==011B==1)&&C==211(A==0&&D==3)

針對A==0設計MC/DC用例時，前一個A==0取反,后一個A==0

也會跟著取反，如果后一個A==0視為其他條件，則不能實現(xiàn)

MC/DC覆蓋，因此，計算判定值時，兩個A==0應視為同一個條

件。

10

4.3邊界值法

邊界值法假定錯誤最有可能出現(xiàn)在區(qū)間之間的邊界，一般對邊界

值本身，及邊界值的兩邊都需設計測試用例。

如下函數(shù)：

〃參數(shù)age表示年齡

intfunc(intage)

{

intret=0;

〃…dosomething

returnret；

}

參數(shù)age表示一個人的年齡，假設有效的取值范圍是0-200,那么，

用邊界值法可以得出以下用例(省略輸出)：

用例1：age=-1；

用例2：age=0；

11

用例3：age=1；

用例4：age=199；

用例5：age=200；

用例6：age=201；

通常，程序?qū)斎脒€會分段處理，例如，年齡在10以下，為兒童，

需要特別照顧；年齡在60歲以上，為退休老人，不能安排工作，那

么，10和60是內(nèi)部邊界，也要設計測試用例：

用例7：age=9；

用例8：age=10；

用例9：age=11；

用例10：age=59；

用例11：age=60；

用例12：age=61；

邊界值法需要了解數(shù)據(jù)所代表的實際意義，此外對于枚舉類型等非標

量數(shù)據(jù)不適用。邊界值法對于復雜的軟件項目來說，適用范圍有限。

4.4等價類法

12

先從代碼編寫的思路說起。程序員編寫一個函數(shù)的代碼，會如何

做呢？

首先，了解代碼功能。程序的功能是什么？無非就是：有哪些輸

入？執(zhí)行什么操作或計算？產(chǎn)生什么輸出？

然后，將功能細化，形成一個或多個功能點。一個功能點就是一

類輸入及其處理。什么叫"一類〃輸入？程序可能有無數(shù)輸入，但代碼

并不需要用無數(shù)個判定來對每個輸入分別做處理，只需將輸入分類，

需要做相同處理的輸入歸于一類，這就是"等價類〃。從編程角度來說,

"等價類''是指計算或操作過程的"等價"，一個等價類就是處理過程完

全相同的輸入的集合。程序中通常用判定來識別分類，一個判定就是

一次分類，嵌套的判定則會造成分類數(shù)量的翻番。

所以，函數(shù)代碼編寫的核心思維就是等價類劃分和處理。一個函

數(shù)要完全正確，關鍵是等價類的劃分要正確完整，且每個等價類的處

理正確。

舉個例子，現(xiàn)在要編寫一個函數(shù)，將字符串左邊的空格刪除。函

數(shù)原形如下：

char*strtrml(char*str);

功能：

將str左邊空格刪除，并返回str本身。

13

功能點:

1.左邊有空格：刪除；（正常輸入）

2.左邊無空格：不作處理；（正常輸入）

3.全部是空格：全部刪除；（正常輸入）

4.空串：不作處理；（邊界輸入）

5.空指針：直接返回。（非法輸入）

不一定需要針對每個功能點分別寫代碼，因為程序中的if、for、

while等語句本身具有“如果不符合條件就跳過〃的含義，所以很多功

能點是可以共用代碼的，例如，前4個功能點只需要相同的代碼，不

過，編程時對功能點的考慮還是要全面。

既然函數(shù)沒有錯誤的關鍵是等價類劃分正確完整且處理正確，那

么測試時，只要把輸入的等價類都列出來，并設定正確的預期輸出，

進行測試就行了。

這就是通常說的“等價類''法，從測試角度來說的“等價”，是指測

試效果上的等價，即同類中一個數(shù)據(jù)測試通過，可以肯定其他數(shù)據(jù)也

會測試通過。

14

用例設計的首要工作是設定輸入。輸入有哪些呢？要從正常輸

入、邊界輸入、非法輸入三方面考慮，每方面進一步劃分形成等價類,

即要考慮：有哪些正常輸入？有哪些邊界輸入？有哪些非法輸入？

多個輸入時，例如有多個參數(shù)，首先把各個參數(shù)的等價類列出來，然

后要考慮參數(shù)之間是否存在特殊的組合關系。例如下面的函數(shù)：

//計算某年某月某日是星期幾,參數(shù)分別表示年月日

intDate（intyear,intmonth,intday）;

用例如下表（假設year的有效范圍是1-9999）：

輸入正常值邊界值非法值組合

Year2000（閏年）10閏年和非閏年要保證都

和2月組合；

2009（非閏年）999910000

2月要和28、29、30

month2（短月）10

日組合；

3（大月）

1213小月要和30、31日組

4（小月）

合；

Day10（普通）10

大月要和31、32日組合

28（非閏年二

3132

月）

29（閏年二月）

15

30（小月）

用例的輸出是比較容易被輕視的工作，但是，沒有充分且正確的

預期輸出，用例基本上沒有意義，就像醫(yī)生要求病人做一大堆檢查，

卻不看檢查結果一樣。預期輸出要根據(jù)程序的設計功能確定正確的

值。一個用例的預期輸出可能有多個。

等價類法是與程序的基本特性”對數(shù)據(jù)分類處理''相匹配的方法。

對于一個函數(shù)來說，如果對數(shù)據(jù)的分類正確且完整，每一個分類處理

正確，那么，程序就沒有問題。同樣，測試時，只要依據(jù)設計功能，

找出所有等價類，那么，用例就是完整的。所以，用例的完整性，本

質(zhì)上是指等價類是否劃分正確且完整，每一類的正確輸出是否均依據(jù)

設計功能正確設定。

使用了等價類法后，是否需要使用其他方法呢？

等價類法從“有哪些正常輸入？有哪些邊界輸入？有哪些非法輸

入？〃三個方面來考慮等價類，因此，邊界值法是等價類法的一部分。

常見的用例設計方法中還有正交法和錯誤推測法。正交法考慮數(shù)

據(jù)的組合，實際上，如果程序?qū)斎霐?shù)據(jù)的組合需要判斷處理，也是

一種等價類劃分，但正交法會產(chǎn)生大量的多余組合，且可能缺少必要

的組合，因此不推薦采用正交法，應該根據(jù)數(shù)據(jù)的實際意義自行組合。

16

單獨從錯誤推測角度去設計用例未免太不可靠，但錯誤推測法可以作

為檢查等價類是否完整的一種思路，即用等價類法設計用例后，可以

考慮哪些輸入比較容易產(chǎn)生錯誤，以檢查是否遺漏，這只是一種檢查

思路，也包含在等價類法之中?？傊?，用例設計只需使用等價類法，

但可以從多種角度檢查等價類的完整性。

4.5循環(huán)測試法

在程序中多循環(huán)判斷是，我們一樣需要重點關注，根據(jù)循環(huán)的重

量級進行。

例如一個簡單循環(huán)判斷：

如下圖4-5,有如下幾個分支需要覆蓋：

1、跳過整個循環(huán)：不進入循環(huán)流程

2、僅有一次進入循環(huán)：需要進行數(shù)據(jù)構造，能夠讓循環(huán)運行一

次

3、n次進入循環(huán)（n為循環(huán)的最大次數(shù)）

不難看出，通過上述分支的覆蓋，就可以驗證循環(huán)的功能以及循

環(huán)設置的邊界是否生效，不會出現(xiàn)循環(huán)沒有控制好，導致實際使用的

時候會多進行一次或者少進行一次循環(huán)的情況。