一、先分清三个数字：注册人数、在线人数和请求量
“我们有三万会员，系统要支持三万人。”这个说法不能直接变成开发要求。
三万会员可能大部分一周才打开一次，也可能在同一分钟抢同一批名额。真正需要讨论的，是活动期间的到访节奏、用户停留时间、操作频率，以及哪些操作会集中发生。
| 老板常说的数字 | 它能说明什么 | 还需要补充什么 |
|---|---|---|
| 注册会员数 | 用户规模和数据规模 | 每天有多少人使用，活动会触达多少人 |
| 同时在线人数 | 一段时间内保持活跃的用户数量 | 这些人是在看图片，还是都在提交订单 |
| 每秒请求数 | 系统每秒收到多少次接口请求 | 是查商品、领券、查库存，还是创建订单 |
| 每分钟成交单数 | 一段时间内的有效交易量 | 支付、库存、发货任务能否一起跟上 |
一个用户打开一页，可能引发商品、价格、库存、优惠券等多次请求；一千个在线用户也可能只是阅读图文，没有同时写入数据。把“在线人数”直接当成“下单并发”，会让报价和测试都失去依据。
如果新业务还没有历史数据，可以先做容量假设。例如预计一万人收到活动链接，其中两千人在最初五分钟进入，再估计浏览、领券、下单的比例。这只是规划假设，不能写成已经验证的承载能力。 活动结束后还要用真实数据修正下一次预估。
二、不要只测首页，要测最容易出事的业务链路
首页能打开，往往是最容易证明的一件事。图片可以提前加载，静态内容可以缓存，而领取最后一张券、扣减最后一件库存、提交支付结果，涉及的是另一组压力。
电商或预约类小程序，至少应该按真实使用路径讨论这几条链路：
- 进入活动页，查看商品或服务详情；
- 领取优惠券，判断是否满足使用条件；
- 选择商品、门店、日期或服务名额；
- 提交订单，计算金额并预留库存；
- 调起支付，接收支付结果并更新订单；
- 查询订单，取消预约或申请退款；
- 后台查看订单，导出活动数据，处理售后。
浏览和交易可以用不同的负载比例测试。但不能为了让结果好看，只挑读取缓存的接口，也不能省去活动当天最关键的写入操作。
还有一个经常被忽略的场景：运营同时做大量后台操作。前台正在接单，后台开始导出十万条记录，或者批量发送消息，两边共用数据库和服务器资源。容量方案需要说明这些任务会不会相互影响，是否需要错峰、排队或限制。
三、把“不卡”拆成速度、成功率和业务正确性
“响应快”不能只看平均值。十次操作里九次很快，一次卡了半分钟，平均数字仍然可能不难看，而那一次恰好可能是用户付款后的订单查询。
老板可以让开发方提供“95% 的操作在多长时间内完成”这类指标，同时保留超时次数和最长等待时间。具体数值必须结合业务复杂度、网络条件和测试范围约定，不能从别人的项目直接照搬。
更重要的是，速度之外还有业务是否正确：
- 同一笔操作反复提交，会不会创建多张订单；
- 库存不足时，会不会继续收款；
- 支付结果重复通知，会不会重复发货；
- 请求超时以后，用户能否查到确定结果；
- 活动结束时，领券数、成交数和实际资金是否对得上。
成功返回一个页面，不等于成功完成一笔业务。 压测结束后，应该检查订单、库存、优惠券、支付记录和后台统计的变化。只交一张“接口成功率 99%”的截图，不足以说明交易链路可靠。
如果需要补齐整体交付材料，可以结合站内的软件项目验收资料清单一起约定。本篇关注的是高峰下的容量和业务一致性，验收资料则负责把结论留成可追溯的证据。
四、至少讨论四种测试，而不是只跑一次
Grafana k6 的官方文档区分了负载、压力、突发、长时间运行等测试方式。对老板来说，不需要记住工具名，但要理解它们分别回答什么问题。
| 测试方式 | 它回答的问题 | 适合检查的情况 |
|---|---|---|
| 常态负载测试 | 预计正常高峰下能否稳定工作 | 日常营业、常规活动流量 |
| 压力测试 | 继续增加负载后，哪里先出现瓶颈 | 承载上限、扩容和降级时机 |
| 突发测试 | 流量突然涌入时，会不会来不及反应 | 直播引流、开售、统一发券 |
| 持续运行测试 | 高负载维持较长时间，会不会逐渐恶化 | 内存累积、连接耗尽、积压任务 |
突发和持续运行尤其值得单独讨论。一套系统可能缓慢增加流量时表现很好，面对突然进入的用户却来不及扩容；也可能前五分钟顺畅，半小时后开始堆积消息和订单任务。
测试结果不只是一个“通过”。它还应该说明负载达到什么水平时开始变慢，哪些资源先接近上限，恢复以后积压任务用了多久清空，以及是否出现重复或遗漏的业务记录。
五、测试环境和生产环境差多少，要写在报告里
开发方在一套更高配置的环境里测出了结果，正式上线却使用较低配置，数字就没有直接比较价值。反过来，在小型测试环境里失败，也不能立刻证明正式环境一定不行。
报告至少要注明：
- 应用、数据库、缓存和队列分别使用什么资源；
- 是否启用与生产一致的限流、日志和权限检查；
- 数据库里有多少用户、商品、订单和历史数据；
- 测试从哪里发起，网络条件是什么；
- 哪些第三方调用使用了模拟响应；
- 哪些结果经过真实集成验证，哪些仍需要单独确认。
尤其不能用空数据库证明历史订单很多时仍然好用。列表查询、库存判断、报表和导出可能在数据增长以后出现新的瓶颈。
支付、短信、地图等第三方服务也有各自的调用规则和额度。未经安排就向真实支付或短信接口大量发请求，既不能得到完整的容量结论，也可能产生费用或触发平台限制。更合理的做法是把内部承载测试和第三方集成验证分开记录，再明确整条链路还有哪些外部约束。
六、扩容之外，先准备超出容量时的经营办法
服务器扩容能解决一部分资源不足，但未必能解决单件库存竞争、数据库锁等待、外部接口限流和重复执行。临时加机器也需要时间，不是活动现场的一句承诺就能完成。
老板应该提前批准超出容量时的处理顺序。哪些功能必须保住，哪些可以稍后再做，用户会看到什么提示，客服如何查询最终结果，都属于交付方案。
例如，可以优先保住已支付订单的查询和处理，让非关键报表稍后生成；对领取名额的请求做有序排队；对于不能确认结果的交易，显示“正在确认”，而不是让用户不断重新支付。
排队也不是把请求无限留在系统里。要有等待上限、退出方式、超时处理和后续通知。用户排队结束后，价格、库存、优惠券是否仍然有效，也要讲清楚。
七、老板可以用这张表和开发方确认容量要求
这是一份填写模板，不是所有小程序通用的性能标准。双方应该根据活动数据、业务风险和预算把空项补齐。
| 要约定的事项 | 需要写清的内容 |
|---|---|
| 活动假设 | 触达人数、到访时间分布、预计订单量、增长余量 |
| 测试路径 | 浏览、领券、提交订单、支付结果处理、订单查询的比例 |
| 响应要求 | 不同操作的等待时间、慢请求比例和超时处理 |
| 正确性要求 | 不超卖、不重复扣减、不重复发货，业务记录可核对 |
| 测试环境 | 资源配置、数据规模、第三方模拟范围和版本 |
| 超出容量时的行为 | 限流、排队、降级、暂停活动的触发条件 |
| 交付证据 | 负载曲线、错误样本、业务校验、瓶颈说明和改进结果 |
| 活动保障 | 值守联系人、监控范围、扩容权限、响应时间和费用 |
把这张表放进需求或验收附件，会自然影响报价。只做首页浏览测试，和验证完整下单链路、准备活动值守，工作量不同。老板可以根据实际风险删减范围，但要知道删掉的是哪一项保障，而不是以为“压测”两个字已经包含全部。
关于资源和长期运行费用，可以继续阅读定制系统上线后的年度成本清单，把一次性验证费用与活动期间的资源、值守费用分别预算。
八、已经开发完了，活动前还来得及做什么？
时间不多时，优先确认活动假设和关键交易链路，不要临时增加一大批促销功能。
可以先在约定环境里完成一次常态负载和一次突发测试，核对订单、库存及支付结果；再把监控、异常提示、人工处理清单和暂停入口检查一遍。测试没有覆盖到的边界，要明确记录，活动流量也应按已经验证的范围控制。
如果关键写入链路仍然会产生重复订单或错误库存，就不应该用“先上线看看”解决。先缩小活动规模、分批开放或调整业务方式，通常比把不确定性一次性暴露给全部客户更容易收场。
老板最终需要拿到的，是一句有条件、有证据的话：在约定环境、数据规模和业务路径下，系统已经验证能够处理什么规模的高峰；超过这个范围，按什么方案降级和恢复。
华茂思捷提供小程序开发与技术顾问服务。如果你准备做活动、直播引流或旧系统扩容，可以先带上预计客流、订单路径和现有部署信息，联系我们梳理容量要求。更多项目判断可以查看老板必读。
参考来源
- Grafana k6：测试类型及各类测试的目标。本文采用其测试分类解释容量验证，不把工具选择或单一压测数字当作经营保障。
文中的活动人数和场景是说明方法的假设，不是华茂思捷已完成的客户项目，也不是对任何具体系统的承载承诺。
