项目过程管理（十一）提测流程和免测标准

有前端或客户端参与的需求，由他们来提测，否则是后端直接提测。

提测记录可以写在IM群公告上，不要覆盖同版本的提测，每个版本发布后由测试同学剪切保存到ODS或测试报告中。如果有项目管理 工具 帮助或者研发有资源自己做一个提测记录系统那就更好了。

（术语解释请参考《排期和立项》，tag的格式请参考《Git分支管理规范》）

1. 开发自测，确保主路径没问题。如果测试组有提供冒烟测试，必须冒烟都通过
2. 在IM群公告栏写上本次提测的tag和测试重点。
3. 如果质量不过关，测试可以打回

提测通知示例

前端t1 2.3.3/1803031104 已自测。自动还款、UI改版
前端t2 2.3.3/1803041203 未自测。抢标
前端t2p1 2.3.3/1803051404 …… 解决一个崩溃，会影响所有需要登录的界面
iOS t3 2.3.3/1803061203 已自测。全功能提测
后端t1 1803061203 解决xxx问题

请注意，p代表有几个patch，没有p0，也不是每轮提测的第一个版本就是p1。

patch的提交频率以天为单位，不建议解决一个bug就提测一个patch。如果实在需要，应该开发和测试同学单对单地验证完毕，然后发patch时再由测试回归多个问题。

原因示例：

• 开发没搭好测试环境
• 主路径跑不通
• 开发未通过冒烟测试用例
• 开发未写明测试重点、修改代码的影响范围
• 开发未提供相关数据库设计文档、接口设计文档

测试应该在IM群里 @所有人 来通告，说明原因

免测标准

免测的 前提是确认测试已知悉 ，然后才是下面的条件。

• 只改UI布局或文案，没有改交互和业务
• 只是改后台报表统计

本节参考

《Git分支管理规范》 https://blog.csdn.net/hursing/article/details/78789204

本系列文章的目录： https://hursing.blog.csdn.net/article/details/88025790