目标

• 能对穷举场景设计测试点（等价类划分法）
• 能对限定边界规则设计测试点（边界值分析法）
• 能对多条件依赖关系进行设计测试点（判定表）
• 能对于项目业务进行设计测试点（场景法）
• 错误推测法

等价类划分法

穷举场景

案例：QQ号码和城市电话（上节课的案例）

等价类总结

针对需要有大量数据测试输入，但是没法穷举测试的地方

• 输入框

• 下拉列表

• 单选复选框

（典型代表：页面的输入框类测试）

边界值分析法

使用边界值解决边界位数限制问题

1、边界值范围节点

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

（不考虑类型的情况下最多7条）

• 上点：边界上的点（正好等于）（绿色）
• 离点：距离上点最近的点（刚好大于、刚好小于）（黄色）
• 内点：范围内的点（区间范围内的数据）（一般取中间值）（蓝色）

2、边界值法设计用例步骤

• 明确需求
• 确定有效和无效等价类
• 确定边界范围值
• 提取数据，编写测试用例

3、小结

• 有关范围限制，最多7条用例（暂时未优化）
• 边界值能解决位数限制问题，但是不能拿解决类型问题（要结合等价类）

边界值（案例-标题）

需求：通过边界值法验证标题长度的合法性

要求：标题长度大于0，小于等于 30个字符

——步骤

1、明确需求

2、确定有效和无效等价（类型）

• 有效等价：大于0，小于等于30个字符
• 无效等价：小于0，大于30个字符

3、确定边界范围

• 上点：边界上的点（0未，30位）
• 离点：距离上点最近的点（1位，29位，31位）
• 内点：范围内的点（15位）

4、提取数据编写用例

边界值优化及总结

结论：7个优化为5个

• 上点：必选（不考虑区间开闭）
• 内点：必选（建议选择中间范围）
• 离点：开内闭外（考虑开闭区间，开区间（无等号）选择内部离点，闭区间（有等号）选择外部离点）

——边界值使用场景

• 在等价类的基础上针对有边界范围的测试数据输入的地方（重点关注边界）
• 常见词语描述：大小、尺寸、重量、最大、最小、至多、至少等修饰词语
• 典型代表：有边界范围的输入框类测试

——小结

单个输入框，常用的方式：等价类+边界值

面试题：最常见的用例设计方法有哪些（等价类、边界值）

判定表

案例：验证“若用户欠费或者关机，则不允许主被叫”功能的测试

说明：（1）等价类边界值分析法主要关注单个输入类条件的测试；（2）并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约关系的测试

判定表介绍

定义：：是一种以表格形式表达多条件逻辑判断的工具

组成：

• 条件桩：列出问题中的所有条件，列出条件的次序无关紧要
• 动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束
• 条件项：列出条件对应的取值，所有可能情况下的真假值
• 动作项：列出条件项的、各种取值情况下应该采取的动作结果

规则：

• 判定表中贯穿条件项和动作项的一列就是一条规则
• 假设有n个条件，每个条件的取值有两个（0,1），全组合有2的n次方种规则

判定表使用场景

1、有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系

2、判定表一般适用于条件组合数量较少的情况（比如4个条件以下）

判定表设计用例步骤

1、明确需求

2、画出判定表

• 列出条件桩和动作桩
• 填写条件项，对条件进行全组合
• 根据条件项的组合确定动作项
• 简化、合并相似规则（有相同的动作）

3、根据规则编写测试用例

判定表（订单案例）

判定表（字符案例）及总结

需求：

1）输入的第一列字符必须是A或B

2）第二列字符必须是一个数字

3）如果第一列字符不正确，则给出信息L

4）如果第二列字符不正确，则给出信息M

5）如果两列字符输入正确，则修改文件成功

——总结

• 多条件之间有依赖关系，使用判定表来进行测试覆盖
• 判定表一般适合4个以内条件依赖关系
• 如果条件超过4个，就不适合覆盖所有条件，应采用正交法来解决

场景法（流程图法）

流程图介绍

流程图定义：使用标准图形和箭头来表达程序或业务的走向（作用：梳理业务用例）

——流程图对测试人员的作用

• 能够看懂流程图，设计业务用例
• 当需求文档信息补全时，能够根据需求，梳理出流程

业务用例是根据流程图来梳理的，需要先了解流程图

业务测试覆盖

1、覆盖业务测试，需要使用流程图法

2、先测试业务，再测试单功能、单模块、单页面

场景法介绍

**说明：**场景法也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程图路径来设计测试用例

意义：

• 用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用
• 测试人员角度：平时测试的都是单个功能点进行测试，任意忽略多个功能的组合测试

**适用场景：**根据实际的应用场景，来测试业务用例（必须先测），可以使用场景法

案例（AIM机取款流程）

• 业务图：
  

• 流程图：
  

• 测试用例：
  

错误推荐法

定义：通过校验推测系统可能出现的问题

思想：根据经验列举出可能出现问题的清单，根据清单分析问题可能原因，推测发现缺陷

场景：

• 时间紧任务量大时，根据之前项目类似经验找出易错的模块重点测试
• 实践宽裕通过该方法列出之前出现问题较多的模块再次测试

当项目测试用例都执行完毕，且BUG修复完成，离上线还有一段时间，在这段时间啊中可以使用错误推荐法复测主要业务或测试未覆盖的功能

（比如项目12点上线，你6点已经根据测试用例测完项目了并且bug解决完了，在6点到12点这个期间你就可以使用错误推荐法去对重点业务进行覆盖）

——面试：时间紧任务量大的情况下你怎么进行测试工作

由于时间紧任务大，先不考虑写测试用例，找开发和产品沟通确认好最重要的业务模块对其进行覆盖，根据进度安排把最主要的业务覆盖后再去测试下一级的次要业务，通过正向再逆向以此类推的方式加班加点地把测试工作做好。

总结