本文章转载于搜狗测试
前言
一个完整的测试流程最终都是以测试确认信作为结尾的~结尾有没有彩蛋呢？请继续往下看~~
确认信的目的：
1.通知关注该任务的相关人员测试结论
2.测试人员认为需要相关人员关注的事项、风险等在确认信中表明
3.确认信作为相关事项及状态的备忘
注：发送上线确认信的目的可归结为一句话：别人关注的事情我们给出结论，我们做过的事情让别人知道
确认信内容:
1. 收件人与抄送人
收件人：修改本次功能的开发，产品
抄送人：开发组，产品组，测试组，设计组以及参与本次功能的人员leader
2. 标题
【项目+版本】+结论+产品确认
例如：【手机端助手Android 6.0】测试完毕，请产品确认
3. 测试结论
结论性语句：验证通过或者验证完毕
例如：手机助手6.0版本验证完毕，详细测试结论如下，请产品确认
4. 相关提醒——无提醒可不写
提醒语句，使用@符号
例如：@具体人员：请确认6.0版本后台上线配置是否是真实数据
5. 测试包版本信息
最终测试包的版本信息：
#版本号、versioncode、MD5、filesize、安装包地址（也可将安装包放在附件中，但考虑到邮件系统的容量，最好是提供下载地址）
6. 上线风险
说明：上线风险的评估可以参考以下思路
① 基本功能：
# 上线前未解决的功能性bug
# 来源：bug 系统中未关闭的功能性bug(比如：遗留问题、技术不支持问题等)、需求阶段已知的无法解决的功能性问题
② 用户体验：
# 对用户造成伤害、误导、不易操作等情况
# 来源：建议类型Bug、测试过程中已知但影响较小未提交的操作风险
③ 未充分测试内容
# 由于环境、机型等原因导致无法测试的功能
注意事项：
① 所有风险必须三方确认，而且在发出确认信之前先进行确认，再发确认信
② 每个风险都要备注产生风险的原因，以及导致的影响
③ 个别（机型，rom，系统）必须罗列在例如当中：可使用“个别。。。由于。。。导致。。。。；例如：。。。”语句
7. 本版本开发修改内容
本版本的所有改动（可能来自需求，也可能来自开发的优化）
来源：需求文档、jira（注意check后再做拷贝）
需求标题较长时，需简化且不丢失表述、易懂
8. 测试验证内容
适用于小版本或是bug需求修改
# 对此需求的验证点（注：不是用例）
对于大版本，建议从以下方面描述
# 新功能验证点
# 兼容性
# 稳定性
# 内存
# 回归性
9. Bug状态
版本内所有Bug状态，注：已全部与开发、产品同学确认最终结论
标注、备注严重Bug
对于备注注意必须与现在的Bug状态的一致
例如：
Bug状态（所有风险均经过开发、产品、测试确认同意遗留）
该版本新提交bug 60个（其中8个开发修改中），详细bug状态如下：
注：
1. 全文使用微软雅黑五号字体、格式对齐
2. 确认信发出前必须check一次，避免遗漏或是有错别字
