性能测试方案怎么写？并发数、场景模型、判定准则怎么定？

写性能测试方案，很多团队最容易犯一个错：把它写成了一份“操作说明书”，第一步打开JMeter，第二步设500个线程，第三步点运行。

这不叫方案，这叫流水账。真正的性能测试方案，是你在动手压测之前立下的“军令状”。它得回答三个极其核心的问题：咱们到底要打多少人？从哪条路打？以及什么样才算打赢？

这三个问题，对应的就是性能方案的三根柱子：并发数、场景模型、判定准则。这三样东西如果定不准，测出来的数据就是自欺欺人。今天咱们就把这三根柱子拆开，聊聊怎么定才不踩坑。

性能测试方案

第一根柱子：并发数怎么定？别“拍脑袋”，看业务

很多项目组定并发数的逻辑极其粗暴：老板说“咱们这系统未来要火，按一万个人同时在线测吧！”或者开发为了数据好看，定个50并发糊弄交差。

并发数绝对不能拍脑袋，它得从真实的业务数据里“推导”出来。

咱们得先搞清一个极其容易混淆的概念：在线用户数 ≠ 并发用户数。
假设你的系统有1万个注册用户，每天有1000个人打开App（在线用户）。但这1000人里，不可能每一秒都在按“提交”按钮。大部分人可能只是在浏览页面，或者盯着屏幕发呆。真正在同一秒内同时发起请求的，可能只有几十个人，这个才是并发用户数。

实操怎么定？

1.看历史数据（最靠谱）：系统如果已经上线了，去查监控平台。找出过去半年里，业务最高峰时的实际并发量和TPS。

2.套用二八定律：如果是新系统，假设每天有10万次交易请求。80%的交易集中在20%的时间（比如每天的高峰期2小时，即7200秒）。那么平均TPS = (100000 * 0.8) / 7200 ≈ 11笔/秒。再根据每个用户的思考时间和接口耗时，倒推出并发数。

3.看合同指标：如果招标文件明确写了“支持500并发”，那这就是你的基线目标，不仅要测500，还得往上探，看看800并发时系统死不死。

第二根柱子：场景模型怎么建？别只压一个接口

有些团队测性能，就逮住一个“登录接口”死命压，压到了1000 TPS，觉得万事大吉。上线后用户一多，系统还是崩了。为什么？因为真实世界里的用户，不会只干一件事。

场景模型必须贴着业务跑。

1. 核心业务链路（全链路压测）
用户从打开App到完成核心目的，中间是有关联的。比如电商系统：浏览商品 (60%) → 搜索商品 (20%) → 加入购物车 (15%) → 提交订单 (5%)。
你在压测脚本里，也得按这个比例去分配虚拟用户的动作。如果所有人都卡在“提交订单”这步，数据库的连接池会被瞬间打满，而缓存可能根本没被用上。只有混合场景，才能测出系统各组件配合时的真实抗压能力。

2. 思考时间（Think Time）
千万别让虚拟用户在脚本里像机器一样，一毫秒都不停地发请求。真实用户在点完“搜索”后，眼睛是要花几秒钟看结果的。在脚本里加上3-5秒的思考时间，系统承受的压力才不会虚高，测出来的数据才有参考价值。

3. 加压策略（别一棍子打死）
建议使用阶梯式加压。从50并发开始，跑5分钟；加到100，再跑5分钟；依次递增。这是为了找拐点。你要看的是“系统在多少并发时，响应时间突然飙升或者错误率飙升”。那个点，就是系统的真实容量极限。

第三根柱子：判定准则怎么定？别用“差不多”

测试做完了，开发问：“性能达标了吗？”测试回：“看着还行，没怎么崩。”

这种回答在验收会上，是要被专家用放大镜怼回去的。判定准则必须量化到具体的数字，并且要有明确的红线。

一份合格的性能判定准则，至少要包含这几个维度：

1.响应时间：不能只看平均值！必须看P95和P99。比如红线设定为：“在500并发下，核心接口的P95响应时间不超过2秒。”这意味着95%的用户体验是达标的。

2.吞吐量（TPS/QPS）：系统在确保响应时间的前提下，每秒到底能处理多少笔业务。比如“订单提交接口的TPS必须达到300”。

3.错误率：压测期间，失败请求的比例绝对不能超过 0.1%。一旦红线踩破，性能指标直接归零。

4.资源利用率：系统跑到峰值时，CPU和内存占用率不能持续超过 75% - 80%。如果CPU打满，说明计算资源是当前的最短板。

软件测试资质

写方案时，必须避开的“资质坑”

最后说个极其残酷的现实。很多团队方案写得漂漂亮亮，测出来的数据也很漂亮。但你写的这份报告，最终是要拿去给甲方或者评审专家看的。

2026年“一单一库”新政落地后，通用软件测试的CMA章已经不再适用。如果你的报告要作为项目验收或招投标的依据，必须由具备CNAS认可的第三方机构出具。

方案里别忘了加一页《测试机构资质证明》。去CNAS官网把机构的《认可范围附件》截图贴上去，确认包含“软件测试”和性能相关标准。千万别等报告交上去被退回，才发现机构资质不对，那时候返工的时间和金钱成本，可就不止一点点了。

性能方案不是写给老板看的PPT，它是测试工程师的“作战地图”。并发看数据，场景看链路，准则看红线。把这三样定死了，你的性能测试才不会是一场自嗨。

标签：性能测试、CNAS性能测试报告