软件工程：黑盒测试用例设计中的关键原则

软件测试从不同的角度可以有很多种分类，最常见的是以下三种分类：

1.从是否关心软件内部结构和具体实现的角度

（1）白盒测试

白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试需要全面了解程序内部逻辑结构，对所有逻辑路径进行测试。对逻辑路径进行覆盖有六种标准，包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化。

·语句覆盖：每条语句至少执行一次。

·判定覆盖：判定的每个分支至少执行一次。

·条件覆盖：每个判定的每个条件应取到各种可能的值。

·判定/条件覆盖：同时满足判定覆盖条件覆盖。

·条件组合覆盖：每个判定中各条件的每一种组合至少出现一次。

·路径覆盖：使程序中每一条可能的路径至少执行一次。

白盒测试如果要覆盖所有的可能，在某种程度上可以看成是一种穷尽测试，但在一个项目中试图采用穷尽测试是不可能的。因为测试用例的数量在理论上可以接近于无穷，因此需要采用合适的方式来进行测试，使之既能够测试所有的语句，覆盖所需的功能点，又不至于测试用例数量过于庞大。基本路径测试方法就是其中一种。基本路径测试是在程序控制流程图的基础上，通过分析控制结构的环路复杂性，导出基本可执行路径的集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。基本步骤是：

·根据流程图画出控制流图

流程图用来描述程序控制结构。可将流程图映射到一个相应的控制流图。在流图中，每一个圆称为流图的节点，代表一个或多个语句。一个处理方框序列和一个菱形决策框可被映射为一个节点，流图中的箭头，称为边或连接，代表控制流，类似于流程图中的箭头。一条边必须终止于一个节点，即使该节点并不代表任何语句。由边和节点限定的范围称为区域。计算区域时应包括图外部的范围。

·计算圈复杂度

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

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

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

②给定流图G的圈复杂度V（G），定义为V（G）＝E－N＋2，E是流图中边的数量，N是流图中节点的数量；

③给定流图G的圈复杂度V（G），定义为V（G）＝P＋1，P是流图G中判定节点的数量。

·导出独立路径

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

·根据独立路径设计测试用例，图7-12是基本路径测试法的前三步的例子，具体测试用例读者可以根据程序代码进行设计。

（2）黑盒测试

黑盒测试也称为行为测试，侧重于软件的功能需求。黑盒测试不是白盒测试的替代品，而是作为发现其他类型的错误的辅助方法，具体包括：不正确或遗漏的功能、接口错误、数据结构或外部数据库访问错误、行为或性能错误、初始化和终止错误。与白盒测试相比较，白盒测试一般在测试过程的早期执行，黑盒测试是在测试过程的中后期执行；白盒测试关注代码的内部结构，黑盒测试关注产品的外部功能和接口；进行白盒测试需要进行内部代码分析，而黑盒测试不需要。

在进行黑盒测试时的测试用例设计需要关注等价类划分和边界值分析。

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

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

无效等价类：与有效等价类的定义相反。

设计测试用例时，要同时考虑这两种等价类。因为，软件不仅要能接收合理的数据，也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。

确定等价类的指导原则是：

图7-12　基本路径测试法

·在输入条件规定了取值范围或值的个数的情况下，可以确定一个有效等价类和两个无效等价类。

·在输入条件需要特定值的情况下，可以确定一个有效等价类和两个无效等价类。

·在输入条件是一个布尔量的情况下，可以确定一个有效等价类和一个无效等价类。

·如输入条件指定集合的某个元素，可以确定一个有效等价类和一个无效等价类。

边界值分析是对等价类划分的合理补充，等价类更多的关注是值域的中间部分（有效等价类）和值域之外的部分（无效等价类），但错误很多时候是在值域的边界上发生。边界值分析的测试用例选取有以下指导原则：

·如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据；

·如果输入条件规定了一组数，则用最大值、最小值，以及略大于或略小于最大值和最小值的值；

·对于输出可以适用上述两条原则；

·如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。

正交表（正交数组）测试是在黑盒测试当中有效减少测试次数的一种方法。一般情况下，如果输入条件包含n个参数，每个参数有m个取值可能性的时候，那么输入的组合总数是mn个，即需要mn次测试，而采用正交数组来设计测试案例则可以有效地减少所需的测试次数。比如有4个输入参数，每个参数有3种不同的取值，一般情况下需要的测试次数是34＝81次，而采用正交表只需要9次（图7-13），一般正交表可以表示为：La（mn），其中a代表需要测试的数，m、n的含义与前面一样，从图7-13（b）可以看出正交表有以下特点：

图7-13　正交表

·每一列中，不同的数字出现的次数相等。如图7-13（b）中任何一列都有“1”“2”“3”，且在任一列的出现数均相等。

·任意两列中数字的排列方式齐全而且均衡。如图7-13（b）中任何两列有序对共有9种，1.1、1.2、1.3、2.1、2.2、2.3、3.1、3.2、3.3，且每对出现数也均相等。

以上两点充分地体现了正交表的两大优越性，即“均匀分散性，整齐可比”。通俗地说，每个因素的每个水平与另一个因素各水平各碰一次，这就是正交性。(www.xing528.com)

关于正交表的求解及其理论基础，有兴趣的读者可以参考组合数学与概率论的相关文献。黑盒测试的测试用例设计还有判定表法、因果图法等，限于篇幅，此处不再说明，有兴趣的读者可以参考相关资料。

（3）灰盒测试

灰盒测试介于白盒测试与黑盒测试之间，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。具体测试用例设计和测试方法可以根据需要采用白盒测试或黑盒测试的方法。

2.从是否执行程序的角度

（1）静态测试

静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。

静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。

·代码检查

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

·结构分析

结构分析主要是以图形的方式表现程序的内部结构，例如函数调用关系图、函数内部控制流图。其中，函数调用关系图以直观的图形方式描述一个应用程序中各个函数的调用和被调用关系；控制流图显示一个函数的逻辑结构。

·代码质量度量

静态测试中主要关注的是代码的可维护性。可维护性可以从四个方面去度量，即可分析性、可改变性、稳定性以及可测试性。可分析性牵涉到代码的编程规范，文档的编写规范等。可测试性在可分析性的基础上对代码本身编写质量有一定的要求，在结构分析中所得到的函数调用关系和控制流图都可以在此进行应用，函数调用越复杂，控制流图当中的圈复杂度越高，代表测试的难度越大。

静态测试通常是以评审的形式进行，根据测试的范围可以采用正式评审，也可以采用非正式评审的方法。

（2）动态测试

动态测试是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能。这种方法由三部分组成：构造测试实例、执行程序、分析程序的输出结果。动态测试是在软件测试当中运用最多的测试方法。

3.从软件开发过程的角度

（1）单元测试

单元测试是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义。如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。单元测试工作一般由程序员完成。

（2）集成测试

集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试。很多时候在进行单元测试的时候并没有问题，但是一旦进行组装，则发现模块不能够正常的运行。

集成测试的目的有功能性和非功能性两类。功能性的是指组装后的子系统或系统达到了系统设计所要求的功能，非功能性的是指除了功能以外的指标，如性能、可靠性等。

集成测试是一个循序渐进的过程，并不是要等到系统的全部模块完成之后再进行测试，问题发现的越早越有利于问题的解决。

（3）系统测试

系统测试是基于系统整体需求说明书的黑盒测试，应覆盖系统所有相关的部件，不仅仅包括需测试的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。系统测试的目的是验证系统是否满足需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的改进方案。系统测试发现问题之后，要经过调试找出错误原因和位置，然后进行改正。

典型的系统测试还包括恢复测试、安全测试、压力测试。

·恢复测试

恢复测试作为一种系统测试，主要关注导致软件运行失败的各种条件，并验证其恢复过程能否正确执行。在特定情况下，系统需具备容错能力。另外，系统失效必须在规定时间段内被更正，否则将会导致严重的经济损失。

·安全测试

安全测试用来验证系统内部的保护机制，以防止非法侵入。在安全测试中，测试人员扮演试图侵入系统的角色，采用各种办法试图突破防线。因此系统安全设计的准则是要想方设法使侵入系统所需的代价更加昂贵。

·压力测试

压力测试是指在正常资源下，使用异常的访问量、频率或数据量来执行系统。

（4）验收测试

验收测试是部署软件之前的最后一个测试操作。在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

（5）回归测试

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极限编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。

（6）确认测试

确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后.已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性。确认测试是在模拟环境下进行的验证被测软件是否满足需求规格说明书列出的需求。

确认测试又可以分为Alpha测试和Beta测试。

·Alpha测试

Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。Alpha测试的目的是评价软件产品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持），尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。Alpha测试为非正式验收测试。

·Beta测试

Beta测试是一种验收测试。Beta测试一般根据需求规格说明书严格检查产品，逐行逐字地对照说明书上对软件产品所做出的各方面要求，确保所开发的软件产品符合用户的各项要求。

图7-14反映了软件开发各阶段与各类测试之间的相互关系。其中需求分析阶段的成果对应验收测试，概要设计对应系统测试，详细设计对应集成测试，编码对应单元测试。此外从单元测试到验收设计，是从白盒测试过渡到黑盒测试，所有的测试可以采用静态测试方法也可以采用动态测试方法。从需求分析到编码的过程中测试计划和测试方案是逐步细化完成的。

图7-14　软件开发各阶段与各类测试之间的关系