A multi-processor module fault injection testing apparatus

Abstract

The application relates to a multi-processor module fault injection test device, and belongs to the technical fields of network communication, redundancy management and system test. The application can simulate all potential faults of processor modules and verify the performance of hot backup switching between the processor modules; a test equipment node sends a fault injection test case number to a tested equipment node, the tested equipment node executes a test script file with the corresponding number, can obtain all expected test intermediate running results of the tested equipment node in time, and can statistically calculate fault test coverage in real time; when the number of processor modules in the system is increased or reduced, the test code does not need to be modified, the system expansion is supported, and the system expansion has good adaptability.

Description

Technical Field

[0001] This invention belongs to the fields of network communication technology, redundancy management and system testing technology, and specifically relates to a multiprocessor module fault injection testing device. Background Technology

[0002] In a certain control system, multiple processor modules are used for redundant hot backup to improve the overall reliability of the control system. How to evaluate the fault tolerance performance of this control system during the system testing phase and verify its ability to handle anomalies or faults has become a key approach to evaluating the reliability of the control system.

[0003] In the above control system, each processor module, as the device under test node, is the core component of the control system. When testing the control system, the reliability of a single processor module can be evaluated by communicating with it individually and manually inputting abnormal parameters or creating hardware link failures. For the redundant hot backup operation of multiple processor modules, it is difficult to simulate the collaborative work between multiple processor modules and the situation where a processor module fails and switches to other processor modules. Existing technologies usually have the following disadvantages when testing the hot backup operation of multiple processor modules: (1) When testing the hot backup switching operation between multiple processor modules, it is impossible to simulate the realism of the switching operation or evaluate the real-time performance of the switching; (2) After the system completes the abnormal test, it can only obtain the final test result, and cannot obtain the desired intermediate test results or statistically analyze the test coverage; (3) Once the number of processor modules involved in the operation changes, it may overturn the current test architecture and increase the test workload. Summary of the Invention

[0004] (a) Technical problems to be solved

[0005] The technical problem to be solved by this invention is: how to overcome the problems of "inability to simulate the realism of switching operations and inability to evaluate the quality of real-time switching" and "inability to evaluate the reliability of redundant systems / modules" in current control systems.

[0006] (II) Technical Solution

[0007] To address the aforementioned technical problems, this invention provides a multiprocessor module fault injection testing device, comprising a test device node and multiple device nodes under test. The test device node includes a first blockchain writing module 11, a first acquisition module 12, a judgment module 13, a statistics module 14, and a first storage module 15. Each device node under test is a multiprocessor module, including a second storage module 21, a second acquisition module 22, a fault processor module 23, and a second blockchain writing module 24.

[0008] The first blockchain writing module 11 is used to select a fault injection test case from the local database of the test device node and broadcast the number of the fault injection test case to all the test device nodes through the blockchain network.

[0009] The second acquisition module 22 is used to open the test script corresponding to the fault injection test case number after receiving the fault injection test case number from the blockchain network.

[0010] The second storage module 21 is used to store the test scripts corresponding to each fault injection test case;

[0011] The fault processor module 23 is used to parse and process the test script, extract the input parameter information of the fault injection test case, and execute the corresponding fault processing.

[0012] The second blockchain writing module 24 is used to generate broadcast information of the actual execution results of each fault injection test case and send it to the blockchain network;

[0013] The first acquisition module 12 is used to obtain the actual execution results of the fault injection test cases from the blockchain network;

[0014] The judgment module 13 is used to compare the actual execution result of the fault injection test case with the expected execution result of the fault injection test case, and to draw a test conclusion on whether the fault injection test case passes.

[0015] Statistical module 14 is used to calculate fault test coverage and fault test pass rate based on test results;

[0016] The first storage module 15 is used to save the information of the fault injection test cases and the test conclusions to the local database of the test device node.

[0017] Preferably, before performing fault injection testing on the test device node, fault injection test cases for all test device nodes are generated first, the number of all fault injection test cases is counted and saved, and the first storage module 15 saves the information of each fault injection test case to the local database.

[0018] Preferably, the content stored in the local database of the test device node includes:

[0019] The ID of each fault injection test case: This ID is unique and serves as a retrieval item in the database;

[0020] Description of each fault injection test case: Briefly explain the purpose and use of the fault injection test case;

[0021] Expected execution results for each fault injection test case: List all expected intermediate and final execution results of the device node under test during the execution of the fault injection test case;

[0022] Actual execution results of fault injection test cases: List the actual intermediate and final execution results of the device node under test during the execution of fault injection test cases;

[0023] Whether the fault injection test case passes: If the expected execution result is consistent with the actual execution result, the test case passes; otherwise, the test case fails.

[0024] Whether the fault injection test case was executed: If the actual execution result of the fault injection test case is received, it indicates that the test has been executed; otherwise, it indicates that the test has not been executed.

[0025] Preferably, the first blockchain writing module 11 is also used to broadcast the time to all tested device nodes through the blockchain network to ensure time synchronization of all tested device nodes in the blockchain network.

[0026] Preferably, the first blockchain writing module 11 is also used to send "start test" and "stop test" commands to all tested device nodes through the blockchain network.

[0027] Preferably, the content of the test script corresponding to the fault injection test case number includes:

[0028] Input parameter information for fault injection test cases: These include one or more input parameters. By setting the values ​​of these input parameters, various faults or anomalies can be simulated.

[0029] Input parameter setting interval: The fault processor module 23 sets the current input parameter value according to this interval. The input parameter setting interval is used to simulate the handling of faults or anomalies by the device node under test under a certain timing.

[0030] Does it need to record the execution time of this execution? If it is necessary to record the execution time of the device under test before and after a certain fault or abnormality occurs, set this script parameter to "Yes"; otherwise, set this script parameter to "No".

[0031] The output parameter values ​​of the test case: include one or more output parameters, including all intermediate results and the final result that the tester is concerned with.

[0032] Preferably, step S2 specifically includes:

[0033] Fault processor module 23 is also used to create a separate process to handle fault injection test tasks for test device nodes;

[0034] When the fault processor module 23 receives the "start test" command sent by the test device node from the blockchain network, it starts the process and begins to work;

[0035] Each fault injection test case number corresponds to a test script. In the process, after the second acquisition module 22 receives the fault injection test case number from the blockchain network, it opens the test script corresponding to the number locally.

[0036] The fault processor module 23 sets the value of each input parameter according to the set interval time of each input parameter in the test script;

[0037] The fault processor module 23 performs corresponding fault processing according to the input parameter values;

[0038] The fault processor module 23 saves the test results generated during the fault handling process in the corresponding output parameters, and the second blockchain writing module 24 sends these output parameters to the blockchain network.

[0039] When the fault processor module 23 receives a "stop test" command from the test device node in the blockchain network, it stops the operation of the process.

[0040] Preferably, if the fault processor module 23 needs to calculate the execution time of this test after setting an input parameter, it records the current system time in a blockchain ledger when the fault injection test case is started; when the fault injection test case is completed, it records the current system time in the blockchain ledger again, obtains the execution time of this test by the difference between the two recorded times in the blockchain ledger, generates broadcast information for this test execution time, and sends it to the blockchain network.

[0041] Preferably, the fault test coverage and fault test pass rate are obtained by the following method: after the first blockchain writing module 11 sends a "stop test" command to the fault processor module 23 through the blockchain network, the statistics module 14 divides the number of passed fault injection test cases by the total number of test cases to obtain the fault test pass rate, and divides the number of executed fault injection test cases by the total number of fault injection test cases to obtain the fault test coverage.

[0042] The present invention also provides an application of the device in the fields of network communication technology, redundancy management and system testing technology.

[0043] (III) Beneficial Effects

[0044] The advantages of this invention compared to the prior art are:

[0045] 1. This device can realistically simulate all potential faults of the processor module and verify the performance of hot backup switching between processor modules;

[0046] 2. The test device node sends the fault injection test case number to the device under test node. The device under test node executes the test script file with the corresponding number. It can obtain all the expected intermediate test results of the device under test node in a timely manner and calculate the fault test coverage in real time.

[0047] 3. When the number of processor modules in the control system increases or decreases, there is no need to modify the test code, supporting system expansion and having good adaptability to system expansion. Attached Figure Description

[0048] Figure 1 This is a diagram showing the overall architecture of the device of the present invention;

[0049] Figure 2 This is a diagram of the node structure of the test equipment of the present invention;

[0050] Figure 3 This is a structural diagram of the node of the device under test according to the present invention. Detailed Implementation

[0051] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0052] This invention proposes a multiprocessor module fault injection testing device. By inputting various faults into the multiprocessor modules, this device not only verifies the entire control system's ability to handle faults and anomalies, but also verifies the collaborative operation between the various processor modules and the functionality and performance of switching to other processor modules after one processor module fails. The device can provide real-time feedback of any desired test results and fully verify the operational reliability of redundant hot backup of multiple processor modules. This device is suitable for scenarios involving verifying the reliability of redundant systems / modules and can obtain quantitative and qualitative indicators related to the reliability of the system / module.

[0053] like Figures 1 to 3 As shown, the present invention proposes a multiprocessor module fault injection testing device, which includes a test device node and multiple device nodes under test. The test device node includes a first blockchain writing module 11, a first acquisition module 12, a judgment module 13, a statistics module 14, and a first storage module 15. Each device node under test is a multiprocessor module, including a second storage module 21, a second acquisition module 22, a fault processor module 23, and a second blockchain writing module 24.

[0054] The first blockchain writing module 11 is used to select a fault injection test case from the local database of the test device node and broadcast the number of the fault injection test case to all the test device nodes through the blockchain network.

[0055] The second acquisition module 22 is used to open the test script corresponding to the fault injection test case number after receiving the fault injection test case number from the blockchain network.

[0056] The second storage module 21 is used to store the test scripts corresponding to each fault injection test case;

[0057] The fault processor module 23 is used to parse and process the test script, extract the input parameter information of the fault injection test case, and execute the corresponding fault processing.

[0058] The second blockchain writing module 24 is used to generate broadcast information of the actual execution results of each fault injection test case and send it to the blockchain network;

[0059] The first acquisition module 12 is used to obtain the actual execution results of the fault injection test cases from the blockchain network;

[0060] The judgment module 13 is used to compare the actual execution result of the fault injection test case with the expected execution result of the fault injection test case, and to draw a test conclusion on whether the fault injection test case passes.

[0061] Statistical module 14 is used to calculate fault test coverage and fault test pass rate based on test results;

[0062] The first storage module 15 is used to save the information of the fault injection test cases and the test conclusions to the local database of the test device node.

[0063] Before performing fault injection tests on the test device nodes, fault injection test cases for all test device nodes are generated first. The test device nodes count and save the number of all fault injection test cases, and the first storage module 15 saves the information of each fault injection test case to the local database.

[0064] The contents stored in the local database of the test device node include:

[0065] The ID of each fault injection test case: This ID is unique and serves as a retrieval item in the database;

[0066] Description of each fault injection test case: Briefly explain the purpose and use of the fault injection test case;

[0067] Expected execution results for each fault injection test case: List all expected intermediate and final execution results of the device node under test during the execution of the fault injection test case;

[0068] Actual execution results of fault injection test cases: List the actual intermediate and final execution results of the device node under test during the execution of fault injection test cases;

[0069] Whether the fault injection test case passes: If the expected execution result is consistent with the actual execution result, the test case passes; otherwise, the test case fails.

[0070] Whether the fault injection test case was executed: If the actual execution result of the fault injection test case is received, it indicates that the test has been executed; otherwise, it indicates that the test has not been executed.

[0071] The test device node and all the device nodes under test are connected through a blockchain network.

[0072] The first blockchain writing module 11 also broadcasts the time to all tested device nodes through the blockchain network to ensure time synchronization of all tested device nodes within the blockchain network.

[0073] The first blockchain writing module 11 also sends "start test" and "stop test" commands to all tested device nodes through the blockchain network.

[0074] The test script corresponding to the fault injection test case number includes the following content:

[0075] Input parameter information for fault injection test cases: These include one or more input parameters. By setting the values ​​of these input parameters, various faults or anomalies can be simulated.

[0076] Input parameter setting interval: The fault processor module 23 sets the current input parameter value according to this interval. This parameter is used to simulate the handling of faults or anomalies by the device node under test under a certain timing.

[0077] Does it need to record the execution time of this execution? If it is necessary to record the execution time of the device under test before and after a certain fault or abnormality occurs, set this script parameter to "Yes"; otherwise, set this script parameter to "No".

[0078] The output parameter values ​​of the test case: include one or more output parameters, including all intermediate results and the final result that the tester is concerned with.

[0079] The fault processor module 23 creates a separate process to handle fault injection testing tasks for the test device nodes;

[0080] When the fault processor module 23 receives the "start test" command sent by the test device node from the blockchain network, it starts the process and begins to work;

[0081] Each fault injection test case number corresponds to a test script. In the process, after the second acquisition module 22 receives the fault injection test case number from the blockchain network, it opens the test script corresponding to the number locally.

[0082] The second acquisition module 22 sets the value of each input parameter according to the set interval time of each input parameter in the test script;

[0083] The second acquisition module 22 performs corresponding fault handling according to the input parameter values;

[0084] The second acquisition module 22 saves the test results generated during the fault handling process in the corresponding output parameters, and the second blockchain writing module 24 sends these output parameters to the blockchain network.

[0085] When the fault processor module 23 receives a "stop test" command from the test device node in the blockchain network, it stops the operation of the process.

[0086] If, during the execution of a script test, the fault processor module 23 needs to calculate the execution time of the current test after setting an input parameter, it records the current system time in a blockchain ledger when the fault injection test case is started; and records the current system time in the blockchain ledger again when the fault injection test case is completed. The execution time of the current test is obtained by the difference between the two recorded times in the blockchain ledger, and the execution time of the current test is generated into a broadcast message and sent to the blockchain network.

[0087] The fault test coverage and fault test pass rate are obtained by the following methods: After the first blockchain writing module 11 sends a "stop test" command to the fault processor module 23 through the blockchain network, the statistics module 14 divides the number of passed fault injection test cases by the total number of test cases to obtain the fault test pass rate, and divides the number of executed fault injection test cases by the total number of fault injection test cases to obtain the fault test coverage.

[0088] When the number of device nodes under test increases or decreases, there is no need to modify the code of the device nodes under test. Only the test script of the device nodes under test or the contents of the local database of the test device nodes need to be modified.

[0089] As can be seen, this invention can promptly obtain all expected intermediate test results of the tested device nodes, statistically analyze fault coverage in real time, and has good adaptability to system expansion. The solution of this invention perfectly solves the problems of current technologies such as "inability to simulate the realism of switching operations and inability to evaluate the quality of switching real-time performance" and "inability to evaluate the reliability of redundant systems / modules."

[0090] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A fault injection testing device for a multiprocessor module, characterized in that, It includes a test device node and multiple device nodes under test. The test device node includes a first blockchain writing module, a first acquisition module, a judgment module, a statistics module, and a first storage module. Each device node under test is a multi-processor module, including a second storage module, a second acquisition module, a fault processor module, and a second blockchain writing module. The first blockchain writing module is used to select a fault injection test case from the local database of the test device node and broadcast the number of the fault injection test case to all test device nodes through the blockchain network. The second acquisition module is used to open the test script corresponding to the fault injection test case number after receiving the fault injection test case number from the blockchain network. The second storage module is used to save the test scripts corresponding to each fault injection test case. The fault handler module is used to parse and process the test script, extract the input parameter information of the fault injection test case, and execute the corresponding fault handling. The second blockchain writing module is used to generate broadcast information from the actual execution results of each fault injection test case and send it to the blockchain network; The first acquisition module is used to obtain the actual execution results of the fault injection test cases from the blockchain network; The judgment module is used to compare the actual execution result of the fault injection test case with the expected execution result of the fault injection test case, and to draw a test conclusion on whether the fault injection test case passes. The statistics module is used to calculate fault test coverage and fault test pass rate based on test results. The first storage module is used to save the information of the fault injection test cases and the test conclusions to the local database of the test device node. The first blockchain writing module is also used to broadcast the time to all tested device nodes through the blockchain network to ensure time synchronization of all tested device nodes in the blockchain network. The first blockchain writing module is also used to send "start test" and "stop test" commands to all tested device nodes through the blockchain network.

2. The apparatus as claimed in claim 1, characterized in that, Before performing fault injection tests on the test device nodes, fault injection test cases for all test device nodes are generated first, the number of all fault injection test cases is counted and saved, and the first storage module saves the information of each fault injection test case to the local database.

3. The apparatus as described in claim 2, characterized in that, The contents stored in the local database of the test device node include: The ID of each fault injection test case: This ID is unique and serves as a retrieval item in the database. Description of each fault injection test case: Briefly explain the purpose and use of the fault injection test case; Expected execution results for each fault injection test case: List all expected intermediate and final execution results of the device node under test during the execution of the fault injection test case; Actual execution results of fault injection test cases: List the actual intermediate and final execution results of the device node under test during the execution of fault injection test cases; Whether the fault injection test case passes: If the expected execution result is consistent with the actual execution result, the test case passes; otherwise, the test case fails. Whether the fault injection test case was executed: If the actual execution result of the fault injection test case is received, it indicates that the test has been executed; otherwise, it indicates that the test has not been executed.

4. The apparatus as claimed in claim 1, characterized in that, The test script corresponding to the fault injection test case number includes the following content: Input parameter information for fault injection test cases: These include one or more input parameters. By setting the values ​​of these input parameters, various faults or anomalies can be simulated. Input parameter setting interval: The fault processor module sets the current input parameter value according to this interval. The input parameter setting interval is used to simulate the handling of faults or anomalies by the device under test nodes under a certain timing. Does it need to record the execution time of this test? If it is necessary to record the execution time of the tested device node before and after a certain fault or abnormality occurs, set this script parameter to "Yes"; otherwise, set this script parameter to "No". The output parameter values ​​of the test case: include one or more output parameters, including all intermediate results and the final result that the tester is concerned with.

5. The apparatus as described in claim 4, characterized in that, The fault handler module is also used to create a separate process to handle fault injection testing tasks for the test device nodes; When the fault processor module receives the "start test" command sent by the test device node from the blockchain network, it starts the process and begins to work; Each fault injection test case number corresponds to a test script. In the process, after the second acquisition module receives the fault injection test case number from the blockchain network, it opens the test script corresponding to the number locally. The fault processor module sets the value of each input parameter according to the set interval time in the test script; The fault handler module performs corresponding fault handling according to the input parameter values; The fault processor module saves the test results generated during the fault handling process in the corresponding output parameters, and the second blockchain writing module sends these output parameters to the blockchain network. When the fault processor module receives a "stop test" command from the test device node in the blockchain network, it stops the operation of the process.

6. The apparatus as claimed in claim 5, characterized in that, If the fault handler module needs to calculate the execution time of this test after setting an input parameter, it will record the current system time in a blockchain ledger when it starts executing this fault injection test case. When this fault injection test case is executed, the current system time is recorded in the blockchain ledger again. The execution time of this test is obtained by the difference between the two recorded times in the blockchain ledger. The execution time of this test is then generated into a broadcast message and sent to the blockchain network.

7. The apparatus as claimed in claim 6, characterized in that, The fault test coverage and fault test pass rate are obtained by the following methods: After the first blockchain writing module sends a "stop test" command to the fault processor module through the blockchain network, the statistics module divides the number of passed fault injection test cases by the total number of test cases to obtain the fault test pass rate, and divides the number of executed fault injection test cases by the total number of fault injection test cases to obtain the fault test coverage.

Images