等价类划分法和边界值分析法
等价类划分法主要集中在分类，主要步骤为：
- 根据需求，大体上可以先划分为有效和无效两种
- 然后再细化相应的等价类
- 建立等价类表
- 生成测试用例
等价类和边界值的关系
- 边界值分析法作为对等价类划分法的补充，边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
- 边界值数据本质上是属于某个等价类的范围，测试时有时是一种冗余(正好等于，刚刚大于或刚刚小于边界的值)，但是为了更好的测试质量，边界值必须要单独进行测试，适当必要的冗余是可以接受的。
等价类划分和边界值分析法的适用场景
- 等价类划分：有数据输入(编辑框)的地方，可以使用等价类划分法。例如:用户登录、注册、新建、查询。
- 边界值分析法：有数据输入且存在取值边界或长度边界时，边界值法往往跟等价类划分法一起使用，从而形成一套较为完善的测试方案。
因果图法和判定表法
等价类法和边界值分析法，这两种方法只考虑了单个的输入条件，并未考虑输入条件的各种组合、输入条件之间的相互制约关系的场景。基于此短板，因果图法和判定表法应运而生。
因果图法的方法步骤
- 找出所有的原因，原因即输入条件或输入条件的等价类；
- 找出所有的结果，结果即输出条件；
- 明确所有输入条件之间的制约关系以及组合关系；哪些条件不能组合到一起，哪些条件可以组合到一起；
- 明确所有输出条件之间的制约关系以及组合关系；哪些输出结果不能同时输出，哪些输出结果可以同时输出
- 找出什么样的输入条件组合会产生哪种输出结果；
- 画出因果图；
- 把因果图转换为判定表/决策表；
- 为判定表中的每一列表示的情况设计测试用例
判定表法
方法原则
主要包含五部分：
- 条件桩：问题的所有条件
- 条件项：所有条件的取值组合
- 动作桩：所有可能的操作
- 动作项：在每一种条件取值组合的情况下，执行动作桩中的哪些动作
- 规则：一种条件取值组合与其对应的动作组合一种条件取值组合与其对应的动作组合(即判定表中贯穿条件项和动作项的一列)构成判定表的一个规则
方法步骤
- 1.列出所有的条件桩和动作桩(输入和输出)；
- 2.填入条件项(输入项)；
- 3.填入动作项，得到初始判定表；
- 4.简化判定表(合并相似规则(相同动作))。
总结
| 方法 | 因果图法/判定表法 |
|---|
| 核心 | 考虑输出条件对输入条件的信赖关系，即因果关系 | | 优点 | a.有助于用一个系统的方法选择出高效的测试用例集；b.通过将规格说明转换为布尔逻辑网络，就可以指出规格说明的不完整和不明确之处 | | 缺点 | a.针对条件组合数量庞大的场景，会产生大量的测试用例;b.通常它不能生成全部应该被确定的有效测试用例。 | | 适用场景 | 在界面中有多个控件，控件之间有组合或限制关系，不同的输入组合会对应不同的输出场景 |
正交试验法
因果图和判定表法在变量值很多、排列组合数量极大的场景下，会生成非常庞大且冗余的测试用例，此时我们很难对所有组合场景进行全量测试用例覆盖，基于此短板，正交试验法应运而生。
使用PICT生成正交试验测试用例
功能图法
因果图、判定表、正交试验主要是针对于不同条件输入输出的组合进行测试，但在实际需求中，也常会遇到需要对被测对象的状态流转进行验证的情况，此时前面几种方法将不再适用，对于这种状态转换类问题，功能图法则可大展身手。
核心思想
抽象出待测系统的若干状态以及状态之间的转换条件和转换路径，然后从状态迁移路径覆盖的角度设计测试用例。
方法步骤
1）分析需求，明确状态节点，具体关注以下几个信息
- 存在的状态;
- 状态之间的转换关系;
- 状态变化的触发条件。
2）梳理不同状态的转换，输出状态-条件表；
3）画出状态迁移图； - 定义初始状态；
- 为初始状态增加一次操作改变初始状态，增加新的状态；
- 为上一步产生的新状态增加一次操作，再增加新的状态；
- 循环直到没有新状态产生为止。
4）转换为状态迁移树；
结合广度优先遍历+深度优先遍历算法，遍历状态迁移图的每一条路径，得到状态迁移树。
5）从状态迁移树导出测试路径。
状态迁移树中根节点到每个叶子节点的路径即为一条测试用例。
总结
| 适用场景 | a.由于某种条件成立导致发生状态改变的情况；b.主要关注状态转移的正确性 |
|---|
| 优点 | a.通过状态图可以清晰掌握系统的整个交互过程;b.可保证每个状态的所有可达状态都覆盖到;c.通过验证给定条件内是否能够产生需要的状态变化，可检验出是否存在不可达的状态、不必要的状态或其他非法状态，以及非法的状态转移 | | 缺点 | 针对有效输入输出进行设计，所以无法覆盖无效路径和非法输入 | | 注意事项 | a.每种状态至少需要访问一次；b.重点测试最常见、最普遍的状态转换;c.其次测试最不常用的状态转换路径;c.单个状态之间的转换可通过结合其他用例设计方法保证覆盖全面;5.添加非法测试路径进行测试。(异常输入、状态和条件的非法组合) |
场景法
场景法概念
场景法是一种通过使用事件触发流程，对系统的功能点或业务流程进行描述的方法。对于同一事件不同的触发顺序和处理结果，可以形成不同的场景。
在日常工作中，针对同一业务需求可以模拟出不同场景，测试用例中对所有功能点及业务流程的覆盖，有利于测试人员设计测试用例，从而提高测试效果，使测试用例更容易理解和执行。
场景法设计层面
1）业务层面：需熟悉需求业务逻辑，并针对当前需求进行发散性思考。
2）技术层面：需分析出基本流和备选流，通过遍历所有基本流和备选流，可以覆盖完整的业务场景。
- 基本流：模拟用户正确的业务操作流程
- 备选流：模拟用户错误的业务操作流程
方法步骤
- 根据需求文档，梳理业务的流程图；
- 分析主干业务正常执行的流程——基本流；
- 分析出分支流程——备选流；
- 组合基本流、备选流，确定基本场景；
- 对每一个场景生成相应的测试用例；
- 对每一个测试用例确定测试数据值。
总结
- 缺点:只能验证业务流程，不能验证单点功能。一般先采用等价类划分、边界值分析、错误推断法、判定表法对单点功能进行验证，验证通过后再采用场景法进行业务流程的验证。
- 注意事项：主题清晰、逻辑无误、步骤简洁、场景唯一
错误推测法
在前面几篇文章中，为大家介绍的都是系统的方法论，但在实际需求测试的过程当中，受到外部环境及业务逻辑的影响，比如涉及多需求耦合、浏览器缓存堆积等情况，仅针对当前需求设计出的测试用例就会有覆盖不全的问题，此时就需要借助以往的经验进行反向错误推测，辅助其他方法对测试用例进行完善。在本篇文章中，首先会对错误推测法的思路进行介绍，并对本系列文章中讲解的所有测试用例设计方法进行归纳总结，给出具体的可应用业务场景，便于大家在遇到同类场景时可快速筛选出适用的方法，将测试用例设计方法论真正落地到日常工作中。
定义
是基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。
设计思路
- 总结归纳以往的测试版本，找出共通的易错点
- 借助网络搜索，参考网上的测试设计要点
- 站在用户的角度去考虑非常规操作
- 编写测试场景标准库来完善错误推测方法
总结
| 方法 | 错误推测法 |
|---|
| 优点 | 充分发挥热的直觉和经验;集思广益;方便使用;快速切入 | | 缺点 | 难以知道测试的覆盖率;可能丢失大量位置的区域;带有主观性且难以复制;只能作为测试设计的补充，不能单独用来设计测试用例 | | 适用场景 | 先用其他方法设计测试用例，再使用错误猜测法补充用例 |
|