Software testing method, device, electronic device and storage medium

Abstract

The present invention provides a software testing method, device, electronic device, and storage medium, which relate to the field of software technology and are used to solve the technical problem of insufficient test module design in existing software testing. The method includes: receiving user input data of the tested software via a network; determining whether processing logic corresponding to each test scenario currently contained in the test module exists and can execute the user input data; if not, adding a test scenario corresponding to the user input data and processing logic corresponding to the added test scenario to the test module; inputting the user input data into the test module, and outputting a first expected output result after the user input data processing logic is executed; inputting the user input data into the tested software, and obtaining a corresponding first actual output result; comparing the first expected output result with the first actual output result to determine whether the test scenario triggered by the user input data passes the test.

Description

Technical Field

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

[0002] In the process of software development, software testing is an important means to ensure software quality and reliability, and it is also an important task in modern information engineering.

[0003] Although there are many mature theories and methods in software testing principles, testing methods and testing strategies that can provide a lot of guidance for testers, in the actual software testing process, testers often only complete software testing based on the established test plans, test cases or test tasks in the research and development stage. The testing basis is single and the accuracy is not high. If the design of the early test is insufficient and there is a lack of test scenarios, it is easy to lead to insufficient testing of the software being tested, which may affect the software quality.

[0004] After the software is released, users are the real users and testers of the software. How to test the released product and use the user input during use to feedback the design defects of the test module to the R&D and testing end are also technical issues that need to be solved. Summary of the Invention

[0005] The embodiment of the present invention provides a software testing method to solve the technical problem of insufficient test module design in existing software testing.

[0006] In a first aspect, an embodiment of the present invention provides a software testing method, comprising:

[0007] Receive user input data of the software under test through the network;

[0008] Determining whether there is processing logic capable of executing the user input data in the processing logic corresponding to each test scenario currently contained in the test module; wherein the test module pre-stores processing logic covering different test scenarios established according to the product requirements of the software under test;

[0009] If not, adding a test scenario corresponding to the user input data and processing logic corresponding to the newly added test scenario to the test module; inputting the user input data into the test module, and outputting a first expected output result after the user input data is executed by the newly added processing logic;

[0010] If it exists, and the test scenario corresponding to the user input data does not pass the test, then output the first expected output result after the user data is input into the test module and executed by the corresponding processing logic;

[0011] Inputting the user input data into the tested software to obtain a corresponding first actual output result;

[0012] Compare the first expected output result with the first actual output result to see whether they are consistent, and determine whether the test scenario triggered by the user input data passes the test.

[0013] The embodiment of the present invention is a test conducted after the software is released. While testing the software, the user input data during user use is used to mine defects in the test module, seamlessly connecting the defect monitoring of the test module with the testing process, improving the test module, and providing a technical solution to solve the shortcomings of the test module design in existing software testing.

[0014] In some embodiments, if a test scenario corresponding to the user input data exists in the test module and has passed the test, the user input data corresponding to the test scenario is discarded.

[0015] The technical solution of this embodiment determines whether a test is needed by judging whether the test scenario test corresponding to the user input data passes, thereby reducing unnecessary repetitive tests and improving test efficiency.

[0016] In some embodiments, the method further includes: determining whether there is an untested scenario in the test module;

[0017] When it is determined that the untested scenario exists, selecting test data corresponding to the untested scenario from a pre-established user input data set; wherein the user input data set is pre-stored with test data corresponding to triggering the different test scenarios;

[0018] Inputting the test data into the test module and the tested software respectively to obtain corresponding second expected output results and second actual output results respectively;

[0019] Comparing whether the second expected output result and the second actual output result are consistent, and determining whether the test scenario triggered by the test data passes;

[0020] Repeat the above steps until there are no untested scenarios in the test module.

[0021] The embodiment of the present invention is a test performed on a product after release. If the user input data test is incomplete, the corresponding data is selected from a pre-established user input set for supplementary testing. This can effectively prevent the occurrence of product omissions and can also effectively monitor the quality of the product during the user usage stage after release, thereby ensuring product quality.

[0022] In some embodiments, the test module includes a coverage mark corresponding to each test scenario; and further includes: marking the coverage marks corresponding to the test scenarios that have been triggered by the user input data and the test data;

[0023] Determining whether there are untested scenarios in the test module specifically includes:

[0024] Determine if there are any test scenarios that are not marked by the identified coverage.

[0025] The embodiment of the present invention adds a coverage mark in the test module. If the processing logic is triggered, the coverage mark is identified. This technical solution can effectively find the test scenarios that are not triggered in the test module, so as to facilitate the selection of test data corresponding to the untested scenarios from the pre-established user input data set.

[0026] In some embodiments, before the user input data is input into the test module, the expected output results corresponding to each test scenario in the test module are initialized;

[0027] Determining whether there are untested scenarios in the test module specifically includes:

[0028] Determine if there are test scenarios where the expected output is the initialization value.

[0029] This embodiment performs an initialization operation on the expected output result. When the test scenario in the test module is triggered, the corresponding expected output result is no longer the initialization value. The test scenario whose expected output result is the initialization value is the untested scenario. This technical solution provides another technical solution for finding the test scenario that is not triggered in the test module. In actual use, different technical solutions can be selected as needed.

[0030] In some embodiments, the method further includes: adding user input data corresponding to the newly added test scenario to the user input data set.

[0031] The embodiment of the present invention collects user input data of the tested software and improves the user input data set by utilizing the user's dynamic input. The processing method is flexible and the user input data set is improved more efficiently.

[0032] In some embodiments, it also includes: recording user input data, and performing user behavior analysis to obtain user behavior analysis results.

[0033] The embodiments of the present invention can perform different analyses on user behaviors according to different requirements to obtain the required analysis results and better improve the software under test.

[0034] In a second aspect, an embodiment of the present invention provides a software testing device, comprising:

[0035] An input unit, configured to receive user input data via a network;

[0036] A test module is used to determine whether there is processing logic that can execute the user input data in the processing logic corresponding to each test scenario included; wherein the test module pre-stores processing logic covering different test scenarios established according to the product requirements of the software under test; if not, a test scenario corresponding to the user input data and the processing logic corresponding to the newly added test scenario are added to the test module, and according to the input of the input unit, the first expected output result after the user input data is executed by the newly added processing logic is output; if it exists, and the test scenario corresponding to the user input data does not pass the test, according to the input of the input unit, the first expected output result after the user data is input into the test module and executed by the corresponding processing logic is output;

[0037] The judgment unit is used to input the user input data into the software under test to obtain the corresponding first actual output result; it is also used to compare whether the first expected output result is consistent with the first actual output result, and determine whether the test scenario triggered by the user input data passes the test.

[0038] In some embodiments, the apparatus further comprises:

[0039] A scenario testing unit, configured to determine whether there is an untested scenario in the test module;

[0040] When it is determined that the untested scenario exists, selecting test data corresponding to the untested scenario from a pre-established user input data set; wherein the user input data set pre-stores test data for triggering the different test scenarios; inputting the test data into the test module to obtain a corresponding second expected output result;

[0041] The judgment unit is further configured to input the user input data set into the software under test to obtain a corresponding second actual output result, and further configured to compare whether the second expected output result is consistent with the second actual output result to determine whether the test scenario triggered by the user input data set passes;

[0042] Repeat the above steps until there are no untested scenarios in the test module.

[0043] In some embodiments, the apparatus further comprises:

[0044] The data updating unit is used to add the user input data corresponding to the newly added test scenario to the user input data set.

[0045] In a third aspect, an embodiment of the present invention provides an electronic device, comprising a processor and a memory, wherein the processor is configured to implement the steps of any one of the methods described in the first aspect when executing a computer program stored in the memory.

[0046] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement the steps of any one of the methods described in the first aspect.

[0047] The technical effects brought about by the implementation methods of the second, third and fourth aspects can refer to the technical effects brought about by the corresponding implementation methods in the first aspect, and will not be repeated here.

[0048] The beneficial effects of the present invention are as follows:

[0049] The embodiment of the present invention is a test conducted after the software is released. While testing the software, the user input data during user use is used to mine defects in the test module, seamlessly connecting the defect monitoring of the test module with the testing process, improving the test module, and providing a technical solution to solve the shortcomings of the test module design in existing software testing. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0051] Figure 1 A flowchart of a software testing method provided by an embodiment of the present invention;

[0052] Figure 2 A flow chart of a method for determining whether a test module has missed a test provided by an embodiment of the present invention;

[0053] Figure 3 A user behavior analysis flow chart provided by an embodiment of the present invention;

[0054] Figure 4 A schematic structural diagram of a software testing device provided by an embodiment of the present invention;

[0055] Figure 5 A schematic structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0056] In order to enable ordinary persons in the art to better understand the technical solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings.

[0057] It should be noted that the terms "first," "second," and the like in the description and claims of the present invention and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of the present invention described herein can be implemented in sequences other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Instead, they are merely examples of apparatus and methods consistent with certain aspects of the present invention, as detailed in the appended claims.

[0058] The design concept of the present invention is described below.

[0059] An embodiment of the present invention provides a software testing method, such as Figure 1 As shown, the specific steps include:

[0060] S101, receiving user input data;

[0061] The data input by the user comes from the input data of the users who use the product after the product is released, or it can be a collection of user-input data as the input of the test.

[0062] S102: Determine whether there is processing logic capable of executing user input data in the processing logic corresponding to each test scenario currently included in the test module; wherein the test module pre-stores processing logic covering different test scenarios established according to product requirements of the software under test;

[0063] If yes, go to step S104, if no, go to step S103;

[0064] The test module is a logic module that processes various types of inputs according to the product requirements design specification during the product requirements design phase. The logical processing of each type of input has corresponding expected outputs. The test module includes processing logic corresponding to various test scenarios established according to the product requirements of the software being tested.

[0065] S103: If not, add a new test scenario corresponding to the user input data and a processing logic corresponding to the newly added test scenario in the test module;

[0066] If the test scenario is incomplete, that is, the test module has defects, it may be due to insufficient design that does not take the test scenario into consideration, or other reasons, such as the introduction of new test scenarios after the software under test is updated, which causes the test module to have no such test scenarios. Therefore, it is necessary to supplement the current test scenario during the test process and add new test scenarios corresponding to the user input data to improve the test, that is, to discover possible defects in the test module through user input to improve the test process.

[0067] S104. If yes, determine whether the test scenario corresponding to the user input data fails the test;

[0068] If yes, go to step S105, if no, go to step S112;

[0069] If there is a test scenario, it is necessary to determine whether the corresponding test scenario has passed the test. If it has not passed, it means that the expected output and the actual output during the previous test are inconsistent, and testing is required. At the same time, it also includes situations where the test scenario has not been tested and needs to be tested.

[0070] S105, inputting the user input data into the test module;

[0071] S106: Output a first expected output result;

[0072] If a new test scenario is added, the first expected output result after the newly added processing logic is executed is output; if a test scenario already exists, the first expected output result after the corresponding processing logic is directly output.

[0073] S107, inputting the user input data into the software under test;

[0074] The software under test can be any software to be tested.

[0075] S108, obtaining a corresponding first actual output result;

[0076] S109: Compare the first expected output result and the first actual output result to see whether they are consistent;

[0077] If yes, go to step S110, if no, go to step S111;

[0078] S110: If they are consistent, the test scenario triggered by the user input data passes the test;

[0079] If they are consistent, it means that the first expected output result of the current test scenario is consistent with the first actual output result, and the test scenario passes.

[0080] S111. If they are inconsistent, the test scenario triggered by the user input data fails.

[0081] Inconsistency indicates that the first expected output result of the current test scenario is inconsistent with the first actual output result. The test scenario fails. If necessary, further analysis is required to determine the cause of the discrepancy.

[0082] The embodiment of the present invention is a test conducted after the software is released. While testing the software, the user input data during user use is used to mine defects in the test module, seamlessly connecting the defect monitoring of the test module with the testing process, improving the test module, and providing a technical solution to solve the shortcomings of the test module design in existing software testing.

[0083] Optionally, as one embodiment, if a test scenario corresponding to the user input data exists in the test module and has passed the test, the user input data corresponding to the test scenario is discarded.

[0084] like Figure 1 As shown, this embodiment omits descriptions of the same steps as the above embodiment, and only describes the contents that are different from the above embodiment;

[0085] S101, S102, and S104 are the same as the steps in the above embodiment;

[0086] S104, determining whether the test scenario corresponding to the user input data fails the test;

[0087] If yes, go to step S105, if no, go to step S112;

[0088] S112, discarding the user input data;

[0089] If there is a test scenario corresponding to the user input data in the test module and the test has passed, it means that the user input data has been tested and the test result is passed. Therefore, there is no need to input the user input data into the test module and perform a test comparison. The user input data can be directly discarded and the current process ends.

[0090] The technical solution of this embodiment determines whether a test is needed by judging whether the test scenario test corresponding to the user input data passes, thereby reducing unnecessary repetitive tests and improving test efficiency.

[0091] Optionally, as one embodiment, the present invention also provides a flow chart of a method for determining whether a test module has missed a test, such as Figure 2 As shown, the specific steps include:

[0092] S201, determining whether there is an untested scenario in the test module;

[0093] If yes, go to step S202, if no, go to step S208;

[0094] If there are untested scenarios, it means that the user data obtained by the tested software is not fully tested, that is, there are product omissions, and it is necessary to increase the input data of the corresponding test scenarios for supplementary testing.

[0095] S202: When it is determined that there is an untested scenario, selecting test data corresponding to the untested scenario from a pre-established user input data set; wherein the user input data set is pre-stored with test data corresponding to triggering different test scenarios;

[0096] The pre-established user input data set is a complete set of input data maintained in the early stage of the R&D test end. It is established based on certain test methods designed according to the requirements of the software being tested, such as equivalence class division, boundary value coverage method, etc. The data in it can cover all test scenarios of the requirement design.

[0097] S203, inputting the test data into the test module;

[0098] S204, obtaining a second expected output result;

[0099] S205, inputting the test data into the software under test;

[0100] S206, obtaining a second actual output result;

[0101] S207: Compare the second expected output result and the second actual output result to see whether they are consistent, and determine whether the test scenario triggered by the test data passes;

[0102] S208. Repeat steps S201-S207 until there are no untested scenarios in the test module, and then end the process.

[0103] The embodiment of the present invention is a test performed on a product after release. If the user input data test is incomplete, the corresponding data is selected from a pre-established user input set for supplementary testing. This can effectively prevent the occurrence of product omissions and can also effectively monitor the quality of the product during the user usage stage after release, thereby ensuring product quality.

[0104] Optionally, as one embodiment, the test module includes a coverage mark corresponding to each test scenario; and further includes:

[0105] Identify the coverage marks corresponding to the test scenarios that have been triggered by user input data and test data;

[0106] Determine whether there are untested scenarios in the test module, including:

[0107] Determine if there are any test scenarios that are not marked by the identified coverage.

[0108] The following is a specific application example:

[0109] Assume that product function module X has M input data and N test scenarios. Then the corresponding test module X has N expected outputs and N coverage marks. The following is a schematic description in the form of partial code, where the characters after / / are used to explain the current code.

[0110] The specific description is as follows:

[0111]

[0112] As can be seen from the above example, each processing logic contained in the test module has a corresponding coverage mark. If the input data triggers a test scenario, the untested scenario can be found by marking the coverage mark. If the scenario is not triggered, the coverage mark is not marked.

[0113] This embodiment adds a coverage mark in the test module. If the test scenario is triggered, the coverage mark is identified. This technical solution can effectively find the test scenarios that are not triggered in the test module, so as to facilitate the selection of test data corresponding to the untested scenarios from the pre-established user input data set.

[0114] Optionally, as one embodiment, before inputting the user input data into the test module, the expected output results corresponding to each test scenario in the test module are initialized;

[0115] Determine whether there are untested scenarios in the test module, including:

[0116] Determine if there are test scenarios where the expected output is the initialization value.

[0117] Also taking the above example as an example, the code part can be found in the above embodiment and will not be repeated here.

[0118] If the coverage mark is canceled, the expected output results corresponding to each test scenario in the test module X are initialized before testing, that is, predictOut1...N are initialized, usually Null initialization is performed as follows:

[0119] predictOut1 = Null;

[0120] PredictOut2 = Null;

[0121] …

[0122] PredictOutN = Null;

[0123] When the tested scenario is triggered, the expected output result of the corresponding scenario will change. For example, when the test scenario of condition 1 is triggered, the corresponding expected output result predictOut1 is the pOut1 value instead of Null. Therefore, in this way, untested scenarios can be found.

[0124] This embodiment performs an initialization operation on the expected output result. When the test scenario in the test module is triggered, the corresponding expected output result is no longer the initialization value. The test scenario whose expected output result is the initialization value is the untested scenario. This technical solution provides another technical solution for finding the test scenario that is not triggered in the test module. In actual use, different technical solutions can be selected as needed.

[0125] Optionally, as one embodiment, the method further includes: adding user input data corresponding to the newly added test scenario to the user input data set.

[0126] The embodiment of the present invention collects user input data of the tested software and improves the user input data set by utilizing the user's dynamic input. The processing method is flexible and the user input data set is improved more efficiently.

[0127] Optionally, as one embodiment, user input data is recorded, and user behavior analysis is performed to obtain user behavior analysis results.

[0128] The following is a specific application example:

[0129] Figure 3 A user behavior analysis flow chart provided in an embodiment of the present invention specifically includes the following steps:

[0130] S301, record user input data;

[0131] S302, data collation and classification;

[0132] It can be classified according to different scenarios, and different classification methods can be used according to analysis needs.

[0133] S303, analyzing input data;

[0134] S304, obtaining user high-frequency input data;

[0135] Different analyses can be performed according to different needs. Here, we take obtaining high-frequency user input data as an example. Of course, other data can also be analyzed. This is just an example.

[0136] S305: indexing high-frequency behaviors in the user input data set to increase the amount of data testing for high-frequency behaviors;

[0137] S306: Obtain and analyze high-frequency user behaviors;

[0138] S307. Further analyze the user's high-frequency behaviors and improve the relevant usage functions of the tested software;

[0139] The embodiment of the present invention records user input data and performs user behavior analysis to obtain user behavior analysis results, indexes high-frequency behaviors in the user input data set, increases the data test volume of high-frequency behaviors, and also focuses on high-frequency user behaviors, further analyzes high-frequency user behaviors, and improves the relevant usage functions of the software under test. The embodiment of the present invention can perform different analyses on user behaviors according to different needs to obtain the required analysis results and better improve the software under test.

[0140] Based on the same inventive concept, this embodiment provides a software testing device 400, which can be specifically seen in the attached Figure 4 ,include:

[0141] Input unit 401, used to receive user input data through the network;

[0142] The test module 402 is used to determine whether there is processing logic that can execute the user input data in the processing logic corresponding to each test scenario included; wherein the test module 402 pre-stores processing logic covering different test scenarios established according to the product requirements of the software under test; if not, a test scenario corresponding to the user input data and the processing logic corresponding to the newly added test scenario are added to the test module 402, and according to the input of the input unit 401, the first expected output result after the user input data is executed by the newly added processing logic is output; if it exists, and the test scenario corresponding to the user input data does not pass the test, according to the input of the input unit 401, the first expected output result after the user data is input into the test module 402 and executed by the corresponding processing logic is output;

[0143] The judgment unit 403 is used to input the user input data into the software under test to obtain the corresponding first actual output result; it is also used to compare whether the first expected output result is consistent with the first actual output result, and determine whether the test scenario triggered by the user input data passes the test.

[0144] Optionally, as one embodiment, the apparatus 400 further includes:

[0145] A scenario testing unit 404 is configured to determine whether there is an untested scenario in the testing module 402;

[0146] When it is determined that the untested scenario exists, selecting test data corresponding to the untested scenario from a pre-established user input data set; wherein the user input data set pre-stores test data for triggering the different test scenarios; inputting the test data into the testing module 402 to obtain a corresponding second expected output result;

[0147] The judgment unit 403 is also used to input the user input data set into the software under test to obtain a corresponding second actual output result, and is also used to compare whether the second expected output result is consistent with the second actual output result, and determine whether the test scenario triggered by the user input data set passes; repeat the above steps until there are no untested scenarios in the test module 402.

[0148] Optionally, as one embodiment, the apparatus 400 further includes a data updating unit 405, configured to add user input data corresponding to a newly added test scenario to the user input data set.

[0149] Based on the same inventive concept, this embodiment also provides an electronic device 500, as shown in the attached Figure 5 As shown, the electronic device 500 includes a processor 501 and a memory 502 , and the processor 501 is configured to implement the steps of any one of the methods in the above embodiments when executing a computer program stored in the memory 502 .

[0150] Based on the same inventive concept, this embodiment further provides a computer-readable storage medium on which computer program instructions are stored. When the computer program instructions are executed by a processor, the steps of any one of the methods in the above embodiments are implemented.

[0151] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0152] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0153] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0154] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0155] Obviously, those skilled in the art may make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A software testing method, characterized in that: include: Receive user input data of the software under test through the network; Determining whether there is processing logic capable of executing the user input data in the processing logic corresponding to each test scenario currently included in the test module; wherein the test module pre-stores processing logic covering different test scenarios established according to the product requirements of the software under test; If not, adding a test scenario corresponding to the user input data and processing logic corresponding to the newly added test scenario to the test module; inputting the user input data into the test module, and outputting a first expected output result after the user input data is executed by the newly added processing logic; If it exists, and the test scenario corresponding to the user input data does not pass the test, then output the first expected output result after the user data is input into the test module and executed by the corresponding processing logic; Inputting the user input data into the tested software to obtain a corresponding first actual output result; Compare the first expected output result with the first actual output result to see whether they are consistent, and determine whether the test scenario triggered by the user input data passes the test.

2. The method according to claim 1, characterized in that Also includes: If a test scenario corresponding to the user input data exists in the test module and has passed the test, the user input data corresponding to the test scenario is discarded.

3. The method according to any one of claims 1-2, characterized in that Also includes: Determining whether there is an untested scenario in the test module; When it is determined that the untested scenario exists, selecting test data corresponding to the untested scenario from a pre-established user input data set; wherein the user input data set is pre-stored with test data corresponding to triggering the different test scenarios; Inputting the test data into the test module and the tested software respectively to obtain corresponding second expected output results and second actual output results respectively; Comparing whether the second expected output result and the second actual output result are consistent, and determining whether the test scenario triggered by the test data passes; Repeat the above steps until there are no untested scenarios in the test module.

4. The method according to claim 3, characterized in that The test module includes a coverage mark corresponding to each test scenario; and further includes: Marking coverage marks corresponding to test scenarios that have been triggered by the user input data and the test data; Determining whether there are untested scenarios in the test module specifically includes: Determine if there are any test scenarios that are not marked by the identified coverage.

5. The method according to claim 3, characterized in that Before inputting the user input data into the test module, initializing the expected output results corresponding to each test scenario in the test module; Determining whether there are untested scenarios in the test module specifically includes: Determine if there are test scenarios where the expected output is the initialization value.

6. The method according to claim 3, characterized in that Also includes: The user input data corresponding to the newly added test scenario is added to the user input data set.

7. The method according to any one of claims 1-2, 4-6, characterized in that: Also includes: Record user input data, perform user behavior analysis, and obtain user behavior analysis results.

8. A software testing device, characterized in that: The device comprises: An input unit, configured to receive user input data via a network; A test module is used to determine whether there is processing logic that can execute the user input data in the processing logic corresponding to each test scenario included; wherein the test module pre-stores processing logic covering different test scenarios established according to the product requirements of the software under test; if not, a test scenario corresponding to the user input data and the processing logic corresponding to the newly added test scenario are added to the test module, and according to the input of the input unit, the first expected output result after the user input data is executed by the newly added processing logic is output; if it exists, and the test scenario corresponding to the user input data does not pass the test, according to the input of the input unit, the first expected output result after the user data is input into the test module and executed by the corresponding processing logic is output; The judgment unit is used to input the user input data into the software under test to obtain the corresponding first actual output result; it is also used to compare whether the first expected output result is consistent with the first actual output result, and determine whether the test scenario triggered by the user input data passes the test.

9. The device according to claim 8, characterized in that The device further comprises: A scenario testing unit, configured to determine whether there is an untested scenario in the test module; When it is determined that the untested scenario exists, selecting test data corresponding to the untested scenario from a pre-established user input data set; wherein the user input data set pre-stores test data for triggering the different test scenarios; inputting the test data into the test module to obtain a corresponding second expected output result; The judgment unit is further configured to input the user input data set into the software under test to obtain a corresponding second actual output result, and further configured to compare whether the second expected output result is consistent with the second actual output result to determine whether the test scenario triggered by the user input data set passes; Repeat the above steps until there are no untested scenarios in the test module.

10. The device according to claim 9, characterized in that The device further comprises: The data updating unit is used to add the user input data corresponding to the newly added test scenario to the user input data set.

11. An electronic device, characterized in that: The electronic device includes a processor and a memory, and the processor is configured to implement the steps of the method according to any one of claims 1 to 7 when executing a computer program stored in the memory.

12. A computer-readable storage medium having computer program instructions stored thereon, characterized in that: When the computer program instructions are executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images