软件性能测试的测试内容是什么？关键指标如何设定？

软件性能测试

很多人一提性能测试，脑子里就蹦出"压测"两个字。但实际上，性能测试远不止压测这一件事。你要是只会跑个 JMeter 看看响应时间，那只能说你刚摸到门边。今天把测试内容和指标设定这两件事一次说清楚。

一、性能测试到底在测什么？

先纠正一个认知：性能测试不是一个动作，是一组动作。

第一种，负载测试。 这是最基础的。模拟正常业务场景下的用户量，看看系统能不能扛住。比如你们日活 10 万，那就按这个量级去压，看响应时间、吞吐量这些指标在不在可接受范围内。目的很简单就是验证系统在预期负载下是否正常。

第二种，压力测试。 跟负载测试不一样，压力测试是往死里压。不断加用户、加请求，直到系统崩溃或者出现明显性能拐点。这一步是为了找到系统的极限在哪。你得知道它最多能扛多少，心里才有底。

第三种，并发测试。 这个专门测多用户同时操作同一资源时会不会出问题。比如秒杀场景，1000 个人同时抢 100 件商品，库存会不会超卖？订单会不会重复？这不是压不压得住的问题，是逻辑对不对的问题。

第四种，稳定性测试，也叫耐力测试。 不是压一下就完了，是长时间跑。比如持续跑 8 小时、24 小时甚至 72 小时，看系统会不会慢慢变慢、内存会不会泄漏、连接池会不会被耗光。很多问题不是一瞬间暴露的，是时间长了才出来。

第五种，尖峰测试。 模拟流量突然暴增的场景。比如整点秒杀、突发新闻推送，流量一秒之内从 100 飙到 10000，系统能不能快速响应、能不能自动扩缩容。这个测的是系统的弹性。

第六种，容量测试。 这个偏向资源规划。数据库最多能存多少条数据不影响查询速度？缓存最多能扛多大的 key 数量？这类测试是为了给将来扩容做依据。

二、关键指标怎么设定

指标设定这件事，说难不难，说简单也真有人栽跟头。核心原则就一条：指标跟业务紧密挂钩，脱离业务谈指标可以说是在耍流氓。

1.响应时间。这个大家最熟悉，但很多人只看平均值。平均值是最会骗人的数字。你平均响应时间 200ms，听着挺好，但如果有 1% 的请求花了 5 秒，用户体验已经崩了。所以必须看分位值。P90、P95、P99，这三个才是重点。一般来说，P99 控制在 500ms 以内是比较合理的目标，具体还得看你们业务能接受什么。

2.吞吐量，也就是 TPS 或者 QPS。这个指标的目标值怎么定？别拍脑袋。去看你们线上的真实流量数据，取峰值的 1.2 到 1.5 倍作为测试目标，留点余量。比如线上峰值是 5000 QPS，那测试目标就定在 6000 到 7500 QPS。

3.错误率。这个指标很多人不当回事，觉得 99% 的成功率已经很高了。但你算一下，99% 的成功率意味着每 100 个请求就有 1 个失败，如果你日均请求量是 1000 万，那就是 10 万次失败。这个数字放到业务里，可能就是 10 万个用户体验受损。所以一般要求错误率控制在 0.1% 以下，核心链路甚至要求 0.01%。

4.资源使用率。CPU、内存、磁盘 I/O、网络带宽，这四个都得盯。一般经验值是 CPU 不超过 80%，内存不超过 85%，磁盘 I/O 不超过 90%。但这些不是死的，得结合你们的硬件配置和业务特点来调。比如你们用的是 SSD，磁盘 I/O 的阈值可以适当放宽；如果是核心交易链路，CPU 超过 70% 就该警惕了。

三、几个常犯的错误

1.指标定得太理想。 上来就说响应时间 100ms 以内，错误率 0。这种指标没有任何参考意义，因为根本达不到。指标要有挑战性，但也得能实现。

2.只关注服务端，不关注客户端。 服务端响应很快，但前端渲染慢、网络延迟高，用户照样觉得卡。性能测试一定要把端到端的链路都覆盖进去。

3.测试环境跟生产环境差太多。 你在 4 核 8G 的机器上测出来的结果，放到生产环境的 32 核 64G 机器上，可能完全不一样。环境差异不消除，测试结果就没有参考价值。

说到底，性能测试的核心不是跑出多漂亮的数字，而是搞清楚系统在什么条件下会出问题、出了问题影响多大。

标签：软件性能测试、性能测试报告