Function test method, device and equipment for dynamic host configuration protocol, and storage medium

Abstract

The invention discloses a function test method, device and equipment of a dynamic host configuration protocol and a storage medium, relates to the technical field of network testing, and discloses the function test method of the dynamic host configuration protocol, which comprises the following steps: obtaining a first port and a second port, the first port is used for verifying the dynamic host configuration protocol, and the second port is used for verifying the dynamic host configuration protocol; the second port is used as a mirror image port for analyzing the uplink message of the first port; according to the first port and the second port, respectively executing an IP allocation test, a lease term management test, an abnormal scene test and an address resolution protocol broadcast automatic test to respectively obtain an IP allocation test result, a lease term management test result, an abnormal scene test result and an address resolution protocol test result; and obtaining a target test result according to the IP allocation test result, the lease term management test result, the abnormal scene test result and the address resolution protocol test result. And comprehensive automatic testing of the dynamic host configuration protocol client in a plurality of functional links is realized.

Description

Technical Field

[0001] This application relates to the field of network testing technology, and in particular to functional testing methods, apparatus, devices and storage media for Dynamic Host Configuration Protocol (DHCP). Background Technology

[0002] Dynamic Host Configuration Protocol (DHCP) client is an important function in computer networks used to automatically obtain network parameters. It can automatically allocate network configuration information, including IP address, subnet mask, default gateway, and domain name server, when a terminal device connects to the network. The normal operation of this function relies on a complete message exchange process between the client and server according to the DHCP standard. It also involves verifying the correctness of the message format, the validity of the parameter configuration, and compatibility with other devices in the network. With the increasing variety of network devices and manufacturers, client function verification must not only conform to protocol specifications but also ensure that address allocation, lease management, and anomaly handling can be performed correctly in various network environments. Therefore, the coverage, accuracy, and consistency of functional testing directly affect the reliability and interoperability of the device in actual deployment.

[0003] Traditional methods primarily rely on manually setting up test environments and manually configuring real Dynamic Host Configuration Protocol (DHCP) servers, switches, and packet capture tools to verify the client's performance at different stages. Alternatively, simple scripting tools can be used to simulate some packet interactions to check if the client can respond to basic allocation requests. Some network testing instruments also offer DHCP simulation functions, but these often only cover limited interaction points and some functionalities. The drawback of these methods is their low level of automation, making it difficult to achieve comprehensive verification of the client's entire lifecycle.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this application is to provide a functional testing method, apparatus, device, and storage medium for Dynamic Host Configuration Protocol (DHCP), aiming to solve the technical problems of low automation and incomplete coverage in the full lifecycle functional verification process of DHCP clients.

[0006] To achieve the above objectives, this application proposes a functional testing method for the Dynamic Host Configuration Protocol (DHCP), the method comprising:

[0007] Obtain the first port and the second port, wherein the first port is used for dynamic host configuration protocol verification, and the second port is used as a mirror port to parse the uplink packets of the first port;

[0008] Based on the first port and the second port, perform IP allocation test, lease management test, abnormal scenario test and address resolution protocol broadcast automation test respectively, and obtain IP allocation test results, lease management test results, abnormal scenario test results and address resolution protocol test results respectively;

[0009] The target test result is obtained based on the IP allocation test result, the lease management test result, the abnormal scenario test result, and the address resolution protocol test result.

[0010] In one embodiment, the step of performing an IP allocation test based on the first port and the second port to obtain the IP allocation test result includes:

[0011] According to the first port, send a Dynamic Host Configuration Protocol Discovery message and a Dynamic Host Configuration Protocol Request message;

[0012] The protocol parsing result is obtained by analyzing the format and content of the Dynamic Host Configuration Protocol Discovery message and the Dynamic Host Configuration Protocol Request message sent via the second port to determine if they are correct.

[0013] When the protocol parsing result is correct, an acknowledgment message is sent to the device under test via the first port, so that the device under test allocates and returns an Internet Protocol address according to the acknowledgment message;

[0014] The network connectivity is verified based on the Internet Protocol address, and the IP allocation test results are obtained.

[0015] In one embodiment, the step of performing a lease management test based on the first port and the second port to obtain the lease management test result includes:

[0016] Obtain a first time node and a second time node, wherein the first time node is earlier than the second time node;

[0017] At the first time point, the first renewal status is obtained by detecting whether a Dynamic Host Configuration Protocol (DHCP) request message is received on the second port.

[0018] The connectivity verification result is determined based on the renewal status;

[0019] At the second time point, based on the renewal status of the device under test detected by the second port, a second renewal status is obtained, and based on the connectivity verification result and the second renewal status, the lease management test result is obtained.

[0020] In one embodiment, the step of determining the connectivity verification result based on the renewal status includes:

[0021] When the renewal condition is renewal, a Dynamic Host Configuration Protocol (DHCP) confirmation message is sent according to the first port, and the network connectivity of the Internet Protocol address is verified to obtain the connectivity verification result.

[0022] When the renewal situation is that no renewal request is detected or the renewal fails, a Dynamic Host Configuration Protocol (DHCP) rejection message is sent according to the first port, and it is detected whether the device under test resends a DHCP discovery message to obtain a new address, so as to obtain the connection status verification result.

[0023] The connectivity verification result is determined based on the connectivity verification result and the connection status verification result.

[0024] In one embodiment, the step of performing an abnormal scenario test based on the first port and the second port to obtain the abnormal scenario test result includes:

[0025] Based on the second port, the test results are obtained by detecting whether the device under test resends the Dynamic Host Configuration Protocol (DHCP) discovery message, thus obtaining the message loss test results.

[0026] Perform a message collision test based on the first port and the second port to obtain the message collision test results;

[0027] The abnormal scenario test results are obtained based on the message loss test results and the message conflict test results.

[0028] In one embodiment, the step of performing a packet collision test based on the first port and the second port to obtain the packet collision test result includes:

[0029] Generate multiple provisioning messages conforming to the Dynamic Host Configuration Protocol standard based on the first port, and record the Internet Protocol address of the target provisioning message;

[0030] The second port is used to detect whether the Internet Protocol address of the Dynamic Host Configuration Protocol Request message sent by the device under test is consistent with the Internet Protocol address of the message provided by the target.

[0031] When the Internet Protocol address of the Dynamic Host Configuration Protocol (DHCP) request message matches the Internet Protocol address of the target provided message, a DHCP confirmation message is sent according to the first port to verify network connectivity and obtain the message conflict test result.

[0032] In one embodiment, the step of performing an automated address resolution protocol broadcast test based on the first port and the second port to obtain the address resolution protocol test result includes:

[0033] The second port is used to detect whether it sends an Address Resolution Protocol broadcast message and to receive a probe response;

[0034] When the Address Resolution Protocol broadcast message is detected and a probe response is received, the first port is used to detect whether the device under test sends a Dynamic Host Configuration Protocol address rejection message to re-apply for an Internet Protocol address, and the first connectivity result is obtained.

[0035] When the Address Resolution Protocol broadcast message is detected but no probe response is received, the device under test is checked according to the first port to see if it is still using the assigned Internet Protocol address, and the network connectivity is verified to obtain a second connectivity result.

[0036] The address resolution protocol test result is obtained based on the first connectivity result or the second connectivity result.

[0037] In addition, to achieve the above objectives, this application also proposes a functional testing device for the Dynamic Host Configuration Protocol (DHCP). The DHCP functional testing device includes: a port acquisition module for acquiring a first port and a second port, wherein the first port is used for DHCP verification, and the second port is used as a mirror port for parsing the uplink packets of the first port.

[0038] The network testing module is used to perform IP allocation testing, lease management testing, abnormal scenario testing, and address resolution protocol broadcast automation testing according to the first port and the second port, respectively, and obtain IP allocation test results, lease management test results, abnormal scenario test results, and address resolution protocol test results.

[0039] The result determination module is used to obtain the target test result based on the IP allocation test result, the lease management test result, the abnormal scenario test result, and the address resolution protocol test result.

[0040] In addition, to achieve the above objectives, this application also proposes a functional testing device for the Dynamic Host Configuration Protocol (DMP), the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the functional testing method for the DMP as described above.

[0041] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the functional testing method of the Dynamic Host Configuration Protocol as described above.

[0042] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the functional testing method for the Dynamic Host Configuration Protocol as described above.

[0043] One or more technical solutions proposed in this application have at least the following technical effects:

[0044] By employing techniques that acquire both the first and second ports, utilize the first port to perform Dynamic Host Configuration Protocol (DHCP) verification, and use the second port to mirror and parse the uplink packets from the first port, the interactive behavior and packet content of DHCP can be synchronously acquired within the same test architecture. This allows for independent testing of multiple functional aspects, such as Internet Protocol address allocation, lease management, abnormal scenarios, and automated address resolution protocol broadcasting, yielding corresponding test results. The test results from each aspect are then combined to obtain a complete target test result. This solves the problems of existing technologies that rely on manual testing, resulting in a fragmented testing process, the inability to complete full-coverage verification of multiple aspects under a unified link, and the difficulty in simultaneously obtaining packet structure and functional verification results. Consequently, it achieves multi-dimensional automated verification of DHCP clients throughout their entire lifecycle, improving test coverage, accuracy, and efficiency. Attached Figure Description

[0045] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0046] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0047] Figure 1 This is a flowchart illustrating an embodiment of the functional testing method for the Dynamic Host Configuration Protocol (DHCP) of this application.

[0048] Figure 2 This is a flowchart illustrating the second embodiment of the functional testing method for the Dynamic Host Configuration Protocol (DHCP) of this application.

[0049] Figure 3 A simplified flowchart illustrating the functional testing method for the Dynamic Host Configuration Protocol provided in Embodiment 2 of this application;

[0050] Figure 4 This is a schematic diagram of the module structure of the functional testing device for the Dynamic Host Configuration Protocol (DRAM) according to an embodiment of this application.

[0051] Figure 5 This is a schematic diagram of the hardware operating environment involved in the functional testing method of the Dynamic Host Configuration Protocol in this application embodiment.

[0052] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0053] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0054] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0055] The main solution of this application embodiment is as follows: Obtain a first port and a second port, wherein the first port is used for Dynamic Host Configuration Protocol (DHCP) verification, and the second port serves as a mirror port for parsing uplink packets from the first port; perform IP allocation testing, lease management testing, abnormal scenario testing, and Address Resolution Protocol (ARP) broadcast automation testing based on the first port and the second port respectively, and obtain IP allocation test results, lease management test results, abnormal scenario test results, and ARP test results respectively; obtain the target test result based on the IP allocation test results, lease management test results, abnormal scenario test results, and ARP test results.

[0056] In this embodiment, for ease of description, the following description will focus on a functional test device for recognizing the Dynamic Host Configuration Protocol.

[0057] Because existing technologies for Dynamic Host Configuration Protocol (DHCP) clients suffer from low automation and incomplete coverage during the full lifecycle functional verification process, this application provides a solution. By employing techniques such as acquiring a first port and a second port, using the first port to perform DHCP verification, and using the second port to mirror and parse the uplink packets of the first port, the interactive behavior and message content of DHCP can be synchronously acquired within the same test architecture. This allows for independent testing of multiple functional aspects, such as Internet Protocol address allocation, lease management, abnormal scenarios, and automated address resolution protocol broadcasting, and obtaining corresponding test results. The test results of each aspect are then combined to obtain a complete target test result. This solves the problems of existing technologies that rely on manual testing, resulting in a fragmented testing process, inability to complete full-coverage verification of multiple aspects under a unified link, and difficulty in simultaneously obtaining message structure and functional verification results. Thus, it achieves multi-dimensional automated verification of DHCP clients throughout their entire lifecycle, improving test coverage, accuracy, and efficiency.

[0058] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone; or an electronic device, a functional testing device for Dynamic Host Configuration Protocol (DHCP), or a testing instrument capable of performing the above functions. The following description uses a testing instrument as an example to illustrate this embodiment and the subsequent embodiments.

[0059] Based on this, embodiments of this application provide a functional testing method for the Dynamic Host Configuration Protocol (DHCP), referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the functional testing method for the Dynamic Host Configuration Protocol of this application.

[0060] In this embodiment, the functional testing method for the Dynamic Host Configuration Protocol includes steps S10 to S30:

[0061] Step S10: Obtain the first port and the second port, wherein the first port is used for dynamic host configuration protocol verification, and the second port is used as a mirror port to parse the uplink packets of the first port.

[0062] It should be noted that the first port is the physical interface on the switch used for Dynamic Host Configuration Protocol (DHCP) authentication, specifically Ethernet 0 port in this embodiment. Its main function is to carry all interactive messages of the DHCP protocol. It is the core channel for DHCP communication between the device under test (such as a switch) and the test instrument. All message sending and receiving related to DHCP authentication is completed through this port, directly participating in various test procedures for the DHCP client function.

[0063] Additionally, the second port is a physical interface on the switch configured for mirroring, specifically Ethernet1 port in this embodiment. As a mirror port, it does not directly participate in DHCP protocol interactions, but is responsible for copying all traffic (including uplink and downlink packets) from the first port and sending the copied traffic to the connected test instrument. This allows the test instrument to capture and parse the packets from the first port through this port, thereby enabling real-time monitoring and analysis of the DHCP interaction process.

[0064] Dynamic Host Configuration Protocol (DHCP) verification refers to the inspection of whether the behavior of a DHCP client (such as a switch) conforms to the protocol standard during the process of obtaining network configuration parameters (such as IP address, subnet mask, gateway, etc.). It covers whether the message format sent by the client is correct, whether the interaction process with the server is complete, and whether lease management is standardized. The purpose is to ensure that the client can communicate normally with the DHCP server and correctly obtain and use network configuration.

[0065] Furthermore, a mirror port is a port configured to copy traffic from other ports (i.e., the source port, such as the first port). Its function is to copy all data packets (including uplink and downlink) from the source port for the connected test instruments to capture and analyze, without affecting the normal data transmission of the source port. In DHCP client function testing, the mirror port is a crucial channel for the test instruments to obtain and parse packets from the first port.

[0066] Furthermore, uplink messages refer to messages sent from the device under test (such as a switch) to the test instrument (simulating a DHCP server). In DHCP interactions, these messages specifically include Discover messages and Request messages. These messages carry key information such as the client's request information and device status. After being captured by the test instrument through the mirror port, they can be used to analyze whether the client's behavior conforms to the expected protocol specifications.

[0067] Understandably, the first step is to obtain two physical ports from the switch: port one and port two. Port one is designated for Dynamic Host Configuration Protocol (DHCP) authentication (e.g., Ethernet port 0), responsible for carrying all message interactions related to DHCP authentication and serving as the core communication channel for DHCP client functionality testing. Port two is configured as a mirroring port (e.g., Ethernet port 1), which replicates all traffic from port one, especially uplink messages, so that testing instruments can capture and parse these messages, providing data support for subsequent message analysis. After obtaining the ports, it's necessary to verify the connection status of both ports to ensure that port one can perform DHCP authentication correctly and that port two's mirroring function can effectively replicate the traffic from port one, laying a reliable foundation for subsequent testing.

[0068] Step S20: Perform IP allocation test, lease management test, abnormal scenario test and address resolution protocol broadcast automation test according to the first port and the second port respectively, and obtain IP allocation test results, lease management test results, abnormal scenario test results and address resolution protocol test results respectively;

[0069] It should be noted that IP address allocation testing verifies whether a DHCP client (such as a switch) can correctly obtain network configuration parameters, such as an IP address, from a test instrument (simulating a DHCP server). The process includes the client sending a Discover message, receiving an Offer message, sending a Request message, receiving an Acknowledgment message, and verifying network connectivity via the Internet Control Message Protocol (ICMP) after obtaining the IP address. The purpose is to verify whether the client's behavior during the IP address acquisition process conforms to the protocol standards.

[0070] Additionally, lease management testing verifies whether the DHCP client's behavior during the IP address lease period conforms to the specifications. It primarily focuses on whether the client automatically sends request messages to renew the lease at 50% (T1 node) and 87.5% (T2 node) of the lease period, and whether it re-applies for an IP address when lease renewal fails (receiving a denial message NAK) or expires. This ensures that the client's IP address lease management complies with protocol requirements, avoiding address conflicts or network outages.

[0071] Additionally, abnormal scenario testing simulates potential network anomalies (such as lost ACK messages, conflicting offer messages, etc.) to test the DHCP client's response mechanisms. This includes verifying whether the client re-initiates the address request process when an ACK is lost, and whether it selects the IP address from the first offer when multiple offers conflict. The purpose is to evaluate the client's fault tolerance and recovery capabilities.

[0072] Additionally, the Address Resolution Protocol (ARP) broadcast automation test verifies whether a DHCP client, after obtaining an IP address, sends an ARP broadcast message to probe whether that IP address is already in use by other devices on the same network segment. If an ARP response is received (i.e., the address is already in use), the client should send a Decline message and request a new address; if no response is received, the address should be used normally to avoid IP address conflicts.

[0073] Furthermore, the IP allocation test results are the conclusions of the IP allocation test, including whether the message format and content sent by the client are correct, whether the interaction process with the server is complete, whether the IP address is successfully obtained, and whether the network connectivity is normal, etc., which are used to determine whether the client's behavior in the IP allocation process meets expectations.

[0074] Additionally, the lease management test results are the conclusions of the lease management test, including whether the client automatically sends lease renewal requests at nodes T1 and T2, whether the behavior is correct when the lease renewal is successful / failed, and whether the IP address is stopped after the lease expires, reflecting the client's compliance with lease management.

[0075] Additionally, the abnormal scenario test results are the conclusions of the abnormal scenario test, including whether the client resends the Discover message when the ACK is lost, and whether it selects the IP address of the first offer when there is an offer conflict, which are used to evaluate the client's ability to cope with abnormal situations.

[0076] Additionally, the Address Resolution Protocol (ARP) test results are the conclusions of the ARP broadcast automated test, including whether the client sends ARP broadcast messages, whether it sends Decline messages when it receives an ARP response, and whether it uses the IP address normally when it does not receive a response, etc., to verify whether the client's mechanism for avoiding address conflicts is effective.

[0077] Understandably, the testing instrument performs four tests based on both the first and second ports. During the IP allocation test, the instrument selects the IP allocation scenario and configures injection. The device under test sends a Discover message through the first port, which is captured on the second port and parsed by the packet capture analysis engine. The instrument then sends an Offer message through the first port, and the device under test sends a Request message. After parsing on the second port, the instrument sends an ACK message. Finally, network connectivity is verified via ping (ICMP), yielding the IP allocation test result. During the lease management test, after completing the IP allocation test, the instrument's timed trigger controller monitors node T1 and checks the second port to see if the device under test sends a Request message. If it does, the instrument sends an ACK and verifies connectivity (update successful). If it does not send a Request message or sends a NAK, the instrument checks if the device resends the Discover message and verifies connectivity (update failed), yielding the lease management test result. During abnormal scenario testing, in the ACK loss scenario, the test instrument does not send an ACK, but detects whether the device resends Discover via the second port; in the Offer conflict scenario, the test instrument sends multiple Offers, and detects whether the device selects the IP address of the first Offer via the second port to obtain the abnormal scenario test results. During automated ARP broadcast testing, after the test device obtains an IP address, it sends an ARP broadcast. The test instrument simulates a response or no response, and detects whether the device sends Decline or a normally used address via the second port to obtain the address resolution protocol test results.

[0078] In one feasible implementation, step S20 may include steps A21 to A24:

[0079] Step A21: Send a Dynamic Host Configuration Protocol (DHCP) discovery message and a DHCP request message according to the first port;

[0080] It should be noted that the Dynamic Host Configuration Protocol Discover message (DHCP Discover message) is a broadcast message sent by a DHCP client (such as the switch under test) when it needs to obtain network configuration. This message contains information such as the client's hardware address (e.g., MAC address) and is used to indicate to all possible DHCP servers on the network that it needs to obtain network parameters such as an IP address. It is the starting message of the DHCP interaction process.

[0081] Additionally, the Dynamic Host Configuration Protocol (DHCP) Request message: The DHCP Request message is a request message sent by the DHCP client to the server after receiving an Offer message from the server. This message specifies the IP address the client wishes to obtain (usually the IP address from the first Offer message) and confirms acceptance of the network configuration corresponding to that address. It is a crucial message for the client to select a specific network configuration in DHCP interactions.

[0082] Understandably, the device under test (such as a switch) sends two types of DHCP messages sequentially through its first port (Ethernet port 0). First, the device under test sends a Dynamic Host Configuration Protocol (DHCP) Discover message, broadcasting to the test instrument (simulating a DHCP server) its need to obtain an IP address and other network configurations. After receiving a Offer message from the test instrument, the device under test again sends a DHCP Request message through the first port, explicitly requesting the IP address and related configurations from the Offer message. Sending these two messages is the core step for the DHCP client to obtain network configurations, laying the foundation for subsequent IP allocation and verification.

[0083] Step A22: Based on the second port, parse whether the format and content of the Dynamic Host Configuration Protocol Discovery message and the Dynamic Host Configuration Protocol Request message are correct, and obtain the protocol parsing result;

[0084] It should be noted that the protocol parsing result is the conclusion obtained by the test instrument after parsing the Dynamic Host Configuration Protocol (DHCP) discovery and request messages through the second port. This result includes whether the message format conforms to the RFC standard (e.g., whether the field length and field order are correct) and whether the content is complete (e.g., whether it contains necessary information such as the client hardware address). It is used to determine whether the DHCP messages sent by the device under test conform to the protocol specifications and is a crucial basis for proceeding with subsequent testing steps.

[0085] Understandably, the testing instrument captures Dynamic Host Configuration Protocol (DHCP) discovery and request messages sent from the first port via the second port (Ethernet port 1, mirror port), and uses its own packet capture and analysis engine to parse these two types of messages. During parsing, it focuses on checking whether the message format conforms to RFC standards (e.g., the order of fields and length are compliant) and whether the content is complete and accurate (e.g., whether it contains the client's MAC address and correctly identifies the message type). Through this parsing, it ultimately obtains protocol parsing results indicating whether the message format and content are correct, providing a basis for judging whether the DHCP message sending behavior of the device under test meets expectations.

[0086] Step A23: When the protocol parsing result is correct, send an acknowledgment message to the device under test according to the first port, so that the device under test allocates and returns an Internet Protocol address according to the acknowledgment message;

[0087] It should be noted that the acknowledgment message (i.e., the DHCPACK message) is a response message sent by the test instrument (simulating a DHCP server) to the device under test after confirming that the Dynamic Host Configuration Protocol (DHCP) discovery and request messages are formatted and contain the correct information. This message contains network configuration parameters requested by the device under test, such as the IP address, subnet mask, gateway address, and DNS server address. It is used to formally confirm the client's permission to use the IP address and is a crucial message for completing IP allocation in the DHCP interaction.

[0088] Furthermore, the device under test refers to the network device that needs to undergo DHCP client function testing, specifically a switch in this embodiment. As a DHCP client, this device sends discovery and request messages according to the DHCP protocol specifications, and allocates and uses IP addresses after receiving confirmation messages. Whether its behavior conforms to the protocol standard is the verification object of this test method.

[0089] Additionally, Internet Protocol (IP) addresses are logical addresses used to identify devices within a network. They consist of 32-bit (IPv4) or 128-bit (IPv6) binary numbers and are used to enable communication between devices on the network. In DHCP testing, the IP address obtained by the device under test from the testing instrument is fundamental for its network access and data transmission. The correct allocation and use of this address is the core verification content of IP allocation testing.

[0090] Understandably, when the protocol parsing results indicate that the Dynamic Host Configuration Protocol (DHCP) Discover and Request messages sent by the device under test are correct in format and content, the testing instrument will send an acknowledgment message to the device under test through the first port. Upon receiving this acknowledgment message, the device under test will allocate the corresponding Internet Protocol (IP) address based on the network configuration parameters contained in the message and will then send this address back to the testing instrument (usually indirectly reflected through subsequent message interactions, such as using the address for communication). This step formally confirms the client's address request from the DHCP server and is a crucial step in completing IP address allocation.

[0091] Step A24: Verify network connectivity based on the Internet Protocol address to obtain the IP allocation test result.

[0092] It should be noted that network connectivity refers to the ability of a device under test (such as a switch) to communicate normally with other devices in the network (such as test instruments or gateways) after obtaining an Internet Protocol address. Verifying network connectivity is typically achieved by sending Internet Control Message Protocol (ICMP) echo request messages (i.e., the ping command). If a corresponding echo reply message is received, it indicates that network connectivity is normal.

[0093] Understandably, the testing instrument uses the Internet Protocol address returned by the device under test (DUT) to verify the connectivity between the DUT and the network by sending ICMP echo request messages (i.e., performing a ping operation). If a corresponding echo reply message is received, it indicates that the DUT has not only successfully been assigned an IP address but can also use that address for network communication normally; if no reply message is received, it indicates an address allocation anomaly or a network connectivity problem. Combining the above verification results with the protocol parsing results and confirmation message interactions from previous steps, the final IP allocation test result is obtained. This result can be directly used to determine whether the IP allocation function of the DUT is normal.

[0094] In this embodiment, the test instrument selects the IP allocation test scenario (configuration injection). During the sending phase, the switch sends a DHCP discover message to the test instrument. The packet capture and analysis engine parses the format and content of the switch's discover message to check if they are correct (packet parsing). During the providing phase, the simulation engine generates a DHCP offer message that conforms to the RFC standard. During the selection phase, the switch receives the offer message and broadcasts a request message. The packet capture and analysis engine parses the format and content of the switch's request message to check if they are correct (packet parsing). During the confirmation phase, the simulation engine generates an ACK message, the switch allocates an IP address, and the test instrument initiates the network connectivity step, pinging the allocated IP address to verify whether the address is connected (network connectivity).

[0095] In one feasible implementation, step S20 may include steps B21 to B24:

[0096] Step B21: Obtain the first time node and the second time node, wherein the first time node is earlier than the second time node;

[0097] It should be noted that the first time point is the first critical time point within the DHCP client's IP address lease period, which in this embodiment is the 50% lease term (i.e., the T1 node). This node is the initial trigger point where the client needs to send a request message to the server to renew the lease period. It is used to verify whether the client can initiate the lease renewal process according to the protocol specifications and is an important time marker for evaluating the client's lease management behavior.

[0098] Additionally, the second time node is the second critical point in the DHCP client's IP address lease period, which in this embodiment is the 87.5% mark (i.e., the T2 node). This node is later than the first time node. If the client's renewal request at the first time node is not confirmed, it will attempt to renew again at this node to further verify whether the client's lease renewal mechanism is sound and ensure the reliability of lease management.

[0099] Understandably, the testing equipment needs to capture two key time points within the DHCP client's IP address lease period: the first time point (50% of the lease period) and the second time point (87.5% of the lease period), with the first time point preceding the second. These two time points are pre-set based on the IP address lease length. For example, if the lease period is 8 hours, the first time point is 4 hours and the second time point is 7 hours. This setting is based on the DHCP protocol's specifications for lease renewal time, providing a time benchmark for subsequent detection of the client's renewal behavior.

[0100] Step B22: At the first time node, the first renewal status is obtained by detecting whether a Dynamic Host Configuration Protocol (DHCP) request message is received on the second port.

[0101] It should be noted that the first renewal scenario refers to the result of the client's renewal behavior detected at the first time point (50% of the lease term), including whether a Dynamic Host Configuration Protocol (DHCP) request message was sent, and whether the message format and content were correct, etc., which is used to determine whether the client has started the normal lease renewal process at the first critical node.

[0102] Understandably, at the first time point (50% of the lease term), the testing instrument captures traffic on the first port through the second port (mirrored port), focusing on detecting whether it receives Dynamic Host Configuration Protocol (DHCP) request messages from the device under test. During the detection process, it also verifies whether the message format conforms to RFC standards and whether the content contains key information such as the currently used IP address. Through these tests, it ultimately obtains the initial renewal status, indicating whether the client successfully initiated a renewal request at the first time point, providing a preliminary basis for evaluating the client's lease management behavior.

[0103] Step B23: Determine the connectivity verification result based on the renewal status;

[0104] It should be noted that connectivity verification results are conclusions drawn from verifying whether the device under test can communicate normally with the network using the Internet Control Message Protocol (ICMP). In lease management testing, the ping command is typically used to verify whether the client can still use the original IP address to communicate after a successful lease renewal, or whether it cannot use the address after a failed renewal, in order to examine the impact of lease status on network connectivity.

[0105] Understandably, based on the first renewal status, the testing instrument performs network connectivity verification to obtain the results. If the first renewal status is "renewed" (the client sent a valid request message and the server confirmed the renewal), the system verifies whether the client can still communicate normally by pinging its IP address. If the first renewal status is "not renewed" (the client did not send a request message or the server refused to renew), the system similarly verifies whether the client has stopped using the IP address (i.e., the ping fails). Through these verifications, the connectivity verification results are determined to check whether the correlation between the lease renewal status and network connectivity matches expectations.

[0106] In one feasible implementation, step B23 may include steps B231 to B233:

[0107] Step B231: When the renewal status is renewal, send a Dynamic Host Configuration Protocol (DHCP) confirmation message according to the first port, and verify the network connectivity of the Internet Protocol address to obtain the connectivity verification result.

[0108] It should be noted that renewal refers to the device under test successfully sending a Dynamic Host Configuration Protocol (DHCP) request message conforming to the protocol specifications through the first port at the first critical point (e.g., 50% of the lease term), indicating that it has actively initiated the lease renewal process. This situation demonstrates that the client's lease management mechanism is working normally at the initial critical point, reflecting that the client maintains the IP address lease term as required by the protocol.

[0109] Additionally, the Dynamic Host Configuration Protocol (DHCP) acknowledgment message (DHCPACK message) is a response message sent by the test instrument (simulating a DHCP server) after receiving a valid renewal request message from the client. This message contains information confirming the successful renewal, allowing the client to continue using its current Internet Protocol (IP) address. It formally acknowledges the client's renewal request and ensures the completion of the lease extension process.

[0110] Furthermore, network connectivity verification refers to the process of verifying whether the device under test can communicate normally with other devices (such as test instruments) on the network after successful contract renewal by using the echo request (i.e., ping operation) of the Internet Control Message Protocol (ICMP). If an echo response is received, it indicates that the address is available and the network is working properly, which is a key step in verifying the validity of the contract renewal.

[0111] Additionally, the connectivity verification result is a conclusion drawn after network connectivity verification, including two scenarios: normal connectivity (ping operation successful, address usable) and abnormal connectivity (ping operation failed, address unusable). When the lease is renewed, this result confirms whether the client can continue to use the Internet Protocol address for network communication normally after obtaining a lease extension.

[0112] Understandably, when the lease renewal status is "renewal" (i.e., the device under test successfully sent a Dynamic Host Configuration Protocol (DHCP) request message at the first possible time), the testing instrument will send a DHCP confirmation message to the device under test through the first port (e.g., Ethernet port 0) to confirm the successful lease renewal. Subsequently, the testing instrument will perform a ping operation on the Internet Protocol address to verify the connectivity of the device under test using that address to the network. If the ping operation is successful, it indicates that the address can be used normally, and the connectivity verification result is "connectivity normal"; if the ping operation fails, the result is "connectivity abnormal". This step, through the sending of the confirmation message and connectivity verification, ensures that the client can still participate in network communication normally after successful lease renewal, and is a crucial step in verifying the effectiveness of lease management.

[0113] Step B232: When the renewal situation is that no renewal request is detected or the renewal fails, a Dynamic Host Configuration Protocol (DHCP) rejection message is sent according to the first port, and it is detected whether the device under test resends a DHCP discovery message to obtain a new address, so as to obtain the connection status verification result.

[0114] It should be noted that "no renewal request detected" or "renewal failed" means that at the first critical point in time, the test instrument failed to detect the Dynamic Host Configuration Protocol (DHCP) request message sent by the device under test through the second port (no renewal request detected), or the detected request message format / content did not conform to the protocol specifications, resulting in the renewal not being recognized (renewal failed). This indicates that the client failed to properly initiate or complete the renewal process at the critical lease term point, and its response mechanism needs further examination.

[0115] Additionally, the Dynamic Host Configuration Protocol (DHCP) NAK message is a response message sent by the test instrument to the device under test via port 1 when no valid renewal request is detected or the renewal fails. This message explicitly informs the client that the renewal request has not been accepted, the current Internet Protocol address lease term cannot be extended, and the client is required to reapply for a new address. It is a key signal that triggers the client's address re-application process.

[0116] Furthermore, the Dynamic Host Configuration Protocol Discover message (DHCP Discover message) is a broadcast message sent by the device under test to the network after receiving a rejection message or after the lease expires. It is used to request a new Internet Protocol address from the test instrument. This message contains information such as the client's hardware address and serves as the starting point for the client to initiate the new address acquisition process, demonstrating the client's ability to recover from renewal failures.

[0117] Additionally, the connectivity verification result determines whether the device under test resends a discovery message and obtains a new address after receiving a rejection message. This includes successful resend (successful resend of discovery message and eventual acquisition of new address) and failed resend (no discovery message sent or inability to obtain new address). This result is used to evaluate the client's fault tolerance and address management reliability after renewal failure.

[0118] Understandably, when the renewal status is "no renewal request detected" or "renewal failed," the testing instrument sends a Dynamic Host Configuration Protocol (DHCP) rejection message to the device under test via the first port, informing it that the renewal was unsuccessful. Subsequently, the testing instrument monitors whether the device under test resends a DHCP discovery message via the second port (mirror port) to initiate a new address request process. If the device under test successfully sends the discovery message and ultimately obtains a new Internet Protocol (IP) address, the connection verification result is "re-application successful"; if no discovery message is sent or a new address is never obtained, the result is "re-application failed." This step simulates a renewal failure scenario to test the client's anomaly handling capabilities, ensuring that it can promptly restore network connectivity when lease management issues arise.

[0119] Step B233: Determine the connectivity verification result based on the connectivity verification result and the connection status verification result.

[0120] Understandably, the testing equipment requires both connectivity verification results and connection status verification results to determine the final connectivity verification result. If the connectivity verification result is normal and the connection status verification result is a successful re-application, then the final connectivity verification result is overall normal connectivity; if any step encounters an anomaly (such as connectivity anomaly or re-application failure), the final result is overall connectivity anomaly. This step, by integrating the verification results from both scenarios, comprehensively evaluates the client's ability to guarantee network connectivity throughout the entire lease management process, providing crucial evidence for the generation of subsequent lease management test results.

[0121] Step B24: At the second time node, based on the renewal status of the device under test detected by the second port, a second renewal status is obtained, and based on the connectivity verification result and the second renewal status, the lease management test result is obtained.

[0122] It should be noted that the second renewal scenario refers to the client's renewal behavior detected at the second time point (87.5% of the lease term). Similar to the first renewal scenario, it includes whether a Dynamic Host Configuration Protocol (DHCP) request message is sent and whether the message is valid. This scenario is used to verify whether the client's retry mechanism is functioning correctly when the initial renewal fails, and it further verifies the lease management behavior.

[0123] Furthermore, the lease management test results are the final conclusion obtained by comprehensively considering the first renewal case, the second renewal case, and the connectivity verification results. It covers whether the client's renewal behavior at the two key lease nodes complies with the protocol specifications, whether network connectivity is normal after lease renewal or expiration, and whether the address reuse mechanism is effective, comprehensively reflecting the reliability of the client's lease management function.

[0124] Understandably, at the second time point (87.5% of the lease term), the testing instrument re-detects the renewal behavior of the device under test through the second port to obtain the second renewal status, i.e., to determine whether the client sends a Dynamic Host Configuration Protocol (DHCP) request message and whether the message is valid. Subsequently, the first renewal status, the second renewal status, and the connectivity verification results are analyzed. If the renewal behavior of both nodes is normal and the connectivity verification passes, it indicates that the lease management function is normal; if there is a renewal failure but the client can re-apply for an address or stop using the original address, and the connectivity meets expectations, it is also considered normal; otherwise, it is judged as abnormal. Through the above comprehensive analysis, the lease management test results are finally obtained, which comprehensively reflect the client's full-cycle management capability of IP address leases.

[0125] In this embodiment, the test instrument selects the lease management test scenario (configuration injection). Following the IP allocation test as described above, the test instrument periodically triggers the controller. At lease node T1, the packet capture analysis engine analyzes whether a request packet is automatically sent to update the lease (packet parsing). The response distinguishes between two types: no update and lease update. (Lease update) The simulation engine constructs an ACK response indicating successful lease update, and pinging the allocated IP address normally detects the lease update (network connectivity). (No lease update) The simulation engine constructs a NAK response indicating the need to reacquire the address. The switch resends DISCOVER, and if no response is received before the lease expires, pinging fails and the allocated IP address is normal, thus detecting the lease expiration and cessation of using this IP address (network connectivity).

[0126] In one feasible implementation, step S20 may include steps C21 to C24:

[0127] Step C21: Detect whether the second port sends an Address Resolution Protocol (ARP) broadcast message and receive a probe response;

[0128] It should be noted that a probe response refers to the response message returned by other terminals within the same network segment to the device under test after receiving an Address Resolution Protocol (IP) broadcast message from the device under test. If they are currently using the Internet Protocol (IP) address contained in that message, the response indicates that the IP address is already in use and will trigger the address re-request process on the device under test.

[0129] Understandably, the testing instrument captures traffic from the first port through the second port (mirrored port), focusing on detecting whether the device under test sends Address Resolution Protocol (ARP) broadcast messages and whether it receives probe responses from other terminals to these broadcast messages. Specifically, the testing instrument monitors the traffic from the first port replicated by the second port, identifies ARP broadcast messages sent by the device under test (containing the Internet Protocol address it intends to use), and further detects whether other terminals return probe responses to these messages. This step is fundamental to verifying the address conflict detection mechanism of the device under test and provides a basis for subsequent judgments on whether its behavior conforms to the protocol specifications.

[0130] Step C22: When the Address Resolution Protocol broadcast message is detected and a probe response is received, the device under test is checked according to the first port to see if it sends a Dynamic Host Configuration Protocol address rejection message to re-apply for an Internet Protocol address, and the first connectivity result is obtained.

[0131] It should be noted that re-applying for an Internet Protocol (IP) address refers to the process by which the device under test, after sending a Dynamic Host Configuration Protocol (DHCP) address rejection message, re-initiates the DHCP process (such as sending a DHCP discovery message) to request a new IP address from the test instrument. This process ensures that the device under test can obtain a usable address and maintain network connectivity in the event of an address conflict.

[0132] Furthermore, the first connectivity result represents the verification result of the test device's behavior after detecting an Address Resolution Protocol (ARP) broadcast message and receiving a probe response. It includes successful re-application (the test device sends a Dynamic Host Configuration Protocol (DHCP) address rejection message and successfully obtains a new address) and failed re-application (no address rejection message is sent or a new address cannot be obtained), used to determine the client's ability to handle address conflicts.

[0133] Understandably, when the testing instrument detects that the device under test (DUT) has sent an Address Resolution Protocol (ARP) broadcast message through the second port and receives a probe response from another terminal (indicating an address conflict), the testing instrument will further detect through the first port whether the DUT has sent a Dynamic Host Configuration Protocol (DHCP) address rejection message. If this rejection message is detected, and the DUT subsequently resends a DHCP discovery message to request a new Internet Protocol (IP) address and ultimately obtains the new address, the first connectivity result is a successful re-application; if no rejection message is detected, or although a message is sent but a new address is not successfully obtained, the first connectivity result is a failed re-application. This step verifies whether the DUT's response mechanism in the event of an address conflict complies with the protocol specifications.

[0134] Step C23: When the Address Resolution Protocol broadcast message is detected but no probe response is received, the device under test is checked according to the first port to see if it is still using the assigned Internet Protocol address, and the network connectivity is verified to obtain a second connectivity result.

[0135] It should be noted that the assigned Internet Protocol (IP) address refers to the IP address that the test instrument assigns to the device under test (DUT) via a Dynamic Host Configuration Protocol (DHCP) acknowledgment (ACK) message. This address is the network identifier that the DUT intends to use, and its validity needs to be confirmed through the detection results of Address Resolution Protocol (ARP) broadcast messages.

[0136] Additionally, maintaining the use of an assigned Internet Protocol (IP) address refers to the behavior of the device under test continuing to use the address for network communication after sending an Address Resolution Protocol (IP) broadcast message and not receiving a probe response (indicating that the address is not in use). This is a normal operation for the client after confirming that the address is available and conforms to the address allocation protocol specifications.

[0137] Furthermore, the second connectivity result is a verification result of the test device's behavior when an Address Resolution Protocol (IP) broadcast message is detected but no probe response is received. It includes normal connectivity (the device under test continues to use the assigned Internet Protocol address and network connectivity verification passes) and abnormal connectivity (the address is not used or connectivity verification fails), used to determine the client's network communication capability when the address is available.

[0138] Understandably, when the testing instrument detects that the device under test (DUT) has sent an Address Resolution Protocol (IP) broadcast message through the second port, but receives no response from other terminals (indicating that the IUT address is not occupied), the testing instrument will check through the first port whether the DUT continues to use the assigned IUT address and verify its network connectivity via Internet Control Message Protocol (ICMP, i.e., ping operation). If the DUT continues to use the address and the ping operation succeeds, the second connectivity result is considered normal; if the DUT does not use the address or the ping operation fails, the second connectivity result is considered abnormal. This step verifies the DUT's normal usage and communication capabilities when the address is confirmed to be available.

[0139] Step C24: Obtain the address resolution protocol test result based on the first connectivity result or the second connectivity result.

[0140] Understandably, the testing instrument comprehensively judges and obtains the address resolution protocol test result based on either the first or second connectivity result. If the first connectivity result indicates successful re-application (correct handling of address conflicts), or the second connectivity result indicates normal connectivity (normal use when addresses are available), then the address resolution protocol test result is compliant with the specification; if the first connectivity result indicates failed re-application, or the second connectivity result indicates connectivity anomaly, then the test result is non-compliant with the specification. This result comprehensively verifies the address resolution protocol broadcast automated detection function of the device under test, ensuring that it can effectively avoid address conflicts and maintain network connectivity.

[0141] In this embodiment, the testing instrument selects the ARP broadcast automated test scenario (configuration injection). Similar to the IP allocation test above, the switch receives the ACK packet sent by the testing instrument during the confirmation phase and sends an ARP broadcast packet to probe whether other terminals on the same network segment are using the IP address assigned by the server (response received). The simulation engine generates an ARP reply packet, and the packet capture analysis engine checks whether the switch sends a DHCP declient packet (no response received). The switch uses the IP address, and the testing instrument initiates the network connectivity step, pinging the assigned IP address to verify connectivity (network connectivity).

[0142] Step S30: Obtain the target test result based on the IP allocation test result, the lease management test result, the abnormal scenario test result, and the address resolution protocol test result.

[0143] It should be noted that the target test results are the final conclusion formed after comprehensively considering the IP allocation test results, lease management test results, abnormal scenario test results, and address resolution protocol test results. It comprehensively reflects the functional performance of the DHCP client in IP allocation, lease management, anomaly handling, and address conflict avoidance, including whether each behavior conforms to RFC standards, whether the interaction process is complete, and whether protocol compatibility is good. It is a holistic evaluation of the DHCP client's functionality and can be used to generate test reports, providing a basis for device function verification.

[0144] Understandably, the testing equipment comprehensively analyzes the results of IP allocation tests, lease management tests, abnormal scenario tests, and address resolution protocol tests. The IP allocation test results determine whether the client can correctly obtain and use an IP address; the lease management test results assess whether the client's lease management is standardized; the abnormal scenario test results verify the client's fault tolerance and recovery capabilities; and the address resolution protocol test results confirm whether the client can effectively avoid IP address conflicts. By summarizing and judging these results, a comprehensive target test result reflecting whether the DHCP client's functions meet protocol standards and design requirements is ultimately formed. This result covers key behaviors throughout the client's entire lifecycle and can be directly used to generate a test report.

[0145] This embodiment provides a functional testing method for the Dynamic Host Configuration Protocol (DHCP). By constructing an integrated test environment and using the first and second ports to verify the DHCP client function and parse messages respectively, it solves the technical problems in the prior art such as low automation of DHCP client function testing, lack of verification of key behaviors, bottleneck of testing efficiency, and lack of identity credibility. It achieves the beneficial effects of improving testing efficiency, fully covering the verification of RFC standard behaviors, accurately controlling the test sequence, ensuring manufacturer compatibility, and improving test reliability.

[0146] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 The functional testing method for the Dynamic Host Configuration Protocol (DHCP) further includes steps S21 to S23 in step S20:

[0147] Step S21: Based on the second port, detect whether the device under test resends the Dynamic Host Configuration Protocol discovery message to obtain the message loss test result;

[0148] Understandably, message loss test results are derived by detecting the behavior of the device under test under abnormal scenarios simulating message loss (such as loss of ACK messages). These results include information such as whether the device under test resends the Dynamic Host Configuration Protocol (DHCP) discovery message, whether the format and content of the resent message conform to the protocol specifications, and whether the resentment time interval is reasonable. This information is used to evaluate the client's fault tolerance capability and the effectiveness of its retry mechanism in the face of message loss.

[0149] Step S22: Perform a message conflict test based on the first port and the second port to obtain the message conflict test result;

[0150] It should be noted that the message conflict test simulates a scenario where multiple DHCP offer messages conflict in a network to verify the processing capability of the device under test. In this test, the test instrument sends multiple different offer messages to the device under test through the first port and observes whether the device under test selects only the IP address in the first offer message and sends the corresponding request message. This verifies whether the key RFC behavior of the client only accepting the first offer conforms to the specification.

[0151] Furthermore, the message conflict test results are the conclusions of the message conflict test, including whether the device under test sends a request message after receiving multiple offer messages, whether the IP address specified in the request message is the same as the IP address in the first offer message, and whether the format and content of the request message are correct. These are used to determine whether the device under test's selection mechanism in the face of message conflicts conforms to the protocol standard.

[0152] Understandably, the testing instrument performs packet collision testing using both the first and second ports. First, the instrument sends multiple RFC-compliant Dynamic Host Configuration Protocol (DHCP) offer messages (simulating an offer collision scenario) to the device under test (DUT) via the first port, recording the IP address contained in the first offer message. Simultaneously, the instrument captures the request message sent by the DUT via the first port (a mirror port), parses the content of the request message, and determines whether the specified IP address matches the IP address recorded in the first offer message, and whether the message format conforms to the specifications. Based on these test results, a packet collision test result reflecting the correctness of the DUT's behavior in the packet collision scenario is obtained.

[0153] In one feasible implementation, step S22 may include steps S221 to S223:

[0154] Step S221: Generate multiple provision messages conforming to the Dynamic Host Configuration Protocol standard based on the first port, and record the Internet Protocol address of the target provision message;

[0155] It should be noted that the target offer message refers to the first offer message sent to the device under test among multiple offer messages. In message collision testing, according to the RFC standard, the client should only accept the first offer message; therefore, this message is used as the baseline, and its contained Internet Protocol address is a key reference for subsequent verification of the behavior of the device under test.

[0156] Additionally, an Internet Protocol (IP) address is a logical address used to identify devices in a network, consisting of 32 bits (IPv4) or 128 bits (IPv6) of binary data. In a service offer message, this address is the network identifier that the server intends to assign to the client; the Internet Protocol address of the target service offer message is the IP address that the client can use, contained in the first service offer message.

[0157] Understandably, the test instrument generates and sends multiple offer messages conforming to the Dynamic Host Configuration Protocol (DHCP) standard to the device under test (DUT) through the first port (Ethernet port 0) to simulate packet collision scenarios in the network. These offer messages contain different Internet Protocol (IP) addresses and corresponding network configuration information, all conforming to the RFC standard. Simultaneously, the test instrument records the IP address contained in the first offer message sent (i.e., the target offer message), providing a benchmark for subsequent verification of whether the DUT only accepts the first offer message.

[0158] Step S222: Detect whether the Internet Protocol address of the Dynamic Host Configuration Protocol Request message sent by the device under test is consistent with the Internet Protocol address of the target provided message according to the second port.

[0159] Understandably, the testing instrument captures the Dynamic Host Configuration Protocol (DHCP) request messages sent by the device under test (DUT) through the first port via the second port (mirror port), parses the content of these messages, and focuses on extracting the Internet Protocol (IP) address that the DUT requests. This address is then compared with the IP address of the recorded target provision message (the first provision message) to check for consistency. This comparison determines whether the DUT selected the address from the first provision message when faced with multiple provision messages.

[0160] Step S223: When the Internet Protocol address of the Dynamic Host Configuration Protocol (DHCP) request message is consistent with the Internet Protocol address of the target provided message, a DHCP confirmation message is sent according to the first port to verify network connectivity and obtain the message conflict test result.

[0161] Understandably, when the test instrument detects that the Internet Protocol address in the Dynamic Host Configuration Protocol (DHCP) request message sent by the device under test (DUT) matches the Internet Protocol address in the target provided message, it will send a DHCP acknowledgment message to the DUT through port 1 to confirm the address allocation. Subsequently, the test instrument verifies the network connectivity of the DUT using that address via a ping operation. If the connectivity verification is successful and the request message format conforms to the specification, the message conflict test result is compliant with the standard; if the connectivity verification fails or the request message has a formatting issue, the result is non-compliant with the standard. This step comprehensively verifies the protocol compliance and functional effectiveness of the DUT under message conflict scenarios.

[0162] Step S23: Based on the message loss test results and the message conflict test results, obtain the abnormal scenario test results.

[0163] It should be noted that the abnormal scenario test results are the final conclusion obtained by combining the packet loss test results and the packet conflict test results. These results comprehensively reflect whether the behavior of the device under test conforms to the DHCP protocol specifications when facing abnormal network scenarios such as packet loss (e.g., acknowledgment packet loss) and packet conflict (e.g., offer packet conflict), including the effectiveness of fault tolerance, retry mechanisms, and selection mechanisms. This is an important basis for evaluating the DHCP client's ability to cope with abnormal situations.

[0164] Understandably, the testing instrument performs a comprehensive analysis of the packet loss test results and the packet conflict test results. If the packet loss test results show that the device under test can promptly resend the Dynamic Host Configuration Protocol (DHCP) discovery message in a timely manner when a message is lost, and the message conforms to the specification, and the packet conflict test results show that the device under test can correctly select the IP address in the first provided message and send the corresponding request message, then the abnormal scenario test result is compliant with the specification; if either test result is not as expected (such as failure to resend the message, selection of the wrong IP address, etc.), then the abnormal scenario test result is non-compliant with the specification. This result comprehensively evaluates the reliability and protocol compliance of the device under test in abnormal network environments.

[0165] In this embodiment, the test instrument selects the Ack loss test scenario (configuration injection). During the sending phase, the switch sends a DHCP discover message to the test instrument. The packet capture and analysis engine parses the format and content of the switch's discover message to check if they are correct (packet parsing). During the providing phase, the simulation engine generates a DHCP offer message that conforms to the RFC standard. During the selected phase, the switch receives the offer message and broadcasts a request message. The packet capture and analysis engine parses the format and content of the switch's request message to check if they are correct (packet parsing). During the confirmation phase, the test instrument does not send an ACK message. The packet capture and analysis engine is used to analyze whether the switch restarts the address request process and sends a DISCOVER message (packet parsing). The test instrument selects the Offer conflict test scenario (configuration injection). In the sending phase, the switch sends a DHCP discover message to the test instrument. The packet capture and analysis engine parses the format and content of the switch's discover message to check if it is correct (packet parsing). In the providing phase, the simulation engine generates multiple DHCP offer messages conforming to the RFC standard, and records the content and IP address of the first offer message. In the selection phase, the switch receives the offer message and broadcasts a request message. The packet capture and analysis engine parses the content of the switch's request message to check if it matches the content and IP address of the first offer message (packet parsing). In the confirmation phase, the simulation engine generates ACK messages, the switch assigns IP addresses, and the test instrument verifies the network (network connectivity).

[0166] This embodiment provides a functional testing method for the Dynamic Host Configuration Protocol (DHCP). By simulating abnormal scenarios such as packet loss and packet conflict in a test environment, and using a second port to detect the behavior of the device under test, as well as performing packet conflict tests through the first and second ports, this method solves the technical problem of insufficient verification of DHCP client behavior in abnormal network environments in the prior art. It achieves the beneficial effect of comprehensively evaluating whether the fault tolerance, retry mechanism, and selection mechanism of the DHCP client in the face of network anomalies comply with the protocol specifications, thereby ensuring the stability and reliability of network devices.

[0167] For example, to help understand the implementation process of the functional testing method for the Dynamic Host Configuration Protocol obtained in this embodiment combined with the above embodiment one, please refer to... Figure 3 , Figure 3 A simplified flowchart of a functional testing method for the Dynamic Host Configuration Protocol is provided, specifically:

[0168] The diagram contains multiple modules and processes. First, the DHCP message interaction section shows the process of the switch's DHCP client interacting with the server simulation engine through the first port, Ethernet0. This includes the client sending a DHCP discover message in the sending phase, the server replying with a DHCP offer message in the offering phase, the client broadcasting a DHCP request message in the selection phase, the server replying with a DHCP ack message in the confirmation phase, and the ack loss and lease renewal processes. Next is the server simulation engine's message construction module, demonstrating the construction of different messages at different stages, such as offer conflict and ack loss tests. The anomaly injection module constructs different messages for different test scenarios through configuration injection, and the testing instrument outputs results and test reports based on the input scenarios. The packet capture and analysis engine is responsible for capturing and analyzing packet content, format, and timing to ensure they are normal, including the client sending a DHCP discover message in the sending phase, the client broadcasting a DHCP request message in the selection phase, client ARP broadcasts, and the client sending a DHCP decline message. The diagram also mentions mirroring the first network port messages and vendor compatibility testing, such as parsing fields like option60 / 125.

[0169] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the functional testing method of the Dynamic Host Configuration Protocol of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0170] This application also provides a functional testing device for the Dynamic Host Configuration Protocol (DHCP). Please refer to [link / reference needed]. Figure 4 The functional testing device for the Dynamic Host Configuration Protocol includes:

[0171] The port acquisition module 10 is used to acquire a first port and a second port, wherein the first port is used for dynamic host configuration protocol verification, and the second port is used as a mirror port to parse the uplink packets of the first port.

[0172] Network testing module 20 is used to perform IP allocation test, lease management test, abnormal scenario test and address resolution protocol broadcast automation test according to the first port and the second port respectively, and obtain IP allocation test results, lease management test results, abnormal scenario test results and address resolution protocol test results respectively;

[0173] The result determination module 30 is used to obtain the target test result based on the IP allocation test result, the lease management test result, the abnormal scenario test result, and the address resolution protocol test result.

[0174] The functional testing apparatus for Dynamic Host Configuration Protocol (DHCP) provided in this application employs the DHCP functional testing method described in the above embodiments, and can solve the technical problems of low automation and incomplete coverage in the full lifecycle functional verification process of DHCP clients. Compared with the prior art, the beneficial effects of the DHCP functional testing apparatus provided in this application are the same as those of the DHCP functional testing method provided in the above embodiments, and other technical features in the DHCP functional testing apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0175] In one embodiment, the network testing module 20 is further configured to: send a Dynamic Host Configuration Protocol (DHCP) discovery message and a DHCP request message according to the first port; parse the format and content of the DHCP discovery message and the DHCP request message according to the second port to determine if they are correct, thereby obtaining a protocol parsing result; when the protocol parsing result is correct, send an acknowledgment message to the device under test according to the first port, so that the device under test allocates and returns an Internet Protocol (IP) address according to the acknowledgment message; and verify network connectivity according to the IP address to obtain an IP allocation test result.

[0176] In one embodiment, the network testing module 20 is further configured to acquire a first time node and a second time node, wherein the first time node is earlier than the second time node; at the first time node, a first renewal status is obtained by detecting whether a Dynamic Host Configuration Protocol (DHCP) request message is received on the second port; a connectivity verification result is determined based on the renewal status; at the second time node, a second renewal status is obtained by detecting the renewal status of the device under test on the second port, and a lease management test result is obtained based on the connectivity verification result and the second renewal status.

[0177] In one embodiment, the network testing module 20 is further configured to: when the renewal status is renewal, send a Dynamic Host Configuration Protocol (DHCP) confirmation message according to the first port and verify the network connectivity of the Internet Protocol address to obtain a connectivity verification result; when the renewal status is no renewal request detected or renewal fails, send a DHCP rejection message according to the first port and detect whether the device under test resends a DHCP discovery message to obtain a new address to obtain a connection status verification result; and determine a connectivity verification result based on the connectivity verification result and the connection status verification result.

[0178] In one embodiment, the network testing module 20 is further configured to detect whether the device under test resends the Dynamic Host Configuration Protocol (DHCP) discovery message based on the second port, and obtain a message loss test result; perform a message conflict test based on the first port and the second port, and obtain a message conflict test result; and obtain the abnormal scenario test result based on the message loss test result and the message conflict test result.

[0179] In one embodiment, the network testing module 20 is further configured to generate multiple provision messages conforming to the Dynamic Host Configuration Protocol (DHCP) standard according to the first port, and record the Internet Protocol address of the target provision message; detect whether the Internet Protocol address of the DHCP request message sent by the device under test is consistent with the Internet Protocol address of the target provision message according to the second port; when the Internet Protocol address of the DHCP request message is consistent with the Internet Protocol address of the target provision message, send a DHCP confirmation message according to the first port and verify network connectivity to obtain a message conflict test result.

[0180] In one embodiment, the network testing module 20 is further configured to: detect whether the second port sends an Address Resolution Protocol (ARP) broadcast message and receives a probe response; when the ARP broadcast message is detected and a probe response is received, detect whether the device under test sends a Dynamic Host Configuration Protocol (DHCP) address rejection message to re-apply for an Internet Protocol (IP) address, based on the first port, to obtain a first connectivity result; when the ARP broadcast message is detected but no probe response is received, detect whether the device under test continues to use the allocated IP address, based on the first port, and verify network connectivity, to obtain a second connectivity result; and obtain the ARP test result based on the first connectivity result or the second connectivity result.

[0181] This application provides a functional testing device for a Dynamic Host Configuration Protocol (DHCP). The DHCP functional testing device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the DHCP functional testing method described in Embodiment 1 above.

[0182] The following is for reference. Figure 5This document illustrates a structural diagram of a functional testing device suitable for implementing the Dynamic Host Configuration Protocol (DHCP) in the embodiments of this application. The functional testing device for the DHCP in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 5 The functional test device for the Dynamic Host Configuration Protocol shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0183] like Figure 5 As shown, the functional test device for the Dynamic Host Configuration Protocol (DMP) may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in ROM (Read Only Memory) 1002 or a program loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the DMP functional test device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the Dynamic Host Configuration Protocol (DRAM) functional test equipment to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a DRAM functional test equipment with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems may be implemented alternatively.

[0184] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0185] The functional testing device for Dynamic Host Configuration Protocol (DHCP) provided in this application, employing the DHCP functional testing method described in the above embodiments, can solve the technical problems of low automation and incomplete coverage in the full lifecycle functional verification process of DHCP clients. Compared with the prior art, the beneficial effects of the DHCP functional testing device provided in this application are the same as those of the DHCP functional testing method provided in the above embodiments, and other technical features in this DHCP functional testing device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0186] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0187] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0188] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the functional testing method of the Dynamic Host Configuration Protocol in the above embodiments.

[0189] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, RAM (Random Access Memory), ROM (Read Only Memory), Erasable Programmable Read Only Memory (EPROM), optical fiber, CD-ROM (CD-Read Only Memory), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0190] The aforementioned computer-readable storage medium may be included in a functional test device for the Dynamic Host Configuration Protocol (DLL); or it may exist independently and not be assembled into a functional test device for the DLL.

[0191] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a Dynamic Host Configuration Protocol (DHCP) functional testing device, the DHCP functional testing device performs the following: acquires a first port and a second port, wherein the first port is used for DHCP verification, and the second port serves as a mirror port for parsing uplink packets from the first port; performs IP allocation testing, lease management testing, abnormal scenario testing, and Address Resolution Protocol (ARP) broadcast automation testing based on the first port and the second port, respectively, and obtains IP allocation test results, lease management test results, abnormal scenario test results, and ARP test results; and obtains a target test result based on the IP allocation test results, lease management test results, abnormal scenario test results, and ARP test results.

[0192] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including LAN (Local Area Network) or WAN (Wide Area Network)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0193] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0194] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0195] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the functional testing method of the Dynamic Host Configuration Protocol (DHCP) described above. This solves the technical problems of low automation and incomplete coverage in the full lifecycle functional verification process of DHCP clients. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the functional testing method of DHCP provided in the above embodiments, and will not be repeated here.

[0196] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the functional testing method for the Dynamic Host Configuration Protocol as described above.

[0197] The computer program product provided in this application can solve the technical problems of low automation and incomplete coverage in the full lifecycle functional verification process of Dynamic Host Configuration Protocol (DHCP) clients. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the functional testing method for DHCP provided in the above embodiments, and will not be repeated here.

[0198] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A functional testing method for a dynamic host configuration protocol, characterized in that, The method includes: Obtain the first port and the second port, wherein the first port is used for dynamic host configuration protocol verification, and the second port is used as a mirror port to parse the uplink packets of the first port; Based on the first port and the second port, perform IP allocation test, lease management test, abnormal scenario test and address resolution protocol broadcast automation test respectively, and obtain IP allocation test results, lease management test results, abnormal scenario test results and address resolution protocol test results respectively; The target test result is obtained based on the IP allocation test result, the lease management test result, the abnormal scenario test result, and the address resolution protocol test result.

2. The method as described in claim 1, characterized in that, The steps for obtaining the IP allocation test result by performing an IP allocation test based on the first port and the second port include: According to the first port, send a Dynamic Host Configuration Protocol Discovery message and a Dynamic Host Configuration Protocol Request message; The protocol parsing result is obtained by analyzing the format and content of the Dynamic Host Configuration Protocol Discovery message and the Dynamic Host Configuration Protocol Request message sent via the second port to determine if they are correct. When the protocol parsing result is correct, an acknowledgment message is sent to the device under test via the first port, so that the device under test allocates and returns an Internet Protocol address according to the acknowledgment message; The network connectivity is verified based on the Internet Protocol address, and the IP allocation test results are obtained.

3. The method as described in claim 1, characterized in that, The steps for performing lease management tests based on the first port and the second port to obtain lease management test results include: Obtain a first time node and a second time node, wherein the first time node is earlier than the second time node; At the first time point, the first renewal status is obtained by detecting whether a Dynamic Host Configuration Protocol (DHCP) request message is received on the second port. The connectivity verification result is determined based on the renewal status; At the second time point, based on the renewal status of the device under test detected by the second port, a second renewal status is obtained, and based on the connectivity verification result and the second renewal status, the lease management test result is obtained.

4. The method as described in claim 3, characterized in that, The step of determining the connectivity verification result based on the renewal status includes: When the renewal condition is renewal, a Dynamic Host Configuration Protocol (DHCP) confirmation message is sent according to the first port, and the network connectivity of the Internet Protocol address is verified to obtain the connectivity verification result. When the renewal situation is that no renewal request is detected or the renewal fails, a Dynamic Host Configuration Protocol (DHCP) rejection message is sent according to the first port, and it is detected whether the device under test resends a DHCP discovery message to obtain a new address, so as to obtain the connection status verification result. The connectivity verification result is determined based on the connectivity verification result and the connection status verification result.

5. The method as described in claim 1, characterized in that, The steps for performing abnormal scenario tests based on the first port and the second port and obtaining the abnormal scenario test results include: Based on the second port, the test results are obtained by detecting whether the device under test resends the Dynamic Host Configuration Protocol (DHCP) discovery message, thus obtaining the message loss test results. Perform a message collision test based on the first port and the second port to obtain the message collision test results; The abnormal scenario test results are obtained based on the message loss test results and the message conflict test results.

6. The method as described in claim 5, characterized in that, The step of performing a packet collision test based on the first port and the second port to obtain the packet collision test result includes: Generate multiple provisioning messages conforming to the Dynamic Host Configuration Protocol standard based on the first port, and record the Internet Protocol address of the target provisioning message; The second port is used to detect whether the Internet Protocol address of the Dynamic Host Configuration Protocol Request message sent by the device under test is consistent with the Internet Protocol address of the message provided by the target. When the Internet Protocol address of the Dynamic Host Configuration Protocol (DHCP) request message matches the Internet Protocol address of the target provided message, a DHCP confirmation message is sent according to the first port to verify network connectivity and obtain the message conflict test result.

7. The method as described in claim 1, characterized in that, The steps for performing automated address resolution protocol (IP) broadcast tests based on the first port and the second port, and obtaining the IP test results, include: The second port is used to detect whether it sends an Address Resolution Protocol (ARP) broadcast message and to receive a probe response. When the Address Resolution Protocol broadcast message is detected and a probe response is received, the first port is used to detect whether the device under test sends a Dynamic Host Configuration Protocol address rejection message to re-apply for an Internet Protocol address, and the first connectivity result is obtained. When the Address Resolution Protocol broadcast message is detected but no probe response is received, the device under test is checked according to the first port to see if it is still using the assigned Internet Protocol address, and the network connectivity is verified to obtain a second connectivity result. The address resolution protocol test result is obtained based on the first connectivity result or the second connectivity result.

8. A functional testing device for a dynamic host configuration protocol, characterized in that, The device includes: The port acquisition module is used to acquire a first port and a second port, wherein the first port is used for dynamic host configuration protocol verification, and the second port is used as a mirror port to parse the uplink packets of the first port; The network testing module is used to perform IP allocation testing, lease management testing, abnormal scenario testing, and address resolution protocol broadcast automation testing according to the first port and the second port, respectively, and obtain IP allocation test results, lease management test results, abnormal scenario test results, and address resolution protocol test results. The result determination module is used to obtain the target test result based on the IP allocation test result, the lease management test result, the abnormal scenario test result, and the address resolution protocol test result.

9. A functional testing device for a dynamic host configuration protocol, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the functional testing method for the Dynamic Host Configuration Protocol as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the functional testing method for the Dynamic Host Configuration Protocol as described in any one of claims 1 to 7.

Images