Reliability test method, device, equipment, medium and system of shunt device

Abstract

The application discloses a kind of reliability test methods, devices, equipment, medium and systems of shunting equipment.The method comprises: obtaining the analog flow description information matched with the shunting equipment to be tested, and generating the analog flow matched with the analog flow description information by flow simulation equipment and sending to the shunting equipment to be tested;Obtain the reliability test script, and split the reliability test script into software exception simulation script and hardware exception simulation script;By the way of software simulation equipment executing software exception simulation script and hardware simulation equipment executing hardware exception simulation script, software and hardware exceptions are input to the shunting equipment to be tested to carry out reliability test;According to the real-time running state of the shunting equipment to be tested in the reliability test process, the performance monitoring equipment generates reliability test result.The technical scheme of the application solves the problem of insufficient coverage of reliability-related scenarios in the existing shunting equipment reliability test, and improves the effectiveness and completeness of the reliability test.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, and in particular to a reliability testing method, apparatus, equipment, medium, and system for a traffic splitter. Background Technology

[0002] With the development of communication technology, information communication methods are becoming increasingly diversified, and network communication plays a crucial role as a carrier. To meet the demands of the times, it is necessary to recognize the importance of network communication and enable the nation to truly move towards an information society.

[0003] In network communication, the reliability of network traffic splitting equipment plays a crucial role and must pass reliability testing before it can be put into use. Existing reliability testing for traffic splitting equipment typically involves sending simulated traffic packets to the equipment at a fixed rate to simulate equipment failures (power-on / off, primary / backup switching, switchboard malfunctions, and high temperatures, etc.), calculating the difference between the packets sent and received by the traffic splitting equipment, dividing it by the packet sending rate, and calculating the fault switching time.

[0004] The above-mentioned reliability testing methods for distribution equipment can cover basic scenarios, but there are certain differences from actual network scenarios. They lack simulations of sudden and abnormal scenarios based on actual network scenarios. Summary of the Invention

[0005] This invention provides a reliability testing method, apparatus, equipment, medium, and system for shunt devices, which simulates sudden and abnormal scenarios in reliability testing while maximally simulating and reproducing real-world network scenarios.

[0006] In a first aspect, embodiments of the present invention provide a reliability testing method for a shunt device, comprising:

[0007] Obtain simulated traffic description information that matches the device under test, and generate simulated traffic that matches the simulated traffic description information through a traffic simulation device and send it to the device under test;

[0008] Obtain the reliability test script and split it into software anomaly simulation script and hardware anomaly simulation script;

[0009] By using software simulation devices to execute software exception simulation scripts and hardware simulation devices to execute hardware exception simulation scripts, software and hardware exceptions are injected into the under-test distribution device for reliability testing.

[0010] The reliability test results are generated by the performance monitoring equipment based on the real-time operating status of the device under test during the reliability test process.

[0011] Furthermore, obtain simulated traffic description information that matches the device under test, including:

[0012] In the existing network scenarios adapted to the traffic offloading device under test, collect historical user traffic data;

[0013] Based on users' historical traffic data, the traffic distribution characteristics of different types of historical packets are statistically analyzed to serve as simulated traffic description information for matching the traffic distribution device under test.

[0014] By taking into account the correlation between simulated traffic description information and the packet traffic distribution characteristics of existing historical real traffic through the above settings, the authenticity of simulated traffic description information is improved.

[0015] Furthermore, a simulated flow matching the simulated flow description information is generated by a flow simulation device and sent to the distribution device under test, including:

[0016] Based on the overall expected traffic value of the simulated traffic and the description information of the simulated traffic, determine the message types that match the simulated traffic and the expected traffic value of each message type;

[0017] Obtain the byte length type that matches the simulated traffic and the percentage of each byte length type. The byte length types include normal scenario byte length and abnormal scenario byte length.

[0018] Based on the message type that matches the simulated traffic, the expected traffic value of each message type, the byte length type, and the proportion of each byte length type, determine the message quantity value of each message type under each byte length type;

[0019] The traffic simulation device generates simulated traffic by calling the simulated traffic model based on the number of packets of each packet type under each byte length type, and sends the simulated traffic to the distribution device under test at line speed.

[0020] The above settings increase the number of messages of different message types under different byte lengths, enabling the simulation of sudden scenarios in the diversion device and improving the diversity of reliability testing scenarios.

[0021] Furthermore, while generating simulated traffic that matches the simulated traffic description information through the traffic simulation device and sending it to the distribution device under test, the process also includes:

[0022] The actual playback traffic is synchronously sent to the test distribution device through the traffic playback device.

[0023] By setting up the above, real playback traffic and simulated traffic are sent to the device under test simultaneously, which increases the validity of the reliability test results of the device under test and improves the actual reference value of the test results.

[0024] Furthermore, the reliability test script is broken down into software anomaly simulation scripts and hardware anomaly simulation scripts, including:

[0025] Among the various simulation instructions included in the reliability test script, identify software anomaly simulation instructions and hardware anomaly simulation instructions;

[0026] Based on the execution order of each simulation instruction in the reliability test script and the preset test script start time, determine the instruction execution time of each software anomaly simulation instruction and hardware anomaly simulation instruction.

[0027] Based on each software exception simulation instruction and its execution time, a software exception simulation script is generated.

[0028] Based on each hardware anomaly simulation instruction and its execution time, a hardware anomaly simulation script is generated.

[0029] With the above settings, multiple scenarios can be covered through automated scripts, and related fault simulation controls can be automatically configured according to scenario requirements without human intervention, thus improving work efficiency.

[0030] Furthermore, based on the real-time operating status of the device under test during the reliability test, the performance monitoring equipment generates reliability test results, including:

[0031] The performance monitoring equipment monitors at least one operational status information of the shunt device under test in real time during the reliability test process.

[0032] When the performance monitoring device determines that the under-test traffic splitter is experiencing an abnormal operating status based on the operating status information, it sends a test traffic stop instruction to the traffic device and simultaneously records the device information of the under-test traffic splitter when the operating status is abnormal as the reliability test result.

[0033] The above settings not only monitor whether traffic forwarding is normal, but also monitor the status of the hardware system, software modules and log system of the device under test. Real-time monitoring is performed, and once an abnormality is detected in the reliability test, traffic input is immediately stopped, and the device status and information are recorded and saved.

[0034] Secondly, embodiments of the present invention also provide a reliability testing apparatus for a shunt device, comprising:

[0035] The simulated traffic sending module is used to obtain simulated traffic description information that matches the traffic splitting device under test, and to generate simulated traffic that matches the simulated traffic description information through the traffic simulation device and send it to the traffic splitting device under test;

[0036] The test script splitting module is used to obtain the reliability test script and split the reliability test script into software anomaly simulation script and hardware anomaly simulation script.

[0037] The reliability test execution module is used to inject software and hardware anomalies into the under-test distribution device by executing software anomaly simulation scripts through software simulation devices and hardware anomaly simulation scripts through hardware simulation devices, in order to conduct reliability tests.

[0038] The reliability result generation module is used to generate reliability test results based on the real-time operating status of the under-test distribution device during the reliability test process through the performance monitoring equipment.

[0039] Thirdly, embodiments of the present invention also provide a reliability testing device for a shunt device, the reliability testing device for the shunt device comprising:

[0040] At least one processor; and

[0041] A memory that is communicatively connected to at least one processor; wherein,

[0042] The memory stores a computer program that can be executed by at least one processor, such that the at least one processor is able to perform the reliability testing method for the shunt device provided in any embodiment of the present invention.

[0043] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing computer instructions, which are used to cause a processor to execute and implement the reliability testing method for the shunt device provided in any embodiment of the present invention.

[0044] Fifthly, embodiments of the present invention also provide a reliability testing system for a traffic splitting device, comprising: a main control device, and a traffic simulation device, a software simulation device, a hardware simulation device, and a performance monitoring device respectively connected to the main control device; wherein the traffic simulation device, the software simulation device, the hardware simulation device, and the performance monitoring device are respectively used to connect to the traffic splitting device under test;

[0045] The main control device is used to execute the reliability test method for the shunt device provided in any embodiment of the present invention.

[0046] Traffic simulation equipment is used to generate simulated traffic and send it to the device under test during reliability testing.

[0047] Software simulation equipment is used to inject software anomalies into the device under test by executing a software anomaly simulation script during reliability testing of the device under test.

[0048] Hardware simulation equipment is used to inject hardware anomalies into the device under test by executing a hardware anomaly simulation script during reliability testing of the device under test.

[0049] Performance monitoring equipment is used to generate reliability test results based on the real-time operating status of the switch under test during reliability testing.

[0050] This invention provides a reliability testing method, apparatus, device, medium, and system for a traffic splitter. The method involves acquiring simulated traffic description information matching the traffic splitter under test (DUT), generating simulated traffic matching the simulated traffic description information using a traffic simulation device, and sending this simulated traffic to the DUT. A reliability test script is acquired and split into a software exception simulation script and a hardware exception simulation script. Software and hardware exceptions are injected into the DUT by executing the software exception simulation script and the hardware exception simulation script, respectively, to perform reliability testing. A performance monitoring device generates reliability test results based on the real-time operating status of the DUT during the reliability test. By employing the above technical solution, the simulated traffic generated by the traffic simulation device and matching the simulated traffic description information is sent to the DUT. During reliability testing, the software simulation device injects software exceptions into the DUT by executing the software exception simulation script, and the hardware simulation device injects hardware exceptions into the DUT by executing the hardware exception simulation script. The performance monitoring device generates reliability test results based on the real-time operating status of the DUT. This invention addresses the limitations of existing traffic simulation models and the lack of simulation for sudden and abnormal scenarios. It expands the range of traffic simulation models to the greatest extent possible, thereby diversifying the traffic models and improving the effectiveness and completeness of reliability test results.

[0051] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0052] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0053] Figure 1 This is a flowchart of a reliability testing method for a shunt device according to Embodiment 1 of the present invention;

[0054] Figure 2 This is a flowchart of a reliability testing method for a shunt device according to Embodiment 2 of the present invention;

[0055] Figure 3 This is a flowchart of a reliability test result generation method according to Embodiment 2 of the present invention;

[0056] Figure 4 This is a schematic diagram of the structure of a reliability testing device for a shunt device according to Embodiment 3 of the present invention;

[0057] Figure 5 This is a schematic diagram of the structure of a reliability testing device for a shunt device according to Embodiment 4 of the present invention;

[0058] Figure 6 This is a schematic diagram of the structure of a reliability testing system for a shunt device according to Embodiment 5 of the present invention. Detailed Implementation

[0059] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0060] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0061] Example 1

[0062] Figure 1This is a flowchart of a reliability testing method for a current distribution device according to Embodiment 1 of the present invention. This embodiment is applicable to situations where reliability testing of a current distribution device under test is performed. The method can be executed by a reliability testing device for the current distribution device. This device can be implemented in hardware and / or software, and can be configured on a computer device, such as a desktop computer, laptop computer, or server with current distribution device functionality. Figure 1 As shown, the method includes:

[0063] S110. Obtain the simulated traffic description information that matches the device under test, and generate simulated traffic that matches the simulated traffic description information through the traffic simulation device and send it to the device under test.

[0064] In this embodiment, simulated traffic can be understood as simulated test traffic packets input into the device under test (DUT) during the reliability testing process. These traffic packets are generally simulated data packets generated based on the characteristics of real network data packets. Simulated traffic description information can be understood as information describing the simulated traffic, which may include message type, packet transmission rate, and byte length. Traffic simulation equipment can be understood as equipment that generates and sends simulated traffic.

[0065] Specifically, when performing reliability testing on the device under test, traffic data packets matching the device under test can be obtained in a real network, and description information of the traffic data packets can be obtained. Simulated traffic matching the description information can be generated by a traffic simulation device, and the simulated traffic can be injected into the device under test according to the test requirements.

[0066] It is understandable that while generating simulated traffic that matches the simulated traffic description information through the traffic simulation device and sending it to the distribution device under test, real traffic in the network can also be injected into the distribution device under test simultaneously to conduct reliability testing together.

[0067] Alternatively, if the simulated traffic generated by the traffic simulation device is insufficient to meet the testing requirements of the device under test, a traffic replication device can be added between the traffic simulation device and the device under test to expand the simulated traffic before injecting it into the device under test. The traffic simulation device can be a network instrument.

[0068] S120. Obtain the reliability test script and split the reliability test script into a software anomaly simulation script and a hardware anomaly simulation script.

[0069] In this embodiment, the reliability test script can be understood as a set of instructions used for reliability testing of the shunt device under test (DUT). It may include control instructions for the DUT, software anomaly simulation instructions, hardware anomaly simulation instructions, and various other instructions related to the DUT. The software anomaly simulation script can be understood as instructions used to control various software modules of the DUT during reliability testing to simulate various software anomalies. The hardware anomaly simulation script can be understood as instructions used to control the hardware related to the DUT during reliability testing to execute hardware anomaly simulations. Hardware anomaly simulation can be understood as simulating potential hardware anomalies in the DUT's hardware under real-world conditions by controlling the operating state of the hardware related to the DUT. For example, shutting down the power controller of one or more circuit modules in the DUT can simulate a power supply anomaly caused by the failure of a component in the DUT's power supply circuit.

[0070] Specifically, before conducting reliability testing, a reliability test script can be written. This script can include one or more software anomaly simulation instructions and one or more hardware anomaly simulation instructions, programmed together to simulate various software and hardware anomaly scenarios. For instance, if an anomaly scenario is: after a software reboot anomaly occurs on a single board in the under-test power distribution device, a hardware reboot anomaly occurs again after 5 minutes, the entire power distribution device can be subjected to an anomaly. Based on this scenario, a reliability test script can be constructed using software anomaly simulation instructions, wait instructions, and hardware anomaly simulation instructions.

[0071] Understandably, software anomaly simulation instructions can generally be executed separately using software simulation devices, and hardware anomaly simulation instructions can be executed separately using hardware simulation devices. Therefore, when testers construct a reliability test script from the perspective of overall anomaly scenario simulation, they need to separate the reliability test script into software anomaly simulation scripts and hardware anomaly simulation scripts.

[0072] In an optional implementation of this embodiment, when splitting the software anomaly simulation script and the hardware anomaly simulation script, if a software anomaly simulation instruction in the software anomaly simulation script is followed by a hardware anomaly simulation instruction in the reliability test script, the software anomaly simulation instruction can be identified; or if a hardware anomaly simulation instruction in the hardware anomaly simulation script is followed by a software anomaly simulation instruction in the reliability test script, the hardware anomaly simulation instruction can be identified. Then, based on the identification, the software simulation device and the hardware simulation device can be linked to execute the software anomaly simulation script and the hardware anomaly simulation script in an orderly manner according to the instruction arrangement order in the reliability test script.

[0073] In another optional implementation of this embodiment, when splitting the software exception simulation script and the hardware exception simulation script, the absolute execution time of each software exception simulation instruction and each hardware exception simulation instruction can be planned based on the relative execution time of the software exception simulation instructions and hardware exception simulation instructions in the reliability test script. For example, software exception simulation instruction B is executed 5 minutes after hardware exception simulation instruction A, and a preset start script execution time, for example, 2023.06.04:12:00:00. This results in the splitting of the software exception simulation script and the hardware exception simulation script, each carrying its absolute execution time. In this case, the software simulation device and the hardware simulation device can execute their respective software exception simulation scripts and hardware exception simulation scripts independently.

[0074] S130. By executing software exception simulation scripts using software simulation devices and hardware exception simulation scripts using hardware simulation devices, software and hardware exceptions are injected into the under-test distribution device for reliability testing.

[0075] In this embodiment, the software simulation device can be understood as a device capable of executing software-related commands in a simulation script. These software-related commands can include correct instructions and incorrect instructions. Incorrect instructions can include instructions such as executing a system reboot, a single-board reboot, software module anomaly simulation, and software process anomaly simulation at inappropriate times. The hardware simulation device can be understood as a device capable of executing hardware-related commands in a simulation script. These hardware-related commands can include normal hardware operation instructions and abnormal operation instructions. Abnormal operation instructions can be commands such as starting and stopping the power supply of the system, a single board, or a specific functional circuit.

[0076] Specifically, in the reliability testing of the shunt device under test, software anomalies are simulated by executing software anomaly simulation scripts through software simulation devices to send error commands to the shunt device under test, and hardware anomalies are simulated by executing hardware anomaly simulation scripts through hardware simulation devices to manage the power supply of the shunt device under test and control the power-on and power-off of the entire device, in order to conduct reliability testing.

[0077] S140. The reliability test results are generated by the performance monitoring equipment based on the real-time operating status of the shunt device under test during the reliability test process.

[0078] In this embodiment, the performance monitoring device can be understood as a device that has the function of real-time monitoring of the device under test. The real-time monitoring function may include functions such as reliability test data anomaly identification, automatic shutdown of traffic input, monitoring and saving current information of the device under test.

[0079] Specifically, when performing reliability testing on the traffic distribution device under test, the device can be monitored in real time using performance monitoring equipment. This can include board status monitoring, log monitoring, traffic forwarding monitoring, and configuration monitoring, and generate reliability test results.

[0080] In an optional embodiment of this example, the performance monitoring device can promptly stop the injection of simulated traffic when the device under test malfunctions, and promptly save various field parameters of the device under test. This can help testers accurately and efficiently locate the cause of the malfunction and improve the efficiency of reliability testing.

[0081] For example, during reliability testing of the device under test (DUT), a large amount of simulated traffic is generated using a traffic simulation device. The total traffic value of the simulated traffic exceeds the maximum processing capacity of the DUT. Simultaneously, a hardware simulation device simulates an abnormal power outage of the DUT, injecting the aforementioned anomaly into the DUT. A performance monitoring device monitors the real-time operating status of the DUT to check for malfunctions, processing anomalies, and whether power can be restored within the expected time, generating the reliability test results for the DUT.

[0082] It should be noted that, in the embodiments of the present invention, after the traffic simulation device generates simulated traffic that matches the simulated traffic description information and sends it to the traffic splitting device under test, the traffic splitting device under test returns the received simulated traffic to the traffic simulation device. Then, the traffic simulation device can further compare the differences between the sent and received simulated traffic to verify the packet forwarding accuracy of the traffic splitting device under test, and thus a more comprehensive reliability test can be performed on the traffic splitting device under test.

[0083] The technical solution of this embodiment obtains simulated traffic description information matching the device under test (DUT), and generates simulated traffic matching the simulated traffic description information using a traffic simulation device, which is then sent to the DUT. A reliability test script is obtained and split into a software anomaly simulation script and a hardware anomaly simulation script. Software and hardware anomalies are injected into the DUT by executing the software anomaly simulation script using a software simulation device and the hardware anomaly simulation script using a hardware simulation device, respectively, to perform reliability testing. A performance monitoring device generates reliability test results based on the real-time operating status of the DUT during the reliability test. This approach differs from traditional DUT reliability testing methods that rely on limited traffic models and relatively fixed fault scenarios, improving the comprehensiveness of reliability testing and increasing the practical reference value of the reliability test results.

[0084] Example 2

[0085] Figure 2This is a flowchart of a reliability testing method for a shunt device provided in Embodiment 2 of the present invention. This embodiment is based on the above embodiments and further optimized and extended, and can be combined with various optional technical solutions in the above embodiments. For example... Figure 2 As shown, the method includes:

[0086] S210. In the existing network scenario adapted to the traffic distribution device under test, collect historical user traffic data.

[0087] In this embodiment, the existing network scenario can be a campus network scenario, a backbone network scenario, or a provincial local area network scenario, etc., and historical traffic data can be understood as real traffic data that already exists in the real scenario.

[0088] Specifically, real traffic data of users in the current network scenario can be collected in the actual network scenario that is compatible with the traffic distribution device to be tested.

[0089] S220. Based on the user's historical traffic data, statistically analyze the traffic distribution characteristics of different types of historical packets to serve as simulated traffic description information for matching the traffic distribution device under test.

[0090] In this embodiment, traffic distribution characteristics can be understood as the distribution characteristics of message types, traffic proportion of each type of message, packet sending rate, and byte length in the traffic.

[0091] Specifically, based on historical traffic data collected in the live network scenario, the traffic proportion, packet sending rate, and byte length of different types of historical packets are analyzed and statistically analyzed. The above statistical information is used as the simulated traffic description information to match the traffic distribution device under test, and simulated traffic can be generated based on the above simulated traffic description information.

[0092] S230. Based on the overall expected traffic value of the simulated traffic and the simulated traffic description information, determine the message type that matches the simulated traffic and the expected traffic value of each message type.

[0093] In this embodiment, the overall expected traffic value can be understood as the maximum simulated traffic value that the under-test distribution device can handle. This traffic value can be the maximum value desired by the user or the maximum value designed by the user; the present invention does not specifically limit this. The expected packet traffic value can be understood as the traffic value of any packet type desired by the user or designed by the user.

[0094] Specifically, when performing reliability testing on the device under test, the message type matching the simulated traffic and the traffic value of each message type can be determined based on the overall expected traffic value of the simulated traffic and the simulated traffic description information constructed based on the traffic distribution characteristics of different types of historical messages from historical traffic data. For example, message types may include V4 ordinary messages, V6 ordinary messages, tunnel messages, and fragmented messages.

[0095] In a specific example, if the simulated traffic description information records that the packet traffic of V4 ordinary packets accounts for 40%, and the total expected traffic value of the simulated traffic is 1024GB, then the expected traffic value of the V4 ordinary packet is 1024GB*40%.

[0096] S240. Obtain the byte length type that matches the simulated traffic and the percentage of each byte length type. The byte length types include normal scenario byte length and abnormal scenario byte length.

[0097] Specifically, during reliability testing of the device under test, the byte length type matching the simulated traffic and the proportion of each byte length type are obtained based on the simulated traffic description information. The byte length types include normal scenario byte lengths and abnormal scenario byte lengths. For example, the normal scenario byte length can be any byte length from 64 bytes to 1518 bytes, or a mixture of several different byte lengths. The abnormal scenario byte length can be a 64-byte burst, a 1518-byte burst, an ultra-short packet, or an ultra-long packet.

[0098] S250. Based on the message type that matches the simulated traffic, the expected traffic value of each message type, the byte length type, and the proportion of each byte length type, determine the message quantity value of each message type under each byte length type.

[0099] For example, the packet types matching the simulated traffic are V4 normal packets and V6 normal packets, where the expected traffic value for V4 normal packets is 600 and the expected traffic value for V6 normal packets is 400. The byte length types matching the simulated traffic include: 64 bytes, 512 bytes, and 1518 bytes, with 64 bytes accounting for 56%, 512 bytes for 20%, and 1518 bytes for 24%. Therefore, the number of 64-byte V4 normal packets is 336, the number of 64-byte V6 normal packets is 224, the number of 512-byte V4 normal packets is 120, the number of 512-byte V6 normal packets is 80, the number of 1518-byte V4 normal packets is 144, and the number of 1518-byte V6 normal packets is 96.

[0100] S260. Based on the number of packets of each packet type under each byte length type, the traffic simulation device calls the simulated traffic model to generate simulated traffic and sends the simulated traffic to the distribution device under test at line speed.

[0101] In this embodiment, the simulated traffic model can be understood as a program or software used to generate simulated traffic. Specifically, it can be understood as a pre-trained machine learning model. A simulated traffic model can correspond to a message type. The input of a simulated traffic model for a certain message type is the byte length type and the number of messages, and the output is the number of messages of that message type under that byte length type.

[0102] Optionally, while generating simulated traffic that matches the simulated traffic description information through the traffic simulation device and sending it to the distribution device under test, the following may also be included:

[0103] The actual playback traffic is synchronously sent to the test distribution device through the traffic playback device.

[0104] Among them, traffic replay equipment can be understood as equipment that replays historical real traffic.

[0105] Specifically, the traffic sent to the device under test can be simulated traffic, or a combination of simulated and real traffic.

[0106] Furthermore, if the actual playback traffic generated by the traffic playback device cannot meet the testing requirements of the traffic distribution device under test, a traffic replication device can be added between the traffic playback device and the traffic distribution device under test to expand the actual playback traffic before injecting it into the traffic distribution device under test. The traffic playback device can be a server.

[0107] It should be noted that in the reliability testing of the device under test, if the instrument port resources and performance of the simulated flow are insufficient, the simulated flow can be copied; if the performance of the simulated flow and the real flow sent to the device under test is insufficient, the two types of flow can be copied to improve the flow performance.

[0108] In this embodiment, real playback traffic and simulated traffic are sent simultaneously, which increases the diversity of traffic and simulates and restores the actual network traffic as much as possible.

[0109] S270. Obtain the reliability test script and split the reliability test script into a software anomaly simulation script and a hardware anomaly simulation script.

[0110] Optionally, the reliability test script can be split into software anomaly simulation scripts and hardware anomaly simulation scripts, and may also include:

[0111] In the reliability test script, software anomaly simulation instructions and hardware anomaly simulation instructions are identified among the various simulation instructions. Based on the execution order of the simulation instructions in the reliability test script and the preset test script start time, the instruction execution time of each software anomaly simulation instruction and hardware anomaly simulation instruction is determined. Based on each software anomaly simulation instruction and its instruction execution time, a software anomaly simulation script is generated. Based on each hardware anomaly simulation instruction and its instruction execution time, a hardware anomaly simulation script is generated.

[0112] In this embodiment, multiple scenarios can be covered by automated scripts, and the relevant fault simulation control can be automatically configured according to the scenario requirements without human intervention, which improves work efficiency and saves human labor.

[0113] S280. By executing software exception simulation scripts using software simulation devices and hardware exception simulation scripts using hardware simulation devices, software and hardware exceptions are injected into the under-test distribution device for reliability testing.

[0114] S290. The reliability test results are generated by the performance monitoring equipment based on the real-time operating status of the shunt device under test during the reliability test process.

[0115] Optional, Figure 3 This is a flowchart of a reliability test result generation method provided in Embodiment 2 of the present invention, as shown below. Figure 3 As shown, it includes:

[0116] S2901. Monitor at least one operational status information of the shunt device under test in real time during the reliability test process using performance monitoring equipment.

[0117] Specifically, during the reliability testing of the device under test, at least one of the following operational status information of the device under test is monitored in real time: board status, logs, traffic forwarding, and configuration.

[0118] S2902. When the performance monitoring equipment determines that the under-test diversion device is experiencing an abnormal operating status based on the operating status information, it sends a test traffic stop sending instruction to the traffic device and simultaneously records the device information of the under-test diversion device when the operating status is abnormal as the reliability test result.

[0119] Specifically, the device status information is monitored in real time through the performance monitoring equipment. If any abnormalities are found, such as hardware system abnormalities, traffic forwarding abnormalities, software module abnormalities, or log recording abnormalities, a test traffic stop sending instruction is sent to the traffic simulation equipment to stop sending simulated traffic to the device under test. At the same time, the operating status information of the device under test, such as the board status, logs, traffic forwarding, and configuration, is recorded as the reliability test result.

[0120] This embodiment differs from common methods for testing the stability of switching devices, which focus primarily on calculating failover time. Instead, it uses performance monitoring equipment to monitor the hardware and software status of the switching device under test (DUT) to determine if any anomalies have occurred. If an anomaly is detected, a test traffic stop instruction is sent to the traffic device, immediately halting traffic input and recording and saving the DUT's status and information. This increases the validity and completeness of the DUT's reliability test results.

[0121] The technical solution of this embodiment collects historical user traffic data in a live network scenario. Based on the traffic distribution characteristics of the historical user traffic data, it determines the packet types matching the simulated traffic, the expected traffic value of each packet type, the byte length type, and the quantity proportion of each byte length type. Based on the above information, it obtains the packet quantity value of each packet type under each byte length type. A traffic simulation device then uses this information to generate simulated traffic by calling a simulated traffic model, and sends the simulated traffic at line speed to the distribution device under test. By adopting this technical solution, it solves the problem that existing traffic models are fixed or limited to a certain type. It enriches the traffic model based on real historical user traffic data, increasing the realism of the traffic model. By increasing the variety of packet type combinations, it simulates and restores the real network scenario as closely as possible.

[0122] Example 3

[0123] Figure 4 This is a schematic diagram of a reliability testing device for a shunt device according to Embodiment 3 of the present invention. This embodiment is applicable to scenarios involving reliability testing of the shunt device under test, and is not specifically limited thereto. Figure 4 As shown, the reliability testing device for the traffic splitting equipment includes: a simulated traffic transmission module 31, a test script splitting module 32, a reliability test execution module 33, and a reliability result generation module 34.

[0124] The system includes the following modules: a simulated traffic sending module 31, which acquires simulated traffic description information matching the device under test and generates simulated traffic matching the simulated traffic description information via a traffic simulation device, sending it to the device under test; a test script splitting module 32, which acquires a reliability test script and splits it into a software anomaly simulation script and a hardware anomaly simulation script; a reliability test execution module 33, which injects software and hardware anomalies into the device under test by executing the software anomaly simulation script via a software simulation device and the hardware anomaly simulation script via a hardware simulation device, for reliability testing; and a reliability result generation module 34, which generates reliability test results based on the real-time operating status of the device under test during the reliability test via a performance monitoring device.

[0125] The technical solution of this embodiment obtains simulated traffic description information matching the device under test (DUT), and generates simulated traffic matching the simulated traffic description information using a traffic simulation device, which is then sent to the DUT. A reliability test script is obtained and split into a software anomaly simulation script and a hardware anomaly simulation script. Software and hardware anomalies are injected into the DUT by executing the software anomaly simulation script using a software simulation device and the hardware anomaly simulation script using a hardware simulation device, respectively, to perform reliability testing. A performance monitoring device generates reliability test results based on the real-time operating status of the DUT during the reliability test. This approach differs from traditional DUT reliability testing methods that rely on limited traffic models and relatively fixed fault scenarios, improving the comprehensiveness of reliability testing and increasing the practical reference value of the reliability test results.

[0126] Optionally, the analog traffic transmission module 31 includes:

[0127] The historical traffic data collection unit is used to collect historical user traffic data in the existing network scenario adapted to the traffic distribution device under test.

[0128] The traffic distribution feature statistics unit is used to statistically analyze the traffic distribution features of different types of historical packets based on the user's historical traffic data, and to provide simulated traffic description information for matching the traffic distribution device under test.

[0129] The message expected traffic value determination unit is used to determine the message type that matches the simulated traffic and the message expected traffic value for each message type based on the overall expected traffic value of the simulated traffic and the simulated traffic description information.

[0130] The byte acquisition unit is used to acquire the byte length type that matches the simulated traffic and the proportion of each byte length type. The byte length types include normal scenario byte length and abnormal scenario byte length.

[0131] The message quantity determination unit is used to determine the message quantity value of each message type under each byte length type based on the message type that matches the simulated traffic, the expected traffic value of each message type, the byte length type, and the quantity ratio of each byte length type.

[0132] The simulated traffic line-rate transmission unit is used to generate simulated traffic by calling the simulated traffic model based on the number of messages of each message type under each byte length type through the traffic simulation device, and then send the simulated traffic to the distribution device under test at line rate.

[0133] Optionally, the analog traffic transmission module 31 may also include:

[0134] The real playback traffic sending unit is used to synchronously send real playback traffic to the test distribution device through the traffic playback device.

[0135] Optionally, the test script is split into module 32, including:

[0136] The abnormal simulation instruction identification unit is used to identify software abnormal simulation instructions and hardware abnormal simulation instructions among the various simulation instructions included in the reliability test script.

[0137] The instruction execution time determination unit is used to determine the instruction execution time of each software anomaly simulation instruction and hardware anomaly simulation instruction based on the execution order of each simulated instruction in the reliability test script and the preset test script start time.

[0138] The software exception simulation script generation unit is used to generate software exception simulation scripts based on each software exception simulation instruction and the instruction execution time of each software exception simulation instruction.

[0139] The hardware anomaly simulation script generation unit is used to generate hardware anomaly simulation scripts based on each hardware anomaly simulation instruction and the instruction execution time of each hardware anomaly simulation instruction.

[0140] Optionally, the reliability result generation module 34 includes:

[0141] The operation status information monitoring unit is used to monitor at least one operation status information of the under-test shunt device in real time during the reliability test process through performance monitoring equipment.

[0142] The stop instruction sending unit is used to send a test traffic stop instruction to the traffic device when the performance monitoring device determines that the under-test traffic splitter is in an abnormal operating state based on the operating status information, and simultaneously record the device information of the under-test traffic splitter when the operating state is abnormal as the reliability test result.

[0143] The reliability testing device for the shunt device provided in the embodiments of the present invention can execute the reliability testing method for the shunt device provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0144] Example 4

[0145] Figure 5 A schematic diagram of an electronic device 40 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0146] like Figure 5 As shown, the electronic device 40 includes at least one processor 41 and a memory, such as a read-only memory (ROM) 42 or a random access memory (RAM) 43, communicatively connected to the at least one processor 41. The memory stores computer programs executable by the at least one processor. The processor 41 can perform various appropriate actions and processes based on the computer program stored in the ROM 42 or loaded from storage unit 48 into the RAM 43. The RAM 43 can also store various programs and data required for the operation of the electronic device 40. The processor 41, ROM 42, and RAM 43 are interconnected via a bus 44. An input / output (I / O) interface 45 is also connected to the bus 44.

[0147] Multiple components in electronic device 40 are connected to I / O interface 45, including: input unit 46, such as keyboard, mouse, etc.; output unit 47, such as various types of monitors, speakers, etc.; storage unit 48, such as disk, optical disk, etc.; and communication unit 49, such as network card, modem, wireless transceiver, etc. Communication unit 49 allows electronic device 40 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0148] Processor 41 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 41 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 41 performs the various methods and processes described above, such as the reliability testing methods for the shunt device described in various embodiments of the present invention.

[0149] The method includes:

[0150] Obtain simulated traffic description information that matches the device under test, and generate simulated traffic that matches the simulated traffic description information through a traffic simulation device and send it to the device under test;

[0151] Obtain the reliability test script and split it into software anomaly simulation script and hardware anomaly simulation script;

[0152] By using software simulation devices to execute software exception simulation scripts and hardware simulation devices to execute hardware exception simulation scripts, software and hardware exceptions are injected into the under-test distribution device for reliability testing.

[0153] The reliability test results are generated by the performance monitoring equipment based on the real-time operating status of the device under test during the reliability test process.

[0154] In some embodiments, the reliability testing method for the shunt device can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 48. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 40 via ROM 42 and / or communication unit 49. When the computer program is loaded into RAM 43 and executed by processor 41, one or more steps of the reliability testing method for the shunt device described above can be performed. Alternatively, in other embodiments, processor 41 can be configured by any other suitable means (e.g., by means of firmware) to perform the reliability testing method for the shunt device as described in the embodiments of the present invention.

[0155] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0156] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0157] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0158] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0159] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0160] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0161] Example 5

[0162] Figure 6 This is a schematic diagram of the structure of a reliability testing system for a shunt device provided in Embodiment 5 of the present invention. Figure 6 As shown, the reliability testing system for the diversion device includes: a main control device 50, and a flow simulation device 51, a software simulation device 52, a hardware simulation device 53, and a performance monitoring device 54, which are respectively connected to the main control device; wherein, the flow simulation device 51, the software simulation device 52, the hardware simulation device 53, and the performance monitoring device 54 are respectively used to connect to the diversion device 55 under test.

[0163] The main control device 50 is used to execute the reliability test method of the shunt device described in any embodiment of the present invention.

[0164] The traffic simulation device 51 is used to generate simulated traffic and send it to the traffic splitter 55 under test when performing reliability testing on the traffic splitter 55 under test.

[0165] The software simulation device 52 is used to inject software anomalies into the switch device 55 under test by executing a software anomaly simulation script during reliability testing.

[0166] The hardware simulation device 53 is used to inject hardware anomalies into the switch device 55 under test by executing a hardware anomaly simulation script during reliability testing of the switch device 55 under test.

[0167] The performance monitoring device 54 is used to generate reliability test results based on the real-time operating status of the switch device 55 under test when performing reliability testing on the switch device 55 under test.

[0168] The technical solution of this invention, by configuring a main control device and traffic simulation devices, software simulation devices, hardware simulation devices, and performance monitoring devices respectively connected to the main control device in the reliability testing system of the traffic distribution device, can generate reliability test results under the following conditions: the simulated traffic device sends simulated traffic to the traffic distribution device under test, the software simulation device injects software anomalies into the traffic distribution device under test, the hardware simulation device injects hardware anomalies into the traffic distribution device under test, and the performance monitoring device monitors the operating status of the traffic distribution device under test in real time. This increases the simulation of sudden and abnormal scenarios, realizes the diversification of traffic models, and improves the effectiveness and completeness of reliability test results.

[0169] In a complete implementation of this embodiment, it may specifically include:

[0170] Simulated traffic or real traffic, or a mixture of simulated and real traffic, is constructed using traffic simulation device 51. The maximum processing capacity traffic of the traffic splitter device 55 under test is input to the device. After internal processing, the device outputs the processed traffic to traffic simulation device 51. Traffic simulation device 51 performs packet count statistics and verifies packet correctness of the received traffic. It should be noted that the device constructing simulated traffic can be a network instrument or test instrument. A traffic model can be pre-configured in the instrument, and automated scripts can be built to automatically modify the traffic content. If the instrument's port resources and performance are insufficient, a traffic replication device is used for traffic replication. The device constructing real traffic can be a server for replaying real traffic. In real-world scenarios, real traffic performance is relatively low, requiring a traffic replication device to improve performance. The device constructing mixed traffic can be a small splitter, optical splitter, or other splitting device, selected according to the actual network environment. Its specific function is to replicate simulated and real traffic. The simulated traffic is constructed with a wide variety of message types and byte lengths, and sent at line speed to simulate real-world network scenarios.

[0171] Specifically, the traffic model can be configured based on the rate, message content, and message length. The traffic proportion of each message type can be set according to parameters. You can choose to send a single type or send multiple types simultaneously. The default packet rate is line speed. The byte length can be selected by using one or more types alternately. The normal byte length is used to verify the accuracy of the processing performance of the under-test traffic splitter 55, while the abnormal byte length is used to test the reliability of the under-test traffic splitter 55.

[0172] The software simulation device 52 performs real-time configuration management of the distribution device 55 under test to simulate real network fault scenarios. The software simulation device 52 can be a server, including command-line whole-machine reboot, single-board reboot, software module anomaly simulation, and software process anomaly simulation, which can be managed through automated scripts.

[0173] The hardware simulation device 53 is a power controller that manages the power supply of the shunt device 55 under test, and simulates the power-on and power-off faults of the whole machine. The relevant controls can be automatically configured according to the needs of the scenario without human intervention.

[0174] The performance monitoring device 54 monitors the under-test traffic splitter 55 in real time and obtains the device's status information through a script. Once an abnormality is detected in the reliability test, the traffic input to the under-test traffic splitter 55 is immediately stopped, and the status, configuration, logs and other information of the under-test traffic splitter 55 are saved, waiting for problem location and analysis.

[0175] It should be noted that the software simulation device 52 and the performance monitoring device 54 can share a single server in order to save resources.

[0176] Specifically, the main control device 50 controls the execution content and execution time of the flow simulation device 51, software simulation device 52, hardware simulation device 53 and performance monitoring device 54 according to the test requirements, thereby performing reliability tests on the diversion device 55 under test.

[0177] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0178] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A reliability testing method for a shunt device, characterized in that, include: Obtain simulated traffic description information that matches the device under test, and generate simulated traffic that matches the simulated traffic description information through a traffic simulation device and send it to the device under test; Obtain the reliability test script and split it into software anomaly simulation script and hardware anomaly simulation script; By using software simulation devices to execute software exception simulation scripts and hardware simulation devices to execute hardware exception simulation scripts, software and hardware exceptions are injected into the under-test distribution device for reliability testing. The reliability test results are generated by the performance monitoring equipment based on the real-time operating status of the device under test during the reliability test process. The step of generating simulated traffic that matches the simulated traffic description information through a traffic simulation device and sending it to the traffic splitting device under test includes: Based on the overall expected traffic value of the simulated traffic and the description information of the simulated traffic, determine the message types that match the simulated traffic and the expected traffic value of each message type; Obtain the byte length type that matches the simulated traffic and the percentage of each byte length type. The byte length types include normal scenario byte length and abnormal scenario byte length. Based on the message type that matches the simulated traffic, the expected traffic value of each message type, the byte length type, and the proportion of each byte length type, determine the message quantity value of each message type under each byte length type; The traffic simulation device generates simulated traffic by calling the simulated traffic model based on the number of packets of each packet type under each byte length type, and sends the simulated traffic to the distribution device under test at line speed.

2. The method according to claim 1, characterized in that, Obtain simulated traffic description information that matches the device under test, including: In the existing network scenarios adapted to the traffic offloading device under test, collect historical user traffic data; Based on users' historical traffic data, the traffic distribution characteristics of different types of historical packets are statistically analyzed to serve as simulated traffic description information for matching the traffic distribution device under test.

3. The method according to claim 1, characterized in that, While generating simulated traffic that matches the simulated traffic description information using a traffic simulation device and sending it to the distribution device under test, the process also includes: The actual playback traffic is synchronously sent to the test distribution device through the traffic playback device.

4. The method according to any one of claims 1-3, characterized in that, The reliability test script is split into software anomaly simulation scripts and hardware anomaly simulation scripts, including: Among the various simulation instructions included in the reliability test script, identify software anomaly simulation instructions and hardware anomaly simulation instructions; Based on the execution order of each simulation instruction in the reliability test script and the preset test script start time, determine the instruction execution time of each software anomaly simulation instruction and hardware anomaly simulation instruction. Based on each software exception simulation instruction and its execution time, a software exception simulation script is generated. Based on each hardware anomaly simulation instruction and its execution time, a hardware anomaly simulation script is generated.

5. The method according to any one of claims 1-3, characterized in that, The performance monitoring equipment generates reliability test results based on the real-time operating status of the under-test power distribution device during the reliability test process, including: The performance monitoring equipment monitors at least one operational status information of the shunt device under test in real time during the reliability test process. When the performance monitoring device determines that the under-test traffic splitter is experiencing an abnormal operating status based on the operating status information, it sends a test traffic stop transmission instruction to the traffic simulation device and simultaneously records the device information of the under-test traffic splitter when it is experiencing an abnormal operating status as the reliability test result.

6. A reliability testing device for a shunt device, characterized in that, include: The simulated traffic sending module is used to obtain simulated traffic description information that matches the traffic splitting device under test, and to generate simulated traffic that matches the simulated traffic description information through the traffic simulation device and send it to the traffic splitting device under test; The test script splitting module is used to obtain the reliability test script and split the reliability test script into software anomaly simulation script and hardware anomaly simulation script. The reliability test execution module is used to inject software and hardware anomalies into the under-test distribution device by executing software anomaly simulation scripts through software simulation devices and hardware anomaly simulation scripts through hardware simulation devices, in order to conduct reliability tests. The reliability result generation module is used to generate reliability test results based on the real-time operating status of the under-test shunt device during the reliability test process through the performance monitoring equipment. The simulated traffic transmission module includes: The message expected traffic value determination unit is used to determine the message type that matches the simulated traffic and the message expected traffic value of each message type based on the overall expected traffic value of the simulated traffic and the simulated traffic description information. The byte acquisition unit is used to acquire the byte length type that matches the simulated traffic and the proportion of each byte length type. The byte length types include normal scenario byte length and abnormal scenario byte length. The message quantity value determination unit is used to determine the message quantity value of each message type under each byte length type based on the message type that matches the simulated traffic, the expected traffic value of each message type, the byte length type, and the quantity ratio of each byte length type. The simulated traffic line-rate transmission unit is used to generate simulated traffic by calling the simulated traffic model based on the number of messages of each message type under each byte length type through the traffic simulation device, and then send the simulated traffic to the distribution device under test at line rate.

7. A reliability testing device for a shunt device, characterized in that, The reliability testing equipment for the shunt device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the reliability testing method for the shunt device according to any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that are used to cause a processor to execute the reliability testing method for the shunt device according to any one of claims 1-5.

9. A reliability testing system for a shunt device, characterized in that, include: The main control device, and the flow simulation device, software simulation device, hardware simulation device and performance monitoring device connected to the main control device respectively; wherein, the flow simulation device, software simulation device, hardware simulation device and performance monitoring device are respectively used to connect to the diversion device under test; The main control device is used to perform the method as described in any one of claims 1-5; The traffic simulation device is used to generate simulated traffic and send it to the device under test when performing reliability testing on the device under test. The software simulation device is used to inject software anomalies into the device under test by executing a software anomaly simulation script when performing reliability testing on the device under test. The hardware simulation device is used to inject hardware anomalies into the device under test by executing a hardware anomaly simulation script when performing reliability testing on the device under test. The performance monitoring device is used to generate reliability test results based on the real-time operating status of the device under test when performing reliability testing on the device under test.

Images