提测环节管理

最新推荐文章于 2025-07-09 08:38:32 发布

杨不羁

最新推荐文章于 2025-07-09 08:38:32 发布

阅读量1.7w

点赞数 8

CC 4.0 BY-SA版权

分类专栏：测试管理测试管理

22 篇文章

订阅专栏

13 篇文章

订阅专栏

作者：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包升级，必须整个项目所有应用一起进行