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

规则

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

提测记录可以写在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