内容简介：有前端或客户端参与的需求，由他们来提测，否则是后端直接提测。提测记录可以写在IM群公告上，不要覆盖同版本的提测，每个版本发布后由测试同学剪切保存到ODS或测试报告中。如果有项目管理工具帮助或者研发有资源自己做一个提测记录系统那就更好了。（术语解释请参考《排期和立项》，tag的格式请参考《Git分支管理规范》）
有前端或客户端参与的需求，由他们来提测，否则是后端直接提测。
提测记录可以写在IM群公告上，不要覆盖同版本的提测，每个版本发布后由测试同学剪切保存到ODS或测试报告中。如果有项目管理 工具 帮助或者研发有资源自己做一个提测记录系统那就更好了。
（术语解释请参考《排期和立项》，tag的格式请参考《Git分支管理规范》）
- 开发自测，确保主路径没问题。如果测试组有提供冒烟测试，必须冒烟都通过
- 在IM群公告栏写上本次提测的tag和测试重点。
- 如果质量不过关，测试可以打回
提测通知示例
前端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
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Thinking Recursively
Eric S. Roberts / Wiley / 1986-1-17 / USD 85.67
The process of solving large problems by breaking them down into smaller, more simple problems that have identical forms. Thinking Recursively: A small text to solve large problems. Concentrating on t......一起来看看 《Thinking Recursively》 这本书的介绍吧!
