2020-12-14 15:20发布
一般产品的版本迭代都是一版版的在推进，每一个版本之间都要经历产品需求确定、开发、测试、升级、发版。
开发按需求开发完成之后，提测的过程，是一个和测试人员交接的过程。这个通常不可能说给测试口述本次改版改了哪些地方，一般而言，会发出一个提测邮件，来与测试交付本次测试。
可能有些人会说，按照需求文档来测试即可，但是很多时候，既定的需求和实际开发的需求是有变动的，开发对这个功能，具体如何实现，也决定了测试需要测试哪些case。
那么提测邮件，写什么，怎么写，很重要。
一个版本的开发任务一般都不是由一个开发人员独立开发，是有多人配合的。那现在就需要有一个对本期改动细节都熟悉的人，知道有哪些变动，哪些功能的实现细节是否有提现。
技术小组组长一般可以承担起这个责任，因为他是必须把所有的功能代码的Pull Request(后文简称PR)都review一遍的人，了解本周期内所有的技术细节，所有的功能改动，知道什么地方的是必须测试的，知道什么地方是临界点需要着重测试的。
当然，如果每个开发人员，提交的PR非常的规范，写清楚提交点和待测试点，基本上只需要翻翻合过的代码，就可以写一封比较好的提测邮件了。
我觉得一篇合格的提测邮件，需要明确有几点，一定要在邮件里有体现。
提测版本的版本号、版本名。
提测版本的下载包地址。
提测功能点。
每个功能点的待测点和影响范围。
其实不太讲究什么格式，只要清晰，明确即可。包含这些信息，哪怕安装包打错了包，指错了安装包的地址，测试人员都可以很快反应过来。
对每个提测的功能点都要有细节说明，每个功能需要测试的场景有细节说明，对每个功能会影响的范围要有细节说明。
举个例子，在拿到分配任务的开始开发的时候，发现涉及到数据库的内容，当然Android端就是SQLite，因为业务需要，需要增加一些字段或者删除一些无用字段。我们知道，在Android中，如果对数据库表结构有修改，是要对数据库进行升级的，否者低版本升级上来的用户，SQLite中是没有你新增的字段的。这个时候如果不在测试邮件里表明，测试人员只是新安装，再进行测试，永远不会发现，从旧版本升级上来的用户，真的会崩溃的。
所以一定要在提测邮件里，标注，改了什么功能，影响的范围是什么，例如修改了数据库表结构，需要测试低版本在有旧数据的情况下，覆盖升级。
提测邮件当然是写给测试看的，但是通常来说，我们会抄送给一些人，例如：产品经理需要知道这些功能如期完工了，关键点也如同需求一样，他们也需要看懂提测邮件。
但是最重要的还是，一定要让测试人员能看懂。不要只是写修改点，一定要明确测试点，和功能触发环境。
一般的句式：新增Xxx功能，需要在Xxx环境中，测试Xxx。
从上面SQLite数据库升级来举例子，就是：修改数据库表结构，需要在低版本有数据的情况下，从低到高版本之间，进行覆盖安装，测试功能是否正常。
这样写，简洁明了，测试不会在来找你说，『升级数据库这个，我要测试什么？』
本来是想贴一个常规的提测邮件的格式的，但是大多数公司的情况都不一样，各有各的情况，把握好上面提到的几点，一般都不会有什么问题。
提测邮件真的是可以有标准流程的，写的清晰明了大家工作效率都高，缺点内容可能测试人员拿到测试包之后，有些case没有覆盖到，导致一段未经测试的代码，就这么发布出去了，其实和一段代码在裸奔一样，是非常的危险的。
当然，一些常规的测试点，测试在发版前都会有一次回归测试。但是不要有侥幸心理，人来操作的事情，难免会有疏漏，把好自己这一关，不要让一个流程从你这里错误下去。
在平时测试中经常会遇到开发提测的问题，到底开发的提测邮件应该包含哪些内容呢，我在下面给大家提供一个模板，希望能给大家带来帮助：
项目名称：xxxx
当前版本号：v1.0
版本发布日期：2016-03-10
本次布署包包含以下文件：
应用包（xxx.zz）
接口包（xxx.zz）
数据库脚本（xxxx.sql、xxx.sql）
布署文档更新：写出更新的地方
本次提包的功能描述：
1、添加会员智能卡号
2、fix bug(bugid xxx、xxx)
提测版本的版本号、版本名，提测版本的下载包地址。
功能点，每个功能点的待测点和影响范围。
虽然从事开发行业的女生越来越多，但女生的比例还是远比不上男生。软件测试的男女生比例则基本相当，软件测试要求细心、耐心，大部分女生也是比较适合学的。而且软件测试课程分为手工测试和自动化测试，手工测试分为功能测试、性能测试、接口测试。自动化测试...
需要。很多人当初抱着测试不需要懂代码，才选择了这个行业，这个就要看对自己的职业定位了，是止步于月薪过万就可以了，还是往20k、30k去突破，如果这样的话，是肯定要会接口、会自动化，就必然要涉及到代码。如果真的看不懂代码，实际的测试后期的工作会出现...
在我看来游戏开发挺难的，尤其像手游一类的还有网游，里面有很多的程序代码而且伤神又费力，不过也有女生在这方面做的很好的，如果你感兴趣，非常想学，可以试试
软件测试专业现在很火热，很缺少人才，25岁学软件测试能学会，就业薪资也高，工作也相对轻松
测试类型有：功能测试，性能测试，界面测试。功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用...
这个其实和接口测试的场景密不可分的，比如说：外部接口测试： 必须先接口测试通过了，才能执行功能测试子系统或者各个模块之间的联调测试： 必须各子系统后台代码完成，并提供接口才可以完成测试，一般来说都要求各子系统功能测试通过后再进行...
这个是会因为公司的架构不同而不同的，并不是固定的，但是一般是会有专门的测试部门，或者叫质量保证部，也有可能是叫别的名字。
移动端测试，包括App兼容性测dao试，7*24小时稳定性测试，功耗性能测试，UI测试，交互测试等，课程主要学习的内容有：1、功能测试主要包括计算机基础、软件测试核心理论、Linux、数据库，学习目标是掌握软件测试核心理论，结合Linux、数据库等可实现移动端、w...
标题 1. 首先要做一个标题党（此标题党非彼标题党）。标题一定要清晰简洁易理解，不应该臃长 2. 尽量前缀要规范，例如模板： [Product][Version]_[Feature]_[Title]，这样描述会很清晰，也方便查找 3. 缺陷的标题一定要描述在什么情况下发生了什么问...
1、 缺陷报告可以记录缺陷2、可以对缺陷进行跟踪管理3、可以对缺陷报告进行分类 总结 统计
1、缺陷编号（Defect ID)，提交BUG的顺序。2、缺陷标题（summary),简明扼要的说明一下这个BUG。3、缺陷的发现者（DetectedBy) ,一般是自己。4、发现缺陷的日期（Detected on date)，一般是当天。5、缺陷所属的模块（subject)， 在测试哪个模块的时候发现的BUG...
缺陷标题好的缺陷标题需要让相关人员一目了然，一般建议的格式是条件+失败。缺陷类型缺陷类型也是根据具体的项目而定的。但一般情况下分为功能、界面、建议。重现步骤重现步骤的编写规则可以参考测试用例中的操作步骤 ，一定要足够详细、说明清楚问题的操作顺...
工具：NoSQLUnitJsTestDriverQTRunnerVenusFluintBuster.JSSQLUnitECUTQTestlibUnitilsgreatestDbUnitAbbotGoogleTest框架：JUnitMoqJSCaptureMockCUnitPyUnitCppUTestCppUnitzCUTcipra
JunitTestNGGoogleTestpytestunittestJmockitJaCoCogcov、lcov、gcovrCoverage.pyEvoSuiteDiffblue Cover
React Hooks测试库( Testing Library)是一个简单而完整的React Hooks测试工具。 React Hooks测试库让用户可以为React钩子创建简单的测试工具，自定义钩子的输入和检索输出，以处理在功能组件体内运行的情况。 使用React Hooks，用户不必为了测试而去担...
1、单元测试注重代码逻辑，接口测试注重业务逻辑；2、单元测试的粒度最小，是测试最小独立的单元模块（不依赖其他模块）；接口测试不是，会覆盖很多；3、单元测试是白盒测试，接口测试是黑盒测试；4、单元测试关注的是代码的实现和逻辑，测试范围较小，保证实...
最多设置5个标签!
{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','/static/images/logo.png', '推荐 末将听令 的问题《提测邮件一般要写哪些内容》','http://www.shouhuola.com/q-31793.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
一、先聊几句
一般产品的版本迭代都是一版版的在推进，每一个版本之间都要经历产品需求确定、开发、测试、升级、发版。
开发按需求开发完成之后，提测的过程，是一个和测试人员交接的过程。这个通常不可能说给测试口述本次改版改了哪些地方，一般而言，会发出一个提测邮件，来与测试交付本次测试。
可能有些人会说，按照需求文档来测试即可，但是很多时候，既定的需求和实际开发的需求是有变动的，开发对这个功能，具体如何实现，也决定了测试需要测试哪些case。
那么提测邮件，写什么，怎么写，很重要。
二、来写一份提测邮件
1、谁来写
一个版本的开发任务一般都不是由一个开发人员独立开发，是有多人配合的。那现在就需要有一个对本期改动细节都熟悉的人，知道有哪些变动，哪些功能的实现细节是否有提现。
技术小组组长一般可以承担起这个责任，因为他是必须把所有的功能代码的Pull Request(后文简称PR)都review一遍的人，了解本周期内所有的技术细节，所有的功能改动，知道什么地方的是必须测试的，知道什么地方是临界点需要着重测试的。
当然，如果每个开发人员，提交的PR非常的规范，写清楚提交点和待测试点，基本上只需要翻翻合过的代码，就可以写一封比较好的提测邮件了。
2、写什么
我觉得一篇合格的提测邮件，需要明确有几点，一定要在邮件里有体现。
提测版本的版本号、版本名。
提测版本的下载包地址。
提测功能点。
每个功能点的待测点和影响范围。
其实不太讲究什么格式，只要清晰，明确即可。包含这些信息，哪怕安装包打错了包，指错了安装包的地址，测试人员都可以很快反应过来。
对每个提测的功能点都要有细节说明，每个功能需要测试的场景有细节说明，对每个功能会影响的范围要有细节说明。
举个例子，在拿到分配任务的开始开发的时候，发现涉及到数据库的内容，当然Android端就是SQLite，因为业务需要，需要增加一些字段或者删除一些无用字段。我们知道，在Android中，如果对数据库表结构有修改，是要对数据库进行升级的，否者低版本升级上来的用户，SQLite中是没有你新增的字段的。这个时候如果不在测试邮件里表明，测试人员只是新安装，再进行测试，永远不会发现，从旧版本升级上来的用户，真的会崩溃的。
所以一定要在提测邮件里，标注，改了什么功能，影响的范围是什么，例如修改了数据库表结构，需要测试低版本在有旧数据的情况下，覆盖升级。
3、写给谁看
提测邮件当然是写给测试看的，但是通常来说，我们会抄送给一些人，例如：产品经理需要知道这些功能如期完工了，关键点也如同需求一样，他们也需要看懂提测邮件。
但是最重要的还是，一定要让测试人员能看懂。不要只是写修改点，一定要明确测试点，和功能触发环境。
一般的句式：新增Xxx功能，需要在Xxx环境中，测试Xxx。
从上面SQLite数据库升级来举例子，就是：修改数据库表结构，需要在低版本有数据的情况下，从低到高版本之间，进行覆盖安装，测试功能是否正常。
这样写，简洁明了，测试不会在来找你说，『升级数据库这个，我要测试什么？』
三、结尾
本来是想贴一个常规的提测邮件的格式的，但是大多数公司的情况都不一样，各有各的情况，把握好上面提到的几点，一般都不会有什么问题。
提测邮件真的是可以有标准流程的，写的清晰明了大家工作效率都高，缺点内容可能测试人员拿到测试包之后，有些case没有覆盖到，导致一段未经测试的代码，就这么发布出去了，其实和一段代码在裸奔一样，是非常的危险的。
当然，一些常规的测试点，测试在发版前都会有一次回归测试。但是不要有侥幸心理，人来操作的事情，难免会有疏漏，把好自己这一关，不要让一个流程从你这里错误下去。
在平时测试中经常会遇到开发提测的问题，到底开发的提测邮件应该包含哪些内容呢，我在下面给大家提供一个模板，希望能给大家带来帮助：
项目名称：xxxx
当前版本号：v1.0
版本发布日期：2016-03-10
本次布署包包含以下文件：
应用包（xxx.zz）
接口包（xxx.zz）
数据库脚本（xxxx.sql、xxx.sql）
布署文档更新：写出更新的地方
本次提包的功能描述：
1、添加会员智能卡号
2、fix bug(bugid xxx、xxx)
提测版本的版本号、版本名，提测版本的下载包地址。
功能点，每个功能点的待测点和影响范围。
相关问题推荐
虽然从事开发行业的女生越来越多，但女生的比例还是远比不上男生。软件测试的男女生比例则基本相当，软件测试要求细心、耐心，大部分女生也是比较适合学的。而且软件测试课程分为手工测试和自动化测试，手工测试分为功能测试、性能测试、接口测试。自动化测试...
需要。很多人当初抱着测试不需要懂代码，才选择了这个行业，这个就要看对自己的职业定位了，是止步于月薪过万就可以了，还是往20k、30k去突破，如果这样的话，是肯定要会接口、会自动化，就必然要涉及到代码。如果真的看不懂代码，实际的测试后期的工作会出现...
在我看来游戏开发挺难的，尤其像手游一类的还有网游，里面有很多的程序代码而且伤神又费力，不过也有女生在这方面做的很好的，如果你感兴趣，非常想学，可以试试
软件测试专业现在很火热，很缺少人才，25岁学软件测试能学会，就业薪资也高，工作也相对轻松
测试类型有：功能测试，性能测试，界面测试。功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用...
这个其实和接口测试的场景密不可分的，比如说：外部接口测试： 必须先接口测试通过了，才能执行功能测试子系统或者各个模块之间的联调测试： 必须各子系统后台代码完成，并提供接口才可以完成测试，一般来说都要求各子系统功能测试通过后再进行...
这个是会因为公司的架构不同而不同的，并不是固定的，但是一般是会有专门的测试部门，或者叫质量保证部，也有可能是叫别的名字。
移动端测试，包括App兼容性测dao试，7*24小时稳定性测试，功耗性能测试，UI测试，交互测试等，课程主要学习的内容有：1、功能测试主要包括计算机基础、软件测试核心理论、Linux、数据库，学习目标是掌握软件测试核心理论，结合Linux、数据库等可实现移动端、w...
标题 1. 首先要做一个标题党（此标题党非彼标题党）。标题一定要清晰简洁易理解，不应该臃长 2. 尽量前缀要规范，例如模板： [Product][Version]_[Feature]_[Title]，这样描述会很清晰，也方便查找 3. 缺陷的标题一定要描述在什么情况下发生了什么问...
1、 缺陷报告可以记录缺陷2、可以对缺陷进行跟踪管理3、可以对缺陷报告进行分类 总结 统计
1、缺陷编号（Defect ID)，提交BUG的顺序。2、缺陷标题（summary),简明扼要的说明一下这个BUG。3、缺陷的发现者（DetectedBy) ,一般是自己。4、发现缺陷的日期（Detected on date)，一般是当天。5、缺陷所属的模块（subject)， 在测试哪个模块的时候发现的BUG...
缺陷标题好的缺陷标题需要让相关人员一目了然，一般建议的格式是条件+失败。缺陷类型缺陷类型也是根据具体的项目而定的。但一般情况下分为功能、界面、建议。重现步骤重现步骤的编写规则可以参考测试用例中的操作步骤 ，一定要足够详细、说明清楚问题的操作顺...
工具：NoSQLUnitJsTestDriverQTRunnerVenusFluintBuster.JSSQLUnitECUTQTestlibUnitilsgreatestDbUnitAbbotGoogleTest框架：JUnitMoqJSCaptureMockCUnitPyUnitCppUTestCppUnitzCUTcipra
JunitTestNGGoogleTestpytestunittestJmockitJaCoCogcov、lcov、gcovrCoverage.pyEvoSuiteDiffblue Cover
React Hooks测试库( Testing Library)是一个简单而完整的React Hooks测试工具。 React Hooks测试库让用户可以为React钩子创建简单的测试工具，自定义钩子的输入和检索输出，以处理在功能组件体内运行的情况。 使用React Hooks，用户不必为了测试而去担...
1、单元测试注重代码逻辑，接口测试注重业务逻辑；2、单元测试的粒度最小，是测试最小独立的单元模块（不依赖其他模块）；接口测试不是，会覆盖很多；3、单元测试是白盒测试，接口测试是黑盒测试；4、单元测试关注的是代码的实现和逻辑，测试范围较小，保证实...