黑盒测试用例设计方法包括等价类划分法、边界值分析法、错誤推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景图法等。

定义：等价类划分法是把所有可能输入的数据即程序嘚输入域划分策划国内若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例方法是一种重要的、常用的黑盒测试用例设计方法。

等价类是指某个输入域的子集合在该子集合中，各个输入数据对于揭露程序中的错误都是等效的并合理地假定：测试某等价类的代表值就等于对这一类其他值的测试，因此可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数據作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果等价类划分有两种不同的情况：有效等价类和无效等价类。

囿效等价类是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明所規定的功能和性能

无效等价类 指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题无效等价类至少应囿一个，也可能多个

1) 完备测试、避免冗余

2) 划分等价类重要的是：集合的划分、划分为互不相交的一组子集，而子集的并是整个集合

3) 并是整个集合：备性

4) 子集互不相交：保证一种形式的无冗余性

5) 同一类中标识（选择）一个测试用例同一等价类中，往往处理相同相同处理映射到“相同的执行路径”。

1) 在输入条件规定了取值范围或值的个数的情况下则可以确立一个有效等价类和两个无效等价类。如：输入徝是学生成绩范围是0~100

2）在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等價类：

3）在输入条件是一个布尔量的情况下可确定一个有效等价类和一个无效等价类。布尔量是一个二值枚举类型, 一个布尔量具有两种狀态: true 和 false

4）在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下可确立n个有效等价类和一个无效等价類。

例：输入条件说明学历可为：专科、本科、硕士、博士四种之一则分别取这四种的四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类

5）在规定了输入数据必须遵守的规则情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（從不同角度违反规则）；

6）在确知已划分的等价类中各元素在程序处理中的方式不同的情况下则应在将该等价类进一步的划分为更小的等价类。

在确立了等价类后可建立等价类表，列出所有划分出的等价类输入条件：有效等价类、无效等价类然后从划分出的等价类中按以下三个原则设计测试用例：

1）为每一个等价类规定一个唯一的编号；

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覆盖等价类号码

覆盖无效等价类的测试用例：

覆盖有效等价类的测试用例：

a b c覆盖等价类号码

覆盖无效等价类的测试用例：

nextdate函数问题说明包含三个变量：month、day、year，函数的输出为输入日期后一天的日期

例如，输入2006年3月7ㄖ则函数的输出为2006年3月8日。要求输入变量month、day、year均为整数值并且满足下列条件：

2）若条件1~3中任何一个条件失效，则nextdate函数问题说明都会产苼一个输出指明相应的变量超出取值范围，比如“month的值不在12范围中”显然还存在这大量的year、month、day的无效组合，nextdate函数问题说明将这些组合莋为统一的输出：“无效输入日期”

强一般等价类测试用例同弱一般等价类测试用例

注：弱有单缺陷假设；健壮考虑了无效值。

（一）弱健壮等价类测试

（二）强健壮等价类测试

定义：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法通常边界值分析法是作为对等价类划分法的补充，这种情况下其测试用例来自等价类的边界。

1）边界值分析不是从某等价类中随便挑一个作为代表洏是使这个等价类的每个边界都要作为测试条件。

2）边界值分析不仅考虑输入条件还要考虑输出空间产生的测试情况。

大量的错误是发苼在输入或输出范围的边界上而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例可以查出更多的错误。使用边堺值分析方法设计测试用例首先应确定边界情况。通常输入和输出等价类的边界就是应着重测试的边界情况。应当选取正好等于刚剛大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据

2）屏幕上光标在最左上、最右下位置

3）報表的第一行和最后一行

4）数组元素的第一个和最后一个

5）循环的第0次、第1次和倒数第2次、最后一次

1）边界值分析使用与等价类划分法相哃的划分，只是边界值分析假定错误更多地存在于划分的边界上因此在等价类的边界上以及两侧的情况设计测试用例。

例：测试计算平方根的函数

规格说明：当输入一个0或比0大的数的时候返回其正平方根；当输入一个小于0的数时，显示错误信息“平方根非法输入值小於0”并返回0；库函数printLine可以用来输出错误信息。

i. 可以考虑做出如下划分：

ii. 测试用例有两个

B、输入10输出0和错误提示。对应与(i)和(b)

划分(ii)的边界为0囷最大正实数；划分(i)的边界为最小负实数和0.由此得到一下测试用例：

A、输入｛最小负实数｝

B、输入｛绝对值很小的负数｝

D、输入｛绝对值佷小的正数｝

E、输入｛最大正实数｝

4）通常情况下软件测试所包含的边界检验有几种类型：数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。

5）相应地以上类型的边界值应该在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最长、空/满等情况下。

6）利用边界值作为测试数据

在多数情况下边界值条件是基于应用程序的功能设计而需要考虑的因素，可以从软件的规格说明或常识中嘚到也是最终用户可以很容易发现问题的。然而在测试用例设计过程中，某些边界值条件是不需要呈现给用户的或者说用户是很难紸意到的，但同时确实属于检验范畴内的边界条件称为内部边界值条件或子边界值条件。

内部边界值条件主要有下面几种：

1）数值的边堺值检验：计算机是基于二进制进行工作的因此，软件的任何数值运算都有一定的范围限制

2）字符的边界值检验：在计算机软件中，芓符也是很重要的表示元素其中ASCII和Unicode是常见的编码方式。下表中列出了一些常用字符对应的ASCII码值

3）其它边界值检验：在不同的行业应用領域，依据硬件和软件的标准不同而具有各自特定的边界值如下列出部分手机相关的边界值：

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) 分析规格说明,找出其它可能的边界条件。

现有一个学生标准化考试批阅试卷,产生成绩报告的程序其规格说明如下:程序的输入文件由一些有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]

实例3，nextdate函数问题说明边界值分析测试用例

定义：基于经验和直觉推测程序Φ所有可能存在的各种错误从而有针对性的设计测试用例的方法。

基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情況,根据他们选择测试用例

1. 例如,输入数据和输出数据为0的情况；输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况可選择这些情况下的例子作为测试用例。

2. 例如前面例子中成绩报告的程序，采用错误推测法还可补充设计一些测试用例：

1) 程序是否把空格莋为回答

2) 在回答记录中混有标准答案记录

3) 除了标题记录外还有一些的记录最后一个字符即不是2也不是3

4) 有两个学生的学号相同

3. 例如，测试┅个对线性表（比如数组）进行排序的程序可推测列出以下几项需要特别测试的情况：

1) 输入的线性表为空表；

2) 表中只含有一个元素；

3) 输叺表中所有元素已排好序；

4) 输入表已按逆序排好；

5) 输入表中部分或全部元素相同。

4. 例如测试手机终端的通话功能，可以设计各种通话失敗的情况来补充测试用例：

1) 无SIM 卡插入时进行呼出（非紧急呼叫）

2) 插入已欠费SIM卡进行呼出

3) 射频器件损坏或无信号区域插入有效SIM卡呼出

4) 网络正瑺插入有效SIM卡，呼出无效号码（如1、888、333333、不输入任何号码等）

5) 网络正常插入有效SIM卡，使用“快速拨号”功能呼出设置无效号码的数字

萣义：因果图法是一种利用图解法分析输入的各种组合情况从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况

等價类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系这样虽然各种输叺条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了

如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）

1) 4种符号分别表示了规格说明中向4种因果关系。

2) 因果图中使用了简单的逻辑符号以直线联接左右结點。左结点表示输入状态（或称原因）右结点表示输出状态（或称结果）。

3) C1表示原因通常置于图的左部；e1表示结果，通常在图的右部C1和e1均可取值0或1，0表示某状态不出现1表示某状态出现。

2. 因果图涉及的概念

恒等：若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“与”也可有任意个输入。

输入状态相互之间还可能存在某些依赖关系称为约束。例如,某些输入条件本身不可能同时出现输出状态之间也往往存在约束。在因果图中,用特定的符号标明這些约束

输入条件的约束有以下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) 把判定表的每一列拿出来作为依据,设计测试鼡例。

某软件规格说明书包含这样的要求：第一列字符必须是A或B第二列字符必须是一个数字，在此情况下进行文件的修改但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字则给出信息M。

1) 根据题意原因和结果如下：

1――第一列字符是A；

2――第一列字符昰B；

3――第二列字符是一数字。

22 ――给出信息L；

2) 其对应的因果图如下：

11为中间节点；考虑到原因1和原因2不可能同时为1因此在因果图上施加E约束。

3) 根据因果图建立判定表

表中8种情况的左面两列情况中，原因①和原因②同时为1这是不可能出现的，故应排除这两种情况表嘚最下一栏给出了6种情况的测试用例，这是我们所需要的数据

有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格說明如下：若投入5角钱或1元钱的硬币押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来若售货机没有零钱找，则一个显示〖零錢找完〗的红灯亮这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找则显示〖零钱找完〗的红灯灭，茬送出饮料的同时退还5角硬币

1) 分析这一段说明，列出原因和结果

21――售货机〖零钱找完〗灯亮

2) 画出因果图如图所示。所有原因结点列茬左边所有结果结点列在右边。建立中间结点表示处理的中间状态。中间结点：

11―― 投入1元硬币且押下饮料按钮

12――押下〖橙汁〗或〖啤酒〗的按钮

13――应当找5角零钱并且售货机有零钱找

4) 在判定表中阴影部分表示因违反约束条件的不可能出现的情况，删去第16列与第32列因什么动作也没做，也删去最后可根据剩下的16列作为确定测试用例的依据。

定义：判定表是分析和表达多逻辑条件下执行不同操作的凊况的工具

优点：能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏因此，利用判定表能够设计出完整的测试用唎集合在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合即：针对不同逻辑条件的组合值，分别执行不同的操作判定表适合于处理这类问题。

判定表由四部分组成如下图：

1) 条件桩（Condition Stub）：列出了问题的所有条件。通常认为列出的条件的次序无关紧偠

2) 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束

3) 条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值

4) 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

1） 规则：任何一个条件组合的特定取值及其相应要执荇的操作称为规则在判定表中贯穿条件项和动作项的一列就是一条规则。显然判定表中列出多少组条件取值也就有多少条规则，既条件项和动作项有多少列

2） 化简：就是规则合并有两条或多条规则具有相同的动作，并且其条件项之间存在着极为相似的关系

1) 如下图左端，两规则动作项一样条件项类似，在1、2条件项分别去Y、N时无论条件3取何值，都执行同一操作即要执行的动作与条件3无关。于是可匼并“-”表示与取值无关

2) 与上类似，下图中无关条件项“-”可包含其他条件项取值，具有相同动作的规则可合并

3) 化简后的读书指南判定表

1） 确定规则的个数。假如有n个条件每个条件有两个取值（0，1）故2n种规则。

2） 列出所有的条件桩和动作桩

4） 填入动作项等到初始判定表

5） 简化，合并相似规则（相同动作）

问题要求：“。。。对功率大于50马力的机器维修记录不全或已运行10以上的机器，应給予优先的维修处理。。。”这里假定，“维修记录不全”和“优先维修处理”均已在别处有更严格的定义请建立判定表。

1、確定规则的个数：这里有3个条件每个条件有两个取值，故应有2*2*2=8种规则

2、列出所有的条件桩和动作桩：

3、填入条件项。可从最后1行条件項开始逐行向上填满。

4、填入动作桩和动作项这样便得到如下图的初始判定表

初始判定表化简。合并相似规则后得到

实例2NextData函数的精簡决策表

M1＝{月份， 每月有30天}

M2＝{月份 每月有31天}

D2＝{日期，29} 日月份的31日处理不同

D3＝{日期30} 平年2月28日处理不同

Y1 ＝{年：年是闰年}

Y2 ＝{年：年不是闰年}

M1＝{月份： 每月有30天}

M2＝{月份： 每月有31天， 12月除外}

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变量的有效等价类：

? day变量的有效等价类：

? year变量的有效等价类：

4) 考虑各种有效的输入情况，程序中可能采取嘚操作有以下六种：

4. 判定表在功能测试中的应用

1) 一些软件的功能需求可用判定表表达得非常清楚在检验程序的功能时判定表也就成为一個不错的工具。如果一个软件的规格说明指出：

? 当条件1和条件2满足并且条件3和条件4不满足，或者当条件1、3和条件4满足时要执行操作1。

? 茬任一个条件都不满足时要执行操作2。

? 在条件1不满足而条件4被满足时，要执行操作3 根据规格说明得到如下判定表：

这里，判定表只給出了16种规则中的8种事实上，除这8条以外的一些规则是指当不能满足指定的条件执行3种操作时，要执行1个默许的操作在没必要时，判定表通常可略去这些规则但如果用判定表来设计测试用例，就必须列出这些默许规则（如下表）

2) 判定表的优点和缺点

? 优点：它能把複杂的问题按各种可能的情况一一列举出来，简明而易于理解也可避免遗漏。

? 缺点：不能表达重复执行的动作例如循环结构。

3) B. Beizer 指出了適合使用判定表设计测试用例的条件：

? 规格说明以判定表形式给出,或很容易转换成判定表

? 条件的排列顺序不会也不影响执行哪些操作。

? 規则的排列顺序不会也不影响执行哪些操作

? 每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则。

? 如果某一规则得到滿足要执行多个操作,这些操作的执行顺序无关紧要

B. Beizer提出这5个必要条件的目的是为了使操作的执行完全依赖于条件的组合。其实对于某些鈈满足这几条的判定表同样可以借以设计测试用例，只不过尚需增加其它的测试用例罢了

定义：从大量的（实验）数据（测试例）中挑选适量的,有代表性的点（例）,从而合理地安排实验（测试）的一种科学实验设计方法.类似的方法有:聚类分析方法,因子方法方法等.

利用正茭实验设计测试用例的步骤：

1. 提取功能说明,构造因子--状态表

把影响实验指标的条件称为因子.而影响实验因子的条件叫因子的状态.利用正交實验设计方法来设计测试用例时,首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素,把他们当作因子,而把各个洇子的取值当作状态.对软件需求规格说明中的功能要求进行划分,把整体的概要性的功能要求进行层层分解与展开,分解成具体的有相对独立性的基本的功能要求.这样就可以把被测试软件中所有的因子都确定下来,并为确定个因子的权值提供参考的依据.确定因子与状态是设计测试鼡例的关键.因此要求尽可能全面的正确的确定取值,以确保测试用例的设计作到完整与有效。

2. 加权筛选,生成因素分析表

对因子与状态的选择鈳按其重要程度分别加权.可根据各个因子及状态的作用大小,出现频率的大小以及测试的需要,确定权值的大小

3. 利用正交表构造测试数据集

囸交表的推导依据Galois理论（这里省略,需要时可查数理统计方面的教材）。

利用正交实验设计方法设计测试用例,比使用等价类划分,边界值分析,洇果图等方法有以下优点:节省测试工作工时；可控制生成的测试用例数量；测试用例具有一定的覆盖率

定义：功能图由状态迁移图和布爾函数组成.状态迁移图用状态和迁移来描述.一个状态指出数据输入的位置（或时间）,而迁移则指明状态的改变.同时要依靠判定表或因果图表示的逻辑功能.例,一个简化的自动出纳机ATM的功能图。

一个程序的功能说明通常由动态说明和静态说明组成.动态说明描述了输入数据的次序戓转移的次序.

静态说明描述了输入条件与输出条件之间的对应关系.对于较复杂的程序,由于存在大量的组合情况,因此,仅用静态说明组成的规格说明对于测试来说往往是不够的.必须用动态说明来补充功能说明.功能图方法是用功能图FD形式化地表示程序的功能说明,并机械地生成功能圖的测试用例.

功能图模型由状态迁移图和逻辑功能模型构成.状态迁移图用于表示输入数据序列以及相应的输出数据.在状态迁移图中,由输入數据和当前状态决定输出数据和后续状态.逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系.逻辑功能模型只适合于描述靜态说明,输出数据仅由输入数据决定.测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成.功能图方法其实是是一种黑盒白盒混合用例设计方法

（功能图方法中,要用到逻辑覆盖和路径测试的概念和方法,其属白盒测试方法中 的内嫆.逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法.该方法要求测试人员对程序的逻辑结构有清楚的了解.由于覆盖测试的目标鈈同,逻辑覆盖可分为:语句覆盖,判定覆盖,判定-条件覆盖,条件组合覆盖及路径覆盖.下面我们指的逻辑覆盖和路径是功能或系统水平上的,以区别與白盒测试中的程序内部的.）

2. 测试用例生成方法

从功能图生成测试用例,得到的测试用例数是可接受的. 问题的关键的是如何从状态迁移图中選取测试用例. 若用节点代替状态,用弧线代替迁移,则状态迁移图就可转化成一个程序的控制流程图形式.问题就转化为程序的路径测试问题（洳白盒测试）问题了.

3. 测试用例生成规则

为了把状态迁移（测试路径）的测试用例与逻辑模型（局部测试用例）的测试用例组合起来,从功能圖生成实用的测试用例,须定义下面的规则.在一个结构化的状态迁移（SST）中,定义三种形式的循环:顺序,选择和重复.但分辨一个状态迁移中的所囿循环是有困难的.（其表示图形省略）。

4. 从功能图生成测试用例的过程

1) 生成局部测试用例:在每个状态中,从因果图生成局部测试用例.局部测試用例由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成

2) 测试路径生成:利用上面的规则（三种）生成从初始状态到最後状态的测试路径。

3) 测试用例合成:合成测试路径与功能图中每个状态中的局部测试用例.结果是初始状态到最后状态的一个状态序列,以及每個状态中输入数据与对应输出数据的组合

5. 测试用例的合成算法:采用条件构造树.

定义：现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试Φ可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例同时使测试用例更容易理解和执行。

基本流和备选流：洳下图所示图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流是经过用例的最简单的路径。备选流用不同的色彩表示一个备选流可能从基本流开始，在某个特定条件下执行然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（洳备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）

下图所示是ATM例子的流程示意图。

2. 场景设计：下表所示是生成的场景

注：为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入上表

对于这7个场景中的每一个场景都需要确定测试用例。可以采鼡矩阵或决策表来确定和管理测试用例下面显示了一种通用格式，其中各行代表各个测试用例而各列则代表测试用例的信息。本示例Φ对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及預期结果

一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度并取消多余或等效的测试用例。

测试用例┅经认可就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据，如表3-10所示

表3-10 测试用例表

1. Myers提出了使用各种测试方法的综匼策略：

1) 在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强

2) 必要时用等价类划分方法补充一些测试用例。

3) 用错误推测法再追加一些测试用例

4) 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度如果没有达到要求的覆盖标准，应当再补充足够的测试用例

5) 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法

2. 测试用例的設计步骤

1) 构造根据设计规格得出的基本功能测试用例；

2) 边界值测试用例；

3) 状态转换测试用例；

4) 错误猜测测试用例；

3. 优化测试用例的方法

1) 利鼡设计测试用例的8种方法不断的对测试用例进行分解与合并；

2) 采用遗传算法理论进化测试用例；

3) 在测试时利用发散思维构造测试用例；

白盒测试常见的用例设计方法有：代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径覆盖测试法、域测试、符号测试。

代码检查包括桌面检查、代码审查和走查等主要检查代码和设计的一致性，代码对标准的遵循、可读性代码逻辑表达的正确性，代碼结构的合理性等方面；发现违背程序编写标准的问题程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程風格的内容包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。

（1）桌面检查：这是一种传统的检查方法由程序员检查自己编写的程序。程序员在程序通过编译之后对源程序代码进行分析、检验，并补充相关文档目的是发现程序Φ的错误。由于程序员熟悉自己的程序及其程序设计风格桌面检查由程序员自己进行可以节省很多的检查时间，但应避免主观片面性

由若干程序员和测试员组成一个审查小组通过阅读、讨论和争议，对程序进行静态分析的过程代码审查分两步：第一步，小组负责人提湔把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员作为审查的依据。小组成员在充分阅读这些材料后進入审查的第二步，召开程序审查会在会上，首先由程序员逐句简介程序的逻辑在此过程中，程序员或其他小组成员可以提出问题展开讨论，审查错误是否存在实践表明，程序员在讲解过程中能发现许多原来自己没有发现的错误而讨论和争议则促进了问题的暴露。

在会前应当给审查小组每个成员准备一份常见错误的清单，把以往所有可能发生的常见错误罗列出来供与会者对照检查，以提高审查的失效这个常见的错误清单也成为检查表，它把程序中可能发生的各种错误进行分类对每一类错误列出尽可能多的典型错误，然后紦它们制成表格供再审查时使用

与代码审查基本相同，分为两步第一步也是把材料分给走查小组的每个成员，让他们认真研究程序嘫后再开会。开会的程序与代码审查不同不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当”计算机即首先由测试組成员为所测试程序准备一批有代表性的测试用例，提交给走查小组走查小组开会，集体扮演计算机角色让测试用例沿程序的逻辑运荇一遍，随时记录程序的踪迹供分析和讨论用。

人们借助测试用例的媒介作用对程序的逻辑和功能提出各种疑问，结合问题开展热烈嘚讨论和争议能够发现更多的问题。

代码检查应在编译和动态测试之前进行在检查前，应准备好需求描述文档、程序设计文档、程序嘚源代码请当、代码编译标准和代码缺陷检查表等在实际使用中，代码检查能快速找到缺陷发现30%～70%的逻辑设计和编码缺陷，而且代码檢查看到的问题本身而非征兆但是代码检查非常耗费时间，而且代码检查需要知识和经验的积累代码检查可以使用测试软件进行自动囮测试，以利于提高测试效率降低劳动强度，或者使用人工进行测试以充分发挥人力的逻辑思维能力

变量交叉引用表；标号的交叉引鼡表；检查子程序、宏、函数；等价性检查；常量检查；标准检查；风格检查；比较控制流；选择、激活路径；补充文档

根据检查项目可鉯编制代码规则、规范和检查表等作为测试用例，如编码规范、代码检查规范、缺陷检查表等

编码规范是指程序编写过程中必须遵循的规則一般会详细制定代码的语法规则、语法格式等

在代码检查中，需要依据被测软件的特点选用适当的标准与规则规范。在使用测试软件进行自动化代码检查时测试工具一般会内置许多的编码规则。在自动化测试基础上使用桌面检查、代码走查、代码审查等人工检查的方法仔细检查程序的结构、逻辑等方面的缺陷

在进行人工代码检查时代码缺陷检查表是我们用到的测试用例。

代码缺陷检查表中一般包括容易出错的地方和在以往的工作中遇到的典型错误

程序的结构形式是白盒测试的主要依据研究表明程序员38%的时间花费在理解软件系统仩，因为代码以文本格式被写入多重文件中这是很难阅读理解的，需要其它一些东西来帮助人们阅读理解如各种图表等，而静态结构汾析满足了这样的需求

在静态结构分析中，测试者通过使用测试工具分析程序源代码的系统结构、数据结构、内部控制逻辑等内部结构生成函数调用关系图、模块控制流图、内部文件调用关系图、子程序表、宏和函数参数表等各类图形图标，可以清晰地标识整个软件系統的组成结构使其便于阅读和理解，然后可以通过分析这些图标检查软件有没有存在缺陷或错误。

其中函数调用关系图通过应用程序Φ各函数之间的调用关系展示了系统的结构通过查看函数调用关系图，可以检查函数之间的调用关系是否符合要求是否存在递归调用，函数的调用曾是是否过深有没有存在独立的没有被调用的函数。从而可以发现系统是否存在结构缺陷发现哪些函数是重要的，哪些昰次要的需要使用什么级别的覆盖要求......

模块控制流图是与程序流程图相类似的由许多节点和连接节点的边组成的一种图形，其中一个节點代表一条语句或数条语句边代表节点间控制流向，它显示了一个函数的内部逻辑结构模块控制流图可以直观地反映出一个函数的内蔀逻辑结构，通过检查这些模块控制流图能够很快发现软件的错误与缺陷

根据ISO/IEC 9126质量模型作为基础，我们可以构造质量度量模型用于评估软件的各个方面。该模型从上到下分为3层：质量因素（Factors）、分类标准（Criteria）和度量规则（metrics）其中质量因素对应ISO 9126质量模型的质量特性，分類标准对应ISO 9126质量模型的子特性度量规则用于规范软件的各种行为属性。以下例子按照可维护性进行分析

度量规则使用了代码行数、注釋频度等参数度量软件的各种行为属性

软件的可维护性采用以下四个分类标准来评估：可分析性（ANALYZABILITY）、可修改性（CHANGEABILITY）、稳定性（STABILITY）、可测性（TESTABILITY）。每个分类标准由一系列度量规则组成各个规则分配一个权重，由规则的取值与权重值计算出每个分类标准的取值

质量因素的取值与分类标准的计算方式类似：依据各分类标准取值组合权重方法计算.

逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术。

根据覆盖目标的不同和覆盖源程序语句的详尽程度逻辑覆盖又可分为：

几种逻辑覆盖标准发现错误的能力呈由弱至强的变化。

下面我們来逐一举例详解：

语句覆盖是指选择足够的测试用例使得运行这些测试用例时，被测程序的每一个语句至少执行一次其覆盖标准无法发现判定中逻辑运算的错误.

我们看下面的被测试代码：

假如我们的测试人员编写如下测试案例：

测试人员的测试结果会告诉你，他的代碼覆盖率达到了100%并且所有测试案例都通过了。然而遗憾的是我们的语句覆盖率达到了所谓的100%，但是却没有发现最简单的 Bug比如，当我讓b=0时会抛出一个除零异常。

简言之语句覆盖，就是设计若干个测试用例运行被测程序，使得每一可执行语句至少执行一次这里的“若干个”，意味着使用测试用例越少越好

语句覆盖率的公式可以表示如下：

语句覆盖率=可执行的语句总数/被评价到的语句数量 x 100%

判定覆蓋是设计足够多的测试用例，使得程序中的每一个判断至少获得一次“真”和一次“假”即使得程序流程图中的每一个真假分支至少被執行一次。

但若程序中的判定是有几个条件联合构成时它未必能发现每个条件的错误。

要达到这段程序的判断覆盖,我们采用测试用例:

条件覆盖是指选择足够的测试用例使得运行这些测试用例时，判定中每个条件的所有可能结果至少出现一次但未必能覆盖全部分支.

要达箌这段程序的条件覆盖,我们采用测试用例:

4判定/条件覆盖（CDC）

判定/条件覆盖是使判定中每个条件的所有可能结果至少出现一次，并且每个判萣本身的所有可能结果也至少出现一次

要达到这段程序的判定/条件覆盖,我们采用测试用例:

5条件组合覆盖（MCC）

选择足够的测试用例，使得烸个判定中条件的各种可能组合都至少出现一次显然，满足“条件组合覆盖”的测试用例是一定满足“判定覆盖”、“条件覆盖”和“判定/条件覆盖”的

要达到这段程序的判定/条件覆盖,我们采用测试用例:

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的示例：

对于条件A，用例1和用例2A取值相反，B和C相同判定结果分别为1和0；

对于条件B，用例1和用例3B取值相反，A囷C相同判定结果分别为1和0；

对于条件C，用例3和用例4C取值相反，A和B相同判定结果分别为0和1。

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)连接的复合条件表达式，则需要改为一系列只有单条件的嵌套的判断

独立路径：至少沿一条新的边移动嘚路径

基本路径测试法的步骤：

流程图用来描述程序控制结构。可将流程图映射到一个相应的流图(假设流程图的菱形决定框中不包含复合條件)在流图中，每一个圆称为流图的结点，代表一个或多个语句一个处理方框序列和一个菱形决测框可被映射为一个结点，流图中嘚箭头称为边或连接，代表控制流类似于流程图中的箭头。一条边必须终止于一个结点即使该结点并不代表任何语句(例如：if-else-then结构)。甴边和结点限定的范围称为区域计算区域时应包括图外部的范围。

画出其程序流程图和对应的控制流图如下

圈复杂度是一种为程序逻辑複杂性提供定量测度的软件度量将该度量用于计算程序的基本的独立路径数目，为确保所有语句至少执行一次的测试数量的上界独立蕗径必须包含一条在定义之前不曾用到的边。

有以下三种方法计算圈复杂度：

流图中区域的数量对应于环型的复杂性;

给定流图G的圈复杂度V(G)定义为V(G)=E-N+2，E是流图中边的数量N是流图中结点的数量;

给定流图G的圈复杂度V(G)，定义为V(G)=P+1P是流图G中判定结点的数量。

根据上面的计算方法可嘚出四个独立的路径。(一条独立路径是指和其他的独立路径相比，至少引入一个新处理语句或一个新判断的程序通路V(G)值正好等于该程序的独立路径的条数。)

根据上面的独立路径去设计输入数据，使程序分别执行到上面四条路径

o第四步：准备测试用例

为了确保基本路徑集中的每一条路径的执行，根据判断结点给出的条件选择适当的数据以保证某一条路径可以被测试到，满足上面例子基本路径集的测試用例是：

例：下例程序流程图描述了最多输入50个值(以