WiFi网络认证系统的测试往往是项目里被压缩最严重的环节。工程商完成设备安装后，把账号给你，让你连上去试一下，能认证就算交付了。这种"能用就行"的验收方式，会留下大量隐患——高并发下认证超时、特定设备型号认证失败、实名日志不完整、Portal页在iOS上弹不出来……这些问题在正式运营后会一个接一个地出现。正式的测试验收应该在上线前完成，而不是靠用户投诉来发现。

功能测试的覆盖范围

功能测试要覆盖所有认证方式，而不是只测一种。如果系统支持手机号短信、微信公众号授权、房间号三种认证方式，就要把这三种都完整走一遍，包括正常流程和异常流程。

正常流程测试：按标准步骤完成认证，验证账号能正常上网、上网时长和流量是否按配置限制、退出登录后是否能正确注销。

异常流程测试：这部分容易被忽略，但更重要。输入错误的手机号、验证码填错了、账号余额不足时、短信延迟超过60秒时、用同一账号在两个设备同时登录时——这些情况的处理逻辑是否合理，错误提示是否清晰，是功能测试必须覆盖的。

多终端兼容性测试

Portal页在不同终端上的表现差异很大，必须专门测试。测试终端要覆盖以下类型：

iOS系统（Safari、微信内置浏览器）：iOS的Captive Portal弹窗机制和Android不同，有时候弹的是系统自带的简化页而不是完整的Portal页。要验证这种情况下认证流程是否能完整走完。

Android系统（原生Chrome、各厂商定制浏览器）：部分国产Android设备的网络检测逻辑有自己的实现，Portal弹窗行为和AOSP不一样。华为、小米、OPPO的设备都要单独测，不能假设Android设备的行为都一样。

笔记本电脑（Windows、Mac）：笔记本用户连WiFi后通常不会自动弹Portal，需要打开浏览器访问任意HTTP页面才会触发重定向。测试时要模拟这个场景，验证HTTPS页面是否也能正确触发重定向（部分系统配置对HTTPS的处理有差异）。

并发压力测试

压力测试的目的是验证系统在预期峰值负载下的表现，而不是验证"系统能不能用"。要先估算场景的峰值并发量：酒店早7点退房高峰大约会有多少设备同时进行认证？商场开门时刻大约会有多少认证请求集中打过来？

压力测试的核心指标：认证响应时间（P95/P99分位，而不只是平均值）、认证成功率（在峰值压力下是否有认证失败）、服务器CPU/内存/数据库连接池使用率（判断是否有余量）。如果厂商提供的系统在压测报告里只有平均响应时间，要专门要求P95分位数据。

合规相关的测试

合规测试经常被省掉，但这是出问题后最麻烦的部分。需要验证的核心项目：

日志完整性：用测试账号完整走一遍认证流程，然后在后台查询日志，确认认证时间、手机号（或其他实名标识）、IP地址、MAC地址、连接时长都有记录，且记录的时间和实际操作时间一致。

日志格式合规性：要求厂商提供一条测试日志，和当地公安要求的日志格式对照，确认字段名称、字段类型、时间格式都符合要求。这个对照工作不要等到检查时才做。

日志保留能力：模拟系统运行六个月的日志量（估算日均日志量×180），确认存储空间够用，以及日志在满了之后的处理机制（告警？自动归档？删除最旧的？）。

故障恢复测试

在上线前做一次故障恢复演练，是经常被省略但价值很高的测试。手动关停认证服务，验证：现有在线用户是否受影响（被踢下线还是维持）、新用户的认证请求如何处理（超时报错还是有提示页）、服务恢复后是否需要所有在线用户重新认证、备份认证服务器（如果有）能否自动接管。

数据库故障同样需要测试：模拟数据库连接失败，观察认证系统的行为，确认系统有合理的错误处理而不是直接崩溃。

验收标准的制定原则

验收标准要在项目合同里明确，不能等到上线前才讨论。几个关键的验收指标：

认证成功率：正常情况下认证成功率≥99%，峰值压力下≥95%。

认证响应时间：P95分位认证响应时间≤3秒。

终端兼容性：在主流iOS、Android设备（各至少3个型号）上Portal页正常显示和认证成功。

合规日志：每次认证都有完整日志，日志格式符合当地要求，支持按手机号和时间段查询。

以上标准是基础门槛，不是上限。有条件的项目可以在合同里加上更具体的指标，比如故障恢复时间SLA、Portal页加载时间上限等。把验收标准写清楚了，验收时才不会陷入"能用就行"的模糊判断。

验收不只是技术团队自己的事，建议邀请业务侧代表（前台主管、商户代表等实际使用方）参与验收测试。这些人对"好用不好用"的感知比技术指标更直接，他们发现的问题往往是技术测试容易遗漏的。在系统上线前把这些问题解决掉，比上线后再修补要省力得多，也不会影响已经在运营中的场所。