“支持一千人同时使用”看起来很明确，但一千人只登录、不停查询和批量上传文件，对系统的压力完全不同。软件性能测试首先要解释这些人到底在做什么、以什么节奏做，再判断系统在相应负载下是否满足目标。下面按委托、实施和报告复核的顺序展开。
一、先把性能要求写完整，再选择测试类型
先从合同、招标参数、用户需求和真实使用场景中提取目标。例如“查询要快”，至少还需要明确查询对象、数据规模、并发或请求节奏、统计口径和允许错误水平。只写“高并发、低延迟”不足以直接判定结果。
| 测试方向 | 主要回答的问题 | 委托时先说明什么 |
|---|---|---|
| 预期负载测试 | 正常或设计负载下是否达到目标 | 日常业务组合、峰值条件与指标 |
| 压力测试 | 更高负载下如何退化、哪里出现瓶颈 | 增压方式、停止条件和恢复观察 |
| 持续运行测试 | 较长运行后是否有资源累积或不稳定 | 运行时长、数据变化和持续负载 |
| 突发负载测试 | 流量突然变化时如何响应 | 突增形态、持续阶段与恢复要求 |
这些是测试目的的区分，不是每份报告必须全部包含的固定套餐。k6官方压力测试说明强调根据实际风险负载确定压力，不宜照搬统一的增幅。协议层测试与浏览器端体验也应区分：网站测试指南将前端与后端验证分别讨论，接口快不必然意味着页面打开就快。
送检前最好形成一行需求：“在指定版本、部署资源和数据量下，执行某组业务，达到约定负载并持续约定时长，按明确的响应、吞吐和成功标准判断。”没有确认的数字先列为待定，不能替客户随意填入漂亮指标。
二、并发用户、吞吐量、响应时间，不要混着用
注册用户数表示账户规模，在线人数可能包括长时间不操作的人，虚拟用户则是工具按脚本模拟的活动。它们不能直接互换。一个虚拟用户循环执行多次请求时，产生的每秒请求数还受响应时间和停顿间隔影响。
| 指标 | 报告需要讲清的口径 |
|---|---|
| 并发／虚拟用户 | 同时执行什么脚本，是否含等待与思考时间 |
| 请求吞吐 | 每秒、每分钟或其他单位，统计哪些请求 |
| 业务吞吐 | 一笔业务由哪些请求组成，成功完成怎样计数 |
| 响应时间 | 从哪里计时，到哪个事件结束，统计平均还是百分位 |
| 失败／错误 | 超时、网络错误、接口错误和业务失败如何计入 |
例如一次“提交申请”包含登录、查询、保存和确认多个请求，不能将请求数直接写成成功提交的申请数。返回HTTP 200也可能携带“业务失败”的内容，应设置与业务结果对应的校验，而不是只看连接成功。
JMeter术语说明中的请求耗时不包含浏览器页面渲染和客户端脚本执行；吞吐量也有明确计时口径。报告引用工具数值时应沿用并说明其定义。平均值可能掩盖较慢请求，采用P95等百分位时，还要说明样本、统计时段以及失败请求的处理，不能只摘最有利的一组数字。
不同系统的指标比较，必须先统一这些条件。同样标为“每秒一千”，可能一个数的是请求，另一个数的是完整事务，表面数值相同并不表示能力相同。
三、搭好测试环境，避免把环境问题当成产品能力
报告应标明软件版本、构建或发布标识、操作系统、中间件、数据库及关键配置。服务器资源、实例数量、网络条件、缓存、负载均衡和外部服务也会影响结果，不能仅写“某软件V1.0”。
准备数据时，应考虑记录总量、字段大小、用户权限和查询分布。空数据库上反复查询一条缓存记录，与大量真实规模数据下的复杂查询，工作量可能相差很大。用模拟数据可以，但应明确构造方式及与目标场景的差异，避免使用未经授权的个人信息或客户数据。
压测机本身也需要监控。如果发生器CPU、连接数或网络先到上限，工具没有发出计划中的负载，就不能把配置界面的目标值写成系统已承受的实际负载。分布式发生器还需检查时钟、脚本和数据的一致性。
测试应在明确授权与隔离安排下实施，提前约定影响范围、备份恢复、监控负责人和停止条件。涉及短信、支付、邮件或第三方接口时，可按方案使用隔离环境或模拟依赖；模拟了哪些部分必须在报告中披露，结果不能无条件代表真实外部链路。
生产环境与测试环境不一致时，列出差异及可能影响，不直接按服务器数量倍乘推断生产性能。若测试过程中扩容、调整数据库或修改程序，需记录变更并区分前后结果。
四、实施时保留完整过程，分析时同时看业务与资源
建议按确认的方案组织以下工作；具体阶段和时长由业务风险与方法确定，不统一套用“跑半小时就够了”。
- 小负载核对脚本：确认登录、关联数据、参数化和业务校验正确，先排除脚本自身错误。
- 建立基线：记录低负载或预期负载下的响应、成功情况和资源状态，作为对照。
- 逐步达到目标负载：记录每个阶段实际达到的负载及系统反应，不把设置值当实测值。
- 保持并观察：同时查看慢请求、错误、队列、CPU、内存、数据库和网络，留存完整时间线。
- 按约定停止并观察恢复：检查降载后业务与资源是否恢复，记录异常、人工干预与数据一致性情况。
JMeter分析报告能够展示多类响应时间、吞吐和错误统计。但工具报表属于证据材料的一部分，正式报告还要说明测试对象、方法、条件、结果和判断依据。只截取一段平稳曲线，忽略增压阶段错误或结束后未恢复，会使读者无法理解完整表现。
发现瓶颈时，应区分观察与原因结论。例如“数据库连接等待增加”是观察，是否由连接池配置、慢查询或外部依赖引起，还需进一步证据。整改后复测应使用可比较的条件；若配置改变，写明变化，不能把两次不同环境的最好结果拼在一起。
五、性能报告至少讲清这些内容
核稿时把“需求—测试用例—结果—结论”逐项对应。每项合同指标应找到相应测试条件与数据；未测、无法评价和不适用应分别说明，不用一个“整体运行正常”覆盖所有未完成项。
| 报告内容 | 复核重点 |
|---|---|
| 产品与环境 | 版本、部署、资源、数据和依赖范围 |
| 方法与场景 | 业务脚本、负载模型、阶段及停止条件 |
| 结果与记录 | 实际负载、响应、吞吐、错误及监控证据 |
| 判定与限制 | 逐项指标是否满足、依据及未覆盖场景 |
常见问题
问：性能测试做多少并发才够？
先看需求和使用场景，没有适用于所有软件的统一人数。还需明确这些用户执行的业务、请求节奏、数据规模与持续时间。
问：只有工具生成的HTML，算正式第三方报告吗？
不能仅凭文件格式或工具名称判断。正式第三方报告需要实际承担机构按相应方法和签发程序出具，工具结果可作为可追溯材料。
问：压到系统报错就是测试失败吗？
要看测试目的。探索极限时可能有意达到退化点；验收负载下发生错误是否不满足要求，则需按已明确的指标与判定规则判断。
问：只测接口，能证明网页打开速度吗？
接口耗时通常不能完整代表用户端加载、渲染及交互体验。有这类要求时，应另明确浏览器、终端、网络与页面指标。
六、官方来源与委托准备
核对日期：2026年10月19日。本文介绍一般软件性能测试组织与报告核对，不为具体软件预设合格阈值，也未对任何在线网站执行压力测试。
- JMeter术语说明｜Apache Software Foundation
- JMeter分析报告生成｜Apache Software Foundation
- 压力测试｜Grafana k6
- 网站负载测试｜Grafana k6
- 检验检测机构监督管理办法（2025年修订）｜国家市场监督管理总局
权检认证（深圳）有限公司可协助将合同性能条款整理为测试项目清单。准备需求原文、系统版本与部署资料、业务流程、测试数据方案和交付要求后，再与实际承担机构确认测试方法、环境、能力范围及报告安排。
配图为技术示意或AI生成场景，不是客户项目、真实报告或检验记录。
本文包含AI辅助创作内容。具体规则以相应官方现行信息为准。
