版权声明：
本公众号发布的所有文章，均属于原创，版权归本公众号所有。
允许有条件转载，转载请附带底部二维码。
一、先聊几句
一般产品的版本迭代都是一版版的在推进，每一个版本之间都要经历产品需求确定、开发、测试、升级、发版。
开发按需求开发完成之后，提测的过程，是一个和测试人员交接的过程。这个通常不可能说给测试口述本次改版改了哪些地方，一般而言，会发出一个提测邮件，来与测试交付本次测试。
可能有些人会说，按照需求文档来测试即可，但是很多时候，既定的需求和实际开发的需求是有变动的，开发对这个功能，具体如何实现，也决定了测试需要测试哪些case。
那么提测邮件，写什么，怎么写，很重要。
二、来写一份提测邮件
1、谁来写
一个版本的开发任务一般都不是由一个开发人员独立开发，是有多人配合的。那现在就需要有一个对本期改动细节都熟悉的人，知道有哪些变动，哪些功能的实现细节是否有提现。
技术小组组长一般可以承担起这个责任，因为他是必须把所有的功能代码的Pull Request(后文简称PR)都review一遍的人，了解本周期内所有的技术细节，所有的功能改动，知道什么地方的是必须测试的，知道什么地方是临界点需要着重测试的。
当然，如果每个开发人员，提交的PR非常的规范，写清楚提交点和待测试点，基本上只需要翻翻合过的代码，就可以写一封比较好的提测邮件了。
2、写什么
我觉得一篇合格的提测邮件，需要明确有几点，一定要在邮件里有体现。
- 提测版本的版本号、版本名。
- 提测版本的下载包地址。
- 提测功能点。
- 每个功能点的待测点和影响范围。
其实不太讲究什么格式，只要清晰，明确即可。包含这些信息，哪怕安装包打错了包，指错了安装包的地址，测试人员都可以很快反应过来。
对每个提测的功能点都要有细节说明，每个功能需要测试的场景有细节说明，对每个功能会影响的范围要有细节说明。
举个例子，在拿到分配任务的开始开发的时候，发现涉及到数据库的内容，当然Android端就是SQLite，因为业务需要，需要增加一些字段或者删除一些无用字段。我们知道，在Android中，如果对数据库表结构有修改，是要对数据库进行升级的，否者低版本升级上来的用户，SQLite中是没有你新增的字段的。这个时候如果不在测试邮件里表明，测试人员只是新安装，再进行测试，永远不会发现，从旧版本升级上来的用户，真的会崩溃的。
所以一定要在提测邮件里，标注，改了什么功能，影响的范围是什么，例如修改了数据库表结构，需要测试低版本在有旧数据的情况下，覆盖升级。
3、写给谁看
提测邮件当然是写给测试看的，但是通常来说，我们会抄送给一些人，例如：产品经理需要知道这些功能如期完工了，关键点也如同需求一样，他们也需要看懂提测邮件。
但是最重要的还是，一定要让测试人员能看懂。不要只是写修改点，一定要明确测试点，和功能触发环境。
一般的句式：新增Xxx功能，需要在Xxx环境中，测试Xxx。
从上面SQLite数据库升级来举例子，就是：修改数据库表结构，需要在低版本有数据的情况下，从低到高版本之间，进行覆盖安装，测试功能是否正常。
这样写，简洁明了，测试不会在来找你说，『升级数据库这个，我要测试什么？』
三、结尾
本来是想贴一个常规的提测邮件的格式的，但是大多数公司的情况都不一样，各有各的情况，把握好上面提到的几点，一般都不会有什么问题。
提测邮件真的是可以有标准流程的，写的清晰明了大家工作效率都高，缺点内容可能测试人员拿到测试包之后，有些case没有覆盖到，导致一段未经测试的代码，就这么发布出去了，其实和一段代码在裸奔一样，是非常的危险的。
当然，一些常规的测试点，测试在发版前都会有一次回归测试。但是不要有侥幸心理，人来操作的事情，难免会有疏漏，把好自己这一关，不要让一个流程从你这里错误下去。
