学校WiFi网络计费系统部署完成后，验收是正式移交使用前的最后一道关卡。很多学校的验收测试只做了基本功能确认——账号能创建、充值能到账、认证能通过——就签字完工了。但一些关键场景在基础测试里不会出现，一旦遗漏，就会变成上线后的隐患，在最不合适的时候爆出来。把这些容易被忽略的测试场景提前列出来，是做好验收的第一步。

高并发认证压力测试不可省略

基础功能测试通常只有几个测试账号同时在线，这和真实运行环境差距很大。开学第一天或者课间换课时，可能几百到几千人同时发起认证请求。如果系统在高并发下出现响应超时或认证失败，学生无法上网，投诉会立即爆发。

压力测试应该模拟峰值并发场景：短时间内发起正常使用量1.5倍的认证请求，观察认证成功率和响应时间。成功率低于99%或者响应时间超过3秒，都需要优化。这个测试不需要真实用户参与，可以使用RADIUS测试工具模拟，但必须在验收前执行，不能把它推迟到上线后再做。

欠费断网和自助恢复的完整链路测试

欠费断网的测试通常只做"把余额清零，确认断网"，但完整链路不止这一步。断网后Portal是否能正常弹出？欠费账号是否还能访问充值页面？充值成功后多长时间恢复上网？这个时间是否符合承诺的标准？恢复后流量计费是否正常继续？

每个步骤都需要测试，而不是只看最终结果。特别是充值到恢复的时间间隔，这是用户体验最直接的指标。如果测试时发现恢复需要几分钟，应该在验收前明确这个数据，并在运营文档里告知用户，避免用户充值后立刻投诉"还没恢复"。

多设备切换和绑定上限的边界测试

学生通常有多台设备，设备绑定数量有上限。验收时需要测试上限边界场景：绑定了最大数量的设备后，再试图添加新设备会怎么样？是提示超限还是静默失败？旧设备解绑后，新设备能否立即绑定还是需要等待？这些细节如果测试时没有发现问题，上线后学生在换新手机或新电脑时就会遇到障碍。

还有一个常见漏洞：设备更换后，旧设备的绑定记录如何处理？如果系统没有自动解绑机制，学生用旧设备绑的配额被占用，新设备无法绑定，需要联系管理员手动处理，运营成本很高。这个流程是否有自助解绑功能，是验收时必须确认的项目。

日志完整性和合规溯源测试

验收时应该专门测试日志的完整性：某个账号在某个时间段的认证记录和流量记录是否完整？日志是否包含完成溯源所需的字段（账号、IP、时间、访问目标）？如果指定一个测试账号在某个时间段上网，之后从日志里能否精确找到该账号的所有活动记录？

日志查询界面也需要测试：输入账号和时间范围后，查询结果是否在合理时间内返回？如果数据量大，查询性能是否能接受？这些细节直接影响日后处理用户投诉和配合合规检查的效率。如果验收时不测，上线后才发现日志查询很慢，再优化的代价就大了。

跨区域策略的正确执行验证

如果系统配置了宿舍区和教学区不同的计费策略，验收时必须分别验证：在宿舍区接入，计费是否按宿舍区的套餐规则执行？在教学区接入，是否按教学区的免费或限速策略执行？在两个区域之间切换时，策略切换是否正确？

这类测试需要在真实网络环境下，用真实设备移动到不同区域接入，而不是在实验室模拟。区域策略如果配置有误，上线后会出现宿舍区学生没有被计费或教学区学生被意外计费的问题，两种情况都会引发投诉。

系统异常恢复能力的验证

学校WiFi网络计费系统的高可用验收，通常只做"主备切换是否正常"，但更细的场景往往没有测：主服务器重启后，已认证的用户会话是否还保持？数据库服务短暂中断后，计费数据是否有丢失？备机切换时，正在充值的用户是否会遇到异常？

这些异常场景的恢复能力，决定了系统在故障时的用户体验损失有多大。如果主备切换时会有几分钟的认证中断，这个情况应该在验收报告里明确记录，并评估是否在可接受范围内。把这些细节留白，上线后出了问题说不清楚，责任归属也模糊。

验收测试要有书面记录

最后，验收测试的过程和结果必须有书面记录。每个测试场景的步骤、预期结果、实际结果、是否通过——都应该记录在验收报告里。如果某个场景没有通过，是现场修复了还是遗留到后续处理，都要写清楚。

没有记录的验收等于没有验收。这份记录在后续出现问题时，是判断责任归属的重要依据。也只有记录完整，才能在每年的运维检查中评估系统是否在持续达标，还是已经开始出现性能退化。学校WiFi网络计费系统的验收质量，决定了后续运营的起点。