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