WiFi认证系统从试运行切换到正式上线，中间有一个关键节点——验收。验收不是走个签字流程，而是确认这套系统在真实运行环境下到底能不能顶住。从实际项目经验来看，验收阶段有几个问题出现的频率非常高。

规模压力测试做没做到位

绝大多数项目的验收测试是在"少量测试终端"的环境下完成的——办公室里拿几台手机连一下、认证通过、测速正常、就验收通过了。但这个测试环境和上线后的真实环境差距非常大：真实环境下可能同时有几百甚至上千台设备在连接WiFi，并发认证的压力是测试环境的几十倍。

验收阶段至少要做一个规模化的并发测试。测试方式不需要多复杂：用几台PC运行自动化脚本，模拟200到500个终端同时发起认证请求，观察认证服务器的响应时间、超时率、以及认证成功率。如果并发500个认证请求的P95响应时间超过5秒，或者超时率超过2%，就意味着上线后高峰时段可能会有用户感知到明显的认证延迟。

压力测试过程中还要特别关注Radius服务器的资源消耗情况——CPU使用率会不会飙升到接近100%、内存有没有持续增长的趋势（可能存在内存泄漏）、UDP缓冲区有没有丢包。这些问题在不加压的情况下是看不出来的。

终端兼容性验证的覆盖面够不够广

验收测试用的是什么终端？如果只用了测试团队自己的手机——大概率是同一品牌的最新款旗舰机——这个测试覆盖面和真实环境的差距就太大了。真实环境里什么样的终端都有，老的、破的、系统版本好几年没更新的、杂牌山寨机、各种IoT设备。

验收时需要准备一个有代表性的终端兼容性测试清单，至少包括：iOS最近三个大版本、Android最近三个大版本（覆盖不同品牌的代表性机型）、Windows和macOS笔记本各一种、至少两种不同品牌的IoT设备。每种终端要完成完整的认证流程——从关联WiFi到Portal弹出到输入验证码到认证成功到正常上网——每一步都要验证。

特别要注意的是Portal页面的兼容性。不同终端上的系统内置浏览器行为差异很大，有的会自动关闭认证页面、有的会缓存上一个页面的内容、有的对HTTPS证书验证非常严格。这些差异在单一终端测试中不会被发现，但在上线后会变成不同用户遇到的完全不同的问题。

异常场景的容错能力有没有测过

验收测试通常测的都是"正常流程"——正常输入手机号、正常收到验证码、正常认证成功。但真实运行环境里，异常情况才是运维最大的工作量来源。验收阶段至少要覆盖这些异常场景：输入错误的验证码、输入格式不正确的手机号、同一个账号同时在多台设备上登录、认证过程中切换飞行模式再打开、认证过程中走出AP覆盖范围再走回来。

每一种异常场景，系统应该有确定的行为——是拒绝认证并给出明确提示，还是自动恢复会话，还是让用户重新开始认证流程。如果验收的时候发现某些异常场景下系统的行为不确定或者不一致，那就需要在上线前修复。上线之后再发现这些问题，修复成本就高太多了。

备份和恢复机制的实操验证

WiFi认证系统的配置数据——认证策略、用户数据、Portal页面模板、Radius参数——是需要做备份的。但很多项目在验收的时候只确认了"有备份功能"，没有实际做过"从备份文件恢复到一台空设备"的实操验证。

建议在验收阶段做一次完整的备份恢复演练：在测试环境里部署一台相同的认证系统设备，用生产环境的备份文件做一次全量恢复，然后逐一验证配置数据、用户数据、认证策略是否完整恢复。这个演练如果在验收阶段不做，等到真的出故障需要恢复的时候，可能会发现备份文件有缺项或者格式不兼容——那时候就来不及了。

切换方案的验证

如果这是替换一套老WiFi认证系统的项目，验收时还有一项容易被忽略的工作：新旧系统的切换方案验证。切换方案不是"凌晨两点割接就完了"，而是需要有明确的回滚方案。如果切换之后发现问题——比如大量用户认证失败——能不能在半小时内切回老系统？切回老系统之后，老系统的数据和配置是不是完整的、没有被新系统影响？

验收阶段的切换验证，建议先在非高峰时段做一次试切换——切换过去跑两小时，观察各项指标，然后切回来。试切换通过之后，再做正式割接。两次操作分开做，风险可控得多。

WiFi认证系统的验收，本质上是一次风险的集中排查。验收阶段多花一天排查问题，比上线后花一周处理故障要值得多。把上面这几项在验收清单里列清楚、逐项验证，不跳项、不走过场，项目才算真正完成交付。