对穷举场景设计测试点
等价类划分法
说明|分类|步骤
一种典型的、重要的黑盒测试方法，是指某个输入域的子集合，在该子集合中，所有的输入数据对于揭露软件中的错误都是等效的。
- 有效等价只取其一，每个无效集合取1个
- 设计一个新的测试用例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步直到所有的有效等价类都被覆盖为止；设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步直到所有的无效等价类都被覆盖为止
适用场景
通过等价类把穷尽测试转化为有限的有效测试
举例
- 用户名长度6~18，必须以字母数字下划线两者或两者以上组合
- 微信红包
- 按数据范围划分：不超过两位小数的值
对限定边界规则设计测试点
边界值分析法
边界范围节点
内点一般取居中的点
最多7条
边界值法设计用例步骤
案例优化
适用场景
单个输入框，常用的方式：边界+等效类
对多条件依赖关系设计测试点
因果图法
使用场景：当需求中存在多个条件，不同条件中存在不同的结果，就会使用因果图法。
分别列出需求中的因子（条件）和结果
判定表法
- 等价类边界值分析法主要关注单个输入类条件的测试
- 并未考虑输入条件之间的各种组合、输入条件于输出结果之间有相互制约关系的测试
- 判定表法要求多个条件之间有依赖或制约关系
判定表定义及组成部分
判定表=条件桩（需求中的因子）+动作桩（需求中的结果）+条件项（不同因子的组合）+动作项（不同因子造成结果的组合）
判定表法设计用例步骤
使用场景
如果条件超过4个，就不适合覆盖所有条件，应采用正交法来解决。
正交实验法
利用因果图设计测试用例时，作为输入条件的原因和输出结果之间的因果关系，有时候很难从软件需求规格说明中得到。往往因果关系非常庞大，提取的用例数目多的惊人，则可以采用正交实验设计方法。
正交表
$$
L_n(m^k)
$$
n是表的行数，也就是需要测试组合的次数
k是表的列数，表示控件的个数（因素的个数，或因子个数）
m是每个控件包含的取值个数（各因素的水平数，即各因素的状态数）
如
$$
L_9(3^4)
$$
有4个控件每个控件有3个取值
9为需要测试的组合个数
对于项目业务设计测试点
场景法
对项目的业务流程功能用例的设计基于场景法来进行设计
通过场景描述的业务流程（业务逻辑），也包括代码实现逻辑，设计用例来遍历场景（路径），验证软件系统功能的正确性
正常流/基本流：从起点开始，通过各个路径，在最后的节点结束。模拟用户正常操作的流程
异常流/错误流/备选流：从起点开始，可能在某个节点结束或者会返回上一节点，模拟用户错误的操作的流程。
流程图
业务流程图是基于场景法设计测试用例的依据，由产品去提供业务流程图
- 覆盖业务测试需要使用流程图法
- 先测试业务、再测试单功能、单模块、单页面
使用场景
业务用例必须先测
案例3-1：
错误推测法（反推法）
- 通过经验推测程序中所有可能出现的问题，主要依靠经验、知识、直觉
- 根据经验列举出可能出现问题的清单，根据清单分析问题可能原因，推测发现缺陷。
- 探索性测试
场景
- 当项目用例都执行完毕且BUG修复完成，离上线还有一段时间，在这段时间中可以使用错误推测法复测主要业务或未测试的功能
白盒测试
- 语句覆盖：可执行语句至少被执行一次；
- 判定覆盖：每个判断的取真分支和取假分支至少经历一次；
- 条件覆盖：每个条件的可能取值一次；
- 判定条件覆盖：每个判定真假各一次，每个判定中的条件各取一次
- 条件组合覆盖：每个条件的所有可能都至少出现一次，并且判定结果至少出现一次 ；与条件覆盖的区别：他不是简单要求每个条件出现“真”和“假”两种结果，而是要求这些结果所有可能至少出现一次；判定中所有条件的总和
- 路径测试：执行所有可能的执行路径；
- 基本路径测试（判断/条件覆盖）： 路径测试执行了每个路径，每个判定的结果肯定经历过一次
- 循环测试：是一种测试方法，其核心思想是多次重复执行相同或类似的测试用例，以发现软件系统在长时间运行或多次执行下的稳定性、性能、内存管理等方面的问题。循环测试通常用于评估软件系统在长时间运行或重复执行下的表现，并且可以帮助识别潜在的内存泄漏、资源泄漏、性能下降等问题。
用例评审
设计完用例后要进行用例评审，评审要检测用例的覆盖率和检查是否错写测试用例。评审分为组内和组外评审用例评审通过之后进行用例归档，再进入用例执行阶段。
笔试面试题
用例需要评审么？紧急情况用例也需要评审么？
需要评审，紧急情况也需要评审，可能不通过会议进行评审，会通过邮件发给相关人员
如果被测项目很紧急，来不及写用例，怎么办？
check list，使用xmind列出测试点，根据检查点进行测试，测试完之后时间足够的时候补充用例——后期要进行回归测试，也可以知道当时是怎么覆盖的
遇到隐形需求如何写用例（需求不明确）
熟悉当前的功能，参考成熟产品，站在用户角度挖掘需求，去和产品沟通
用例有没有优先级？如果一定要有优先级，依据什么来确定呢？
有，根据功能，使用的场景是不是重要的，核心的
如何去编写测试用例？（以项目为基础来讲一个小模块用例设计，手机号）
编写测试用例会用到什么方法？
先去了解项目的业务流程，对于业务流程的用例使用场景法写，针对某些输入功能用等价类边界值来进行设计，需求里面存在多个条件多个组合，使用因果图判定表设计
web测试
测试点：前端页面发布上线之前需要检查（描述不恰当的文字出现）所有注释或去除注释
img图片必须要有title属性（悬停和未加载显示）
按钮测试点：统一使用value赋值