性能测试指标
单轮测试可产出的全部数据及其读法。术语定义见基本概念。
客户无需提前定义指标——下列数据均自动产出，不需选择或配置。 需客户确认的仅第四节所列三项。
表中的英文名为报告中的字段名，与中文含义一一对应。
一、客户端指标
客户端指压测机一侧，即从用户视角测量的端到端耗时。
同一轮测试同时产出三个层级的数据，无需为不同粒度分别执行：
| 层级 | 回答的问题 | 典型用途 |
|---|---|---|
| 接口级 | 链路中哪一个请求耗时最长 | 定位问题 |
| 链路级 | 完整操作的端到端耗时 | 对外承诺与验收口径 |
| 全局 | 整轮的总体水平 | 结论陈述 |
1. 接口级
粒度最细的一层，链路中每个请求单独统计，用于定位耗时集中在哪一步。
| 字段 | 含义 |
|---|---|
business_duration | 单次请求耗时 |
business_error_rate | 该接口的失败率 |
server_time | 服务端处理耗时（取自响应头） |
response_body_size | 响应体大小 |
endpoint_bytes_received / endpoint_bytes_sent | 该接口的收发字节数 |
server_time 与客户端总耗时相减，即可把网络与排队开销从服务端处理时间里分离出来。
客户抱怨"慢"时，这一步能立刻区分是服务端慢还是链路慢。
2. 链路级
将完整用户操作作为整体计时，对应用户实际感知的等待时间。 该层最贴近用户体验，是对外承诺的推荐口径。 链路内任一步失败，整条记为失败。
| 字段 | 含 义 |
|---|---|
workflow_duration | 完整链路耗时 |
workflow_error_rate | 链路失败率 |
3. 全局
压测工具（k6）的原生指标，通用性最好，适合写入对外的验收结论。
| 字段 | 含义 |
|---|---|
http_req_duration | 全部请求的耗时分布 |
http_req_failed | 整体失败率 |
http_reqs | 请求总数 |
iterations | 完成的完整操作次数 |
vus | 并发虚拟用户数 |
data_sent / data_received | 收发数据总量 |
checks | 断言通过情况 |
4. 每项指标的统计列
| 列 | 含义 | 常见用途 |
|---|---|---|
count | 样本数 | 判断这项数据够不够有统计意义 |
avg / med | 平均值 / 中位数 | 看整体水平，中位数不受长尾影响 |
p90 / p95 / p99 | 分位耗时 | 验收口径通常写这里，p95 最常用 |
min / max | 最快 / 最慢 | max 用来发现偶发的极端卡顿 |
err% | 失败率 | 与耗时并列的第二条硬指标 |
tps | 每秒完成数 | 吞吐量口径 |
srvP95 | 服务端处理 p95 | 剔除网络后的纯服务端耗时 |
recvKB / sentKB | 单次收发字节 | 定位"响应体过大"型的慢 |
分位取值与 JMeter 聚合报告保持一致（min / 中位 / 90 / 95 / 99 / max），便于和历史报告对比。
平均值受长尾影响被拉平。100 个请求中 95 个为 100 ms、5 个为 10 s 时， 平均值仅 595 ms，掩盖了后 5 个请求的严重劣化。验收应使用 p95 / p99。
二、服务端资源指标
压测同时在被测环境采集 CPU 与内存，与客户端数据落在同一时间轴上， 用于回答「响应劣化时服务端处于何种状态」。
有这层数据，结论才能从「响应慢」推进到「某服务 CPU 达到上限，需扩容」， 后者才具备可执行性。
| 采集内容 | 说明 |
|---|---|
| CPU 使用量 | 可换算为相对配额的占比 |
| 内存使用量 | 同上 |
| 统计维度 | 节点 / 命名空间 / 服务 / 实例 / 容器，按业务名归类而非实例编号 |
| 采样间隔 | 默认 10 秒，可调（下限 2 秒） |
单副本打满、其余空闲时，取平均将显示为低负载，掩盖真实瓶颈。
物理机或虚拟机部署需另行配置采集方式。 集群监控的开启方式见开启监控。
三、判定与验收
红线（阈值）用于判定单轮测试是否通过，可设在四个层级：
| 层级 | 判定对象 | 示例 |
|---|---|---|
| 接口 | 单个请求的耗时与失败率 | p95 小于 2000 ms |
| 链路 | 完整操作的端到端耗时 | p95 小于 5000 ms |
| 全局 | 整轮的失败率与耗时 | 整体失败率低于 1% |
| 服务端 | CPU / 内存水位 | CPU 占用不超过配额的 80% |
每一层均可单独切换为「仅观察」模式。
红线需在客户实际环境中标定后才具备判定意义。未经标定即用于验收， 首轮通常大面积越线，导致报告失去可信度。
正确顺序：首轮测出实际水位 → 依据实测数据与客户商定 → 启用判定模式。 仅观察模式下越线情况照常写入报告，仅不影响成败结论。
易误读的口径
红线「business_duration{workflow:打开需求列表} 的 p95 小于 600 ms」的含义是：
该链路内的单个请求，95% 快于 600 ms
而非：
整条链路 95% 在 600 ms 内完成
因为 business_duration 的样本单位是单个请求，
附加链路名仅将统计范围限定到该链路所含的请求。
该差异影响重大：一条 30 步的链路，每步耗时 500 ms 均可通过此红线， 但端到端耗时已达 15 秒。
表述「用户完成一次操作的等待时间」须使用 workflow_duration，不得使用 business_duration。
分阶段统计
单轮压测分为升压、稳态、降压三个阶段（见基本概念）， 报告对各阶段分别统计耗时、失败率与服务端水位。
验收数据取自稳态阶段。 升压阶段负载较低、耗时数据偏优， 混合统计会使整体结果偏乐观。阶段之间的间隔也会单独检查， 避免各阶段均正常而间隔期存在故障的情况被掩盖。
当前红线的判定范围为整轮测试，含升压与降压阶段，因此判定偏松： 升压阶段的低耗时会拉低整轮 p95，可能出现整轮红线通过而稳态阶段实际不达标的情况。
读取报告时须以分阶段统计中的稳态行为准。
四、需要客户明确的三件事
前述指标均自动产出。以下三项只能由客户方确定。
1. 目标业务量 —— 峰值并发用户数，或目标吞吐量。
该值决定压测强度。缺少它则测得的数据没有参照系： 「50 并发下 p95 为 800 ms」只有在客户实际业务量即为 50 并发时才具备意义。
客户常给出的是注册用户总数，需换算，方法见并发公式。
2. 验收口径与阈值 —— 需卡指标的链路、使用 p95 或 p99、具体数值。
客户验收项常写为「响应时间阈值为 ___」，容易被填入无法达成的数值。 应先测出实际水位，再依据实测数据与客户商定。顺序颠倒将导致该项无法推进。
3. 数据规模 —— 测试环境需写入的工作项、页面、成员数量。
该量级应对齐客户当前的真实规模，或其未来一到两年的预期规模。 可生成的量级见工具执行手册。