The WiFi network certification system is often the most compressed link in the project. After the installation of the equipment, the engineer gives you the account number and lets you go up and try it on, so that this can be done."It's good enough to work."The way they receive and inspect them leaves a lot of problems.——High-timed certification, failed equipment model authentication, incomplete real name logs, Portal page not available on iOS……These problems arise one after the other.
Coverage of functional tests
The functionality test covers all authentication methods, not just one. If the system supports mobile phone text messages, micro-public authorization, room number certifications, it takes a full look at all three, including normal and unusual processes.
Normal process test: Validation is completed as a standard step, to verify that the account number is connected to normal Internet access, that it is configured for length of time and traffic, and that it can be properly cancelled after exiting login.
Anomalous process test: this is easy to ignore, but more important. Entering the wrong cell number, misfilled authentication code, when account balance is insufficient, text message delayed by over 60 seconds, login with the same account number at both devices——The logic of handling these cases is reasonable and the error hints are clear and must be covered by functional tests.
Multi-end compatibility tests
Portal pages vary widely from one terminal to another and must be tested specifically.
iOS (Safari, Micro-Trust Internal Browser): The iOS's Captive Portal window mechanism and Android are different, sometimes playing a simplified page of the system instead of a full Portal page. To verify whether the authentication process is complete in such cases.
Android systems (original Chrome, agreed browsers at various plants): The network detection logic of some national-produced Android devices has its own realization, and Portal windows behave differently from AOSP. All equipment in China, Mi, OPPO are individually measured, and it cannot be assumed that the Android device acts the same.
Notebook computers (Windows, Mac): The laptop user does not usually play Portal automatically after WiFi and needs to open a browser to access any of the HTTP pages before triggering re-direction. Tests are done by simulating this scenario and verifying whether the HTTPS page is also correctly triggered by re-direction (some system configurations differ in how HTTPS is handled).
And stress tests.
The purpose of the pressure test is to verify the system's performance at its intended peak, not to validate."Is the system working?". The peak and volume of the scene is estimated: how many equipment will be certified at the hotel's 7 a.m. Hotel exit peak? How many requests for certification will be called in when the mall opens?
Core indicators for pressure testing: authentication response time (P95/P99 split, not just average), certification success rate (whether there is a failure of certification under peak pressure), server CPU/RAM/database connection pool usage (judgment of residuals). If the system provided by the manufacturer has only an average response time in the stress report, P95 partition data are specifically requested.
Compliance-related tests
Compliance tests are often eliminated, but this is the most problematic part of the problem.
Log integrity: complete the authentication process with a test account and then search the log at the back, confirming that the time of authentication, cell phone numbers (or other physical name identification), IP addresses, MAC addresses, connections are recorded and the time of recording is consistent with actual operation.
Log format compliance: the manufacturer is required to provide a test log, and to match the log format required by local public security, confirming that field names, fields type, time format are in order. This check will not be done until it has been checked.
Log retention capacity: log volume for six months of operation of the simulation system (estimated average daily log volume)×180), confirm that there is sufficient storage space and the mechanism for processing logs after they are full (alarm? Auto-archiving? Delete the oldest?
Failure recovery test
A failure recovery exercise before being online is often omitted but highly valuable. Manually shut down the authentication service to verify whether existing online users are affected (kicked off or maintained), how new user certification requests are handled (overtime or tippage), whether all online users need recertification after the service has been restored, and if back-up authentication servers can be automatically taken over.
Database failures also require testing: simulation of database connections fail, observation of the behaviour of authentication systems and confirmation that the system has a reasonable error processing rather than a direct breakdown.
Principles for the establishment of acceptance and inspection standards
The acceptance and inspection criteria are clear in the project contract and cannot be discussed until online.
Certification success rate: normal certification success rate≥99%. Under peak pressure.≥95%。
Certification response time: P95-square authentication response time≤Three seconds.
Terminal compatibility: Normal display and authentication of Portal pages on mainstream iOS, Android devices (at least three models each).
Compliance log: Each certification has a full log, which is in accordance with local requirements and supports queries by cell phone number and time period.
The above criteria are the base threshold, not the ceiling. A conditional project can add more specific indicators to the contract, such as a downtime SLA and Portal page loading time limits."It's good enough to work."The vague judgment.
The acceptance is not just a matter for the technical team itself, but it is recommended that business side representatives (the front desk manager and the business representative) be invited to participate in the acceptance test."It's not working."The perception is more direct than the technical indicators, and they often find problems that are easily missed by technological tests. Solve them before the system goes online, much less than it does when it gets online and then fixes them, and it doesn’t affect sites already in operation.