什么是性能测试？如何做性能测试？

---

前言

      性能测试是软件开发过程中不可或缺的一环，它旨在通过自动化的测试工具模拟多种正常、峰值以及异常负载条件，对系统的各项性能指标进行全面评估。这一测试过程不仅能够帮助我们识别并消除应用程序中的性能瓶颈，还能确保系统在各种负载条件下都能稳定运行，满足用户的实际需求。

      本教程将详细介绍性能测试的基本概念、重要性以及实施步骤，帮助读者全面了解和掌握性能测试的方法和技巧。无论您是测试新手还是有一定经验的测试工程师，都能通过本教程获得实用的知识和实践经验，为您的软件项目提供更加可靠的性能保障。接下来，让我们一起深入探讨性能测试的奥秘吧！

---

 

 

一、什么是性能测试

通俗地讲，性能测试就是检查一个系统或软件在承受各种工作负载时，它的表现如何。这就像你买了一辆新车，不仅要看它的外观和内饰，更想知道它在高速行驶、爬坡、满载等情况下的表现，比如油耗、速度、稳定性等。

在软件或系统领域，性能测试会模拟用户在实际环境中可能遇到的各种场景，比如高并发访问、大数据量处理、长时间运行等，然后观察系统的响应时间、吞吐量、资源占用率等指标，从而评估系统的性能是否满足预期。

具体来说，性能测试可能包括以下几个方面：

1. 基准测试：在没有任何负载的情况下，测试系统的基本性能。
2. 负载测试：逐渐增加系统的负载，观察系统在不同负载下的性能表现。
3. 压力测试：模拟系统可能遇到的最大负载，测试系统的抗压能力。
4. 稳定性测试：长时间运行系统，观察系统是否会出现性能下降、崩溃等问题。
5. 并发测试：模拟多个用户同时访问系统，测试系统的并发处理能力。

通过性能测试，开发者和测试人员可以了解系统的性能瓶颈，优化系统设计，确保系统在实际使用中能够稳定、高效地运行。

 

二、如何开展性能测试？

1、明确测试目标和需求

比如，我们6.18做活动，需要测试大批量用户进入百度网站首页的性能情况，一般实际情况下，产品经理或者项目经理在提需求之前，都会制定测试目标指标，如果没有制定，那么就需要自己去分析项目背景后去制定。

目标，可以通过接口清单来识别，或者自己去扒代码，后者自己去抓包，要尽可能的全面，都可以。梳理出来需要压测的目标接口以后，再去梳理接口的业务功能、依赖的上下游服务调用链路、数据库配置和库表等等。根据需求背景和接口功能，科学制定每个接口的通过指标，指标包含了平均响应时间、TPS等。比如，登录接口比较重要，可以指定为TPS>3000，95RT<1S,自己制定的目标和指标，还需要跟产品和开发讨论，避免错漏。

如下图：

 

 

2. 测试准备

2.1，首先要准备好压测机，目前大部分公司都有JumpServer这样的机器，如有，最好就用这种机器，因为网络和配置相对稳定。如没有就视情况准备1台或者多台电脑（分布式压测）；

2.2，制定扩容方案（一般先纵向扩容，再横向扩容）。准备对测试环境应用服务、数据库、网关等进行扩容，扩容可以扩到与生产环境一致，或者按照比例扩，总之要在压测前扩好；

2.3，准备脚本，脚本一般使用JMeter编写，脚本的编写要尽量使用参数化，这一步这里不单独讲，作者另外有文章专门讲脚本的编写。

2.4，准备压测数据，为了保证压测结果的准确，我们需要将测试环境的数据量保持与生产环境一致，造数据，我们可以通过前置接口去造，或者依赖数据库的存储过程，存储过程造数据，另外也有文章教程。造的数据记得要做好标记，压测完需要清理掉。

2.5，提前准备监控，目前很多公司都上云了，可以通过阿里云的RDS数据库监控、kubernetes容器监控、云监控、ARMS监控，等手段来监控各服务的性能情况，ARMS需要提前打桩；如果没有上云，那就远程连接linux服务器，通过命令来监控了。

2.6，一般的大型压测或者比较重要的业务压测，我们需要把压测时间、服务等信息，告知有关联的开发和测试团队，运维团队，避免压测时影响到其他人的使用，以及人员的支持。特别是压测生产环境时，一定要提前邮件告知各方团队，严格按照计划压测。

 

3. 选择测试方法和工具

• 负载测试：逐渐增加系统的负载，观察系统性能的变化情况。
• 压力测试：在系统达到饱和状态下，测试系统的稳定性和错误处理能力。
• 工具选择：根据测试需求选择合适的性能测试工具，如JMeter、LoadRunner、Gatling等。

4. 执行测试

4.1压测时，我们需要随时观察：上下游服务、数据库、网关服务的性能表现，主要关注服务的CPU、内存、TPS、JVM等。以及JMeter中聚合报告的吞吐量、响应时间等关键性能指标；

4.2，通过以上性能表现，我们需要实时调整压测的并发数，最终把性能瓶颈找到。

 

5. 分析测试结果

• 对比预期目标：将测试结果与预期的性能指标进行对比，评估系统是否满足需求。
• 定位性能瓶颈：分析测试结果，找出系统中的性能瓶颈，如数据库查询、网络传输等。
• 这儿我们重点看一下聚合报告，JMeter的聚合报告（Aggregate Report）是性能测试结果分析的核心工具之一，它提供了多项关键指标来评估系统的性能表现。以下是各项指标的详细解析，包括定义、计算方式、实际意义及使用场景。

  ---

  1. Label（标签）
  - 定义：测试计划中每个请求的名称（如HTTP请求、API接口名称）。
  - 作用：区分不同请求的测试结果，便于对比分析。

  ---

  2. Samples（样本数）
  - 定义：该请求的总执行次数（成功 + 失败）。
  - 计算公式：`Samples = 成功数 + 失败数`
  - 意义：
  - 检查是否达到预期的并发量。
  - 如果样本数远低于预期，可能意味着线程未正常启动或系统过早崩溃。

  ---

  3. Average（平均值）
  - 定义：所有请求响应时间的算术平均值（单位：毫秒）。
  - 计算公式：Average= Samples/∑所有请求的响应时间
  - 意义：
  - 反映整体请求的平均耗时。
  - 局限性：易受极端值（如超时请求）影响，可能掩盖性能问题。

  ---

  4. Median（中位数）
  - 定义：将所有请求的响应时间按从小到大排序，取中间位置的值（即第50百分位数）。
  - 意义：
  - 表示50%的请求响应时间 ≤ 该值。
  - 相比平均值，更能代表“典型”性能，不受极端值干扰。

  ---

  5. 90% Line（90百分位数）
  - 定义：90%的请求响应时间 ≤ 该值，剩余10%的请求响应时间 > 该值。
  - 意义：
  - 关注大多数请求的性能，同时识别尾部延迟（较慢的10%）。
  - 适用于对用户体验要求较高的场景（如网页加载）。

  ---

  6. 95% Line（95百分位数）
  - 定义：95%的请求响应时间 ≤ 该值，剩余5%的请求响应时间 > 该值。
  - 意义：
  - 更严格地评估性能，识别最慢的5%请求。
  - 常用于SLA（服务等级协议）达标分析（如“95%的请求需在1秒内完成”）。

  ---

  7. 99% Line（99百分位数）
  - 定义：99%的请求响应时间 ≤ 该值，剩余1%的请求响应时间 > 该值。
  - 意义：
  - 识别极端情况（如网络抖动、资源竞争导致的极慢请求）。
  - 适用于高可靠性系统（如金融交易）。

  ---

  8. Min（最小值）
  - 定义：所有请求中的最短响应时间。
  - 意义：
  - 反映系统在最优情况下的表现。
  - 如果最小值异常高（如>100ms），可能说明基础延迟较高（如DNS解析慢）。

  ---

  9. Max（最大值）
  - 定义：所有请求中的最长响应时间。
  - 意义：
  - 反映最差情况下的性能。
  - 如果最大值极高（如30秒），可能意味着超时、死锁或资源耗尽。

  ---

  10. Error %（错误率）
  - 定义：失败请求的百分比。
  - 计算公式：Error %= Samples / 失败请求数 ×100%
  - 意义：
  - 衡量系统稳定性，错误率>0%需排查原因（如HTTP 500、连接超时）。
  - 通常要求错误率<1%（严苛场景需=0%）。

  ---

  11. Throughput（吞吐量）
  - 定义：单位时间内（每秒）处理的请求数（单位：requests/second）。
  - 计算公式： Throughput= 测试总时间（秒）/ Samples
  - 意义：
  - 直接反映系统处理能力（如1000 RPS表示每秒处理1000个请求）。
  - 与并发用户数结合分析，可判断系统瓶颈（如数据库、CPU、网络）。

  ---

  12. Received KB/sec（接收吞吐量）
  - 定义：每秒从服务器接收的数据量（单位：KB/s）。
  - 意义：
  - 监控网络带宽消耗。
  - 如果该值接近网络带宽上限，可能成为性能瓶颈。

  ---

  13. Sent KB/sec（发送吞吐量）
  - 定义：每秒向服务器发送的数据量（单位：KB/s）。
  - 意义：
  - 分析客户端上传数据的效率（如文件上传接口）。

  ---

  关键指标综合分析示例
  假设某API测试结果：

 

分析结论：
1. 性能分布：
- 50%请求≤400ms（良好），但95%线高达1200ms，说明5%请求明显变慢（需优化）。
- 最大响应时间5秒，可能存在超时或资源竞争。
2. 稳定性：错误率2%需排查（如日志分析）。
3. 吞吐量：50 RPS是否达标？需对比预期值。

---

如何优化？
- 高百分位数（如95%线）问题：检查慢查询、缓存失效、第三方接口延迟。
- 高错误率：分析日志（如HTTP 500、连接超时）。
- 低吞吐量：增加并发线程数或优化服务器配置（如数据库连接池）。

---

总结
- 平均值：粗略评估，但易受极端值影响。
- 中位数/百分位数：更精准反映用户体验。
- 吞吐量：衡量系统处理能力。
- 错误率：系统稳定性的关键指标。

通过结合这些指标，可以全面定位性能瓶颈并制定优化策略！

6. 报告和调优

• 编写测试报告：详细记录测试过程、结果和发现的问题。结论要准确、问题要清晰直接表现。如以下3图。
• 系统调优：根据测试结果对系统进行优化，如调整配置、优化代码、升级硬件等。调优问题比较复杂，后续再单独刨析。

• 

   

  

   

  

   

7. 重复测试

• 每一个性能问题，测试人员需要提交优先级较高的BUG，并在在系统调优后，重复执行性能测试，验证优化效果。

8.注意事项

• 确保测试环境与生产环境一致：性能测试应在与生产环境尽可能一致的环境中进行，以确保测试结果的准确性。
• 充分模拟实际场景：测试场景应尽可能贴近实际用户的使用情况，以发现潜在的性能问题。
• 注意测试数据的保密性：在测试过程中可能涉及敏感数据，应确保数据的保密性和安全性。

 

 

 

---

结语

亲爱的朋友：
      希望本文中描述的问题以及解决方案，可以帮助到您。当然，我们深知，问题和挑战总是层出不穷，新的情况也在不断涌现。如果读者朋友您有更好的方案，或者在实际应用中发现了文中的不足之处，请不吝分享您的宝贵建议。诚挚地邀请每一位读者加入我们的行列，共同完善这份教程。
    感谢您的阅读与支持！

Dear frends,

     We hope that the questions and solutions presented in this article can be of assistance to you. Of course, we are fully aware that problems and challenges are always emerging in an endless stream, and new situations are constantly arising. If you, our readers, have better solutions or have discovered any deficiencies in this article through practical application, please do not hesitate to share your valuable suggestions with us. We sincerely invite every reader to join us in continuously improving this tutorial.

Thank you for your reading and support!
See you,Parting is for better meeting！

---