注册签到压力测试演练：如何检验 check-in

注册环节高负载验收的实操方案：峰值场景、安全数据、备份、PASS/FAIL 判定标准以及承包方报告。

压力彩排需要证明什么？

签到压力彩排应当证明：在真实客流下，宾客的整个流程都能正常运转——记录能被找到，二维码能被扫描，状态只变更一次，胸牌能打印出来，并且结果在相邻工位上可见。这里的签到是指查找记录并确认宾客到场。单个表单的成功响应或扫描器的提示音，还不能证明整个流程已经就绪。

我们 Aventura 首先确定检查边界。宾客出示邀请函或请求查找记录。系统校验状态、记录到场并将数据传送至打印。

操作员会收到明确的确认。依赖关系图中还包括外部服务。

完整的签到流程已在关于活动参与者签到的文章中详细说明。这里的任务更具体：在压力下检验该流程，并按照预先写好的标准得出“通过”或“不通过”的结论。

扫描器在成功解码条形码后可能发出提示音。这只能证明设备读取了字符，并不能证明中央系统中写入了新状态。因此，观察员要核对操作员屏幕、宾客卡片、打印结果和最终导出数据，而不仅仅是扫描器的反应。

用客户语言描述的峰值客流

我们通过宾客到达场景来设定峰值，而不是用整数虚拟用户数。客户描述到达时间窗口、主群体占比、多个入口、人工处理情形和并发操作。技术团队计算每分钟启动多少操作以及每个阶段持续多久。

对于会议组织，收集交通时刻表、全体会议开始时间、分会场准入规则和资料发放规则很有用。大巴到达或全体会议结束会形成需求台阶。即使之前的操作已经变慢，宾客仍会继续到来。

最小模型包括：

• 按时间窗口划分的预期宾客数量；
• 二维码、手动查找和无预先登记宾客的占比；
• 入口、柜台、扫描器和打印机的数量；
• 重复扫描和重新打印的占比；
• 状态或类别的临时变更；
• 对网络、邮件、短信和外部数据库的依赖。

这样的画像可以将技术负载与可见的排队情况对应起来。服务器可能响应很快，但工位仍因查找、打印或错误提示不清晰而服务宾客缓慢。因此，需要分别测量系统操作和柜台处的完整周期。

场景中应包含哪些操作？

场景应复现团队在入口处执行的业务操作，包括异常情况。只测试一个注册页面会带来虚假的“已就绪”感。主流程应与人工搜索、重复二维码、迟到登记和打印一起运行，以便观察对共享资源的争用以及复杂情况对队列的影响。

我们按以下方式构建路径：

1. 来宾出示二维码或提供用于搜索的信息。
2. 操作员找到唯一正确的记录。
3. 系统检查当前状态和访问权限。
4. Check-in 只更改一次状态。
5. 打印机打印带有最新类别的胸牌。
6. 相邻柜台无需手动刷新数据即可看到变更。
7. 最终导出包含一条已确认的签到记录。

场景中会加入错别字、同姓者、无二维码的情况、已使用过的码、迟到登记和补打胸牌请求。详细载体清单可对照关于活动中安全二维码的文章进行核对，但不要将负载测试变成单独的二维码安全审计。

后期变更也必须走完整个流程。在控制导出后创建或修改记录，然后检查搜索、权限、打印和新状态的传播。关于迟到登记的相邻材料有助于准备此类场景，而无需重复整个项目日历。

注册已完整融入活动执行流程。如果需要场地、供应商和入口团队的总体流程，请查看商务活动组织服务：我们会提前商定角色、控制点和备用方案。

我们也会在Aventura 的 Telegram 频道发布场地准备和团队工作的实用解析。

三种运行模式

在我们的验收协议中，我们使用三种模式：基础链路快速检查、预期工作流和突发峰值。它们回答不同的问题。一次平稳的加压可能掩盖脚本错误，而寻找极限容量并不能确认约定的峰值是否符合业务标准。

k6 文档中有针对基础检查、常规负载、过载、突发峰值和系统极限搜索的独立模式。客户不必深入了解工具配置，但需要理解运行的目的。

一种模式展示对突发涌入的反应，另一种寻找极限。工作运行则确认活动的具体场景。

在大规模演练之前，团队会对每条路径进行基础运行。它能发现错误的测试记录、缺少必要权限和集成错误。之后，负载按约定的曲线增加，而不是由技术人员即兴决定。

如何准备安全的测试数据？

用于演练时，最好使用合成档案，这些档案复刻嘉宾数据库的结构，但不包含真实联系方式。数据集中包含不同角色和类别。部分记录会模拟相似的姓氏、较晚的变更和例外情况。在启动之前，团队会确认访问权限和删除期限，并将对外群发转入安全的测试环境。

Federal Law No. 152-FZ 第五条的规定要求处理目的必须具体、数据须与该目的相符且不得过度。对于负载测试而言，这是一个实际理由：如果同一场景可以用虚构记录复现，就不要为了“逼真”而复制生产数据库。

数据集按以下步骤准备：

1. 确定实际参与 check-in 的字段和状态。
2. 创建所需类别和分布的合成记录。
3. 单独标记用于重复 QR、较晚变更和重新打印的记录。
4. 将操作员和观察员的访问权限限制为测试角色。
5. 阻止向真实收件人发送邮件和消息。
6. 指定验收后记录、日志和导出文件的删除期限。

对表格和同意的法律要求需要单独核查。相关材料见按 152-FZ 制定的注册表单。在负载演练中，我们检查的是已经批准的数据方案。测试记录的构成、访问权限、日志记录和保存期限应与个人数据负责人或律师协商确定。

启动前的「通过 / 未通过」（PASS/FAIL）标准

PASS/FAIL 是指按照事先记录的标准判定「通过 / 未通过」。请在测试前记录验收标准，并将其与承诺的宾客旅程对应起来。延迟或操作次数没有通用标准。项目团队应设定可接受的流量、错误、服务时间和停止规则，然后在不事后调整阈值的情况下，将实际结果与这些标准进行对比。

k6 的阈值条件会自动标记某项指标是否达到标准。不能将文档中的具体数值直接作为项目标准照搬。这些数值应由系统负责人、客户和运营团队结合可接受的队列和承诺的服务来确定。

一项特殊标准涉及负载生成器。如果计划的操作未能启动，报告所描述的流量将低于声明值。指标 dropped_iterations 有助于将被测系统的性能下降与资源不足或生成器自身配置错误区分开来。

演练时该破坏什么？

演练期间，我们会在约定的时间窗口内依次断开或减慢各个依赖项：网络、打印机、外部服务或某一台工作站。团队检查发现速度、提示信息的清晰度以及切换到备用方案的过程。每次故障都按脚本触发，并有权立即停止，且事先指定演练负责人。

有用的故障清单：

• 网络缓慢或短暂不可用；
• 某一台扫描仪或打印机故障；
• check-in 实际已完成但响应丢失；
• HTTP 响应“请求过多”，并注明重试前的等待时间；
• 外部数据库或打印服务不可用；
• 操作员因状态不明而重复点击；
• 手动标记后依赖项恢复。

立即自动重试可能引发新的请求浪潮：已经过载的服务会收到更多请求，恢复时间更长。如果操作会改变嘉宾状态，盲目重试可能造成重复记录。系统必须区分安全重试、等待和人工核对结果。

网络部分最好与场地基础设施负责人协商。会议嘉宾 Wi-Fi 一文解释了为什么不能用与嘉宾流量相同的通用速度测试来评估服务注册。

服务台、二维码与反馈

实验室测试还需辅以在真实服务台、设备和载体上的现场演练。团队检查不同亮度下的手机屏幕、纸质码、反光、重复靠近和噪声。操作员必须看到明确的操作结果，且该结果不能仅依赖界面中的声音或颜色。

GS1 将二维码的可读性与符号周围的空白区、对比度、平整网格以及无图形噪声联系起来。因此演练应包含嘉宾实际会遇到的尺寸、材质和展示方式。显示器上完美的测试图片不能替代真实载体。

在我们的场景中，我们检查六种可区分状态：“码已读取”、“正在校验”、“入场已确认”、“已标记”、“未找到记录”和“无连接”。W3C 状态消息指南要求状态变化能够以程序化方式确定，而无需强制转移焦点。对服务台而言，这也是员工培训速度的问题。

入口的物理布局、排队和设备摆放需要在选择场地时加以考虑。系统可能通过服务器测试，却因狭窄的门厅、多个类别共用一条通道或操作员需穿过嘉宾人流才能到达打印机而损失吞吐量。

如何检查备用方案与恢复？

只有在实际切换、继续签到并完成反向核对之后，备用方案才算有效。如果声称具备本地或离线模式，团队会断开主要依赖、累积操作、恢复连接并检查冲突。如果没有离线模式，则演练人工流程和面向所有签到台统一下达的切换指令。

恢复场景按以下步骤进行：

1. 演练负责人宣布所选依赖发生故障。
2. 团队记录发现时间和可见症状。
3. 签到主管下达一条统一的切换指令。
4. 操作员通过备用路径继续签到。
5. 观察员记录人工和本地标记。
6. 按约定顺序恢复主服务。
7. 核对数据、处理冲突并确认最终版本。

关于通信方案和本地名单操作的详细说明，请参阅无移动互联网的活动一文。在本次演练中，关键在于切换节点和反向同步：由谁下达指令、操作员看到什么，以及如何排除重复的到场标记。

备用方案不应由各签到台自行启用。未经协调的本地决策会产生多个版本的“真相”。由一位负责人决定模式，演练日志则记录时间、原因和适用范围。

承包商在压测运行后的报告

报告应展示实际产生的负载以及每项业务操作的结果。需单独列出限制条件和负责修复的人员。仅提供平均延迟图表是不够的。

客户需要按时间分布的性能概况、打印状态和备用方案的工作情况。对于严重缺陷，还需补充按原始场景重新运行的结果。

报告包括：

• 系统和场景的版本；
• 测试数据和设备的版本；
• 操作开始的计划分布；
• 实际产生的分布；
• 每项单独操作的结果；
• 错误和超时；
• “请求过多”响应及重试行为；
• dropped_iterations 和生成器资源；
• 工作场所的完整服务时间；
• 打印队列和重复发放的情况；
• 切换到备用方案及恢复的结果；
• 缺陷清单、负责人和复检标准。

我们将缺陷与可复现的场景关联起来。卡片中保留原始条件和操作步骤。同时注明预期结果以及团队在运行中实际看到的情况。

为继续工作，需记录影响、临时措施和负责人。总体方法可参考活动现场事件日志。在场地开放前，缺陷与活动工作日志分开管理。

“已修复”的消息并不能关闭问题。团队需在可比的原始条件下重复同一场景。如果结果发生变化，报告中会出现新的 PASS。如果没有变化，缺陷保持开放状态，或作为明确商定的限制条件予以接受。

客户验收清单

您需要的是一份简短的、可理解的确认清单，而不是访问每一份技术图表。在彩排结束前，请确认到达流程已复现、复杂情况未中断主流程、备用方案已实际启用。对于每个关键缺陷，指定负责人，并在修复后进行复测并记录结果。

1. 已描述到达时间窗口、入口和操作组成。
2. 每条路线的基础运行已在高负载前完成。
3. 预期流量和突发峰值已分别测试。
4. 实际强度与计划一致，或差异已得到解释。
5. 成功的二维码最终只产生一次正确标记。
6. 超时后重试不会产生重复记录。
7. 打印已在真实打印机和耗材上验证。
8. 手动处理走独立通道，不阻塞主流程。
9. 操作员能看到清晰的状态和下一步操作。
10. 使用了访问权限受限的合成数据。
11. 依赖故障和恢复已实际演练。
12. 每个关键缺陷在修复后均已复测。

现场彩排宜按照与活动技术彩排相同的规则构建：脚本、可观察结果、问题负责人和复测。区别在于焦点——这里整个团队只关注注册环节及其依赖项。

验收应覆盖客人在真实流量下、故障时和恢复后的完整路径。单独的扫描器或表单无法提供完整画面。

资料来源

• Grafana k6：负载测试类型
• Grafana k6：thresholds 判定标准
• Grafana k6：dropped iterations
• Microsoft Azure Architecture Center：重试风暴反模式
• Microsoft Azure Architecture Center：重试模式
• Zebra DataWedge：条码输入与反馈
• GS1：二维条码质量与可读性指南
• IETF RFC 6585：HTTP 429 Too Many Requests
• W3C WCAG 2.2：状态消息
• 联邦法律第 152-FZ 号：个人数据处理原则