前言

近期在做项目总结，发现在开发提测内容时，如果信息传递不明确，容易造成测试后期执行不顺畅，从而增加测试与开发沟通成本，比如以下案例：

1.  某一功能优化，服务器端新旧功能由两个不同的开发完成，涉及两个不用的测试服务器。新功能提测的时候，开发未说明测试环境，测试延用之前的旧服务器，发现部分功能异常，测试针对该问题进行定位、沟通占用了较长时间，最终确认是测试环境问题~

2.  开发提测模块list信息不详细，测试无法明确哪些提测了？哪些没提测？

问题虽小，但积累多了就占用成本，于是测试与开发约定了以下提测内容规范~

开发提测内容规范和方式：

【必备】提测模块内容说明

 说明：即提测功能模块、未提测模块及预计提测时间说明，尽可能的与需求文档中模  块名称保持一 致

 比如: 

          1. 提测模块：xx、xx

          2. 未提测模块：xx、xx   ，预计提测时间点

 【必备】提测版本信息、代码分支路径信息、打包路径等

  说明：开发需提供提测的安装包或版本信息、打包脚本路径、打包系统等，方便测试   直接进行测试

【必备】测试注意事项

 说明：从开发实现的角度，说明模块已存在的问题/可能存在的问  题，测试应注意的  验证点等

 比如：测试需要兼容的系统版本，哪些功能点可能存在的问题较多

【必备】测试需要的环境说明

  说明：提供相应功能测试时需要的环境、前提条件、辅助信息等

  比如：测试服务器、配置文件、辅助测试工具

【可选】开发自测结果说明

 说明：开发在提测前，代码自测结果说明。

【可选】影响范围

 说明：当前代码变动的影响范围说明

【提测方式】

 开发提测模块需使用同一出口，方便测试进行查看、备忘

  比如：邮件、jira系统、其他项目管理系统

提测内容模板