一、背景
近期代理了服务端测试团队，由于之前并未规范好测试流程，有时会出现流程节点混乱、测试人员分配不均等情况。现在重新梳理了服务端测试流程，也方便后续对团队中测试的规范管理。
二、测试流程分析图
三、流程阶段
1. 需求阶段
了解项目背景（产品的用户对象、变现方式等）、了解需要实现的功能点、了解模块间的关系
2. 设计阶段
明确测试颗粒度，需要落地什么样的测试策略同步给开发和产品。
测试职责：
- 明确执行结果（便于定义接口用例的期望值）
- 确保可测试性（开发/运维有没有提供可测的测试环境，例如功能点的服务实现、接口交互有可能依赖某些三方服务，只有生产环境才能接入，测试环境无法接入，此时正常流程无法走通，需要开发写桩、写死交互逻辑去闭环这个问题）
- 明确测试颗粒度（是否需要进行接口、性能、功能测试；如果要进行接口测试，要关注例如开发是否做了入参校验的问题，否则测试无意义）
- 确定测试周期（了解服务的最终交付预期，测试结束时间肯定不能超过最终交付的时间）
1）制定测试计划
计划文档包括：
- 背景描述
- 拆分任务项
- 对每个任务项的定义：开始条件、结束条件、负责人、交付结果（文档、邮件、文件）
- 风险评估（测试环境部署问题、人员风险、测试质量）
测试职责：
- 评估工时(用例设计、用例评审、自动化框架搭建、自动化脚本编写、版本发布测试、冒烟测试、三轮测试、故障演练、预发布测试、放量测试)
- 明确每个节点交付结果
- 可能存在的风险情况(可测试性、时间、人力)
- 同步计划
2）设计测试策略
- 根据用例设计和用例设计模版输出全量测试用例
- 设计服务端故障演练的场景
- 设计放量测试策略
- 若为迭代需求时，设计数据升级测试用例
3）测试策略评审
- 评估策略的可行性
- 确保策略的正确性
- 是否遵循流程规范等
4）自动化框架搭建及接口用例转换
搭建框架：
- 特殊协议，实现请求方法、结果获取的方法
- 基于业务层封装数据处理方法
- 复用基础框架
全量用例转化：
- 先转化主流程测试用例，其他input、handle的用例围绕主流程测试用例进行调整，并且需要确保用例100%脚本化。
3. 提测阶段
提测门禁
- 检查是否满足门槛(开发是否完成自测工作，确保单元测试的覆盖率)
- 提测时间是否符合预期
4. 测试阶段
1）版本发布测试或数据升级测试
- 版本发布测试（根据部署文档来部署，部署完成后验证主流程，主流程如果满足期望值说明部署文档可靠）
- 数据升级测试
前置：在测试环境先部署好v1.0的版本，构建v1.0的数据（跑跑业务主流程）
测试方法：由开发提供版本升级文档（上线流程文档），由测试这边根据文档进行服务升级，升级好后，验证v1.0数据处理的正确性，验证v2.0所有的主流程（冒烟测试）
2）冒烟测试
- 验证主流程场景无问题
- 调试脚本，确保全量脚本的可靠性，主流程用例跑不通的话提测打回
3）正式测试执行
- 第一轮全量用例执行
- 第二轮bugfix回归
- 第三轮全量用例回归
- 其他测试策略执行（如服务故障演练等）
5. 测试输出
1）代码覆盖率统计
等到执行时已经没有未解决的缺陷或存在影响流程的问题缺陷，我们就会开始统计，访问测试环境的服务器，部署代码覆盖率统计工具并启动，启动工具后启动被测服务并执行接口自动化测试用例，用例执行结束后采集结果，评估代码覆盖率结果是否达到所定义的阈值（80%），如果未达到，检查覆盖不到的场景，补充相关用例继续测试。
2）测试报告输出
先阐述测试结果，项目的测试背景、描述测试测试方案、测试执行情况（用例数、缺陷数、已关闭的bug数）、附件测试用例、相关负责人、遗留的问题、风险点等。
6. 上线阶段
放量测试
可以根据每次调配的流量权重比例来确定不同测试阶段的测试策略。
- 放量比例：1% → 10% 阶段
- 进行业务功能流程的校验。
- 启动配置项的校验。
- 比例1%运行正常，再调到10%运行。
- 放量比例：10% → 50% → 60% → 70% → 80% 阶段
- 每次比例上调都延长运行时间，比如10%运行1小时，调到50%可运行半天。
- 出现内存溢出等问题，可以调回上个比例，知道问题解决再进行放量.
- 放量比例：80% → 90% → 100% 阶段
- 通过日志观察旧版本服务无运行数据，再回收旧版本服务实例。
- 放量比例100%后可以运行一两天，放量测试才结束。
