A method, system and device for automatically testing software update files

Abstract

The present application discloses a method, system and device for automatically testing software update files, which are used to automatically test software update files to be released. The present application method includes: deploying and enabling a listening state, the listening state is used to listen to update requirements; when the update requirements are listened to, the listening state is interrupted; an update file is generated according to the update requirements, the update file includes multiple recipe files; the target software is determined through the update file, and the target software is updated; the user usage environment is simulated according to the multiple recipe files; the target software is tested according to the user usage environment and the first recipe file; when the test time of the software test is longer than the preset time, the recipe file is switched until the multiple recipe files complete the software test and generate a test report.

Description

Technical Field

[0001] The present application relates to the field of data processing, and in particular to a method, system and device for automatically testing software update files. Background Art

[0002] In the current software development involving artificial intelligence algorithms and machine vision algorithms, the construction and update stability and accuracy of algorithm libraries and algorithm recipes are crucial. These updates may include the introduction of new algorithms, optimization or repair of existing algorithms, construction of new recipes or optimization of existing recipes, etc. In order to ensure that these updates can be stably used in the user's actual production applications, testing and verification are usually required. However, manual testing and verification work is time-consuming and error-prone, and may not be in line with the user's actual production process.

[0003] In existing technologies, manual intervention is usually the main method. After updating the algorithm library or algorithm formula, developers need to manually download the update package and call the corresponding dependent reference items, manually deploy the test environment and test cases, and manually repeat the running and analysis of test results. This mode of manual intervention is not only inefficient, but also easily affected by human factors, resulting in incomplete testing or deviation.

[0004] The existing technologies in this field have the following major problems: First, the manual testing process is cumbersome and time-consuming, and requires experienced operators, which increases development costs and labor intensity. Second, the algorithm library is updated frequently, and the manual intervention test mode cannot respond in time, and it is easy to make omissions, resulting in the release of the updated algorithm library without testing, which greatly reduces the stability of the software system. Finally, the existing testing methods cannot systematically manually and analyze test data, and thus cannot provide valuable references for subsequent updates. Therefore, the existing technology has obvious limitations in ensuring reliability and stability after updates. Summary of the invention

[0005] In order to solve the above technical problems, the present application provides a method, system and device for automatically testing software update files to be released.

[0006] The technical solution provided in this application is described below:

[0007] The first aspect of the present application provides a method for automatically testing a software update file, comprising:

[0008] Deploy and enable the monitoring state, which is used to monitor update requirements;

[0009] When an update request is detected, the monitoring state is interrupted;

[0010] Generate an update file according to update requirements, the update file includes multiple recipe files;

[0011] Determine the target software through the update file, and update the target software;

[0012] Simulate user usage environment based on multiple recipe files;

[0013] Performing software testing on the target software according to the user usage environment and the first recipe file;

[0014] When the test duration of the software test is longer than the preset duration, the recipe file is switched until multiple recipe files complete the software test and generate a test report.

[0015] Optionally, software testing is performed on the target software according to the user usage environment and the first recipe file, including:

[0016] Get a first recipe file from multiple recipe files;

[0017] Initialize a first recipe instruction according to a first recipe file;

[0018] Activate the simulated user operation module;

[0019] The simulated user operation module is controlled to execute the first recipe instruction on the target software.

[0020] Optionally, when the test duration of the software test is longer than a preset duration, the recipe file is switched until multiple recipe files complete the software test and a test report is generated, including:

[0021] Get the test duration through the timer;

[0022] When the test duration is greater than the preset duration, a second recipe file is obtained from the multiple recipe files, and a second recipe instruction is generated according to the second recipe file;

[0023] Controlling the simulated user operation module to execute the second recipe instruction on the target software;

[0024] When the second recipe instruction is the last untested recipe file among the multiple recipe files, a test report is generated.

[0025] Optionally, after simulating the user usage environment according to the multiple recipe files, the method further includes:

[0026] Get the preset duration and start the timer.

[0027] Optionally, before generating an update file according to the update requirement, the update file including the algorithm library and the plurality of recipe files, the method further comprises:

[0028] Determine whether the update requirements have been tested;

[0029] If yes, re-enter the monitoring state.

[0030] Optionally, when the test duration of the software test is longer than a preset duration, the recipe file is switched until multiple recipe files complete the software test and generate a test report, the method further includes:

[0031] Package the update requirements into an update file and publish the update file;

[0032] Restart the monitoring state.

[0033] Optionally, the update file also includes an algorithm library, and before determining the target software through the update file and updating the target software, the method further includes:

[0034] The algorithm library is deployed to the target software so that the stability of the newly added algorithms in the algorithm library can be tested when the target software is tested.

[0035] A second aspect of the present application provides a system for automatically testing software update files, comprising:

[0036] A first monitoring unit is used to deploy and enable a monitoring state, where the monitoring state is used to monitor update requirements;

[0037] An interrupt unit is used to interrupt the monitoring state when an update requirement is detected;

[0038] A generating unit, used for generating an update file according to an update requirement, wherein the update file includes a plurality of recipe files;

[0039] A determination unit, used to determine the target software through the update file and update the target software;

[0040] A simulation unit, used to simulate a user usage environment according to a plurality of recipe files;

[0041] A first testing unit, used to perform software testing on the target software according to the user usage environment and the first recipe file;

[0042] The second testing unit is used to switch the recipe file when the test duration of the software test is greater than a preset duration, until the software test is completed with multiple recipe files, and a test report is generated.

[0043] Optionally, the first test unit is specifically used for:

[0044] Get a first recipe file from multiple recipe files;

[0045] Initialize a first recipe instruction according to a first recipe file;

[0046] Activate the simulated user operation module;

[0047] The simulated user operation module is controlled to execute the first recipe instruction on the target software.

[0048] Optionally, the second test unit is specifically used for:

[0049] Get the test duration through the timer;

[0050] When the test duration is greater than the preset duration, a second recipe file is obtained from the multiple recipe files, and a second recipe instruction is generated according to the second recipe file;

[0051] Controlling the simulated user operation module to execute the second recipe instruction on the target software;

[0052] When the second recipe instruction is the last untested recipe file among the multiple recipe files, a test report is generated.

[0053] Optionally, the system further includes:

[0054] The acquisition unit is used to acquire the preset duration and start the timer.

[0055] Optionally, the system further includes:

[0056] A judgment unit, used to judge whether the update requirement has been tested;

[0057] The second monitoring unit is used to re-enter the monitoring state when the judgment result of the judgment unit is yes.

[0058] Optionally, the system further includes:

[0059] The release unit is used to package the update requirements into update files and release the update files;

[0060] The third monitoring unit is used to restart the monitoring state.

[0061] Optionally, the update file also includes an algorithm library, and the system also includes:

[0062] The deployment unit is used to deploy the algorithm library to the target software so that the stability of the newly added algorithms in the algorithm library can be tested when the target software is tested.

[0063] A third aspect of the present application provides a device for automatically testing a software update file, the device comprising:

[0064] Processor, memory, input-output unit, and bus;

[0065] The processor is connected to the memory, the input and output unit, and the bus;

[0066] The memory stores a program, and the processor calls the program to execute the first aspect and any optional method in the first aspect.

[0067] A fourth aspect of the present application provides a computer-readable storage medium, on which a program is stored. When the program is executed on a computer, the program executes the first aspect and any optional method in the first aspect.

[0068] It can be seen from the above technical solutions that this application has the following advantages:

[0069] Update requirements are monitored by deploying a monitoring state. When update requirements are monitored, update files are generated according to the update requirements. The updated software is tested by simulating user operations through the recipe files in the update files, so that the update file testing of the software update can be automatically performed. BRIEF DESCRIPTION OF THE DRAWINGS

[0070] In order to more clearly illustrate the technical solution in the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0071] Figure 1 A flowchart of an embodiment of the method for automatically testing software update files in the present application;

[0072] Figure 2a A flowchart of an embodiment of the first stage of the method for automatic testing of software update files in the present application;

[0073] Figure 2b A flowchart of an embodiment of the second stage of the method for automatic testing of software update files in the present application;

[0074] Figure 3 A schematic diagram of the structure of an embodiment of a system for automatic testing of software update files in this application;

[0075] Figure 4 A schematic diagram of another embodiment of the system for automatically testing software update files in the present application;

[0076] Figure 5 A schematic diagram of the structure of an embodiment of a device for automatically testing software update files in the present application. DETAILED DESCRIPTION

[0077] It should be noted that the method for automatically testing software update files provided in this application can be applied to a terminal, a system, or a server. For example, the terminal can be a smart phone or a computer, a tablet computer, a smart TV, a smart watch, a portable computer terminal, or a fixed terminal such as a desktop computer. For the convenience of explanation, this application uses a terminal as an example for explanation.

[0078] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0079] See also Figure 1 The present application first provides an embodiment of a method for automatically testing software update files, the embodiment comprising:

[0080] S101, deploy and enable the monitoring state, the monitoring state is used to monitor update requirements;

[0081] The deployment method of the monitoring state is to use the FileSystemWatcher class to monitor changes in the file system under the specified path.

[0082] For example, watcher is an instance of FileSystemWatcher. The path property in watcher is used to specify the file path to be monitored. The Filter property refers to the file filter, which only monitors the required file types. The NotifyFilter notification filter property regulates the activity type to be monitored. Created monitors the subscription event and binds the monitoring to the method to be called after the update. Then, when the property EnableRaisingEvents is set to true, it means that FileSystemWatcher starts working, starts monitoring the update activities, responds to the update in real time and takes responsive actions. That is, it monitors the update requirements.

[0083] S102, when an update requirement is detected, interrupt the monitoring state;

[0084] Specifically, after the terminal determines that there is a need to update the software, the monitoring state is controlled to be interrupted until the update test is completed.

[0085] In actual situations, stability testing of software updates is a long-term repetitive task, that is, continuously repeating a certain operation to determine the stability of the software for this operation. Therefore, it will be occupied when performing update testing. In actual situations, in order to determine the reliability of the test, a terminal will only perform one test task at a time, and the next test task can only be performed after the current test task is completed.

[0086] S103, generating an update file according to the update requirement, the update file including a plurality of recipe files;

[0087] The recipe file is used to simulate user operations, wherein the content of the recipe file includes at least: algorithm parameters, configuration settings, data processing rules, user interface definitions, business logic and dependencies.

[0088] The recipe file is used to preset user usage, and its generation process is as follows:

[0089] First, set the cycle time. Generally, the unit of the cycle time is hours. Second, add simulated user operation instructions, which include but are not limited to: add an import image folder instruction, traverse the folder images and add them to the corresponding nodes. Then, add test monitoring instructions, which include but are not limited to: add a single-step sequential execution operator instruction and add a judgment node execution status instruction. Finally, add an output result instruction to compare the output result data.

[0090] Multiple recipe files mean that one update test needs to perform tests of multiple operations, and the number of test operations is the same as the number of recipe files.

[0091] In actual situations, the update requirement can index all project files used for the update, and these project files include at least software update content and a recipe file, wherein the software update content is used to deploy the test environment, and the recipe file is used to simulate user operations.

[0092] S104, determining the target software through the update file, and updating the target software;

[0093] In actual situations, more than one software is installed in a terminal. Therefore, after determining that an update requirement has been generated, the terminal needs to determine the target software based on the update requirement. Specifically, the update requirement carries the software tag corresponding to the software that needs to be updated. When the update file is generated, the software tag and related current version information will be generated in the update file accordingly, so that the terminal determines the target software based on the software tag.

[0094] After the terminal determines the target software, it will update the data of the target software. After the update is completed, the software client will be opened to prepare for subsequent testing.

[0095] S105, simulating a user usage environment according to a plurality of recipe files;

[0096] The user usage environment is used to simulate user operations to perform operational tests on the updated target software. The content carried in the recipe file is the script instructions that simulate user operations. When there are multiple recipe files, the terminal will read the recipe files one by one, and simulate the user operations corresponding to the recipe files in a loop within a preset time period to ensure the stability of the updated target software when performing the same operations.

[0097] In actual situations, the user's usage environment will cause the operation of peripheral drivers to dynamically affect the parameters of the CPU and memory. At the same time, when simulating some specific terminal environments, the switching of the target software between the foreground and the background will require the target software to refresh the UI. The terminal will simulate the running status of the target software based on these situations, that is, change the CPU and memory parameters or refresh the UI of the target software through script instructions.

[0098] S106, performing software testing on the target software according to the user usage environment and the first recipe file;

[0099] After determining that the terminal opens the target software client and enters the user environment, the contents of the recipe files are read one by one according to the actual order of the multiple recipe files, that is, the first recipe file is obtained. It should be noted that the first recipe file described here refers to the first recipe file obtained by the terminal from the multiple recipe files according to the actual order.

[0100] S107, when the test duration of the software test is longer than the preset duration, the recipe file is switched until the software test is completed with multiple recipe files, and a test report is generated.

[0101] In order to improve the reliability of the feedback obtained from the updated software test, after entering the test state, the terminal will continue to execute the instructions of a recipe file until the preset test time is met. Only if there is no abnormality in the target software process during the preset test time, the terminal will determine that after this update, the operations corresponding to the recipe file can be stably executed in the target software.

[0102] In actual situations, when executing software testing, the terminal will continuously monitor the operating status of the software. When an abnormal state of the target software process occurs, the abnormal state will be recorded in the log file. The log file is mainly used to obtain the number of times the target software client is started during software testing, so as to determine the stability of the target software when executing the corresponding operations of the recipe file.

[0103] When there are multiple recipe files, after completing the test of one recipe file, the terminal will automatically switch to the next recipe file to execute a new test task until all recipe files have completed the test.

[0104] This embodiment monitors update requirements by deploying a monitoring state, generates an update file based on the update requirement when an update requirement is monitored, and tests the updated software by simulating user operations through a recipe file in the update file, so that the update file testing of the software update can be performed automatically.

[0105] See also Figure 2a to Figure 2b , the present application embodiment provides another embodiment of the method for automatically testing software update files, the embodiment comprising:

[0106] S201, deploy and enable the monitoring state, the monitoring state is used to monitor update requirements;

[0107] S202, when an update requirement is detected, interrupt the monitoring state;

[0108] Steps S201 to S202 in this embodiment are similar to steps S101 to S102 in the aforementioned embodiment, and will not be described in detail here.

[0109] S203, determining whether the update requirement has been tested;

[0110] Ways for the terminal to determine whether the update requirement has been tested include, but are not limited to: determining through a log file generated by the test and determining through a version number of the target software.

[0111] Among them, each time the terminal performs an update test on the target software, a log file will be generated. The log file will carry the version information of the target software in this test, so that the terminal can determine the test status of the current update requirement through the test file.

[0112] In addition, the update requirement carries the software tag of the target software and the related current version information. The terminal will determine the version status of the target software in the current terminal based on the update requirement. When the version status of the target software is the same as the version information of the update requirement, the terminal determines that the update requirement has been tested and executes step S204. If the terminal determines that the update requirement has not been tested, it executes step S205.

[0113] S204: If yes, re-enter the monitoring state.

[0114] According to the above steps, after the terminal determines that there is a software update requirement, the monitoring state is interrupted until the update test is completed. Therefore, when the terminal determines that the update requirement has been tested, it proves that the target software has completed the update test, and the terminal reactivates the monitoring state and continues to monitor other update requirements.

[0115] S205, generating an update file according to the update requirement, the update file including a plurality of recipe files;

[0116] Step S205 in this embodiment is similar to step S103 in the above embodiment, and will not be described in detail here.

[0117] S206, determining the target software by updating the file, and deploying the algorithm library to the target software, so that the stability test of the newly added algorithm in the algorithm library is performed when the target software is tested.

[0118] The algorithm library is a predefined, optimized algorithm implementation, which is a collection of algorithm packages obtained by encapsulating the algorithm code through modular and reusable code component states. When updating the software, the algorithm library inevitably needs to be updated. Function optimization or function addition is generally implemented in the form of adding code. The addition of code means that the algorithm library needs to be updated synchronously to avoid the situation where the algorithm cannot find the calling basis.

[0119] In this embodiment, the terminal determines the update content of the software based on the monitored update requirements, that is, compares the actual code differences of the updated modules to determine the actual update content, and then can monitor the changes in the algorithm library and algorithm formula in the system in real time. The terminal can automatically detect the update activities and the updated algorithm library by monitoring the script and comparing the MD5 of the target library without manual intervention.

[0120] S207, determining the target software through the update file, and updating the target software;

[0121] S208, simulating a user usage environment according to a plurality of recipe files;

[0122] Steps S207 to S208 in this embodiment are similar to steps S104 to S105 in the aforementioned embodiment, and will not be described in detail here.

[0123] S209: Obtain a preset duration and start a timer.

[0124] Specifically, the preset duration is the preset cycle time obtained by the terminal, that is, the duration of the test required to be executed for each recipe file, that is, the test duration. Only when the test duration meets the preset duration, the terminal will test the next recipe file.

[0125] S210, obtaining a first recipe file from multiple recipe files;

[0126] According to the above steps, the recipe file is used to simulate user operations. In the case of multiple recipe files, the terminal will obtain these recipe files one by one and test these recipe files.

[0127] In actual situations, the recipe files are generally sorted according to naming rules or recipe file generation time, which is not specifically limited here.

[0128] S211, initializing a first recipe instruction according to a first recipe file;

[0129] After determining the recipe file that needs to be executed for this software test, the terminal will initialize the content of the recipe file to obtain the recipe instructions corresponding to the recipe file. The recipe instructions are instructions used to simulate user operations. The terminal will execute the process in the recipe file according to the read recipe instructions.

[0130] S212, activating the simulated user operation module;

[0131] The simulated user operation module is used to execute recipe instructions. In actual situations, the simulated user operation module needs to rely on the user usage environment to run, that is, when the simulated user operation module is activated, the terminal will enter the user usage environment. When entering the user usage environment, the terminal will actively start the client of the target software.

[0132] S213: Control the simulated user operation module to execute the first recipe instruction on the target software.

[0133] At this time, the terminal is already in the simulated user use environment, and enters the client of the target software. In this environment, the terminal executes the first recipe instruction by controlling the simulated user operation module, so that the software test is performed according to the first recipe instruction.

[0134] In actual situations, the content of recipe instructions includes actual action instructions and feedback generation instructions, wherein the actual action instructions are used to determine the actual actions simulating user operations, and the feedback generation instructions are used to provide conditions for generating feedback. Generally, the situation requiring immediate feedback is when the terminal determines that the stability of the software is unreliable when executing the recipe instructions. The purpose of generating feedback is to inform the operator of this situation so that the unreliable stability situation can be manually reviewed.

[0135] S214, obtaining the test duration through a timer;

[0136] Specifically, the test duration is obtained through a timer, and the timer is started when the terminal obtains the first recipe file. Each time the preset time is reached, the timer is reactivated and the test of the recipe file is terminated.

[0137] In this embodiment, when there are multiple recipe files in the terminal, the preset duration can be set by the recipe file itself. When the recipe file itself carries the expected test duration, the expected test duration is used as the preset duration to compare with the test duration obtained by the timer. If the recipe file itself does not carry the expected test duration data, the preset duration set in step S209 is directly used as the comparison value of the test duration.

[0138] S215, when the test duration is greater than the preset duration, obtaining a second recipe file from the plurality of recipe files, and generating a second recipe instruction according to the second recipe file;

[0139] The purpose of software testing is to ensure the operating stability of the target software after using the updated data. Therefore, the terminal's recipe file should simulate the state of users using a certain service for a long time. Therefore, the number of recipe files is related to the number of commonly used services.

[0140] The switching of recipe files is related to the test duration of the recipe files. When the test duration is greater than the preset duration, the terminal determines that the current recipe file has completed the test and switches to the next recipe file. At the same time, it determines the preset duration based on the data carried by the recipe file and starts testing the next recipe file. The aforementioned next recipe instruction is the second recipe file, which is the next recipe file obtained by the terminal after completing the current recipe instruction.

[0141] The second recipe file is initialized to obtain a second recipe instruction, so that the terminal can perform a software test simulating a user operation according to the second recipe instruction.

[0142] S216, controlling the simulated user operation module to execute the second recipe instruction on the target software;

[0143] Similar to step S213, after the terminal determines the second recipe instruction, it will simulate the user operation through the second recipe instruction in the established user usage environment to complete the test of the corresponding recipe file of the target software through the second recipe instruction.

[0144] S217: When the second recipe instruction is the last untested recipe file among the multiple recipe files, generate a test report.

[0145] After completing the test of the second recipe instruction, the terminal will obtain the next recipe file to generate a recipe instruction and repeat the aforementioned operation of performing software testing on the recipe file. However, when the recipe file corresponding to the second recipe instruction is the last recipe file among multiple recipe files, the terminal will generate a test report based on the instruction generated by the failure to obtain the new recipe file.

[0146] S218, packaging the update requirements into an update file, and publishing the update file;

[0147] In actual situations, if a major exception occurs during software testing, such as a crash in the test software process, the terminal will immediately generate a prompt to diagnose and repair the cause of the recipe file test failure through manual intervention, and then restart the software test of the corresponding configuration file. Therefore, if the terminal completes the test of all recipe files, it means that the update file corresponding to the update requirement of the current test can enable the target software to run stably after the data is updated, so the update file will be packaged and released.

[0148] S219: Restart the monitoring state.

[0149] Similar to step S204, after the terminal determines that there is a software update requirement, the monitoring state is controlled to be interrupted until the update test is completed. Therefore, when the terminal determines that the update file has been released for the update requirement and the test is completed, it proves that the target software has completed the update test, and the terminal reactivates the monitoring state and continues to monitor other update requirements.

[0150] In the embodiment of the present application, the content carried by the recipe file is used to simulate user operation actions in different environments, and the test duration is limited by a preset time. Only when the test process meets the test duration can it be said that the software update operation under this configuration is stable, thereby improving the stability of the results of the automatic test output of this application.

[0151] The above is a detailed description of the method for automatically testing software update files in the embodiment of the present application. The following is a detailed description of the system and device for automatically testing software update files.

[0152] See also Figure 3 The present application provides an embodiment of a system for automatically testing software update files, which includes:

[0153] The first monitoring unit 301 is used to deploy and enable a monitoring state, where the monitoring state is used to monitor update requirements;

[0154] The interruption unit 302 is used to interrupt the monitoring state when an update requirement is monitored;

[0155] A generating unit 303, used to generate an update file according to an update requirement, wherein the update file includes a plurality of recipe files;

[0156] The determination unit 304 is used to determine the target software through the update file and update the target software;

[0157] A simulation unit 305, used for simulating a user usage environment according to a plurality of recipe files;

[0158] A first testing unit 306, used to perform software testing on the target software according to the user usage environment and the first recipe file;

[0159] The second testing unit 307 is used to switch the recipe file when the test duration of the software test is greater than a preset duration, until multiple recipe files complete the software test and generate a test report.

[0160] In this embodiment, the functions of each unit are the same as those described above. Figure 1 The steps in the illustrated embodiments correspond to each other and will not be described again here.

[0161] See also Figure 4 The present application provides an embodiment of a system for automatically testing software update files, which includes:

[0162] A first monitoring unit 401 is used to deploy and enable a monitoring state, where the monitoring state is used to monitor update requirements;

[0163] The interruption unit 402 is used to interrupt the monitoring state when an update requirement is monitored;

[0164] A determination unit 403 is used to determine whether the update requirement has been tested;

[0165] The second monitoring unit 404 is used to re-enter the monitoring state when the judgment result of the judgment unit is yes.

[0166] A generating unit 405, used to generate an update file according to the update requirement, the update file including an algorithm library and a plurality of recipe files;

[0167] The deployment unit 406 is used to deploy the algorithm library to the target software so that the stability test of the newly added algorithm in the algorithm library can be performed when the target software is tested.

[0168] The determination unit 407 is used to determine the target software through the update file and update the target software;

[0169] A simulation unit 408, used to simulate a user usage environment according to a plurality of recipe files;

[0170] The acquisition unit 409 is used to acquire a preset duration and start a timer.

[0171] A first testing unit 410, configured to perform software testing on the target software according to the user usage environment and the first recipe file;

[0172] The second testing unit 411 is used to switch the recipe file when the test duration of the software test is greater than a preset duration, until multiple recipe files complete the software test and generate a test report.

[0173] A publishing unit 412, used to package the update requirements into an update file and publish the update file;

[0174] The third monitoring unit 413 is used to restart the monitoring state.

[0175] Optionally, the first testing unit 410 is specifically used for:

[0176] Get a first recipe file from multiple recipe files;

[0177] Initialize a first recipe instruction according to a first recipe file;

[0178] Activate the simulated user operation module;

[0179] The simulated user operation module is controlled to execute the first recipe instruction on the target software.

[0180] Optionally, the second testing unit 411 is specifically used for:

[0181] Get the test duration through the timer;

[0182] When the test duration is greater than the preset duration, a second recipe file is obtained from the multiple recipe files, and a second recipe instruction is generated according to the second recipe file;

[0183] Controlling the simulated user operation module to execute the second recipe instruction on the target software;

[0184] When the second recipe instruction is the last untested recipe file among the multiple recipe files, a test report is generated.

[0185] In this embodiment, the functions of each unit are the same as those described above. Figure 2a to Figure 2b The steps in the illustrated embodiments correspond to each other and will not be described again here.

[0186] See also Figure 5 The present application embodiment provides another embodiment of a device for automatically testing software update files, including:

[0187] Processor 501, memory 502, input and output unit 503, bus 504;

[0188] The processor 501 is connected to the memory 502, the input and output unit 503 and the bus 504;

[0189] Processor 501 specifically executes Figure 1 , Figure 2a and Figure 2b The operations corresponding to the steps in the method are not described in detail here.

[0190] The present application also relates to a computer-readable storage medium on which a program is stored, wherein when the program is run on a computer, the computer is caused to execute any of the above methods.

[0191] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0192] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

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

[0194] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0195] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, read-only memory), random access memory (RAM, random access memory), disk or optical disk, etc. Various media that can store program codes.

Claims

1. A method for automatically testing software update files, characterized in that: The method comprises: Deploy and enable a listening state, where the listening state is used to listen for update requirements; When the update requirement is detected, the monitoring state is interrupted; Generate an update file according to the update requirement, wherein the update file includes an algorithm library and multiple recipe files; Determine the target software through the update file, update the target software, and after the update is completed, open the software client to prepare for subsequent testing; Simulating a user usage environment according to the multiple recipe files, the recipe files are used to simulate user operations, and the contents of the recipe files at least include: algorithm parameters, configuration settings, data processing rules, user interface definitions, business logic and dependencies; Performing software testing on the target software according to the user usage environment and the first recipe file; When the test duration of the software test is longer than a preset duration, switching the recipe files until the multiple recipe files complete the software test and generating a test report; The performing software testing on the target software according to the user usage environment and the first recipe file comprises: Acquire a first recipe file from the multiple recipe files; Initializing a first recipe instruction according to the first recipe file, where the recipe instruction is an instruction for simulating a user operation; Activate a simulated user operation module, the simulated user operation module is used to execute recipe instructions, and the simulated user operation module runs depending on the user usage environment; The simulated user operation module is controlled to execute the first recipe instruction on the target software.

2. The method according to claim 1, characterized in that When the test duration of the software test is longer than a preset duration, the recipe file is switched until the multiple recipe files complete the software test and a test report is generated, including: Get the test duration through the timer; When the test duration is greater than a preset duration, obtaining a second recipe file from the multiple recipe files, and generating a second recipe instruction according to the second recipe file; Controlling the simulated user operation module to execute the second recipe instruction on the target software; When the second recipe instruction is the last untested recipe file among the multiple recipe files, a test report is generated.

3. The method according to claim 1 or 2, characterized in that: After simulating the user usage environment according to the multiple recipe files, the method further includes: Get the preset duration and start the timer.

4. The method according to claim 1 or 2, characterized in that: Before generating an update file according to the update requirement, wherein the update file includes an algorithm library and a plurality of recipe files, the method further includes: Determining whether the update requirement has been tested; If yes, re-enter the monitoring state.

5. The method according to claim 1 or 2, characterized in that: When the test duration of the software test is longer than a preset duration, the recipe file is switched until the multiple recipe files complete the software test and generate a test report, the method further includes: Packaging the update requirements into an update file and publishing the update file; Restart the listening state.

6. The method according to claim 1 or 2, characterized in that: Before determining the target software through the update file and updating the target software, the method further includes: The algorithm library is deployed to the target software so that the stability test of the newly added algorithm in the algorithm library can be performed when the target software is tested.

7. A system for automatically testing software update files, characterized in that: The system comprises: A monitoring unit, used to deploy and enable a monitoring state, wherein the monitoring state is used to monitor update requirements; An interruption unit, configured to interrupt the monitoring state when the update requirement is detected; A generating unit, configured to generate an update file according to the update requirement, wherein the update file includes an algorithm library and a plurality of recipe files; A determination unit, used to determine the target software through the update file, and update the target software, and after the update is completed, open the software client to prepare for subsequent testing; A simulation unit, used to simulate a user usage environment according to the plurality of recipe files, wherein the recipe files are used to simulate user operations, and the contents of the recipe files at least include: algorithm parameters, configuration settings, data processing rules, user interface definitions, business logic, and dependencies; A first testing unit, configured to perform software testing on the target software according to the user usage environment and the first recipe file; A second testing unit, configured to switch recipe files when the test duration of the software test is longer than a preset duration, until the multiple recipe files complete the software test and generate a test report; The first test unit is specifically used for: Get a first recipe file from multiple recipe files; Initializing a first recipe instruction according to the first recipe file, where the recipe instruction is an instruction for simulating a user operation; Activate a simulated user operation module, the simulated user operation module is used to execute recipe instructions, and the simulated user operation module runs depending on the user usage environment; The simulated user operation module is controlled to execute the first recipe instruction on the target software.

8. A device for automatically testing software update files, characterized in that: The device comprises: Processor, memory, input-output unit, and bus; The processor is connected to the memory, the input and output unit, and the bus; The memory stores a program, and the processor calls the program to execute the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a program stored thereon, wherein the program, when executed on a computer, performs the method according to any one of claims 1 to 6.

Images