随机测试

随机测试流程，自我积累，暂时作为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建议如下

统计处理结果1-各人贡献数目

统计处理结果2-各个模块

a）是bug：严重问题，需要开发及时修改；是bug且延期处理；
b）暂无法复现：问题无法复现；
c）已知问题：问题模块负责人已知；
d）确认不是问题：三方沟通后确认不是问题；
e）建议：站在用户的角度提出的需求建议。
总数为“是问题”的个数与“建议”的个数相加。
注：”对测试结果统计和滤重“和“公示结果”可以根据适合自己项目组的规则制定。

参与人员，各个人反馈的结果

8）邮件反馈结果

Dear All, 本次【xx模块】随机测试结果如下，请查阅

测试模块
环境&版本
测试时间
参与随机测试人员

发现bugxx个，其中xx个属于漏测，xx个属于已知问题，xx个暂未复现问题后续继续关注
以上bug 请相关模块负责人 @xx @xx继续关注

统计处理结果1-各人贡献数目图表(excel表含柱状图）

统计处理结果2-各个模块(excel表含柱状图）