某金融产品的测试方案
背景介绍
xx收入系统是一款收入管理平台
业务介绍
xx收入系统是基于公司旗下对外销售的产品进行收入管理，包括业务收入上报、收入确认、应收收款核销等流程，支持公司财管角色用户通过收入系统各单据流水对账，输出财务报表。
架构介绍
l收入上报
l收入确认
l应收收款核销
…
测试计划
测试目标
阶段 阶段 目标 时间
阶段一 功能测试 质量提升 Q1
阶段二 性能测试 性能调优 Q2
阶段三 自动化测试 效率提升 Q3
阶段四 持续集成持续交付 效率提升 Q4
测试策略
功能测试策略
为了更好的完成功能测试，提高产品质量及测试效率，制定了以下测试方案
背景
- 很多业务流程相似；
- 业务比较复杂，关联性较强。
问题： - 每次迭代编写测试用例重复性高，经常性某个模块或某种场景bug率较高
- 业务比较复杂，关联影响评估不足，导致漏测
解决方案
- 测试用例设计阶段
- 抽离常用测试点、测试流程，bug率较高业务场景，梳理checklist，每次迭代用例判断是否关联checklist，如关联直接复用
- 梳理主流程业务测试用例，每次版本迭代回归
- 测试数据保证多样性，模拟生产使用场景
- 用例评审阶段
- 与需求、开发共同评估确认关联影响，查漏补缺
- 增加主流程业务测试用例评审，保证每次迭代不影响主流程业务
- 用例执行阶段
- 多熟悉业务背景，基于业务操作进行用例执行
- 主流程业务回归采用自动化测试实现
成果
- 降低线上bug发生率50%左右，提升产品质量及用户体验性。
- 提高测试效率，减少重复性工作耗时。
性能测试策略
随着用户量的增加，系统的性能不能满足用户的需求，为了满足用户日常使用，提升系统的用户体验感
解决方案
通过系统的单接口负载压测和系统稳定性压测，分析系统性能瓶颈，优化接口达到性能标准，针对优化代码无法解决接口的性能瓶颈，通过扩大服务器容量来满足需求。
方案实施
- 性能测试方案设计
- 测试环境：根据业务数据准备测试环境的硬件、软件的大小
- 测试指标：明确响应时间、吞吐量、CPU使用率、内存使用率的标准
- 测试数据：根据系统用户量，28法则明确测试数据量
- 测试场景：根据业务梳理测试场景，如系统使用频繁的接口、新增/修改接口、特殊接口要求快速响应、大数据量接口
- 测试策略：单接口负载测试、接口稳定性测试
- 测试工具：选择合适工具如jmeter、监控平台搭建
- 测试执行：执行压测脚本并收集测试数据
- 结果分析：根据压测数据分析性能瓶颈，明确后续服务器资源
- 性能测试方案评审
- 检查性能测试方案不合理点
- 性能压测脚本设计
-针对依赖其他接口返回结果入参的接口如何设计脚本，通过json提取器、BeanShell后置处理器- 针对大数据量的接口怎么mock数据
- 业务场景复杂性
- 性能压测脚本评审
- 解决脚本设计是否存在不合理或者影响性能风险点
- 准备压测环境
- 准备压测环境明确服务器硬盘和内存
- 被压测环境大数据量准备：如何造测试数据
- 监控平台：监测压测过程的CPU使用率和内存使用率
- 执行压测脚本
- 执行压测测试服务器脚本执行、部署到jenkins执行
- 收集压测数据、监控平台
- 输出测试报告
- 输出性能测试报告编写测试报告
- 分析系统的性能瓶颈，提出解决方案
- 性能调优
- 性能调优推动开发优化系统性能瓶颈问题
- 归还验证
总结
- 结果大大提升系统的性能及系统稳定性
- 明确服务器扩容量，最大程度缩减成本
效能提升策略
自动化测试方案
背景
随着当前项目业务的发展，后端接口越来越多，更新越来越频繁，造成开发侧更新接口文档不及时、不全面，测试侧手工回归接口测试任务工作量大、接口测试工具五花八门、测试效率低下，测试结果未能及时报告到相应干系人，开发侧转测质量低等问题突出，不仅带来了项目的时间、人力成本增加，更是无法保障项目交付质量，而公司的测试平台已经上线，并已经支持了项目版本管理、流水线任务管理，测试计划管理、测试套件管理、测试用例管理、测试报告管理等功能，基于此情况，项目推进全面实HTTP/HTTPS协议的后端接口自动化测试。
方案
- 通过采用Python+Pytest+requests+jsonpath+allure的自动化测试框，实现自动化测试工具的开发，统一采用自动化测试工具，把后端接口测试全面转成自动化测试；
- 约束开发侧，所有后端接口通过Swagger在线接口文档输出；
- 通过Swagger在线接口文档，自动生成后端接口测试用例到excel表格接口用例文档中；
- 对每条接口测试用例按照用例优先级、业务功能模块、项目版本号进行标记，导入到测试平台进行管理；
- 自动化测试用例采用数据驱动理念，对各个接口用例补充相应前置条件、测试数据和期望结果；
- 开发侧转测前需要自动化跑通后端接口冒烟测试用例；
- 对每次测试结果保存到测试平台中，并且及时通过邮件分发给项目干系人；
任务
- 自动化测试工具开发；
- 接口测试用例生成和编写；
- 跟测试联调自测；
成果
- 实现了每个版本的后端接口全量业务自动化测试回归执行，接口回归测试工作量从15人天，降到3人天，提升效率5倍；
- 实现了根据用例分级分业务模块分项目版本号进行勾选，实现自动化接口用例自定义测试回归；
- 对开发侧转测的质量大大提升，版本打回率降低到5%；
- 实现了接口自动化测试结果自动归档并自动分发到项目干系人，让项目经理更加及时准确的了解项目进度和项目质量；
- 提升测试团队的测试技术、激发了测试人员工作激情、提高了项目质量；
持续集成持续交付方案
背景
开发在频繁部署时，有时会造成某些关键业务功能不可用，影响测试环境的稳定以及提测效率，需要测试左移对质量进行管控。为此，搭建一个持续集成持续交付模式，使自动化流程来的更快、更频繁、更可靠的构建、测试和发布。
方案
- 建立自动化用例库
- P0案例集
- P0+P1案例集
- 完成测试后，发送邮件给干系人
- 引入Sonar代码扫描
- 推动开发写单元测试
- 设立代码准入规则，对代码进行提交、合并等操作时，对每个节点进行检查
- 单元测试：提交代码的节点，前期覆盖率阈值暂定30%，中期50%，后期80%
- Sonar扫描：提交代码时，GitLab的Hook触发Jenkins的Sonar扫描任务
- 自动化测试：合并代码的节点，P0案例集通过率100%
- 把持续集成接入发布平台，在开发分支合并时触发集成测试，测试结果通过后自动发布
- P0+P1案例集的通过率在90%
成果
- 因为P0+P1案例的门禁，测试环境的稳定性提高了，再也没有发生过因代码问题而引发的测试环境异常
- 开发的代码质量提高了，最开始的时候只要求单元测试覆盖率是30%，逐步推进，目前单测覆盖率要求最低50%，后期要求80%
- 后端需求的移测成功率达到了100%
- 减少返工，测试人效平均减少1人日