[TOC]

性能测试流程

如何做性能测试

0.前期准备

1. 尽量参与业务需求评审，可以对业务有更深刻的了解
2. 了解哪些是核心业务，哪些可能存在并发请求
3. 在了解后，可以在业务评审时给出性能需求意见

   1.性能需求分析、评审

4. 明确性能测试的范围，包含哪些业务接口（使用多的核心业务）
5. 性能测试的目标是多少（TPS、响应时间rt、成功率或者+其它的技术指标），性能需求要项目组一起来商量一起来出，如果出不来就由性能测试人员来引导出这个性能测试目标
6. 关于需求来源：迭代项目/新项目 迭代项目： 范围：新增的、修改的、受影响的 目标：不能低于之前版本的性能、未来所需的容量的预估 业务比例：业务请求的比例（单接口），通过类似ELK之类的日志平台来统计
   新项目： 范围：核心业务功能 目标：参考竞品、经验值（寻求产品经理确认） 业务比例：项目组讨论、项目试运行后统计、要测试出最大容量TPS，为上线后限流提供参考

   2.制定性能测试方案

7. 项目背景： 背景描述 系统架构 * 压测目的
8. 术语说明：为了避免理解存在偏差 * TPS、响应时间RT、并发、业务比例、单场景、容量场景（混合场景）、稳定性场景
9. 性能测试需求：测试范围、目标 要压测的接口清单，以及业务比例 各个场景的目标：TPS、RT、成功率
10. 测试资源 人力资源：项目经理、性能测试工程师、开发工程师、运维工程师 压测工具（压力端）：Jmeter、压力机（win/Linux） * 压测环境：硬件、软件、部署
11. 压测设计 数据： 参数化数据：数据量根据业务来
    唯一性：tps500，压测时间600s，至少需要300000数据量，乘以20% 非唯一性：tps500，也是压测时间600s，至少覆盖线上实际被使用到的 数据库存量（基础数据）：数据量和生产量级保持一致
    场景： 单场景：单个业务接口，可以发现明显的性能BUG（目标TPS要比容量场景对应接口的目标TPS要高） 容量场景（混合场景）：结合业务比例模拟线上真实业务场景（因为：线上环境，每个接口的调用次数不一样） 稳定性场景： 明确压测时间设置多少？ jmeter中，tps=总请求数/并发时间，并发时间=总请求数/tps，例如：5000万业务量/800的TPS=62500s，建议时间120% 目标业务量/最大容量tps，最好比这个时间更多(1.2)
    加压方式： 秒杀、抢购：瞬间产生压力 非秒杀、抢购：逐步阶梯加压
    监控：根据压测接口的链路涉及的技术栈，选择合适的监控工具 * 比如：链路监控工具是微服务的标配（JAV项目）
12. 测试计划 * 里程碑节点计划，详细的项目性能计划
13. 风险评估 * 根据当前情况，预估可能的风险以及措施
    
14. 测试准则/参考资料

    3.性能测试方案评审

    • 评审通过后，方案发送给项目成员，如若后续未再反馈其它问题，表示认可方案通过

      4.申请性能测试环境

    • 简单架构：nginx + Tomcat + mysql 比如1个tomcat：tps100 2个tomcat：tps180（存在20tps损耗，根据损耗率预估-生产上可以达到多少tps）
    • 复杂架构
    • 新项目的话，可以直接在线上环境进行压测

      5.性能测试用例及评审

      6.搭建测试环境

    • 根据压测环境的部署去搭建应用和监控

      7.准备测试脚本、测试数据

    • 脚本：开发提供压测环境调通的postman或者jmeter脚本；或者根据接口文档写
    • 场景设计
    • 准备数据 参数化数据 代码生成 从数据库导出 数据库存量数据 复杂表关系：jmeter跑业务接口【推荐】 单表：代码、数据库存储过程（多个sql集合，循环添加）

      8.环境确认测试

    • 静态测试：确认配置
    • 非静态测试：确认环境是否可用

      9.执行压测并监控

    • 不要一次性打开所有监控，每一步需要哪个监控就开哪个监控

      10.分析定位

    • 简单架构：可以看资源消耗进行分析
    • 复杂架构：服务太多，通过分解时间的方式 举例：场景比对--怀疑是xx服务资源不足，增加节点 可能功能时间都差不多，进行功能隔离

      11.性能优化

    • 如果有自己的优化方案，可以发给项目组进行抛砖引玉，如果有更好的优化方案，就可以进行应用
    • 没有方案，寻求项目组协助

      12.性能回归

      13.编写性能报告

    • 核心内容 ==测试过程详情及分析==：每个场景的执行结果（截图），并分析结果 ==测试总结及建议（重点）==：测试结果是多少？测试是否通过？发现什么问题？原因是什么？优化方案是什么？优化后系统性能提升了多少倍？ ==问题汇总==：罗列发现的所有问题，包含问题现象（比如日志截图）、监控截图。 ==风险评估==：遗留风险问题 （虽然测试达标了，但是因为外围系统做了挡板、压测环境配置和生产比比较低等因素，可能存在一些风险，给出建议） * ==优化清单==