Test case sorting method, device, computing device and storage medium

Abstract

This invention discloses a test case sorting method, apparatus, computing device, and storage medium. The method includes: calculating the defect susceptibility probability of each class common to the software version under test and historical versions; calculating the testing capability of each test case based on the defect susceptibility probability of each class; and sorting the test cases according to their testing capabilities to obtain a priority ranking result. This invention can improve the reliability of test case sorting, optimize test cases, and increase the testing value of test cases for the software version under test.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of software testing, and in particular to a test case sorting method, apparatus, computing device and storage medium. Background Art

[0002] In order to adapt to people's ever-evolving and changing needs, various software are constantly being updated to meet various needs that keep pace with the times.

[0003] Since various underlying codes will inevitably be changed during the software version change process, after the software version update is completed, unforeseen stability and usage problems may occur. Software developers usually choose to test the software through various pre-determined test cases after the software version update is completed. After the problems that arise during the test process are fixed, the new version of the software is pushed. If you want to test the software with high quality, you need to select as many test cases as possible, which seriously affects the efficiency of software testing. Therefore, how to optimize and select test cases has become an urgent problem to be solved. Summary of the invention

[0004] The present invention provides a test case sorting method, device, computing equipment and storage medium to improve the reliability of test case sorting, optimize test cases, and thus improve the test value of test cases for software versions to be tested.

[0005] In a first aspect, an embodiment of the present invention provides a test case sorting method, the method comprising: calculating the defect susceptibility probability of each class shared by the software version to be tested and the historical version;

[0006] Calculate the test capability of each test case based on the defect probability of each class;

[0007] The test cases are sorted according to their test capabilities to obtain a priority sorting result of the test cases.

[0008] In a second aspect, an embodiment of the present invention further provides a test case sorting device, the device comprising:

[0009] The probability calculation module is used to calculate the probability of defects in each class shared by the software version under test and the historical versions;

[0010] A capability determination module is used to calculate the test capability of each test case based on the defect susceptibility of each class;

[0011] The priority sorting module is used to sort each of the test cases according to the test capabilities of each of the test cases to obtain a priority sorting result of the test cases.

[0012] In a third aspect, an embodiment of the present invention further provides a computing device, the device comprising:

[0013] one or more processors;

[0014] A storage device for storing one or more programs;

[0015] When the one or more programs are executed by the one or more processors, the one or more processors implement any test case sorting method described in the first aspect.

[0016] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium comprising computer-executable instructions, on which computer-executable instructions are stored, and when the computer-executable instructions are executed by a computer processor, any test case sorting method described in the first aspect is implemented.

[0017] The embodiment of the present invention obtains the defect probability of each class in the common classes, and further determines the test capability of the test case based on the defect probability, thereby prioritizing the test cases according to the test capability, improving the reliability of the test case sorting, optimizing the test cases, and improving the test value of the test cases for the software version to be tested. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:

[0019] Figure 1A is a schematic diagram of a test case sorting method provided according to an embodiment of the present invention;

[0020] Figure 1B is a schematic diagram of a defect susceptibility model provided by an embodiment of the present invention;

[0021] Figure 2 is a schematic diagram of a test case sorting method provided according to another embodiment of the present invention;

[0022] Figure 3 is a structural schematic diagram of a test case sorting device provided according to another embodiment of the present invention;

[0023] Figure 4 is a block diagram of a computing device used to implement an embodiment of the present invention. DETAILED DESCRIPTION

[0024] The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the present invention, rather than to limit the present invention. It should also be noted that, for ease of description, only parts related to the present invention, rather than all structures, are shown in the accompanying drawings.

[0025] Regression testing refers to a phase in the software testing cycle, which is usually performed after the software system is updated. The purpose of updating the software system is to modify the problems in the current version or to add new functions based on the existing functions. For the program P′ under test, regression testing not only ensures that the newly added or modified code behavior of P′ on its previous version P is correct, but also ensures that the unmodified code behavior in P′ is not affected. Whenever the program is modified, testers need to perform regression testing to ensure the quality of the software. Therefore, regression testing is an important and indispensable testing activity. However, frequent regression testing will take up a large part of the project resources, including time and human resources. Some previous research results show that the time cost of regression testing accounts for more than one-third of the total cost of software maintenance. Researchers in industry and academia have been committed to finding ways to reduce the cost of regression testing and improve the efficiency of regression testing.

[0026] In the embodiment of the present application, by optimizing the test case set of regression testing, the cost of regression testing can be effectively reduced and the efficiency of regression testing can be improved. Specifically, the test case priority sorting technology can be used for optimization, and it is considered that different test cases have different contributions to the test objectives. Therefore, the test cases are sorted according to their contribution to the test objectives, and those test cases that contribute more to the test objectives are executed first. On this basis, the tester can freely adjust the length of the test case execution sequence according to the budget of the project. Compared with ordinary testing activities, regression testing can use more information, including the test case pool composed of the test cases of the previous version and the execution slices and execution results of the test cases. If this information is used, it can assist the optimization of regression testing and improve the efficiency of regression testing.

[0027] In the embodiment of the present application, considering that the modification information of the program source code and the quality measurement information of the code unit will affect the defect susceptibility of the code unit, the higher the defect susceptibility of the code unit, the greater the possibility of the test case covering the code unit to find defects. Therefore, the present invention proposes a test case prioritization technology based on multiple factors, which constructs a test case-code unit coverage matrix using the modification information of the program source code, software quality measurement information and code coverage information of the test case, and uses a greedy algorithm to prioritize the test cases according to the coverage of the test cases.

[0028] Figure 1A A flowchart of a test case sorting method provided by an embodiment of the present invention is applicable to the case of determining the priorities of different test cases in a test case set. The method can be executed by a test case sorting device provided by an embodiment of the present invention, and the device can be implemented in software and / or hardware. The device can be configured in a computing device with corresponding data processing capabilities. The method specifically includes:

[0029] S110, calculating the defect probability of each class shared by the software version to be tested and the historical versions.

[0030] Among them, the defect-prone probability can be understood as the probability that the code of the software version to be tested may have defects for each class. The greater the defect-prone probability of a class, the more expected it is to have a test case that can effectively test this class during the testing process. Correspondingly, the contribution or value of this test case is higher. The defect-prone probability can be determined by a conditional probability network, and the conditional probability network can be composed of three elements: C nodes, CF edges, and conditional probability distribution of F nodes.

[0031] Figure 1B FIG. 1 is a schematic diagram of a defect susceptibility model provided by an embodiment of the present invention. Figure 1B , in the accompanying figure:

[0032] C node: A class that exists in both the version V to be tested and the historical version V-1 of the software P has a corresponding C node. A C node contains the code modification information of the corresponding class and has two possible values: modified (denoted as c) and unmodified (denoted as ). If the source code of a class changes from version V-1 to version V, the class is considered modified, otherwise it is unmodified.

[0033] F-node: Each C-node has a corresponding F-node, which is used to indicate the defect susceptibility of the class. An F-node also has two possible values: contains defects (denoted as f) and does not contain defects (denoted as ). These two values ​​represent whether the corresponding class contains defects or does not contain defects.

[0034] CF edge: A class that exists in both the version V to be tested and the historical version V-1 of the software P has a CF edge from the corresponding C node to the corresponding F node. Such an edge represents a causal relationship: modifying the code of a class may introduce defects into the class.

[0035] Specifically, after obtaining the software version to be tested and the historical version, the classes shared by the two are compared to determine whether the corresponding source code of each class has been modified. Based on the corresponding defect susceptibility of each class, the probability of causing defects in this class when the source code is modified or not modified is calculated as the defect susceptibility of each class. By only calculating the defect susceptibility of the shared classes instead of all classes, the test data of the previous version can be partially borrowed to reduce the amount of data testing during the software version testing process.

[0036] Exemplarily, before calculating the defect probability of each class common to the tested version and the historical version, it is necessary to collect the test coverage matrix of the test case set T used in this test on the previous historical version V-1 of the tested software P.

[0037] Table 1 shows the test coverage of the test case set T on version V-1 of the software P. According to the test coverage shown in Table 1, the test coverage matrix corresponding to the test case set of the previous version can be obtained, and the test coverage matrix can be adaptively modified according to the content of this version update and can be used again without rebuilding the test coverage matrix, thereby improving the test efficiency.

[0038] Table 1 Test coverage of test case set T on version V-1 of software P

[0039]

[0040] S120. Calculate the test capability of each test case according to the defect probability of each class.

[0041] Among them, testing capability refers to whether the current test case can effectively test the common classes.

[0042] Specifically, for a test case, it may cover at least one of the shared classes, or it may not cover any of the shared classes. At this time, it is necessary to determine whether the current test case has the test capability based on whether the current test case covers one of the shared classes. If the current test case covers any of the shared classes, it is also necessary to further determine the test capability of the current test implementation example based on the defect probability of the covered class. Among them, if the test case covers at least one line of code in any class, it means that the current test case covers the class. The quantitative value of the test capability of each test case is determined by the defect probability, which facilitates the priority sorting of subsequent different test implementations. The test capability determined by the defect probability can also ensure the reliability of the test capability sorting.

[0043] S130. Sort the test cases according to their test capabilities to obtain a priority sorting result of the test cases.

[0044] Among them, priority is the logical order of the order and weight of different test cases when they are executed, which is used to distinguish the importance of different test cases.

[0045] Specifically, the test cases are sorted according to their test capabilities for the test target, and those test cases with better test capabilities are executed first. The priority of each test case can be determined in order from high to low test capabilities, and the length of the test case execution sequence can be freely adjusted according to the project budget. By sorting the test cases based on test capabilities, it is ensured that the test cases with better test capabilities can be executed first, which improves the test value of the test cases used in the version test.

[0046] The embodiment of the present invention obtains the defect probability of each class in the common classes, and further determines the test capability of the test case based on the defect probability, thereby prioritizing the test cases according to the test capability, improving the reliability of the test case sorting, and improving the test value of the test case for the software version to be tested.

[0047] Figure 2 This is a flowchart of a test case sorting method provided by another embodiment of the present invention. This embodiment is optimized and improved on the basis of the above embodiments. Figure 2 The method may include:

[0048] S211, determining a priori probability that each class is modified and a priori probability that each class is not modified according to the modification amount of each class shared by the software version to be tested and the historical version;

[0049] Specifically, the source code of the classes shared by the software under test and the historical version is obtained respectively, and the differences in quantity and format are compared between the two to determine the amount of modification of the shared class. For example, if 20 lines of 50 lines of code are modified, then the amount of modification of this class is 20 lines of code. Based on the ratio of the amount of modification to the source code of the shared class in the historical version, the prior probability that the code has been modified and the prior probability that it has not been modified can be determined. Among them, the sum of the prior probability that it has not been modified and the prior probability that it has been modified should be 1.

[0050] Exemplarily, the prior probability P(c) of each class being modified can be calculated by the following formula: i ) and the prior probability of each class is not modified

[0051] P(c i )=change(class i )

[0052]

[0053] Among them, change(class i ) is equal to the number of lines of code modified from version V-1 to version V in class i in software P / the total number of lines of code in version V-1 of class i.

[0054] S212, estimating the conditional probability that a modified part and an unmodified part of each class contain defects according to the incoming coupling metric value and the outgoing coupling metric value of each class;

[0055] Among them, Afferent Coupling (CA) is a software quality metric used to measure the number of classes that depend on a specific class (if class A calls the method of this specific class or uses its member variables, then class A depends on this specific class). Efferent Coupling (CBO) is an object-oriented software quality metric in the Chidamber and Kemerer (CK) metric set, which is used to measure the number of classes that a specified class depends on (if this specified class calls the method of class A or uses its member variables, then this specified class depends on class A). CA and CBO are metric indicators for each class in version V, which can be accessed through some tools, such as ckjm. ckjm calculates Chidamber and Kemerer object-oriented metrics, including CA and CBO, by processing the bytecode of compiled Java files.

[0056] Specifically, for each F node, the conditional probability that its packet is modified and the conditional probability that it is not modified are estimated based on the afferent coupling and efferent coupling univariate defect susceptibility models, respectively.

[0057] In the embodiment of the present invention, optionally, estimating the conditional probability that the modified part and the unmodified part of each class contain defects according to the incoming coupling metric value and the outgoing coupling metric value of each class includes:

[0058] According to the ratio of the incoming coupling metric of each class to the maximum incoming coupling metric, the conditional probability that the modified part of each class contains defects is estimated; according to the ratio of the outgoing coupling metric of each class to the maximum outgoing coupling metric, the conditional probability that the unmodified part of each class contains defects is estimated.

[0059] Specifically, the incoming coupling metric value of class i can be understood as the number of classes that depend on class i among the shared classes; the outgoing coupling metric value of class i can be understood as the number of classes that class i depends on among the shared classes; the maximum incoming coupling metric value can be understood as the maximum value of the incoming coupling metric values ​​of each shared class; the outgoing coupling metric value, the maximum outgoing coupling metric value can be understood as the maximum value of the outgoing coupling metric values ​​of each shared class. For example, the conditional probability P(f) that the modified part of each class contains a defect is estimated by the following formula i |c i ) and the conditional probability that the unmodified part contains a defect

[0060]

[0061]

[0062] Among them, β+δ 2 <<α+δ 1 ≤1, β, δ 2 , α, δ 1 Can be set according to needs. CA(class i ) is the incoming coupling metric value of class i in the version V of software P to be tested, CBO (class i ) is the outgoing coupling metric value of class i in the version V to be tested of software P.

[0063] S213. Calculate the defect-prone probability of each class according to the prior probability of each class being modified and the prior probability of each class not being modified, and the conditional probability that the modified part and the unmodified part of each class contain defects.

[0064] Specifically, since the defect-prone probability model is essentially related to the C node and the F node, i.e., the CF edge, the modified prior probability and the unmodified prior probability calculated above are essentially the numerical representations of the C node, and the conditional probability that the modified part and the unmodified part of each class contain defects is the numerical representation of the F node. Therefore, the corresponding defect-prone probability is calculated based on the prior probability and the conditional probability, making the defect-prone probability more reliable.

[0065] Optionally, the prior probability of each class being modified can be multiplied by the conditional probability of the modified part to obtain the first probability of the class; the prior probability of each class being unmodified can be multiplied by the conditional probability of the unmodified part to obtain the second probability of the class; the first probability of each class can be added to the second probability to obtain the defect-prone probability of each class.

[0066] For example, the defect probability P(f i ):

[0067]

[0068] S221. For each test case, the defect probability of each class is multiplied by the coverage value of the test case for the corresponding class in the historical version to obtain the test capability of the test case for each class.

[0069] Specifically, Cov(T j ,class i ) represents the test case T j For the test coverage of class i in version V-1 of software P, that is, the coverage value, if test case T j covers at least one line of code in class i, then cov(T j ,class i )=1, otherwise cov(T j ,class i )=0. On this basis, test case T j The test capability for class i can be expressed as: P(f i )cov(T j ,class i ).

[0070] S222. Add the test capabilities of the test case for each class to obtain the test capability of the test case.

[0071] For example, the test case T can be expressed as j Add up the test capabilities of each class and calculate the test capability TC of each test case in the test case set T j :

[0072] TC j =∑P(f i )cov(T j ,class i )|class i ∈C

[0073] Among them, TC j Represents test case T j The testing capability, P(f i ) represents the defect susceptibility of class i in the tested version V of software P; set C is the remaining covering set, which initially contains all classes that exist in the tested version V and version V-1 of software P.

[0074] S231. Remove the test case with the largest current test capability value from the test case set.

[0075] S232. Add the removed test case to the result sequence which is initially empty.

[0076] The result sequence is the final test case sorting result for testing the current software version to be tested.

[0077] Specifically, after determining the test capability of the test implementation, the test case with the greatest test capability is transferred to the result sequence. Since the result sequence is empty at this time, the test with the greatest test capability will be executed first, that is, the test case with the greatest test capability is set to the highest priority, ensuring that the level of test capability is orderly converted into the level of test priority. Deleting the test case to be transferred from the test case set before transferring to the result sequence can avoid the same test case from repeatedly acquiring test capability and transferring.

[0078] In addition, when removing a test case or adding the removed test case to the result sequence, the remaining coverage set C is updated, and the classes covered by the removed test case are removed from the remaining coverage set C. On this basis, after each test case with the largest current test capability value is removed, the test case with the largest test capability value can continue to be selected for the remaining classes (i.e., the classes not covered by the removed test case), which can avoid multiple test capability calculations and comparisons for the same class by different test cases, thereby improving the test value of each test case for all classes and ensuring the reliability of the sorting results and the test effect.

[0079] S233: Determine whether all test cases in the test case set have been removed. If not, return to execute S231. If yes, return to execute step S234.

[0080] S234. The test cases in the result sequence arranged in the order of addition are the priority sorting result.

[0081] The embodiments of the present invention improve the accuracy of defect-prone probability by combining prior probability and conditional probability to calculate defect-prone probability; make the test capability more effective and reliable by adding the common class test capabilities covered by the test case as the test capability of the test case; and further improve the value and sorting reliability of the test case by converting the disordered test cases in the original test case set into clear and definite priority sorting in the result sequence according to the size of the test capability.

[0082] Based on the above embodiment, optionally, removing the test case with the maximum current test capability value from the test case set includes:

[0083] If there is more than one test case with the largest value of the current test capability, a random strategy is used to select one of the test cases to remove.

[0084] Specifically, if in the process of calculating the test capabilities of different test cases, if two test cases have exactly the same test capabilities, if both are transferred to the result sequence, not only will it be impossible to define different priorities, but also the use of test cases with the same test capabilities for separate testing will waste test resources. Therefore, when determining that test cases with the same test capabilities appear, the present invention adopts a random strategy to select one of the test cases to remove until only one test case with the same test capability remains, which ensures that the priorities are effectively sorted based on the test capabilities and further improves the test value of the test cases.

[0085] Figure 3 This is a structural block diagram of a test case sorting device provided by another embodiment of the present invention. This embodiment is applicable to the case of determining the priorities of different test cases in a test case set. The device can be implemented in software and / or hardware and can be configured in a computing device with corresponding data processing capabilities. Figure 3 As shown, the device may include:

[0086] Probability calculation module 310, used to calculate the defect probability of each class shared by the software version to be tested and the historical version;

[0087] A capability determination module 320, for calculating the test capability of each test case according to the defect susceptibility probability of each class;

[0088] The priority sorting module 330 is used to sort each of the test cases according to the test capability of each of the test cases to obtain a priority sorting result of the test cases. Optionally, the probability calculation module 310 includes a priori probability determination unit, a conditional probability determination unit, and a comprehensive probability calculation unit.

[0089] The device and module can execute the test case sorting method provided by any embodiment of the present invention, and have functional modules and beneficial effects corresponding to the execution method.

[0090] The prior probability determination unit is used to determine the prior probability of each class being modified and the prior probability of each class not being modified according to the modification amount of each class shared by the software version to be tested and the historical version.

[0091] The conditional probability determination unit is used to estimate the conditional probability that the modified part and the unmodified part of each class contain defects according to the incoming coupling metric value and the outgoing coupling metric value of each class.

[0092] The comprehensive probability calculation unit is used to calculate the defect-prone probability of each class based on the modified prior probability and the unmodified prior probability of each class, and the conditional probability that the modified part and the unmodified part of each class contain defects.

[0093] Optionally, the conditional probability determination unit includes a modified conditional probability calculation subunit and an unmodified conditional probability calculation subunit.

[0094] The modification conditional probability calculation subunit is used to estimate the conditional probability that the modified part of each class contains defects according to the ratio of the incoming coupling metric value of each class to the maximum incoming coupling metric value.

[0095] The unmodified conditional probability calculation subunit is used to estimate the conditional probability that the unmodified part of each class contains defects according to the ratio of the outgoing coupling metric value of each class to the maximum outgoing coupling metric value.

[0096] The comprehensive probability calculation unit includes a first probability calculation subunit, a second probability calculation subunit and a comprehensive probability calculation subunit.

[0097] The first probability calculation subunit is used to multiply the modified prior probability of each class by the conditional probability of the modified part to obtain a first probability of the class.

[0098] The second probability calculation subunit is used to multiply the unmodified prior probability of each class by the conditional probability of the unmodified part to obtain the second probability of the class.

[0099] The comprehensive probability calculation subunit is used to add the first probability of each class to the second probability to obtain the defect susceptibility probability of each class.

[0100] Optionally, the capability determination module 310 is specifically used to, for each test case, multiply the defect probability of each class by the coverage value of the test case for the corresponding class in the historical version to obtain the test capability of the test case for each class; and add the test capabilities of the test case for each class to obtain the test capability of the test case.

[0101] Optionally, the priority sorting module 330 includes a test case removal unit and a sorting result determination unit.

[0102] The test case removal unit is used to remove the test case with the maximum value of the current test capability from the test case set, and add the removed test case to the result sequence which is initially empty.

[0103] The sorting result determination unit is used to repeat the above-mentioned removal and addition operations until all test cases in the test case set are removed, and the test cases arranged in the result sequence according to the order of addition are the priority sorting result.

[0104] Optionally, the test case removal unit is further used to adopt a random strategy to select one of the test cases to remove if there is more than one test case with the maximum value of the current test capability.

[0105] The above-mentioned devices, modules, units and sub-units after further explanation can execute the test case sorting method provided by any embodiment of the present invention, and have the corresponding functional modules and beneficial effects of the execution method.

[0106] Figure 4 A schematic diagram of a computing device provided in accordance with another embodiment of the present invention is shown in FIG. Figure 4 As shown, the device includes a processor 40, a memory 41, an input device 42 and an output device 43; the number of processors 40 in the device can be one or more. Figure 4 A processor 40 is taken as an example; the processor 40, memory 41, input device 42 and output device 43 in the device can be connected by a bus or other means. Figure 4 The example of connecting through bus is taken in the following.

[0107] The memory 41, as a computer-readable storage medium, can be used to store software programs, computer executable programs and modules, such as program instructions / modules corresponding to the test case sorting in the embodiment of the present invention (for example, the probability calculation module 301, the capability determination module 302 and the priority sorting module 303 in the test case sorting device). The processor 40 executes various functional applications and data processing of the device by running the software programs, instructions and modules stored in the memory 41, that is, realizes the above-mentioned test case sorting method.

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

[0109] The input device 42 may be used to receive input digital or character information and generate key signal input related to user settings and function control of the device / terminal / server. The output device 43 may include a display device such as a display screen.

[0110] Another embodiment of the present invention further provides a storage medium containing computer executable instructions, wherein the computer executable instructions are used to perform a trial case sorting method when executed by a computer processor, the method comprising:

[0111] Calculate the defect probability of each class shared by the software version under test and the historical version;

[0112] Calculate the test capability of each test case based on the defect probability of each class;

[0113] The test cases are sorted according to their test capabilities to obtain a priority sorting result of the test cases.

[0114] Of course, the computer executable instructions of a storage medium containing computer executable instructions provided by an embodiment of the present invention are not limited to the operations of the method described above, and can also execute related operations in the test case sorting method provided by any embodiment of the present invention.

[0115] Through the above description of the implementation methods, the technicians in the relevant field can clearly understand that the present invention can be implemented by means of software and necessary general hardware, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ROM), random access memory (RAM), flash memory (FLASH), hard disk or optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods described in each embodiment of the present invention.

[0116] It is worth noting that in the embodiment of the above-mentioned search device, the various units and modules included are only divided according to functional logic, but are not limited to the above-mentioned division, as long as the corresponding functions can be achieved; in addition, the specific names of the functional units are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of the present invention.

[0117] Note that the above are only preferred embodiments of the present invention and the technical principles used. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of the present invention, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A test case sorting method, characterized in that: include: Calculate the defect probability of each class shared by the software version under test and the historical version; Calculate the test capability of each test case based on the defect probability of each class; Sorting each of the test cases according to the test capability of each of the test cases to obtain a priority sorting result of the test cases; The defect probability of each class shared by the software version under test and the historical version is calculated, including: Determine the prior probability that each class is modified and the prior probability that each class is not modified according to the modification amount of each class shared by the software version to be tested and the historical version; According to the incoming coupling metric and the outgoing coupling metric of each class, the conditional probability that the modified part and the unmodified part of each class contain defects is estimated; The defect-prone probability of each class is calculated based on the prior probability of each class being modified and the prior probability of each class not being modified, and the conditional probability that the modified part and the unmodified part of each class contain defects.

2. The method according to claim 1, characterized in that According to the incoming coupling metric and the outgoing coupling metric of each class, the conditional probability that the modified part and the unmodified part of each class contain defects is estimated, including: Estimate the conditional probability that the modified part of each class contains a defect based on the ratio of the afferent coupling metric of each class to the maximum afferent coupling metric; Based on the ratio of the outgoing coupling metric of each class to the maximum outgoing coupling metric, the conditional probability that the unmodified part of each class contains a defect is estimated.

3. The method according to claim 2, characterized in that Based on the prior probability of each class being modified and the prior probability of each class not being modified, and the conditional probability that the modified part and the unmodified part of each class contain defects, the defect-prone probability of each class is calculated, including: Multiply the modified prior probability of each class by the conditional probability of the modified part to obtain the first probability of the class; Multiply the unmodified prior probability of each class by the conditional probability of the unmodified part to obtain the second probability of the class; The first probability of each class is added to the second probability to obtain the defect proneness probability of each class.

4. The method according to claim 1, characterized in that: Calculate the test capability of each test case based on the defect probability of each class, including: For each test case, respectively multiply the defect probability of each class by the coverage value of the test case for the corresponding class in the historical version to obtain the test capability of the test case for each class; The test capability of the test case for each class is added together to obtain the test capability of the test case.

5. The method according to claim 1, characterized in that The test cases are sorted according to the test capabilities of the test cases to obtain a priority sorting result of the test cases, including: Remove the test case with the largest current test capability value from the test case set, and add the removed test case to the initially empty result sequence; The above-mentioned removal and addition operations are repeated until all test cases in the test case set are removed, and the test cases in the result sequence arranged in the order of addition are the priority sorting result.

6. The method according to claim 5, characterized in that Remove the test cases with the largest current test capability value from the test case set, including: If there is more than one test case with the largest value of the current test capability, a random strategy is used to select one of the test cases to remove.

7. A test case sorting device, characterized in that: include: The probability calculation module is used to calculate the probability of defects in each class shared by the software version under test and the historical versions; A capability determination module is used to calculate the test capability of each test case based on the defect susceptibility of each class; A priority sorting module is used to sort each of the test cases according to the test capability of each of the test cases to obtain a priority sorting result of the test cases; Wherein, the probability calculation module includes: A priori probability determination unit, used to determine the priori probability of each class being modified and the priori probability of each class not being modified according to the modification amount of each class shared by the software version to be tested and the historical version; a conditional probability determination unit, for estimating the conditional probability that the modified part and the unmodified part of each class contain defects according to the incoming coupling metric value and the outgoing coupling metric value of each class; The comprehensive probability calculation unit is used to calculate the defect-prone probability of each class based on the prior probability of each class being modified and the prior probability of each class not being modified, and the conditional probability that the modified part and the unmodified part of each class contain defects.

8. A computing device, characterized in that include: one or more processors; A storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the test case sorting method as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the test case sorting method as described in any one of claims 1 to 6 is implemented.

Images