基本概念

本章其余页面所使用术语的定义与前提。未接触过性能测试的读者请先阅读本页。

一、性能测试的定位

功能测试验证的是正确性：操作的结果是否符合预期。 性能测试验证的是在压力下的表现：响应时间、吞吐能力、错误率、以及长时间运行的稳定性。

两者不可互相替代。功能完全正确的系统，在并发场景下仍可能不可用。

私有部署场景下，同一版本的 ONES 运行在不同硬件规格、不同数据量级的环境中， 性能表现可能相差数十倍。因此性能测试是交付环节的必要组成部分， 用于回答四类问题：

类型	典型诉求
验收	合同约定「工作项列表 2 秒内打开」，当前环境是否达标
容量	用户规模扩至 3000 人后，现有配置是否够用，需要扩容哪一部分
风险	早高峰集中登录的十分钟内，系统是否会不可用
稳定	连续运行一周后，性能是否会持续劣化

二、造数与压测的关系

性能测试由两个阶段构成：

1. 造数：向测试环境写入规模化业务数据，使其数据量级接近客户实际环境；
2. 压测：在该环境上模拟并发操作，采集并判定性能指标。

造数不可省略。空环境上得到的性能数据不成立—— 无数据时查询无需扫描，响应时间与真实场景不具可比性。 客户环境中工作项数量可达百万级，查询代价与空环境相差数个数量级。

压测必须在独立的测试环境进行

压测会产生大量真实读写，可能影响正在使用的系统，并写入无效数据。 测试环境的硬件规格应与客户实际规格对齐，否则测得的数据对客户没有参考价值。

三、术语定义

以下定义贯穿本章。示例统一采用「打开需求列表」这一操作。

业务链路（workflow）

一次完整的用户操作，是性能统计的基本单位。

单次用户操作在前端往往对应多个后端请求。以「打开需求列表」为例， 需依次或并发请求列表数据、筛选条件、成员信息、权限信息等，共三十余个请求。 这些请求被归为一条业务链路，按整体计时——用户感知的是操作的端到端耗时， 而非其中单个请求的耗时。链路内任一请求失败，整条链路记为失败。

虚拟用户（VU）与并发

VU（Virtual User）指压测工具模拟的并发用户。单个 VU 循环执行业务链路： 发起操作、等待、再次发起。

「50 并发」即同时有 50 个 VU 在执行操作。

并发数与用户总数是两个量级

客户所称「5000 个用户」通常指注册用户数。同一时刻实际发起请求的用户远少于此， 两者可相差两到三个数量级。直接按注册用户数设定并发，得到的结论不具参考价值。 换算方法见并发公式。

迭代与思考时间

VU 完整执行一遍业务链路称为一次迭代。

两次迭代之间的停顿称为思考时间（think time），用于模拟真实用户的操作间隔。 无思考时间的连续请求不符合真实使用模式，会高估系统承压。

响应时间与分位数

性能验收中最关键、也最易误用的概念。

设某轮测试中「打开需求列表」执行 100 次，耗时排序后：

统计口径	定义	本例取值
平均值	全部样本的算术平均	595 ms
中位数（p50）	第 50 个样本的耗时	100 ms
p95	第 95 个样本的耗时，即 95% 的请求快于该值	800 ms
p99	第 99 个样本的耗时	9 s
最大值	最慢样本的耗时	10 s

本例的实际分布是：95 次约 100 ms，5 次约 10 s。平均值 595 ms 掩盖了后者。

验收口径应使用分位数，不得使用平均值

平均值受长尾影响被拉平，会掩盖部分用户体验严重劣化的事实。 行业通行口径为 p95，即「95% 的用户可在该时间内获得响应」； 要求更严格的场景使用 p99。

吞吐量：TPS 与 RPS

单位时间内系统处理的请求量。两个常用口径：

• RPS（Requests Per Second）：每秒 HTTP 请求数；
• TPS（Transactions Per Second）：每秒完成的业务操作数。

两者相差一条链路所含的请求数。前述「打开需求列表」含三十余个请求， 故 10 TPS 约相当于 300 RPS。

与客户对齐吞吐量指标时须先明确口径

客户提出「支撑 200 TPS」时，须确认所指为 200 个业务操作还是 200 个 HTTP 请求。 两者相差约三十倍，按错误口径验收将得出相反结论。

到达率

压测端主动发起操作的速率，与吞吐量互为一体两面： 吞吐量描述系统实际处理量，到达率描述施加的请求速率。

两种加压方式的区别：

加压方式	系统响应变慢时
按并发数加压	VU 等待时间延长，发起速率随之下降，压力自动回落
按到达率加压	速率保持不变，压力不随系统变慢而回落

按并发数加压无法测出系统上限——系统变慢时压力同步回落，二者达成虚假平衡。 验收「能否支撑 200 TPS」必须按到达率加压。

到达率的单位是每秒完成的业务操作数，非 HTTP 请求数，换算见并发公式。

错误率

失败请求占总请求的比例，与响应时间并列为两项硬指标。

只看响应时间而不看错误率存在风险：系统过载时响应时间可能下降， 因为请求被快速拒绝而非正常处理。

压测模式

压测强度、持续时间与判定标准的完整配置。工具的配置文件中称为 profile。

同一组业务链路可施加不同强度以回答不同问题：1 个 VU 执行 5 次用于验证脚本可用性； 50 个 VU 持续 15 分钟用于验证常态业务量；300 个 VU 瞬时加压用于验证抗冲击能力。 共七种，见压测模式。

红线（阈值）

判定单轮测试是否通过的具体指标值，如「p95 小于 2000 毫秒」。

红线有两种模式：判定模式下越线即判失败；仅观察模式下越线情况写入报告但不影响结论。

首轮测试应使用「仅观察」模式

红线需在客户实际环境中标定后才具备判定意义。未经标定即用于验收， 首轮通常大面积越线，导致报告失去可信度。

正确顺序：首轮测出实际水位 → 依据实测数据与客户商定阈值 → 启用判定模式。

基线

系统在低负载、几乎无资源竞争条件下的性能表现，作为后续对比的参照。

基线用于区分性能问题的成因：

现象	判断
基线即慢	接口自身实现效率低，扩容无效
基线正常、加压后劣化	并发下才出现的问题，通常为排队、锁竞争或资源不足

升压、稳态与降压

单轮压测通常分为三个阶段：升压（并发数由 0 递增至目标值）、 稳态（维持目标并发）、降压（并发回落，观察系统恢复情况）。

验收数据取自稳态阶段

升压阶段负载较低、耗时数据偏优，与稳态数据混合统计会使整体结果偏乐观。 读取报告时须以分阶段统计中的稳态行为准。

四、本章其余内容

目标	页面
了解一次测试的完整流程与门禁	测试流程
确认可覆盖的业务场景	场景列表
了解可产出的指标及其读法	性能测试指标
选择压测强度	压测模式
执行步骤	工具执行手册
数据写入后的检索延迟	索引时长
并发与吞吐量的换算	并发公式