[TOC]

性能测试流程

如何做性能测试

0.前期准备

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

1.性能需求分析、评审

1. 明确性能测试的范围，包含哪些业务接口（使用多的核心业务）
2. 性能测试的目标是多少（TPS、响应时间rt、成功率或者+其它的技术指标），性能需求要项目组一起来商量一起来出，如果出不来就由性能测试人员来引导出这个性能测试目标

3. 关于需求来源：迭代项目/新项目

   • 迭代项目：

     • 范围：新增的、修改的、受影响的
     • 目标：不能低于之前版本的性能、未来所需的容量的预估
     • 业务比例：业务请求的比例（单接口），通过类似ELK之类的日志平台来统计

   • 新项目：

     • 范围：核心业务功能
     • 目标：参考竞品、经验值（寻求产品经理确认）
     • 业务比例：项目组讨论、项目试运行后统计、要测试出最大容量TPS，为上线后限流提供参考

2.制定性能测试方案

1. 项目背景：

   • 背景描述
   • 系统架构
   • 压测目的

2. 术语说明：为了避免理解存在偏差

   • TPS、响应时间RT、并发、业务比例、单场景、容量场景（混合场景）、稳定性场景

3. 性能测试需求：测试范围、目标

   • 要压测的接口清单，以及业务比例
   • 各个场景的目标：TPS、RT、成功率

4. 测试资源

   • 人力资源：项目经理、性能测试工程师、开发工程师、运维工程师
   • 压测工具（压力端）：Jmeter、压力机（win/Linux）
   • 压测环境：硬件、软件、部署

5. 压测设计

   • 数据：

     • 参数化数据：数据量根据业务来

     唯一性：tps500，压测时间600s，至少需要300000数据量，乘以20%
     非唯一性：tps500，也是压测时间600s，至少覆盖线上实际被使用到的

     • 数据库存量（基础数据）：数据量和生产量级保持一致

   • 场景：

     • 单场景：单个业务接口，可以发现明显的性能BUG（目标TPS要比容量场景对应接口的目标TPS要高）

     • 容量场景（混合场景）：结合业务比例模拟线上真实业务场景（因为：线上环境，每个接口的调用次数不一样）

     • 稳定性场景：

       • 明确压测时间设置多少？
       • jmeter中，tps=总请求数/并发时间，并发时间=总请求数/tps，例如：5000万业务量/800的TPS=62500s，建议时间*120%
       • 目标业务量/最大容量tps，最好比这个时间更多(*1.2)

     • 加压方式：

       • 秒杀、抢购：瞬间产生压力
       • 非秒杀、抢购：逐步阶梯加压

   • 监控：根据压测接口的链路涉及的技术栈，选择合适的监控工具

     • 比如：链路监控工具是微服务的标配（JAV项目）

6. 测试计划

   • 里程碑节点计划，详细的项目性能计划

7. 风险评估

   • 根据当前情况，预估可能的风险以及措施

8. 测试准则/参考资料

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.编写性能报告

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