人数不是唯一的压力指标
一百人同时浏览静态内容，与一百人同时提交订单、上传文件或生成报表，对系统产生的负载不同。性能需求应写明用户会做什么、操作频率和数据规模，而非只提出支持很多人在线。还要区分日常使用和短时高峰，确定哪些核心操作最需要保持响应，让测试目标与实际业务场景对应。
建立可重复的测试条件
测试环境的服务器资源、数据库规模、缓存状态和外部接口条件会影响结果。记录这些条件，才能比较优化前后差异。准备接近实际分布的样本数据，例如有些客户关联很多订单、有些用户拥有更复杂的权限。不能只在空库里重复点击一个简单页面，再把结果推广到全部业务功能。
关注等待发生在哪个环节
页面慢可能来自网络、数据库查询、文件处理或第三方服务，先观察再决定优化方式。批量导出与日常查询可以采用不同的处理路径，避免耗时任务占满关键资源。对于外部服务故障，应设置清楚的超时与失败反馈，不能让所有请求无限等待。具体性能目标和资源成本需要一起评估，避免只追求单一数字。
验收稳定性与恢复能力
除了正常高峰测试，还可以检查持续运行、突发流量和外部依赖变慢的情况，确认没有重复写入或任务丢失。报告记录响应分布、错误情况和资源变化，并对应到具体业务操作。上线后根据真实使用继续观察，性能验收提供的是在明确条件下的证据，不能被理解为任何规模下都不会出现瓶颈的承诺。
方案落地前需要确认
本文以“系统性能验收”为主题讨论功能设计，属于方案指南，不代表某个客户项目的实际交付承诺。具体实施前，应由业务负责人确认适用规则、使用角色、现有系统接口和验收方式，再通过原型验证关键操作。对于暂时不能确定的条件，保留待确认清单，在范围明确后评估开发周期与费用，避免将示例直接套用于不同企业。