随机测试流程,自我积累,暂时作为base模板,后续会继续优化
ps:后续目标,可以完成随机测试-APP-模块初稿
1.发起随机测试
项目负责人发起随机测试,明确项目背景,筛选测试目标模块
随机测试的模块需要满足如下三个准则之一:
1.1近期改动比较大的模块
特征:代码变更多、bug多
1.2新增模块
特征:测试时间有限,未经历线上用户验证,存在潜伏bug可能
1.3质量不佳的模块
特征:bug集中的模块, reopen bug
2.测试checklist
项目准备
随机测试并不是没有目的尝试各种情况试图发现软件缺陷,是需要一定的准备工作的。
项目负责人
按照模块名称、环境配置、测试说明&功能介绍、测试点、测试负责人统计需要随机测试的模块,可以帮助随机测试人员明确测试范围、了解测试功能的基本信息和要达到的效果;
3.安排测试时间
项目负责人安排随机测试的时间,一般选择在功能用例执行完毕,功能趋于稳定之后进行
完成n轮测试后,模块趋于稳定,完成核心功能回归
4.通知所有人测试
项目负责人提前一天通知全组进行功能模块的随机测试,即在“随机测试通知”邮件中体现测试时间、测试地点及测试关注点;
5.反馈问题格式
将测试发现的问题按照如下格式发送出来;
各字段释义为:
①编号:1、2、3、...、n;
②所属模块:写明出现bug的模块名称;
③描述:描述出现bug的具体过程;
④指派人:若可以确定该模块的测试负责人,写上名字;
⑤备注:其他关于该bug的描述都可写在备注里;
⑥处理结果(请负责人添加):指派人回复bug的处理结果,标明状态(是问题、建议、暂无法复现、已知问题、确认不是问题);
6.提交bug&问题跟进
汇总问题后,回复给各个模块测试负责人
模块测试负责人,复现bug,并写明结果给项目负责人,确定是bug提交给开发
7.对测试结果统计和滤重
项目负责人统计模块测试负责人反馈的结果
每个人发现的bug数量,过滤掉不是问题的“bug”、无法复现的bug和已知问题
统计bug建议如下
a)是bug:严重问题,需要开发及时修改;是bug且延期处理;
b)暂无法复现:问题无法复现;
c)已知问题:问题模块负责人已知;
d)确认不是问题:三方沟通后确认不是问题;
e)建议:站在用户的角度提出的需求建议。
总数为“是问题”的个数与“建议”的个数相加。
注:”对测试结果统计和滤重“和“公示结果”可以根据适合自己项目组的规则制定。
参与人员,各个人反馈的结果
8)邮件反馈结果
Dear All, 本次【xx模块】随机测试结果如下,请查阅
测试模块
环境&版本
测试时间
参与随机测试人员
发现bugxx个,其中xx个属于漏测,xx个属于已知问题,xx个暂未复现问题后续继续关注
以上bug 请相关模块负责人 @xx @xx继续关注
统计处理结果1-各人贡献数目图表(excel表含柱状图)
统计处理结果2-各个模块(excel表含柱状图)