软件测试学习之黑盒测试方法论

黑盒测试方法论

等价类

等价类划分法

等价类划分是一种重要的、常用的黑盒测试方法

不需要考虑程序的内部结构，只需要考虑程序的输入规格即可

它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性

用户所有可能输入的数据，划分成了若干个子集，然后从每一个子集当中选取少数具有代表性的数据作为测试用例

在有限的测试资源的情况下，用少量有代表性的数据得到比较好的测试结果

等价类分类

有效等价类：指符合《需求文档》，输入合理的数据集合            

无效等价类：指不符合《需求文档》，输入不合理的数据集合

等价类划分原则

1、规定输入的取值范围或个数时，划分一个有效和两个无效

2、规定了输入的集合或规则必须要遵循的条件，则划分一个有效和一个无效

3、输入条件是一个布尔值，则划分为一个有效和一个无效

4、输入条件是一组数据，并且每一个输入的值做不同的处理，则划分若干有效和一个无效

5、输入条件规定了必须要遵循的某项规则下，则划分为一个有效和若干个无效

6、不是所有的等价类都有无效等价类

等价类设计步骤

1、先划分等价类：找出所有可能的分类

2、有效等价类：需求中的条件

3、确定无效等价类：与条件相反的情况，再找到特殊情况

4、从各个分类中挑选测试用例数据

等价类总结

长度

类型

组成规则

是否为空

是否重复

是否去除空格

边界值分析法

大量的软件测试实践表明，故障往往出现在定义域或值域的边界上，而不是在其内部

为检验边界附近的处理专门设计测试用例，通常都会取得很好的测试效果

边界值分析法是一种很实用的黑盒测试用例方法，它具有很强的发现故障的能力

边界值分析法是作为对等价类划分法的补充，测试用例来自等价类的边界

边界值确定

上点：边界上的点

离点：离上点最近的点

内点：在输入域内任意一个点

选取正好等于等于、刚好大于或刚好小于边界值作为测试数据

边界点划分规则

如果规定了输入域的取值范围

       选取刚好在范围边界的点

       刚好超过边界的点

如果规定了输入值的个数

       最大个数

       最小个数

       比最小个数少1

       比最大个数多1

如果规定了输入是一个有序的集合

       选取集合的第一个元素

       选取集合的最后一个元素

边界值总结

确定边界情况

选取正好等于、刚刚好大于或刚刚好小于边界值作为测试数据

确定各个值的等价类

因果图法

因果图定义

因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法

它适合于检查程序输入条件的各种组合情况

       “因“—— 输入条件

       “果”—— 输出结果

因果图适用场景

描述多种条件的组合

产生多个动作

因果图中的基本符号

恒等：若原因出现，则结果出现；若原因不出现，则结果也不出现

非：若原因出现，则结果不出现；若原因不出现，则结果出现

或：有多个原因。若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现

与：有多个原因。若几个原因都不出现，则结果才出现；若其中一个原因不出现，则结果不出现

 因果图中的约束条件

互斥E:a、b、c只能有一个成立，但是可以都不成立

包含I:a、b、c中至少有一个成立

唯一O:a、b、c有且仅有一个成立

要求R:如果a成立，则要求b必须也成立，其他的不约束

屏蔽M：如果a成立的时候，强制b不成立，其他的不约束

 

 

因果图法基本步骤

找出所有的输入条件（因）

找出所有的输出条件（果）

明确所有输入条件之间的制约关系以及组合关系

明确所有输出条件之间的制约关系以及组合关系

找出什么样的输入条件组合会产生哪种输出结果

把因果图转换成判定表

为判定表中的每一列表示的情况设计测试用例

判定表

判定表法

因果图只是一种辅助工具，通过分析最终得到判定表，再通过判定表编写测试用例

画因果图非常麻烦，影响测试效率，可以直接写判定表，进而编写测试用例

判定表的组成

条件桩：问题的所有条件

动作桩：问题的所有输出

条件项：针对条件桩的取值

动作项：条件项的各种取值情况下的输出结果

判定表设计步骤

1.列出所有的条件桩和动作桩

2.确定规则数：条件取值个数^条件数

3.填入条件项

4.填入动作项。得到初始判定表

5.简化判定表

场景法

场景法概述

场景法就是模拟用户操作软件时的场景，主要用于测试系统的业务流程

基本流：按照正确的业务流程来实现的一条操作路径

备选流：导致程序出现错误的操作流程

场景法用例设计步骤

根据需求规格说明，画出功能模块流程图；

根据流程图，描述出程序的基本流及备选流；

根据基本流和备选流生成不同的场景，构造场景列表；

对每一个场景生成相应的测试用例；

对生成的所有测试用例重新复审，去掉多余的测试用例；

测试用例确定后，为每一个测试用例确定测试数据值

优点：适合有业务流程的

缺点：未能验证单个流程点

基于模型的测试方法

Model-based testing介绍

基于模型的测试时基于模型的设计的应用，用于设计和可选地执行工件以执行软件测试或系统测试。模型可用于表示被测系统的期望行为，或表示测试策略和测试环境。

Model-based Testing中的模型

描述SuT的模型通常是对SUT所需行为的抽象、部分表示。从这种模型派生的测试用例是与模型在同一抽象级别上的功能测试。这些测试用例统称为抽象测试套件。抽象测试套件不能直接针对SUT执行，因为该套件处于错误的抽象级别。可执行的测试套件需要从响应的抽象测试套件派生而来。可执行测试套件可以直接与被测系统通信。这是通过将抽象测试用例映射到适合执行的具体测试用例来实现的。在一些基于模型的测试环境中，模型包含足够的信息来直接生成可执行的测试套件。在其他情况下，抽象测试套件中的元素必须映射到软件中的特定语句或方法调用，以创建具体的测试套件。这被称为解决“映射问题”。

模型构建方法

有限状态机

UML

编程语言

数学方法

Model-based Testing 中的testing

测试可以通过不同的方式从模型中导出。因为测试通常是实验性的并且基于启发式，所以没有已知的单一测试推导的最佳方法。通常将所有与测试派生相关的参数合并到一个包中，该包通常被称为“测试需求”、“测试目的”甚至“用例”。这个包可以包含关于模型中应该关注的那些部分的信息，或者完成测试的条件（测试停止标准）。

Model-based Testing补充说明

因为测试套件源自模型而不是源代码，基于模型的测试通常被视为一种形式的黑盒测试。复杂软件系统的基于模型的测试仍然是一个不断发展的领域

基于模型的测试方法（维基百科与百度百科）

基于模型的测试（英语：Model-based Testing）属于软件测试领域的一种测试方法。按照此方法，测试用例可以完全或部分的利用模型自动产生。以上所说的模型通常是指被测系统（SUT,system under test）某些（通常是功能性的）方面的描述。

模型一般都是对被测系统预期行为动作的抽象描述。这些测试用例的集合就是抽象测试套件（abstract test suite）。抽象测试套件不可以直接执行于需要测试的系统，因为，他们不在同一抽象级别。

测试套件（test suites）是由模型生成，而不是由源代码生成。因此，基于模型的测试又常常被当作黑盒测试的一种形式。但从某种层面来说，这并不十分准确。毕竟，基于模型的测试是与源代码级的测试覆盖率，以及对代码的功能测试都有着很大的关系。

工具

GraphWalker