在入网或验收场景下，一份站得住脚的性能测试报告，通常会被要求写清哪些指标？

在入网或验收场景下，一份能站得住脚的第三方性能测试报告，不能只堆一堆数字。评审专家看的不是“你测了没有”，而是“关键指标有没有覆盖、数据能不能复现、结论有没有依据”。

下面把一份合格的性能测试报告里必须写清的指标，按维度拆开说。

性能测试指标

一、响应时间，不能只写平均值

响应时间是用户感受最直接的指标，但报告里只写“平均响应时间1.2秒”是不够的。真正站得住脚的写法，必须把分位数列出来。

P95和P99是验收场景的硬指标。 入网安评通常要求“95%的请求响应时间不超过2秒”，这就是P95。如果P95是2.1秒，哪怕平均值再漂亮，结论也是不通过。验收报告里通常还会要求区分平均响应时间和峰值响应时间，有些项目甚至要求分别列出“服务器90%的事务处理平均响应时间”和“接口并发响应时间”。

同时，响应时间应该拆开写：网络传输时间、应用处理时间、数据库查询时间各占多少。这样评审专家能判断瓶颈到底在哪一层，而不是笼统给一个总数。

二、吞吐量，TPS和QPS要分清楚

吞吐量反映的是系统“单位时间能干多少活”。报告里至少要写清楚TPS（每秒事务数）和QPS（每秒查询数）。

交易类系统看TPS，查询类系统看QPS，两者不能混着写。验收场景通常会要求“在XX并发下，系统TPS不低于XX”。入网安评则更关注系统在受压情况下吞吐量的变化情况，随着并发增加，吞吐量是持续上升、平稳、还是开始下降，这个趋势比一个静态数字更有说服力。

有些项目还会要求补充网络吞吐量、网络使用频度、带宽占用等网络效率指标，尤其是涉及视频、大文件传输的系统。

四、并发用户数，峰值和正常分开列

报告里必须写清楚两件事：正常并发数和峰值并发数分别测到了多少。

验收场景的写法通常是：“系统在正常并发XX用户时，响应时间XX；在峰值并发XX用户时，响应时间XX，错误率XX。”入网安评则要求验证“在预测的峰值并发下，系统不崩溃、性能不骤降”。

需要注意的是，并发用户数不等于在线用户数。报告里要明确区分“有效并发用户数”和“峰值在线用户量”，避免混淆。

五、资源利用率，CPU和内存有明确红线

资源利用率是判断系统“有没有余量”的关键。入网安评通常要求CPU和内存占用率不超过70%，这是明确的量化红线。

报告里要写清楚：CPU利用率、内存占用、磁盘I/O、网络带宽在测试过程中的峰值和均值。如果是数据库密集型系统，还要补充数据库连接池利用率、慢查询数量、缓存命中率等指标。这些数据不光证明系统“跑得动”，也证明系统“跑得健康”。

六、错误率，稳定性的一票否决项

错误率是很多报告容易漏掉的指标。验收场景通常要求错误率低于0.1%，部分严格项目要求低于0.01%。

报告里要写清楚：测试期间总请求数、失败请求数、错误率是多少。如果出现错误，还要说明错误的类型：是超时、是业务逻辑错误、还是系统异常。错误率超标，其他指标再漂亮，结论也是不通过。

七、稳定性，高负载下不能崩

入网安评明确要求“高负载下无崩溃或性能骤降”。报告里需要体现持续稳定性测试的结果：在满负载或过载情况下，系统连续运行一段时间（通常24小时以上）后的表现。

需要关注的指标包括：响应时间是否随时间劣化、内存是否持续增长（内存泄漏的典型信号）、错误率是否上升、资源占用是否失控。有些验收项目还会要求测试故障恢复时间，系统在异常情况下多久能恢复到正常水平。

八、报告里还要有的“软指标”

除了上面这些量化指标，一份站得住脚的报告还需要写清楚测试环境配置（服务器型号、CPU、内存、数据库版本、网络拓扑）、测试场景和用例（模拟了什么业务操作、并发梯度怎么设的）、测试工具和版本。这些信息决定了结果能不能复现，评审专家如果无法根据报告还原测试条件，数据就没有说服力。

测试软指标

另外，测试依据必须明确。目前国内性能测试的核心依据是GB/T 25000.51-2016，它把“性能效率”拆成时间特性、资源利用性、容量、依从性四个子特性。报告里逐项对照这四个子特性给出结论，比笼统写“性能良好”要扎实得多。

响应时间看P95/P99，吞吐量分TPS/QPS，并发数分正常和峰值，资源利用率盯70%红线，错误率不能超标，稳定性要看长时间高负载。这些指标写全了、写准了，报告才经得起评审专家的逐项核对。

标签：性能测试、软件指标