1、需求预审
一般是产品、开发组长、测试组长参与需求预审,产品简单说下需求,开发和测试共同评估需求可行性(一般大公司会有这个环节)
2、需求细评
需求预审后产品会拉相应需求群,开发组长和测试组长分配好对应需求开发和测试人员,将其拉到需求群并参与细评,细评时产品对需求进行详细讲解
3、版本排期
需求细评人员评估用例编写工时和测试工时,组长review组内工时。根据提测时间和工时进行排期。
4、用例编写
根据需求文档、设计稿、技术实现文档进行用例编写
5、用例评审
提测前1-2天组织需求用例评审,拉上对应开发、产品参与,评审完后整理用例并提供P0用例给开发自测。
6、开发提测
开发需自测P0用例,需要在自测用例上标上自测结果和执行人员。P0用例未通过需打回。
7、测试执行
- 进入测试阶段后,每日下班前需在项目群同步版本测试情况,卡点问题需要及时暴露推进。
- 需求冒烟通过后,需通知产品、UI、翻译进行验收。
- 需求冒烟通过后,需执行app性能测试和monkey测试。
- 发版前一天需拉上产品开发进行bug评审,评审出发版前需要解决的bug。
- 发版前一天提前通知产品运营等进行线上配置。
- 测试完一轮后如果没有影响服务端上线的bug需要提前通知服务端上线并提前打好正式包
8、线上回归
正式回归前需要分配好回归用例的执行人员,服务端上线后先线上回归新需求,再回归原有功能
9、提审
回归没有问题后通知产品提审,并打开提审开关。
10、测试报告
编写该版本的测试报告,总结版本测试质量情况并发邮件,抄送项目组
10、回归用例整理
需求测试人员整理回归用例,将本次版本核心功能点整理到回归用例中。
11、线上崩溃和用户反馈跟进
版本灰度期间关注线上崩溃和ANR情况,及时跟进线上反馈问题,有必要需发补丁及时解决。灰度一段时间后崩溃和anr正常,用户反馈无异常可全量。