一个规范的测试流程可以减少重复劳动，提升团队协作效率，保障测试工作的全面性和质量，能及时发现问题，闭环问题，减少生产成本。本文主要对我们公司的测试流程进行总结。
需求了解→设计评审→编写测试计划→编写测试用例→用例评审→搭建接口自动化框架→进行全量用例的脚本化→提测门禁→执行→代码覆盖率统计→测试报告
需求阶段：
了解项目背景（了解产品的用户对象、变现方式）、了解需要实现的功能点、了解模块间的关系。
设计评审：
通常在评审前会前置的拿到设计文档、接口文档，提前了解底层服务实现，把可能存在的问题和疑问点记录起来在评审对齐信息，在评审期间，需要明确测试颗粒度、明确执行结果、功能完善优化、了解项目交付的周期（是否能够在规定时间内完成测试工作）。
测试计划：
输出文档，和相关的开发成员、测试 leader 对齐计划
项目的测试背景、需要覆盖的模块、如果是迭代需求了解影响面。
明细化测试工作的任务项（测试用例、用例评审、框架搭建、冒烟测试、全量测试、回归测试、测试报告、代码覆盖率统计）。
负责人
开始结束时间
任务项交付结果
风险评估
接口自动化框架搭建：
前置了解被测服务协议，根据协议封装 business 模块，减少编码成本，接着复用成熟的通用框架，日志生成模块、通用的断言方法、配置读取方法、用例批量执行方法、环境切换方法、报告生成方法的实现。
全量用例脚本转换：
先转换主流程测试用例，其他input、handle的用例围绕主流程测试用例进行调整，并且需要确保用例100%脚本化。
提测门禁：
提测前我们测试会提供接口的主流程测试用例给到开发，开发需要确保用例结果的正确性，其次还需要明确相关服务增量代码覆盖率达到99%的指标，才允许提测。
用例脚本执行：
先执行主流程测试用例，顺便调试脚本，确保全量脚本的可靠性，主流程用例跑不通的话提测驳回，否则执行全量用例，将断言失败的测试用例编写成问题单提交到缺陷管理平台，当进行完一轮全量测试以后才允许开发提交bugfix代码到测试分支上，接着再进行第二轮的全量脚本执行，通常需要执行三轮全量的测试用例。
代码覆盖率统计：
等到执行时已经没有未解决的缺陷或存在影响流程的问题缺陷，我们就会开始统计：
访问测试环境的服务器--->部署代码覆盖率统计工具并启动--->启动被测服务--->执行接口自动化测试用例--->采集结果--->代码覆盖率结果达到阈值85%（如果未达到进行原因分析，补充未覆盖场景用例，重新执行用例统计指标）。
测试报告：
先阐述测试总结，项目的测试背景、描述测试方案、测试执行情况（用例数、缺陷数、已关闭的bug数）、附件测试用例、相关负责人、遗留的问题、风险点。
预发布测试
目的：保障项目能够在线上环境稳定运行
介入时机：项目测试环境稳定后
step1：准备一个线上的预发布环境，访问入口只开放对应的测试人员（有可能是开放公司 ip 的白名单）
step2：主流程场景校验。
step3：相关的密钥信息是否有更新，不能直接用测试环境的。
放量测试：
目的：确保真实用户访问项目还能保持服务的稳定性，并且当前项目可以满足线上的用户流量。
介入时机：项目准备上线
step1：通过控制流量分发的权重，分配1%的真实用户量到新版本的服务实例，稳定运行15~30min
step2：放量10%，稳定运行15~30min
step3：放量30%，稳定运行15~30min
step4：放量50%，稳定运行1d
step5：放量80%，稳定运行1d
step6：放量90%，稳定运行1d
step7：放量100%，稳定运行1d
在放量测试期间需要关注命中到的真实用户事务，是否正常，通过查看日志去分析；同时还要关注被测服务的资源利用率。如果在某一量级存在事务失败或资源利用率等问题，可以回滚到上一级的权重，再精准定位问题解决问题。
评论区