Multi-process test method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of multi-process testing, in particular to a multi-process testing method and device, electronic equipment and a storage medium. Obtaining a target test case; the target test case is generated based on a process chain of the to-be-tested business, and the process chain comprises a plurality of to-be-tested processes; in response to a starting command for starting the target test case, starting the target test case; testing the to-be-tested process based on the process chain to generate test data; and analyzing the test data, and determining a test result corresponding to the to-be-tested process. According to the method, the dynamic test data of each thread or process does not need to be printed, and then the dynamic test data is manually analyzed to verify respective logic correctness between the threads or between the processes, so that the multi-process test efficiency is improved, and the accuracy of a test result is ensured.

Description

Technical Field

[0001] The present invention relates to the technical field of multi-process testing, and in particular to a multi-process testing method, device, electronic equipment and storage medium. Background Art

[0002] With the development of intelligent connected vehicles, vehicle-mounted software functions have gradually realized the service-oriented architecture (SOA), and middleware provides common underlying services and their interfaces. Due to the universality of SOA middleware, when upper-layer applications consume services, multiple parties often consume services at the same time, that is, multiple processes call service interfaces to obtain service capabilities; at the same time, in the implementation of application logic and the service itself, multi-threading is often used to improve its own processing capabilities. Therefore, it is particularly important to test multi-threading and multi-process of vehicle-mounted SOA middleware in the vehicle embedded environment.

[0003] For multi-thread and multi-process testing of vehicle-mounted SOA middleware in vehicle-mounted embedded environments, it is relatively complex to obtain effective dynamic test information in real time for automated verification due to the concurrent and parallel characteristics of threads, the disorder of thread scheduling, and the isolation of resources between processes. Currently, the dynamic test data of each thread or process is printed, and then manually analyzed to verify the logical correctness of each thread or process.

[0004] The above method has a low test efficiency due to the high logic complexity between multi-threads and multi-processes and manually analyzes test data. It is also easy to introduce artificial uncertainty, which affects the accuracy of the test results. Summary of the invention

[0005] In view of this, the present invention provides a multi-process testing method, device, electronic device and storage medium to solve the problem that due to the high logical complexity between multi-threads and multi-processes, the testing efficiency is low through manual analysis of test data, and it is easy to introduce human uncertainty, thereby affecting the accuracy of the test results.

[0006] In a first aspect, the present invention provides a multi-process testing method, the method comprising:

[0007] Obtain a target test case; the target test case is generated based on a process chain of the business to be tested, and the process chain includes multiple processes to be tested;

[0008] In response to a start command for starting a target test case, starting the target test case;

[0009] Test the process to be tested based on the process chain and generate test data;

[0010] Analyze the test data and determine the test results corresponding to the process to be tested.

[0011] The multi-process testing method provided in the embodiment of the present application obtains a target test case, and the target test case is generated based on the process chain of the business to be tested, and the process chain includes multiple processes to be tested, so that the multiple processes to be tested in the process chain can be tested based on the target test case. In response to the start command of starting the target test case, the target test case is started; the process to be tested is tested based on the process chain, and test data is generated, thereby ensuring the accuracy of the generated test data. The test data is analyzed to determine the test results corresponding to the process to be tested, thereby ensuring the accuracy of the determined test results. Therefore, the above method does not need to print the dynamic test data of each thread or process, and then manually analyze the dynamic test data to verify the logical correctness of each thread or process, thereby improving the efficiency of multi-process testing and ensuring the accuracy of the test results.

[0012] In an optional implementation, in response to a start command for starting a target test case, starting the target test case includes:

[0013] In response to a start command for starting a target test case, starting a parent process to be tested in the process to be tested based on a process chain;

[0014] The child process to be tested in the process to be tested is pulled up through the parent process to be tested to start the target test case.

[0015] The multi-process testing method provided in the embodiment of the present application responds to the start command of starting the target test case, starts the parent process to be tested in the process to be tested based on the process chain; pulls up the child process to be tested in the process to be tested through the parent process to be tested to start the target test case, thereby ensuring the accuracy of starting the parent process to be tested and the child process to be tested, and then ensuring the normal operation of the parent process to be tested and the child process to be tested, and ensuring the accuracy of the test results corresponding to the parent process to be tested and the child process to be tested.

[0016] In an optional implementation, the test data includes first test data corresponding to the parent process to be tested and second test data corresponding to the child process to be tested, and analyzing the test data to determine the test result corresponding to the process to be tested includes:

[0017] Controlling the parent process to be tested to verify the first test data and the second test data;

[0018] If both the first test data and the second test data are successfully verified, it is determined that all processes to be tested are successfully tested and a test result is generated;

[0019] If the verification of the first test data and / or the second test data fails, it is determined that the test of the process to be tested fails, and a test result is generated.

[0020] The multi-process testing method provided in the embodiment of the present application controls the parent process to be tested to verify the first test data and the second test data. If the verification of the first test data and the second test data is successful, it is determined that the test of all processes to be tested is successful, and a test result is generated; if the verification of the first test data and / or the second test data fails, it is determined that the test of the process to be tested fails, and a test result is generated, thereby ensuring the accuracy of the generated test result.

[0021] In an optional implementation, the process to be tested includes a parent process to be tested and a child process to be tested, the test data includes first test data corresponding to the parent process to be tested and second test data corresponding to the child process to be tested, and the process to be tested is tested based on the process chain to generate test data, including:

[0022] Testing the parent process to be tested to generate first test data;

[0023] The sub-process to be tested is tested to generate second test data.

[0024] The multi-process testing method provided in the embodiment of the present application tests the parent process to be tested to generate first test data; and tests the child process to be tested to generate second test data, thereby ensuring the accuracy of the generated first test data and the second test data.

[0025] In an optional implementation manner, the parent process to be tested includes at least one thread to be tested; and testing the parent process to be tested to generate first test data includes:

[0026] Run the main thread to be tested in the parent process to be tested to generate the first sub-test data;

[0027] Determine whether there is a child thread to be tested in the parent process to be tested;

[0028] If there is a child thread to be tested in the parent process to be tested, the child thread to be tested is run to generate second sub-test data;

[0029] Controlling the main thread to be tested to verify the first sub-test data and the second sub-test data;

[0030] First test data is generated according to a result of verifying the first sub-test data and the second sub-test data.

[0031] The multi-process testing method provided in the embodiment of the present application runs the main thread to be tested in the parent process to be tested, generates the first sub-test data, ensures the accuracy of the generated first sub-test data, and then can determine whether the parent process to be tested is tested successfully based on the first sub-test data. Determine whether there is a child thread to be tested in the parent process to be tested. If there is a child thread to be tested in the parent process to be tested, run the child thread to be tested to generate the second sub-test data, and ensure the accuracy of the generated second sub-test data. Control the main thread to be tested to verify the first sub-test data and the second sub-test data; based on the results of verifying the first sub-test data and the second sub-test data, generate the first test data, and ensure the accuracy of the generated first test data.

[0032] In an optional implementation manner, before controlling the main thread to be tested to verify the first sub-test data and the second sub-test data, the method further includes:

[0033] Run the main thread to be tested, create global variables, condition variables and mutex locks;

[0034] After the sub-thread to be tested generates the second sub-test data, the sub-thread to be tested is controlled to add a mutex lock to the global variable, and based on the identification information of the sub-thread to be tested, the corresponding second sub-test data is added to the global variable;

[0035] After the second sub-test data is added, the mutex lock of the global variable is released, and the target function in the condition variable is called to notify the main thread to be tested;

[0036] Control the main thread to be tested to obtain the second sub-test data from the global variable.

[0037] The multi-process testing method provided in the embodiment of the present application runs the main thread to be tested, creates global variables, conditional variables and mutex locks. After the sub-thread to be tested generates the second sub-test data, the sub-thread to be tested is controlled to add a mutex lock to the global variable, and based on the identification information of the sub-thread to be tested, the corresponding second sub-test data is added to the global variable, thereby ensuring the accuracy of the sub-thread to be tested adding the corresponding second sub-test data to the global variable. After completing the addition of the second sub-test data, the mutex lock of the global variable is released, and the target function in the conditional variable is called to notify the main thread to be tested, and the main thread to be tested is controlled to obtain the second sub-test data from the global variable, so that the main thread to be tested can obtain the second sub-test data, and then verify the first sub-test data and the second sub-test data.

[0038] In an optional implementation, running the main thread to be tested in the parent process to be tested to generate first sub-test data includes:

[0039] Run the main thread to be tested and obtain the running data;

[0040] Verify the operation data;

[0041] If the running data is verified successfully, it is determined that the main thread to be tested is tested successfully and the first sub-test data is generated; and a mutex is added to the first sub-test data to control the main thread to be tested to be in a waiting state, so as to wait for the sub-thread to be tested to call the target function to notify the main thread to be tested.

[0042] If the verification of the running data fails, it is determined that the test of the main thread to be tested has failed, and the first sub-test data is generated.

[0043] The multi-process testing method provided in the embodiment of the present application runs the main thread to be tested and obtains the running data; verifies the running data, and if the verification of the running data is successful, it is determined that the test of the main thread to be tested is successful, and the first sub-test data is generated; the accuracy of the generated first sub-test data is guaranteed. Then, a mutex lock is added to the first sub-test data to control the main thread to be tested to be in a waiting state, so as to wait for the sub-test thread to call the target function to notify the main thread to be tested, thereby preventing other threads from causing damage to the first sub-test data. If the verification of the running data fails, it is determined that the test of the main thread to be tested fails, and the first sub-test data is generated, thereby ensuring the accuracy of the generated first sub-test data.

[0044] In an optional implementation, controlling the parent process to be tested to verify the first test data and the second test data includes:

[0045] After the sub-process to be tested generates the second test data, based on the identification information of the sub-process to be tested, the corresponding second test data is added to the shared memory;

[0046] Controlling the target child thread in the parent process to be tested to periodically obtain the second test data from the shared memory;

[0047] After obtaining the second test data, the target child thread is controlled to add a mutex lock to the global variable;

[0048] Add the acquired second test data to the global variable;

[0049] Control the main thread to be tested in the parent process to be tested to obtain the second test data from the global variable;

[0050] The main thread to be tested is controlled to verify the first test data and the second test data.

[0051] The multi-process testing method provided by the embodiment of the present application is that after the child process to be tested generates the second test data, the corresponding second test data is added to the shared memory based on the identification information of the child process to be tested, so that the sharing of the second test data can be realized; the target child thread in the parent process to be tested is controlled to periodically obtain the second test data from the shared memory. After obtaining the second test data, the target child thread is controlled to add a mutex lock to the global variable, so that it can be ensured that when the target child thread adds the obtained second test data to the global variable, other threads will not extract or add data in the global variable, thereby ensuring the accuracy of the target child thread adding the obtained second test data to the global variable. The main thread to be tested in the parent process to be tested is controlled to obtain the second test data from the global variable, which ensures the accuracy of the obtained second test data, and the main thread to be tested is controlled to verify the first test data and the second test data, thereby ensuring the accuracy of the verification of the first test data and the second test data.

[0052] In a second aspect, the present invention provides a multi-process testing device, the device comprising:

[0053] An acquisition module is used to acquire a target test case; the target test case is generated based on a process chain of the business to be tested, and the process chain includes multiple processes to be tested;

[0054] A starting module, used for starting the target test case in response to a starting command for starting the target test case;

[0055] A generation module is used to test the process to be tested based on the process chain and generate test data;

[0056] The determination module is used to analyze the test data and determine the test results corresponding to the process to be tested.

[0057] The multi-process testing device provided in the embodiment of the present application obtains a target test case, and the target test case is generated based on the process chain of the business to be tested, and the process chain includes multiple processes to be tested, so that the multiple processes to be tested in the process chain can be tested based on the target test case. In response to the start command of starting the target test case, the target test case is started; the process to be tested is tested based on the process chain, and test data is generated, thereby ensuring the accuracy of the generated test data. The test data is analyzed to determine the test result corresponding to the process to be tested, thereby ensuring the accuracy of the determined test result. Therefore, the above method does not need to print the dynamic test data of each thread or process, and then manually analyze the dynamic test data to verify the logical correctness of each thread or process, thereby improving the efficiency of multi-process testing and ensuring the accuracy of the test results.

[0058] In a third aspect, the present invention provides an electronic device comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the multi-process testing method of the first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0059] In a fourth aspect, the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the multi-process testing method of the first aspect or any corresponding embodiment thereof.

[0060] In a fifth aspect, the present invention provides a computer program product, comprising computer instructions for causing a computer to execute the multi-process testing method of the first aspect or any corresponding embodiment thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0062] Figure 1 is a flowchart of a multi-process testing method according to an embodiment of the present invention;

[0063] Figure 2 is a flowchart of another multi-process testing method according to an embodiment of the present invention;

[0064] Figure 3 is a flowchart of another multi-process testing method according to an embodiment of the present invention;

[0065] Figure 4 is a flowchart of another multi-process testing method according to an embodiment of the present invention;

[0066] Figure 5 is a structural block diagram of a multi-process testing device according to an embodiment of the present invention;

[0067] Figure 6 It is a schematic diagram of the hardware structure of the electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0068] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0069] It should be noted that the multi-process testing method provided in the embodiment of the present application, its execution subject can be a multi-process testing device, and the multi-process testing device can be implemented as part or all of an electronic device through software, hardware, or a combination of software and hardware, wherein the electronic device can be a server or a terminal, wherein the server in the embodiment of the present application can be a single server or a server cluster composed of multiple servers, and the terminal in the embodiment of the present application can be a smart phone, a personal computer, a tablet computer, a wearable device, and other intelligent hardware devices such as an intelligent robot. In the following method embodiments, the execution subject is an electronic device as an example for explanation.

[0070] According to an embodiment of the present invention, a multi-process testing method embodiment is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0071] In this embodiment, a multi-process testing method is provided, which can be used for the above-mentioned electronic device. Figure 1 is a flowchart of a multi-process testing method according to an embodiment of the present invention. Figure 1 As shown, the process includes the following steps:

[0072] Step S101, obtaining a target test case.

[0073] The target test case is generated based on the process chain of the business to be tested, and the process chain includes multiple processes to be tested.

[0074] Specifically, the electronic device can receive target test cases input by a user; it can also receive target test cases sent by other devices; it can also generate a process chain including multiple processes to be tested based on the business to be tested, and then compile the process chain to generate target test cases.

[0075] The embodiment of the present application does not specifically limit the manner in which the electronic device obtains the target test case.

[0076] Step S102, in response to a start command for starting a target test case, start the target test case.

[0077] Specifically, the electronic device may start the target test case based on the process chain in response to a start command input by a user to start the target test case.

[0078] The electronic device may also start the target test case based on the process chain in response to a start command for starting the target test case sent by other devices.

[0079] Exemplarily, the electronic device may, based on the GoogleTest framework, respond to a start command for starting a target test case by calling the SetUp() function of the GoogleTest framework to start the target test case, and the target test case ends running after the TearDown() function in the GoogleTest framework stops.

[0080] This step will be described in detail below.

[0081] Step S103: testing the process to be tested based on the process chain to generate test data.

[0082] Specifically, the electronic device can run the process to be tested based on the process chain, and then obtain the running data corresponding to the process to be tested, verify the running data, and generate test data.

[0083] This step will be described in detail below.

[0084] Step S104: Analyze the test data to determine the test result corresponding to the process to be tested.

[0085] Specifically, after acquiring the test data corresponding to the process to be tested, the electronic device may analyze the test data to determine the test result corresponding to the process to be tested.

[0086] This step will be described in detail below.

[0087] The multi-process testing method provided in the embodiment of the present application obtains a target test case, which is generated based on a process chain of a business to be tested, and the process chain includes multiple processes to be tested, so that the multiple processes to be tested in the process chain can be tested based on the target test case. In response to a start command to start the target test case, the target test case is started; the process to be tested is tested based on the process chain, and test data is generated, thereby ensuring the accuracy of the generated test data. The test data is analyzed to determine the test result corresponding to the process to be tested, thereby ensuring the accuracy of the determined test result.

[0088] Therefore, the above method does not need to print the dynamic test data of each thread or process and then manually analyze the dynamic test data to verify the logical correctness of each thread or process, thereby improving the efficiency of multi-process testing and ensuring the accuracy of the test results.

[0089] In this embodiment, a multi-process testing method is provided, which can be used for the above-mentioned electronic device. Figure 2 is a flowchart of a multi-process testing method according to an embodiment of the present invention. Figure 2 As shown, the process includes the following steps:

[0090] Step S201, obtaining a target test case.

[0091] The target test case is generated based on the process chain of the business to be tested, and the process chain includes multiple processes to be tested.

[0092] For details about this step, please refer to the above description of step S101, which will not be described in detail here.

[0093] Step S202, in response to a start command for starting a target test case, start the target test case.

[0094] Specifically, the above step S202 may include the following steps:

[0095] Step S2021, in response to a start command for starting a target test case, start a parent process to be tested in the process to be tested based on a process chain.

[0096] Specifically, the electronic device may respond to a start command for starting a target test case input by a user or sent by other devices, and then start a parent process to be tested in the process to be tested based on identification information of the process to be tested in the process chain.

[0097] Exemplarily, the electronic device may, based on the GoogleTest framework, respond to a start command for starting a target test case by calling the SetUp() function of the GoogleTest framework to start a parent process to be tested in the process to be tested based on a process chain.

[0098] In addition, after the TearDown() function in the GoogleTest framework stops, the target test case ends running.

[0099] Step S2022: Start the child process to be tested in the process to be tested by the parent process to be tested, so as to start the target test case.

[0100] Optionally, if there is a sequential relationship between the sub-processes to be tested in the process to be tested, the sub-processes to be tested in the process to be tested are pulled up by the parent process to be tested according to the sequential relationship between the sub-processes to be tested to start the target test case.

[0101] Optionally, if there is no sequential relationship between the sub-processes to be tested in the process to be tested, the sub-processes to be tested in the process to be tested are simultaneously pulled up by the parent process to be tested to start the target test case.

[0102] Step S203: testing the process to be tested based on the process chain to generate test data.

[0103] Specifically, the process to be tested includes a parent process to be tested and a child process to be tested, and the test data includes first test data corresponding to the parent process to be tested and second test data corresponding to the child process to be tested. The above step S203, testing the process to be tested based on the process chain to generate test data, may include the following steps:

[0104] Step S2031, testing the parent process to be tested to generate first test data.

[0105] Specifically, the parent process to be tested includes at least one thread to be tested, and the above step S2031 may include the following steps:

[0106] Step a1, running the main thread to be tested in the parent process to be tested, and generating the first sub-test data.

[0107] Specifically, the above step a1 may include the following steps:

[0108] Step a11, running the main thread to be tested and obtaining running data.

[0109] Specifically, the electronic device can run the main thread to be tested and obtain running data.

[0110] Optionally, the electronic device may also control the main thread to be tested to create global variables, conditional variables and mutexes, and create a child thread to be tested in the parent process to be tested while the main thread to be tested is running.

[0111] Exemplarily, the electronic device may initialize global variables in the SetUp() function and create a child thread to be tested in the parent process to be tested.

[0112] Step a12, verifying the operation data.

[0113] Specifically, the electronic device can verify the operation data using a preset verification method.

[0114] Among them, the preset verification method can be a test macro verification method in the GoogleTest framework, or it can be other verification methods. Among them, the test macro verification method can include but is not limited to ASSERT_EQ test macro and ASSERT_NE test macro. Among them, ASSERT_EQ test macro is used to check whether two values ​​are equal; ASSERT_NE test macro is used to check whether two values ​​are not equal.

[0115] Exemplarily, the electronic device may use ASSERT_EQ to calculate a first verification value corresponding to the operating data, and then compare the first verification value corresponding to the operating data with a first true value corresponding to the operating data. If the first verification value is equal to the first true value, it is determined that the operating data verification is successful; if the first verification value is not equal to the first true value, it is determined that the operating data verification fails.

[0116] Step a13, if the running data is verified successfully, it is determined that the main thread to be tested is tested successfully, the first sub-test data is generated, and a mutex is added to the first sub-test data to control the main thread to be tested to be in a waiting state to wait for the sub-thread to be tested to call the target function to notify the main thread to be tested.

[0117] Specifically, if the running data is verified successfully, the electronic device determines that the main thread to be tested is tested successfully and generates the first sub-test data. After the main thread to be tested is tested successfully and the first sub-test data is generated, the electronic device can add a mutex lock to the first sub-test data to control the main thread to be tested to be in a waiting state, so as to wait for the sub-thread to be tested to call the target function to notify the main thread to be tested.

[0118] Exemplarily, after the main thread to be tested is tested successfully and the first sub-test data is generated, the electronic device can add a mutex lock to the first sub-test data, and then call the wait() function in the conditional variable to control the main thread to be tested to be in a waiting state.

[0119] Step a14: If the verification of the running data fails, it is determined that the test of the main thread to be tested fails, and the first sub-test data is generated.

[0120] Specifically, if the verification of the running data fails, the electronic device determines that the test of the main thread to be tested fails, and generates the first sub-test data.

[0121] Step a2: determine whether there is a child thread to be tested in the parent process to be tested.

[0122] Specifically, the electronic device may identify the parent process to be tested, and determine whether there is a child thread to be tested in the parent process to be tested.

[0123] Step a3: If there is a child thread to be tested in the parent process to be tested, the child thread to be tested is run to generate second sub-test data.

[0124] Specifically, if there is a child thread to be tested in the parent process to be tested, the child thread to be tested is run to generate second sub-test data.

[0125] It should be noted that the process of running the sub-thread to be tested and generating the second sub-test data is consistent with the process of running the main thread to be tested in the parent process to be tested and generating the first sub-test data. Therefore, you can refer to the process of running the main thread to be tested in the parent process to be tested and generating the first sub-test data.

[0126] Step a4: controlling the main thread to be tested to verify the first sub-test data and the second sub-test data.

[0127] Specifically, the electronic device may use a preset verification method to control the main thread to be tested to verify the first sub-test data and the second sub-test data.

[0128] Among them, the preset verification method can be a test macro verification method in the GoogleTest framework, or it can be other verification methods. Among them, the test macro verification method can include but is not limited to ASSERT_EQ test macro and ASSERT_NE test macro. Among them, ASSERT_EQ test macro is used to check whether two values ​​are equal; ASSERT_NE test macro is used to check whether two values ​​are not equal.

[0129] Exemplarily, the electronic device can calculate the second verification value corresponding to the first sub-test data and the second sub-test data based on the ASSERT_EQ test macro, and then compare the second verification value with the second real value corresponding to the first sub-test data and the second sub-test data to verify the first sub-test data and the second sub-test data. If the second verification value is equal to the second real value, it is determined that the verification of the first sub-test data and the second sub-test data is successful; if the second verification value is not equal to the second real value, it is determined that the verification of the first sub-test data and the second sub-test data has failed.

[0130] Step a5: generating first test data according to the result of verifying the first sub-test data and the second sub-test data.

[0131] Specifically, if the first sub-test data and the second sub-test data are successfully verified, the electronic device determines that the parent process to be tested is successfully verified and generates the first test data.

[0132] If the verification of the first sub-test data and the second sub-test data fails, the electronic device determines that the verification of the parent process to be tested fails and generates the first test data.

[0133] In an optional implementation manner of the present application, before the above step a5, controlling the main thread to be tested to verify the first sub-test data and the second sub-test data, the method further includes the following steps:

[0134] Step b1, run the main thread to be tested, create global variables, conditional variables and mutex locks.

[0135] Step b2: after the sub-thread to be tested generates the second sub-test data, the sub-thread to be tested is controlled to add a mutex lock to the global variable, and based on the identification information of the sub-thread to be tested, the corresponding second sub-test data is added to the global variable;

[0136] Step b3, after completing the addition of the second sub-test data, release the mutex lock of the global variable, and call the target function in the conditional variable to notify the main thread to be tested;

[0137] Step b4, controlling the main thread to be tested to obtain the second sub-test data from the global variable.

[0138] Specifically, the electronic device may run a main thread to be tested, control the main thread to be tested to create global variables, conditional variables and mutexes in the main thread to be tested, and create a child thread to be tested in a parent process to be tested.

[0139] Then, the electronic device can obtain the running data corresponding to the main thread to be tested and verify the running data. If the running data is verified successfully, it is determined that the main thread to be tested is tested successfully, the first sub-test data is generated, and a mutex is added to the first sub-test data, and the main thread to be tested is controlled to be in a waiting state to wait for the sub-thread to be tested to call the target function to notify the main thread to be tested.

[0140] At the same time, the sub-thread to be tested can obtain the running data corresponding to the sub-thread to be tested, and verify the running data. According to the verification result, it is determined whether the sub-thread to be tested reaches the expected state or meets the preset conditions. If the sub-thread to be tested reaches the expected state or meets the preset conditions, it is determined that the test of the sub-thread to be tested is successful, and the second sub-test data is generated; if the sub-thread to be tested does not reach the expected state or meet the preset conditions, it is determined that the test of the sub-thread to be tested fails, and the second sub-test data is generated.

[0141] After the sub-test thread generates the second sub-test data, the sub-test thread is controlled to add a mutex lock to the global variable, and based on the identification information of the sub-test thread, the corresponding second sub-test data is added to the global variable. After the second sub-test data is added, the mutex lock of the global variable is released, and the target function in the condition variable is called to notify the main thread to be tested. Exemplarily, the sub-test thread can call the notify() function in the condition variable to notify the main thread to be tested.

[0142] After the main thread to be tested receives the notification sent by the sub thread to be tested, the electronic device can control the main thread to be tested to obtain the second sub test data from the global variable.

[0143] Then, the main thread to be tested is controlled to verify the first sub-test data and the second sub-test data.

[0144] Step S2032: Test the sub-process to be tested to generate second test data.

[0145] The sub-process to be tested includes at least one thread to be tested.

[0146] Specifically, the electronic device may run the main thread to be tested in the sub-process to be tested to generate the third sub-test data. Then, it is determined whether there is a sub-thread to be tested in the sub-process to be tested; if there is a sub-thread to be tested in the sub-process to be tested, the sub-thread to be tested is run to generate the fourth sub-test data. The electronic device controls the sub-thread to be tested to verify the third sub-test data and the fourth sub-test data. Then, the electronic device generates the second test data according to the result of verifying the third sub-test data and the fourth sub-test data.

[0147] It should be noted that the step of generating the second test data corresponding to the child process to be tested may refer to the step of generating the first test data corresponding to the parent process to be tested, which will not be described in detail here.

[0148] Step S204: Analyze the test data to determine the test result corresponding to the process to be tested.

[0149] Specifically, the test data includes first test data corresponding to the parent process to be tested and second test data corresponding to the child process to be tested. The above step S204 may include the following steps:

[0150] Step S2041, controlling the parent process to be tested to verify the first test data and the second test data.

[0151] Specifically, the above step S2041 may include the following steps:

[0152] Step c1: after the sub-process to be tested generates the second test data, the corresponding second test data is added to the shared memory based on the identification information of the sub-process to be tested.

[0153] Specifically, after the sub-process to be tested generates the second test data, the electronic device may control the sub-process to be tested, and add the corresponding second test data to the shared memory based on the identification information of the sub-process to be tested.

[0154] Step c2, controlling the target child thread in the parent process to be tested to periodically obtain the second test data from the shared memory.

[0155] Then, the electronic device controls the target child thread in the parent process to be tested to periodically obtain the second test data from the shared memory.

[0156] The acquisition period may be 0.1s or 0.2s, and the embodiment of the present application does not specifically limit the acquisition period.

[0157] Step c3, after acquiring the second test data, controlling the target child thread to add a mutex lock to the global variable.

[0158] Specifically, after acquiring the second test data, the target sub-thread is controlled to add a mutex lock to the global variable.

[0159] Step c4, adding the acquired second test data to the global variable.

[0160] Specifically, the electronic device may control the target sub-thread to add the acquired second test data to the global variable.

[0161] Step c5, controlling the main thread to be tested in the parent process to be tested to obtain the second test data from the global variable.

[0162] Specifically, after the sub-thread to be tested adds the acquired second test data to the global variable, the electronic device may control the main thread to be tested in the parent process to be tested to acquire the second test data from the global variable.

[0163] Step c6, controlling the main thread to be tested to verify the first test data and the second test data.

[0164] Specifically, the electronic device may use a preset verification method to control the main thread to be tested to verify the first test data and the second test data.

[0165] Among them, the preset verification method can be a test macro verification method in the GoogleTest framework, or it can be other verification methods. Among them, the test macro verification method can include but is not limited to ASSERT_EQ test macro and ASSERT_NE test macro. Among them, ASSERT_EQ test macro is used to check whether two values ​​are equal; ASSERT_NE test macro is used to check whether two values ​​are not equal.

[0166] Exemplarily, the electronic device may use ASSERT_EQ to calculate the third verification value corresponding to the first test data and the second test data, and then compare the third verification value corresponding to the first test data and the second test data with the third true value corresponding to the first test data and the second test data. If the third verification value is equal to the third true value, it is determined that the verification of the first test data and the second test data is successful; if the third verification value is not equal to the third true value, it is determined that the verification of the first test data and the second test data has failed.

[0167] Step S2042: If both the first test data and the second test data are successfully verified, it is determined that all processes to be tested are successfully tested and a test result is generated.

[0168] Step S2043: If the verification of the first test data and / or the second test data fails, it is determined that the test of the process to be tested fails, and a test result is generated.

[0169] The multi-process testing method provided in the embodiment of the present application responds to the start command of starting the target test case, starts the parent process to be tested in the process to be tested based on the process chain; pulls up the child process to be tested in the process to be tested through the parent process to be tested to start the target test case, thereby ensuring the accuracy of starting the parent process to be tested and the child process to be tested, and then ensuring the normal operation of the parent process to be tested and the child process to be tested, and ensuring the accuracy of the test results corresponding to the parent process to be tested and the child process to be tested.

[0170] Then, run the main thread to be tested in the parent process to be tested, create global variables, conditional variables and mutexes, run the main thread to be tested, and obtain the running data; verify the running data, if the running data is successfully verified, then determine that the main thread to be tested is successfully tested, and generate the first sub-test data; ensure the accuracy of the generated first sub-test data. Then, add a mutex to the first sub-test data, control the main thread to be tested to be in a waiting state, so as to wait for the sub-thread to be tested to call the target function to notify the main thread to be tested, thereby avoiding other threads from causing damage to the first sub-test data. If the running data verification fails, then determine that the main thread to be tested fails, and generate the first sub-test data; ensure the accuracy of the generated first sub-test data, and then determine whether the parent process to be tested is successfully tested based on the first sub-test data. Determine whether there is a sub-thread to be tested in the parent process to be tested. If there is a sub-thread to be tested in the parent process to be tested, run the sub-thread to be tested, generate the second sub-test data, and ensure the accuracy of the generated second sub-test data. After the sub-thread to be tested generates the second sub-test data, the sub-thread to be tested is controlled to add a mutex lock to the global variable, and based on the identification information of the sub-thread to be tested, the corresponding second sub-test data is added to the global variable, thereby ensuring the accuracy of the sub-thread to be tested adding the corresponding second sub-test data to the global variable. After completing the addition of the second sub-test data, the mutex lock of the global variable is released, and the target function in the conditional variable is called to notify the main thread to be tested, and the main thread to be tested is controlled to obtain the second sub-test data from the global variable, so that the main thread to be tested can obtain the second sub-test data, and then verify the first sub-test data and the second sub-test data. According to the results of verifying the first sub-test data and the second sub-test data, the first test data is generated, and the accuracy of the generated first test data is guaranteed.

[0171] Then, after the child process to be tested generates the second test data, based on the identification information of the child process to be tested, the corresponding second test data is added to the shared memory, so that the second test data can be shared; the target child thread in the parent process to be tested is controlled to periodically obtain the second test data from the shared memory. After obtaining the second test data, the target child thread is controlled to add a mutex lock to the global variable, so that when the target child thread adds the obtained second test data to the global variable, other threads will not extract or add data in the global variable, thereby ensuring the accuracy of the target child thread adding the obtained second test data to the global variable. The main thread to be tested in the parent process to be tested is controlled to obtain the second test data from the global variable, thereby ensuring the accuracy of the obtained second test data, and the main thread to be tested is controlled to verify the first test data and the second test data, thereby ensuring the accuracy of the verification of the first test data and the second test data.

[0172] Optional, such as Figure 3 FIG. 1 is a flow chart of a multi-process testing method provided in an embodiment of the present application, which mainly includes the following steps:

[0173] (1) The main thread to be tested runs.

[0174] (2) Create global variables, condition variables, and mutex locks.

[0175] (3) Initialize global variables in the SetUp() function and create a child thread to be tested.

[0176] (4) Acquisition and verification of the test process information of the main thread to be tested.

[0177] Specifically, the test process information of the main thread to be tested is obtained in real time when the main thread to be tested is running. The test process information of the main thread to be tested is judged and verified through the GoogleTest test macro. If the test process information of the main thread to be tested fails to be verified, the entire test case fails.

[0178] (5) Protection and waiting of the test result information and other test information of the main thread to be tested.

[0179] Specifically, if the test process information of the main thread to be tested passes the verification, the test result information of the main thread to be tested and other required test information are protected by a mutex lock.

[0180] (6) Creation of sub-threads to be tested and acquisition of real-time process information.

[0181] Specifically, a sub-thread to be tested is created, the sub-thread to be tested runs in real time, and its process information is obtained.

[0182] (7) Real-time process information verification.

[0183] Specifically, the GoogleTest test macro is used to judge and verify the acquired real-time test process information of the sub-thread to be tested.

[0184] (8) Expected state or condition judgment.

[0185] Specifically, if the real-time test process information verification passes, it is determined whether the sub-thread to be tested meets the expected running state or a certain condition.

[0186] (9) Processing of test information of the sub-thread to be tested.

[0187] Specifically, if the sub-thread to be tested meets the expected state, the following operations are performed in sequence: adding a mutex lock; setting globally shared sub-thread to be tested test information, synchronizing the main thread to be tested; and releasing the mutex lock.

[0188] If the sub-thread to be tested does not meet the expected state, continue to obtain and verify the real-time test process information of the sub-thread to be tested. If the real-time process information verification fails, perform the following operations in sequence: add a mutex; set the globally shared sub-thread to be tested test information; release the mutex.

[0189] (10) The sub-thread to be tested sets the global shared test information and notifies the main thread to be tested.

[0190] Specifically, the sub-thread to be tested sets the global shared test information during its running process. The sub-thread to be tested uses the `notify()` function of the condition variable to notify the main thread to be tested.

[0191] (11) The main thread to be tested waits for notification.

[0192] Specifically, when the main thread to be tested is waiting in `wait()`, it receives the `notify()` notification from the child thread to be tested.

[0193] (12) The main thread to be tested performs data verification.

[0194] After receiving the notification, the main thread to be tested uses the GoogleTest test macro to automatically and uniformly verify the test data of the main thread to be tested and the test data shared by the sub-threads to be tested.

[0195] (13) Determination of test results.

[0196] Make judgment based on the verification results:

[0197] If the test data of each thread passes unified verification, the test case is judged as PASS.

[0198] If it fails, the test case is judged as FAIL.

[0199] (14) Resource release.

[0200] After the test result is determined, release the mutex and other resources of the main thread to be tested in the `TearDown()` function.

[0201] (15) Test result statistics and execution of the next test case.

[0202] Through the above step logic, the communication and data interaction between the sub-thread to be tested and the main thread to be tested can be realized, and the test result determination and resource release can be performed automatically. This can improve the test efficiency and accuracy and ensure that the test data of each thread is correctly verified and processed.

[0203] In an optional embodiment of the present application, Figure 4As shown, the multi-process testing method provided in the embodiment of the present application may also include the following steps:

[0204] (16) Pull up the child process to be tested in the process to be tested through the parent process to be tested.

[0205] (17) The sub-process to be tested generates test data.

[0206] (18) The child process to be tested writes the test data into the shared memory.

[0207] (19) The target child thread in the parent process to be tested periodically obtains the second test data from the shared memory.

[0208] (20) After acquiring the second test data, control the target child thread to add a mutex lock to the global variable, add the acquired second test data to the global variable, and release the mutex lock.

[0209] (21) The sub-thread to be tested calls the `notify()` function of the condition variable to notify the main thread to be tested.

[0210] In the present embodiment, a multi-process test device is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceived.

[0211] This embodiment provides a multi-process testing device, such as Figure 5 As shown, including:

[0212] The acquisition module 301 is used to acquire a target test case; the target test case is generated based on a process chain of the business to be tested, and the process chain includes multiple processes to be tested;

[0213] A starting module 302, configured to start a target test case in response to a start command for starting a target test case;

[0214] A generating module 303, used for testing the process to be tested based on the process chain and generating test data;

[0215] The determination module 304 is used to analyze the test data and determine the test result corresponding to the process to be tested.

[0216] In some optional implementations, the startup module 302 is specifically used to respond to a startup command for starting a target test case, start a parent process to be tested in the process to be tested based on a process chain; and pull up a child process to be tested in the process to be tested through the parent process to be tested to start the target test case.

[0217] In some optional embodiments, the test data includes first test data corresponding to the parent process to be tested and second test data corresponding to the child process to be tested. The determination module 304 is specifically used to control the parent process to be tested to verify the first test data and the second test data; if the first test data and the second test data are both verified successfully, it is determined that all processes to be tested are tested successfully, and a test result is generated; if the verification of the first test data and / or the second test data fails, it is determined that the test of the process to be tested fails, and a test result is generated.

[0218] In some optional implementations, the process to be tested includes a parent process to be tested and a child process to be tested, the test data includes first test data corresponding to the parent process to be tested and second test data corresponding to the child process to be tested, and the generation module 303 is specifically used to test the parent process to be tested to generate the first test data; and to test the child process to be tested to generate the second test data.

[0219] In some optional implementations, the parent process to be tested includes at least one thread to be tested, and the generation module 303 is specifically used to run the main thread to be tested in the parent process to be tested to generate first sub-test data; determine whether there is a child thread to be tested in the parent process to be tested; if there is a child thread to be tested in the parent process to be tested, run the child thread to be tested to generate second sub-test data; control the main thread to be tested to verify the first sub-test data and the second sub-test data; and generate first test data based on the results of verifying the first sub-test data and the second sub-test data.

[0220] In some optional implementations, the generation module 303 is specifically used to run the main thread to be tested, create global variables, conditional variables and mutex locks; after the sub-thread to be tested generates the second sub-test data, the sub-thread to be tested is controlled to add a mutex lock to the global variable, and based on the identification information of the sub-thread to be tested, the corresponding second sub-test data is added to the global variable; after completing the addition of the second sub-test data, the mutex lock of the global variable is released, and the target function in the conditional variable is called to notify the main thread to be tested; the main thread to be tested is controlled to obtain the second sub-test data from the global variable.

[0221] In some optional implementations, the generation module 303 is specifically used to run the main thread to be tested and obtain running data; verify the running data; if the verification of the running data is successful, it is determined that the test of the main thread to be tested is successful, and the first sub-test data is generated, and a mutex lock is added to the first sub-test data to control the main thread to be tested to be in a waiting state, so as to wait for the sub-test thread to call the target function to notify the main thread to be tested; if the verification of the running data fails, it is determined that the test of the main thread to be tested fails, and the first sub-test data is generated.

[0222] In some optional embodiments, the determination module 304 is specifically used to add the corresponding second test data to the shared memory based on the identification information of the child process to be tested after the child process to be tested generates the second test data; control the target child thread in the parent process to be tested to periodically obtain the second test data from the shared memory; after obtaining the second test data, control the target child thread to add a mutex lock to the global variable; add the obtained second test data to the global variable; control the main thread to be tested in the parent process to be tested to obtain the second test data from the global variable; and control the main thread to be tested to verify the first test data and the second test data.

[0223] The further functional description of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0224] The multi-process testing device in this embodiment is presented in the form of a functional unit, where the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that executes one or more software or fixed programs, and / or other devices that can provide the above functions.

[0225] The embodiment of the present invention also provides an electronic device having the above Figure 5 The multi-process test setup shown.

[0226] See also Figure 6 , Figure 6 is a schematic diagram of the structure of an electronic device provided by an optional embodiment of the present invention, such as Figure 6 As shown, the electronic device includes: one or more processors 10, a memory 20, and interfaces for connecting components, including high-speed interfaces and low-speed interfaces. The components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the electronic device, including instructions stored in or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 6 A processor 10 is taken as an example.

[0227] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0228] The memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiment.

[0229] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the electronic device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0230] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.

[0231] The electronic device further includes an input device 30 and an output device 40. The processor 10, the memory 20, the input device 30 and the output device 40 may be connected via a bus or other means. Figure 6 The example of connecting through bus is taken in the following.

[0232] The input device 30 can receive input digital or character information, and generate key signal input related to the user settings and function control of the electronic device, such as a touch screen, a keypad, a mouse, a track pad, a touch pad, an indicator rod, one or more mouse buttons, a trackball, a joystick, etc. The output device 40 may include a display device, an auxiliary lighting device (e.g., an LED) and a tactile feedback device (e.g., a vibration motor), etc. The above-mentioned display device includes but is not limited to a liquid crystal display, a light emitting diode, a display and a plasma display. In some optional embodiments, the display device can be a touch screen.

[0233] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0234] A part of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the existence of the computer program instruction in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc., and accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium accessible to the computer.

[0235] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention. Such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A multi-process testing method, characterized in that: The method comprises: Obtain a target test case; the target test case is generated based on a process chain of a service to be tested, wherein the process chain includes multiple processes to be tested; In response to a start command for starting the target test case, start the target test case; Testing the process to be tested based on the process chain to generate test data; The test data is analyzed to determine the test result corresponding to the process to be tested.

2. The method according to claim 1, characterized in that The step of starting the target test case in response to a start command for starting the target test case comprises: In response to a start command for starting the target test case, starting a parent process to be tested in the process to be tested based on the process chain; The child process to be tested in the process to be tested is pulled up by the parent process to be tested to start the target test case.

3. The method according to claim 2, characterized in that The test data includes first test data corresponding to the parent process to be tested and second test data corresponding to the child process to be tested, and the analyzing the test data to determine the test result corresponding to the process to be tested includes: Controlling the parent process to be tested to verify the first test data and the second test data; If both the first test data and the second test data are successfully verified, it is determined that all the processes to be tested are successfully tested, and the test result is generated; If the verification of the first test data and / or the second test data fails, it is determined that the test of the process to be tested fails, and the test result is generated.

4. The method according to claim 1, characterized in that: The process to be tested includes a parent process to be tested and a child process to be tested, the test data includes first test data corresponding to the parent process to be tested and second test data corresponding to the child process to be tested, and the process to be tested is tested based on the process chain to generate test data, including: Testing the parent process to be tested to generate first test data; The sub-process to be tested is tested to generate second test data.

5. The method according to claim 4, characterized in that The parent process to be tested includes at least one thread to be tested; and the step of testing the parent process to be tested to generate first test data includes: Running the main thread to be tested in the parent process to be tested to generate first sub-test data; Determine whether there is a child thread to be tested in the parent process to be tested; If the child thread to be tested exists in the parent process to be tested, running the child thread to be tested to generate second sub-test data; Controlling the main thread to be tested to verify the first sub-test data and the second sub-test data; The first test data is generated according to a result of verifying the first sub-test data and the second sub-test data.

6. The method according to claim 5, characterized in that Before controlling the main thread to be tested to verify the first sub-test data and the second sub-test data, the method further includes: Run the main thread to be tested, create global variables, conditional variables and mutex locks; After the sub-thread to be tested generates the second sub-test data, controlling the sub-thread to be tested to add the mutex lock to the global variable, and adding the corresponding second sub-test data to the global variable based on the identification information of the sub-thread to be tested; After completing adding the second sub-test data, releasing the mutex lock of the global variable, and calling the target function in the conditional variable to notify the main thread to be tested; The main thread to be tested is controlled to obtain the second sub-test data from the global variable.

7. The method according to claim 6, characterized in that The step of running the main thread to be tested in the parent process to be tested to generate first sub-test data includes: Run the main thread to be tested and obtain running data; verifying the operating data; If the running data is successfully verified, it is determined that the main thread to be tested is successfully tested, the first sub-test data is generated, and the mutex is added to the first sub-test data, and the main thread to be tested is controlled to be in a waiting state to wait for the sub-thread to be tested to call the target function to notify the main thread to be tested; If the verification of the running data fails, it is determined that the test of the main thread to be tested fails, and the first sub-test data is generated.

8. The method according to claim 6, characterized in that The controlling the parent process to be tested to verify the first test data and the second test data includes: After the sub-process to be tested generates the second test data, based on the identification information of the sub-process to be tested, the corresponding second test data is added to the shared memory; Controlling the target child thread in the parent process to be tested to periodically obtain the second test data from the shared memory; After acquiring the second test data, controlling the target child thread to add the mutex lock to the global variable; Adding the acquired second test data to the global variable; Controlling the main thread to be tested in the parent process to be tested to obtain the second test data from the global variable; The main thread to be tested is controlled to verify the first test data and the second test data.

9. A multi-process testing device, characterized in that: The device comprises: An acquisition module is used to acquire a target test case; the target test case is generated based on a process chain of the business to be tested, wherein the process chain includes a plurality of processes to be tested; A starting module, configured to start the target test case in response to a starting command for starting the target test case; A generating module, used for testing the process to be tested based on the process chain to generate test data; The determination module is used to analyze the test data and determine the test result corresponding to the process to be tested.

10. An electronic device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the multi-process testing method according to any one of claims 1 to 8 by executing the computer instructions.

Images