第5章 黑盒测试案例设计技术
5．1 测试用例设计方法
一、测试用例概述
1．简介
测试用例设计是将软件测试的行为活动，作一个科学化的组织归纳，其目的是为了能将软件测试的行为转换为可管理的模式。
测试用例是将测试行为具体量化的方法之一，即测试用例就是设计一个情况，软件程序在该情况下，必须能够正常运行并且达到程序所设计的执行结果。如果程序在这种情况下不能正常运行，且这种问题会重复发生，那就表示软件程序人员已经测出软件有缺陷，这时候就必须将该问题标示出来，并且输入到问题跟踪系统内，以便通知软件开发人员。软件开发人员接获通知后，将该问题在下个测试版本内修改完成，软件测试工程师取得新的测试版本后，必须利用同一用例来测试该问题，确保该问题已修改完成。
2．优势
由于不可能进行穷举测试，为节省时间和资源、提高测试效率，须从数量极大的可用测试数据中挑选出具有代表性或特殊性的测试数据来进行测试。使用测试用例的优势如下：
（1）在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率；
（2）测试用例的使用令软件测试的实施重点突出、目的明确；
（3）在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度，缩短项目周期；
（4）功能模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。
3．黑盒测试用例设计方法
包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。这些方法比较实用，但采用哪种方法，在使用时要针对开发项目的特点对方法加以适当的选择。
二、等价类划分法
1．概述
（1）简介
一种典型的黑盒测试方法，用该方法设计测试用例用这一方法设计测试用例完全不考虑程序的内部结构，只需根据需求规格说明书。须仔细分析和推敲说明书的各项需求，特别是功能需求。把说明中对输入的要求和输出的要求区别开来并加以分解。由于穷举测试工作量太大，需在大量的可能数据中选取其中的一部分作为测试用例。
（2）原理
等价类划分法就是把程序的输入域划分成若干部分，然后从各部分中选取少数代表性数据作为测试用例。各类的代表性数据在测试中的作用等价于该类中的其他值，即如果某一类中的一个例子发现了错误，该等价类中的其他例子也能发现同样的错误；反之同理。使用该方法设计测试用例，首先必须在分析需求规格说明的基础上划分等价类，列出等价类表。
2．划分等价类和列出等价类表
（1）等价类
等价类指某个输入域的子集合。在该子集合中，各输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对该类其他值的测试。故可以把全部输入数据合理地划分为若干等价类，在各等价类中取一个数据作为测试的输入条件，就可用少量代表性的测试数据取得较好的测试结果。
（2）等价类划分的情况
①有效等价类
有效等价类是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
②无效等价类
与有效等价类的定义恰巧相反。
注意：设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验。这样的测试才能确保软件具有更高的可靠性。
（3）确定等价类的原则
①在输入条件规定了取值范围或值的个数的情况下，可以确立一个有效等价类和两个无效等价类；
②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类；
③在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类；
④在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类；
⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）；
⑥在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。
（4）列出等价类表
在确立了等价类之后，建立等价类表，列出所有划分出的等价类如表5-1所示。
表5-1 等价类表示例
3．确定测试用例
（1）确定测试用例的步骤
①为每个等价类规定一个唯一的编号；
②设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复该步，最后使得所有有效等价类均被测试用例所覆盖；
③设计一个新的测试用例，使其只覆盖一个无效等价类。重复该步使所有无效等价类均被覆盖。
（2）示例说明
在寻找等价区间时，想办法把软件的相似输入、输出、操作分成组。这些组就是等价区间。具体例子如下：
①在两数相加的用例中，测试1＋13和1＋99999999似乎不同。程序对1和最大数值相加的处理和对两个小一些的数值相加的处理有所不同。后者必须处理溢出情况。因为软件操作可能不同，所以这两个用例属于不同的等价区间。
a．如果具有编程经验，可能会想到更多可能导致软件操作不同的“特殊”数值。复制的多种方法如图5-1所示，它给出了选中编辑菜单后显示复制和粘贴命令的计算器程序。各项功能（即复制和粘贴）有5种执行方式。若复制，可以单击复制菜单命令，键入C，按Ctrl＋C或Ctrl＋Shift＋C组合键。任何一种输入途径都会把当前数值复制到剪贴板中，执行同样的输出操作，产生同样的结果。
图5-1 复制的多种方法
b．如果要测试复制命令，可以把5种输入途径划分减为3个，单击菜单命令，键入C和按Ctrl＋C组合键。无论以何种方式激活复制功能都工作正常，甚至可以缩减为1个区间。
②已知标准的另存为对话框，如图5-2所示。
图5-2 存盘对话框
根据下面给出的规格说明，利用等价类划分的方法，给出足够的测试用例。“一个程序读入3个整数，把3个数值看作一个三角形的3条边的长度值。该程序要打印出信息，说明这个三角形是不等边的、等腰的、还是等边的”。可设三角形的3条边分别为A，B，C。如果能构成三角形的3条边，必须满足：A＞0，B＞0，C＞0，且A＋B＞C，B＋C＞A，A＋C＞B。
如果等腰，还要判断A＝B，或B＝C，或A＝C。
如果等边，则需判断是否A＝B，且B＝C，且A＝C。
a．列出等价类表，如表5-2所示。
表5-2 等价类表
b．设计测试用例：输入顺序是【A，B，C】，如表5-3所示。
表5-3 测试用例
注意：Windows文件名可以包含除了“、”“/”“：”“·”“？”“＜＞”和“\”之外的任意字符。文件名长度是1～255个字符。如果为文件名创建测试用例，等价区间有合法字符、非法字符、合法长度的名称、过长名称和过短名称。
（3）注意事项
①等价分配的目标是把可能的测试用例组合缩减到仍然足以满足软件测试需求为止。故选择了不完全测试，就要冒一定的风险，所以必须仔细选择分类。
②科学有时也是一门艺术。测试同一个复杂程序的两个软件测试员，可能会制定出两组不同的等价区间。只要审查等价区间的人都认为它们足以覆盖测试对象就可以了。
三、边界值分析法
从长期的测试工作经验得知，大量的错误发生在输入或输出范围的边界上，而不在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多错误。
1．边界条件
边界条件是特殊情况，程序在处理大量中间数值时都对，但可能在边界处出现错误。下面的一段源代码说明了在一个极简单的程序中如何产生边界条件问题。
该段代码的意图是创建包含10个元素的数组，并为数组中的每一元素赋初值－1。该程序建立了包含10个整数的数组data和一个计数值i。For循环是从1～10，数组中从第1个元素到第10个元素被赋予数值－1。在大多数开发语言脚本中，应当以声明的范围定义数组，在本例中定义语句是dim data(10) as integer，第一个创建的元素是data(0)，而不是data(1)。该程序实际上创建了一个从data(0)～data(10)共11个元素的数组。程序从1～10循环将数组元素的值初始化为－1，但是由于数组的第一个元素是data(0)，故没有被初始化。程序执行完毕，数组值如下：
data（0）＝0；data（6）＝－1
data（1）＝－1；data（7）＝－1
data（2）＝－1；data（8）＝－1
data（3）＝－1；data（9）＝－1
data（4）＝－1；data（10）＝－1
data（5）＝－1
注意：data（0）的值是0，不是－1。若后期用到数组的第1个元素data（0），不加注意以为其值为－1。在复杂的大型软件中，若产生该类问题，可能导致极其严重的软件缺陷。
2．次边界条件
有些边界在软件内部，用户几乎看不到，但软件测试仍有必要检查。这样的边界条件称为次边界条件或者内部边界条件。寻找这样的边界不要求软件测试员具有程序员那样阅读源代码的能力，但要求大体了解软件的工作方式。举例如下：
（1）2的乘方
计算机和软件的计数基础是二进制数，用位（bit）来表示0和1，一个字节（byte）由8位组成，一个字（word）由两个字节组成等。常用的2的乘方单位及其范围或值如表5-4所示。
表5-4 软件中2的乘方
注意：
①表5-4中所列的范围和值是作为边界条件的重要数据。除非软件向用户提出这些范围，否则在需求文档中不指明。其通常由软件内部使用，外部看不见，当然，在产生软件缺陷的情况下可能会看到。
②建立等价区间时，要考虑是否需要包含2的乘方边界条件。为覆盖任何可能的2的乘方次边界，还要包含临近双位边界的14、15和16，以及临近字节边界的254、255和256。
（2）ASC II表
ASC II表是另一个常见的次边界条件。部分ASC II值表的清单如表5-5所示。
表5-5 部分ASC II值表
注意：
①表5-5不是结构良好的连续表。0～9的后面ASC II值是48～57。斜杠字符（/）在数字0的前面，而冒号字符“：”在数字9的后面。大写字母A～Z对应65～90，小写字母对应97～122，这些情况都代表次边界条件。
②如果测试进行文本输入或文本转换的软件，在定义数据区间包含哪些值时，参考ASCII表是相当明智的。
（3）其他一些边界条件
另一种看起来很明显的软件缺陷来源于当软件要求输入时，没有输入任何内容，只按了Enter键，这种情况在产品说明书中常常被忽视，但是在实际使用中却时有发生。如果没有对空值进行好的处理的话，将不知程序会引向何方。正确的软件通常应将输入内容默认为合法边界内的最小值，或合法区间内的某合理值，否则，返回错误提示信息。这些值通常在软件中进行了特殊处理，需要建立单独的等价区间。
3．边界值的选择方法
（1）概述
边界值分析是一种补充等价划分的测试用例设计技术，其不是选择等价类的任意元素，而是选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也适用于输出域测试用例。
（2）遵循原则
对边界值设计测试用例，应遵循以下原则：
①如果输入条件规定了值的范围，则应取刚达到该范围的边界的值，以及刚刚超越该范围边界的值作为测试输入数据；
②如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据；
③根据规格说明的各输入条件，使用前面的原则①；
④根据规格说明的各输出条件，应用前面的原则②；
⑤如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例；
⑥如果程序中使用了一个内部数据结构，则应当选择该内部数据结构边界上的值作为测试用例；
⑦分析规格说明，找出其他可能的边界条件。
四、错误推测法
错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误，有针对性地设计测试用例的方法。其基本思想是列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
五、因果图法
1．概述
因果图法是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换为判定表。在软件工程中，有些程序的功能可以用判定表的形式来表示，并根据输入条件的组合情况规定相应的操作。故应该为判定表中的每一列设计一个测试用例，以便保证测试程序在输入条件的某种组合下，操作正确。
2．因果图设计方法
（1）利用因果图导出测试用例的步骤
①分析程序规格说明的描述中的原因和结果
原因常是输入条件或是输入条件的等价类，而结果是输出条件。
②分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”
③标明约束条件
由于语法或环境的限制，有些原因和结果的组合情况不可能出现。为表明这些特定的情况，在因果图上使用若干个标准的符号标明约束条件。
④把因果图转换成判定表
⑤为判定表中每一列表示的情况设计测试用例
因果图生成的测试用例（局部，组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而增加。在较为复杂的问题中该方法常常十分有效，能有力地确定测试用例。若开发项目在设计阶段就采用了判定表，就不必再画因果图，可以直接利用判定表设计测试用例。
（2）因果图中的基本符号
通常在因果图中，用Ci表示原因，Ei表示结果，其基本符号如图5-3所示。各结点表示状态，可取“0”或“1”值。“0”表示某状态不出现，“1”表示某状态出现。
图5-3 因果图的基本图形符号
①恒等：若原因出现，则结果出现；若原因不出现，则结果也不出现。
②非（～）：若原因出现，则结果不出现；若原因不出现，则结果出现。
③或（∨）：若几个原因中有1个出现，则结果出现；若几个原因都不出现，则结果不出现。
④与（∧）：若几个原因都出现，结果才出现。若其中有1个原因不出现，则结果不出现。
（3）因果图中可附加的约束条件符号
为表示原因与原因之间、结果与结果之间可能存在的约束条件，在因果图中可以附加一些表示约束条件的符号。从输入（原因）考虑，有4种约束，例如：（a）、（b）、（c）、（d）。从输出（结果）考虑，还有1种约束，例如：（e），如图5-4所示。
图5-4 因果图的约束符号
①E（互斥）：表示a、b两个原因不会同时成立，两者最多有一个可能成立。
②I（包含）：表示a、b、c三个原因中至少有一个必须成立。
③O（唯一）：表示a和b当中必须有一个，且仅有一个成立。
④R（要求）：表示当a出现时，b必须也出现。a出现时不可能b不出现。
⑤M（屏蔽）：表示当a是1时，b必须是0。而当a为0时，b的值不定。
3．因果图测试用例
有一处理单价为1元5角钱的盒装饮料的自动售货机软件。若投入1元5角硬币，按下“可乐”“雪碧”或“红茶”按钮，相应的饮料就送出来。若投入的是两元硬币，在送出饮料的同时退还5角硬币。分析该段说明，可列出原因和结果。
（1）原因
①投入1元5角硬币；
②投入2元硬币；
③按“可乐”按钮；
④按“雪碧”按钮；。
⑤按“红茶”按钮。
（2）中间状态
①已投币；
②已按钮。
（3）结果
①退还5角硬币；
②送出“可乐”饮料；
③送出“雪碧”饮料；
④送出“红茶”饮料。
根据原因和结果，可设计以下因果图（如图5-5所示。）
图5-5 因果图
转换为测试用例，如表5-6所示，每一列可作为确定测试用例的依据。
表5-6
六、判定表驱动法
在程序设计发展初期，判定表已被用作编写程序的辅助工具，它可以把复杂的逻辑关系和多种条件组合的情况表达得较明确。
1．判定表组成
判定表通常由4个部分组成，如图5-6所示。
图5-6 判定表
（1）条件桩（condition stub）
列出问题的所有条件，列出条件的次序无关紧要。
（2）动作桩（action stub）
列出问题规定可能采取的操作。该操作排列顺序没有约束。
（3）条件项（condition entry）
列出针对其所列条件的取值，在所有可能情况下的真、假值。
（4）动作项（action entry）
列出在条件项的各种取值情况下应该采取的动作。
（5）规则
任何一个条件组合的特定取值及其相应要执行的操作。在判定表中贯穿条件项和动作项的一列就是一条规则。显然，判定表中列出多少组条件取值，就有多少条规则，条件项和动作项就有多少列。
2．判定表建立
（1）建立步骤
①确定规则的个数，假如有n个条件，每个条件有两个取值（0，1），故有2n种规则；
②列出所有的条件桩和动作桩；
③填入条件项；
④填入动作项和制定初始判定表；
⑤简化，合并相似规则或者相同动作。
（2）Beizer指出的适合使用判定表设计测试用例的条件
①规格说明以判定表的形式给出，或很容易转换成判定表；
②条件的排列顺序不影响执行哪些操作；
③规则的排列顺序不影响执行哪些操作；
④当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则；
⑤如果某一规则要执行多个操作，这些操作的执行顺序无关紧要。
七、正交试验法
1．正交试验设计方法
（1）简介
正交试验法是使用已经造好了的表格“——”正交表来安排试验并进行数据分析的一种方法。其简单易行并且计算表格化，应用性较好。
（2）举例
①例题
为提高某化工产品的转化率，选择了三个有关因素进行条件试验，反应温度（A），反应时间（B），用碱量（C），并确定了各自试验范围如下：
a．A：80～90℃。
b．B：90～150分钟。
c．C：5%～7%。
②试验目的
搞清楚因子A、B、C对转化率有何种影响，分清主次要，从而确定最适生产条件，即温度、时间及用碱量各为多少才能使转化率最高。此处，对因子A、B和C，在试验范围内都选了三个水平，如下所示：
a．A：A1＝80℃，A2＝85℃，A3＝90℃。
b．B：B1＝90分钟，B2＝120分钟，B3＝150分钟。
c．C：C1＝5%，C2＝6%，C3＝7%。
在正交试验设计中，因子可以定量，也可以定性。而定量因子各水平间的距离可以相等，也可以不相等。
③试验方法
a．全面试验法
第一，简介
取三因子所有水平之间的组合，即A1B1C1，A1B1C2，……，A3B3C3，共有33＝27次试验。立方体的27个节点如表5-7所示。
图5-7 全面试验法取点
第二，特点
全面试验对各因子与指标间的关系剖析得比较清楚。但试验次数太多。特别是当因子数目多，每个因子的水平数目也很多时，试验量非常大。如选6个因子，每个因子取5个水平时，如欲做全面试验，则需56＝15625次试验，实际上不可能实现。如果应用将要介绍的正交试验法，只做25次试验就行了。而且在某种意义上讲，这25次试验代表了15625次试验。
b．简单对比法
第一，简介
简单对比法即变化一个因素而固定其他因素，如首先固定B、C于B1、C1，使A变化：
如得出结果A3最好，则固定A于A3，C还是C1，使B变化：
得出结果以B2为最好，则固定B于B2，A于A3，使C变化：
试验结果以C2为最好。则认为最好的工艺条件是A3B2C2。
第二，特点
最大优点就是试验次数少，通常有一定效果，但缺点很多。首先该方法的选点代表性很差，如按上述方法进行试验，试验点完全分布在一个角上，而在一个很大的范围内没有选点，因此这种试验方法不全面。其次，用该方法比较条件好坏时，是把单个的试验数据拿来，进行数值上的简单比较，而试验数据中必然包含着误差成分，所以单个数据的简单比较不能剔除误差，必然造成结论的不稳定。
注意：考虑兼顾这两种试验方法的优点，从全面试验的点中选择具有典型性、代表性的点，使试验点在试验范围内分布得很均匀，能反映全面情况。如上例，对应于A、B、C各有3个平面，共9个平面，9个平面上的试验点都应当一样多，即对各因子的各水平都要同等看待。如图5-8所示，试验点用0表示。可知，在9个平面中每个平面上都恰好有3个点，而每个平面的每行每列都有1个点，而且只有1个点，总共9个点。这样的试验方案，试验点的分布很均匀，试验次数也不多。
图5-8 正交试验设计图例
④正交试验设计法
a．简介
用正交表来安排试验及分析试验结果的方法，按照正交表来安排试验，能使试验点分布很均匀和减少试验次数，且计算分析简单，能够清晰地阐明试验条件与指标之间的关系。正交表具有两条性质：每列中各数字出现的次数一样多；任何两列所构成的各有序数对出现的次数都一样多。
b．L符号各数字的意义
一般用L代表正交表，常用的有L8（27）、L9（34）、L16（45）、L8（4×24）等。此符号各数字的意义如下：
第一，L8（27）
7为此表列的数目（最多可安排的因子数）；2为因子的水平数；8为此表行的数目（试验次数）。
第二，L18（2×37）
有7列是3水平的，有1列是2水平的，L18（2×37）的数字表明，用其来安排试验，做18个试验最多可以考察1个2水平因子和7个3水平因子。在行数为mn型的正交表中（m，n是正整数），试验次数（行数）＝∑（每列水平数－1）＋1，利用上述关系式可以从所要考察的因子水平数来决定最低的试验次数，进而选择合适的正交表。
比如要考察5个3水平因子及一个2水平因子，则起码的试验次数为5×（3－1）＋1×（2－1）＋1＝12（次），即在行数不小于12，既有2水平列又有3水平列的正交表中选择，L18（2×37）适合。
第三，在L9（34）中（如表5-7所示）
各列中的1、2、3都各自出现3次；任何两列，例如第3、4列，所构成的有序数对从上向下共有9种，既没有重复也没有遗漏。其他任何两列所构成的有序数对也是这9种各出现一次。这反映了试验点分布的均匀性。
表5-7 L9（34）正交表
c．试验方案的设计
安排试验时，只须把所考察的每个因子任意地对应于正交表的一列（一个因子对应一列，不能让两个因子对应同一列），然后把每列的数字“翻译”成所对应因子的水平。故每行的各水平组合就构成了试验条件（不考虑没安排因子的列）。
对于上例，因子A、B、C均为水平的，试验次数要不少于3×（3－1）＋1＝7（次），可考虑选用L9（34）。因子A、B、C可任意地对应于L9（34）的某三列，例如A、B、C分别放在1、2、3列，然后试验按行进行，顺序不限，每一行中各因素的水平组合就是每一次的试验条件，从上到下就是这个正交试验的方案，如表5-8所示。该试验方案的几何解释正好是正交试验设计图例。
表5-8 试验方案
3个3水平的因子，做全面试验需要33＝27次试验，现用L9（34）来设计试验方案，只要做9次，工作量减少了2/3，而在一定意义上代表了27次试验。
2．正交试验测试用例设计步骤
（1）提取功能说明，构造因子—状态表
把影响实验指标的条件称为因子，而影响实验因子的条件称为因子的状态。确定因子与状态是设计测试用例的关键。
利用正交试验设计方法设计测试用例，首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素，把其当作因子，而把各个因子的取值当做状态。应尽可能全面地、正确地确定取值，以确保测试用例的设计做到完整与有效。
（2）加权筛选，生成因素分析表
对因子与状态的选择可按其重要程度分别加权。可根据各个因子及状态作用的大小、出现频率的大小以及测试的需要，确定权值的大小。
（3）利用正交表构造测试数据集，正交表的推导依据Galois理论
与使用等价类划分、边界值分析、因果图等方法相比，利用正交试验设计方法设计测试用例优点如下：
①节省测试的工作工时；
②可控制生成的测试用例的数量；
③测试用例具有一定的覆盖率。
可以采用正交试验法设计出最少的测试组合，达到有效的测试目的。
八、功能图法
1．功能图设计方法
（1）简介
功能图方法是用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例。功能图方法实际上是一种黑盒、白盒混合用例设计方法。
（2）功能图模型的构成
①状态迁移图
状态迁移图用于表示输入数据序列以及相应的输出数据。在状态迁移图中，由输入数据和当前状态决定输出数据和后续状态。
②逻辑功能模型
逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系。只适合于描述静态说明，输出数据仅由输入数据决定。测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成。
（3）特点
功能图方法中要用到逻辑覆盖和路径测试的概念和方法，属于白盒测试方法中的内容。逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法，该方法要求测试人员对程序的逻辑结构清楚地了解。由于覆盖测试的目标不同，逻辑覆盖可分为：语句覆盖、判定覆盖、判定一个条件覆盖，条件组合覆盖及路径覆盖。以下指的逻辑覆盖和路径是功能或系统水平上的，以区别于白盒测试中程序内部，如图5-9及表5-9所示。
图5-9 功能图
表5-9 判定表
2．功能图法生成测试用例
功能图由状态迁移图和布尔函数组成。状态迁移图用状态和迁移来描述一个状态，指出数据输入的位置（或时间），而迁移则指明状态的改变，同时要依靠判定表和因果图表示的逻辑功能。
（1）测试用例生成方法
从功能图生成测试用例，得到的测试用例数可接受。问题的关键是如何从状态迁移图中选取测试用例。若用节点代替状态，用弧线代替迁移，状态迁移图就可转化成一个程序的控制流程图形式。问题就转化为程序的路径测试问题（白盒测试范畴概念）。
（2）测试用例生成规则
为了把状态迁移（测试路径）的测试用例与逻辑模型的测试用例组合起来，从功能图生成实用的测试用例，须定义下面的规则。一个结构化的状态迁移中，定义3种形式的循环：顺序、选择和重复。但分辨一个状态迁移中的所有循环是有困难的。
（3）从功能图生成测试用例的过程
①生成局部测试用例：在各状态中，从因果图生成局部测试用例，局部测试库由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成。
②测试路径生成：利用上面的规则生成从初始状态到最后状态的测试路径。
③测试用例合成：合成测试路径与功能图中各状态的局部测试用例。结果是初始状态到最后状态的一个状态序列，以及各状态中输入数据与对应输出数据的组合。
④测试用例的合成算法：采用条件构造树。
九、场景法
1．基本流和备选流
如图5-10所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的彩色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。
图5-10 基本流和各选流
按照如图5-10中所示的每个经过用例的路径，可以确定以下用例场景：
（1）场景1：基本流。
（2）场景2：基本流、备选流1。
（3）场景3：基本流、备选流1、备选流2。
（4）场景4：基本流、备选流3。
（5）场景5：基本流、备选流3、备选流1。
（6）场景6：基本流、备选流3、备选流1、备选流2。
（7）场景7：基本流、备选流4。
（8）场景8：基本流、备选流3、备选流4。
注意：为方便起见，场景5、6和8只考虑了备选流3循环执行一次的情况。
2．ATM例子
（1）例子描述
ATM例子的流程示意图如图5-11所示。
图5-11 ATM流程示意图
如表5-10所示，表中包含了图5-11中所示提款用例的基本流和某些备用流。
表5-10 用例流
续表
（2）场景设计
生成的场景如表5-11所示。
表5-11 场景设计
（3）用例设计
对于以上7个场景中的各场景都需要确定测试用例，一般采用矩阵或决策表来确定和管理测试用例。一种通用格式如表5-12所示，其中行代表各个测试用例，列代表测试用例的信息。首先确定执行用例场景所需的数据元素，然后构建矩阵，最后要确定包含执行场景所需的适当条件的测试用例。以下的矩阵中，V表示这个条件必须是有效的才可执行基本流，I表示这种条件下将激活所需备选流，n/a表示该条件不适用于测试用例。
表5-12 测试用例表
以上的矩阵中，注意如下：
①六个测试用例执行了四个场景。对于基本流，上述测试用例CW1被称为正面测试用例。一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。对于基本流，负面测试用例由CW2～CW6表示。CW2～CW6相对于备选流2～4而言是正面测试用例。而且对于这些备选流中的每个而言，至少存在一个负面测试用例，就是CW1-基本流。
②各场景只有一个正面测试用例和负面测试用例是不充分的，场景4正是这样的一个示例。要全面地测试场景4-PIN有误，至少需要三个正面测试用例，以激活场景4：
a．输入了错误的PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤3-输入PIN。
b．输入了错误的PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。
c．最后一次输入时输入了“正确”的PIN。备选流在步骤5-输入金额处重新加入基本流。
③上面矩阵中，无需为条件输入任何实际的值。以该方式创建测试用例矩阵的优点在于容易看到测试的是何种条件。由于只需要查看V和I，该方式还易于判断是否已经确定了充足的测试用例。从表5-12中可发现存在几个无效的条件I，这表明测试用例还不完全，如场景6-不存在的账户/账户类型有误和场景7-账户余额不足就缺少测试用例。
（4）数据设计
一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。测试数据表如表5-13所示。
表5-13 测试数据表
测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据。以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。
①需要其他测试用例的内容
a．场景6——账户不存在/账户类型有误：未找到账户或账户不可用。
b．场景6——账户不存在/账户类型有误：禁止从该账户中提款。
c．场景7——账户余额不足：请求的金额超出账面金额。
②用到测试用例的情况
在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：
a．无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）；
b．无法读卡（读卡机堵塞、脱机或出现故障）；
c．账户已消户、冻结或由于其他方面原因而无法使用；
d．ATM内的现金不足或不能提供所请求的金额（与CW3不同，在CW3中只是一种币值不足，而不是所有币值都不足）；
e．无法联系银行系统以获得认可；
f．银行网络离线或交易过程中断电。
结论：所有从事软件测试和即将从事软件测试的人大都是从黑盒测试做起的，各类型的软件、各测试用例设计的方法都有各自的特点，针对不同软件如何利用这些黑盒方法非常重要，能极大地提高测试效率和测试覆盖度，认真掌握这些方法的原理，有效提高测试水平，积累更多的测试经验。
十、测试方法选择的综合策略
（1）首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，此为减少工作量和提高测试效率最有效的方法；
（2）在任何情况下都必须使用边界值分析方法。经验表明，用该方法设计出的测试用例发现程序错误的能力最强；
（3）可以用错误推测法追加一些测试用例，这需要依靠测试工程师的智慧和经验；
（4）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。若没有达到要求的覆盖标准，应当再补充足够的测试用例；
（5）如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法；
（6）对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果；
（7）功能图法是很好的测试用例设计方法，可以通过不同时期条件的有效性设计不同的测试数据；
（8）对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。
5．2 测试用例的编写
一、测试用例计划的重要性
仔细计划测试用例，是达成测试目标的必由之路，这样做的重要性体现如下：
（1）在小型软件项目上，可能有数千个测试用例。建立用例可能需要测试员经过一段时间时间。正确的计划会组织好用例，以便全体测试员和其他项目小组成员有效地审查和使用。
（2）在项目期间有必要多次执行同样的测试，以寻找新的软件缺陷，保证老的软件缺陷得以修复。若没有正确计划，不可能知道需要执行哪个测试用例，原有的测试是否得到重复。
（3）有时需要回答整个项目期间的重要问题。若没有测试用例计划，就不能回答。
（4）在少数高风险行业中，软件测试小组必须明确执行计划执行的测试。发布忽略某些测试用例的软件是危险的。正确的测试用例计划和跟踪提供了一种证实测试的手段。
二、测试设计说明
为更好地进行测试，需要为单个软件特性定义具体的测试方法，即测试设计说明。测试设计说明的目的是组织和描述针对具体特性需要进行的测试，其并不给出具体的测试用例或者执行测试的步骤。以下内容来自于ANSI/IEEE829标准，应作为测试设计说明的部分内容：
1．标识符
用于引用和定位测试设计说明的唯一标识符。该说明还应该引用整个测试计划和包含任何其他计划或者说明的引用。
2．要测试的特性
对测试设计说明所包含的软件特性的描述。该部分还将明确指出要间接测试的特性，通常作为主特性的辅助特性。
3．方法
描述测试的通用方法。如果方法在测试计划中列出，应该在此详细描述要使用的技术，并给出如何验证测试结果的方法。用文件比较工具比较输出的文件和源文件，若相同，则认为通过；若不同，则认为失败。
4．测试用例信息
用于描述所引用的测试用例的相关信息。应该列出所选的等价区间，给出测试用例的引用信息以及用于执行测试用例的测试程序说明。
5．通过/失败规则
描述用何种规则来判定某项特性的测试结果是通过还是失败的。该描述有可能非常简单和明确。也可能不是非常明确。
三、测试用例说明
1．简介
ANSI/IEEE829标准称测试用例说明为编写用于输入输出的实际数值和预期结果，还明确指出，使用具体测试用例产生的测试程序的限制。测试用例的编写如表5-14所示。
表5-14 测试用例
2．ANSI/IEEE 829标准列出的应包含的重要信息
一个测试用例说明可以由多个测试用例说明来引用，也可引用多个测试程序。ANSI/IEEE 829标准还列出了一些应该包含在内的重要信息，如下：
（1）标识符
由测试设计过程说明和测试程序说明引用的唯一标识符。
（2）测试项
描述被测试的详细特性、代码模块等，比测试设计说明中所列的特性更加具体。如果测试设计说明提到“计算器程序的加法功能”，则测试用例说明就会相应地提到“加法运算的上限溢出处理”。还要指出引用的产品说明书或者测试用例所依据的其他设计文档。
（3）输入说明
该说明列举执行测试用例的所有输入内容或者条件。如果测试计算器程序，输入说明可能简单到“1＋1”。如果测试蜂窝电话交换软件，输入说明可能是成百上千种输入条件。如果测试基于文件的产品，输入说明可能是文件名和内容的描述。
（4）输出说明
描述进行测试用例预期的结果。
（5）环境要求
环境要求是指执行测试用例必要的硬件、软件、测试工具、人员等。
（6）特殊要求
描述执行测试必须的特殊要求。测试写字板程序也许不需要任何特殊条件，但是测试一些特殊的软件（如核电站软件）就有特殊要求。
（7）用例之间的依赖性
若一个测试用例依赖于其他用例，或者受其他用例的影响，应在此注明。
若按照此处推荐的文档格式，对于每个测试用例至少都要写上一页的描述文字，数干个测试用例可能要形成几千页文档。所以常把ANSI/IEEE 829标准当作规范而不是标准使用。
3．举例
采用简便方法并不是说放弃或者忽视重要的信息，而是意在找出一个更有效的方法对这些信息进行精简。一个打印机兼容性简单列表的例子如表5-15所示。
表5-15 打印机兼容性简单列表
表中的每一行是一个测试用例，有自己的标识符。伴随测试用例的所有其他信息，例如测试项、输入说明、输出说明、环境要求、特殊要求和依赖性等对所有这些用例都必须有，可以一并编写，附加到表格中。审查测试用例的人可以快速看完测试用例信息，然后审查表格，检查其范围。表述测试用例的其他选择有大纲、状态表或数据流程图等方式。
四、测试程序说明
ANSI/IEEE829标准把测试程序定义为“明确指出为实现相关测试设计而执行具体测试用例和操作软件系统的全部步骤”。测试程序又称“测试脚本说明”，详细定义了执行测试用例的每一步操作。需要定义的内容如下：
1．标识符
用来把测试程序与相关测试用例和测试设计相联系的唯一标识。
2．目的
本程序描述的目的以及将要执行的测试用例的引用信息。
3．特殊要求
执行测试所需的其他程序、特殊测试技术或者特殊设备。
4．程序步骤
执行测试用例的详细描述。包含以下内容：
（1）日志：指出用何种方法记录测试结果和现象；
（2）设置：说明如何准备测试；
（3）启动：说明启动测试的步骤；
（4）程序：描述运行测试的步骤；
（5）衡量标准：描述如何判断结果；
（6）关闭：描述因意外原因而推迟测试的步骤；
（7）终止：描述正常停止测试的步骤；
（8）重置：说明如何把环境恢复到测试前的状态；
（9）偶然事件：说明如何处理计划之外的情况。
使用详细的程序说明，把要测试什么、如何测试等问题都表述得一目了然。如图5-12所示是“Windows计算器”的测试程序说明的例子片断。
图5-12 测试程序说明片断
五、测试用例细节探讨
1．概述
测试用例计划包括四个目标，组织性、重复性、跟踪和测试证实。开发测试用例的软件测试工程师要力争实现这些目标，但是其实现程度取决于行业、公司、项目和测试组的具体情况，通常不太可能按照最细致的程度去编写测试用例。
2．特点
（1）设计的测试用例计划要力求达到最佳的详细程度。
（2）无比详细的测试用例说明减少了测试的随意性，使测试可以很好地重复，使得无经验的测试人员按照测试用例说明也能执行测试。但编写如此细致的测试用例说明要花费相当多的时间和精力，且由于细节繁多，会阻滞测试工作，造成测试执行时间变长。
（3）开始编写测试用例时，最好是采用当前项目的标准，同时需要根据ANSI/IEEE 829标准定义的格式，看什么符合项目要求，并做适当调整。
（4）不同的测试工程师设计的测试用例会有所不同。通常有经验的测试工程师设计出来的测试用例，在深度及广度上会比经验少的测试工程师的完整，这就是测试经验值。