一、基础概念
【学习目标】
软件测试的定义
7种测试分类的区别
质量模型的重点5项
测试流程的6个步骤
测试模板8个要素
认识软件及测试
什么是软件：控制计算机硬件工作的工具
软件基本组成：客户端、服务器、数据库
软件产生过程：需求产生-》需求文档-》设计效果图-》产品开发-》产品测试-》部署上线
什么是软件测试：使用技术手段验证软件是否满足使用需求
软件测试目的：减少软件缺陷（bug），保障软件质量
测试主流技能
功能测试：主要验证程序的功能是否满足需求
自动化测试：使用代码或工具代替手工，对项目进行测试
接口测试：使用代码或工具对服务端提供的接口进行测试
性能测试：模拟多人使用软件，查找服务器缺陷
常见的测试分类
1.按测试阶段划分
单元测试：针对程序源代码进行测试
集成测试：针对程序接口进行测试
系统测试：针对程序功能、非功能(如兼容性、文档等)进行测试
验收测试：使用不同用户 (内测、公测)进行测试
2.按代码可见度划分
黑盒测试：不关注源代码，针对程序界面功能进行测试
灰盒测试：针对程序部分代码进行测试(接口)
白盒测试：针对程序源代码进行测试
3.专项测试
性能测试
安全测试
测试模型-质量模型
1.质量模型：衡量一个优秀软件的维度（8个方面），其中功能、性能、兼容、易用、安全是最重要的5个维度
#性能补充一点，达到20w的时候服务器资源占用情况
软件测试流程
测试用例
1、什么是用例
用户实际使用的案例
2、什么是测试用例
为测试项目而设计的执行文档
3、测试用例的作用
防止漏测
执行测试的标准，不仅仅关注成功失败，还有用户角度关注的问题
4、用例设计编写格式
用例编号：项目_模块_编号
用例标题：预期结果(测试点)
模块/项目：所属项目或模块
优先级：表示用例的重要程度或者影响力P0~p4(P0最高,用户使用最频繁的用例)
前置条件：要执行此条用例，有哪些前置操作
测试步骤：描述操作步骤
测试数据：操作的数据，没有的话可以为空
预期结果：期望达到的结果+不同用户的隐性结果（比如购物平台卖家、买家、平台看到的结果可能不同）
案例：根据以下测试点编写用例
需求：QQ登录(4条)
1、账号为空
2、账号未注册
3、密码为空
4、密码错误
|
用例编号 |
用例标题 |
模块/项目 |
优先级 |
前置条件 |
测试步骤 |
测试数据 |
预期结果 |
|
QQ_login_001 |
登录失败(账号为空) |
登录 |
p1 |
1、打开登录界面 2、网络正常 |
1、输入账号 2、输入密码 3、点击登录按钮 |
1、账号：空 2、密码：123456 |
登录失败，提示账号不可为空 |
|
QQ_login_002 |
登录失败(账号未注册) |
登录 |
p1 |
1、打开登录界面 2、网络正常 3、账号未注册 |
1、输入账号 2、输入密码 3、点击登录按钮 |
1、账号：未注册账号 2、密码：123456 |
登录失败，提示账号不存在 |
|
QQ_login_003 |
登录失败(密码为空) |
登录 |
p1 |
1、打开登录界面 2、网络正常 3、账号已注册 |
1、输入账号 2、输入密码 3、点击登录按钮 |
1、账号：已注册账号 2、密码：空 |
登录失败，提示密码不可为空 |
|
QQ_login_004 |
登录失败(密码错误) |
登录 |
p1 |
1、打开登录界面 2、网络正常 3、账号已注册 |
1、输入账号 2、输入密码 3、点击登录按钮 |
1、账号：已注册账号 2、密码：错误密码 |
登录失败，提示密码错误 |
二、测试设计
【学习目标】
1.能对穷举场景设计测试点
2.能对限定边界规则设计测试点
3.能对多条件依赖关系进行设计测试点
4.能对于项目业务进行设计测试点
等价类划分法-解决穷举的问题
说明：在所有测试数据中，具有某种共同特征的数据集合进行划分
分类：1.有效等价类:满足需求的数据集合 2.无效等价类:不满足需求的数据集合
步骤：1.明确需求 2.确定有效和无效等价类 3.提取数据编写测试用例
适用场景：需要有大量数据测试输入，但是没法穷举测试的地方，如输入框、下拉列表、单选复选框。典型代表：页面的输入框类测试
总结：
案例：需求：验证QQ号码的合法性，要求6~10位自然数
1).明确需求：长度：6~10位 类型：自然数
2).有效类：8位自然数 无效类：3位自然数、12位自然数、8位非自然数、为空
3).提取数据编写测试用例：12345678；123；123456789012；1234567A；空
|
用例编号 |
用例标题 |
模块/项目 |
优先级 |
前置条件 |
测试步骤 |
测试数据 |
预期结果 |
|
QQ_001 |
QQ合法(8位自然数) |
QQ账号 |
p0 |
打开QQ验证程序 |
1、输入账号 3、点击验证按钮 |
账号：12345678 |
提示QQ合法 |
|
QQ_002 |
QQ不合法(3位自然数) |
QQ账号 |
p1 |
打开QQ验证程序 |
1、输入账号 3、点击验证按钮 |
账号：123 |
提示QQ不合法 |
|
QQ_003 |
QQ不合法(12位自然数) |
QQ账号 |
p1 |
打开QQ验证程序 |
1、输入账号 3、点击验证按钮 |
账号：123456789012 |
提示QQ不合法 |
|
QQ_004 |
QQ不合法(8位非自然数) |
QQ账号 |
p1 |
打开QQ验证程序 |
1、输入账号 3、点击验证按钮 |
账号：1234567A |
提示QQ不合法 |
|
QQ_005 |
QQ不合法(为空) |
QQ账号 |
p1 |
打开QQ验证程序 |
1、输入账号 3、点击验证按钮 |
账号：空 |
提示QQ不合法 |
案例：需求: 验证某城市电话号码正确性
要求:
1.区号:空或者是三位数字
2.前缀码:非“0”且非“1”开头的三位数字
3.后缀码:四位数字
1).明确需求：
1.区号:空或者是三位数字 长度
2.前缀码:非“0”且非“1”开头的三位数字 类型
3.后缀码:四位数字 规则
2).确定有效类和无效类
|
参数 |
说明 |
有效类 |
有效数据 |
无效类 |
无效数据 |
|
区号 |
长度 |
空、3位 |
1、空 2、123 |
非3位且非空 |
1234 |
|
前缀码 |
3位 |
234 |
非3位 |
23 |
|
|
后缀码 |
4位 |
1234 |
非4位 |
123 |
|
|
区号 |
类型 |
自然数 |
/ |
非自然数 |
12A |
|
前缀码 |
自然数 |
/ |
非自然数 |
23A |
|
|
后缀码 |
自然数 |
/ |
非自然数 |
123A |
|
|
区号 |
规则 |
/ |
/ |
/ |
/ |
|
前缀码 |
非0且非1开头 |
/ |
0或1开头 |
1、012 2、123 |
|
|
后缀码 |
/ |
/ |
/ |
/ |
|
|
合计：2条用例 |
合计：8条用例 |
#写有效用例的时候需要3个参数全对，因此2条用例；写无效用例的时候当1个参数错误时其他参数得保持正确，因此8个用例
#正向用例：一条尽可能覆盖多条
#逆向用例：每一条数据，都是一条单独用例
3).提取数据编写测试用例
|
用例编号 |
用例标题 |
模块/项目 |
优先级 |
前置条件 |
测试步骤 |
测试数据 |
预期结果 |
|
Tel_001 |
号码正确(区号空；前缀码非0非1开头的三位数字；后缀码四位数字) |
号码 |
p0 |
打开号码验证程序 |
1、输入区号 2、输入前缀码 3、输入后缀码 4、点击验证 |
区号：空 前缀码：234 后缀码：1234 |
提示号码正确 |
|
Tel_002 |
号码正确(区号三位数字；前缀码非0非1开头的三位数字；后缀码四位数字) |
号码 |
p0 |
打开号码验证程序 |
1、输入区号 2、输入前缀码 3、输入后缀码 4、点击验证 |
区号：123 前缀码：234 后缀码：1234 |
提示号码正确 |
|
Tel_003 |
号码错误(区号非三位数字，其余正确) |
号码 |
p1 |
打开号码验证程序 |
1、输入区号 2、输入前缀码 3、输入后缀码 4、点击验证 |
区号：1234 前缀码：234 后缀码：1234 |
提示号码错误 |
|
Tel_004 |
号码错误(前缀码非非0非1开头的非三位数字，其余正确) |
号码 |
p1 |
打开号码验证程序 |
1、输入区号 2、输入前缀码 3、输入后缀码 4、点击验证 |
区号：空 前缀码：23 后缀码：1234 |
提示号码错误 |
|
Tel_005 |
号码错误(后缀码非四位数字，其余正确) |
号码 |
p1 |
打开号码验证程序 |
1、输入区号 2、输入前缀码 3、输入后缀码 4、点击验证 |
区号：空 前缀码：234 后缀码：123 |
提示号码错误 |
|
Tel_006 |
号码错误(区号三位非数字，其余正确) |
号码 |
p1 |
打开号码验证程序 |
1、输入区号 2、输入前缀码 3、输入后缀码 4、点击验证 |
区号：12A 前缀码：234 后缀码：1234 |
提示号码错误 |
|
Tel_007 |
号码错误(前缀码非0非1开头的三位非数字，其余正确) |
号码 |
p1 |
打开号码验证程序 |
1、输入区号 2、输入前缀码 3、输入后缀码 4、点击验证 |
区号：空 前缀码：23A 后缀码：1234 |
提示号码错误 |
|
Tel_008 |
号码错误(后缀码四位非数字，其余正确) |
号码 |
p1 |
打开号码验证程序 |
1、输入区号 2、输入前缀码 3、输入后缀码 4、点击验证 |
区号：空 前缀码：234 后缀码：123A |
提示号码错误 |
|
Tel_009 |
号码错误(前缀码0开头的三位数字其余正确) |
号码 |
p1 |
打开号码验证程序 |
1、输入区号 2、输入前缀码 3、输入后缀码 4、点击验证 |
区号：空 前缀码：012 后缀码：1234 |
提示号码错误 |
|
Tel_010 |
号码错误(前缀码1开头的三位数字，其余正确) |
号码 |
p1 |
打开号码验证程序 |
1、输入区号 2、输入前缀码 3、输入后缀码 4、点击验证 |
区号：空 前缀码：123 后缀码：1234 |
提示号码错误 |
友情提示：完整的用例应该是等价类和边界值一块写，这里只演示了等价类的用例
边界值分析法-解决边界位数限制问题
1.边界范围节点
方法：选取正好等于、刚好大于、刚好小于边界的值作为测试数据
上点：边界上的点(正好等于)
离点：距离上点最近的点(刚好大于、刚好小于)
内点：范围内的点(区间范围内的数据)
案例：-99~99区间内做边界值测试
测试分析如下：
上点：边界上的点 (绿色) 2条用例
离点：离边界最近的点 (黄色) 4条用例
内点：范围内的点(蓝) 1条用例
因此最多可设计7条测试用例，
提示：所有边界值的测试用例最多只会有7条用例
边界值能解决位数(长度)问题，但是不能解决类型问题（因此要结合等价类），而规则可以用等价类解决
2.应用设计步骤
明确需求
确定有效和无效等价类
确定边界范围值
提取数据编写测试用例
3.边界值优化
结论：7个点优化为5个点
上点：必选(不考虑区间开闭)
内点：必选(建议选择中间范围)
离点：开内闭外(考虑开闭区间，开区间选择内部离点，闭区间选择外部离点)
#10<a<=20 ->使用开闭区间表达:(10,20]
#开区间：不包含
#闭区间：包含
#开区间指的是区间边界的两个值不包括在内：(a,b)
#闭区间指的是区间边界的两个值包括在内：[a,b]
#半开半闭区间：开区间一边的边界值不包括在内，而闭区间一边的边界值包括在内：[a,b)、(a,b]
4.适用场景
在等价类的基础上针对有边界范围的测试数据输入的地方(重点关注边界)
常见词语描述：大小、尺寸、重量、最大、最小、至多、至少等修饰词语
典型代表：有边界范围的输入框类测试
5.总结
案例：通过边界值法验证标题长度的合法性，标题长度大于0，小于等于30个字符
明确需求：0个字符<标题长度<=30个字符
确定有效无效等价类：长度可以由边界值去测，这里只需要测类型即可 有效类：>0且<=30位字符 无效类：>0且<=30位非字符(纯数字)
确定边界范围值：上点：0，30 离点：-1，1，29，31 内点：15
提取数据编写测试用例：有效类边界测试已包含，删除；-1不能实现，删除，因此共7条用例
|
用例编号 |
用例名称 |
项目/模块 |
优先级 |
前置条件 |
测试步骤 |
测试数据 |
预期结果 |
|
title_001 |
不合法(标题位非字符) |
标题 |
p1 |
打开标题验证程序 |
1.输入标题 2.点击验证 |
12345 |
不合法 |
|
title_002 |
不合法(标题字符数=0) |
标题 |
p1 |
打开标题验证程序 |
1.输入标题 2.点击验证 |
空 |
不合法 |
|
title_003 |
合法(标题字符数=30) |
标题 |
p0 |
打开标题验证程序 |
1.输入标题 2.点击验证 |
12345678901234567890123456789a |
合法 |
|
title_004 |
合法(标题字符数=1) |
标题 |
p0 |
打开标题验证程序 |
1.输入标题 2.点击验证 |
a |
合法 |
|
title_005 |
合法(标题字符数=29) |
标题 |
p0 |
打开标题验证程序 |
1.输入标题 2.点击验证 |
1234567890123456789012345678a |
合法 |
|
title_006 |
不合法(标题字符数=31) |
标题 |
p1 |
打开标题验证程序 |
1.输入标题 2.点击验证 |
123456789012345678901234567890a |
不合法 |
|
title_007 |
合法(标题字符数=15) |
标题 |
p0 |
打开标题验证程序 |
1.输入标题 2.点击验证 |
1234567890abcde |
合法 |
案例：通过边界值法验证QQ号码的合法性，要求6~10位自然数
明确需求：6~10位自然数
明确有效类无效类：有效类：6~10位自然数 无效类：6~10位非自然数，为空
边界值分析：上点：6，10 离点：5，7，9，11 内点：8
提取数据写测试用例：
|
用例编号 |
用例名称 |
项目/模块 |
优先级 |
前置条件 |
测试步骤 |
测试数据 |
预期结果 |
|
qq_001 |
不合法(qq为6~10位非自然数) |
|
p1 |
打开qq验证程序 |
1.输入qq号 2.点击验证按钮 |
123456a |
不合法 |
|
qq_002 |
合法(qq为6位自然数) |
|
p0 |
打开qq验证程序 |
1.输入qq号 2.点击验证按钮 |
123456 |
合法 |
|
qq_003 |
合法(qq为10位自然数) |
|
p0 |
打开qq验证程序 |
1.输入qq号 2.点击验证按钮 |
1234567890 |
合法 |
|
qq_004 |
不合法(qq为5位自然数) |
|
p1 |
打开qq验证程序 |
1.输入qq号 2.点击验证按钮 |
12345 |
不合法 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
qq_007 |
不合法(qq为11位自然数) |
|
p1 |
打开qq验证程序 |
1.输入qq号 2.点击验证按钮 |
12345678901 |
不合法 |
|
qq_008 |
合法(qq为8位自然数) |
|
p0 |
打开qq验证程序 |
1.输入qq号 2.点击验证按钮 |
12345678 |
合法 |
|
qq_009 |
不合法(qq为空) |
|
p1 |
打开qq验证程序 |
1.输入qq号 2.点击验证按钮 |
空 |
不合法 |
#根据边界值优化原则，qq_005、qq_006两条用例可以不要
判定表法-解决多条件有依赖关系的问题
1.判定表法的引入
案例：验证“若用户欠费或者关机，则不允许主被叫”功能的测试
说明：等价类边界值分析法主要关注单个输入类条件的测试，并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约关系的测试，因此引入判定表法
2.判定表定义及组成部分
定义：是一种以表格形式表达多条件逻辑判断的工具
组成：
条件桩：列出问题中的所有条件，列出条件的次序无关紧要
动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束
条件项：列出条件对应的取值，所有可能情况下的真假值
动作项：列出条件项的、各种取值情况下应该采取的动作结果。
|
条件 |
是否欠费 |
是 |
是 |
否 |
否 |
|
是否关机 |
是 |
否 |
是 |
否 |
|
|
操作 |
是否允许主被叫 |
否 |
否 |
否 |
是 |
#灰色：条件桩 黄色：动作桩 绿色：条件项 蓝色：动作项
规则：
判定表中贯穿条件项和动作项的一列就是一条规则
假设有n个条件，每个条件的取值有两个(0,1)，全组合有2的n次方种规则
3.判定表法设计用例步骤
明确需求
画出判定表
列出条件桩和动作桩
填写条件项，对条件进行全组合
根据条件项的组合确定动作项
简化、合并相似规则(有相同的动作)
根据规则编写测试用例
4.使用场景
有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖(制约)关系
判定表一般适用于条件组合数量较少的情况(比如4个条件以下)，如果超过4个会用到正交法和因果图法设计测试用例
5.总结
案例：订购单检查
规则：
如果金额大于500元，又未过期，则发出批准单和提货单;
如果金额大于500元，但过期了，则不发批准单与提货单;
如果金额小于等于500元，则不论是否过期都发出批准单和提货单:
在过期的情况下不论金额大小还需要发出通知单。
明确需求：上述规则
画判定表：
|
是否大于500 |
是 |
是 |
否 |
否 |
|
是否过期 |
是 |
否 |
是 |
否 |
|
批准单 |
× |
√ |
√ |
√ |
|
提货单 |
× |
√ |
√ |
√ |
|
通知单 |
√ |
× |
× |
√ |
提取数据，编写用例：
|
用例编号 |
用例名称 |
项目/模块 |
优先级 |
前置条件 |
测试步骤 |
测试数据 |
预期结果 |
|
order_001 |
发通知单(大于500，已过期) |
订单 |
p0 |
打开订单验证程序 |
1.输入金额 2.输入是否过期 3.点击验证按钮 |
金额：600 已过期 |
发通知单，不发批准单、提货单 |
|
order_002 |
发批准单、提货单(大于500，未过期) |
订单 |
p0 |
打开订单验证程序 |
1.输入金额 2.输入是否过期 3.点击验证按钮 |
金额：600 未过期 |
发批准单、提货单，不发通知单 |
|
order_003 |
发批准单、提货单(小于500，已过期) |
订单 |
p0 |
打开订单验证程序 |
1.输入金额 2.输入是否过期 3.点击验证按钮 |
金额：400 已过期 |
发批准单、提货单，不发通知单 |
|
order_004 |
发批准单、提货单、通知单(小于500，未过期) |
订单 |
p0 |
打开订单验证程序 |
1.输入金额 2.输入是否过期 3.点击验证按钮 |
金额：400 未过期 |
发批准单、提货单、通知单 |
案例：文件修改规则
规则：
输入的第一列字符必须是A或B
第二列字符必须是一个数字
如果第一列字符不正确，则给出信息L
如果第二列字符不正确，则给出信息M
如果两列字符输入正确，则修改文件成功
明确需求：上述规则
画判定表：
|
第一列为A或B |
是 |
是 |
否 |
否 |
|
第二列为一个数字 |
是 |
否 |
是 |
否 |
|
给出信息L |
× |
× |
√ |
√ |
|
给出信息M |
× |
√ |
× |
√ |
|
修改文件成功 |
√ |
× |
× |
× |
提取数据，编写用例：
|
用例编号 |
用例名称 |
项目/模块 |
优先级 |
前置条件 |
测试步骤 |
测试数据 |
预期结果 |
|
file_001 |
修改成功(第一列符合条件，第二列符合条件) |
文件 |
p0 |
打开文件验证程序 |
1.输入第一列 2.输入第二列 3.点击验证按钮 |
第一列：A 第二列：1 |
修改成功 |
|
file_002 |
输出M(第一列符合条件，第二列不符合条件) |
文件 |
p1 |
打开文件验证程序 |
1.输入第一列 2.输入第二列 3.点击验证按钮 |
第一列：A 第二列：a |
输出信息M |
|
file_003 |
输出L(第一列不符合条件，第二列符合条件) |
文件 |
p1 |
打开文件验证程序 |
1.输入第一列 2.输入第二列 3.点击验证按钮 |
第一列：C 第二列：1 |
输出信息L |
|
file_004 |
输出L、M (第一列不符合条件，第二列不符合条件) |
文件 |
p1 |
打开文件验证程序 |
1.输入第一列 2.输入第二列 3.点击验证按钮 |
第一列：C 第二列：a |
输出信息L、M |
场景法-解决业务覆盖测试
重点：先测试业务，再测试单功能、单模块、单页面
1.流程图
使用标准图形和箭头来表达程序或业务的走向
流程图对测试人没有什么作用?
能够看懂流程图，设计业务用例
当需求文档信息不全时，能够根据需求，梳理出流程
网页版工具：https://processon.com/
Windows工具：visio
2.介绍
说明：
场景法也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。
意义：
用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用
测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试
3.使用场景
根据实际的应用场景，来测试业务用例，可以使用场景法
4.总结
案例：流程图练习
1、用户名为admin 密码为: 123456，输出: 登录成功
2、登录、搜索商品、添加购物车、去结算、支付，如果支付成功，则提示下单成功，否则提示支付失败
案例：ATM机取款流程
1、开始->验证银行卡不成功->结束
2、开始->验证银行卡成功->密码错误3次->结束
3、开始->验证银行卡成功->密码验证成功->账户余额不足->结束
4、开始->验证银行卡成功->密码验证成功->账户余额验证成功->取款金额不正确->结
5、开始->验证银行卡成功->密码验证成功->账户余额验成功->取款金额确->ATM机余额不足->结束
6、开始->验证银行卡成功->密码验证成功->账户余额验证成功->取款金额正确->ATM机余额充足->取款成功->结束
#一共6条业务用例，其中正向的那条(第6条)为冒烟测试，一个项目首先确保冒烟测试成功才会做其他测试
|
用例编号 |
用例标题 |
项目/模块 |
优先级 |
前置条件 |
测试步骤 |
测试数据 |
预期结果 |
|
ATM_001 |
取款失败(非银行卡) |
ATM |
p1 |
打开ATM验证程序 |
插入卡 |
卡：会员卡 |
取款失败，提示卡为非银行卡 |
|
ATM_002 |
取款失败(密码错误3次) |
ATM |
p1 |
打开ATM验证程序 |
1.插入卡 2.输入密码 |
卡：银行卡 密码：错误密码 |
取款失败，提示密码错误3次，吞卡 |
|
ATM_003 |
取款失败(卡余额不足) |
ATM |
p1 |
1.打开ATM验证程序 2.卡余额0 |
1.插入卡 2.输入密码 3.输入取款金额 |
卡：银行卡 密码：正确密码 金额：1000 |
取款失败，提示卡余额不足 |
|
ATM_004 |
取款失败(取款金额不符合要求) |
ATM |
p1 |
1.打开ATM验证程序 2.卡余额10000 |
1.插入卡 2.输入密码 3.输入取款金额 |
卡：银行卡 密码：正确密码 取款金额：1 |
取款失败，提示只能取100或100的倍数 |
|
ATM_005 |
取款失败(ATM机余额不足) |
ATM |
p1 |
1.打开ATM验证程序 2.卡余额10000 3.ATM机余额0 |
1.插入卡 2.输入密码 3.输入取款金额 |
卡：银行卡 密码：正确密码 取款金额：1000 |
取款失败，提示ATM机余额不足（现实中只会提示故障） |
|
ATM_006 |
取款成功 |
ATM |
p0 |
1.打开ATM验证程序 2.卡余额10000 3.ATM机余额20000 |
1.插入卡 2.输入密码 3.输入取款金额 |
卡：银行卡 密码：正确密码 取款金额：1000 |
取款成功，打印凭证 |
错误推测法
1.定义
通过经验推测系统可能出现的问题
2.思想
根据经验列举出可能出现问题的清单，根据清单分析问题可能原因，推测发现缺陷
3.场景
时间紧任务量大时，根据之前项目类似经验找出易出错的模块重点测试
实践宽裕通过该方法列出之前出现问题较多的模块再次测试
4.实际应用场景
当项目用例都执行完毕，且BUG修复完成，离上线还有一段时间，在这段时间中可以使用错误推荐法复测主要业务或测试未覆盖的功能。
标签：qq,验证,用例,点击,测试,设计,编写,输入 From： https://www.cnblogs.com/vorn/p/17673608.html