1、测试人员需准备测试用例和冒烟用例
2、全组人员需评审测试用例
3、开发人员需自测:逐条自测通过测试提供的冒烟用例(注意:这点很重要)
4、提测前验收:提测前全体人员通过会议对整体功能点验收
a、由开发人员提供验收list,验收前发邮件到全员过目
b、开发准备好环境和数据做验收演示,由测试人员和产品对功能验收
c、测试人员和产品确定是否验收通过,验收通过后才可提测
d、验收不通过则修复bug后再次进行提测前验收,直到验收通过
5、提测和版本升级时,务必所有版本,脚本,配置和包都通过全员邮件发送,
注:sql格式如v1.0_20190101_name.sql
a、如果在测试环境执行不通过:
a1、测试人员需要回复邮件执行中的错误截图
a2、开发人员需要重新发起邮件,测试人员重新执行直到通过,通过后保留文件到本地做上线备用
b、如果执行通过:需要回复邮件,且保留文件到本地做上线备用
6、提测后,测试过程中如果存在冒烟用例中的bug,可由测试人员决定版本打回重新提测
注:打回重新提测导致的delay由开发人员自行负责,故请所有人员认真对待自测的冒烟用例
7,暂定每天提交3次bug修复版本,时间分别为10:00,14:00,17:00,如有影响测试的紧急bug,可由测试人员要求开发修复后立即提交版本
注:bug次数和时间可变更
8,bug必须放到bug管理平台中统一管理
a、bug标题需清晰
b、bug中须有截图和关键测试数据,如订单号,id,用户手机号等
注:简单明了的bug可只写标题
c、复杂的bug,需记录重现步骤
d、开发需对每个bug进行原因备注
e、重复reopen的bug请重视
f、开发正在修复一个bug时,请先把bug状态置为open
9、每次迭代中的需求变更,或者新增任务,需要在bug管理平台创建任务且邮件通知到全员
10、测试中后期,产品人员可对测试环境的系统提前查看
11、测试通过后,测试人员通知产品,产品先私下自行操作验收一遍
12、产品验收会议:全员参加,测试人员提供验收list,测试人员演示,如验收不通过:需修复bug后再次验收,直到验收通过
13、上线升级邮件:
a、验收通过后,由测试人员整理上线升级所需的服务版本,sql脚本,配置等
b、sql脚本需要每个文件都在测试环境执行通过,邮件中需备注按时间顺序依次执行sql
c、整理好测试报告后,发送给项目负责人,抄送给全员(注意,不能发送给运维)
d、项目负责人对测试报告进行查看(特别是sql和配置),通过后转发给运维
14、上线后:
a、开发人员盯线上日志
b、测试人员进行线上验收:新功能和全局重点功能
15、如果出现线上bug,需记录到bug管理系统中,且说明出现bug的情景,后续补充解决方法,上线升级邮件中需附带记录的线上bug
注:上线升级邮件只能由项目负责人发送给运维,不能由开发人员自行发送。(特殊情况可由项目负责人授权开发代发上线升级邮件)
注:所有上线邮件,全员都需关注,如果发现异常请及时告知相关人员。
群里的bug问题,有@到人的,如果看到了正在查看问题,请及时告知发起人
群里的线上bug,请所有相关人员及时在群里回复,不要私聊后群里没有响应,会让人误会是否有人正在跟进。
bug修复升级邮件:需附带此版本中修复的bug记录标题和所需升级的服务版本号
20、统一不同邮件的标题格式。