问供应商“系统能支持五千人吗”，得到的答案可能仍不足以安排现场。五千人在一周内陆续参加，与五千人在两分钟内同时进入，给系统带来的压力不同。容量讨论先把人数、时间和操作过程说清楚，再谈当前方案能否承担。
总人数、同时在线与请求速率分开问
总人数描述项目覆盖规模，同时在线描述某个时段有多少人在场；请求速率描述单位时间内向系统发出多少请求。一个人可能阅读很久没有请求，也可能在一个操作中触发多个请求，因此三者不能直接换算。
提交答案、保存进度、生成报告等具体行为，还会影响不同环节。产品实际怎样处理这些动作，应由服务方说明，不应仅凭测评持续时间推断连接一直保持或数据库持续写入。
可参考微软负载测试概念说明，区分虚拟用户、请求和响应等指标。机构不需要自己设计压测工具，但需要知道供应商测了怎样的使用过程。
两个平均数，只能说明各自的问题
假设某段稳定运行期间平均有五千人同时参与，每人平均停留十五分钟，也就是九百秒。在这种稳态、进入与离开大致平衡的条件下，平均进入速率约为5000÷900，约每秒5.56人。它不是系统请求速率，也不能用来保证突发高峰。
另一个情境是五千人在两分钟内集中进入。这个进入窗口的平均速率为5000÷120，约每秒41.67人；如果其中不少人在同几秒点击，瞬时峰值还会高于窗口平均值。两种算式的前提不同，不能混用，更不能只凭项目总人数除以作答时长计算容量。
最终需要验证的是当前方案在约定使用路径和高峰安排下的实际表现，而不是把一个平均数写成产品容量承诺。
把施测安排写成供应商能验证的情境
提供预计批次人数、进入时间窗口、常见设备与网络条件、预计作答时长，以及是否集中提交和同时查看报告。若不同校区或部门采用不同安排，分别说明。
请服务方据此说明测试条件、覆盖环节、结果与限制。仅有首页打开很快，不能代表提交和报告生成也经过同样验证。评估中使用获准的测试材料，不把真实受测者资料作为默认测试数据。
容量与现场组织一起确认
若现有条件不适合全部集中进入，可以讨论分批、错峰或提前准备等安排，但应由双方确认实际效果与资源条件。现场需有明确的技术联系人与替代安排，参与者遇到异常时知道该等待、记录问题还是联系工作人员，避免连续重复提交。
方案改变，例如增加人数、缩短进入窗口或集中生成更多报告时，再核对原测试是否覆盖。可靠的容量答复应该带着时间安排与验证条件，而不是一个脱离场景的最大人数。