WiFi网络计费系统的验收测试是一个特别容易被流于形式的工作。大多数项目的验收就是走一遍功能清单：认证能通、计费能算、支付能付、报表能看，检查完就算验收通过了。但以我参与过几次项目验收的经验来看，真正的风险点都在那些"功能清单上没写但实际运行中一定会遇到"的场景里。

验收测试最大的盲区就是只测正常流程不测异常流程。怎么测异常流程？首先要列出所有可能的异常场景：NAS突然重启、RADIUS服务宕机、数据库连接断开、网络出口中断、支付平台回调延迟、用户余额不足时并发发起多次认证——这些场景在实际运行中几乎一定会发生，但大多数验收方案里根本没有涉及。

每一类异常场景的测试都至少要覆盖三个维度：系统是否能正确检测到异常、系统在异常期间是否能保持可接受的降级服务水平、系统在异常恢复后是否能自动恢复正常运行。比如NAS重启的场景，WiFi网络计费系统应该在检测到NAS下线后进入等待恢复状态，当NAS重新上线后自动重新建立RADIUS连接，而不是需要人工介入重启服务。

WiFi网络计费系统的计费准确性光靠手动验证是不够的——手动测试只能覆盖几个用户的几条计费记录，实际运行中可能是几千条记录同时产生。验收测试里应该包括计费的自动化压力测试：用脚本模拟一定数量的用户并发认证和使用流量，然后比对系统记录的计费数据和模拟脚本生成的预期数据，看误差率是否在可接受范围内。

这个测试的难度在于要模拟真实的流量使用——不是只发几个ping，而是模拟浏览网页、看视频、下载文件这些真实场景下的流量特征。简单的做法是用iperf或者curl来产生流量，复杂一点的做法是录制真实用户的流量模式然后回放。

很多验收测试停留在"功能模块级验证"——认证模块测一下、计费模块测一下、支付模块测一下，各测各的。但WiFi网络计费系统是一个完整的业务流程链：用户注册→账户充值→连接WiFi→Portal认证→上网→计费扣费→对账结算→数据报表。任何一个环节断掉都会影响整个链条。

端到端的验收应该模拟完整业务流程走一遍，从"一个新用户第一次看到Portal页面"开始，到"月底财务拿到对账报表"结束，中间每一步都要验证数据是否完整传递、状态是否正确更新。

大部分WiFi网络计费系统的验收测试都只做短期测试——跑一轮功能检查就结束了。但系统的长期稳定性是另一个重要维度。建议在正式验收前至少做一轮至少七十二小时的稳定性测试，模拟正常业务负载连续运行，观察系统的CPU、内存、磁盘使用趋势，以及是否有慢查询积累、日志膨胀、内存泄漏等问题。

七十二小时的持续运行虽然不能完全替代一个月的实际运营，但至少能把那些短期内就会暴露的稳定性问题找出来。WiFi网络计费系统的验收测试最怕的就是形式主义——功能清单上全部打钩，但实际上连最基本的异常恢复都没测过。验收的目的不是走完流程交差，而是在系统正式投入使用之前尽可能多地发现隐患。异常场景覆盖不足、计费精度没做自动化验证、端到端业务流程存在断点、长期稳定性没有验证——这四个问题是验收阶段最常见的盲区。把验收做扎实了，上线以后的运维压力至少能减轻一半。验收不是终点，但把验收做得足够充分至少能给你一个相对干净的起跑线。上线以后的新问题会不断冒出来，但那些本可以在验收阶段就发现的问题，不应该成为上线以后的第一批工单。最后说一个实操建议：验收测试不要只由实施方自己做，一定要有甲方的技术人员或者至少是运营负责人全程参与。因为实施方对系统的熟悉程度和操作习惯跟甲方完全不同，很多实施方觉得"没问题"的地方，恰恰是甲方上线以后会频繁卡住的环节。甲方参与验收不是为了找茬，而是为了确认系统在自己团队手里确实能跑通。把验收测试的参与范围扩大一些，把验收标准写得更具体一些，把验收文档留得更完整一些，这三件事做到位了，上线以后的磨合期会短很多。验收文档的价值在于它不是给实施方看的，而是给未来的自己看的。一年以后系统需要升级、两年以后需要扩容、三年以后换了运营团队，新接手的人能靠验收文档快速理解系统的边界和已知的限制条件，而不是从零开始摸索。