Software testing method and device based on probability model, equipment and storage medium

Abstract

Embodiments of the present disclosure provide a software testing method and device based on a probability model, equipment and a storage medium. The method comprises: obtaining at least two test operations corresponding to a to-be-tested interface, wherein the test operation is used to trigger a control in the to-be-tested interface; determining a target test operation according to a probability distribution model and the at least two test operations, wherein the probability distribution model is used to represent the probability distribution of interface components that can be covered after different test operations are executed, the probability distribution model is generated according to historical test data, and the target test operation is a test operation in the test operations, which has the largest coverage of a target interface component after being executed; and sending the target test operation to a testing machine to enable the testing machine to test the to-be-tested interface. Since the target test operation has the largest coverage of the target interface component after being executed, testing the to-be-tested interface based on the target test operation can improve the coverage effect of the test and improve the test efficiency and test effectiveness.

Description

TECHNICAL FIELD

[0001] Embodiments of the present disclosure relate to the field of computer software, and particularly relate to a software testing method and device based on a probability model, an apparatus, and a storage medium. BACKGROUND

[0002] Software testing in the software development process is an important link to ensure the quality of software programs. In the process of testing software, in the prior art, test cases can be automatically generated according to the characteristics of the software under test, and then the automatic generation of test cases is used to realize the automatic testing of software.

[0003] However, due to the complexity of software programs, the randomness of generating test cases in the prior art is large, and the selected test operations are often randomly selected, thus resulting in low test coverage. Multiple and long-time testing is required to meet the testing effect, resulting in low testing efficiency and poor effectiveness. SUMMARY

[0004] Embodiments of the present disclosure provide a software testing method and device based on a probability model, an apparatus, and a storage medium to overcome the problems of low testing efficiency and poor effectiveness in the software testing process.

[0005] In a first aspect, embodiments of the present disclosure provide a software testing method based on a probability model, comprising:

[0006] obtaining at least two test operations corresponding to a to-be-tested interface, wherein the test operations are used to trigger controls in the to-be-tested interface; determining a target test operation according to a probability distribution model and the at least two test operations, wherein the probability distribution model is used to represent the probability distribution of interface components that can be covered after different test operations are executed, the probability distribution model is generated according to historical test data, and the target test operation is a test operation in the test operations that has the largest coverage rate of a target interface component after being executed; and sending the target test operation to a testing machine to enable the testing machine to test the to-be-tested interface.

[0007] In a second aspect, embodiments of the present disclosure provide a software testing device based on a probability model, comprising:

[0008] an obtaining module configured to obtain at least two test operations corresponding to a to-be-tested interface, wherein the test operations are used to trigger controls in the to-be-tested interface;

[0009] determining a target test operation according to the probability distribution model and the at least two test operations, wherein the probability distribution model is used to represent a probability distribution of interface components that can be covered after different test operations are performed, the probability distribution model is generated according to historical test data, and the target test operation is a test operation in the test operations, coverage of a target interface component after which is the largest;

[0010] sending the target test operation to a test machine, so that the test machine tests the interface to be tested.

[0011] In a third aspect, an electronic device is provided, and the electronic device includes at least one processor and a memory.

[0012] The memory stores computer-executable instructions.

[0013] The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor performs the software testing method based on the probability model as described in the first aspect and various possible designs of the first aspect.

[0014] In a fourth aspect, a computer-readable storage medium is provided, and the computer-readable storage medium stores computer-executable instructions. When a processor executes the computer-executable instructions, the software testing method based on the probability model as described in the first aspect and various possible designs of the first aspect is implemented.

[0015] In a fifth aspect, a computer program product is provided, and the computer program product includes a computer program. When a processor executes the computer program, the software testing method based on the probability model as described in the first aspect and various possible designs of the first aspect is implemented.

[0016] The embodiment provided in the method, device, equipment and storage medium for software testing based on a probability model, at least two test operations corresponding to a to-be-tested interface are acquired, wherein the test operation is used to trigger a control in the to-be-tested interface; a target test operation is determined according to a probability distribution model and the at least two test operations, wherein the probability distribution model is used to represent a probability distribution of interface components that can be covered after different test operations are executed, the probability distribution model is generated according to historical test data, and the target test operation is a test operation in the test operations, which has the largest coverage rate of a target interface component after being executed; and the target test operation is sent to a test machine, so that the test machine tests the to-be-tested interface. Since the target test operation determined by the probability distribution model has the largest coverage rate of the target interface component after being executed, the target test operation is sent to the test machine, so that the test machine tests the to-be-tested interface according to the target test operation, the coverage effect of the test can be improved, and the test efficiency and test effectiveness can be improved. BRIEF DESCRIPTION OF DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are some embodiments of the present disclosure, and other drawings can be obtained by those skilled in the art without creative labor under the premise of the drawings.

[0018] Figure 1 An application scenario diagram of the method for software testing based on a probability model provided by the embodiment of the present disclosure is provided.

[0019] Figure 2 A flowchart of the method for software testing based on a probability model provided by the embodiment of the present disclosure is provided. Figure 1 ;

[0020] Figure 3 A schematic diagram of a test operation covering an interface component provided by the embodiment of the present disclosure is provided.

[0021] Figure 4 A flowchart of the method for software testing based on a probability model provided by the embodiment of the present disclosure is provided. Figure 1 ;

[0022] Figure 5 A structural block diagram of the device for software testing based on a probability model provided by the embodiment of the present disclosure is provided.

[0023] Figure 6 A structural diagram of an electronic device provided by the embodiment of the present disclosure is provided.

[0024] Figure 7This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

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

[0026] The application scenarios of the embodiments of this disclosure are explained below:

[0027] Figure 1 An application scenario diagram of the software testing method based on a probability model provided in this disclosure is shown, such as... Figure 1 As shown, the software testing method based on a probability model provided in this embodiment can be applied in automated testing scenarios. Specifically, the test server 11, after obtaining the interface to be tested sent by the terminal device 12, analyzes the interface to be tested based on the probability model, determines the test action that meets the test requirements, and sends the test action to the test machine 13 to generate corresponding test cases, execute the test, and generate test results to complete the test of the interface to be tested. Afterwards, the test machine 13 can send the test results to the terminal device 12 to complete the delivery of the test results, and or, the test machine 13 can send the test results to the test server 11 as sample data to update the data model stored in the test server 11 for testing.

[0028] In the related art, through model-based testing (MBT), automatic testing of software programs can be realized. The basic principle is: through some functional description of the system under test, a model of the system under test is constructed, and then test cases are generated according to the model or a part of the model for testing. However, due to the complexity of the software program itself, the randomness of generating test cases in the related art is large, and at the same time, due to the dynamic change of the pages in the software program according to the needs of the product, the corresponding model will also continue to expand, and it is difficult to reuse the experience of historical testing. Therefore, through the traditional model-based testing method, the selected test operation is often random, however, for software program testing, it is usually necessary to repeat the test with each version upgrade iteration, and through random test operation for testing, a large amount of repeated testing will be caused, and the functional unit that needs to be tested is ignored, or the functional unit that needs to be tested can be covered after multiple tests. Thus, the problems of low test efficiency and poor effectiveness are caused.

[0029] Therefore, there is an urgent need for a test method that can effectively utilize historical test data and improve test coverage to solve the above problems.

[0030] Figure 2 The software testing method based on the probability model provided by the embodiments of the present disclosure Figure 1 The method of the present embodiment can be applied in a test server or a terminal device. The present embodiment takes the test server as the execution subject of the method provided by the present embodiment to illustrate the software testing method based on the probability model, which includes the following steps.

[0031] S101: At least two test operations corresponding to a to-be-tested interface are acquired, wherein the test operation is used to trigger a control in the to-be-tested interface.

[0032] Exemplarily, the program to be tested is a mobile phone application (APP) for example, and the program to be tested is composed of multiple function interfaces capable of jumping to each other, wherein the interface to be tested is a function interface in the program to be tested, for example, a homepage, a search page, a video playing page, a user information page, and the like in the APP program. A control is arranged in the interface to be tested, and the control, after being triggered, performs a corresponding function. For example, a control corresponding to a "search button" performs a search function in the program and jumps to a "search result" page after being triggered. For another example, a control corresponding to a "video detail button" jumps to a "video detail" page after being triggered. The test operation is operation information for triggering the function of the control, and more specifically, the test operation can include coordinate information and an action type. The coordinate information is used to represent a screen coordinate, and the action type is, for example, clicking, sliding, and the like, so as to trigger the control at the screen coordinate position through the coordinate information and the action type. Further, the at least two test operations corresponding to the interface to be tested are obtained by obtaining the screen coordinates of the controls in the interface to be tested and the operation types of the controls, wherein the operation type represents a controllable manner of the control, for example, clicking, sliding, and the like, and the corresponding test operation is obtained.

[0033] In a possible implementation, the at least two test operations corresponding to the interface to be tested are obtained by receiving interface structure information of the interface to be tested, wherein the interface structure information includes an XML tree, and the interface to be tested is parsed according to the interface structure information to determine at least two controls, and the test operation corresponding to each control is obtained.

[0034] Specifically, the XML tree is an XML file used to represent the interface structure of the interface to be tested, and the XML tree records the identification and coordinates of the controls in the interface to be tested. The at least two controls in the interface to be tested are determined by parsing the XML tree, and the test operation corresponding to the at least two controls is obtained.

[0035] S102: determining a target test operation according to the probability distribution model and the at least two test operations, wherein the probability distribution model is used to represent the probability distribution of the interface components that can be covered after different test operations are performed, the probability distribution model is generated according to historical test data, and the target test operation is a test operation with the largest coverage rate of the target interface component among the test operations.

[0036] For example, a probability distribution model is a mathematical model used to characterize the probability distribution of UI components (Activities) that can be covered after a test operation is executed. Specifically, a UI component is an application component that a user can interact with on its provided screen to perform actions such as making a phone call, taking a photo, sending an email, or viewing a map. Each UI component is given a window to draw its user interface. The window typically fills the screen, but can also be smaller than the screen and float on top of other windows. An application typically consists of multiple loosely connected UI components. Generally, a certain UI component in the application is designated as the "main" UI component, that is, the UI component presented to the user when the application is first launched. Furthermore, each UI component can launch another UI component to perform different operations.

[0037] Furthermore, for each test operation, once the test operation is executed, the corresponding control is triggered, causing the program under test to launch one or more UI components. The launched UI components are those covered by the test operation. Each UI component may also contain one or more other related UI components. Each test operation, depending on the subsequent execution steps, may only cover a portion of the UI components. Therefore, for each UI component, there is a probability that it can be covered by the test operation. Figure 3 This is a schematic diagram of a test operation coverage interface component provided in an embodiment of this disclosure, such as... Figure 3 As shown, when test operation a is executed for the first time, test operation a can cover interface component A, as well as interface component A1 which is set within interface component A and associated with interface component A; when test operation a is executed for the second time, test operation a can cover interface component A, as well as interface component A2 which is set within interface component A and associated with interface component A. When test operation a is executed for the Nth time, where N is a positive integer greater than 1, it can be determined that the probability of interface component A being covered by test operation a is 100%, the probability of interface component B being covered by test operation a is 0%, the probability of interface component A1 being covered by test operation a is 30%, and the probability of interface component A2 being covered by test operation a is 70%. That is, the probability distribution of interface components (interface component A, interface component A1, interface component A2, and interface component B) that can be covered after test operation a is executed. Of course, it can be understood that interface components A1 and A2 can also include related components such as interface component A11 and interface component A12. In this case, the probability distribution of interface components that can be covered after test operation a is executed also includes interface component A11, interface component A12, etc., which will not be elaborated here.

[0038] The probability distribution of the interface components that can be covered after the execution of the test operation a can be determined through historical test data. Meanwhile, the historical test data can also be used to determine the probability distribution of the interface components that can be covered after the execution of other test operations, such as test operation b and test operation c. Finally, a probability distribution model is generated to represent the probability distribution of the interface components that can be covered after the execution of different test operations. Optionally, before the step, the method further includes: obtaining historical test data, the historical test data representing the coverage of different interfaces after the execution of historical test operations in previous test tasks; and generating the probability distribution model according to the historical test data.

[0039] Further, the target interface component is an interface component determined according to the specific requirements of the software program product, for example, an interface component that is of interest to the tester, an interface component that has not been tested, or an interface component that needs to be tested with emphasis. That is, the target interface component is an interface component that can improve the comprehensive test effect when tested. The target interface component can be all or part of the interface components associated with the interface under test in the program under test. The probability distribution model generated through the historical test data can be used to determine the probability distribution of the interface components that can be covered by each test operation, and then determine the test operation with the maximum coverage rate of the target interface component, i.e., the target test operation. Exemplarily, the coverage rate can be determined by the probability of covering the target interface component and the number of the target interface components covered by the test operation.

[0040] S103: Send the target test operation to the test machine to test the interface under test.

[0041] Further, after the target test operation is determined, the target test operation is sent to the test machine. The test machine generates a corresponding test case according to the target test operation or executes the target test operation to obtain a test result according to a preset execution script, thereby realizing the test process of the interface under test. Exemplarily, the target test operation can include an operation type and a screen coordinate. After receiving the target test operation, the test machine executes a corresponding operation on a corresponding screen position according to the operation type and the screen coordinate, for example, clicks a control located at the (a, b) coordinate position and obtains a corresponding execution result. The specific process of testing according to the test operation or the test case in this step is a prior art, which will not be described here.

[0042] In the embodiment, at least two test operations corresponding to the to-be-tested interface are acquired, wherein the test operation is used to trigger a control in the to-be-tested interface; a target test operation is determined according to a probability distribution model and the at least two test operations, wherein the probability distribution model is used to represent a probability distribution of interface components that can be covered after different test operations are executed, the probability distribution model is generated according to historical test data, and the target test operation is a test operation in which the coverage of the target interface component after execution is the largest; and the target test operation is sent to a test machine, so that the test machine tests the to-be-tested interface. Since the target test operation determined by the probability distribution model has the largest coverage of the target interface component after being executed, sending the target test operation to the test machine enables the test machine to test the to-be-tested interface according to the target test operation, thereby improving the coverage effect of the test and improving the test efficiency and test effectiveness.

[0043] Reference Figure 4 , Figure 4 Flowchart of a software testing method based on a probability model provided by the embodiment of the present disclosure Figure 1 In the embodiment, the process of step S102 is refined, and a step of generating historical data is added. The software testing method based on a probability model includes the following steps.

[0044] S201: At least two test operations corresponding to a to-be-tested interface are acquired, wherein the test operation is used to trigger a control in the to-be-tested interface.

[0045] S202: Specific operations generated after a control in the to-be-tested interface is triggered are acquired, and the specific operations are abstracted according to representation information of the specific operations, to obtain abstract operations.

[0046] For example, after a control in the to-be-tested interface is triggered, corresponding specific operations are generated, such as executing a search function, jumping to another interface component, and the like. For different specific operations, the specific operations can be abstracted and aggregated according to the operation types represented by the specific operations, to generate corresponding abstract operations. Specifically, for example, a plurality of test operations (actions) corresponding to controls that execute similar functions and achieve similar effects are abstracted and aggregated as one abstract operation (widget). Thus, data dimensionality reduction of the test operations is achieved, the number of test operations is reduced, the dimensionality of the probability distribution model is reduced, and the difficulty of determining the target test operation is reduced.

[0047] Optionally, before step S201, the following step is further included.

[0048] S200A: Historical test data are acquired, and historical test operations are abstracted according to representation information of the historical test operations, to generate historical abstract operations. The historical test data are used to represent the coverage of different to-be-tested interfaces after the historical test operations are executed in previous test tasks.

[0049] Exemplarily, the characterization information comprises at least one of the following: an interface component of the interface to be tested, identification information of the control, a class name of the control, and an operation type of the test operation.

[0050] Specifically, the method for abstracting the historical test operation to generate the historical abstract operation comprises: acquiring an interface component (Activity) of the interface to be tested, identification information (ResourceID) of the control in the interface to be tested, a class name (ClassName) of the control in the interface to be tested, and an operation type (ActionType) of the test operation, and performing hash operation on a string splicing result of the above items to obtain an identification of the abstract operation.

[0051] Optionally, the characterization information further comprises text information (ValidText) of the control, which is determined by analyzing a static text list in an installation package (apk file) of the program to be tested. Optionally, for the text information of the control, the text information is limited according to the static text list obtained by analyzing the apk package, and a text not in the static text list is set as a special identification, for example, "other", so as to prevent infinite expansion of the model in some more dynamic APPs.

[0052] S200B: generating abstract historical test data according to the interface to be tested reached after the historical abstract operation is executed, wherein the abstract historical test data characterizes frequencies of different historical abstract operations being executed to reach different interface components.

[0053] S200C: generating a probability distribution model according to the abstract historical test data.

[0054] Specifically, after the historical abstract operation is acquired, according to the test result corresponding to the historical abstract operation, the frequency of the historical abstract operation being executed to reach different interface components, i.e., the abstract historical test data, can be determined, wherein the higher the frequency is, the higher the probability of the corresponding interface component being covered is; the frequencies of reaching different interface components are counted and normalized, and thus the probability distribution model can be obtained. The specific process is similar to the process of determining the probability distribution model by the historical test data in the embodiments corresponding to the present disclosure, which can be referred to for detailed introduction, and will not be described herein. Figure 3 The process of determining the probability distribution model by the historical test data in the embodiments corresponding to the present disclosure is similar, which can be referred to for detailed introduction, and will not be described herein.

[0055] S203: acquiring state information of the interface to be tested, wherein the state information is used to characterize the measured state of each abstract operation corresponding to the interface to be tested.

[0056] Specifically, the tested state of the abstract operation refers to whether the abstract operation has been tested in the previous test process and the test result. The tested state of each abstract operation represented by the state information of the interface to be tested can be obtained through abstract historical test data or a probability distribution model, which will not be described here. When the state information of the interface to be tested is different, the corresponding test strategy is used for processing, which can improve the test effect. The specific implementation method is introduced in the subsequent steps.

[0057] S204: If the state information of the interface to be tested is the first state, determine the coverage rate coefficient of the untested operation, wherein the coverage rate coefficient represents the coverage rate of the interface component corresponding to the abstract operation after the abstract operation is executed.

[0058] Exemplarily, the state information includes a first state, and the first state represents that there is an untested operation in each abstract operation corresponding to the interface to be tested. The untested operation is an abstract operation not contained in the probability distribution model. Specifically, when there is an untested operation in each operation object corresponding to the interface to be tested, it indicates that the control corresponding to the untested operation is a newly added control that has not been tested. In this case, in order to focus on testing whether the newly added control can correctly start the corresponding interface component after being triggered, the newly added control and the interface component that can be covered by the corresponding test operation can be regarded as the target interface component.

[0059] Exemplarily, the coverage rate coefficient is information representing the coverage ability of the interface component after the abstract operation is executed. Specifically, for example, the coverage rate coefficient can be the number of interface components that can be covered after the abstract operation is executed. The larger the coverage rate coefficient is, the larger the number of interface components that can be covered after the abstract operation is executed. The coverage rate coefficient of the untested operation can be determined based on a measured system model constructed based on MBT, and the measured system model contains description information of the interface component associated with the untested operation. The process of determining the number of interface components associated with a certain test operation based on the measured system model is known to those skilled in the art, and will not be described here.

[0060] S205: Determine the target abstract operation according to the coverage rate coefficient of the untested operation.

[0061] In a possible implementation, the abstract operation corresponding to the untested operation whose coverage coefficient is greater than the preset threshold value can be determined as the target abstract operation. When the untested operation includes a plurality of abstract operations, one or more of the abstract operations can be randomly selected as the target abstract operation. In another possible implementation, the abstract operation corresponding to the maximum coverage coefficient is determined as the target abstract operation according to the coverage coefficients of the abstract operations in the untested operation. In this embodiment, the abstract operation that has not been tested in history is tested preferentially by determining the untested operation, so that the new function of the program under test is preferentially tested, and the test efficiency of the new function is improved. Meanwhile, the untested operation is sorted according to the coverage coefficients, and the abstract operation with a large coverage coefficient is selected as the target abstract operation, so that the test coverage in the new function test process can be further improved, and the test effect is improved.

[0062] S206: If the state information of the interface under test is the second state, the first abstract operation whose execution frequency is less than a preset threshold value is obtained from the abstract operations corresponding to the interface under test according to the probability distribution model.

[0063] Specifically, the state information includes the second state, and the second state indicates that each test operation corresponding to the interface under test is included in the probability distribution model. When each test operation is included in the probability distribution model, it indicates that the interface under test does not include an untested control and a corresponding test operation. Therefore, when the state information of the interface under test is the second state, in order to further improve the coverage of the target interface component on the basis of the existing probability distribution model, the first abstract operation whose execution frequency is less than a preset threshold value is selected from the abstract operations corresponding to the interface under test according to the existing probability distribution model. Since the first abstract operation is executed less frequently, compared with the abstract operation that is executed multiple times, the first abstract operation has a greater probability of testing the interface component that has not been covered before, thereby more probably improving the coverage of the target interface component.

[0064] S207: Whether the target abstract operation can be determined is determined according to a coverage improvement value of the first abstract operation.

[0065] Exemplarily, the coverage improvement value is used to represent the probability that the coverage of the interface component is improved after the abstract operation is executed. Specifically, the coverage improvement value is an evaluation value of the coverage that is improved after the abstract operation is executed. Exemplarily, the coverage improvement value can be determined according to historical test records by calculating the ratio of the interface component that is covered by the abstract operation to the interface component that can be theoretically covered by the abstract operation. The smaller the ratio is, the greater the probability of coverage improvement is, that is, the greater the coverage improvement value is.

[0066] Exemplarily, in a possible implementation, the coverage promotion value of the first abstract operation is data recorded in the probability distribution model, representing the probability of improving the test coverage. The coverage promotion value corresponding to the first abstract operation can be obtained through the existing probability distribution model. Then, the execution probability of each abstract operation is calculated according to the coverage promotion value, and the abstract operations are sorted according to the execution probability, and the abstract operation with the maximum execution probability is selected as the target abstract operation.

[0067] Exemplarily, if the maximum execution probability is greater than a preset value, it indicates that there is a suitable abstract operation as the target abstract operation. At this time, the target abstract operation can be determined, and the following S207 is executed.

[0068] S208: determining the target abstract operation according to the coverage promotion value of the first abstract operation.

[0069] In this embodiment, the target abstract operation is determined through the coverage promotion value of the first abstract operation. The abstract operation corresponding to the test operation with the maximum promotion probability of the test coverage is determined as the target test operation, which can further improve the coverage in the test process and rapidly improve the coverage in the early test.

[0070] If the target abstract operation cannot be determined according to the coverage promotion value of the first test operation, for example, the maximum execution probability is less than a preset value, it indicates that there is no suitable abstract operation as the target abstract operation. Then, the following S207 is executed.

[0071] S209: judging whether each abstract operation corresponding to the interface to be tested is updated with a reward value.

[0072] If there is a second abstract operation updated with a reward value in each abstract operation corresponding to the interface to be tested, the following is executed.

[0073] S210: determining the second abstract operation in each abstract operation corresponding to the interface to be tested and not updated with a reward value as the target abstract operation.

[0074] If each abstract operation corresponding to the interface to be tested is updated with a reward value, the following is executed.

[0075] S211: determining the third abstract operation corresponding to the maximum reward value in each abstract operation as the target abstract operation.

[0076] Exemplarily, if the target abstract operation cannot be determined according to the coverage promotion value of the first test operation, for example, the determined target abstract operation is null, a conventional method is used to determine the target abstract operation according to the reward value corresponding to each abstract operation, wherein the reward value is referred to as a quality value (Q value) in the field of reinforcement learning (Reinforcement Learning), which is used to represent the expectation of the total reward caused by the agent after selecting an action. In this embodiment, exemplarily, according to different strategies, the greater the Q value corresponding to the abstract operation, the greater the coverage of the abstract operation or the greater the coverage promotion value. The selection strategy based on the Q value and the model training algorithm based on the Q value (Q-Learning) are prior art known to those skilled in the art, which will not be described herein. Specifically, the test operation corresponding to the second abstract operation whose reward value is not updated is determined as the target abstract operation, which can prevent the abstract operation corresponding to some control from being unable to select the abstract operation according to the Q value because the Q value is not updated, thereby preventing the test behavior from being abnormal; if the reward value of each abstract operation corresponding to the interface under test is updated, the third abstract operation corresponding to the maximum Q value in the abstract operation is determined as the target abstract operation.

[0077] S212: determining a target test operation according to the target abstract operation.

[0078] Specifically, the abstract operation is abstracted and obtained by one or more test operations, therefore, if the target abstract operation is generated by multiple test operations, one or more test operations corresponding to the multiple test operations can be determined as the target test operation according to a preset strategy or randomly, which will not be described herein.

[0079] S213: sending the target test operation to the test machine to test the interface under test by the test machine.

[0080] S214: updating the reward value corresponding to each test operation in the next update state according to a preset reward model, wherein the reward model is used to represent the mapping relationship between the input parameter and the reward value corresponding to the test operation.

[0081] Specifically, the update state refers to the timing of updating the reward model according to the test result, which can occur after the test machine completes the test or before the next test starts. Exemplarily, the next update state refers to the state of updating the reward model after the test machine completes the test, and the reward value corresponding to each test operation in the reward model is updated according to the specific test result after the test machine tests the interface under test according to the target test operation, wherein the test result is, for example, the number and frequency of the target page components covered by the test.

[0082] wherein, exemplarily, the input parameters comprise at least one of the following:

[0083] the number of test operations that are not included in the probability distribution model in the next update state, the number of test operations that are not executed in the next update state, the probability that all test operations improve the coverage rate in the next update state, and the probability that the test operation improves the coverage rate in the next update state.

[0084] In this embodiment, the reward model is updated through the test result, so that the reward value corresponding to each test operation can more accurately represent the coverage rate of the test operation on the target interface component, and thus when the updated reward model is used to test the interface to be tested subsequently, the coverage rate of the test operation can be better evaluated, the accuracy of determining the target test operation can be improved, and the testing effect and testing efficiency can be improved.

[0085] In this embodiment, the implementation manners of steps S201 and S211 are the same as those of steps S101 and S103 in the embodiment of the present disclosure shown in Figure 2 The implementation manners of steps S201 and S211 are the same as those of steps S101 and S103 in the embodiment of the present disclosure shown in

[0086] The software testing method based on the probability model corresponding to the above embodiment, Figure 5 A structural block diagram of a software testing device based on a probability model provided by the embodiment of the present disclosure is shown in FIG. 3. For ease of illustration, only parts related to the embodiment of the present disclosure are shown. Refer to Figure 5 The software testing device 3 based on the probability model comprises:

[0087] The acquisition module 31 is configured to acquire at least two test operations corresponding to the interface to be tested, wherein the test operation is used to trigger a control in the interface to be tested.

[0088] The determination module 32 is configured to determine a target test operation according to a probability distribution model and the at least two test operations, wherein the probability distribution model is used to represent the probability distribution of the interface components that can be covered after different test operations are executed, the probability distribution model is generated according to historical test data, and the target test operation is a test operation that has the largest coverage rate on the target interface component after being executed among the test operations.

[0089] The test module 33 is configured to send the target test operation to a test machine, so that the test machine tests the interface to be tested.

[0090] In one embodiment of the present disclosure, the determination module 32 is specifically configured to acquire state information of the interface to be tested, wherein the state information is used to represent the measured states of the test operations corresponding to the interface to be tested; and determine the target test operation according to the state information and the probability distribution model.

[0091] In an embodiment of the present disclosure, the state information comprises a first state, the first state representing that there is an untested operation in each test operation corresponding to the interface under test, the untested operation being a test operation not included in the probability distribution model; and the determining module 32, when determining the target test operation according to the state information and the probability distribution model, is specifically configured to: if the state information of the interface under test is the first state, determine a coverage rate of the untested operation, wherein the coverage rate represents a coverage rate of an interface component after the test operation is executed; and determine the target test operation according to the coverage rate of the untested operation.

[0092] In an embodiment of the present disclosure, the state information comprises a second state, the second state representing that each test operation corresponding to the interface under test is included in the probability distribution model; and the determining module 32, when determining the target test operation according to the state information and the probability distribution model, is specifically configured to: if the state information of the interface under test is the second state, obtain a first test operation with a number of executions less than a preset threshold from each test operation corresponding to the interface under test according to the probability distribution model; and determine the target test operation according to a coverage rate improvement value of the first test operation, wherein the coverage rate improvement value represents a probability of improving the coverage rate of the interface component after the test operation is executed.

[0093] In an embodiment of the present disclosure, the determining module 32 is further configured to: if the target test operation cannot be determined according to the coverage rate improvement value of the first test operation, determine a second test operation with an unrewarded value from each test operation corresponding to the interface under test as the target abstract operation.

[0094] In an embodiment of the present disclosure, the determining module 32 is further configured to: if each test operation corresponding to the interface under test has an updated reward value, determine a third test operation corresponding to a maximum reward value from each test operation as the target abstract operation.

[0095] In an embodiment of the present disclosure, the test operation comprises an abstract operation, the abstract operation being obtained by abstracting a specific operation of a triggered control; and the obtaining module 31 is further configured to: obtain the specific operation generated after a control in the interface under test is triggered; and abstract the specific operation according to the representation information of the specific operation to obtain the abstract operation.

[0096] In an embodiment of the present disclosure, before determining the target test operation according to the probability distribution model and the at least two test operations, the determining module 32 is further configured to: obtain historical test data, the historical test data representing a coverage of different interfaces under test after a historical test operation is executed in a previous test task; and generate the probability distribution model according to the historical test data.

[0097] In an embodiment of the present disclosure, the determining module 32, when generating the probability distribution model according to the historical test data, is specifically configured to: abstract the historical test operations according to the characterization information of the historical test operations to generate historical abstract operations; generate abstract historical test data according to the interfaces arrived after the historical abstract operations are executed, wherein the abstract historical test data represents the frequency of different historical abstract operations being executed to arrive at different interface components; and generate the probability distribution model according to the abstract historical test data.

[0098] In an embodiment of the present disclosure, the characterization information includes at least one of the following: an interface component of the interface under test, identification information of a control, a class name of the control, and an operation type of the test operation.

[0099] In an embodiment of the present disclosure, the characterization information further includes text information of the control, and the text information is determined by analyzing static text lists in an installation package of the program under test.

[0100] In an embodiment of the present disclosure, after the determining module 32 determines the target test operation according to the probability distribution model and the at least two test operations, the determining module 32 is further configured to: update the reward values corresponding to the test operations in the next update state according to a preset reward model, wherein the reward model is used to represent a mapping relationship between an input parameter and a reward value corresponding to the test operation; and the input parameter includes at least one of the following: the number of times of executing the test operation, the number of test operations not included in the probability distribution model in the next update state, the number of test operations not executed in the current test task in the next update state, and the probability of improving the coverage rate of all test operations in the next update state.

[0101] In an embodiment of the present disclosure, the obtaining module 31 is specifically configured to: receive interface structure information of the interface under test, wherein the interface structure information includes an extensible markup language tree structure; analyze the interface under test according to the interface structure information to determine at least two controls; and obtain the test operation corresponding to each control.

[0102] The device provided in the embodiment can be used to execute the technical solutions of the above-mentioned method embodiments, and has similar principles and technical effects, which will not be described here again.

[0103] Figure 6 A structural schematic diagram of an electronic device provided in an embodiment of the present disclosure is shown in FIG. 4, which includes at least one processor 41 and a memory 42. Figure 6

[0104] The memory 42 stores computer execution instructions.

[0105] The at least one processor 41 executes the computer execution instructions stored in the memory 42, so that the at least one processor 41 executes the method as shown in FIG. 3.​Figure 2-4 The software testing method based on the probability model in the embodiment.

[0106] The processor 41 and the memory 42 are connected through the bus 43.

[0107] The related description can be referred to Figure 2-4 The corresponding description and effects of the steps in the corresponding embodiment can be understood, and will not be described in detail here.

[0108] Reference Figure 7 It shows a structural diagram of an electronic device 900 suitable for implementing the embodiments of the present disclosure, which can be a terminal device or a server. The terminal device can include, but is not limited to, mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, personal digital assistants (PDA), tablet computers (PAD), portable multimedia players (PMP), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), and the like, and fixed terminals such as digital TVs, desktop computers, and the like. Figure 7 The electronic device shown is only an example and should not limit the functions and use range of the embodiments of the present disclosure.

[0109] As Figure 7 shown, the electronic device 900 can include a processing device (such as a central processor, a graphics processor, etc.) 901, which can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 902 or loaded from a storage device 908 into a random access memory (RAM) 903. In the RAM 903, various programs and data required for the operation of the electronic device 900 are also stored. The processing device 901, the ROM 902, and the RAM 903 are connected to each other through a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0110] In general, the following devices can be connected to the I / O interface 905: input devices 906, including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, and the like; output devices 907, including, for example, a Liquid Crystal Display (LCD), a speaker, a vibrator, and the like; storage devices 908, including, for example, a magnetic tape, a hard disk, and the like; and communication devices 909. The communication devices 909 can allow the electronic device 900 to communicate wirelessly or via a wire with other devices to exchange data. Although Figure 7 The electronic device 900 is shown with various devices, but it is understood that not all of the shown devices are required to be implemented or present. More or fewer devices can alternatively be implemented or present.

[0111] In particular, the processes described above with reference to the flowcharts can be implemented as a computer software program according to embodiments of the present disclosure. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program code for executing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via the communication devices 909, or installed from the storage devices 908, or installed from the ROM 902. When the computer program is executed by the processing devices 901, the above-mentioned functions defined in the methods of embodiments of the present disclosure are performed.

[0112] It should be noted that the computer-readable medium described above can be a computer-readable signal medium or a computer-readable storage medium or any combination thereof. The computer-readable storage medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus or device, or any suitable combination of the foregoing. More specific examples of the computer-readable storage medium can include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present disclosure, the computer-readable storage medium can be any tangible medium that contains or stores a program used by or in connection with an instruction execution system, apparatus or device. In the present disclosure, the computer-readable signal medium can include a data signal propagated in baseband or propagated as a carrier wave in a propagated data signal, in which the computer-readable program code is contained. Such a propagated data signal can take any of a variety of forms, including but not limited to electro-magnetic, optical, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium that is not a storage medium and that can communicate, propagate or transport a program for use by or in connection with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wire, cable, RF, etc., or any suitable combination of the foregoing.

[0113] The computer-readable medium described above can be included in the electronic device described above; or can exist separately from the electronic device and be connected to the electronic device through a communication network.

[0114] The computer-readable medium described above carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the methods described in the above embodiments.

[0115] Computer program code for carrying out operations of the present disclosure can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0116] The flow diagrams and the block diagrams in the drawings are illustrations of architectures, functionalities, and operations of possible implementations of systems, methods, and computer program products according to various embodiments of present disclosure. In this regard, each block in the flow diagrams or block diagrams can represent a module, a procedure, or a part of code, which comprises one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or in the reverse order, depending on the functionality involved. It is also noted that each block in the block diagrams and / or flow diagrams and combinations of blocks in the block diagrams and / or flow diagrams can be implemented by special-purpose hardware-based systems that perform the specified functions or operations, or combinations of special-purpose hardware and computer instructions.

[0117] The units described in the embodiments of the present disclosure can be implemented by software, or by hardware. In some cases, the name of the unit does not constitute a limitation on the unit itself. For example, the first obtaining unit can also be described as a unit for obtaining at least two Internet protocol addresses.

[0118] The functions described in this specification can be implemented in part or in whole by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc.

[0119] In the context of this disclosure, a machine-readable medium can be a tangible medium that contains or stores a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine-readable storage medium will include one or more lines of electrical connections, portable computer disks, hard disk drives, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or Flash memory), optical fibers, portable compact disc read-only memories (CD-ROMs), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0120] In a first aspect, according to one or more embodiments of the present disclosure, a software testing method based on a probability model is provided, including:

[0121] obtaining at least two test operations corresponding to a to-be-tested interface, wherein the test operations are used to trigger controls in the to-be-tested interface; determining a target test operation according to a probability distribution model and the at least two test operations, wherein the probability distribution model is used to represent a probability distribution of interface components that can be covered after different test operations are executed, the probability distribution model is generated according to historical test data, and the target test operation is a test operation in the test operations, which has the largest coverage rate of a target interface component after being executed; and sending the target test operation to a testing machine, so as to make the testing machine test the to-be-tested interface.

[0122] According to one or more embodiments of the present disclosure, determining a target test operation according to a probability distribution model and at least two test operations includes: obtaining state information of the to-be-tested interface, wherein the state information is used to represent measured states of the test operations corresponding to the to-be-tested interface; and determining a target test operation according to the state information and the probability distribution model.

[0123] According to one or more embodiments of the present disclosure, the state information includes a first state, the first state represents that there is an untested operation in the test operations corresponding to the to-be-tested interface, and the untested operation is a test operation not included in the probability distribution model; and determining a target test operation according to the state information and the probability distribution model includes: if the state information of the to-be-tested interface is the first state, determining a coverage rate coefficient of the untested operation, wherein the coverage rate coefficient represents a coverage rate of an interface component corresponding to a test operation after the test operation is executed; and determining the target test operation according to the coverage rate coefficient of the untested operation.

[0124] According to one or more embodiments of the present disclosure, the state information comprises a second state, the second state representing that each test operation corresponding to the to-be-tested interface is included in the probability distribution model; and determining the target test operation according to the state information and the probability distribution model comprises: if the state information of the to-be-tested interface is the second state, obtaining, according to the probability distribution model, a first test operation from each test operation corresponding to the to-be-tested interface, the first test operation having a number of executions less than a preset threshold; and determining the target test operation according to a coverage rate improvement value of the first test operation, wherein the coverage rate improvement value represents a probability of improving the coverage rate of the interface component after the test operation is executed.

[0125] According to one or more embodiments of the present disclosure, the method further comprises: if the target test operation cannot be determined according to the coverage rate improvement value of the first test operation, determining a second test operation from each test operation corresponding to the to-be-tested interface as a target abstract operation, the second test operation having no updated reward value.

[0126] According to one or more embodiments of the present disclosure, the method further comprises: if each test operation corresponding to the to-be-tested interface has an updated reward value, determining a third test operation corresponding to a maximum reward value from each test operation as a target abstract operation.

[0127] According to one or more embodiments of the present disclosure, the test operation comprises an abstract operation, the abstract operation being obtained by abstracting a specific operation of triggering the control; and the method further comprises: obtaining a specific operation generated after a control in the to-be-tested interface is triggered; and abstracting the specific operation according to representation information of the specific operation to obtain the abstract operation.

[0128] According to one or more embodiments of the present disclosure, before determining the target test operation according to the probability distribution model and at least two test operations, the method further comprises: obtaining historical test data, the historical test data representing coverage of different to-be-tested interfaces after historical test operations are executed in previous test tasks; and generating the probability distribution model according to the historical test data.

[0129] According to one or more embodiments of the present disclosure, generating the probability distribution model according to the historical test data comprises: abstracting the historical test operation according to representation information of the historical test operation to generate a historical abstract operation; generating abstract historical test data according to to-be-tested interfaces reached after the historical abstract operation is executed, the abstract historical test data representing frequencies of reaching different interface components after different historical abstract operations are executed; and generating the probability distribution model according to the abstract historical test data.

[0130] According to one or more embodiments of the present disclosure, the characterization information comprises at least one of the following: an interface component of the interface to be tested, identification information of the control, a class name of the control, and an operation type of the test operation.

[0131] According to one or more embodiments of the present disclosure, the characterization information further comprises text information of the control, which is determined by analyzing a static text list in an installation package of the program to be tested.

[0132] According to one or more embodiments of the present disclosure, after determining the target test operation according to the probability distribution model and the at least two test operations, the method further comprises: updating, according to a preset reward model, a reward value corresponding to each test operation in a next update state, wherein the reward model is used to represent a mapping relationship between an input parameter and a reward value corresponding to a test operation; and the input parameter comprises at least one of the following: a number of times of execution of the test operation, a number of test operations not included in the probability distribution model in the next update state, a number of test operations not executed in the current test task in the next update state, and a probability of improving coverage of all test operations in the next update state.

[0133] According to one or more embodiments of the present disclosure, the at least two test operations corresponding to the interface to be tested are obtained by: receiving interface structure information of the interface to be tested, wherein the interface structure information comprises an extensible markup language tree structure; analyzing the interface to be tested according to the interface structure information to determine the at least two controls; and obtaining a test operation corresponding to each control.

[0134] In a second aspect, according to one or more embodiments of the present disclosure, a software testing device based on a probability model is provided, comprising:

[0135] An obtaining module is configured to obtain at least two test operations corresponding to an interface to be tested, wherein the test operation is used to trigger a control in the interface to be tested.

[0136] A determining module is configured to determine a target test operation according to a probability distribution model and the at least two test operations, wherein the probability distribution model is used to represent a probability distribution of interface components that can be covered after different test operations are executed, the probability distribution model is generated according to historical test data, and the target test operation is a test operation in the test operations, which has the largest coverage rate of a target interface component after being executed.

[0137] A testing module is configured to send the target test operation to a testing machine, so that the testing machine tests the interface to be tested.

[0138] According to one or more embodiments of the present disclosure, the determining module is specifically configured to: acquire state information of the to-be-tested interface, wherein the state information is used to represent the tested state of each test operation corresponding to the to-be-tested interface; and determine the target test operation according to the state information and the probability distribution model.

[0139] According to one or more embodiments of the present disclosure, the state information includes a first state, and the first state represents that there is an untested operation in each test operation corresponding to the to-be-tested interface, wherein the untested operation is a test operation not included in the probability distribution model; and when determining the target test operation according to the state information and the probability distribution model, the determining module is specifically configured to: if the state information of the to-be-tested interface is the first state, determine a coverage rate coefficient of the untested operation, wherein the coverage rate coefficient represents the coverage rate of an interface component after the test operation is executed; and determine the target test operation according to the coverage rate coefficient of the untested operation.

[0140] According to one or more embodiments of the present disclosure, the state information includes a second state, and the second state represents that each test operation corresponding to the to-be-tested interface is included in the probability distribution model; and when determining the target test operation according to the state information and the probability distribution model, the determining module is specifically configured to: if the state information of the to-be-tested interface is the second state, acquire a first test operation with a number of executions less than a preset threshold from each test operation corresponding to the to-be-tested interface according to the probability distribution model; and determine the target test operation according to a coverage rate improvement value of the first test operation, wherein the coverage rate improvement value is used to represent the probability of improving the coverage rate of an interface component after the test operation is executed.

[0141] According to one or more embodiments of the present disclosure, the determining module is further configured to: if the target test operation cannot be determined according to the coverage rate improvement value of the first test operation, determine a second test operation with an unrevised reward value from each test operation corresponding to the to-be-tested interface as a target abstract operation.

[0142] According to one or more embodiments of the present disclosure, the determining module is further configured to: if each test operation corresponding to the to-be-tested interface is revised, determine a third test operation corresponding to a maximum reward value from each test operation as a target abstract operation.

[0143] According to one or more embodiments of the present disclosure, the test operation includes an abstract operation, and the abstract operation is obtained by abstracting a specific operation of triggering the control; and the acquiring module is further configured to: acquire the specific operation generated after a control in the to-be-tested interface is triggered; and abstract the specific operation according to the representation information of the specific operation to obtain the abstract operation.

[0144] According to one or more embodiments of the present disclosure, before determining the target test operation according to the probability distribution model and at least two test operations, the determining module is further configured to: acquire historical test data, the historical test data being used to represent coverage of different to-be-tested interfaces after historical test operations are performed in previous test tasks; and generate the probability distribution model according to the historical test data.

[0145] According to one or more embodiments of the present disclosure, according to the historical test data, the determining module is specifically configured to: abstract the historical test operations according to the representation information of the historical test operations to generate historical abstract operations; generate abstract historical test data according to to-be-tested interfaces reached after the historical abstract operations are performed, wherein the abstract historical test data represents frequencies of reaching different interface components after different historical abstract operations are performed; and generate the probability distribution model according to the abstract historical test data.

[0146] According to one or more embodiments of the present disclosure, the representation information includes at least one of the following: an interface component of the to-be-tested interface, identification information of the control, a class name of the control, and an operation type of the test operation.

[0147] According to one or more embodiments of the present disclosure, the representation information further includes text information of the control, and the text information is determined by analyzing static text lists in an installation package of the to-be-tested program.

[0148] According to one or more embodiments of the present disclosure, after determining the target test operation according to the probability distribution model and at least two test operations, the determining module is further configured to: update reward values corresponding to the test operations in a next update state according to a preset reward model, wherein the reward model is used to represent a mapping relationship between input parameters and reward values corresponding to the test operations; and the input parameters include at least one of the following: a number of times of performing the test operation, a number of test operations not included in the probability distribution model in the next update state, a number of test operations not performed in the test task in the next update state, and a probability of improving coverage rate of all test operations in the next update state.

[0149] According to one or more embodiments of the present disclosure, the acquiring module is specifically configured to: receive interface structure information of the to-be-tested interface, wherein the interface structure information includes an extensible markup language tree structure; analyze the to-be-tested interface according to the interface structure information to determine at least two controls; and acquire test operations corresponding to the controls.

[0150] In a third aspect, an electronic device is provided according to one or more embodiments of the present disclosure, and includes at least one processor and a memory;

[0151] The memory stores computer-executable instructions;

[0152] The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor performs the software testing method based on the probabilistic model as described in the first aspect above and various possible designs of the first aspect.

[0153] In a fourth aspect, a computer-readable storage medium is provided according to one or more embodiments of the present disclosure, and the computer-readable storage medium stores computer-executable instructions, when the processor executes the computer-executable instructions, the software testing method based on the probabilistic model as described in the first aspect above and various possible designs of the first aspect is implemented.

[0154] In a fifth aspect, a computer program product is provided according to an embodiment of the present disclosure, and the computer program product includes a computer program, when the computer program is executed by a processor, the software testing method based on the probabilistic model as described in the first aspect above and various possible designs of the first aspect is implemented.

[0155] The above description is merely preferred embodiments of the present disclosure and a description of the principles of the technology employed. It will be understood by those skilled in the art that the disclosed scope of the present disclosure is not limited to the technical solutions formed by the specific combinations of the above technical features, and also covers other technical solutions formed by any combinations of the above technical features or equivalent features without departing from the above disclosed concept. For example, the technical solutions formed by replacing the above features with the technical features disclosed in the present disclosure (but not limited to) having similar functions.

[0156] In addition, although each operation is described in a particular order, this should not be understood as requiring the operations to be performed in the specific order or in a sequential order. In certain circumstances, multi-tasking and parallel processing can be advantageous. Similarly, although several implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Certain features described in the context of separate embodiments can also be combined in a single embodiment. Conversely, various features described in the context of a single embodiment can also be separated and implemented in multiple embodiments.

[0157] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A software testing method based on a probabilistic model, characterized in that, The method comprises the following steps: obtaining at least two test operations corresponding to a to-be-tested interface, wherein the test operations are used to trigger a control in the to-be-tested interface; the test operations comprise abstract operations, and the abstract operations are obtained by abstracting specific operations for triggering the control; determining a target test operation according to a probability distribution model and the at least two test operations, wherein the probability distribution model is used to represent a probability distribution of interface components that can be covered after different test operations are executed, the probability distribution model is generated according to historical test data, and the target test operation is a test operation in the test operations, which has the largest coverage rate of a target interface component after being executed; sending the target test operation to a test machine, so that the test machine tests the to-be-tested interface; The method further comprises the following steps:

2. The method of claim 1, wherein, obtaining a specific operation generated after the control in the to-be-tested interface is triggered; and abstracting the specific operation according to representation information of the specific operation to obtain the abstract operation. The method of determining a target test operation according to a probability distribution model and at least two test operations comprises the following steps: obtaining state information of the to-be-tested interface, wherein the state information is used to represent measured states of the test operations corresponding to the to-be-tested interface; 3. The method of claim 2, wherein, determining the target test operation according to the state information and the probability distribution model. The state information comprises a first state, and the first state represents that there is an untested operation in the test operations corresponding to the to-be-tested interface, wherein the untested operation is a test operation not contained in the probability distribution model; The method of determining a target test operation according to the state information and the probability distribution model comprises the following steps: if the state information of the to-be-tested interface is the first state, determining a coverage rate coefficient of the untested operation, wherein the coverage rate coefficient represents a coverage rate of an interface component after a test operation is executed; 4. The method of claim 2, wherein, determining the target test operation according to the coverage rate coefficient of the untested operation. The state information comprises a second state, and the second state represents that the test operations corresponding to the to-be-tested interface are all contained in the probability distribution model; The method of determining a target test operation according to the state information and the probability distribution model comprises the following steps: if the state information of the to-be-tested interface is the second state, obtaining a first test operation with a number of executions less than a preset threshold value from the test operations corresponding to the to-be-tested interface according to the probability distribution model; 5. The method of claim 4, wherein, determining the target test operation according to a coverage rate improvement value of the first test operation, wherein the coverage rate improvement value is used to represent a probability of improving a coverage rate of an interface component after a test operation is executed. The method further comprises the following steps:

6. The method of claim 5, wherein, if the target test operation cannot be determined according to the coverage rate improvement value of the first test operation, determining a second test operation with an unrewarded reward value from the test operations corresponding to the to-be-tested interface as a target abstract operation. The method further comprises the following steps: if the test operations corresponding to the to-be-tested interface all have updated reward values, determining a third test operation corresponding to a maximum reward value from the test operations as a target abstract operation.

7. The method of claim 1, wherein, Before determining the target test operation according to the probability distribution model and at least two test operations, the method further comprises: obtaining historical test data, wherein the historical test data is used to represent coverage of different to-be-tested interfaces after the historical test operations are executed in previous test tasks; generating the probability distribution model according to the historical test data.

8. The method of claim 7, wherein, Generating the probability distribution model according to the historical test data comprises: abstracting the historical test operations according to the representation information of the historical test operations to generate historical abstract operations; generating abstract historical test data according to to-be-tested interfaces reached after the historical abstract operations are executed, wherein the abstract historical test data represents frequencies of reaching different interface components after different historical abstract operations are executed; generating the probability distribution model according to the abstract historical test data.

9. The method according to claim 1 or 8, characterized in that, The representation information comprises at least one of the following: interface components of the to-be-tested interface, identification information of the control, class name of the control, and operation type of the test operation.

10. The method of claim 9, wherein, The representation information further comprises text information of the control, and the text information is determined by analyzing static text lists in an installation package of a to-be-tested program.

11. The method of claim 5 or 6, wherein, After determining the target test operation according to the probability distribution model and at least two test operations, the method further comprises: updating reward values corresponding to the test operations in the next update state according to a preset reward model, wherein the reward model is used to represent a mapping relationship between input parameters and reward values corresponding to the test operations; The input parameters comprise at least one of the following: execution times of the test operation, a number of test operations not included in the probability distribution model in the next update state, a number of test operations not executed in the current test task in the next update state, and a sum of probabilities of improving coverage rates of all test operations in the next update state.

12. The method according to any one of claims 1 to 6, characterized in that, Obtaining at least two test operations corresponding to the to-be-tested interface comprises: receiving interface structure information of the to-be-tested interface, wherein the interface structure information comprises an extensible markup language tree structure; analyzing the to-be-tested interface according to the interface structure information to determine at least two controls; obtaining test operations corresponding to each control.

13. A software testing apparatus based on a probabilistic model, characterized by, Comprise: an obtaining module, configured to obtain at least two test operations corresponding to a to-be-tested interface, wherein the test operation is used to trigger a control in the to-be-tested interface; the test operation comprises an abstract operation, and the abstract operation is obtained by abstracting a specific operation of triggering the control; a determining module, configured to determine a target test operation according to a probability distribution model and at least two test operations, wherein the probability distribution model is used to represent a probability distribution of interface components that can be covered after different test operations are executed, the probability distribution model is generated according to historical test data, and the target test operation is a test operation that has the largest coverage rate of a target interface component after being executed among the test operations; a testing module, configured to send the target test operation to a testing machine, so that the testing machine tests the to-be-tested interface. The acquisition module is further configured to acquire a specific operation generated after a control in the interface to be tested is triggered; and abstract the specific operation according to representation information of the specific operation to obtain the abstract operation.

14. An electronic device, comprising: The method comprises: at least one processor and a memory; the memory stores computer-executable instructions; the at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the software testing method based on the probabilistic model according to any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, and when the processor executes the computer-executable instructions, the software testing method based on the probabilistic model according to any one of claims 1 to 12 is implemented.

16. A computer program product comprising a computer program which, when executed by a processor, implements the software testing method based on the probabilistic model according to any one of claims 1 to 12.

Images