本文转自测试人社区，原文链接：https://ceshiren.com/t/topic/31921
一，黑盒测试方法论
1，等价类
1.1 定义
- 等价类划分是一种重要的、常用的黑盒测试方法
- 不需要考虑程序的内部结构，只需要考虑程序的输入规格即可
- 它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性
- 用户所有可能输入的数据，划分成了若干个子集，然后从每一个子集当中选取少数具有代表性的数据作为测试用例
- 在有限的测试资源的情况下，用少量有代表性的数据得到比较好的测试效果
1.2 等价类分类
- 有效等价类：指符合《需求文档》，输入合理的数据集合
- 无效等价类：指不符合《需求文档》，输入不合理的数据集合
1.3 设计步骤
- 先划分等价类：找出所有可能的分类
- 确定有效等价类：需求中的条件
- 确定无效等价类：与条件相反的情况，再找到特殊情况
- 从各个分类中挑选测试用例数据
2，边界值
2.1 定义
- 边界值分析法是一种很实用的黑盒测试用例方法，它具有很强的发现故障的能力
- 边界值分析法是作为对等价类划分法的补充，测试用例来自等价类的边界
2.2 边界值确定
- 上点：边界上的点
- 离点：离上点最近的点
- 内点：在输入域内任意一个点
- 选取正好等于、刚好大于或刚好小于边界值作为测试数据
2.3 边界值总结
- 确定边界情况
- 选取正好等于、刚刚好大于或刚刚好小于边界值作为测试数据
- 确定各个值的等价类
3，判定表
3.1 定义
- 因果图只是一种辅助工具，通过分析最终得到判定表，再通过判定表编写测试用例
- 画因果图非常麻烦，影响测试效率，可以直接写判定表，进而编写测试用例
3.2 组成
- 条件桩：问题的所有条件
- 动作桩：问题的所有输出
- 条件项：针对条件桩的取值
- 动作项：条件项的各种取值情况下的输出结果
3.3 设计步骤
- 列出所有的条件桩和动作桩
- 确定规则数：条件取值个数^条件数
- 填入条件项
- 填入动作项。得到初始判定表
- 简化判定表
4，场景法
4.1 定义
- 场景法就是模拟用户操作软件时的场景，主要用于测试系统的业务流程
- 基本流：按照正确的业务流程来实现的一条操作路径
- 备选流：导致程序出现错误的操作流程
4.2 用例设计步骤
- 根据需求规格说明，画出功能模块流程图；
- 根据流程图，描述出程序的基本流及备选流；
- 根据基本流和备选流生成不同的场景，构造场景列表；
- 对每一个场景生成相应的测试用例；
- 对生成的所有测试用例重新复审，去掉多余的测试用例；
- 测试用例确定后，为每一个测试用例确定测试数据值
5，因果图
5.1 定义
- 因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法
- 它适合于检查程序输入条件的各种组合情况
- “因” —— 输入条件
- “果” —— 输出结果
5.2 适合场景
- 描述多种条件的组合
- 产生多个动作
5.3 因果图中的基本符号
- 恒等：若原因出现，则结果出现；若原因不出现，则结果也不出现
- 非：若原因出现，则结果不出现；若原因不出现，则结果出现
- 或：有多个原因。若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现
- 与：有多个原因。若几个原因都出现，则结果才出现；若其中一个原因不出现，则结果不出现
5.4 因果图中的约束条件
- 互斥 E：a、b、c 只能有一个成立，但是可以都不成立
- 包含 I：a、b、c 中至少有一个成立
- 唯一 O：a、b、c 有且仅有一个成立
- 要求 R：如果 a 成立，则要求 b 必须也成立，其他的不约束
- 屏蔽 M：如果 a 成立的时候，强制 b 不成立，其他的不约束
5.5 因果图法基本步骤
- 找出所有的输入条件（因）
- 找出所有的输出条件（果）
- 明确所有输入条件之间的制约关系以及组合关系
- 明确所有输出条件之间的制约关系以及组合关系
- 找出什么样的输入条件组合会产生哪种输出结果
- 把因果图转换成判定表
- 为判定表中的每一列表示的情况设计测试用例
6，正交法
6.1 定义
简介 正交法(0rthogonalArray)是一种设计实验方案和测试用例的统计方法，旨在通过有限次试验来研究多个因素对结果的影响，同时尽可能减少试验次数。正交法的主要特点是通过一种合理的方式选择一组试验参数的组合，以实现对所有可能的参数组合进行有效的覆盖，从而节省试验资源和成本。
正交法的核心思想是在所有可能的因素组合中，选择一组互相正交的因子水平组合，以尽可能少的试验次数来观察所有因素的影响。
正交表是一种特制的表格，一般用 Ln(m^k)表示，L代表是正交表，n代表试验次数或正交表的行数，k代表最多可安排影响指标因素的个数或正交表的列数，m 表示每个因素水平数。
其中，因素是影响试验结果的一个变量或因素，可以是独立变量、处理水平或参数。因素可以是产品的属性、工艺参数、环境条件等。水平是每个因素可能的取值或状态。例如，一个因素可以有多个不同的水平，如高、中、低等。
6.2 使用场景及操作步骤
使用场景
- 多参数系统：当系统具有多个输入参数，而且这些参数之间存在相互影响时，正交法特别有用。
- 多条件覆盖：当需要覆盖不同的条件组合，以测试系统在不同情况下的行为。
- 资源有限：当测试资源有限，需要在较小的测试用例集中获得尽可能广泛的覆盖。
常用正交表
正交表根据参数数量和取值范围的不同，有多种等级和类型可供选择。选择适当的正交表可以有效地设计测试用例，覆盖各种参数组合，以达到最佳的测试覆盖和效率
操作步骤 1.确定测试参数和取值范围:识别系统的输入参数和条件。这可能包括各种参数、设置、状态等。 2.确定正交表和参数等级:根据参数数量和取值范围，选择合适的正交表 3.设计正交表:使用正交表工具，根据系统的输入参数和条件构建正交表， 4.生成测试用例:从正交表中选择测试用例，以覆盖尽可能多的参数组合。确保所选用例能够测试系统的各个方面。
7，基于模型的测试
二，测试用例设计
1，用例组成（以我测过的项目为例）
- 需求名称
- 一级模块
- 二级模块
- 用例标题
- 优先级
- 前提条件
- 测试步骤
- 期望结果（预期结果）
2，用例设计方法的选择
- 任何情况下，都需要采用等价类划分法，将无限测试变成有限测试
- 在规定了数据范围的情况下，必须采用边界值分析法
- 如果需要关注它的主要功能和业务流程、业务逻辑是否正确实现，考虑使用场景法
- 如果含有输入条件的组合情况，考虑选用因果图和判定表法
- 采用错误推断法再追加测试用例
3，测试用例编写步骤
- 划分功能模块
- 正向功能验证
- 单个功能项验证
- 功能之间交互验证
- 隐形需求
4，测试用例的粒度
- 测试用例可以写的很简单，也可以写的很复杂
- 最简单的测试用例是测试的纲要，仅仅指出要测试的内容
- 测试用例写的过于简单，则可能失去了测试用例的意义
- 测试用例写得过于复杂或详细，会带来两个问题：
- 效率问题
- 维护成本问题
5，用例评审
- 测试用例的本身的描述是否清晰，是否存在二义性
- 测试用例内容是否正确，是否与需求目标相一致
- 测试用例的期望结果是否确定、唯一
- 测试用例是否覆盖了所有的需求
- 测试用例是否具有可执行性
- 是否从用户层面来设计用户使用场景和业务流程的测试用例
- 场景测试用例是否覆盖最复杂的业务流程
- 用例设计是否包含了正面、反面的用例
三，面试测试用例设计
1，设计思路
- 需求分析
- 明确需求
- 和面试官交流需求细节
- 界面
- 页面布局设计和产品原型图一致
- 页面文案正确
- 功能
- 正向功能验证
- 单个功能项验证
- 功能之间交互验证
- 接口验证
- 易用性
- 功能操作是否简便
- 页面布局是否美观合理
- 提示语相关信息是否易于理解
- 兼容性
- APP
- 平台
- 厂商
- 系统版本
- 屏幕大小与分辨率
- WEB
- 浏览器
- 操作系统
- 分辨率
- 性能
- 服务器性能测试
- APP 客户端性能测试
- 安全性
- 注入攻击
- 加密
- 权限
- APP 测试要点
- 网络
- 中断
- 系统权限
- WEB 测试要点
- 链接测试
- 多个浏览器同时访问
四，白盒测试方法
1，白盒测试的度量
- 根据待测产品的内部实现细节来设计测试用例
- 白盒测试的执行手段是可以涵盖单元测试、集成测试
- 使用代码覆盖率作为白盒测试的主要度量指标
2，代码覆盖率常见概念
- 语句覆盖：每行代码都要覆盖至少一次
- 判定覆盖：判定表达式的真假至少覆盖一次
- 判定/条件覆盖：判定覆盖与条件覆盖都必须覆盖
- 条件组合覆盖：判定表达式中的所有条件组合都需要覆盖
- 分支覆盖：控制流中的每条边都要被覆盖一次
- 路径覆盖：所有的路径都要尽量覆盖
- 指令覆盖：一行代码会被编译为多条指令，尽可能的覆盖所有指令
- 方法覆盖：每个方法至少要被覆盖一次
- 类覆盖：每个类至少被覆盖一次
3，覆盖率统计的工具
- emma
- cobertura
- jacoco
4，插桩原理
- 对jvm的字节码插桩
- 基于block插桩
- 计算覆盖的代码块
5，流程覆盖
- 利用代码执行流代表流程
- 流程覆盖用路径覆盖率表达
- 对流程进行裁剪获得一个适合业务的小规模的业务子集
- 流程覆盖率=测试经过的路径/业务子集路径
6，精准化测试
- 代码调用链与黑盒测试用例的关联
- 根据代码变更自动分析影响范围
- 黑盒测试过程中借助代码流程覆盖数据指导探索式测试
- 利用线上数据推导有效测试用例
- 代码流程分析与覆盖率统计
