目录
一、测试流程
二、测试用例
2.1概念
2.2用例编写格式
三、设计测试点
3.1等价类
3.1.1概念
3.1.2案例
3.1.3适用场景
3.1.4执行用例
3.2边界值
3.2.1概念
3.2.2案例
3.2.3使用场景
3.3判定表
3.3.1判定表使用原因
3.3.2概念
3.3.3案例
3.3.4使用场景
3.4场景法
3.4.1概念
3.4.2案例
3.4.3使用场景
四、缺陷管理
4.1概念
4.2缺陷编写
4.3缺陷管理工具
五、抓包
5.1抓包目的
5.2抓包概念
5.3抓包知识
5.4抓包工具
一、测试流程
需求分析：
说明：根据产品需求文档，提取出规则要求
提取规则要求的目的：
- 明确软件有哪些功能和要求
- 为设计测试点做准备
设计测试点：
测试点：要进行验证的点，根据需求规则设计测试点。
设计测试点的目的：
- 防止测试时有遗漏
- 为编写测试用例做准备
测试用例：
说明：将测试点转化为测试执行的文档。
编写用例的目的：
- 指导测试点正确测试实施
- 为执行测试做准备
用例执行：
说明：执行用例就是执行测试。
缺陷管理：
说明：当执行用例结果和预期结果不符时为缺陷，就需要对缺陷进行管理。
缺陷管理目的：
- 测试的目的就是减少软件缺陷（提交缺陷——>等待修复——>验证缺陷）
- 为测试报告做准备
测试报告：
说明：对于本次执行测试缺陷进行分析统计，对于本次测试实施进行总结。
主要内容：
- 缺陷统计
- 缺陷分析
- 遗留缺陷
- 测试总结
二、测试用例
2.1概念
用例：用户使用的案例
测试用例：执行测试时用户案例
英文：Test Case
目的：保证测试点的正确执行
2.2用例编写格式
说明：用例编写格式一般由八大要素组成。
编写示例
微信登录测试点：
- 登录成功
- 密码错误，登录失败
三、设计测试点
3.1等价类
3.1.1概念
3.1.2案例
（验证QQ账号的合法性）
要求：6~10位自然数
步骤：
1.明确需求
- 内容：自然数（0、1、2······）
- 长度：6-10位
2.确定有效和无效等价类
- 有效等价:6-10位
- 无效等价：①小于6位 ②大于10位 ③非自然数
3.提取数据编写测试用例
- 有效等价：8位（12345678）
- 无效等价：①小于6位——5位（12345） ②大于10位——11位（12345678901） ③非自然数
3.1.3适用场景
针对：需要有大量数据测试输入，但是没法穷举测试的地方。
- 输入框
- 下拉列表
- 单选复选框
典型代表：页面输入框类测试
3.1.4执行用例
- 当执行结果和预期结果不一致，则为缺陷。
- 发现缺陷需要进行缺陷管理（提交——>开发修复——>测试验证——>关闭缺陷）
示例：（验证某城市电话号码正确性）
要求：
- 区号：空或者是三位数字
- 前缀码：非“0”且非“1”开头的三位数字
- 后缀码：四位数字
步骤：
1.明确需求
2.确定有效和无效等价类
3.提取数据编写测试用例
4.执行用例
3.2边界值
3.2.1概念
说明：选取正好等于、刚好大于、刚好小于边界的值作为测试数据。
边界值法设计用例步骤：
- 明确需求
- 确定有效和无效等价类
- 确定边界范围值
- 提取数据编写测试用例
3.2.2案例
需求：通过边界值法验证标题长度的合法性
要求：标题长度大于0，小于等于30个字符（0<标题长度<=30）
步骤：
1.明确需求
- （0，30]
2.确定有效和无效等价类
- 有效：4
- 无效：-1,31
3.确定边界值
- 上点：0,30
- 离点：-1,1,39,31
- 内点：10
4.提取数据编写用例
优化：
- 上点：必选
- 内点：必选
- 离点：开内闭外
5.执行用例
3.2.3使用场景
- 在等价类的基础上针对有边界范围的测试数据输入的地方（重点关注边界）
- 常见词语描述：大小、尺寸、重量、最大、最小、至多、至少等修饰语
- 典型代表：有边界范围的输入框类测试
示例：（验证QQ号的合法性）
要求：6~10位自然数
步骤：
1.明确需求
2.确定有效和无效等价类
3.确定边界值
4.提取数据编写用例
5.用例执行
3.3判定表
3.3.1判定表使用原因
案例：验证“若用户欠费或者关机，则不允许被叫”功能测试
说明：
- 等价类、边界值分析法主要关注单个输入条件的测试
- 并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约关系的测试
3.3.2概念
1.定义：是一种以表格形式表达多条件逻辑判断的工具
2.组成：
- 条件桩：列出问题中的所有条件，列出条件的次序无关紧要。
- 动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束。
- 条件项：列出条件对应的取值，所有可能情况下的真假值。
- 动作项：列出条件项的各种取值情况下应该采取的动作结果。
3.规则
- 判定表中贯穿条件项和动作项的一列就是一条规则
- 假设有n个条件，每个条件的取值有两个（0,1），全组含有2的n次方种规则
4.判定表设计用例步骤
| 1.明确需求 | |
| 2.画出判定表 | 列出条件桩和动作桩 填写条件项，对条件进行全组合 根据条件项的组合确定动作项 简化合并相似规则（有相同的动作） |
| 3.根据规则编写测试用例 |
3.3.3案例
1.需求分析
- 如果金额大于500元，又未过期，则发出批准单和提货单
- 如果金额大于500元，但过期了，则不发批准单与提货单
- 如果金额小于等于500元，则不论是否过期都发出批准单和提货单
- 在过期的情况下不论金额大小还需要发出通知单
2.画判定表
3.设计测试用例
4.执行用例
3.3.4使用场景
- 有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系。
- 判定表一般适用于条件组合数量较少的情况（比如4个条件以下）
示例：（文件修改规则）
1.明确需求
- 输入的第一列字符必须是A或B
- 第二列字符必须是一个数字
- 如果第一列字符不正确，则给出信息L
- 如果第二列字符不正确，则给出信息M
- 如果两列字符输入正确，则修改文件成功
2.画判定表
3.设计测试用例
4.用例执行
3.4场景法
3.4.1概念
说明：场景法也可以叫做流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。
意义：
- 用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用。
- 测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试。
3.4.2案例
ATM机取款流程
ATM机取款流程——流程图
设计测试用例
用例执行
3.4.3使用场景
根据实际的应用场景来测试业务用例可以使用场景法。
四、缺陷管理
4.1概念
1.定义：软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug。
2.缺陷评判标准：
3.缺陷产生原因：
需求阶段：需求描述不易理解，有歧义、错误等
设计阶段：设计文档存在错误或者缺陷
编码阶段：代码出现错误
运行系统：软硬件系统本身故障导致软件缺陷
4.软件缺陷的生命周期：
5.软件缺陷的类型：
4.2缺陷编写
1.缺陷的核心内容
2.缺陷描述
案例：
3.缺陷的跟踪流程
4.缺陷的提交流程
5.缺陷的提交要素
6.提交缺陷的注意事项
4.3缺陷管理工具
1.禅道
禅道项目管理软件 - 开源、免费的项目研发测试管理工具 (zentao.net)
https://www.zentao.net/特点：
- 国产、免费、开源、简单、轻量级
- 三管融合（产品管理、项目管理、质量管理）
2.禅道的使用用户
3.禅道使用流程
五、抓包
5.1抓包目的
- 功能测试时跳过ui界面验证，验证后端程序处理能力。（如：请求支付100元，通过抓包修改请求价格0.1元，查看后端程序是否能正常处理）
- 分析前端bug还是后端bug。（如：ui显示数据错误，提交bug时需要指定提交人，那是提交给前端开发还是后端开发？）
- 弱网测试（如：app应用模拟4G、3G网络）
- 接口测试时，缺乏接口描述文档，需要抓包获取。（如：查看支付宝请求信息）
5.2抓包概念
说明：通过工具抓取前端与后端的通信内容
5.3抓包知识
- 抓包操作（http、https）
- 断点操作-拦截修改（请求、响应）
- 弱网测试
5.4抓包工具
- fidder（windows）断点、弱网、录制请求和响应
- Charles（mac、windows）断点、弱网、录制请求和响应
- 浏览器开发者工具（查看请求和响应首选）
