在做测试中，开发提交的测试版本过于简单，导致花大量的时间进行沟通。下面对测试版本提交做了下总结：
测试申请要求：
1、应该以邮件的形式发送给大家（包括质量信息部经理、测试负责人，测试执行人，项目负责人，项目决策人）。
2、内容包括版本主题，版本的路径、版本描述。
如：
标题：XX已提交,标签已制作，请知悉。该XX版本解决XX，XXX不对的故障！
SVN路径：https://XX.XX.XX.XX:8443/svn/xx
描述：修正了传真单XX的情况。
提交测试版本内容包括：
一、版本提交清单。
内容要求：
1、版本提交的时间
2、负责开发人
2、本次版本（每次迭代也算一个小版本）实现（修改）的功能点一一列出
二、如果涉及到配置安装软件或环境的，还应该有相应的部署手册。
部署手册要求：
1、应该尽可能详尽，如果测试人员发现bug，也应列入QC进行缺陷管理。
2、测试人员严格按部署手册进行环境部署，如因部署手册出现问题导致后续步骤无法进行的，应打回相应开发人员重新提交版本，并邮件通知大家（包括直属领导和项目决策人）。
3、如果部署手册出现问题，但因为项目时间紧急，测试人员能自行搞定的，也可以部署后把缺陷提交到QC上，在下次回归时做测试。
4、部署手册不能由测试人员修改，部署手册出现严重问题影响用户安装部署环境的，测试否决予以发布，并邮件通知大家。
三、对应版本的源码和编译后的文件。
四、如果涉及到数据导入（比如大量数据测试），还应该提供相应的sql执行语句；实际还包括数据库的定时任务、储存过程等。
五、开发单元测试用例和测试报告。
六、如果涉及到用户使用手册、还应该附上用户手册等。
七、版本其他（如shell脚本、涉及到的插件等）。
以上都应该分类建一个项目文件夹固化下来，过后每次提交版本后都应该有一个版本检查测试。根据实际情况，以上版本内容可以经过大家一致同意后做适当的增减。
最后：其中某一个环节出现问题（如功能出现大缺陷，导致后面功能不能使用。或部署手册有问题，不能按上面完成环境部署等），导致后续没法测试或测试困难的，直接打回开发重提版本。