Method and device for automatically testing number of connectable users of user front-end equipment
By generating virtual users and using multi-threading technology for automated testing, the problems of low efficiency, complex operation and unrepeatable results of CPE device user count test in the prior art are solved, and efficient and accurate automated testing is achieved.
Patent Information
- Application Number
- CN202411478016.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-22
- Publication Date
- 2025-02-18
AI Technical Summary
In the prior art, a test method for the number of users that can be connected by the user pre-equipment (CPE) requires a large number of terminal devices, and the operation is complex and the results cannot be repeated.
By generating multiple virtual users and configuring a unique MAC address for each virtual user, using multi-threading technology to send and listen to messages, automatically counting and analyzing message content, automatic testing of CPE devices is realized.
It improves testing efficiency and accuracy, reduces human error, ensures the consistency and repeatability of test results, and is suitable for different models of CPE tests.
Smart Images

Figure CN119484368A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of user front-end equipment automated testing, and more specifically, to an automated testing method and device for the number of users connectable to a user front-end equipment. Background Art
[0002] CPE (Customer Premise Equipment) products can receive wireless signals from wireless routers, wireless APs, wireless base stations, etc.; at the same time, they can convert 4G / 5G signals into WiFi signals and provide them to hardware devices for networking, and can support multiple devices to access the Internet at the same time. Therefore, CPE can be widely used in wireless network access in rural areas, towns, hospitals, units, factories, communities, etc., which can save the cost of laying wired networks and solve the problem of last-mile network connection.
[0003] In the prior art, there are two methods for testing the number of users that can be connected to a CPE product:
[0004] Method 1: Manually use multiple (30 to 100 or more) computers or mobile phones to connect to the CPE one by one through WLAN, and then check how many terminals are successfully connected on the CPE. However, this method requires a large number of terminal devices, takes a long time to test, has high testing costs, and is inefficient.
[0005] Method 2: Use a packet sending tool to manually send virtual packets with different MAC addresses to the CPE, and then check on the CPE how many terminals have been successfully connected. However, in this method, the packet sending tool needs to be manually configured before each test, which is complicated and difficult to ensure the consistency and repeatability of the test results. Summary of the invention
[0006] One of the purposes of the present invention is to provide an automated testing method for the number of users that can be connected to a user front-end device, so as to solve the existing problems that a large number of terminal devices are required, the operation is complicated, and the results are not repeatable in the user number testing of CPE equipment; the second purpose of the present invention is to provide an automated testing device for the number of users that can be connected to a user front-end device.
[0007] In order to solve the above technical problems, the technical solution of the present invention is as follows:
[0008] A first aspect of the present invention provides an automated testing method for the number of users that can be connected to a user premise equipment, comprising:
[0009] Generate multiple virtual users and configure a unique MAC address for each virtual user;
[0010] Constructing a first message according to the MAC address of each virtual user, and sending all the first messages to the network in a multi-threaded manner, wherein the first message includes the requested IP address;
[0011] Monitoring and collecting a second message sent from the user front-end device, where the second message is sent by the user front-end device after the user front-end device receives the first message, and the second message includes the requested IP address;
[0012] Extracting the requested IP addresses in all the second messages and counting the number of the extracted requested IP addresses;
[0013] The test result is obtained based on the number of IP addresses of the request extracted and a preset number threshold.
[0014] In the above technical means, the number of generated virtual users is dynamically adjusted according to the test requirements, and the data independence and synchronization between threads are ensured through a reasonable thread scheduling and synchronization mechanism, so as to realize concurrent operation of virtual users and simulate the real scenario of multiple users connecting to CPE at the same time, improve the test efficiency, automatically generate and send messages, and automatically analyze the content of the messages, thereby reducing the complexity of manual operations.
[0015] Furthermore, the number of the generated multiple virtual users is not less than the preset number threshold.
[0016] Furthermore, configuring a unique MAC address for each virtual user includes:
[0017] A unique MAC address is generated for each virtual user in a loop. Each MAC address is generated by adding an offset to the base MAC address and formatted into a standard MAC address format.
[0018] Further, constructing the first message according to the MAC address of each virtual user includes:
[0019] Create a DhcpDiscoverThread thread based on the MAC address of each virtual user;
[0020] Generate a random transaction ID in the DhcpDiscoverThread thread;
[0021] A first message is constructed according to the MAC address of the virtual user and a random transaction ID, wherein the first message includes an Ethernet layer, an IP layer, a UDP layer, a BOOTP layer and a DHCP layer, and the IP layer includes the requested IP address.
[0022] Further, the monitoring and collecting of the second message sent from the user front-end device includes:
[0023] Create DhcpDiscoverThread thread;
[0024] Monitor the network interface through the sniff function and capture the messages on the network interface;
[0025] An offer_handler function is defined in the DhcpDiscoverThread thread. When the message captured on the network interface is the second message, the offer_handler function is used to add the second message to the offers list.
[0026] Further, after the offer_handler function adds the second message to the offers list and the DhcpDiscoverThread thread ends, all the second messages in the offers list are put into the dhcp_offer_queue queue.
[0027] Further, extracting the requested IP addresses in all the second messages includes:
[0028] Extracting second messages from the dhcp_offer_queue queue in sequence;
[0029] For each extracted second message, the transaction ID, the requested IP address and the MAC address are extracted.
[0030] Further, counting the number of the IP addresses of the requests extracted includes:
[0031] Create a DhcpRequestThread thread, in which a third message is constructed according to the requested IP address extracted from each of the second messages, and then the third message is sent through a network interface;
[0032] Whenever a third message is received, the counter is increased until all the third messages are sent, and the counter count value is the number of the requested IP addresses.
[0033] Further, according to the number of the extracted IP addresses of the request and the preset number threshold, a test result is obtained, including:
[0034] When the number of the extracted IP addresses of the request is equal to the preset number threshold, the test passes;
[0035] When the number of the extracted IP addresses of the request is not equal to the preset number threshold, the test fails.
[0036] A second aspect of the present invention provides an automated testing device for the number of users that can be connected to a user front-end device, comprising:
[0037] A generation configuration module, wherein the generation configuration module is used to generate multiple virtual users and configure a unique MAC address for each virtual user;
[0038] A sending module, the sending module is used to construct a first message according to the MAC address of each virtual user, and send all the first messages to the network in a multi-threaded manner, wherein the first message includes the requested IP address;
[0039] A monitoring module, the monitoring module is used to monitor and collect a second message sent from the user front-end device, the second message is sent by the user front-end device after the user front-end device receives the first message, and the second message includes the IP address of the request;
[0040] A statistical module, the statistical module is used to extract the requested IP addresses in all the second messages and count the number of the extracted requested IP addresses;
[0041] An output module is used to obtain a test result based on the number of the extracted requested IP addresses and a preset number threshold.
[0042] Compared with the prior art, the technical solution of the present invention has the following beneficial effects:
[0043] 1. Efficient automated testing: The present invention uses multi-threading technology to achieve efficient automated testing of CPE equipment in a multi-user environment, greatly improving the test speed and accuracy.
[0044] 2. Real scenario simulation: By simulating a multi-user connection scenario in an actual network environment, the present invention can easily test and evaluate the performance of the number of users that can be connected to the CPE.
[0045] 3. Reduce human errors: The automated testing process reduces the errors caused by manual operations and ensures the consistency and repeatability of test results.
[0046] 4. Flexibility and scalability: The device can adjust thread parameters and user scale as needed, and is suitable for testing CPEs of different models. BRIEF DESCRIPTION OF THE DRAWINGS
[0047] Figure 1 A flowchart of an automated testing method for the number of users that can be connected to a user front-end device provided by an embodiment of the present invention;
[0048] Figure 2 A module schematic diagram of an automated testing device for the number of users that can be connected to a user front-end device provided in an embodiment of the present invention. DETAILED DESCRIPTION
[0049] The drawings are for illustrative purposes only and should not be construed as limiting the present patent;
[0050] In order to better illustrate the present embodiment, some parts in the drawings may be omitted, enlarged or reduced, and do not represent the size of the actual product;
[0051] It is understandable to those skilled in the art that some well-known structures and their descriptions may be omitted in the drawings.
[0052] The technical solution of the present invention is further described below in conjunction with the accompanying drawings and embodiments.
[0053] Example
[0054] The embodiment of the present invention provides an automated testing method for the number of users that can be connected to a user front-end device, such as Figure 1 As shown, including:
[0055] Generate multiple virtual users and configure a unique MAC address for each virtual user;
[0056] Constructing a first message according to the MAC address of each virtual user, and sending all the first messages to the network in a multi-threaded manner, wherein the first message includes the requested IP address;
[0057] Monitoring and collecting a second message sent from the user front-end device, where the second message is sent by the user front-end device after the user front-end device receives the first message, and the second message includes the requested IP address;
[0058] Extracting the requested IP addresses in all the second messages and counting the number of the extracted requested IP addresses;
[0059] The test result is obtained according to the number of the requested IP addresses extracted and the preset number threshold. The embodiment of the present invention provides a modularly designed automated testing framework, which is based on the scapy program in the python software language development environment. The scapy program automatically virtualizes a large number of users to send standard format DHCP protocol messages to the CPE, monitors and processes the CPE response messages, and finally connects to the CPE as a virtual terminal and successfully obtains the IP address assigned by the CPE. The scheme has a high degree of automation capability, can flexibly configure test parameters in different network environments, and generate detailed test reports. Through the above technical scheme, the embodiment of the present invention can effectively simulate the multi-user scenario in the actual use of CPE, and accurately evaluate the performance of the maximum number of accessible users of the CPE device.
[0060] In a further embodiment, the number of the generated multiple virtual users is not less than the preset number threshold.
[0061] In a specific embodiment, the number of virtual users is set to USERS_NUM, for example, 30 users, and this value is the maximum number of connectable users supported by the CPE.
[0062] In a further embodiment, configuring a unique MAC address for each virtual user includes:
[0063] A unique MAC address is generated for each virtual user in a loop. Each MAC address is generated by adding an offset to the base MAC address and formatted into a standard MAC address format.
[0064] In a specific embodiment, USERS_NUM unique MAC addresses are generated by looping, each MAC address is generated by adding an offset to a base MAC address (e.g., "5c:6a:ec:12:81:62") and formatted into a standard MAC address format (XX:XX:XX:XX:XX). The code example is as follows:
[0065]
[0066] In a further embodiment, constructing the first message according to the MAC address of each virtual user includes:
[0067] Create a DhcpDiscoverThread thread based on the MAC address of each virtual user;
[0068] Generate a random transaction ID in the DhcpDiscoverThread thread;
[0069] A first message is constructed according to the MAC address of the virtual user and a random transaction ID, wherein the first message includes an Ethernet layer, an IP layer, a UDP layer, a BOOTP layer and a DHCP layer, and the IP layer includes the requested IP address.
[0070] In a specific embodiment, a DhcpDiscoverThread thread is created for each virtual MAC address. In this thread, a random transaction ID (xid) is generated and a DHCP Discover message is constructed. The message includes an Ethernet layer, an IP layer, a UDP layer, a BOOTP layer, and a DHCP layer, in which the generated MAC address and the random xid are used, and then a unique host name hostmane is generated for each MAC address based on the random xid, and then the DHCPDiscover message is sent through the specified network interface. The code example is as follows:
[0071]
[0072]
[0073] In a further embodiment, monitoring and collecting the second message sent from the user front-end device includes:
[0074] Create DhcpDiscoverThread thread;
[0075] Monitor the network interface through the sniff function and capture the messages on the network interface;
[0076] An offer_handler function is defined in the DhcpDiscoverThread thread. When the message captured on the network interface is the second message, the offer_handler function is used to add the second message to the offers list.
[0077] In a specific embodiment, in the DhcpDiscoverThread thread, an offer_handler function is defined to process the received message. When the received message is a DHCP Offer (i.e., the DHCP message type is 2), it is added to the offers list. The network interface is monitored by the sniff function to capture messages on UDP port 67 or 68, and the timeout is set to 20 seconds. The code example is as follows:
[0078]
[0079] In a further embodiment, after the offer_handler function adds the second message to the offers list and the DhcpDiscoverThread thread ends, all the second messages in the offers list are put into the dhcp_offer_queue queue.
[0080] In a specific embodiment, after the DhcpDiscoverThread thread ends, the collected offers list is put into the dhcp_offer_queue queue for subsequent processing. The code example is as follows:
[0081] dhcp_offer_queue.put(offers)
[0082] In a further embodiment, extracting the requested IP addresses in all the second messages includes:
[0083] Extracting second messages from the dhcp_offer_queue queue in sequence;
[0084] For each extracted second message, the transaction ID, the requested IP address and the MAC address are extracted.
[0085] In a further embodiment, counting the number of the extracted IP addresses of the request includes:
[0086] Create a DhcpRequestThread thread, in which a third message is constructed according to the requested IP address extracted from each of the second messages, and then the third message is sent through a network interface;
[0087] Whenever a third message is received, the counter is increased until all the third messages are sent, and the counter count value is the number of the requested IP addresses.
[0088] In a specific embodiment, a start_dhcp_request_threads function is defined to take out a DHCP Offer message from the dhcp_offer_queue. For each DHCP Offer, the transaction ID (xid), DHCP server IP address, assigned client IP address and client MAC address are extracted, and a DhcpRequestThread thread is created. In this thread, a DHCP Request message is constructed, including options such as the requested IP address, server ID and client ID, and then the DHCP Request message is sent through the network interface. The code example is as follows:
[0089]
[0090]
[0091] At the same time, in the main thread, a print_count variable is maintained to count the number of users who successfully obtain IP addresses. In the start_dhcp_request_threads function, every time a DHCP Request message is sent, the requested IP address is printed and the print_count counter is increased. The code example is as follows:
[0092] for entry in mac_ip_list:
[0093] print(entry[0])#Print the IP address being requested
[0094] print_count+=1#Increment the counter
[0095] In a further embodiment, a test result is obtained according to the number of the extracted IP addresses of the request and a preset number threshold, including:
[0096] When the number of the extracted IP addresses of the request is equal to the preset number threshold, the test passes;
[0097] When the number of the extracted IP addresses of the request is not equal to the preset number threshold, the test fails.
[0098] In a specific embodiment, in the main thread, when the program is executed to the end, if print_count is equal to USERS_NUM, it means that all virtual users have successfully connected to the CPE and obtained IP addresses, and the test passes. Otherwise, the test fails and the number of users actually connected is output. The code example is as follows:
[0099]
[0100] This embodiment uses a multi-threaded approach to simulate a large number of users sending DHCP requests to the CPE at the same time, monitors and automatically processes the returned messages, counts the users who are successfully connected, and automatically tests and evaluates whether the CPE meets the maximum number of connectable users.
[0101] The embodiment of the present invention further provides an automated testing device for the number of users that can be connected to a user front-end device, which is used in the automated testing method for the number of users that can be connected to a user front-end device described in the above embodiment, comprising:
[0102] A generation configuration module, wherein the generation configuration module is used to generate multiple virtual users and configure a unique MAC address for each virtual user;
[0103] A sending module, the sending module is used to construct a first message according to the MAC address of each virtual user, and send all the first messages to the network in a multi-threaded manner, wherein the first message includes the requested IP address;
[0104] A monitoring module, the monitoring module is used to monitor and collect a second message sent from the user front-end device, the second message is sent by the user front-end device after the user front-end device receives the first message, and the second message includes the IP address of the request;
[0105] A statistical module, the statistical module is used to extract the requested IP addresses in all the second messages and count the number of the extracted requested IP addresses;
[0106] An output module is used to obtain a test result based on the number of the extracted requested IP addresses and a preset number threshold.
[0107] The same or similar reference numerals correspond to the same or similar components;
[0108] The terms used in the drawings to describe positional relationships are only used for illustrative purposes and should not be construed as limiting this patent;
[0109] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the present invention, and are not intended to limit the embodiments of the present invention. For those skilled in the art, other different forms of changes or modifications can be made based on the above description. It is not necessary and impossible to list all the embodiments here. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the protection scope of the claims of the present invention.
Claims
1. An automated testing method for the number of users that can be connected to a user front-end device, characterized in that: include: Generate multiple virtual users and configure a unique MAC address for each virtual user; Constructing a first message according to the MAC address of each virtual user, and sending all the first messages to the network in a multi-threaded manner, wherein the first message includes the requested IP address; Monitoring and collecting a second message sent from the user front-end device, where the second message is sent by the user front-end device after the user front-end device receives the first message, and the second message includes the requested IP address; Extracting the requested IP addresses in all the second messages and counting the number of the extracted requested IP addresses; The test result is obtained based on the number of IP addresses of the request extracted and a preset number threshold.
2. The automated testing method for the number of users that can be connected to a user front-end device according to claim 1, characterized in that: The number of the generated multiple virtual users is not less than the preset number threshold.
3. The automated testing method for the number of users that can be connected to a user front-end device according to claim 1, characterized in that: The step of configuring a unique MAC address for each virtual user includes: A unique MAC address is generated for each virtual user in a loop. Each MAC address is generated by adding an offset to the base MAC address and formatted into a standard MAC address format.
4. The automated testing method for the number of users that can be connected to a user front-end device according to claim 1, characterized in that: The step of constructing a first message according to the MAC address of each virtual user includes: Create a DhcpDiscoverThread thread based on the MAC address of each virtual user; Generate a random transaction ID in the DhcpDiscoverThread thread; A first message is constructed according to the MAC address of the virtual user and a random transaction ID, wherein the first message includes an Ethernet layer, an IP layer, a UDP layer, a BOOTP layer and a DHCP layer, and the IP layer includes the requested IP address.
5. The automated testing method for the number of users that can be connected to a user front-end device according to claim 1, characterized in that: The monitoring and collecting of the second message sent from the user front-end device includes: Create DhcpDiscoverThread thread; Monitor the network interface through the sniff function and capture the messages on the network interface; An offer_handler function is defined in the DhcpDiscoverThread thread. When the message captured on the network interface is the second message, the offer_handler function is used to add the second message to the offers list.
6. The automated testing method for the number of users that can be connected to a user front-end device according to claim 5, characterized in that: After the offer_handler function adds the second message to the offers list and the DhcpDiscoverThread thread ends, all the second messages in the offers list are put into the dhcp_offer_queue queue.
7. The automated testing method for the number of users that can be connected to a user front-end device according to claim 6, characterized in that: Extracting the IP addresses of the requests in all the second messages includes: Extracting second messages from the dhcp_offer_queue queue in sequence; For each extracted second message, the transaction ID, the requested IP address and the MAC address are extracted.
8. The automated testing method for the number of users that can be connected to a user front-end device according to claim 7, characterized in that: Count the number of IP addresses of the request extracted, including: Create a DhcpRequestThread thread, in which a third message is constructed according to the requested IP address extracted from each of the second messages, and then the third message is sent through a network interface; Whenever a third message is received, the counter is increased until all the third messages are sent, and the counter count value is the number of the requested IP addresses.
9. The automated testing method for the number of users that can be connected to a user front-end device according to any one of claims 1 to 8, characterized in that: According to the number of the extracted IP addresses of the request and the preset number threshold, a test result is obtained, including: When the number of the extracted IP addresses of the request is equal to the preset number threshold, the test passes; When the number of the extracted IP addresses of the request is not equal to the preset number threshold, the test fails.
10. An automated testing device for the number of users that can be connected to a user front-end device, characterized in that: include: A generation configuration module, wherein the generation configuration module is used to generate multiple virtual users and configure a unique MAC address for each virtual user; A sending module, the sending module is used to construct a first message according to the MAC address of each virtual user, and send all the first messages to the network in a multi-threaded manner, wherein the first message includes the requested IP address; A monitoring module, the monitoring module is used to monitor and collect a second message sent from the user front-end device, the second message is sent by the user front-end device after the user front-end device receives the first message, and the second message includes the IP address of the request; A statistical module, the statistical module is used to extract the requested IP addresses in all the second messages and count the number of the extracted requested IP addresses; An output module is used to obtain a test result based on the number of the extracted requested IP addresses and a preset number threshold.
Citation Information
Cited By
FTTR equipment stability test method and device, medium and equipment
CN120151701A