性能测试理论基础核心知识

一、性能测试的意义 (3.1)

1. 为什么需要性能测试？

• 驱动力： 互联网用户规模巨大（近10亿），导致系统面临的并发访问压力急剧增加。

• 行业要求： 不仅是专业性能岗位，大中型互联网公司（如BAT, TMD）的功能测试岗位也普遍要求掌握性能测试知识。

2. 什么是性能测试？

• 核心定义： 通过模拟多并发用户访问，来获取系统的各项性能指标。

• 目的：

  • 验证： 系统在高并发下的处理能力、响应能力和稳定性是否达到预期要求。

  • 定位： 发现系统的性能瓶颈和潜在隐患。

  • 保障： 最终目的是保障系统质量，提升用户体验。

二、需要做性能测试的系统类型 (3.2)

以下五类系统或模块是性能测试的重点对象：

1. 用户量大的系统： 访问量（PV）高的模块或接口。

2. 核心模块与接口： 业务关键部分，一旦出现性能问题，影响范围和后果严重。

3. 复杂业务逻辑与算法： 涉及大量计算（如加密、解密、排序），消耗大量CPU资源，容易成为瓶颈。

4. 高并发场景： 如电商平台的秒杀、大促（双十一），访问洪峰明显。

5. 新技术选型： 在系统重构或技术架构升级时，通过性能对比测试，确保新方案性能不低于甚至优于旧方案。

三、性能测试的分类 (3.3)

1. 客户端性能：

   • 关注点： APP或Web应用本身的性能。

   • 指标： CPU占用率、内存消耗、页面加载速度、渲染流畅度等。

2. 服务端性能：

   • 关注点： 服务器后端系统的性能。

   • 指标： 并发处理能力、响应时间等。

   • 实现方式： 主要通过接口进行测试。

3. 行业倾向：

   • 目前市场上所说的“性能测试工程师”岗位，绝大多数指的是服务端性能测试。

   • 原因： 服务器资源成本高且相对固定，而个人客户端设备性能已普遍过剩。

四、性能测试的核心指标 (3.4)

1. 并发用户数

• 定义： 同时向服务器发送请求的用户数量。

• 关键理解： “同时”是一个相对概念，指在极短时间内（如毫秒级）发出的请求，并非绝对同一时刻。

• 相关概念辨析：

  • 注册用户数： 系统中创建了账号的用户总量。范围最大

  • 在线用户数： 已成功登录，在服务器端保有Session的用户数量。

  • 并发用户数： 在线的用户中，真正同时向服务器发出请求的用户数量。范围最小

  • 关系： 注册用户 > 在线用户 > 并发用户

2. TPS 与 QPS

• TPS：

  • 全称： Transactions Per Second（每秒事务数）。

  • 通俗理解： 服务器每秒处理的接口调用次数。

  • 意义： 直接体现系统的处理能力。TPS越高，说明系统单位时间内能处理的业务越多，性能越好。

• QPS：

  • 全称： Queries Per Second（每秒查询数）。

  • 起源： 数据库领域。

  • 现状： 在性能测试语境中，开发人员常使用QPS来泛指接口的每秒请求量，常与TPS混用，可视为等效。

3. 响应时间

• 定义： 从客户端发送请求到客户端接收到最后一个响应字节所花费的总时间。

• 组成部分： 包括网络传输时间 + 各服务器组件处理时间（如中间件、应用程序、数据库等）。

• 具体指标：

  • 平均响应时间：

    • 多次请求的响应时间的算术平均值。

    • 缺点： 容易受少数极端值（非常慢或非常快的请求）的影响，从而失真。

  • 百分比响应时间：

    • 定义： 用于消除极端值影响，更能反映大多数用户的真实体验。

    • 例如：

      • TP90 = 100ms：表示90%的请求的响应时间都小于等于100ms。

      • TP95： 95%的请求耗时低于此值。

      • TP99： 99%的请求耗时低于此值。

    • 计算方法：

      1. 将所有请求的响应时间从大到小排序。

      2. 取排序后位于第90%（或95%、99%）位置的响应时间值。

性能测试高级概念与指标关系

一、百分比响应时间（TP90等）的应用场景

• 核心价值： 作为平均响应时间的补充，提供更真实、多维度性能视角，体现分析专业性。

• 具体应用场景：

  1. 在性能报告中例行展示： 无论是否有异常，都建议将TP90/TP95等指标纳入报告，以提供更全面的数据维度。

  2. 当出现极端值时进行深入分析：

     • 识别信号： 当你发现最大响应时间 与平均响应时间 相差数个数量级时（例如，平均10ms，最大60,000ms）。

     • 分析结论： 这表明系统中存在少量但极其缓慢的请求，这些请求严重拉高了平均值，使其无法代表大多数用户的真实体验。

     • 解决方案： 此时，TP90 等百分比响应时间指标就显得至关重要，它能剔除掉顶部最慢的10%的请求，告诉你“90%的用户体验其实在这个更好的时间范围内”。

二、补充的性能指标

1. 成功率：

   • 定义： 请求的成功比率。

   • 目标： 理想状态下应为100%。

2. PV 与 UV：

   • PV：

     • 全称： Page View（页面浏览量）。

     • 定义： 页面或接口的访问次数。

     • 特点： 重复访问会累计。

     • 示例： 一个人一天内访问百度100次，就贡献了100个PV。

   • UV：

     • 全称： Unique Visitor（独立访客）。

     • 定义： 访问页面或接口的唯一用户数。

     • 特点： 强调人的唯一性，同一用户多次访问不重复计算。

     • 应用： 常用于统计日活跃用户 等指标。

     • 示例： 一个人一天内访问百度100次，只贡献了1个UV。

3. 吞吐量：

   • 常见歧义： 不同上下文中定义不同。

     • 在JMeter等工具中，常直接指代 TPS。

     • 在更多场景下，特指网络流量。

   • 精确定义（推荐）： 网络吞吐量，即单位时间内网络上传输的数据总量。

   • 分类：

     • 上行流量： 从客户端发往服务器端的数据。

     • 下行流量： 从服务器端返回给客户端的数据。

三、核心性能指标之间的关系

1. TPS vs 响应时间：

   • 关系： 响应时间越短，TPS越高。

   • 类比： 仓库处理卡车的速度越快，单位时间内能处理的卡车总数就越多。

2. TPS vs 并发用户数：

   • 关系： 并非并发数越高，TPS就无限增长。它们的关系遵循“性能拐点”模型：

     • 增长期： 初期，随着并发用户数增加，TPS几乎线性增长。

     • 瓶颈期/拐点： 当并发数达到系统极限时，TPS达到峰值并趋于稳定，不再增长。这个临界点称为性能拐点。

     • 衰退期： 继续增加并发用户，系统可能因资源耗尽而性能下降（TPS降低），甚至崩溃（TPS降为0）。

   • 类比： 如同踩油门加速，车速会提升，但达到发动机极限后，车速便无法再提升，猛踩油门甚至可能损坏发动机。

3. 核心公式：TPS = 并发用户数 / 平均响应时间（单位：秒）

   • 公式解读：

     • 这是一个理论计算公式，实际值可能有轻微偏差。

     • 它揭示了三个核心指标的内在联系，知道任意两个即可估算第三个。

   • 公式推导示例：

     • 场景： 10个并发用户，平均响应时间为0.5秒。

     • 计算：

       1. 单个用户1秒内可完成请求次数：1秒 / 0.5秒 = 2次。

       2. 10个并发用户1秒内总共完成请求次数：10用户 * 2次/用户 = 20次。

       3. 因此，TPS = 20。

       4. 整合算式：TPS = 10 / 0.5 = 20，与公式一致。

四、后续学习方向：系统监控指标

性能测试除了关注上述外部性能指标，还需监控系统内部资源，以定位瓶颈：

• 操作系统监控： CPU使用率、内存使用率、网络I/O、磁盘I/O。

• 中间件监控： 连接数、线程池状态、长/短连接。

• 应用层监控： JVM内存、GC情况、锁竞争。

• 数据库监控： 连接数、缓存命中率、SQL查询效率。

性能测试流程与高级场景核心知识梳理

一、性能测试完整流程（8个步骤）

这是一个必须掌握的标准化流程，面试高频考点。

1. 需求调研

2. 测试计划

3. 环境搭建

4. 数据准备

5. 脚本编写

6. 压测执行

7. 调优回归

8. 测试报告

---

二、流程步骤详解

1. 需求调研

• 核心： 在测试前全面了解需求，避免盲目测试。

• 对接人： 产品经理 与 开发人员（因涉及大量技术细节）。

• 需明确的内容：

  • 项目背景与测试范围： 要测试哪些接口或模块。

  • 业务逻辑与数据流向： 接口的作用、数据如何存储。

  • 系统架构： 技术栈、框架、部署方式（分布式/单点）、中间件、数据库等。（至关重要，影响后续环境搭建和问题排查）

  • 配置信息： 生产环境与测试环境的硬件/软件配置。

  • 测试数据量： 参考生产环境的数据规模（如用户数、订单量），不同数据量级性能表现不同。

  • 外部依赖： 系统调用的第三方接口（如支付、内容审核），需考虑是否要做挡板模拟。

  • 使用场景与业务量： 用户行为模式、日常业务量级（用于设计测试场景和计算指标）。

  • 预期指标： 期望的TPS、响应时间等。（需需求方提供，若无则需共同制定）

  • 上线时间： 用于制定测试计划。

2. 测试计划/方案

• 内容： 项目描述、性能指标、业务模型、测试环境、资源、方法等。

• 核心：场景设计 - 性能测试一般不需编写传统用例，而是设计测试场景。

  • 面试高频问题： “你们性能测试有哪些场景？”

3. 环境搭建

• 黄金准则： 测试环境配置应尽量与生产环境保持一致（硬件、OS版本、软件配置等），以使测试结果更具参考价值。

• 现实： 因成本问题，很多公司无法实现1:1复制。

• 进阶： 有实力的大公司会通过技术改造，直接在生产环境进行压测（如阿里双十一），以获取最真实的数据。

4. 数据准备（数据构造）

• 重要性： 性能测试需要大量数据，数据量级会影响结果。

• 常用方法：

  • 通过业务接口造数据（最简单直接，如调用注册接口造用户）。

  • 通过SQL/存储过程造数据（需熟悉数据库结构）。

  • 通过脚本（Python/Java）导入数据（灵活，适合复杂逻辑）。

5. 脚本编写

• 工具选择：

  • JMeter： 互联网公司主流，开源免费。

  • LoadRunner： 商业工具，收费昂贵，稳定权威，多见于银行、金融、国企。

  • Locust： 基于Python的开源框架，无界面，代码驱动，灵活性高。

• 脚本要点：

  • 协议： HTTP最常用，其次RPC。

  • 参数化： 让并发用户使用不同的动态数据，而非固定值。

  • 关联： 处理接口之间的数据依赖。

  • 断言： 验证请求是否成功。

6. 压测执行

• 分布式压测： 当单台压力机无法产生足够压力时，需使用多台压力机同时压测。

• 监控： 极其重要。没有监控就无法分析和定位问题。需监控系统各级指标。

• 能力要求： 执行 -> 监控 -> 结果收集 -> 数据分析 -> 瓶颈定位。具备全链路能力是高级工程师的标志。

7. 调优回归

• 核心思想： 性能调优是团队工作，非测试人员一人之责。

• 测试角色： 核心职责是定位问题，并推动开发、DBA、运维进行修复。

• 关键方法：

  • 全链路排查： 沿请求路径（网络 -> 中间件 -> 应用 -> 数据库）逐一排查。

  • 日志分析： 大多数性能问题会在日志中体现（如超时、连接数不足、内存泄漏）。

  • 模块隔离法： 通过注释/修改代码，逐一排除可疑模块（如先绕过数据库查询），快速缩小问题范围。

  • 反复迭代： 调优需要多次尝试、验证、回归。

8. 测试报告

• 内容： 概述、测试环境、结果数据、分析过程、调优说明、结论与建议。

• 作用： 项目交付物，总结测试活动与成果。

---

三、性能测试场景设计（面试必背）

1. 基准测试

   • 目的： 建立性能基线。

   • 方法： 使用 1个并发用户 测试系统，获取TPS和响应时间数据。

   • 用途： 后续代码重构或优化后，与此基线对比，验证性能变化。

2. 单接口负载测试

   • 目的： 验证单个接口的性能，找到其性能拐点。

   • 方法： 使用多并发用户对单个接口进行压测。

3. 混合场景负载测试

   • 目的： 模拟真实生产环境，找到整个系统的性能拐点。

   • 方法： 按照一定业务比例，同时对多个接口进行压测，关注总TPS。

4. 稳定性测试

   • 目的： 验证系统在长时间运行下的稳定性。

   • 方法： 长时间（通常 >12小时或24小时）压测。

   • 关注点： TPS和响应时间是否稳定、是否存在内存泄漏等问题。

5. 高可用性测试

   • 目的： 验证集群在节点故障时的容错能力。

   • 方法： 在压测过程中，模拟集群中某个节点宕机。

   • 关注点： 系统是否能自动切换流量，业务是否受影响（用户无感知），TPS是否保持稳定。