|
|
|
黑盒测试又称为数据驱动测试、基于规格的测试、输入输出测试或者功能测试。黑盒测试基于产品功能规格说明书，从用户角度针对产品特定的功能和特性进行验证活动，确认每个功能是否得到完整实现，用户能否正常使用这些功能。
|
|
|
|
黑盒测试在不知道系统或组件内部结构的情况下进行，不考虑内部逻辑结构，着眼于程序外部结构，在软件接口处进行测试。黑盒测试主要具有如下功能：
|
|
|
|
（1）检查程序功能能否按需求规格说明书的规定正常使用，测试各个功能是否有遗漏，检测是否满足性能等特性要求。
|
|
|
|
（2）检测人机交互是否错误，检测数据结构或外部数据库访问是否错误，程序是否能适当地接收输入数据而产生正确的输出结果，并保持外部信息（如数据库或文件等）的完整性。
|
|
|
|
|
|
黑盒测试方法主要有等价类划分、边界值分析、决策表、因果图、错误推测和功能图法等测试方法，本节主要介绍等价类划分、边界值分析、决策表和元素分析法与错误推测法。
|
|
|
|
|
|
等价类是指某个输入域的子集合。在该子集合中，测试某等价类的代表值就等于对这一类其他值的测试，对于揭露程序的错误是等效的。因此，将输入的全部数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据取得较好的测试结果。
|
|
|
|
|
|
（1）有效等价类。对于程序的规格说明来说，它是由合理的、有意义的输入数据构成的集合，利用它可检验程序是否实现了规格说明中所规定的功能和性能。
|
|
|
|
（2）无效等价类。与有效等价类相反，它是由对程序的规格说明无意义、不合理的输入数据构成的集合。
|
|
|
|
测试用例的设计不仅接收合理的数据，也能经受意外的不合理数据的考验，这样才能确保软件具有较高的可靠性。
|
|
|
|
分析可能的输入情况，按照如下几条规则对等价类进行划分。
|
|
|
|
（1）在输入条件规定了取值范围或值的个数的情况下，确立一个有效等价类和两个无效等价类。
|
|
|
|
例如，若输入条件规定了x的取值为1～100的整数，则等价类划分有效等价类1≤x≤100，两个无效等价类分别为x<1或x>100。
|
|
|
|
（2）按照数值集合划分。在输入条件规定了输入值的集合或者规定了“必须如何”的条件下，确立一个有效等价类和一个无效等价类。
|
|
|
|
例如，输入条件规定了x的取值为偶数，则有效等价类为x的值为偶数，无效等价类为x的值不为偶数的整数。
|
|
|
|
（3）输入条件是一个布尔量的情况，确定一个有效等价类和一个无效等价类。
|
|
|
|
（4）规定输入数据取一组值（假定n个），并且程序要在对每一个输入值分别处理的情况下，确立n个有效等价类和一个无效等价类。
|
|
|
|
例如，分房方案中对教授、副教授、讲师、助教分别计分，则有效类为4个；无效类为1个。
|
|
|
|
（5）按照限制条件或规则划分。在规定输入数据必须遵守的规则的情况下，确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
|
|
|
|
例如，C程序设计语言的语法规定．每个语句应以“；”结束，则其有效类有1个，而无效类有若干个（如以“，”结束、以“：”结束、以空格结束等）。
|
|
|
|
（6）在确知已划分的等价类中各元素在程序处理方式不同的情况下，再将该等价类进一步划分为更小的等价类。
|
|
|
|
|
|
|
|
|
|
根据等价类表，确定测试用例。首先，为每一个等价类规定唯一编号；其次，设计新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；最后，设计新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止（通常，程序在执行一个错误后不继续检测其他错误，故每次只测一个无效类）。
|
|
|
|
|
|
软件测试实践中，大量的错误往往发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。例如，数组下标、循环控制变量等边界附近往往出现大量错误。因此，作为等价类划分方法的补充，边界值分析方法不是选择等价类的任意元素，而主要是针对各种边界情况设计测试用例。
|
|
|
|
|
|
（1）对16位的整数而言，32767和-32768是边界。
|
|
|
|
|
|
|
|
|
|
（5）循环的第0次、第1次和倒数第2次、最后一次是边界。
|
|
|
|
边界值分析法应着重测试的情况，一般选取等价类划分的输入和输出的边界正好等于或刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
|
|
|
|
|
|
（1）如果输入条件规定了值的范围，则应选取刚达到范围的边界值，以及刚刚超越边界的值作为测试的输入数据。
|
|
|
|
（2）如果输入条件规定了值的个数，则用略低于最小值、最小值、略高于最小值、正常值、略低于最大值、最大值和略高于最大值作为测试数据。
|
|
|
|
（3）如果程序规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
|
|
|
|
|
|
决策表又称为判定表，用于分析多种逻辑条件下执行不同操作的技术。在程序设计发展的初期，决策表是程序编写的辅助工具。决策表可以把复杂的逻辑关系和多种条件的组合情况表达明确，与高级程序设计语言中的if-else、switch-case等分支结构语句类似，它将条件判断与执行的动作联系起来。但与程序语言中的控制语句不同的是，决策表能将多个独立的条件和多个动作联系清晰地表示出来。
|
|
|
|
|
|
（1）条件桩：列出了问题的所有条件。通常认为，列出的条件次序无关紧要。
|
|
|
|
（2）动作桩：列出了问题规定可能采取的操作，这些操作的排列顺序没有约束。
|
|
|
|
（3）条件项：列出了针对条件桩的取值在所有可能情况下的真假值。
|
|
|
|
（4）动作项：列出了在条件项的各种取值的有机关联情况下应该采取的动作。
|
|
|
|
规则即任何条件组合的特定取值及其相应要执行的操作。在决策表中，贯穿条件项和动作项的列就是规则。显然，决策表中列出多少个条件取值，也就有多少个规则，条件项和动作项就有多少列。
|
|
|
|
所有条件都是逻辑结果的决策表称为有限条件决策表。如果条件有多个值，则对应的决策表就叫做扩展条目决策表。决策表用来设计测试用例，条件解释为输入，动作解释为输出。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
有n个条件的决策表有2n个规则（每个条件取真、假值）。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
元素分析法主要是对测试对象中的各个元素的属性、范围、特点等进行分析，通过对元素的分析，寻找出测试空间和缺陷空间，设计测试用例的方法。
|
|
|
|
|
|
|
|
（2）分析每个元素的特点和属性，确定测试空间与缺陷空间。
|
|
|
|
|
|
错误推测法是基于经验和直觉的推测，列举出程序中所有可能错误和容易发生错误的特殊情况，有针对性地设计测试用例。
|
|
|
|
经验表明，一段程序中已发现的错误数目和尚未发现的错误数目成正比。程序中容易出错的情况如下所示：当输入数据为零时，或者输入或输出的数目允许变化（例如，被检索的或生成的表的项数），或者输入或输出的数目为0和1的情况（例如，表为空或只有一项）等，都较容易发生错误。又如，在单元测试时曾列出许多在模块中常见的错误，以前产品测试中曾经发现的错误等，这些就是经验的总结。
|
|
|
|
错误推测法是根据测试人员的经验来确定测试的范围和程度，主要采用如下技术：
|
|
|
|
|
|
|
|
（3）根据测试类似或相关系统的经验，了解在以前的这些系统中曾在哪些地方出现过缺陷。
|
|
|
|
|
|
|
