黑盒测试
黑盒测试又称功能性测试、数据驱动测试、基于规格说明的测试
定义：在已知软件所应具有的功能的基础上，检查程序功能能否按需求规格说明书的规定正常使用，功能是否有遗漏，性能等特性要求是否满足。
特点：参照规格说明检查软件，不要求考察代码，以用户视角进行测试
目的：
1.检测软件功能是否正确和完整
2.检测是否有人机交互和数据访问错误
3.检测软件行为和性能是否满足需求
4.检测软件初始化和终止过程是否有错误
测试需求的描述
需求跟踪矩阵（RTM）
对软件开发过程所有需求进行跟踪。建立需求和测试用例的映射。
用例场景
描述流经用例的路径，从用例开始到结束，遍历这条路径上所有基本流和备选流。
- 基本流：正常流程
- 备选流：自基本流开始，在某特定条件下开始执行
- 可能重新加入基本流（流1, 流3）
- 可能起源于另一备选流（流2 ）
- 终止用例不再重新加入某流（流2，流4）
可生成场景：
场景1 基本流
场景2 基本流 备选流1
场景3 基本流 备选流1 备选流2
…
测试规格的描述
因果图
基本符号
约束符号
E约束(异)：a和b中最多有一个可能为1。
I 约束(或)：a、b、c中至少有一个必须为1。
O约束(唯一)：a和b必须有一个且仅有一个为1。
R约束(要求)：a是1时，b必须是1。
M约束(强制)：若结果a为1，则结果b强制为0。
例
规格说明要求：
输入的第一个字符必须是#或*，第二个字符必须是一个数
字，此情况下进行文件的修改；
如果第一个字符不是#或*，则给出信息N；
如果第二个字符不是数字，则给出信息M。
1）分析因果
| 原因 | 结果 |
|---|---|
| c1：第一个字符是# | e1：给出信息N |
| c2：第一个字符是* | e2：修改文件 |
| c3：第二个字符是一个数 | e3：给出信息M |
2）画出因果图
决策表
条件桩—列出问题的所有条件
条件项—针对条件桩给出的条件列出所有可能的取值
动作桩—列出问题规定的可能采取的操作
动作项—指出在条件项的各组取值情况下应采取的动作
步骤
（1） 确定规则的个数。n个条件的决策表有2^n个规则（每个条件取真、假）
（2） 列出所有的条件桩和动作桩。
（3） 填入条件项。
（4） 填入动作项，得到初始决策表。
（5） 简化决策表，合并相似规则。合并后的条件项用符号“-”表示。
契约
契约的形式
–前置条件：模块执行前应该满足的条件
–后置条件：模块执行后应满足的条件
–不变式：模块执行中应维持的一组性质
其它
- 自动机（状态转换图）
- 软件所要实现的功能可用自动机（状态转换图）描述。
- 代数规约
- 描述类等抽象数据类型
- 模态逻辑
- 线性时态逻辑
- 计算树逻辑
- Petri网
黑盒测试技术
-
从需求规格生成测试用例
-
随机测试法
-
自适应随机法
在输入空间中随机选择测试点的同时，刻意保证新选择的点与已有测试点有较大距离，从而更好地保证覆盖的全面性
-
等价类划分法
-
根据规约，将输入空间根据测试的等效性，划分为多个等价类，每个分类仅取一个或少量测试用例来进行测试
-
优点
- 代表性：少量测试数据
- 全面性：取得较好的测试结果
-
划分方法
- 根据输入数据本身的特征进行划分
- 根据可能造成的程序行为差异进行划分
- 对划分的结果进一步细分
-
用例设计
先尽量多地覆盖尚未覆盖的有效等价类，重复至所有的有效等价类均被测试用例所覆盖。然后设计新的测试用例，使它仅覆盖一个尚未覆盖的无效等价类，重复至所有的无效等价类均被测试用例所覆盖。
-
-
边界值分析法
对输入、输出或内部的边界值进行测试的一种测试方法。通常是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
-
错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。
-
正交实验设计法
-
对于因果、逻辑关系相对简单，或者不清晰，但组合关系复杂的程序可采用正交试验设计法生成测试用例。
-
使用已经造好了的正交表格来安排试验，简单易行并且计算表格化，应用性较好。特别适用于输入为枚举值的情况。
-
正交表
L8(2^7)：7为此表列的数目（最多可安排的因子数）；2为
因子的水平数；8为此表行的数目（试验次数）。
-
