一、引言
1.1 目的
为了明示测试发布环节中各角色负责事项，改进流程中容易忽略的问题；
为了确保上线版本的质量，对测试环节和发布环节进行合理管控；
制定准入准出规范，为团队在项目过程中提供规范性指导。
1.2 范围和执行
本规范适用于正常的测试和发布环节，紧急线上事故修复不受此规范约束；
规范明确了各角色需要完成的事项，未写明的部分皆由测试同学负责推动；
规范具体实施根据开发提测环节和测试通过发布环节来决策执行。
二、测试发布流程
2.1基本流程
测试发布流程如下图所示：
2.2 测试环节
功能测试：单独功能/Story级别的测试
版本测试：集成系统/流程的完整测试
接口测试：新增接口的正常和异常
性能测试：接口、活动或架构的性能测试专项
兼容性测试：针对不同机型的兼容性
2.3 发布环节
发布：考虑业务体验、灰度和发布后留守观察线上数据
三、测试标准
3.1 功能测试
3.2 版本测试
3.3 性能测试
3.4 兼容性测试
四、发布标准
五、疑问解答
1、开发问为什么要做规范，之前做的不好吗？
答：规范不是针对某个角色，是为了明确研发流程的各角色的责任，不负责的地方进行释放；
如果团队现状跟规范一致，说明质量环节与一线公司流程一致；
对于以往默认放过的问题，希望通过规范能明确出来，进行改进。
2、加入开发自测用例，产品体验环节，还需要测试做什么？
答：开发和产品的自测验证环节的粒度很粗，目的是为了解决最低级的问题（流程不通、实现错误）；
测试需要执行几千条*N轮详细测试用例（N取决于代码质量）；
需要对代码的异常路径、边界值、特殊场景、集成性能、自动化等专项进行测试和执行。
3、怎么推广？规范是安排团队进行试点执行吗？
答：从内部系统项目先行试点。
4、特殊情况如修复紧急问题需要走流程吗？
答：引言说的很清楚，特殊紧急情况不用完全遵守规定，功能相关角色应该第一时间配合修复上线；
目前作为纲领文件是可以的，执行的时候还需要有细则。不然没有量化指标，就没有人对结果负责；
规范是纲领和执行文件的混合体，在普遍适用的关键点设定了指标(需求开发完成80%转测)；
不再更细化的原因是，规范本身最重要目的在于明确大家的任务和结果。而对于具体执行项和程度应该由项目组团队根据自身情况进行调整和确认，规范不应该成为沉重的流程；
比如产品or运营体验换机，应该在本次提测邮件基础上回复–产品or运营已体验即可。
5、如何做到质量和响应时间的平衡？
答：对质量要求提高后，将质量问题引起的反复转测提前到转测试环节
对于固定上线时间的产品，集中测试资源全力配合验证。至于结果是有损体验发布还是完整修复后发布，根据项目组集体来决定；
对于响应慢的情况，我们仔细分清楚哪些是能优化后，改进的慢？项目组要持续优化；
哪些是不项目本身需要，不能做优化的慢？我们记录下来，以后再提供给业务侧解决方案时我们有预估数据基准。