作者:cryanimal 微信:lazytest
导语
虽然说开发和测试一家人,应该相互信任,不过在关键环节有法可依,还是非常必要的,“提测”环节便是其中之一,每个角色做好分内工作,有助于整体研发效率的提升,毕竟,一个BUG半小时嘛。本文将详细描述关于测试准入、提测邮件、提测后的CR、测试报告相关事宜,规范提测环节。测试准入标准
提测邮件模板(点击下载):
- 邮件标题:【项目提测】 + 提测模块名称
- 邮件收件人:对应的测试人员
- 邮件抄送:项目小组邮件群
- 详细内容如下表,带 * 号为必填项:
项 目 提 测 |
|||||||
项目名称 * |
不要填写服务名称 |
迭代周期 * |
迭代数 | 提测人 * |
|
||
开发环境部署通过 * |
是(强制要求) 减少因依赖冲突、未merge base、jar包黑名单引起的测试环境部署失败 |
是否完成自测及联测 * |
是 (强制要求) |
配置文件是否变更* |
是或否 (强制要求) |
||
变更项* |
增加内容 |
l 请尽量详细描述提测功能的变更点。 l 拒绝“详见需求文档”类似描述,一旦遇到,提测打回,上线日期顺延。 |
|||||
修改内容 |
|
||||||
修复bug |
|
||||||
缓存key及更新规则说明 |
|||||||
其他配置、规则说明 |
|||||||
变更影响范围 * (测试范围说明) |
l 请描述变更影响范围。 l 若因变更影响范围未写明而出现的线上bug,记录到开发人员的kpi。 |
||||||
建议测试方法 |
|||||||
送测版本和API版本* |
l 请填写:svn,git 版本url。 l 请注意:分支名称符合约定规范。 |
||||||
变更SQL |
l 写sql地址(如果有)或脚本内容(如果没有sql统一管理地址,则写sql内容) |
开发环境是否已执行 |
是(强制要求) |
提测后注意事项
1. 提测后,非bug fix的修改,必须征得QA同意(如重构)
提测后的修改,未告知QA的情况多有发生,这也是产生线上问题的高发区,有此规定,可以规避这类“好心做坏事”的概率。
2. Bug fix涉及的代码,QA做code review
项目紧张的时候,bug也会比较多,而另一方面,全面回归的时间也几乎没有,因此因bug修复引入新bug,又未被发现的隐患就会比较大。
引入Bug fix涉及的代码,QA做CR,一方面能明确回归范围,另一方面也能减少质量隐患。
提测后,测试前,需要对代码进行diff,将base和提测分支进行比较,确定回归范围
测试完成后,上线前,再次对代码diff,将上线版本和提测版本进行比较,确定提测后没有无关代码提交。
3. 基础jar包升级,必须整个项目所有应用一起进行
测试报告模板(点击下载):
- 邮件标题:【测试报告】 + 提测模块名称
- 邮件收件人:提测人,需求提出产品
- 邮件抄送:项目小组邮件群
- 详细内容如下表,带 * 号为必填项:
项 目 测 试 报 告 |
|||||||||||
项目名称 * |
迭代周期 |
|
预计上线日期 * |
|
测试人员 * |
||||||
送测模块/接口 * |
与提测邮件标题中的【提测模块】内容保持一致 |
提测人 * |
|
||||||||
送测版本 * |
与提测邮件保持一致 |
测试类型 * |
功能/接口测试 |
||||||||
送测模块总数 * |
系统外部依赖 |
无 |
|||||||||
测试部署失败次数 * |
服务名 |
次数 |
提测次数 * |
服务名 |
次数 |
bug数 * |
填写数量 |
||||
|
|
|
|
||||||||
|
|
|
|
||||||||
测试内容 * |
请详细描述测试点,不要写测试案例; |
||||||||||
测试结果 * |
测试通过/不通过 |
||||||||||
遗留bug清单 |
bug描述 |
bug等级 |
处理人 |
||||||||
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|