WiFi certification system switched from trial to official online, with one key node in the middle——Receiving and inspection is not a signature process, but an assurance that the system is able to withstand in a real operating environment. From actual project experience, several problems arise very frequently during the receiving and inspection phase.
The scale pressure test is not done.
Most projects are receiving and inspection tests"Small Test Terminal"It's done in the environment.——The office has been able to connect several mobile phones, verify them, speed them properly and receive them. But the real environment gap between this test environment and the online environment is very large: hundreds or even thousands of devices may be connected to WiFi in a real environment and there will be tens of times more pressure on the testing environment to issue certifications.
The acceptance and inspection phase will be at least one scale-based simultaneous distribution test. The testing process does not need to be complicated: several PCs run automated scripts, simulate 200 to 500 terminals simultaneously initiating authentication requests, observing the response time of the authentication server, overtime rates, and certification success rates. If the P95 response time for 500 certification requests is more than 5 seconds or the overtime rate exceeds 2%, it means that there may be a user perception of significant certification delays at the peak when going online.
Special attention to resource consumption of Radius servers during stress testing——Whether CPU usage will soar to nearly 100%, whether there is a continuing trend of RAM (possibly RAM leaks) and if the UDP buffer zone is lost. These problems are not apparent without pressure.
Is the end compatibility certification sufficiently covered?
What's the terminal for the acceptance test? If only the test team's own cell phone.——Probably the latest flag ship in the same brand.——This test covers a wide gap between the real environment. There are all kinds of terminals in the real environment, old, broken, system versions that have not been updated for years, various Iot devices.
A representative list of end compatibility tests is required for receiving and inspection, including at least three more versions of iOS, the three most recent versions of Android (the representative machine covering different brands), Windows and Macos notebooks with Iot devices of one or at least two different brands. Each terminal has to complete a full authentication process——From association WiFi to Portal popup to input authentication code to authentication success to normal access——Every step has to be verified.
Of particular note is the compatibility of Portal pages. The system browser behaviour varies widely across terminals, with some automatically closing authentication pages, others cleaving the content of the previous page and others being very rigorous in verifying HTTPS certificates. These differences are not detected in single terminal tests, but they become completely different problems for different users when they go online.
Have you ever measured the ability of an anomaly to fit in?
The acceptance test is usually taken."Normal Process"——The normal number of the cell phone, the normal receipt code, and the normal authentication were successful. But in a real operating environment, anomalies are the biggest source of work for the transport dimensions.
Every anomaly, the system should behave with certainty.——Whether to reject authentication and give a clear indication, or to automatically resume the session, or to allow users to restart the certification process. If certain anomalies are detected at the time of acceptance that the system is not working in an uncertain or inconsistent manner, then it needs to be repaired before going online. When you get on line, the cost of repairing them is much higher.
Validation of back-up and recovery mechanisms
Configuration data for the WiFi certification system——Authentication policy, user data, Portal page template, Radius parameters——It's a backup. But many of the projects were confirmed at the time of acceptance."Backup function"I didn't actually do it."Restores to an empty device from backup file"The physical verification.
It is recommended that a full back-up recovery exercise be performed during the receiving and inspection phase: deploy an identical authentication system device in the test environment, restore the backup file in full, then verify the complete recovery of configuration data, user data, authentication strategy on a case-by-case basis. If this exercise is not done during the receipt and inspection stage, when a real malfunction requires restoration, there may be gaps or inconsistencies in the form of the backup document.——It was too late.
Switching Project Validation
If this is a project to replace an old WiFi certification system, there is also a convenient task at the time of receipt: the switch-over program for new and old systems is validated. The switch option is not"It's done at 2:00 in the morning.", but it needs a clear rollback. If the switch is followed by problems,——Like a lot of user certification failed.——Can you cut back the old system in half an hour? Is the data and configuration of the old system complete and not affected by the new system?
Switching validation at the receiving and inspection stage, recommended first for a trial switch during non-peak periods——Switches past two hours, observes the indicators and then cuts back. After the trial switch passes, you do a formal cut. Two operations are separate, with much more risk control.
The WiFi certification system is essentially a centralized check-up of risks. It takes one more day to process the receipt and inspection phase, which is worth more than a week to handle problems after being online. If you have to add these items to the receiving and inspection list clearly, item by item, without jumping or going through the field, the project will be truly delivered.