A debugging method and device, electronic equipment and storage medium

Abstract

The application discloses a hacking test method, which comprises the following steps: determining a function module of target software and an interface contained in the function module; performing arrangement and combination on the function module and the interface to obtain a plurality of hacking test scenes; and performing hacking test on the target software under each hacking test scene. The hacking test method can efficiently and comprehensively perform hacking test on software. The application also discloses hacking test device, electronic equipment and storage medium, which have the above beneficial effects.

Description

Technical Field

[0001] This application relates to the field of testing technology, and in particular to a burn-in test method, apparatus, electronic device, and storage medium. Background Technology

[0002] Stress testing primarily involves continuously running a system under a pre-designed test environment for a given period of time to observe its status. Stress testing is crucial in software testing, serving as a vital means of verifying software version stability and functional reliability. However, existing stress testing methods typically only perform tests under a single configuration, resulting in incomplete coverage of functionalities. Furthermore, changing software configurations often requires manual parameter adjustments, which is both labor-intensive and hinders comprehensive and reliable stress testing.

[0003] Therefore, how to perform efficient and comprehensive stress testing on software is a technical problem that needs to be solved by those skilled in the art. Summary of the Invention

[0004] The purpose of this application is to provide a stress test method, apparatus, electronic device, and storage medium that can efficiently and comprehensively perform stress tests on software.

[0005] To address the aforementioned technical problems, this application provides a stress test method, which includes:

[0006] Identify the functional modules of the target software and the interfaces contained in those functional modules;

[0007] Multiple stress test scenarios are obtained by arranging and combining the functional modules and the interfaces;

[0008] Perform a stress test on the target software in each of the stress test scenarios.

[0009] Optionally, the functional modules and interfaces can be arranged and combined to obtain multiple stress test scenarios, including:

[0010] Select multiple target functional modules from all the aforementioned functional modules;

[0011] Multiple target interfaces are selected from the interfaces included in each target functional module, and the target interfaces are sorted to obtain the interface execution order;

[0012] The stress test scenario is generated based on the selected target functional module and the execution order of the corresponding interfaces of the target functional module.

[0013] Optionally, multiple target functional modules may be selected from all the aforementioned functional modules, including:

[0014] Determine the number of modules to be selected, M; where 1 ≤ M ≤ N, and N is the total number of all the functional modules.

[0015] Select M functional modules from all the aforementioned functional modules as the target functional modules;

[0016] Accordingly, multiple target interfaces are selected from the interfaces included in each target functional module, and the target interfaces are sorted to obtain the interface execution order, including:

[0017] Determine the number of interfaces m corresponding to each target functional module; where 1≤m≤n, and n is the total number of interfaces contained in the target functional module;

[0018] Select m interfaces from all interfaces of the target functional module as target interfaces, and arrange the target interfaces to obtain the interface execution order.

[0019] Optionally, after generating the stress test scenario based on the selected target functional modules and the execution order of the interfaces corresponding to the target functional modules, the method further includes:

[0020] Determine whether all stress test scenarios for the target software have been generated;

[0021] If not, proceed to the step of selecting multiple target functional modules from all the aforementioned functional modules.

[0022] Optionally, in each of the aforementioned stress test scenarios, a stress test is performed on the target software, including:

[0023] Determine the test parameters for the stress test scenario, and determine the test duration based on the test parameters; wherein, the test parameters include the version of the target software and / or the number of functional modules included in the stress test scenario;

[0024] The target software is subjected to a stress test for the specified duration under the stress test scenario.

[0025] Optionally, if the test parameters include the number of functional modules, then determining the test duration based on the test parameters includes:

[0026] The test duration is calculated according to a preset formula; wherein the test duration is positively correlated with the number of functional modules.

[0027] Optionally, in each of the aforementioned stress test scenarios, a stress test is performed on the target software, including:

[0028] Determine the stress test scenario for the current batch;

[0029] The current batch of stress test scenarios is distributed to multiple stress test devices, so that the stress test devices can perform stress test on the target software in the current batch of stress test scenarios;

[0030] Determine whether the stress test of all the aforementioned stress test devices has been completed;

[0031] If so, determine the new current batch stress test scenario and proceed to the step of distributing the current batch stress test scenario to multiple stress test devices.

[0032] This application also provides a stress test apparatus, which includes:

[0033] An information determination module is used to determine the functional modules of the target software and the interfaces contained in the functional modules;

[0034] The scenario generation module is used to arrange and combine the functional modules and the interfaces to obtain multiple stress test scenarios;

[0035] The testing module is used to perform a stress test on the target software in each of the stress test scenarios.

[0036] This application also provides a storage medium on which a computer program is stored, wherein the computer program, when executed, implements the steps of the above-described burn-in test method.

[0037] This application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor invokes the computer program in the memory to implement the steps of the above-described stress test method.

[0038] This application provides a stress test method, comprising: determining the functional modules of a target software and the interfaces contained in the functional modules; arranging and combining the functional modules and the interfaces to obtain multiple stress test scenarios; and performing a stress test on the target software in each stress test scenario.

[0039] This application defines the functional modules of the target software and the interfaces contained in each functional module. By arranging and combining the functional modules and interfaces, multiple stress test scenarios for the target software can be obtained. Stress tests are then performed on the target software under each stress test scenario. In the above process, stress test scenarios can be obtained by arranging and combining functional modules and interfaces without manual configuration. This solution can simulate all random operations performed by personnel in real life as much as possible, overcoming the limitations of fixed stress test scenarios and expanding the scope and proportion of random testing. Therefore, this solution can efficiently and comprehensively perform stress tests on software. This application also provides a stress test device, an electronic device, and a storage medium, which have the above-mentioned beneficial effects, and will not be elaborated further here. Attached Figure Description

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

[0041] Figure 1 A flowchart illustrating a stress test method provided in an embodiment of this application;

[0042] Figure 2 A schematic diagram of a target software system provided in an embodiment of this application;

[0043] Figure 3 This is a schematic diagram illustrating a stress test scenario distribution provided in an embodiment of this application;

[0044] Figure 4 A flowchart illustrating a method for determining a stress test scenario provided in an embodiment of this application;

[0045] Figure 5 This is a schematic diagram of a stress test device provided in an embodiment of this application. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0047] Please see below. Figure 1 , Figure 1 A flowchart of a stress test method provided in this application embodiment, the specific steps of which may include:

[0048] S101: Determine the functional modules of the target software and the interfaces contained in the functional modules;

[0049] In this embodiment, the target software is used to perform a stress test. The target software can be face recognition software, audio playback software, instant messaging software, etc. The specific type of target software is not limited here.

[0050] This embodiment can identify the functional modules that can be combined with software functions. Please refer to [link / reference]. Figure 2 , Figure 2This is a schematic diagram of a target software system provided in an embodiment of this application. Figure 2 F1, F2, ..., FN represent the N functional modules of the target software. Taking face recognition software as an example, its functional modules include, but are not limited to, web modules, human-computer interaction modules, algorithm modules, IO output modules, service integration modules, etc.

[0051] Based on the identified functional modules of the target software, the interfaces that can be combined for each functional module can be statistically analyzed. Figure 2 In this context, I1, I2, ..., In represent the nth interface of a functional module. Taking the interfaces of functional modules involved in face recognition software as an example, the web module involves the distribution and reading of various software configurations and the download of resources. Therefore, the web module includes various adjustable configuration interfaces, as well as interfaces for reading configurations and downloading resources. The human-machine interface module involves the display of various situations, software configuration under human-machine operation, and resource reading on the human-machine interface. The human-machine interface module can include interfaces related to human-machine display, human-machine configuration reading, and human-machine resource reading. The algorithm module involves the recognition results of various detections, including but not limited to face recognition, personnel recognition, liveness detection, mask recognition, body temperature detection, and safety helmet recognition. The algorithm module can include interfaces of functional modules involved in algorithm detection. The peripheral interface module involves data transmission of peripheral interfaces under various situations. The peripheral interface module includes, but is not limited to, USB data transmission, RS485 data input / output, Wiegand input / output, IO input / output, etc. The service docking module involves the uploading and receiving of data between the software and other service docking software. The service docking module includes interfaces related to software data uploading and various configuration distributions performed by the server.

[0052] For each functional module's interfaces, the fields involved in each interface can be statistically analyzed; for example... Figure 2 As shown, s1, s2, ..., sp represent p fields of the interface. Since the purpose of stress testing is to test the stability of the software under certain scenarios, no abnormal configurations are made for the interface parameters in this case; standard values ​​need to be set for the parameters of the interface under test in advance. After obtaining the fields contained in each interface, stress testing can be implemented based on the fields obtained above.

[0053] S102: Arrange and combine the functional modules and the interfaces to obtain multiple stress test scenarios;

[0054] After obtaining all the functional modules and interfaces of the target software, these modules and interfaces can be arranged and combined to obtain various stress test scenarios, allowing for stress testing for a certain duration under these scenarios. As a feasible implementation method, the number of functional modules to be selected and the number of interfaces corresponding to each functional module can be predetermined, and stress test scenarios can be obtained by arranging and combining these information. The number of interfaces selected for each functional module can be different during the above process.

[0055] S103: Perform a stress test on the target software in each of the stress test scenarios.

[0056] In this embodiment, after obtaining all stress test scenarios, stress tests can be performed on the target software under each stress test scenario. Alternatively, a corresponding stress test can be performed when a new stress test scenario is generated.

[0057] This embodiment identifies the functional modules of the target software and the interfaces contained in each functional module. By arranging and combining the functional modules and interfaces, multiple stress test scenarios for the target software can be obtained. Stress tests are then performed on the target software under each stress test scenario. In the above process, stress test scenarios can be obtained by arranging and combining functional modules and interfaces without manual configuration. This solution can simulate as many random operations as possible by real-world personnel, overcoming the limitations of fixed stress test scenarios and expanding the scope and proportion of random testing. Therefore, this solution can efficiently and comprehensively perform stress tests on software.

[0058] As for Figure 1 Further description of the corresponding embodiment shows that stress tests corresponding to various stress test scenarios can be performed on one or more stress test devices. Specifically, parallel stress test can be implemented in the following way: determining the current batch of stress test scenarios; distributing the current batch of stress test scenarios to multiple stress test devices, so that the stress test devices can perform stress tests on the target software in the current batch of stress test scenarios; determining whether the stress test on all the stress test devices has been completed; if so, determining a new current batch of stress test scenarios, and proceeding to the step of distributing the current batch of stress test scenarios to multiple stress test devices. In the above process, the number of scenarios included in the current batch of stress test scenarios is the same as the number of stress test devices, so that each stress test scenario in the current batch of stress test scenarios is sent to the corresponding stress test device. The software stress test method provided in this embodiment improves the reliability of test results and test efficiency by automatically generating complete stress test scenarios and performing stress tests in parallel on multiple devices.

[0059] Please see Figure 3 , Figure 3This is a schematic diagram illustrating the distribution of a stress test scenario according to an embodiment of this application. It selects m interfaces from all interfaces and M functional modules from all functional modules, and combines these with a randomly combined parameter T set by the user to achieve automatic construction and execution of the test scenario. T represents the execution time of the stress test, D1~Dq represent the stress test devices, I1~In represent interfaces, and F1~FN represent functional modules.

[0060] Stress testing should verify the stability of software versions in various scenarios within a shorter time. This solution can automatically allocate stress testing environments to multiple devices under test and perform stress testing. Multi-threaded parallel processing helps improve efficiency.

[0061] Please see Figure 4 , Figure 4 This is a flowchart illustrating a method for determining a stress test scenario provided in an embodiment of this application. This embodiment is... Figure 1 The further description of S102 in the corresponding embodiment can be used to compare this embodiment with... Figure 1 Further implementation methods can be obtained by combining the corresponding embodiments. This embodiment may include the following steps:

[0062] S401: Select multiple target functional modules from all the aforementioned functional modules;

[0063] S402: Select multiple target interfaces from the interfaces contained in each target functional module, and sort the target interfaces to obtain the interface execution order;

[0064] S403: Generate the stress test scenario based on the selected target functional module and the execution order of the corresponding interfaces of the target functional module.

[0065] After generating the stress test scenario according to the selected target functional module and the execution order of the interface corresponding to the target functional module, it can be determined whether all stress test scenarios of the target software have been generated; if not, proceed to step S401 to select multiple target functional modules from all the functional modules.

[0066] Specifically, target functional modules can be selected as follows: determine the number of modules to be selected, M; where 1 ≤ M ≤ N, and N is the total number of all functional modules; select M functional modules from all the functional modules as the target functional modules. For example, a list of functional modules [F1, F2, ..., FN] can be obtained; the number of modules to be selected, M, is determined to achieve the number of combinations of functional modules. The value of M can be generated sequentially within the interval [1, N], and the number of all possible stress test scenarios, F... M The calculation method is as follows:

[0067] After determining the order of functional modules, the execution order of interfaces within a single functional module can be determined. The execution order of interfaces is achieved by generating a permutation order using input parameters. Specifically, the number of interfaces *m* corresponding to each target functional module can be determined; where 1 ≤ *m* ≤ *n*, and *n* is the total number of interfaces contained in the target functional module. *m* interfaces are selected from all interfaces of the target functional module as target interfaces, and the execution order is obtained by arranging these target interfaces. For example, when generating the interface execution order, it is necessary to obtain the interface list [I1, I2, ..., In] for each functional module; determine the number of interfaces *m* corresponding to each target functional module; where *m* is a random number within the interval [1, n]. This scheme determines the combination order of interfaces through permutation. The number of stress test scenarios generated when selecting *m* interfaces for the F1 functional module is... The order of arrangement can be generated through programming.

[0068] In one scenario, such as when M=2, the execution sequence of the interface is as follows: two functional modules are randomly selected from the functional modules to combine and form a stress test scenario. If the extracted functional modules are an IO output module and a service integration module, the resulting test scenario is that the interfaces under the IO output module and the interfaces under the service integration module run continuously during the stress test time T. Interfaces under the IO output module include RS485 data transmission interfaces, Wiegand input / output interfaces, USB input / output interfaces, etc.; interfaces under the service integration module include MQTT transmission interfaces, HTTP data transmission interfaces, Websocket data transmission interfaces, etc. This example only lists stress test scenarios where two functional modules are selected and combined; the resulting stress test scenarios are not listed individually. This embodiment can automatically generate a stress test environment, eliminating the need for frequent manual parameter adjustments and switching of the running mode during stress testing, saving manpower and improving testing efficiency.

[0069] As for Figure 1Further description of the corresponding embodiment: After determining the stress test scenario, the stress test can be implemented in the following way: determine the test parameters of the stress test scenario, and determine the test duration based on the test parameters; wherein, the test parameters include the version of the target software and / or the number of functional modules included in the stress test scenario; perform a stress test on the target software for the specified test duration under the stress test scenario. The test duration can be determined based on the version of the target software or the number of functional modules. The more important the version of the target software (e.g., the main version is more important than the temporary version), the longer the test time; the more functional modules included in the stress test scenario, the longer the test time. When the test parameters include the number of functional modules, the test duration can be calculated according to a preset formula; wherein, the test duration is positively correlated with the number of functional modules.

[0070] For example, the above-mentioned preset formula can be: T = α version ×t×M, T is the test duration, α version The coefficient (α) corresponding to the version of the target software. version >0, and α version The size of the module is positively correlated with the importance of the version, t is the stress test unit time (e.g., it can be 10 seconds), and M is the number of functional modules.

[0071] In software testing, the stress test duration T varies depending on the software version and functional modules. The duration T is related to the number of functional modules used in the stress test: T = t × M, where t represents the stress test unit time and M represents the number of functional modules extracted from all functional modules. There are four types of software versions: mainline versions with significant overall functional modifications, iterative official versions with minor modifications to the mainline version, temporary versions meeting specific customer needs, and feature versions with significant modifications to a particular module. Regarding the stress test time requirements for different versions, the mainline and official versions have a wider application scope and higher importance; therefore, the stress test unit time for these versions is set to 120 minutes. Temporary and feature versions are implemented after the mainline and official versions have passed testing, with only minor functional modifications; therefore, the stress test unit time for temporary and feature versions can be set to 80 minutes.

[0072] The scope of functional modules tested during stress testing varies depending on the version type. There are two scenarios: For official and mainline versions, which have a wider range of functionalities and require testing of all modules; and for temporary and feature versions, which only modify some functionalities, stress testing is only needed on the modules affected by the modifications. In the first scenario, a stress test iterates through all functional modules. The list of functional modules obtained is [F1, F2, ..., FN]. All functional modules and their interfaces are tested together; the stress test unit time for this combined test is 120 minutes. In the second scenario, a stress test is performed on only some functional modules. The list of functional modules obtained is [F1, ..., Fh], where 0 ≤ h ≤ N, and F1 to Fh represent the functional modules to be tested. If there is only one functional module, then h = 0. In this case, the parameter M is generated sequentially from [1, h], and the stress test unit time for this combined test can be 80 minutes. This embodiment employs different strategies and non-fixed stress test scenarios to perform tests based on the nature of the task and testing requirements, thus providing greater flexibility.

[0073] After determining the stress test scenarios and the corresponding stress test time for each scenario, these stress test scenarios can be assigned to the corresponding stress test devices, and then the stress test devices will perform stress tests according to the corresponding stress test scenarios.

[0074] Software testing typically includes a restart mechanism to ensure that abnormal situations such as software crashes can be resolved by restarting. However, stress testing aims to fully identify and expose problems. Therefore, before performing stress testing on the target software in each scenario, the restart mechanism can be disabled to prevent restarting after a software crash (i.e., a freeze). The restart mechanism is a mechanism by which monitoring software restarts the target software after detecting a crash. Stress testing aims to verify the stability of the version's functionality through long-term operation; therefore, this solution records the device's operating status during stress testing. Thus, the solution requires recording stress testing logs for each device. Log information includes, but is not limited to, execution time, execution interface, CPU status, memory status, and interface response status. During or after stress testing, testers can access the log information to understand the device's stress testing results. This embodiment records the stress testing status and results of each device through operating logs to assist in verifying the stability of the software version's functionality. Once the execution order of the functional modules and each interface is determined, interface testing techniques are required. The programming languages ​​used for this implementation include, but are not limited to, Python and Java.

[0075] The above embodiments enable the identification of more problems in stress testing. By randomly combining elements, they simulate as many random operations as possible from real-world scenarios, overcoming the limitations of fixed stress testing scenarios and expanding the scope and weight of random testing. This is more conducive to discovering performance issues during software stress testing. In existing face recognition software stress testing, the software versions operate with limited functionality. This solution, through continuous functional combinations, allows the software versions to operate with a wider range and greater flexibility during stress testing.

[0076] Please see Figure 5 , Figure 5 This is a schematic diagram of a stress test device provided in an embodiment of this application. The device may include:

[0077] Information determination module 501 is used to determine the functional modules of the target software and the interfaces included in the functional modules;

[0078] The scene generation module 502 is used to arrange and combine the functional modules and the interfaces to obtain multiple stress test scenarios;

[0079] The test module 503 is used to perform a stress test on the target software in each of the stress test scenarios.

[0080] This embodiment identifies the functional modules of the target software and the interfaces contained in each functional module. By arranging and combining the functional modules and interfaces, multiple stress test scenarios for the target software can be obtained. Stress tests are then performed on the target software under each stress test scenario. In the above process, stress test scenarios can be obtained by arranging and combining functional modules and interfaces without manual configuration. This solution can simulate as many random operations as possible by real-world personnel, overcoming the limitations of fixed stress test scenarios and expanding the scope and proportion of random testing. Therefore, this solution can efficiently and comprehensively perform stress tests on software.

[0081] Furthermore, the scene generation module 502 includes:

[0082] A module selection unit is used to select multiple target functional modules from all the aforementioned functional modules;

[0083] An interface selection module is used to select multiple target interfaces from the interfaces included in each target functional module, and sort the target interfaces to obtain the interface execution order.

[0084] The combination unit is used to generate the stress test scenario according to the selected target functional module and the execution order of the corresponding interface of the target functional module.

[0085] Furthermore, the module selection unit is used to determine the number M of modules to be selected; where 1≤M≤N, and N is the number of all the functional modules; it is also used to select M functional modules from all the functional modules as the target functional modules;

[0086] Correspondingly, the interface selection module is used to determine the number m of interfaces corresponding to each target functional module; where 1≤m≤n, and n is the total number of interfaces contained in the target functional module; it is also used to select m interfaces as target interfaces from all interfaces of the target functional module, and arrange the target interfaces to obtain the interface execution order.

[0087] Furthermore, it also includes:

[0088] The judgment module is used to determine whether all stress test scenarios of the target software have been generated after generating the stress test scenarios according to the selected target functional modules and the execution order of the interfaces corresponding to the target functional modules; if not, then proceed to the step of selecting multiple target functional modules from all the functional modules.

[0089] Furthermore, test module 503 includes:

[0090] The duration determination unit is used to determine the test parameters of the stress test scenario and determine the test duration based on the test parameters; wherein, the test parameters include the version of the target software and / or the number of functional modules included in the stress test scenario;

[0091] An execution unit is used to perform a stress test on the target software for the specified test duration under the stress test scenario.

[0092] Furthermore, if the test parameters include the number of functional modules, the execution unit is used to calculate the test duration according to a preset formula; wherein the test duration is positively correlated with the number of functional modules.

[0093] Furthermore, it also includes:

[0094] The dead-and-reboot mechanism shutdown module is used to disable the dead-and-reboot mechanism before performing a stress test on the target software in each stress test scenario; wherein the dead-and-reboot mechanism is the mechanism by which the monitoring software restarts the target software after detecting that the target software has crashed.

[0095] Furthermore, the testing module 503 is used to determine the current batch of stress test scenarios; it is also used to distribute the current batch of stress test scenarios to multiple stress test devices so that the stress test devices can perform stress tests on the target software in the current batch of stress test scenarios; it is also used to determine whether the stress tests of all the stress test devices have been completed; if so, a new current batch of stress test scenarios is determined, and the step of distributing the current batch of stress test scenarios to multiple stress test devices is initiated.

[0096] Since the embodiments of the apparatus and the embodiments of the method correspond to each other, please refer to the description of the embodiments of the method for the embodiments of the apparatus, which will not be repeated here.

[0097] This application also provides a storage medium on which a computer program is stored, which, when executed, can perform the steps provided in the above embodiments. The storage medium may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0098] This application also provides an electronic device that may include a memory and a processor. The memory stores a computer program, and when the processor calls the computer program in the memory, it can implement the steps provided in the above embodiments. Of course, the electronic device may also include various network interfaces, power supplies, and other components.

[0099] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

[0100] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A stress test method, characterized in that, include: Identify the functional modules of the target software and the interfaces contained in those functional modules; Multiple stress test scenarios are obtained by arranging and combining the functional modules and the interfaces; Perform a stress test on the target software in each of the stress test scenarios; Specifically, performing a stress test on the target software in each stress test scenario includes: The test parameters for the stress test scenario are determined, and the test duration is determined based on the test parameters; wherein, the test parameters include the version of the target software and / or the number of functional modules included in the stress test scenario; the software test version is divided into four types: the main version with major modifications to the overall software functions, the official version with minor modifications to the main version and subsequent iterations, the temporary version to meet the special needs of certain customers, and the feature version with key modifications to a certain module in the software version; The stress test unit time and the scope of functional modules to be executed are set according to the type of software test version; wherein, stress test is performed on all functional modules of the official version and the main version, and stress test is performed on the modified functional modules of the temporary version and the feature version. Determine the stress test scenario for the current batch; The current batch of stress test scenarios is distributed to multiple stress test devices, so that the stress test devices can perform stress test on the target software for the specified duration in the current batch of stress test scenarios; the test duration is calculated according to a preset formula, the preset formula being T=α. version ×t×M,α version α represents the coefficient corresponding to the version of the target software. version >0, α version The size of M is positively correlated with the importance of the version, where t is the stress test unit time and M is the number of functional modules. Determine whether the stress test of all the aforementioned stress test devices has been completed; If so, determine the new current batch stress test scenario and proceed to the step of distributing the current batch stress test scenario to multiple stress test devices; Before performing a stress test on the target software in each stress test scenario, the method further includes: disabling the hang-up and restart mechanism; wherein, the hang-up and restart mechanism is a mechanism by which the monitoring software restarts the target software after detecting that the target software has crashed.

2. The stress test method according to claim 1, characterized in that, Multiple stress test scenarios are obtained by arranging and combining the functional modules and the interfaces, including: Select multiple target functional modules from all the aforementioned functional modules; Multiple target interfaces are selected from the interfaces included in each target functional module, and the target interfaces are sorted to obtain the interface execution order; The stress test scenario is generated based on the selected target functional module and the execution order of the corresponding interfaces of the target functional module.

3. The stress test method according to claim 2, characterized in that, Select multiple target functional modules from all the aforementioned functional modules, including: Determine the number of modules to be selected, M; where 1 ≤ M ≤ N, and N is the total number of all the functional modules. Select M functional modules from all the aforementioned functional modules as the target functional modules; Accordingly, multiple target interfaces are selected from the interfaces included in each target functional module, and the target interfaces are sorted to obtain the interface execution order, including: Determine the number of interfaces m corresponding to each target functional module; where 1≤m≤n, and n is the total number of interfaces contained in the target functional module; Select m interfaces from all interfaces of the target functional module as target interfaces, and arrange the target interfaces to obtain the interface execution order.

4. The stress test method according to claim 2, characterized in that, After generating the stress test scenario based on the selected target functional modules and the execution order of their corresponding interfaces, the process further includes: Determine whether all stress test scenarios for the target software have been generated; If not, proceed to the step of selecting multiple target functional modules from all the aforementioned functional modules.

5. A stress test device, characterized in that, include: An information determination module is used to determine the functional modules of the target software and the interfaces contained in the functional modules; The scenario generation module is used to arrange and combine the functional modules and the interfaces to obtain multiple stress test scenarios; The testing module is used to perform a stress test on the target software in each of the stress test scenarios. The testing module is used to determine the test parameters of the stress test scenario and determine the test duration based on the test parameters. The test parameters include the version of the target software and / or the number of functional modules included in the stress test scenario. The software test versions are divided into four types: a mainline version with significant modifications to the overall software functionality, an iterative official version with minor modifications to the mainline version, a temporary version to meet specific customer needs, and a feature version with significant modifications to a particular module. The stress test unit time and the scope of functional modules to be executed during the stress test are set according to the type of software test version. Stress testing is performed on all functional modules of the official version and the mainline version, and on the modified functional modules of the temporary version and the feature version. The testing module is configured to determine the current batch of stress test scenarios; distribute the current batch of stress test scenarios to multiple stress test devices, so that the stress test devices can perform stress tests on the target software for the specified duration under the current batch of stress test scenarios; and determine whether the stress tests on all stress test devices have been completed. If so, a new current batch of stress test scenarios is determined, and the process proceeds to the step of distributing the current batch of stress test scenarios to multiple stress test devices. The test duration is calculated according to a preset formula, where the preset formula is T = α. version ×t×M,α version α represents the coefficient corresponding to the version of the target software. version >0, α version The size of M is positively correlated with the importance of the version, where t is the stress test unit time and M is the number of functional modules. The dead-and-reboot mechanism shutdown module is used to disable the dead-and-reboot mechanism before performing a stress test on the target software in each stress test scenario; wherein the dead-and-reboot mechanism is the mechanism by which the monitoring software restarts the target software after detecting that the target software has crashed.

6. An electronic device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program, and the processor, when calling the computer program in the memory, implements the steps of the burn-in test method as described in any one of claims 1 to 4.

7. A storage medium, characterized in that, The storage medium stores computer-executable instructions, which, when loaded and executed by a processor, implement the steps of the stress test method as described in any one of claims 1 to 4.

Images