Method of generating test cases, testing method, platform, device, medium and product

Abstract

The application provides a method for generating a test case, a test method, a platform, a device, a medium and a product. The method comprises the following steps: in response to receiving a verification request instruction, obtaining a target out port according to the verification request instruction; in a preset mapping relationship between an alternative out port and an alternative network address segment, determining a target network address according to the target out port, the target network address being a network address in the alternative network address segment corresponding to the target out port; taking the target network address as a destination network address of a test case corresponding to the target out port, and generating the test case corresponding to the target out port; and the test case is used for testing a routing function of a network device to which the target out port belongs. Thus, the maintenance cost of the test case can be reduced.

Description

Technical Field

[0001] This application relates to the field of routing function testing technology, and more specifically, to a method for generating test cases, a testing method, a platform, a device, a medium, and a product. Background Technology

[0002] In the research and development and testing process of network equipment and core chips, routing functionality is a core module that ensures the accuracy and stability of data forwarding, and it must undergo rigorous functional verification and coverage testing. Currently, testers typically write targeted test cases manually, or use scripts to semi-automatically generate constrained test cases.

[0003] Each test case has a fixed source and destination address. During execution, the test case is first parsed to extract the fixed source and destination addresses, and a corresponding simulated network data packet is generated accordingly. Then, the network data packet is sent to the device under test (DUT), and the actual output port of the network data packet is monitored in real time to determine whether it matches the expected port in the routing table.

[0004] Because the test is highly coupled with the routing table, once the routing table configuration is changed (network segment adjustment, port mapping update, addition or deletion of routing entries, recalculation of dynamic routing protocols), all the original test cases become invalid. They need to be manually located, modified, recompiled and debugged one by one, which results in high maintenance costs. Summary of the Invention

[0005] The purpose of this application is to provide a method, testing method, platform, device, medium, and product for generating test cases, in order to solve the problem that the maintenance cost of test cases is high due to the high coupling between test cases and routing tables in related technologies.

[0006] In a first aspect, embodiments of this application provide a method for generating test cases, including: In response to receiving a verification request instruction, the target outgoing port is obtained according to the verification request instruction; In the preset mapping relationship between alternative outgoing ports and alternative network address ranges, the target network address is determined according to the target outgoing port; the target network address is the network address in the alternative network address range corresponding to the target outgoing port. Using the target network address as the destination network address of the test case corresponding to the target outgoing port, a test case corresponding to the target outgoing port is generated; the test case is used to test the routing function of the network device to which the target outgoing port belongs.

[0007] The source and destination network addresses in the existing test cases are directly derived from routing table entries. Therefore, once the routing table changes, such as with network segment adjustments or port mapping updates, the fixed addresses in the original test cases will become incompatible with the new routing table and will all become invalid.

[0008] In the above implementation, by establishing a mapping relationship between alternative outgoing ports and alternative network address ranges, the test case generation logic is separated from the routing table. When the network structure changes, only this mapping relationship needs to be updated, and the system can dynamically generate test cases that match the changed network structure without modifying the original test cases one by one, thus reducing the maintenance cost of test cases.

[0009] Optionally, obtaining the target outgoing port according to the verification request instruction includes: When the verification request instruction indicates that routing verification is performed based on a specified outgoing port, the specified outgoing port is obtained from the verification request instruction, and the specified outgoing port is the target outgoing port.

[0010] Existing methods indirectly verify routes by constructing specific addresses, with the test starting by guessing which port a given address might pass through. In the implementation described above, by specifying the target outgoing port in the verification request command, the test can begin by verifying that specific outgoing port. This method, using the specified outgoing port as a direct input parameter, achieves a precise correspondence between test intent and test execution. Thus, during testing, testers can specify each physical or logical port that needs verification one by one, eliminating the need to rely on random addresses or manual enumeration of address ranges. This fundamentally solves the problem of some ports remaining uncovered for extended periods in existing technologies, ensuring that every logical or physical port can be effectively verified.

[0011] Secondly, when a specific port is suspected of being faulty, testers do not need to reconstruct or filter complex address test sets. They can simply specify the port in the verification request instruction to immediately generate test cases for that specific port, which greatly shortens the problem reproduction cycle.

[0012] Optionally, obtaining the target outgoing port according to the verification request instruction includes: When the verification request instruction indicates that routing verification is performed based on any one of the outgoing ports, any one of the candidate outgoing ports will be determined as the target outgoing port.

[0013] Traditional methods rely on randomly generated addresses to indirectly verify routes. Since there's no direct, uniform mapping between address distribution and outgoing ports, some ports are frequently hit while others remain uncovered for extended periods. The implementation described above, however, uses candidate outgoing ports as the selection criteria, ensuring each port has a consistent probability of being selected. This guarantees that in long-term or large-scale regression testing, test traffic is fairly and evenly distributed across all candidate outgoing ports. This fundamentally avoids the problem of uneven test resource allocation caused by improper selection strategies or uneven address distribution, where some ports are frequently tested while others remain uncovered for extended periods.

[0014] Optionally, in the preset mapping relationship between alternative outgoing ports and alternative network address ranges, the target network address is determined based on the target outgoing port, including: Using the target outgoing port, a matching operation is performed in the preset mapping relationship between alternative outgoing ports and alternative network address segments to obtain all target network address segments associated with the target outgoing port; From any host address in any target network address range, select any address as the target network address; the host address in the target network address range is an address other than the network address and the broadcast address.

[0015] In real-world network environments, a single physical or logical port often handles traffic from multiple different network segments. This means that an outgoing port may be responsible for forwarding multiple routing policies or multiple routing entries. In the implementation described above, by first obtaining all target network address ranges associated with the target outgoing port, it ensures that no network address range related to the target outgoing port is missed. Then, from the host addresses within any target network address range, any address is selected as the target network address. This allows all addresses handled by the target outgoing port to be tested and covered, effectively eliminating the problem of only verifying a portion of the address ranges in traditional methods.

[0016] Secondly, by limiting the selection of target network addresses to host addresses (excluding network addresses and broadcast addresses), this ensures that the selected target network address is a valid unicast address that can be assigned to a host. This guarantees that the destination network address used in the generated test cases is valid at the protocol level, thus avoiding problems such as incorrect routing of test stimuli and misinterpretation of test results due to invalid addresses, thereby improving the usability and reliability of the test cases.

[0017] Optionally, the mapping relationship between the alternative outgoing ports and the alternative network address ranges is constructed based on the effective routing table in the network device.

[0018] In the above implementation, since the mapping relationship between the alternative outgoing ports and the alternative network address ranges directly originates from the actual effective routing table in the network device, the constructed mapping relationship can accurately reflect the current forwarding behavior of the network device. This ensures that the mapping relationship between the destination address and the target outgoing port of the test cases subsequently generated based on this mapping relationship can be consistent with the actual forwarding logic of the network device, thereby guaranteeing the reliability and validity of the test results obtained based on this test case.

[0019] Secondly, this application provides a testing method, including: The test cases are sent to the network device, and the test cases are generated according to the method for generating test cases described in the first aspect above. Obtain the actual output port of the data packet corresponding to the test case output by the network device; Determine whether the actual output port is the same as the target output port corresponding to the test case; If the actual output port is the same as the target output port corresponding to the test case, the verification is deemed successful; if the actual output port is different from the target output port corresponding to the test case, the verification is deemed unsuccessful.

[0020] The above implementation method, in conjunction with the test case generation method in the first aspect, forms a complete automated testing chain: test cases are generated on demand, sent to network devices, the actual output port of the test cases is obtained, and the actual output port is compared with the target output port corresponding to the test cases to determine whether the verification passes. This achieves a fully automated closed loop from test case generation to result judgment, significantly improving testing efficiency and reducing the risk of errors introduced by manual operation.

[0021] Optionally, before determining whether the actual output port is the same as the target output port corresponding to the test case, the test method further includes: Determine whether the actual header fields of the data packet corresponding to the test case are the same as the expected header fields; If the actual header field of the data packet corresponding to the test case is different from the expected header field, the verification fails. Determining whether the actual output port is the same as the target output port corresponding to the test case includes: If the actual header field of the data packet corresponding to the test case is the same as the expected header field, determine whether the actual output port is the same as the target output port corresponding to the test case.

[0022] In real-world network devices, packet header fields may be modified during forwarding. If an error occurs in the network device's processing of the header fields, but the packet is still forwarded, verifying only the output port might lead to an incorrect conclusion of successful verification, masking the header processing defect. The implementation described above verifies the correctness of the header fields first, ensuring that the packet has been correctly processed before forwarding. This avoids misjudgments in port verification due to header errors and improves the accuracy of the verification results.

[0023] Thirdly, this application provides a testing platform, including: The test case generation unit is configured to generate test cases according to the method described above. The test unit is configured to test the routing function of the network device according to the test method described above.

[0024] Optionally, the test case generation unit includes: The first acquisition module is configured to acquire the target output port according to the verification request instruction in response to receiving the verification request instruction; The first determining module is configured to determine the target network address based on the target outgoing port in a preset mapping relationship between candidate outgoing ports and candidate network address ranges, wherein the target network address is the network address in the candidate network address range corresponding to the target outgoing port; The generation module is configured to use the target network address as the destination network address of the test case corresponding to the target outgoing port, and generate test cases corresponding to the target outgoing port; the test cases are used to test the routing function of the network device to which the target outgoing port belongs.

[0025] Optionally, the test unit includes: The sending module is configured to send the test cases to the network device; The second acquisition module is configured to acquire the actual output port of the data packet corresponding to the test case output by the network device. The second determining module is configured to determine whether the actual output port is the same as the target output port corresponding to the test case; The third determining module is configured to indicate that the verification is successful if the actual output port is the same as the target output port corresponding to the test case; and to indicate that the verification fails if the actual output port is different from the target output port corresponding to the test case.

[0026] Fourthly, this application provides an electronic device including a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the method for generating test cases of the first aspect above, or the test method of the second aspect above.

[0027] Fifthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the method for generating test cases as described in the first aspect, or the testing method as described in the second aspect.

[0028] Sixthly, this application provides a computer program product, the computer program product comprising a computer program, which, when executed by a processor, implements the method for generating test cases as described in the first aspect, or the testing method as described in the second aspect. Attached Figure Description

[0029] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 A flowchart illustrating a method for generating test cases provided in an embodiment of this application; Figure 2 A flowchart illustrating a testing method provided in an embodiment of this application; Figure 3 A flowchart illustrating another testing method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a test case generation unit provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a test unit provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0031] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0032] Example 1: In existing technologies, even if the network device's effective routing table is completely correct, meaning the matched outgoing port is the target outgoing port, data packets may still fail to be correctly forwarded from that target outgoing port. Reasons for this may include, but are not limited to, the following: Firstly, router firewalls block ICMP echo requests from the WAN port by default. Therefore, even if the effective routing table correctly specifies the outgoing port, if an ACL (Access Control List) or firewall rule is configured on the interface corresponding to that outgoing port, the test cases will be filtered and dropped, resulting in forwarding failure.

[0033] Secondly, before a network device can send a data packet from its egress port, it needs to obtain the MAC address of the next-hop device via ARP (Address Resolution Protocol) to complete link-layer encapsulation. The next-hop device represents the actual network device corresponding to the next-hop address. If ARP resolution fails (e.g., the next-hop device does not respond or the ARP entry expires), even if the effective routing table specifies the target egress port, the data packet cannot be sent from the target egress port because encapsulation cannot be completed.

[0034] Thirdly, if the target outgoing port is in a down state, that is, the physical layer of the target outgoing port is not connected or the link layer protocol is not activated, even if the effective routing table points to the target outgoing port, the data packet cannot be sent out from the target outgoing port, and forwarding will inevitably fail.

[0035] Fourthly, when routing loops exist in the network, test cases may be repeatedly forwarded, and the TTL (Time To Live) value will continuously decrease. Eventually, the test cases will be discarded because the TTL has decreased to 0, and they will not be able to be forwarded normally from the expected target outgoing port.

[0036] Fifthly, if the TTL value of the test case is too small, it may be dropped by intermediate devices before reaching the destination; if the MTU (Maximum Transmission Unit) is set improperly, resulting in packet fragmentation failure or exceeding the link MTU limit, it will also be dropped, causing forwarding failure.

[0037] Sixthly, incorrect configuration of NAT (Network Address Translation) forwarding rules or DNAT (Destination Network Address Translation) rules may cause requests to fail to be routed correctly. Furthermore, advanced features such as load balancing policies and multi-path routing may also alter the actual forwarding path of data packets, causing test cases to fail to forward from the target outgoing port as expected.

[0038] For these reasons, it is necessary to use test cases to verify the routing of network devices in order to determine whether the data forwarding path can accurately send data.

[0039] Existing technology requires testers to manually write targeted test cases based on routing design specifications and static / dynamic routing table configurations, or to semi-automatically generate constrained random test cases through scripts. Each test case has a fixed source IP (Internet Protocol Address) and destination IP address, sends simulated network data packets to the network device under test, monitors the actual output port of the simulated network data packets, and determines whether the actual output port of the simulated network data packets is consistent with the expected port in the routing table.

[0040] The existing testing method involves: setting source and destination network addresses to generate test cases, sending the test cases to the network device under test, obtaining the actual output port of the test cases, and determining whether the actual output port is the same as the expected port. Its core verification method is the forward comparison from address to port.

[0041] However, because test cases are tightly coupled with the routing table, once the routing table configuration changes, such as network segment adjustment, port mapping update, addition or deletion of routing entries, or recalculation of dynamic routing protocols, all the original test cases will become invalid. They need to be manually located, modified, recompiled, and debugged one by one, which results in extremely low adaptation efficiency, significantly extends the development cycle, and has high maintenance costs.

[0042] Secondly, achieving full port coverage in this way requires manually constructing the IP address for each outgoing port, which is tedious and prone to omissions. Furthermore, given the massive routing tables generated by dynamic routing protocols and the presence of multi-port devices, it cannot be guaranteed that every outgoing port and every routing path will be effectively tested.

[0043] Furthermore, in large-scale regression testing, randomly generated IP addresses cannot evenly cover all outgoing ports. Some ports and routing entries remain uncovered for extended periods, requiring significantly longer test durations to barely improve coverage, resulting in high resource consumption.

[0044] Finally, existing testing methods can only verify whether a specified address can be forwarded to the correct port, but cannot reversely verify whether a specified port can correctly forward all addresses belonging to that port. Problems such as routing table configuration errors, entry conflicts, and abnormal port mappings are difficult to detect.

[0045] To address at least some of the problems in the prior art, this application provides a method for generating test cases, which can be found in [reference needed]. Figure 1 As shown, Figure 1 A flowchart illustrating a method for generating test cases provided in this application embodiment includes: Step S101: In response to receiving the verification request instruction, obtain the target output port according to the verification request instruction.

[0046] In one optional implementation of this application, the verification request instruction is used to characterize route verification based on a specified outgoing port. In this case, the verification request instruction includes the specified outgoing port, which is the target outgoing port. Thus, the test starting point can be set to the specified outgoing port, and the specified outgoing port can be used as a direct input parameter, eliminating the need for manual enumeration of address ranges to perform testing of a specific outgoing port.

[0047] In another optional implementation of this application, the verification request instruction is used to characterize routing verification based on any one of the egress ports of the target network device. In this case, the verification request instruction includes the identification information of the target network device. Correspondingly, any candidate egress port belonging to the target network device can be determined as the target egress port. In this way, the probability of each candidate egress port being selected is consistent, thereby ensuring that in long-term or large-scale regression testing, test traffic can be fairly and evenly distributed to all candidate egress ports. This fundamentally avoids the problem of uneven distribution of test resources, where some ports are frequently tested and others are not covered for a long time due to improper selection strategies or uneven address distribution.

[0048] In another optional implementation of this application, the verification request instruction is used to characterize the routing verification of the target network device. Similarly, in this case, the verification request instruction also includes the identification information of the target network device. All candidate outgoing ports belonging to the target network device can be determined as the target outgoing port. In this way, full routing verification based on all outgoing ports of the target network device can be achieved.

[0049] In another optional implementation of the embodiments of this application, the verification request instruction can be used to characterize the routing verification of any outgoing port. In this case, since the verification request instruction does not specify the target network device, any candidate outgoing port can be determined as the target outgoing port.

[0050] In another optional implementation of this application embodiment, the verification request instruction can characterize the routing verification of a specified port that meets a preset port status. In this case, the verification request instruction includes the preset port status, and correspondingly, the candidate outgoing port that meets the preset port status can be determined as the target outgoing port. Thus, testers can directly specify the outgoing port that meets the preset port status as the target outgoing port without manually constructing the address, thereby simplifying the routing verification configuration process and enabling them to select the outgoing port with the corresponding physical status for routing verification according to their own needs.

[0051] In this optional implementation, if there are multiple candidate output ports that meet the preset port status, all of the multiple candidate output ports that meet the preset port status can be determined as the target output port, or any one of the candidate output ports that meets the preset port status can be determined as the target output port.

[0052] For example, a preset port status could be that the port's bandwidth utilization is below a threshold, or that the port management status is UP, meaning that both the physical layer and the link layer of the port are enabled normally, and the port is in a communicable state. It is understood that the preset port statuses are not limited to the examples mentioned above and can be set according to actual needs.

[0053] Step S102: Determine the target network address based on the target outgoing port in the preset mapping relationship between alternative outgoing ports and alternative network address ranges.

[0054] In this embodiment of the application, the mapping relationship between the preset alternative outgoing ports and alternative network address ranges is constructed based on the effective routing table of the network device.

[0055] The effective routing table is the routing table that the network device currently uses for forwarding decisions.

[0056] A routing table can include static routing tables, and it can also include dynamic routing tables.

[0057] A static routing table represents fixed path information that is manually configured and written into the router by the network administrator according to the network topology, and its routing path is preset.

[0058] Dynamic routing tables can be generated using dynamic protocols such as OSPF (Open Shortest Path First), BGP (Border Gateway Protocol), and RIP (Routing Information Protocol). In SDN (Software-Defined Networking) architecture, dynamic routing tables can also be flow tables centrally calculated and distributed by the SDN controller.

[0059] The effective routing table includes a mapping between destination network address ranges, next-hop addresses, and outgoing port identifiers. Network devices use this mapping to determine the transmission path of data packets when forwarding them.

[0060] For example, the effective routing table can be as shown in Table 1:

[0061] Table 1 The destination network address range and the subnet mask together define the destination network range that the routing entry points to.

[0062] The next-hop address represents the IP address of the adjacent router interface to which the data packet needs to be sent after arriving at the current device.

[0063] The outgoing port indicates the physical or logical port from which a data packet leaves the current network device.

[0064] The protocol / type is used to indicate the origin of the route entry, such as Static, OSPF, Direct, etc.

[0065] Based on the effective routing table of network devices, routing entries can be parsed to extract four core fields: destination network address range, subnet mask, next-hop address, and outgoing port identifier. Then, all destination network address ranges corresponding to the same outgoing port can be aggregated to obtain a list of home network address ranges. Finally, a hash mapping table is constructed with the outgoing port identifier as the key and the list of home network address ranges as the value, realizing the reverse association between each valid outgoing port and its corresponding home network address range, i.e., obtaining the mapping relationship between candidate outgoing ports and candidate network address ranges. For example, a hash mapping table with the outgoing port identifier as the key and the list of home network address ranges as the value can be shown in Table 2.

[0066] Table 2 In this embodiment, the output port identifier can be any index that can identify the output location, such as physical port number, logical port ID (Identifier), or channel number.

[0067] The destination network address range includes, but is not limited to, any routable address range such as IP (Internet Protocol) subnets and MPLS (Multi-Protocol Label Switching) labels. IP subnets are the primary form of destination network addresses in traditional IP routing tables; MPLS labels are address identifiers used for label switching in MPLS label forwarding tables. Furthermore, in Layer 2 forwarding tables, MAC (Media Access Control) address ranges can also be used as destination network address ranges.

[0068] In this application, an alternative outgoing port may correspond to at least one alternative network address range, and an alternative network address range may include at least one valid address.

[0069] For example, the target outgoing port can be used to perform a matching operation in the preset mapping relationship between alternative outgoing ports and alternative network address ranges to obtain all target network address ranges associated with the target outgoing port; For each target network address range: If the target network address range is an IP subnet, any address can be selected from the host addresses within that target network address range as the target network address; the host addresses in the target network address range are addresses other than network addresses and broadcast addresses.

[0070] When the target network address range is an MPLS label, any available label value other than reserved labels can be selected from the label value range of the target network address range as the target network address.

[0071] For example, reserved labels may include labels 0 through 15. Label 0 may be an explicit null label (IPv4), label 1 may be a router alert label (Router Alert), label 2 may be an implicit null label (IPv6), label 3 may be an implicit null label (Implicit Null), and labels 4 through 15 may be other reserved labels.

[0072] If the target network address range is a MAC address range, any unicast MAC address can be selected from that range as the target network address; a unicast MAC address is an address whose least significant bit of the first byte is 0. This excludes broadcast addresses (FF:FF:FF:FF:FF:FF) and multicast addresses (addresses whose least significant bit of the first byte is 1).

[0073] Step S103: Using the target network address as the destination network address of the test case corresponding to the target outgoing port, generate the test case corresponding to the target outgoing port; the test case is used to test the routing function of the network device to which the target outgoing port belongs.

[0074] The source address of the test case can be a preset address.

[0075] In this embodiment of the application, if the destination network address is an IP address, then the preset address is also an IP address.

[0076] If the destination network address is an MPLS label, then the default address is also an MPLS label. For example, the default address can be the ingress label of the test initiating device, a default test label value, or an MPLS reserved label, to form a complete MPLS test message and verify the label forwarding function of the network device to which the target outgoing port belongs.

[0077] In this embodiment, if the destination network address is a MAC address, then the preset address is also a MAC address. For example, the preset address can be the interface MAC address of the test initiating device, a preset test MAC address, or a broadcast MAC address, to form a complete Layer 2 test frame and verify the Layer 2 forwarding function of the network device to which the target outgoing port belongs.

[0078] The method for generating test cases provided in this application establishes a mapping relationship between candidate outgoing ports and candidate network address ranges, thus separating the test case generation logic from the routing table. When the network structure changes, only this mapping relationship needs to be updated, and the system can dynamically generate test cases that match the changed network structure without modifying the original test cases one by one, thereby reducing the maintenance cost of test cases.

[0079] Combination Figure 2 As shown, after generating test cases, if you need to test the routing function of the network device at the target outgoing port based on the test cases, you can perform the following steps: Step S104: Send the test cases to the network device.

[0080] Step S105: Obtain the actual output port of the data packet corresponding to the network device's output test case.

[0081] Step S106: Determine whether the actual output port is the same as the target output port corresponding to the test case. If yes, proceed to step S107; otherwise, proceed to step S108.

[0082] In one optional implementation of this application, since the test cases are generated based on the target outgoing port, a mapping relationship between the test cases and the target outgoing ports can be obtained. Thus, the actual output port obtained can be directly compared with the target outgoing port corresponding to the test case, and verification can be completed without additional routing table queries.

[0083] In another optional implementation of this application, the test case may not include the target outgoing port. However, since the test case includes the source address and the destination network address, the destination network address can be used as the query key to perform a matching operation in the effective routing table of the network device to obtain the expected outgoing port. Correspondingly, the expected outgoing port is the target outgoing port corresponding to the test case.

[0084] Step S107: Verification confirmed.

[0085] Step S108: Verification failed.

[0086] In this embodiment of the application, the test case includes a source address and a destination network address. After receiving the test case, the network device can use the destination network address as the query key value to perform the longest prefix match in its own effective routing table to determine the corresponding next-hop address and outgoing port, and then forward the test case out from the outgoing port.

[0087] The testing method provided in this application, in conjunction with the test case generation method of the first aspect, forms a complete automated testing chain: test cases are generated on demand, sent to network devices, the actual output port of the test cases is obtained, and the actual output port is compared with the target output port corresponding to the test cases to determine whether the verification is successful. This achieves an automated testing chain from test case generation to result judgment, significantly improving testing efficiency and reducing the risk of errors introduced by manual operation.

[0088] Optional, combined Figure 3 As shown, before step S106, the following steps may also be performed: Step S109: Determine whether the actual header field of the data packet corresponding to the test case is the same as the expected header field; if yes, proceed to step S106; otherwise, proceed to step S108.

[0089] In real-world network devices, packet header fields may be modified during forwarding. If an error occurs in the network device's processing of the header fields, but the packet is still forwarded, verifying only the output port might lead to an incorrect conclusion of successful verification, masking the header processing defect. The above implementation verifies the correctness of the header fields first, ensuring that the packet has been correctly processed before forwarding. This avoids misjudgments in port verification due to header errors and improves the accuracy of the verification results.

[0090] Example 2 Based on the same inventive concept, embodiments of this application provide a verification platform, including a test case generation unit and a test unit.

[0091] The test case generation unit is configured to generate test cases according to the test case generation method of Embodiment 1 above; the test unit is configured to test the routing function of the network device according to the test method of Embodiment 1 above.

[0092] In one feasible embodiment of this application, combined with Figure 4 As shown, the test case generation unit includes: a first acquisition module 401, a first determination module 402, and a generation module 403.

[0093] The first acquisition module 401 is configured to acquire the target output port according to the verification request instruction received; The first determining module 402 is configured to determine the target network address based on the target output port in a preset mapping relationship between alternative output ports and alternative network address ranges. The generation module 403 is configured to use the target network address as the destination network address of the test case corresponding to the target outgoing port, and generate test cases corresponding to the target outgoing port; the test cases are used to test the routing function of the network device to which the target outgoing port belongs.

[0094] In one feasible implementation of this application, the first acquisition module 401 may be specifically configured to acquire the specified outgoing port from the verification request instruction when the verification request instruction indicates that routing verification is performed based on the specified outgoing port, and the specified outgoing port is the target outgoing port.

[0095] In one feasible embodiment of this application, the first acquisition module 401 may be specifically configured to determine any candidate outgoing port as the target outgoing port when the verification request instruction indicates that routing verification is performed based on any outgoing port.

[0096] In one feasible embodiment of this application, the first acquisition module 401 may be specifically configured to use the target outgoing port to perform a matching operation in the preset mapping relationship between alternative outgoing ports and alternative network address segments to obtain all target network address segments associated with the target outgoing port; and select any address as the target network address from the host addresses of any target network address segment; the host addresses in the target network address segment are addresses other than network addresses and broadcast addresses.

[0097] Combination Figure 5 As shown, the test unit includes a sending module 501, a second acquisition module 502, a second determination module 503, and a third determination module 504.

[0098] The sending module 501 is configured to send test cases to the network device. The second acquisition module 502 is configured to acquire the actual output port of the data packet corresponding to the test case output by the network device. The second determination module 503 is configured to determine whether the actual output port is the same as the target output port corresponding to the test case. The third determination module 504 is configured to indicate that the verification is successful if the actual output port is the same as the target output port corresponding to the test case, and to indicate that the verification fails if the actual output port is different from the target output port corresponding to the test case.

[0099] In one feasible embodiment of this application, the second determining module 503 is further configured to determine whether the actual header field of the data packet corresponding to the test case is the same as the expected header field. If the actual header field of the data packet corresponding to the test case is the same as the expected header field, it is determined whether the actual output port is the same as the target output port corresponding to the test case.

[0100] The third determination module 504 is also configured to determine verification failure if the actual header field of the data packet corresponding to the test case is different from the expected header field.

[0101] It should be understood that, for the sake of brevity, some of the content described in Embodiment 1 will not be repeated in this embodiment.

[0102] Example 3 Based on Embodiment 2, this application provides further illustrative examples of this application: Taking a static routing table as an example, perform route verification on a specified port of the target network device: After the verification platform starts, it obtains the effective routing table of the target network device, calculates interest on the effective routing table, and obtains three valid entries: Entry A: 10.1.1.0 / 24 → Next hop address: 192.168.1.1 → Outgoing port 3; Entry B: 10.1.2.0 / 24 → Next-hop address: Direct connection → Outgoing port 5; Entry C: 172.16.0.0 / 16 → Next hop address: 192.168.1.254 → Outgoing port 3; Create a hash mapping table between the outgoing port and the network address range, using the outgoing port as the key: Outgoing port 3: 10.1.1.0 / 24 → Next hop address: 192.168.1.1; 172.16.0.0 / 16 → Next hop address: 192.168.1.254; Outgoing port 5: 10.1.2.0 / 24 → Next hop address: Direct connection.

[0103] In response to receiving a verification request instruction, the verification request instruction specifies the target output port as output port 3.

[0104] Retrieve the network address range corresponding to port 3 from the hash map table, randomly select the 10.1.1.0 / 24 network segment, and generate a valid host address 10.1.1.123; Construct a test packet with a source IP address of 192.168.2.100 and a destination IP address of 10.1.1.123, and send it to the target network device.

[0105] If the monitor captures the test packet on outgoing port 3 and the fields are forwarded normally, the verification is considered successful; if the test packet is not captured on outgoing port 3, the routing function is considered abnormal.

[0106] Example 4 Based on Example 2, combined with Figure 6 As shown, a further example of the verification platform is provided: In this embodiment of the application, the verification platform can be implemented based on the UVM (Universal Verification Methodology) framework.

[0107] In this embodiment of the application, when a tester inputs a verification request command, the verification request command will trigger the top-level container Test of the test case in the UVM verification framework, and Test will start the corresponding sequence layer Sequence.

[0108] The Sequence layer calls the hash map stored in the core reference layer and queries the hash map based on the target outgoing port to obtain the target network address.

[0109] The Sequence layer generates test cases based on the target network address and sends the test cases to the Driver layer.

[0110] The driver layer converts test cases into physical signals and sends them to network devices.

[0111] The monitor monitors network devices and obtains the actual output port of the data packets corresponding to the network device's output test cases.

[0112] The scoring board (i.e., the second determination module and the third determination module) compares whether the actual output port is the same as the target output port, thereby determining whether the verification is successful or unsuccessful.

[0113] In addition, the scoring board can also calculate the actual output port coverage and verification pass rate.

[0114] In one optional implementation of this embodiment, the sequence layer includes a directed subsequence and a random regression subsequence. The directed subsequence is executed cyclically according to a specified port list; the random subsequence automatically and randomly selects the target outgoing port, generates the target network address, and can be configured for millions of iterations, recording a random seed.

[0115] In other words, the directional subsequence can receive a predefined list of target outgoing ports. In the test case generation task, each target outgoing port is traversed sequentially according to the order of the target outgoing port list; for each target outgoing port, a corresponding test case is generated and sent to the network device to verify the routing function of that target outgoing port.

[0116] A random subsequence can randomly select a target output port from a set of candidate output ports, rather than manually specifying it.

[0117] Example 5: Based on the same inventive concept, this embodiment provides an electronic device, see [link to relevant documentation]. Figure 6 As shown, it includes a processor 601 and a memory 602. Wherein: The processor 601 is used to execute one or more programs stored in the memory 602 to implement the above-described method or test method for generating test cases.

[0118] It is understandable that processor 601 can be a processor core or processor chip, or other circuitry capable of program configuration and execution. Memory 602 can be RAM (Random Access Memory), ROM (Read-Only Memory), flash memory, etc., but this is not a limitation.

[0119] It's understandable. Figure 6 The structure shown is for illustrative purposes only; the electronic device may also include components that are more advanced than those shown. Figure 6 The more or fewer components shown, or having the same Figure 6 Different configurations are shown. For example, it may also have an internal communication bus for communication between the processor 601 and the memory 602; or it may have an external communication interface, such as a USB (Universal Serial Bus) interface, a CAN (Controller Area Network) bus interface, etc.; or it may have an information display component such as a display screen, but this is not a limitation.

[0120] Based on the same inventive concept, this embodiment also provides a computer-readable storage medium, such as a floppy disk, optical disk, hard disk, flash memory, USB flash drive, SD (Secure Digital Memory Card), MMC (Multimedia Card), etc., in which one or more programs implementing the above steps are stored. These one or more programs can be executed by one or more processors to implement the above-described method for generating test cases or test methods. Further details will not be elaborated here.

[0121] Based on the same inventive concept, this embodiment also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described method for generating test cases or a test method.

[0122] For example, a computer program product may be an installation package or a program package.

[0123] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0124] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0125] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0126] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0127] In this article, "multiple" refers to two or more.

[0128] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for generating test cases, characterized in that, include: In response to receiving a verification request instruction, the target outgoing port is obtained according to the verification request instruction; In the preset mapping relationship between alternative outgoing ports and alternative network address ranges, the target network address is determined according to the target outgoing port, and the target network address is the network address in the alternative network address range corresponding to the target outgoing port; Using the target network address as the destination network address of the test case corresponding to the target outgoing port, generate the test case corresponding to the target outgoing port; The test cases are used to test the routing function of the network device to which the target output port belongs.

2. The method according to claim 1, characterized in that, Obtaining the target outgoing port according to the verification request instruction includes: When the verification request instruction indicates that routing verification is performed based on a specified outgoing port, the specified outgoing port is obtained from the verification request instruction, and the specified outgoing port is the target outgoing port.

3. The method according to claim 1, characterized in that, Obtaining the target outgoing port according to the verification request instruction includes: When the verification request instruction indicates that routing verification is performed based on any one of the outgoing ports, any one of the alternative outgoing ports will be determined as the target outgoing port.

4. The method according to claim 1, characterized in that, In the preset mapping relationship between alternative outgoing ports and alternative network address ranges, determining the target network address based on the target outgoing port includes: Using the target outgoing port, a matching operation is performed in the preset mapping relationship between alternative outgoing ports and alternative network address ranges to obtain all target network address ranges corresponding to the target outgoing port; From any host address in any target network address range, select any address as the target network address; the host address in the target network address range is an address other than the network address and the broadcast address.

5. The method according to any one of claims 1 to 4, characterized in that, The mapping relationship between the alternative outgoing ports and the alternative network address ranges is constructed based on the effective routing table in the network device.

6. A testing method, characterized in that, include: The test cases are sent to the network device, wherein the test cases are generated according to the method for generating test cases according to any one of claims 1 to 5; Obtain the actual output port of the data packet corresponding to the test case output by the network device; Determine whether the actual output port is the same as the target output port corresponding to the test case; If the actual output port is the same as the target output port corresponding to the test case, the verification is deemed successful. If the actual output port is different from the target output port corresponding to the test case, the verification is deemed to have failed.

7. The test method according to claim 6, characterized in that, Before determining whether the actual output port is the same as the target output port corresponding to the test case, the test method further includes: Determine whether the actual header fields of the data packet corresponding to the test case are the same as the expected header fields; If the actual header field of the data packet corresponding to the test case is different from the expected header field, the verification fails. Determining whether the actual output port is the same as the target output port corresponding to the test case includes: If the actual header field of the data packet corresponding to the test case is the same as the expected header field, determine whether the actual output port is the same as the target output port corresponding to the test case.

8. A testing platform, characterized in that, include: The test case generation unit is configured to generate test cases according to the method for generating test cases as described in any one of claims 1 to 5; The test unit is configured to test the routing function of the network device according to the test method of claim 6 or 7.

9. The testing platform according to claim 8, characterized in that, The test case generation unit includes: The first acquisition module is configured to acquire the target output port according to the verification request instruction in response to receiving the verification request instruction; The first determining module is configured to determine the target network address based on the target outgoing port in a preset mapping relationship between candidate outgoing ports and candidate network address ranges; the target network address is the network address in the candidate network address range corresponding to the target outgoing port. The generation module is configured to use the target network address as the destination network address of the test case corresponding to the target outgoing port, and generate test cases corresponding to the target outgoing port; the test cases are used to test the routing function of the network device to which the target outgoing port belongs.

10. The testing platform according to claim 8, characterized in that, The test unit includes: The sending module is configured to send the test cases to the network device; The second acquisition module is configured to acquire the actual output port of the data packet corresponding to the test case output by the network device. The second determining module is configured to determine whether the actual output port is the same as the target output port corresponding to the test case; The third determining module is configured to indicate that the verification is successful if the actual output port is the same as the target output port corresponding to the test case; and to indicate that the verification fails if the actual output port is different from the target output port corresponding to the test case.

11. An electronic device, characterized in that, It includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the method for generating test cases as described in any one of claims 1 to 5, or the test method as described in claim 6 or 7.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the method for generating test cases as described in any one of claims 1 to 5, or the test method as described in claim 6 or 7.

13. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method for generating test cases as described in any one of claims 1 to 5, or the test method as described in claim 6 or 7.

Images