测试流程规范
1、需求创建:项目和需求均需要求产品在PMP/行云里创建相应的项目及需求任务信息;
2、需求确认:同产品,开发以及相关人员确认需求(需求评审必须三方达成一致);
3、需求排期:项目和需求必须经测试人员排期,非测试排期可以不接受测试,评估测试工时,确定提测时间,上线时间;
4、需求变更/紧急需求:必须要找测试leader沟通好方案、风险和资源,然后走变更/紧急邮件申请;
5、测试用例:项目必须要有详细的测试用例,需求的用例可以根据实际情况灵活安排;
6、用例评审:项目测试用例必须通过产品、研发等干系人的一致评审,重要需求用例需进行组内评审,用例评审需在提交测试之前完成;
7、风险评估:需求阶段和测试阶段,提前给出影响项目和需求的原因和风险(例如:延期、影响流程、卡点、环境数据缺失等及时上报升级,测试评估有质量风险需上报,不容许做上线决策);
8、缺陷管理:项目中的缺陷和需求中的典型缺陷必须提交jira;(对于Reopen的BUG需要将对应jira的标签赋值【Reopen】 若涉及多次Reopen需要标记次数,只有一次Reopen不需要标记;见附件截图;
9、项目及需求,必须每天邮件同步测试进度)
10、项目必须要输出测试计划,测试用例,测试报告,测试总结;
11、开发必须经过自测和功能演示(研发提测标准是完成自测和功能演示,自测依据冒烟用例,冒烟用例在提测之前完成);
12、开发需要通过jira和邮件提测;(对于冒烟测试不通过的送测(冒烟不通过邮件打回),需要将对应jira的标签赋值【冒烟测试不通过】,见附件截图)
13、开发完成的需求以提测为准,才算真正进入到测试阶段;
14、 分支测试通过才可以合到主干,并在主干上进行系统测试;
15、 预发布测试通过后,才允许进行提交上线;
16、新增和修改配置开关信息,提醒开发完善注释信息;
17、所有线上改动务必同步测试,尤其配置文件修改机房调整等,着重进行测试,杜绝搭车上线;
18、在UAT阶段需要邮件邀请产品、UED和业务进行验收,收到验收通过确认再进行上线;(后续细化验收通过标准);
19、重要项目和功能建议进行灰度发布;
20、上线前开发发送上线邮件和checklist;
21、上线前测试需与研发确定好上线计划和步骤;
22、上线前提醒开发提前知晓关联系统负责人关注各自系统(以群或邮件的方式);
23、上线前提前梳理好本次上线需要修改的配置文件等信息,提醒开发进行配置备份;
24、上线前提前准备好本次上线验证所需的测试数据,测试场景;
25、上线完成后,本次上线功能着重测试,关联的核心系统和业务场景要进行整体系统回归验证;
26、线上功能验证的同时,提醒开发实时关注后台日志及系统情况;
27、上线过程中出现异常,及时配合开发进行排查和定位问题;
28、若上线导致重大影响,且短时间无法修复,需要求开发立即进行回滚;
29、持续关注UMP、JSF、JMQ、后台日志等相关监控系统信息(至少30分钟),各系统监控信息均保持平稳,则代表上线成功;
30、上线后验证完毕,邮件回复或邮件通报本次成功上线的内容,发送测试报告;
31、评估上线过程中测试所用的数据是否需要还原或清除;
32、测试流程中出现任何异常需要确定异常后的24H内,在QM系统(质量效能平台)做异常事件登记;