Test scenes and validation methods that must be covered when WiFi network billing system is online

The acceptance test of WiFi's network billing system is a particularly easy exercise to be carried out. Most projects are receiving and inspection by checking the functional list: authentication works, billing works, payment can be paid, statements can be seen, and the check is passed. But, based on my experience with several project acceptances, the real risk points are there."The functional list doesn't exist, but it's going to be there in the actual operation."In the scene.

The biggest blind area for receiving and inspection tests is only normal process undetected abnormality. How to detect an anomaly? First, you have to list all possible anomalies: nas sudden reboot, RADIOS server, database connection break-off, network export interruption, payment platform callback delay, user balance shortfall, multiple authentication launch——These scenarios are almost always in operation, but most acceptance programmes do not cover them at all.

Each type of anomaly is tested to cover at least three dimensions: whether the system correctly detects anomalies, whether it maintains acceptable downgrading during an abnormal period, and whether the system automatically returns to normal operation after an abnormal recovery. For example, in a scenario where NAS restarts, WiFi network billing systems should be in a state of waiting for restoration when they are detected below NAS, and when NAS re-enters, RADIUS connections will automatically be re-established instead of requiring manual intervention to restart services.

WiFi network billing system costing accuracy is not enough to be manually verified.——Manual tests can cover only a few billing records of several users, and may be produced thousands of them simultaneously in actual operation. The acceptance test should include automated pressure tests for the billing: a script is used to simulate a certain number of users and send authentications and traffic uses, then to see whether error rates are acceptable compared with the data generated by the system record count and simulation scripts.

The difficulty of this test is to simulate real traffic.——Instead of sending a few pings, it simulates the traffic features of the real scenes by browsing web pages, looking at videos, downloading files. Simplely, iperf or curl is used to generate traffic, and complicatedly, it records the flow patterns of the true user and then returns them.

Many acceptance tests are stuck in"Function Module Level Validation"——The authentication module takes a check, the billing module measures, the payment module measures, each. But WiFi network billing system is a complete business process chain: user registration→Account Charg→Connect WiFi→Portal authentication→Online→Charge deductions→Reconciliations→Data report. Any break-up affects the entire chain.

End-to-end acceptance should be simulated to run through the full business process from"A new user first saw Portal page"Here we go."At the end of the month, financial reconciliations were obtained"At the end, each of the steps in the middle is to verify that the data are being transmitted in a complete manner and that the status is being correctly updated.

Most of the WiFi network billing tests are only short-term.——Run a functional check is over. But the system’s long-term stability is another important dimension. It is recommended that at least one round of stabilization tests of 72 hours be performed before the formal acceptance, to simulate normal operational load running on a continuous basis, to observe the system’s CPU, memory, disk usage trends and whether there are slow search accumulations, log expansions, memory leakages etc.

The 72-hour running is not a complete substitute for the actual operation of one month, but at least it will identify the stability problems that will be exposed in the short term. The most fear of the WiFi network billing system is formalism.——The purpose of receiving and inspection is not to complete the process deviations, but to detect as many hazards as possible before the system becomes fully operational. The anomaly scene is not covered adequately, the billing accuracy is not automated, there are breakpoints in end-to-end business processes and long-term stability is not verified——These four problems are the most common blind areas in the receiving and inspection phase. The acceptance test is solid, so that the pressure on the carrier's feeder can be reduced by at least half. The acceptance test is not the end point, but it is sufficient to give you a relatively clean start-up line. New questions arise from the time you get online, but those which could have been discovered during the receipt and inspection stage should not be the first to be done after the line."Sure."The point is that the upper line will be a time-consuming link. The first side of the receipt process does not seek to get problems, but rather to confirm that the system actually runs in the hands of its own team. Extending the participation in the acceptance test to some extent, making it more specific and keeping the receiving and inspection document more complete, all three things are done, and the closing period after being connected will be much shorter.