一、黑白盒测试
1.1 基本理论概述
| 方面 | 黑盒测试 | 白盒测试 |
|---|---|---|
| 定义 | 无需了解代码内部的测试方法， 以用户的角度， 从输入与输出数据的对应关系的测试方法。 | 需要了解内部结构或代码， 以开发者的角度， 对内部结构逻辑运作形式的测试方法。 |
| 目的 | 注重软件功能的测试：
| 注重软件内部逻辑结构的覆盖测试：
|
| 方法 |
|
|
| 优点 | 模拟真实用户场景，不受代码更改影响。 | 深入覆盖代码逻辑，更好地识别错误。 |
| 缺点 | 覆盖范围有限，无法访问内部问题。 | 耗时，高度依赖于实现更改。 |
| 适用层级 | 通常适用于较高级别（例如系统、验收）。 | 应用于所有层级（单元、集成、系统等）。 |
1.2 测试方法
1.2.1 黑盒测试方法
1.2.1.1 等价类划分法
划分等价类：
概念：等价类是指某个输入域的子集合。
分类：根据输入数据的合理性对等价类划分分为两种情况：有效等价类和无效等价类。
- 有效等价类：是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合内利用有效等价类可检验程序是否实现规格说明中的规定功能性能。例如规定0~100人，输入在该范围内即可。
- 无效等价类：包含不符合输入合理性的输入数据的子集。例如，规定0~100人，输入-10，101人；规定性别，输入外星人或数字等不合规数据。
确定类原则：
- 在输入条件规定了取值范围或值的个数的情况下，则 1 有效 + 2 无效
- 在输入条件规定了输入值的集合或者界定“必须如何”的条件的情况下，则 1 有效 + 1 无效
- 在输入条件是一个bool的情况下，则 1 有效 + 1 无效
- 规定输入数据的一组值（设 n 个），程序要对每一输入值分别处理的情况，n 有效 + 1 无效
- 规定输入数据必须遵守的规则的情况下，1 有效 + m 无效
- 确知已划分的等价类中各元素在程序处理中的方式不同的情况，应细分等价类。
用例设计原则：
考虑：输入条件 有效等价类 无效等价类
- 为每一个等价类规定一个唯一的编号。
- 设计一个新的测试用例：1）使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步直到所有的有效等价类都被覆盖为止；2）使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步直到所有的无效等价类都被覆盖为止。
1.2.1.2 边界值分析法
概念：通过选择等价类边界的测试用例。
特点：重视输入及输出条件边界，一般为那些恰好处于边界、或超过边界、或边界以下的状态。
用例设计原则：
- 输入条件规定值的范围，则应取刚达到这个范围的边界值，及刚刚超越范围边界值为测试输入
- 输入条件规定值的个数，则用最大及最小个数，比最小数少一，比最大数多一数为测试输入。
- 程序的规格说明输入域或输出域是有序集合，应选取集合的第一及最后一个元素为测试输入。
- 程序中使用了一个内部数据结构，应当选择这个内部数据结构的边界上的值作为测试输入。
区别性案例：
例子： 考虑一个要求用户输入年龄的软件功能，该年龄范围是 18 到 60 岁之间。我们可以使用等价类划分和边界值分析来设计测试用例：
-
等价类划分法：
- 选取三个等价类别：18 岁以下（无效数据）、18 到 60 岁之间的有效年龄、60 岁以上（无效数据）。
- 从每个等价类别中选择一个或多个测试用例，比如 17 岁、30 岁和 65 岁，来代表各自的类别。
-
距离边界值分析：
- 边界值包括 18、19、59 和 60 岁。除了这些边界值之外，还会考虑接近边界的值，比如 17、20、58 和 61 岁。
- 测试用例将会包括这些边界值及其附近的值，例如 18、19、20、58、59 和 60 岁等。
1.2.1.3 错误推测法
概念：基于经验和直觉推测程序中所有可能存在的各种错误，有针对性的设计测试用例的方法.
特点：good：与“探索式测试方法”的基本思想和理念是不谋而合的，敏捷开发模式下的投入产出比很高，被广泛应用。缺点：难以系统化，过度依赖个人能力。
错误推测方法分类:
- 输入数据测试方面
- 输入非法数据: 非法类型、非法范围/长度、非法格式
- 输入默认值：接受软件的默认值、键入空值、把默认值改为另一个值、把默认值改为另一个值，再变为空值
- 输入特殊字符（集）：根据被测软件所处的操作系统、程序设计语言、后台数据库以及具体业务等信息列出表格，进行讨论，标明哪些需要测试，哪些需要剔除。以及，通过复制粘贴强制输入程序不允许输入的数据.
- 注意错误信息检查：包括错误信息与错误要对应一致、错误信息不能为空、错误信息不能包含开发代码等等…
- 输出数据方面
- 同一个输入产生多种输出
- 验证输出结果的正确性
- 数据结构方面的错误推测
- 数据结构溢出：eg: 变量：上溢->值太大； 下溢->值太小
- 数组：上溢->数据量太多； 下溢->数据量太少
- 计算结果溢出：输入非法值或很小与很大数据，强制结果产生下溢或上溢
- 操作数和操作符不符
- 文件系统方面的错误推测
- 使文件系统超载， 适用于数据存储到硬盘中时；
- 测试方法：
- 创建满容量或近乎满容量的文件系统，然后强制执行各种通过输入或输出访问文件系统的操作。
- 打开足够多的文件，文件打开时会强制创建备份副本，从而占用双倍的存储空间。
- 使用工具 Canned Heat，模拟文件系统超载。
- 测试方法：
- 更改文件访问权限
- 使介质忙或不可用
1.2.1.4 因果图法
概念：考虑输入条件之间的相互组合/制约条件和内部逻辑模型的流程图，最终生成判定表。
适用：检查程序输入条件的各种组合情况。
测试设计流程：
- 分析软件规格说明描述中，输入条件（原因）或输入条件的等价类及输出条件（结果），并给每个输入和输出赋予一个标识符。
- 分析软件规格说明描述的语义，找原因与结果之间/原因与原因之间对应的关系，画出因果图
- 由于语法或环境限制，不会出现无效或非常规关系.。需表明特殊情况下，在因果图上用一些记号标明约束或限制条件。
- 把因果图转换为判定表。
- 把判定表的每一列拿出来作为依据，设计测试用例。
1.2.2 白盒测试方法
基本路径测试（Basis Path Testing）：
- 基本路径测试旨在执行程序中所有可能的独立路径。
- 主要关注于程序的控制流程图，目标是覆盖程序图中的所有独立路径至少执行一次。
逻辑覆盖（Logical Coverage）：
- 逻辑覆盖旨在测试执行期间代码中的结构被验证的程度。
逻辑覆盖方法分类：
发现错误的能力呈由弱到强的变化：
- 语句覆盖：每条语句至少执行一次。
- 判定覆盖：确保每个布尔表达式的每个条件为真和假至少一次。
- 条件覆盖：要求每个条件都取各种可能的值（真和假）至少一次。
- 判定/条件覆盖：同时满足判定覆盖条件覆盖。
- 条件组合覆盖：每个判定中各条件的每一种组合至少出现一次。
- 路径覆盖：覆盖程序中的所有可能路径，确保每个路径至少执行一次。
要求：
- 保证一个模块中的所有独立路径至少被使用一次。
- 对所有逻辑值均需测试 true 和 false。
- 在上下边界及可操作范围内运行所有循环。
- 检查内部数据结构以确保其有效性。
区别：
- 焦点不同：1）基本路径测试专注于覆盖程序中的所有可能路径；2）而逻辑覆盖侧重于衡量测试中逻辑结构的覆盖程度。
- 测试方法不同：1）基本路径测试涉及识别程序中的基本路径，并设计覆盖所有路径的测试用例；2）逻辑覆盖则是一种评估测试覆盖度的指标。
例子：
对于一个简单的程序，假设有一个 if-else 条件：
def example_function(a, b):
if a > 0:
return a
else:
return b
- 基本路径测试：控制流图可能包括两个路径，从函数入口到返回的两个可能路径。设计测试用例以覆盖这两个路径，例如测试 a > 0 和 a <= 0 的情况。
- 逻辑覆盖：针对条件覆盖和判定覆盖，确保测试覆盖 a > 0 和 a <= 0 两种情况，以及每种情况下的真和假。
1.3 测试步骤：
- 测试计划阶段：根据需求说明书，制定测试进度。
- 测试设计阶段：依据程序设计说明书，按照一定规范化的方法进行软件结构划分和设计测试用例。
- 测试执行阶段：输入测试用例，得到测试结果。
- 测试总结阶段：对比测试的结果和代码的预期结果，分析错误原因，找到并解决错误。
扫一扫
1253
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
