Test case optimization method, device, equipment and storage medium

Abstract

The embodiment of the present application discloses a test case optimization method, apparatus, device and storage medium, the method comprising: determining a first test case set based on detected software defects and initial test cases used before defect repair; performing path analysis on the software after defect repair to obtain difference nodes between the first path set before defect repair and the second path set after defect repair; generating initial coverage test data based on the difference nodes, and determining a second test case set based on the initial coverage test data; screening the first test case set and the second test case set to obtain a third test case set corresponding to the software after defect repair. This generates a test case set with high coverage, while achieving the purpose of controlling test time and reducing test costs, and ultimately improving overall test efficiency.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of software testing, and are related to but not limited to a test case optimization method, apparatus, device and storage medium. Background Art

[0002] Regression testing is to retest only the modified parts after the software is modified, so as to achieve the same test coverage as full testing. Regression testing has become the most common testing method in software testing.

[0003] When using regression testing in related technologies, the focus is on how to select effective regression test cases. However, whether selecting all the early test cases or some of the early test cases, it ignores the possibility of new problems being introduced when fixing defects, and fails to perform targeted testing on the new problems, resulting in problems such as long testing time, high testing costs, and low test coverage, which affects testing efficiency. Summary of the Invention

[0004] In view of this, embodiments of the present application provide a test case optimization method, apparatus, device, and storage medium.

[0005] The technical solution of the embodiment of the present application is implemented as follows:

[0006] The present invention provides a test case optimization method, including:

[0007] Determining a first test case set based on the detected software defects and initial test cases used before defect repair;

[0008] Performing path analysis on the software after defect repair to obtain difference nodes between a first path set before defect repair and a second path set after defect repair;

[0009] generating initial coverage test data based on the difference nodes, and determining a second test case set based on the initial coverage test data;

[0010] The first test case set and the second test case set are screened to obtain a third test case set corresponding to the software after defect repair.

[0011] In some embodiments, determining a defect test case corresponding to the software defect includes:

[0012] When the initial test cases include a test case associated with the software defect, determining the test case as the defect test case;

[0013] When the initial test cases do not include a test case associated with the software defect, obtain description information of the software defect, the description information including at least the affected version, prerequisites, test steps and expected results; based on the description information, determine the defect test case corresponding to the software defect.

[0014] In some embodiments, obtaining the importance, defect level, and execution time of current test data includes:

[0015] Analyze the requirement analysis document of the software after the defect is fixed to obtain an analysis result, and obtain the importance based on the analysis result;

[0016] Determining the defect level by the level of the software defect;

[0017] The execution time of the current test data is determined as the execution time.

[0018] In some embodiments, screening the first test case set and the second test case set to obtain a third test case set corresponding to the software after defect repair includes:

[0019] Merging the first test case set and the second test case set to obtain a merged test case set;

[0020] Deleting duplicate test cases in the merged test case set to obtain a non-redundant test case set;

[0021] The third test case set is determined based on the preset test case coverage and the non-redundant test case set.

[0022] The present invention provides a test case optimization device, comprising:

[0023] A first determination module is configured to determine a first test case set based on the detected software defects and the initial test cases used before defect repair;

[0024] An analysis module, configured to perform path analysis on the software after defect repair, and obtain difference nodes between a first path set before defect repair and a second path set after defect repair;

[0025] a second determination module, configured to generate initial coverage test data based on the difference nodes, and determine a second test case set based on the initial coverage test data;

[0026] The screening module is used to screen the first test case set and the second test case set to obtain a third test case set corresponding to the software after defect repair.

[0027] The present invention provides a test case optimization device, which includes:

[0028] processor; and

[0029] a memory for storing a computer program executable on the processor;

[0030] Wherein, when the computer program is executed by the processor, the steps of the above-mentioned test case optimization method are implemented.

[0031] An embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. The computer-executable instructions are configured to execute the steps of the above-mentioned test case optimization method.

[0032] The embodiments of the present application provide a test case optimization method, apparatus, device and storage medium. When a software defect is detected, a first test case set is determined based on the software defect and the initial test data used before the defect is repaired. Then, a path analysis is performed on the software after the defect is repaired, and the first path set before the defect is repaired and the second path set after the defect is repaired are analyzed to obtain the difference node between the two path sets. Then, initial coverage test data is generated based on the difference node, and a second test case set is determined based on the initial coverage test data. Finally, the first test case set and the second test case set are screened to obtain a third test case set corresponding to the software after the defect is repaired. In this way, not only the initial test data and the first test case set related to the software defect are obtained, thereby covering the test of the software defect; but also the difference node between the first path set before the defect repair and the second path set after the defect repair is analyzed, and the initial coverage test data is determined based on the difference node, and the second test case related to the difference node is further determined to cover the new problem test caused by the path change; the first test case set and the second test case set are screened to control the test time, and the third test case set corresponding to the software after the defect repair is obtained, thereby generating a test case set with high coverage, while achieving the purpose of controlling the test time and reducing the test cost, and ultimately improving the overall test efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In the drawings, which are not necessarily drawn to scale, like reference numerals may describe similar components throughout the different views.The drawings illustrate generally, by way of example and not limitation, various embodiments discussed herein.

[0034] Figure 1 A schematic diagram of an implementation flow of the test case optimization method provided in an embodiment of the present application;

[0035] Figure 2 A schematic diagram of another implementation flow of the test case optimization method provided in an embodiment of the present application;

[0036] Figure 3 A schematic diagram of another implementation flow of the test case optimization method provided in an embodiment of the present application;

[0037] Figure 4 A schematic diagram of another implementation flow of the test case optimization method provided in an embodiment of the present application;

[0038] Figure 5 A schematic diagram of the structure of the test case optimization device provided in an embodiment of the present application;

[0039] Figure 6 A schematic diagram of the composition structure of the test case optimization device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0040] In order to make the purpose, technical solutions and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limiting this application. All other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0041] In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0042] In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0043] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0044] To address the problems in the related art, embodiments of the present application provide a test case optimization method. The method provided by embodiments of the present application can be implemented by a computer program. When executed, the computer program completes each step of the test case optimization method provided by embodiments of the present application. In some embodiments, the computer program can be executed by a processor in an electronic device. Figure 1A schematic diagram of an implementation flow of the test case optimization method provided in the embodiment of the present application is shown as follows: Figure 1 As shown, the method includes:

[0045] Step S101 : determining a first test case set based on detected software defects and initial test cases used before defect repair.

[0046] Here, software defects (bugs) can be protocol defects, security policy defects, logic defects, etc. Software defects will cause the software to be unable to complete corresponding functions, or only complete part of the functions, thereby making the software unable to achieve all the expected functions.

[0047] After designing and writing a piece of software, initial test cases are needed to verify that the software performs its intended functions. These initial test cases can be directly obtained from a default database or designed specifically by the designer based on the software's functional characteristics. When selecting or designing initial test cases, the overall functionality of the software is considered, without taking into account any potential defects.

[0048] Based on this, a defect test case corresponding to the software defect is determined, and then the test case corresponding to the software defect and the initial test case are merged to obtain a first test case.

[0049] Step S102 : performing path analysis on the software after defect repair to obtain difference nodes between a first path set before defect repair and a second path set after defect repair.

[0050] Here, performing path analysis on the software is equivalent to performing path analysis on the code or programs included in the software. All paths traversed by the software during runtime before the bug fix is ​​performed are referred to as the first path set, while all paths traversed by the software during runtime after the bug fix is ​​performed are referred to as the second path set. Path analysis includes path search, path determination, and identification of nodes along the paths. By analyzing the path of the software after the bug fix is ​​performed, all paths in the second path set and all nodes along each path can be obtained. Furthermore, since the relevant information about the software before the bug fix is ​​known, all paths in the first path set and all nodes along each path are also known.

[0051] The first and second path sets are analyzed to determine the different nodes on the same path in the two path sets, and the different nodes in the two path sets are identified as different nodes. The different nodes may be nodes removed from the second path set compared to the first path set, nodes added to the second path set compared to the first path set, or both nodes removed and nodes added to the second path set compared to the first path set.

[0052] Step S103: Generate initial coverage test data based on the difference nodes, and determine a second test case set based on the initial coverage test data.

[0053] When implementing step S103, if the difference nodes are that the second path set has some nodes deleted compared to the first path set, these deleted nodes are found, and then the test data associated with these deleted nodes is determined. The test data associated with the deleted nodes is deleted from the initial test data to form the initial coverage test data. If the difference nodes are that the second path set has some nodes added compared to the first path set, these added nodes are found, and then the test data associated with these added nodes is determined. The test data associated with the deleted nodes is added to the initial test data to form the initial coverage test data.

[0054] Furthermore, the test case set is determined starting from the path with the most nodes covered by the initial coverage test data. First, the path with the most nodes covered by the initial coverage test data is determined as the current coverage path, and all paths through which the difference nodes pass are determined as paths to be covered. Then, the relevant nodes in the second path set that are associated with the nodes in the target path are determined, wherein the target path is the path in the first path set that includes the difference nodes. Then, the test data of each node on all paths where these relevant nodes are located is obtained, and the test data and the test data in the first test case set are determined as the initial test data set. Then, the output test case set is obtained through the initial test data set and the preset data model. Finally, the output test case set that meets the coverage condition is determined as the second test case set. For example, when the preset data model is a genetic algorithm, the initial test data set is the initial population, and the output test case set is the final population.

[0055] Step S104: Screen the first test case set and the second test case set to obtain a third test case set corresponding to the software after defect repair.

[0056] Here, the third test case set is the final test case set required, which is used to test the software after the defects are corrected.

[0057] In an embodiment of the present application, the first test case set and the second test case set can be directly merged, and duplicate test cases in the merged set can be deleted to obtain a third test case set.

[0058] In some embodiments, the first test case and the second test case can be merged to obtain a merged test case set; then, the duplicate test cases in the merged test case set are deleted to obtain a non-redundant test case set; finally, based on the preset test case coverage and the non-redundant test case set, a third test case set is determined. For example, when the preset test case coverage is 100%, that is, when the test case coverage reaches full coverage, the non-redundant test case set is directly determined as the third test case set.

[0059] The embodiments of the present application provide a test case optimization method, apparatus, device and storage medium. When a software defect is detected, a first test case set is determined based on the software defect and the initial test data used before the defect is repaired. Then, a path analysis is performed on the software after the defect is repaired, and the first path set before the defect is repaired and the second path set after the defect is repaired are analyzed to obtain the difference node between the two path sets. Then, initial coverage test data is generated based on the difference node, and a second test case set is determined based on the initial coverage test data. Finally, the first test case set and the second test case set are screened to obtain a third test case set corresponding to the software after the defect is repaired. In this way, not only the initial test data and the first test case set related to the software defect are obtained, thereby covering the test of the software defect; but also the difference node between the first path set before the defect repair and the second path set after the defect repair is analyzed, and the initial coverage test data is determined based on the difference node, and the second test case related to the difference node is further determined to cover the new problem test caused by the path change; the first test case set and the second test case set are screened to control the test time, and the third test case set corresponding to the software after the defect repair is obtained, thereby generating a test case set with high coverage, while achieving the purpose of controlling the test time and reducing the test cost, and ultimately improving the overall test efficiency.

[0060] Based on the above embodiments, the present application further provides a test case optimization method, such as Figure 2 As shown, the method can be implemented by following steps S201 to S219:

[0061] Step S201: Obtain software defects detected in the last test.

[0062] When testing and verifying software through a testing tool, the testing tool can detect software defects in the software and output relevant information about the software defects in the form of prompt information.

[0063] Step S202: Determine whether the initial test cases include test cases associated with software defects.

[0064] Search all defect test cases from the initial test cases and determine the defects corresponding to all defect test cases. If the defects include software defects or defects similar to software defects, it indicates that the initial test cases include test cases associated with software defects, and execute step S203; if the defects do not include software defects and defects similar to software defects, it indicates that the initial test cases do not include test cases associated with software defects, and execute step S204.

[0065] Step S203: Determine the test case associated with the software defect as a defect test case.

[0066] At this time, it indicates that the defect corresponding to the initial test case includes a software defect or a defect similar to the software defect, then the test case corresponding to the defect associated with the software defect is directly determined as the defect test case.

[0067] Step S204: Obtain description information of the software defect, and determine a defect test case corresponding to the software defect based on the description information.

[0068] At this time, the initial test cases do not include defect test cases, so the description information of the defect itself is obtained, wherein the description information at least includes common information items of the use case, such as the affected version, prerequisites, test steps and expected results.

[0069] Furthermore, common use case information items such as impact version, prerequisites, test steps and expected results are converted one by one into defect use cases corresponding to the defects.

[0070] Step S205 , synthesize the defect test case and the initial test case to obtain a first test case set.

[0071] Here, if the initial test cases include all defective test cases, then the initial test cases are the result of combining the defective test cases and the initial test cases. That is, the initial test cases can be determined as the first test case set. If the initial test cases do not include all defective test cases, then the defective test cases are merged with the test cases in the initial test cases to obtain a merged test case set, and the merged test case set is determined as the first test case set.

[0072] Step S206 : performing path analysis on the software after defect repair to obtain difference nodes between the first path set before defect repair and the second path set after defect repair.

[0073] The first and second path sets are analyzed. If the two path sets share the same path, the different nodes on the same path in the two path sets are identified and considered differential nodes. These differential nodes can be nodes removed from the second path set compared to the first path set, nodes added to the second path set, or both nodes removed and nodes added to the second path set. Alternatively, if the two path sets share different paths, the nodes on the entire different path are considered differential nodes.

[0074] Step S207 : determining operation information for the difference node and difference test data related to the difference node when repairing the defect.

[0075] Analyze the operation information for the difference node. For example, if the difference node is a node that has some nodes removed from the second path set compared to the first path set, the operation information is determined to be a deletion operation; if the difference node is a node that has some nodes added to the second path set compared to the first path set, the operation information is determined to be an addition operation. Furthermore, based on the difference node, differential test data related to the difference node is determined from the initial test data.

[0076] Step S208: Determine whether the operation information is a delete operation.

[0077] If the operation information indicates that a different node has been deleted, that is, if the operation information is a delete operation, step S209 is executed; if the operation information indicates that a different node has been added, that is, if the operation information is an add operation, step S210 is executed. Furthermore, if the different nodes are that the second path set has both some nodes deleted and others added compared to the first path set, step S209 is executed for the deleted nodes, and step S210 is executed for the added nodes.

[0078] Step S209 , deleting the difference data corresponding to the deleted difference node from the initial test data of the initial test case to generate initial coverage test data.

[0079] Step S210 , merging the initial test data and the difference data corresponding to the added difference nodes to generate initial coverage test data.

[0080] Step S211: Determine the current covered path and the path to be covered.

[0081] Here, in the second path set, the path with the most covered path nodes by the initial coverage test data is determined as the current covered path. In the second path set, all paths through which the difference nodes pass are determined as paths to be covered.

[0082] Step S212: determine the relevant nodes in the second path set that are associated with the nodes in the target path, and obtain the test data of all nodes on the path where the relevant nodes are located; and determine the test data of all nodes on the path where the relevant nodes are located and the test data of the first test case set as the initial input test data set.

[0083] When implementing step S212, the target path is the path in the first path set that includes the difference node. The difference node included in the first path set before the defect is repaired is obtained, and then the path on which the difference node is located in the first path set is obtained. All nodes on the path are marked. After the defect is repaired, relevant nodes such as the marked node, the marked node's parent node, the marked node's child nodes, and the marked node's sibling nodes are determined in the second path set. All paths traversed by the relevant node are determined, and test data for all nodes on all these paths is obtained. Here, the nodes on all paths traversed by the relevant node are the nodes most relevant to the defect. Therefore, these paths and nodes are the focus of post-repair testing.

[0084] Step S213: input the initial input test data set into a preset data model to obtain an output test case set.

[0085] Here, the preset data model can be an artificial intelligence algorithm such as a genetic algorithm model, a logistic regression algorithm model, a Bayesian classification algorithm model, a neural network algorithm model, etc.

[0086] The initial input and output test data sets can be optimized and transformed into output test case sets through the preset data model.

[0087] Step S214: determine whether the output test case set meets the coverage condition.

[0088] Here, the coverage condition includes two meanings. One is whether the output test case set can fully cover the nodes on the current coverage path; the other meaning is whether the output test case set can fully cover the nodes on all paths to be covered. When the output test case set can fully cover the nodes on the current coverage path and all nodes on the paths to be covered, the output test case set is considered to meet the coverage condition, and step S215 is executed; if the output test case set can neither fully cover the nodes on the current coverage path nor fully cover all nodes on the paths to be covered, the output test case set is considered to not meet the coverage condition, and step S216 is executed.

[0089] In some embodiments, the output test case set meeting the coverage condition can be achieved by the following method: when all nodes on the current coverage path are covered by the output test cases, the next path is selected from the path to be covered, the initial input test data for the next path is updated preferentially, and the output test case coverage corresponding to all nodes on the next path is determined; then another path is selected from the path to be covered, and this cycle is repeated until all output test cases corresponding to the nodes on the path to be covered are found, and finally, the obtained output test case set meets the coverage condition.

[0090] Step S215: Determine the output test case set as the second test case set.

[0091] At this point, the output test case set satisfies the coverage condition, the output test case set can cover all nodes on the current coverage path and the path to be covered, and there are no redundant cases in the output test case set. Here, the output test case set is directly determined as the required second test case set.

[0092] Step S216: determining an intervention factor based on the initial coverage test data.

[0093] Here, the intervention factor is used to directionally change the test data in the initial input test data set.

[0094] At this point, the output test case set does not meet the coverage condition, so the required second test case set cannot be further determined. Then, an intervention factor is determined based on the initial coverage test data to change the output test case set. Taking the genetic algorithm as an example, the intervention factor can be the selection operator, crossover operator, and mutation operator in the genetic algorithm. Taking the mutation operator as an example, in general, the mutation operator is uncontrollable and random, that is, it causes the output test case set to mutate in an uncertain direction. In an embodiment of the present application, the encoding string of each data in the initial coverage test data and the gene value on the encoding string are analyzed, and a new mutation operator is determined based on the gene value, so that the initial input and output test data set mutates in the direction of the gene value, and affects the output test case set to mutate in a determined direction.

[0095] Step S217: determining a new input test data set based on the intervention factor and the initial input test data set.

[0096] During step S217, each test data point on all paths in the initial input test data set is obtained, and the gene value of the code string on each test data point is determined. The gene value of the code string on each test data point is then altered using the intervention factor, making the gene value of the code string on each test data point similar to the gene value of the code string on each data point in the initial coverage test data. The corresponding test data set after the altered code string gene value is determined as the new input test data set. Next, to obtain the second test case set, step S213 is executed.

[0097] Step S218: merge the first test case set and the second test case set to obtain a merged test case set.

[0098] The first test case in the first test case set in step S205 is obtained, and the second test case in the second test case set in step S215 is obtained at the same time, and the first test case and the second test case are merged to obtain a merged test case set.

[0099] Step S219: Delete duplicate test cases in the merged test case set to obtain a non-redundant test case set; and then determine the third test case set based on the preset test case coverage and the non-redundant test case set.

[0100] When implementing step S219, duplicate test cases in the merged test case set are determined, and then the duplicate test cases are deleted to obtain a test case set without duplicate test cases, which is called a non-redundant test case set.

[0101] Furthermore, the test case coverage refers to the ratio of the number of nodes covered by the test case set to the total number of nodes. In an embodiment of the present application, the preset test coverage can be 100%, that is, the test case set covers all nodes. In this case, the non-redundant test case is directly determined as the third test case set. Here, since the current coverage path and the path to be covered determined in step S211 are the paths most relevant to the software defect, that is, all paths affected by the software modification due to the repair of the software defect. Based on this, the determined second test case set can fully cover all nodes on the current coverage path and the path to be covered. Finally, when the final third test case set is determined based on the first test case set and the second test case set, the preset test coverage is set to 100%, that is, the third test case also needs to fully cover all nodes on the current coverage path and the path to be covered, which is equivalent to the third test case covering all paths and nodes on the paths related to the software defect. In this way, the test case set with the highest coverage can be formed, thereby improving the test efficiency and achieving the best test effect.

[0102] In the embodiment of the present application, through the above steps S201 to S219, the defect test case corresponding to the software defect is first determined, and then the defect test case and the initial test case are synthesized to obtain a first test case set for the software defect; then, a path analysis is performed on the software after the defect is repaired, and the difference nodes between the first path set before the defect repair and the second path set after the defect repair are obtained through analysis, and then the initial coverage test data is determined based on the operation information of the difference node, the relevant difference test data of the difference node and the initial test data; further, the current coverage path is determined based on the initial coverage test data, the path to be covered is determined based on the difference node, and the nodes in the target path and the nodes in the second path set are also determined. Related nodes associated with nodes in a target path, wherein the target path is a path including difference nodes in a first path set, and then an initial input test data set is determined based on the test data of the nodes in the target path, the related nodes, and the test data in the first test case set, and the initial input test data set is input into a preset data model to obtain an output test case set, and the output test case set that meets the coverage condition is determined as a second test case set; finally, the first test case set and the second test case set are merged to obtain a merged test case set, duplicate test cases in the merged test case set are deleted to obtain a non-redundant test case set, and then a third test case set is determined based on the preset test case coverage and the non-redundant test case set. At the same time, if the output test case set does not meet the coverage condition, an intervention factor is generated based on the initial coverage test data to directionally change the initial input test data set and generate a new input test data set to make the preset data model output an output test case set that meets the coverage condition. In this way, test cases targeting software defects and related nodes are determined, so that the test direction of the test cases is accurately positioned and the test coverage is flexible and changeable, while achieving the purpose of controlling the test time and reducing the test cost, ultimately improving the test efficiency and achieving better test results.

[0103] In some embodiments, after step S215, as Figure 3 As shown, the following steps S301 to S309 may also be performed:

[0104] Step S301 : determining the number of different nodes between the current covered path and the path to be covered, and determining the ratio of the number of different nodes to the total number of nodes in the path to be covered as the layer proximity similarity.

[0105] Here, the difference nodes between the current covered path and the path to be covered are obtained, and then based on the ratio of the difference nodes to the total number of nodes in the path to be covered, the similarity between the two paths is determined and recorded as the hierarchical similarity.

[0106] Step S302 : determining the distance between the test node where the current test data is located and a node at the same level as the test node.

[0107] Here, the distance refers to the number of nodes passed from one node to another node. In the embodiment of the present application, the nodes at the same level as the test node where the current test data is located are first obtained, and then the distance between the test node and the nodes at the same level is determined.

[0108] Step S303 , analyzing the requirement analysis document of the software after defect repair to obtain analysis results, and obtaining the importance based on the analysis results.

[0109] By analyzing the requirements document, we can understand the functionality that the software is supposed to accomplish. Based on this functionality, we can determine the importance of the current test data. For example, if the current test data is essential to achieving the functionality, then the current test data is considered to be of high importance.

[0110] Step S304: Determine the defect level according to the level of the software defect.

[0111] Step S305: determining the execution time of the current test data as the execution time.

[0112] Step S306 : determining the judgment function according to the layer proximity, the distance, the importance, the defect level, and the inverse of the execution time.

[0113] When implementing step S306, since shorter execution time is more conducive to testing, and higher layer proximity, distance, importance, and defect level are more conducive to testing, a judgment function can be determined based on the inverse of layer proximity, distance, importance, defect level, and execution time. This judgment function can be used to determine the quality of the current test data.

[0114] For example, the layer proximity is denoted as Appr n (x), the branch distance is recorded as Dist n (x), the test case importance is recorded as CaseI n (x), the defect level is recorded as BugL n (x), the execution time is recorded as CaseE n (x), for the modified software in different places, the corresponding weight factors α, β and γ can be assigned to each factor respectively, where α≠β≠γ, α+β+γ=1, then the judgment function can be expressed as the following formula (1):

[0115]

[0116] Step S307: Based on the judgment function, it is judged whether the test data in the initial input test data set meets the judgment value.

[0117] Here, the judgment value can be 70%, 75%, etc. Meeting the judgment value can be considered to be not less than the judgment value. When the test data in the initial input test data set meets the judgment value, it indicates that the test data is excellent, and step S308 is executed; when the test data in the initial input test data set does not meet the judgment value, it indicates that the test data is poor, and step S309 is executed.

[0118] Step S308: Determine the input test data set that meets the judgment value as the next input test data set.

[0119] At this point, the test data is of high quality and can be directly used as the next input test data set.

[0120] Step S309: Optimize the input test data set that does not meet the judgment value.

[0121] At this point, it indicates that the test data is poor and cannot be directly used as the next input test data set. At the same time, in order to prevent the output test case set from falling into a local optimum too early, another optimization search will be performed on the test data that does not meet the judgment value, and the optimization result will be put into the next input test data set.

[0122] In the embodiment of the present application, through steps S301 to S309, the importance, defect level and execution time of the current test data are introduced, and then combined with the layer proximity and distance to determine the judgment function to determine the quality of the test data. The better test data is directly used as the next input test data set. In order to avoid the problem of local optimality, the poorer test data will also be optimized and the optimized test data will be placed in the next input test data set. In this way, the initial input and output test data sets are judged and the better test data is selected for the next input test data set, so that the output test case set can reach the global optimality, thereby improving the test efficiency.

[0123] Based on the above embodiments, the present application further provides a method for automatically generating and optimizing test cases based on a genetic algorithm, which is applied to regression testing. Regression testing is the most common test in software testing. One of the goals of regression testing is to retest only the modified parts after the software is modified, thereby achieving the same test coverage as a full test. The key to regression testing is how to select effective regression test cases to ensure test effectiveness and improve test efficiency.

[0124] The existing regression testing mainly uses the following two methods for selecting use cases:

[0125] Method 1: Execute all the previous test cases.

[0126] During each regression test, all tests established in the previous testing phase are executed to confirm the correctness of the problem modification and whether it has adversely affected other functions and performance. This method is suitable for regression testing of any scope of software and has the lowest analysis and setup costs, but it has the problem of high test running costs.

[0127] Method 2: Selectively execute previous use cases.

[0128] During regression testing, only a subset of previous test cases is executed. Whether the subset selection is reasonable will directly affect the effectiveness and efficiency of regression testing. Currently, there are three commonly used test case selection methods.

[0129] (1) Testing limited to the scope of modification. Test cases are selected based on the content of the modification. This part of the test case only ensures that the modified defects or new functions in the software are covered by the test. The test efficiency is the highest, but the risk is also the greatest. It can be used when the project schedule is under great pressure or the system structure design has little coupling.

[0130] (2) Regression testing within the affected functional scope. This type of regression testing requires analyzing which functions or performance may be affected by the current modification. All test cases corresponding to all affected functions and performance will be regressed. However, determining which functions or performance will be affected depends on the experience of the test analyst. This method is only suitable for use in general projects.

[0131] (3) Select regression tests based on certain coverage indicators. This method is generally used when the scope of related functions and performance impact is difficult to define. The simplest strategy of this method is to stipulate that the test within the modification scope is 100%, and the test of other scopes stipulates a use case coverage threshold.

[0132] It is not difficult to find that existing research on regression test cases is basically based on the selection of original use cases, while ignoring targeted testing of problems that may be introduced when fixing defects. Based on this, the embodiment of the present application proposes a method for adaptively generating use cases based on discovered defects (bugs) to cover the parts of the problem that may be introduced by fixing the defects. Finally, the two test case sets are summarized and screened to finally generate a minimal regression test case set with maximum coverage, wider applicability, and the ability to discover more defects in a shorter time.

[0133] The embodiment of the present application is based on the test case generation technology of the genetic algorithm. By statically analyzing the path of the repair software, the nodes added, updated, and deleted on the original path are found, and the difference nodes are analyzed to generate initial coverage test data to guide the operation of the mutation operator in the genetic algorithm process. The initial population of the genetic algorithm is selected based on the modified path. Then, by introducing three factors: the importance of the test data covered by the node, the level of the defect found, and the execution time of the case, the fitness function and genetic operator of the genetic algorithm are improved to generate optimal test data covering the defect repair module. This is used to solve the problems of long testing time, high testing cost, and low test coverage in related technologies.

[0134] To address the problems of heavy testing workload and low testing efficiency caused by constantly fixing defects in software during regression testing, a new regression test case automatic generation and optimization method based on genetic algorithms is proposed by combining test case selection with test case automatic generation technology. This method can be implemented by following the steps 1 and 2:

[0135] Step 1: Check whether the submitted bug has associated test cases. If so, keep the test case; if not, directly convert the bug into a test case for the next regression test, and record the combined test case set as T1; taking the tool Jira as an example, based on Jira's own functions, by setting the bug's affected version, prerequisites, test steps, expected results and other common use case information items in the "Description", and by reading the name, priority, description and other information, the bugs are converted one by one into use cases to form the test case set T1.

[0136] Step 2: Through static analysis of the repaired software path, nodes are added, updated, and deleted from the original path, and differential nodes are analyzed to generate initial coverage test data, which is used to guide the mutation operator operation in the genetic algorithm process. The initial population of the genetic algorithm is selected based on the modified path. Then, by introducing three factors, namely the importance of the test data covered by the nodes, the level of the defects found, and the execution time of the use case, the fitness function and genetic operators of the genetic algorithm are improved. Based on the improved genetic algorithm, a test data model is generated, and finally, the test case set T2 affected by the software modification is automatically generated.

[0137] When constructing the fitness function of the genetic algorithm in step 2, the layer proximity of the software path node Appr n (x) and branch distance Dist n (x), and introduce the test case importance CaseI of the covered node n (x), Defect level BugL n (x), execution time Case E n(x) and other factors, and assign corresponding weight factors α, β, and γ to each factor for the modified software in different places, where α≠β≠γ, α+β+γ=1, so as to design a more reasonable standard to judge the quality of a feasible solution. The specific formula is shown in the above formula (1).

[0138] in:

[0139]

[0140]

[0141]

[0142] In formula (2), the value of layer proximity is the closer the path p(x) covered by the current individual x is to the path P to be covered k The number of different nodes and path P k The ratio of the total number of nodes; In formula (3), |c1-c2| is the expression between branch nodes. In order to distinguish the case where c1≠c2, a micro constant t is added. In formula (4), the importance of a test case is the ratio of the sum of the importance of the requirements p covered by the case to the total importance of all requirements m, and r represents the rth requirement. The importance of each test requirement is analyzed by the tester from the requirement analysis document, and the value is divided according to the actual situation. Defect level BugL n (x) is determined by the level of the bug submitted. n (x) is expressed in its reciprocal form. From the above formula (1), it can be seen that when the error severity level detected by the test case is higher, the importance value of the test case is higher, and the effective execution time of the test case is shorter, the test data on the path node is relatively better, which is conducive to quickly obtaining the optimal solution that meets the requirements.

[0143] In the embodiment of the present application, generating a test case set T2 for new problems caused by software modification can be achieved by following the steps S401 to S412:

[0144] Step S401: static analysis of the repair software path.

[0145] Mark the original path nodes according to the actual modification situation, then perform the corresponding operations of adding, changing, and deleting nodes, compare the nodes on the path before and after the software modification, and determine the different nodes.

[0146] Step S402: Generate initial coverage test data.

[0147] Analyze the difference nodes to generate initial coverage test data. For example, if the difference node is to delete node A and add nodes B and C, analyze and find the test data related to node A and delete it. Then analyze the test data related to nodes B and C and add it to the original test data to form the initial coverage test data.

[0148] Step S403: Generate a path to be covered.

[0149] All paths passing through different nodes are considered as paths to be covered.

[0150] Step S404: Generate an initial population.

[0151] Determine all paths passing through the marked node and its parent node, child node, and sibling node, and use the test data of all nodes on all paths and the test data of test case T1 in step 1 as the initial population of the genetic algorithm.

[0152] Step S405: assign values ​​to algorithm parameters.

[0153] The parameters in the genetic algorithm include population size, crossover probability, mutation probability, termination evolution generation, etc. When assigning parameters, the parameters can be assigned through human experience or through bit string decoding.

[0154] Step S406: constructing a fitness function of the genetic algorithm.

[0155] Get the layer proximity Appr of the path node n (x), branch distance Dist n (x), the test case importance of the covered node CaseI n (x), Defect level BugL n (x) and execution time CaseE n (x); then, based on the current defect, determine the weight factors α, β, and γ corresponding to each factor, for example, α = 0.2, β = 0.3, γ = 0.5. The fitness function is determined based on formula (1).

[0156] Step S407: Calculate the fitness value of the initial population.

[0157] The fitness value of the initial population is calculated according to the fitness function, the quality of the population is evaluated, and the elite population with higher fitness value is retained and directly enters the second round of iteration; in addition, the population with lower fitness value is optimized again, and the optimization result can enter the second round of iteration.

[0158] Step S408: Determine whether the optimal solution set for the current target path is found.

[0159] If the retained elite population can cover all nodes on the current target path, it is considered that the optimal solution set for the current target path has been found, and step 409 is executed; if the retained elite population cannot cover all nodes on the current target path, it is considered that the optimal solution set for the current target path has not been found, and step S410 is executed.

[0160] Step S409: Determine whether the optimal solution for the path to be covered is found.

[0161] The judgment method of step S409 may refer to the judgment method of step S408. If the optimal solution of the path to be covered has been found, step S412 is executed; otherwise, step S410 is executed.

[0162] Step S410: determining a mutation operator based on the initial coverage test data.

[0163] The implementation of this step refers to the implementation steps of the above step S217.

[0164] Step S411: Directively generate a new population based on the mutation operator.

[0165] The implementation of this step refers to the implementation steps of the above step S217.

[0166] Step S412: output the test case set.

[0167] In this way, through steps S401 to S412, the repair software path is statically analyzed to analyze the difference nodes, and then the initial coverage test data and the path to be covered are generated based on the difference nodes; then, all nodes on the path where the defect is located before the repair and the paths where the related nodes are located are determined, the test data of these nodes are determined, and these test data and the test data of T1 are used as the initial population; then, the parameters are assigned values, a fitness function is constructed, and the fitness value of the initial population is calculated based on the fitness function. The test data with higher fitness values ​​directly enter the second round of iterative testing, while the test data with lower fitness values ​​enter the second round of iterative testing after optimization; finally, the optimal solution of the current target path and the path to be covered is determined as the second test case set. When the optimal solution cannot be determined, the mutation operator can be determined by the initial coverage test data, and then a new population is generated by the mutation operator to determine the optimal solution. In this way, a second test case set with a higher coverage rate can be generated, and the purpose of reducing testing costs can be achieved, thereby improving testing efficiency.

[0168] Based on the foregoing embodiments, the embodiments of the present application provide a test case optimization device, wherein the modules included in the device and the units included in each module can be implemented by a processor in a computer device; of course, they can also be implemented by a specific logic circuit; in the implementation process, the processor can be a central processing unit (CPU, Central Processing Unit), a microprocessor (MPU, Microprocessor Unit), a digital signal processor (DSP, Digital Signal Processing) or a field programmable gate array (FPGA, Field Programmable Gate Array), etc.

[0169] The present application embodiment further provides a test case optimization device, Figure 5 A schematic diagram of the structure of the test case optimization device provided in the embodiment of the present application is shown as follows: Figure 5 As shown, the test case optimization device 500 includes:

[0170] A first determination module 501 is configured to determine a first test case set based on the detected software defects and the initial test cases used before defect repair;

[0171] An analysis module 502 is configured to perform path analysis on the software after defect repair to obtain difference nodes between a first path set before defect repair and a second path set after defect repair;

[0172] A second determination module 503 is configured to generate initial coverage test data based on the difference nodes, and determine a second test case set based on the initial coverage test data;

[0173] The screening module 504 is configured to screen the first test case set and the second test case set to obtain a third test case set corresponding to the software after defect repair.

[0174] In some embodiments, the first determining module 501 includes:

[0175] A first determining unit, configured to determine a defect test case corresponding to the software defect;

[0176] A synthesis unit is used to synthesize the defect test case and the initial test case to obtain the first test case set.

[0177] In some embodiments, the first determining unit includes:

[0178] a first determining subunit, configured to determine the test case as the defect test case when the initial test case includes a test case associated with the software defect;

[0179] The second determination sub-unit is used to obtain descriptive information of the software defect when the initial test case does not include a test case associated with the software defect, the descriptive information including at least the affected version, prerequisites, test steps and expected results; and determine the defect test case corresponding to the software defect based on the descriptive information.

[0180] In some embodiments, the second determining module 503 includes:

[0181] a second determining unit, configured to determine operation information for the difference node and difference test data related to the difference node during defect repair;

[0182] a first generating unit, configured to, when the operation information indicates that there is a deleted difference node, delete the difference data corresponding to the deleted difference node from the initial test data of the initial test case to generate the initial coverage test data;

[0183] The second generating unit is configured to, when the operation information indicates that there is an added difference node, merge the initial test data with the difference data corresponding to the added difference node to generate the initial coverage test data.

[0184] In some embodiments, the second determining module 503 further includes:

[0185] A third determining unit is configured to determine, in the second path set, a path having the most covered path nodes by the initial coverage test data as a current covered path, and determine all paths through which the difference nodes pass as paths to be covered;

[0186] a fourth determining unit, configured to determine a related node in the second path set that is associated with a node in a target path, and obtain test data of all nodes on the path where the related node is located, wherein the target path is a path in the first path set that includes the difference node;

[0187] a fifth determining unit, configured to determine the test data of all nodes on the path where the relevant node is located and the test data of the first test case set as an initial input test data set;

[0188] An input unit, configured to input the initial input test data set into a preset data model to obtain an output test case set;

[0189] A sixth determination unit is used to determine the output test case set as the second test case set when the output test case set meets the coverage condition, wherein when the output test case set meets the coverage condition, the output test case set can cover all nodes on the current coverage path and the path to be covered, and there are no redundant cases in the output test case set.

[0190] In some embodiments, it is characterized in that the test case optimization device 500 further includes:

[0191] A third determination module is configured to determine an intervention factor based on the initial coverage test data, wherein the intervention factor is used to directionally change the test data in the initial input test data set;

[0192] A fourth determining module is configured to determine a new input test data set based on the intervention factor and the initial input test data set when the output test case set does not satisfy the coverage condition.

[0193] In some embodiments, the test case optimization apparatus 500 further includes:

[0194] An establishment module, configured to establish a determination function based on the current coverage path, the path to be covered, the importance of current test data, the defect level, and the execution time;

[0195] A selection module, configured to select an input test data set that meets a preset judgment value from the initial input test data set based on the judgment function;

[0196] The fifth determining module is configured to determine the input test data set that meets the determination value as the next input test data set.

[0197] In some embodiments, the establishing module includes:

[0198] a seventh determining unit, configured to determine the number of different nodes between the current covered path and the path to be covered, and determine the ratio of the number of different nodes to the total number of nodes in the path to be covered as the layer proximity similarity;

[0199] an eighth determining unit, configured to determine a distance between a test node where the current test data is located and a node at the same level as the test node;

[0200] The acquisition unit is used to obtain the importance, defect level and execution time of the current test data;

[0201] A ninth determining unit is configured to determine the judgment function according to the layer proximity, the distance, the importance, the defect level, and the inverse of the execution time.

[0202] In some embodiments, the acquiring unit includes:

[0203] An analysis subunit, configured to analyze a requirement analysis document of the software after defect repair, obtain an analysis result, and obtain the importance based on the analysis result;

[0204] a third determining subunit, configured to determine the defect level based on the level of the software defect;

[0205] The fourth determining subunit is configured to determine the execution time of the current test data as the execution time.

[0206] In some embodiments, the screening module 504 includes:

[0207] a merging unit, configured to merge the first test case set and the second test case set to obtain a merged test case set;

[0208] A deleting unit, configured to delete duplicate test cases in the merged test case set to obtain a non-redundant test case set;

[0209] The tenth determining unit is configured to determine the third test case set based on the preset test case coverage and the non-redundant test case set.

[0210] It should be noted that, in the embodiment of the present application, if the above-mentioned test case optimization method is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on such understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program code, such as a U disk, a mobile hard disk, a read-only memory (ROM, Read Only Memory), a magnetic disk or an optical disk. In this way, the embodiment of the present application is not limited to any specific combination of hardware and software.

[0211] Accordingly, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, characterized in that when the computer program is executed by a processor, the steps in the test case optimization method provided in the above embodiment are implemented.

[0212] The present invention provides a test case optimization device. Figure 6 A schematic diagram of the composition structure of the test case optimization device provided in the embodiment of the present application is shown as follows: Figure 6As shown, the test case optimization device 600 includes: a processor 601, at least one communication bus 602, a user interface 603, at least one external communication interface 604, and a memory 605. The communication bus 602 is configured to enable communication between these components. The user interface 603 may include a display screen, and the external communication interface 604 may include a standard wired interface and a wireless interface. The processor 601 is configured to execute the program of the test case optimization method stored in the memory to implement the steps of the test case optimization method provided in the above embodiment.

[0213] The description of the above electronic device and storage medium embodiments is similar to the description of the above method embodiments and has similar beneficial effects as the method embodiments. For technical details not disclosed in the electronic device and storage medium embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0214] It should be noted that the description of the above storage medium and device embodiments is similar to the description of the above method embodiments and has similar beneficial effects as the method embodiments. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0215] It should be understood that "one embodiment" or "an embodiment" mentioned throughout the specification means that the specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. The above-mentioned serial numbers of the embodiments of the present application are for description only and do not represent the advantages and disadvantages of the embodiments.

[0216] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0217] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0218] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units; they may be located in one place or distributed across multiple network units; some or all of the units may be selected according to actual needs to achieve the purpose of the embodiment of the present application.

[0219] In addition, all functional units in the embodiments of the present application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the above-mentioned integrated units can be implemented in the form of hardware or in the form of hardware plus software functional units.

[0220] Those skilled in the art will understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above-mentioned method embodiments; and the aforementioned storage medium includes: mobile storage devices, read-only memories (ROMs), magnetic disks, optical disks, and other media that can store program codes.

[0221] Alternatively, if the above-mentioned integrated unit of the present application is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application, or the part that contributes to the relevant technology, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling an AC to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROMs, magnetic disks or optical disks.

[0222] The above is merely an embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A test case optimization method, characterized in that: The method comprises: Determining a first test case set based on the detected software defects and initial test cases used before defect repair; Performing path analysis on the software after defect repair to obtain difference nodes between a first path set before defect repair and a second path set after defect repair; Initial coverage test data is generated based on the difference node, and a second test case set is determined based on the initial coverage test data; wherein, the second test case set is determined based on the initial coverage test data, including: in the second path set, determining the path with the most covered path nodes by the initial coverage test data as the current coverage path, and determining all paths passed by the difference node as paths to be covered; determining the relevant nodes in the second path set that are associated with the nodes in the target path, and obtaining test data of all nodes on the path where the relevant nodes are located, wherein the target path is the path in the first path set that includes the difference node; determining the test data of all nodes on the path where the relevant nodes are located and the test data of the first test case set as the initial input test data set; inputting the initial input test data set into a preset data model to obtain an output test case set; when the output test case set meets the coverage condition, determining the output test case set as the second test case set, wherein when the output test case set meets the coverage condition, the output test case set can cover all nodes on the current coverage path and the path to be covered, and there are no redundant cases in the output test case set; The first test case set and the second test case set are screened to obtain a third test case set corresponding to the software after defect repair.

2. The method according to claim 1, wherein The determining of a first test case set based on the detected software defects and the initial test cases used before defect repair comprises: Determine defect test cases corresponding to the software defects; The defect test case and the initial test case are synthesized to obtain the first test case set.

3. The method according to claim 2, characterized in that The generating initial coverage test data based on the difference nodes includes: Determine operation information for the difference node and difference test data related to the difference node when repairing the defect; When the operation information indicates that there is a deleted difference node, deleting the difference data corresponding to the deleted difference node from the initial test data of the initial test case to generate the initial coverage test data; When the operation information indicates that there is an added difference node, the initial test data and the difference data corresponding to the added difference node are merged to generate the initial coverage test data.

4. The method according to claim 3, characterized in that The method further comprises: determining an intervention factor based on the initial coverage test data, the intervention factor being used to directionally change the test data in the initial input test data set; When the output test case set does not satisfy the coverage condition, a new input test data set is determined based on the intervention factor and the initial input test data set.

5. The method according to claim 4, characterized in that The method further comprises: Establishing a decision function based on the current coverage path, the path to be covered, the importance of current test data, the defect level and the execution time; Based on the judgment function, selecting an input test data set that meets a preset judgment value from the initial input test data set; The input test data set that meets the preset judgment value is determined as the next input test data set.

6. The method according to claim 5, characterized in that The establishing of a determination function based on the current coverage path, the path to be covered, the importance of current test data, the defect level, and the execution time includes: Determining the number of different nodes between the current covered path and the path to be covered, and determining the ratio of the number of different nodes to the total number of nodes in the path to be covered as the layer proximity; Determine the distance between the test node where the current test data is located and a node at the same level as the test node; Obtain the importance, defect level and execution time of the current test data; The decision function is determined according to the layer proximity, the distance, the importance, the defect level, and the inverse of the execution time.

7. A test case optimization device, characterized in that: The device comprises: A first determination module is configured to determine a first test case set based on the detected software defects and the initial test cases used before defect repair; An analysis module, configured to perform path analysis on the software after defect repair, and obtain difference nodes between a first path set before defect repair and a second path set after defect repair; a second determination module, configured to generate initial coverage test data based on the difference node, and determine a second test case set based on the initial coverage test data; wherein the second determination module determines the second test case set based on the initial coverage test data, including: determining, in the second path set, the path with the most covered path nodes by the initial coverage test data as the current coverage path, and determining all paths through which the difference node passes as paths to be covered; determining, in the second path set, related nodes associated with nodes in a target path, and obtaining test data of all nodes on the path where the related nodes are located, wherein the target path is the path in the first path set that includes the difference node; determining the test data of all nodes on the path where the related nodes are located and the test data of the first test case set as the initial input test data set; inputting the initial input test data set into a preset data model to obtain an output test case set; and determining the output test case set as the second test case set when the output test case set satisfies a coverage condition, wherein when the output test case set satisfies the coverage condition, the output test case set can cover all nodes on the current coverage path and the path to be covered, and there are no redundant cases in the output test case set; The screening module is used to screen the first test case set and the second test case set to obtain a third test case set corresponding to the software after defect repair.

8. A test case device, characterized in that: The device comprises: processor; and a memory for storing a computer program executable on the processor; Wherein, when the computer program is executed by a processor, the steps of the test case optimization method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium, wherein computer-executable instructions are stored therein, and wherein the computer-executable instructions are configured to execute the steps of the test case optimization method according to any one of claims 1 to 6.

Images