Methods and apparatus for generating interface test cases

Abstract

This specification provides a method and apparatus for generating interface test cases. The method for generating interface test cases includes: obtaining test case execution data corresponding to the interface under test of the application under test; clustering and filtering the test case execution data to obtain seed test cases; obtaining the execution information of the seed test cases on the interface under test; filtering initial test cases from the seed test cases based on the execution information; performing cross-mutation on the initial test cases according to a pre-created test case gene pool to obtain extended test cases corresponding to the initial test cases; and generating target test cases for the interface under test based on the initial test cases and extended test cases. This intelligently and automatically generates a large number of test cases corresponding to the interface under test of the application under test. By conducting experiments on real interfaces of real applications using seed test cases, a large number of test cases are generated efficiently and with high quality, and the generated test cases have high coverage of the execution branches of the interface under test.

Description

Technical Field

[0001] This specification relates to the field of application testing technology, and in particular to a method for generating interface test cases. One or more embodiments of this specification also relate to an interface test case generation apparatus, a computing device, and a computer-readable storage medium. Background Technology

[0002] With the rapid development of computer and internet technologies, a wide variety of applications have emerged, affecting all aspects of people's lives and work. Given the frequent iterations and upgrades of business processes and the rapid updates in requirements, to ensure the quality of each application iteration and upgrade and reduce the frequency of failures during use, testers need to perform regression testing on the original functions of the application with each iteration. This means that the same functionalities need to be regressed each time. Using manual regression testing in this situation results in a significant waste of manpower, greatly reducing both testing efficiency and quality.

[0003] Since the implementation of an application's own functions and its interactions with other applications can be achieved by calling multiple interfaces through program code, regression testing of the application's original functions can be performed by testing these interfaces. In existing technologies, interface testing often involves testers manually writing test cases. However, this method is costly, requires testers to be familiar with the testing logic and have extensive testing experience, and demands high levels of expertise from testers. Furthermore, manually creating test cases is inefficient and produces low-quality results. Summary of the Invention

[0004] In view of this, embodiments of this specification provide a method for generating interface test cases. One or more embodiments of this specification also relate to an interface test case generation apparatus, a computing device, and a computer-readable storage medium, to address the technical deficiencies existing in the prior art.

[0005] According to a first aspect of the embodiments of this specification, a method for generating interface test cases is provided, comprising:

[0006] Obtain test case execution data corresponding to the interface to be tested of the application under test, and perform clustering and filtering on the test case execution data to obtain seed test cases;

[0007] Obtain the execution information of the seed test cases on the interface to be tested, and select initial test cases from the seed test cases based on the execution information;

[0008] Based on the pre-created test case gene pool, the initial test cases are cross-mutated to obtain the extended test cases corresponding to the initial test cases, and the target test cases of the interface to be tested are generated based on the initial test cases and the extended test cases.

[0009] According to a second aspect of the embodiments of this specification, an apparatus for generating interface test cases is provided, comprising:

[0010] The acquisition module is configured to acquire test case execution data corresponding to the interface to be tested of the application under test, and to perform clustering and filtering on the test case execution data to obtain seed test cases;

[0011] The filtering module is configured to obtain the execution information of the seed test cases on the interface to be tested, and filter the initial test cases from the seed test cases based on the execution information;

[0012] The generation module is configured to perform cross-mutation on the initial test cases according to a pre-created test case gene pool to obtain extended test cases corresponding to the initial test cases, and generate target test cases for the interface to be tested based on the initial test cases and the extended test cases.

[0013] According to a third aspect of the embodiments of this specification, a computing device is provided, comprising:

[0014] Memory and processor;

[0015] The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to perform the following steps:

[0016] Obtain test case execution data corresponding to the interface to be tested of the application under test, and perform clustering and filtering on the test case execution data to obtain seed test cases;

[0017] Obtain the execution information of the seed test cases on the interface to be tested, and select initial test cases from the seed test cases based on the execution information;

[0018] Based on the pre-created test case gene pool, the initial test cases are cross-mutated to obtain the extended test cases corresponding to the initial test cases, and the target test cases of the interface to be tested are generated based on the initial test cases and the extended test cases.

[0019] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, implement the steps of the method for generating interface test cases according to any one of the claims.

[0020] This specification provides an embodiment of a method for generating interface test cases. The method involves obtaining test case execution data corresponding to the interface under test of the application under test; clustering and filtering the test case execution data to obtain seed test cases; obtaining the execution information of the seed test cases on the interface under test; selecting initial test cases from the seed test cases based on the execution information; performing cross-mutation on the initial test cases according to a pre-created test case gene pool to obtain extended test cases corresponding to the initial test cases; and generating target test cases for the interface under test based on the initial test cases and the extended test cases. In this approach, test case execution data corresponding to the interface under test of the application under test can be obtained, which is essentially real online traffic data. Seed test cases can be constructed using this real online traffic data. Based on the actual execution of the seed test cases on the interface under test, initial test cases are selected. Subsequently, cross-mutation is performed on these initial test cases to obtain extended test cases corresponding to them. This intelligently and automatically generates a large number of test cases corresponding to the interface under test of the application under test. Experiments are then conducted on real interfaces of the real application using these seed test cases, resulting in a large number of test cases generated efficiently and with high quality, and the generated test cases have high coverage of the execution branches of the interface under test. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating a method for generating interface test cases according to one embodiment of this specification;

[0022] Figure 2a This is a schematic diagram of a target link provided in one embodiment of this specification;

[0023] Figure 2b This is a cross-use diagram of an embodiment provided in this specification;

[0024] Figure 2c This is a schematic diagram illustrating the expansion of a use case gene pool according to one embodiment of this specification;

[0025] Figure 2d This is a schematic diagram of an interface test case generation architecture provided in one embodiment of this specification;

[0026] Figure 2e This is a test case generation architecture diagram provided in one embodiment of this specification;

[0027] Figure 2f This is a schematic diagram of the environment architecture of a genetic algorithm provided in one embodiment of this specification;

[0028] Figure 2g This is a schematic diagram of a life cycle provided in one embodiment of this specification;

[0029] Figure 2hThis is a schematic diagram illustrating the execution of a use case provided in one embodiment of this specification;

[0030] Figure 3 This is a schematic diagram of the structure of an interface test case generation device provided in one embodiment of this specification;

[0031] Figure 4 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0032] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0033] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed business processes.

[0034] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0035] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0036] Traffic data: Data obtained by collecting traffic from online machines, without affecting normal user use, to obtain the real requests and service response results of online users.

[0037] Genetic Algorithm: A genetic algorithm is an adaptive random search heuristic algorithm. Its basic architecture relies on the laws of natural selection and genetic theory to simulate and solve problems related to the evolution and heredity of organisms in nature. It is a type of self-organizing and adaptive artificial intelligence technology.

[0038] Interface testing: Interface testing involves examining the data interaction between components within a system and between different systems. It verifies whether the interface meets the functional, security, and performance requirements specified in the interface specification by analyzing the relationship between the inputs and outputs under different conditions.

[0039] CFG: Control Flow Graph, also known as a control flow diagram, is an abstract representation of a process or program. It is a data structure that represents the control branch structure in program code.

[0040] Java-agent: Java-agent is a native programming interface provided by the Java Virtual Machine. Through JVMTI, external processes can obtain a lot of information about the runtime JVM.

[0041] Mock: During development, a mock is a method used to create a virtual object to test certain objects that are not easy to construct or obtain.

[0042] It's important to note that with frequent iterations and upgrades of business processes, requirements are updated rapidly. To ensure application quality, testers need to perform regression testing on the original functionality with each iteration. Each integration necessitates regressing the same functionalities. Manually performing point-by-point regression testing in this situation leads to significant waste of manpower, greatly reducing both efficiency and quality. Interface testing can provide agile development with efficient defect detection and quality supervision capabilities, primarily in the following ways: it facilitates continuous integration, increases regression speed because the shorter chain makes bugs easier to locate before integration; and it offers lower testing costs and higher efficiency, providing a low-cost, high-efficiency solution even with increasing system complexity.

[0043] Currently, there are two main approaches to interface testing in the industry: 1. Developers or testers manually write test cases using tools such as ACTS and ITEST. The advantage of this method is that it provides comprehensive coverage, but the disadvantage is that it is costly to write test cases and requires familiarity with business processes and expert experience to manually create data and mock test cases. 2. Use DOOM to record and replay traffic. The advantage of this method is that it has no writing cost, but the disadvantage is that it requires a large amount of traffic to be recorded, has high noise reduction costs, and unstable coverage.

[0044] Furthermore, regarding test case generation, current mainstream research focuses on unit test cases, with main implementation schemes including analysis-based and search-based methods. Popular tools using these schemes include Zest, AFL, Evosuite, and SamrtUnit. Analysis-based methods typically cannot handle the complexity of modern internet technology systems or require excessive manual adaptation. Search-based methods mostly handle binary-level mutations, which is often insufficient given that most software does not accept arbitrary binary data, as it can consume significant computational resources to bypass verification. Some solutions attempt to address this issue by introducing parameter generators, which decode arbitrary bit sequences into valid input. This method is more efficient than traditional methods and may perform well in unit testing, but for interface testing, it struggles to use complex data types as seeds because there is no easy way to encode complex input data into binary sequences.

[0045] To address the aforementioned issues, this specification proposes an automated and intelligent scheme for generating interface test cases. It designs and builds an improved genetic algorithm and algorithm training environment for internet system interface test cases, automatically generating internet system interface test cases.

[0046] This specification provides a method for generating interface test cases. It also relates to an interface test case generation device, a computing device, and a computer-readable storage medium, which will be described in detail in the following embodiments.

[0047] Figure 1 A flowchart of a method for generating interface test cases according to an embodiment of this specification is shown, including steps 102 to 106.

[0048] Step 102: Obtain the test case execution data corresponding to the interface to be tested of the application under test, and perform clustering and filtering on the test case execution data to obtain seed test cases.

[0049] It should be noted that test case execution data refers to real online traffic data, which is the actual data generated when the online business process runs through the interface under test of the application under test; that is, historical business process data. In practice, historical real traffic data of the online business process can be recorded to obtain the test case execution data corresponding to the interface under test of the application under test.

[0050] In practical applications, seed use cases are mainly selected by clustering and filtering online use case execution data. From thousands to hundreds of thousands of use case execution data, about N representative use cases are selected as seed use cases for the algorithm.

[0051] In an optional implementation of this embodiment, the test case execution data, i.e., the acquired online traffic, can be analyzed to select approximately N representative traffic items as seed test cases for the algorithm. This involves clustering and filtering the test case execution data to obtain seed test cases, including:

[0052] Identify the valid features and structural differences in the execution data of the aforementioned use cases;

[0053] Seed use cases are determined from the use case execution data based on the effective features and structural differences.

[0054] It should be noted that the test case execution data obtained online from the operation of business processes includes many features, such as valid features and invalid features. Valid features refer to features in the test case execution data that have distinctiveness, mainly features such as product codes, organization codes, and amounts that can affect the code logic; invalid features refer to features such as order numbers, serial numbers, and user identifiers that generally do not affect the code logic.

[0055] In addition, the data formats of different test case execution data generated by different business processes may be different. Therefore, there may be structural differences between different test case execution data. This structural difference means that the test case execution data obtained online is usually stored in a nested JSON format, which contains nested key-value pairs. When the keys of the test case execution data are inconsistent (whether there are more or fewer keys), it can be considered that their data structures are inconsistent.

[0056] In practical applications, we can pre-define which types of features are valid features, such as product codes, organization codes, and monetary values. Then, we can filter out use cases that include valid features and exhibit structural differences from the acquired use case execution data, and use these as seed use cases. In this way, use cases with different structures can enrich the diversity of seed use cases.

[0057] In the embodiments of this specification, seed test cases can be determined from a large amount of test case execution data based on the effective features and structural differences in the test case execution data. The selected seed test cases all include effective features and have the same structure, and can all effectively test the interface under test of the application under test. Moreover, they all have data structures that the interface under test of the application under test can recognize, which facilitates the subsequent expansion of the test cases corresponding to the interface under test of the application under test based on the seed test cases, thereby generating a large number of test cases efficiently and with high quality.

[0058] Step 104: Obtain the execution information of the seed test cases on the interface to be tested, and select the initial test cases from the seed test cases based on the execution information.

[0059] It should be noted that seed test cases can be replayed on the interface under test to help identify the target coverage branches. That is, by inputting seed test cases into the interface under test for pre-running, the corresponding execution information can be obtained. Based on this execution information, it can be determined which branches are covered and which branches are not covered, thereby selecting initial test cases from various seed test cases. The selected initial test cases can then be used as parent test cases to expand the test cases through a genetic algorithm.

[0060] In an optional implementation of this embodiment, the step of selecting initial test cases from the seed test cases based on the execution information includes:

[0061] Based on the execution information, a control flow diagram corresponding to the interface under test is generated, and based on the control flow diagram, the uncovered target link corresponding to the interface under test is determined.

[0062] Determine the fitness score of the seed use case to each target link, and generate the fitness vector of the seed use case based on each fitness score, wherein the value of each dimension in the fitness vector is the fitness score of the seed use case to the corresponding target link;

[0063] For each target link, the screening probability of each seed use case is determined based on the fitness score of each seed use case;

[0064] Initial test cases are selected from each of the seed test cases based on the selection probability.

[0065] Specifically, by inputting seed test cases into the interface under test of the application under test, the execution results of the seed test cases through the interface under test can be obtained, i.e., execution information. Based on this execution information, a control flow diagram of the interface under test's data processing logic can be generated. This control flow diagram indicates which execution branches the interface under test's data processing logic includes, which nodes each execution branch goes through, which execution branches can currently be covered, and which execution branches are not yet covered, i.e., the uncovered target links. The target link refers to the execution branch that is not covered by data, meaning there are no test cases to test this execution branch. To ensure the completeness of the test of the interface under test, test cases that can cover the target link need to be generated, thereby enabling the testing of that target link.

[0066] It's important to note that replaying seed test cases on the interface under test allows for the collection of code coverage, i.e., execution information. For each covered conditional statement, if at least one execution branch is not executed in this step, those branches will be set as the target links in the subsequent genetic algorithm, i.e., the baseline for test case expansion. For example... Figure 2a This is a schematic diagram of a target link provided in one embodiment of this specification, such as... Figure 2a As shown, the control flow tree of an example interface under test is displayed. By replaying the seed test case (i.e., historical data), the pre-run main link is covered, but other links are not covered, generating a result as shown below. Figure 2a The three target links shown are (target links 1-3).

[0067] In the embodiments described in this specification, the interface test case generation problem can be described as a multi-objective optimization problem. That is, the goal is to generate a test case that can cover multiple target links. Therefore, the fitness value of the test case will be a vector, where the value of each dimension is the fitness score of the test case to the target link.

[0068] In practical applications, the fitness scores from seed test cases to each target link can be determined, and a fitness vector for the seed test case can be generated based on each fitness score. The fitness score from a seed test case to a target link can represent the reliability of the seed test case for testing that target link. Therefore, for each target link, the screening probability of each seed test case can be determined based on the fitness scores of each seed test case. This screening probability represents the probability that a seed test case is selected and can be used to test the corresponding target link of the interface under test. Based on this screening probability, reliable initial test cases that are suitable for the corresponding target link of the interface under test and can be used to test the target link can be selected from each seed test case. Subsequently, test cases can be expanded based on the selected initial test cases. The expanded test cases are of higher quality and have a greater probability of covering the currently uncovered execution branches in the interface under test.

[0069] It should be noted that in the stage of generating interface test cases, an improved genetic algorithm was designed. Seed test cases, target links, and a pre-created gene pool constitute the data base of the genetic algorithm. Then, a complete interface test case generation algorithm is formed through fitness calculation, test case sorting and filtering, test case crossover, and test case mutation.

[0070] In the embodiments of this specification, determining the fitness score from the seed use case to each target link includes:

[0071] Determine the branch distance and link depth from the seed use case to each target link;

[0072] Based on the branch distance and link depth from the seed use case to each target link, determine the fitness score of the seed use case to each target link.

[0073] It should be noted that the fitness score calculation specifically includes two parts: branch distance and link depth. The branch distance from the seed use case to each target link can represent the value that the internal variables of the use case need to be changed to reach the target link in the code, calculated by the parsing capability of the code bytecode (bytecode is a binary file containing an executable program, consisting of a sequence of code / data pairs, a kind of intermediate code); the link depth refers to the depth of the code branch link, such as... Figure 2a The longest link depth shown is 5, and the hierarchical distance can be calculated from the link depth.

[0074] In practical applications, the link depth from the seed use case to each target link can be calculated using the following formula (1):

[0075]

[0076] Where, r i Let t represent the i-th target link. j Let aj represent the j-th seed use case, al(r) i , t j ) represents the seed use case t j to target link r i The link depth, uncover(r) i , t j ) represents the seed use case t j The target link r was not covered. i The number of nodes, num(r) i ) represents the target link r i The total number of nodes.

[0077] In addition, the branch distance from the seed use case to each target link can be calculated using the following formula (2):

[0078]

[0079] Where, r i Let t represent the i-th target link. j Let l represent the j-th seed use case. i d(r) represents the number of target links. i , t j ) represents the seed use case t j to target link r i The branch distance, m represents the target link r i The number of branch nodes, p(r) i , t j m) represents the seed use case t j At the target link r i The branch distance of the m-th branch node, norm(x) = 1 - 1.001-x The purpose is to reduce the branch distance p(r) i , t j Normalize m to the interval (0, 1]. Represents the target link r i The depth of the middle branch node m, Represents the target link r i The depth of the branch node n, l j This indicates the number of seed use cases.

[0080] In practical implementation, when calculating the branch distance of a seed use case to a branch node on the target link, it can be calculated based on the correspondence between the branch predicate and the branch distance. Here, the branch predicate is an abstraction of code branching, that is, a mathematical abstraction of the code logic such as if / else / switch / conditions in the code, and the branch distance refers to how the branch distance is calculated for this abstraction.

[0081] As an example, the correspondence between branch predicates and branch distances is shown in Table 1 below. Here, D is just a constant, a represents a bytecode-level variable, and b represents a bytecode-level judgment constant that determines the branch direction. if|ab|=0then 0 else|ab|+D means that when the branch judgment is equal to 0, the branch distance is 0, and when the branch judgment is not equal to 0, the branch distance is |ab|+D.

[0082] Table 1. Correspondence between branch predicates and branch distances

[0083] Branch predicate Branch distance a = b if |ab|=0 then 0 else |ab|+D a! = b if|ab|! =0 then 0 else|ab|+D a<b if a-b<0 then 0 else(a-b)+D a<=b if a-b<=0 then 0 else(a-b)+D a>b if b-a<0 then 0 else(b-a)+D a>=b if b-a<=0 then 0 else(b-a)+D boolen if True then 0 else D

[0084] In addition, the calculation process of fitness score can be expressed as the following formula (3):

[0085]

[0086] in, This represents each seed use case (i.e., seed use cases t1-t). j ) to each target link (i.e., target link r1-r i The fitness score of d(r) i , t j ) represents test case t j Uncovered target link r i The branch distance.

[0087] It should be noted that the fitness score of each seed test case to each target link can be calculated based on the branch distance and link depth of each seed test case to each target link. The fitness score calculated by combining the branch distance and link depth is more accurate, which makes it easier to accurately select parent test cases that can be crossovered and mutated by genetic algorithms, thereby expanding the seed test cases and obtaining high-quality test cases.

[0088] In one optional implementation of this embodiment, the selection probability of each seed use case is determined based on its fitness score, including:

[0089] The seed use cases are sorted according to their fitness scores, and the selection probability of each seed use case is determined based on the sorting results.

[0090] It should be noted that since the fitness scores of each seed use case to each target link are not the same, some are high and some are low, the quality of the test cases expanded by the genetic algorithm will also vary depending on the seed use cases selected as parent use cases. Therefore, for each target link, the seed use cases can be sorted based on their fitness scores to determine the selection probability of each seed use case for that target link. That is, the probability that each seed use case will be selected as a parent use case to expand the test cases corresponding to that target link under that target link. Based on this selection probability, initial test cases can be selected from each seed use case. The selected initial test cases are the most suitable seed use cases for expanding test cases under that target link.

[0091] In practical applications, in each iteration, for each target link whose nodes are not yet fully covered, two seed test cases can be selected to expand and obtain new test cases. Therefore, for each target link, the seed test cases can first be sorted according to their corresponding fitness scores. Then, starting from the seed test case with the highest fitness score, the screening probability of each seed test case being selected as a parent test case is calculated until two necessary parent test cases are selected.

[0092] In practice, the selection probability of each seed use case under a certain target link can be calculated using the following formula (4):

[0093]

[0094] in, Indicates the target link r i Seed use case t j The probability of selecting a parent test case, ε represents a small constant. The score represents the fitness obtained above, and m represents the number of test cases for each seed test case.

[0095] In the embodiments of this specification, for each target link, parent test cases used in the next step of genetic mutation through a genetic algorithm can be selected based on the ranking of the fitness scores of each seed test case. The selection probability is calculated based on the fitness score; a seed test case with a higher selection probability indicates that it performs better among the seed test cases and is more likely to be selected as the parent test case for the next generation. In this way, selecting test cases with high fitness and good performance for the target link from each seed test case as the parent test cases for the next generation can improve the performance of the parent test cases, thereby improving the quality of test cases expanded based on the parent test cases.

[0096] Step 106: Based on the pre-created test case gene pool, perform cross-mutation on the initial test cases to obtain the extended test cases corresponding to the initial test cases, and generate the target test cases for the interface to be tested based on the initial test cases and the extended test cases.

[0097] It's important to note that genetic algorithms include operations such as fitness calculation, crossover, and mutation. Mutation occurs when a parent gene undergoes a mutation, such as being replaced by another gene. During mutation, reference genes are needed to modify the parent genes, hence the definition of a gene pool. Here, a gene refers to the data involved in the genetic algorithm. If two genes have a parental relationship, then those two genes are considered parental genes. In other words, parental genes are parental data with a parental relationship. Changes in parental data result in mutation. The gene pool is a collection of genes containing a large number of reference genes. These reference genes provide reference data for the mutation of parent genes. Specifically, certain reference genes can be selected from the gene pool, and based on these selected reference genes, some parent genes are reassigned, thus achieving the mutation process.

[0098] In this embodiment, the data type can be test case data. In this embodiment, "gene" refers to test case data. The parent gene is the parent test case with a parent-child relationship. When the parent test case is mutated later, some parameters in the parent test case need to be reassigned. Therefore, the gene pool is the test case gene pool. The test case gene pool can refer to a pre-created collection containing a large number of reference test cases. That is, the genes in the test case gene pool are the parameters included in the reference test cases. The test case gene pool can provide a reference for the genetic mutation of the initial test cases. Genetic mutation is performed based on the genes in the test case gene pool. That is, a reference test case can be selected from the test case gene pool, and the parameters of the parent test case are reassigned based on the parameters included in the reference test case to achieve mutation, thereby improving the reliability of genetic mutation and obtaining high-quality expanded test cases.

[0099] In one optional implementation of this embodiment, the step of performing crossover mutation on the initial test cases according to a pre-created test case gene pool to obtain expanded test cases corresponding to the initial test cases includes:

[0100] Select parent test cases from the initial test cases and obtain the set cross attributes;

[0101] Based on the cross attributes, the parent use cases are cross-referenced to obtain initial expanded use cases;

[0102] Based on the pre-created test case gene pool, the initial expanded test cases are mutated to obtain expanded test cases corresponding to the initial test cases.

[0103] It should be noted that the initial test cases are selected from the seed test cases, and are those with high fitness and reliability. These initial test cases can all be used as parent test cases for genetic mutation to obtain corresponding extended test cases. Therefore, any two initial test cases can be randomly selected as parent test cases, and the set crossover attribute can be obtained. Then, based on the crossover attribute, the parent test cases are cross-crossed to obtain initial extended test cases. Then, based on the pre-created test case gene pool, the initial extended test cases are mutated to obtain the extended test cases corresponding to the initial test cases.

[0104] Here, the crossover attribute refers to the attribute corresponding to the feature parameters that need to be crossed in the parental use case. This crossover attribute can be set in advance based on the genetic variation requirements.

[0105] In the embodiments of this specification, the parent test cases can first be cross-crossed based on the pre-set cross-cross attributes, and then mutated according to the pre-created test case gene pool to obtain the expanded test cases corresponding to the initial test cases. Through the dual genetic treatment of cross-crossing and mutation, the quality of the obtained expanded test cases is improved.

[0106] In one optional implementation of this embodiment, the parental use cases are a tree structure, and the nodes in the tree structure are the feature parameters included in the parental use cases; the step of crossing the parental use cases according to the cross attribute to obtain the initial expanded use cases includes:

[0107] Based on the cross attribute, determine whether the child use case corresponding to the parent use case includes the cross attribute;

[0108] If all are included, then directly swap the subtrees corresponding to the target node in the parent use case to obtain the initial expanded use case;

[0109] If any parent use case is not included, then the node preceding the target node in the target parent use case is determined as the update node, and the subtrees of the parent use case rooted at the update node are swapped to obtain the initial expanded use case, wherein the target parent use case is a parent use case that includes the target node corresponding to the cross attribute.

[0110] It should be noted that each parent use case includes a large number of various feature parameters. Therefore, the attributes corresponding to the feature parameters that need to be crossed can be pre-defined, i.e., the cross attributes. Then, based on the cross attributes, multi-level hierarchical crosses can be performed.

[0111] In practical applications, each parent test case can be represented as a tree, and the feature parameters included in the parent test case are the nodes in the tree. Therefore, we can first determine whether each node included in the parent test case includes the target node corresponding to the set cross attribute. If both include it, it means that both parent test cases include the feature parameters corresponding to the set cross attribute. At this time, we can directly swap the subtrees corresponding to the target node in the two parent test cases. This subtree is the parent node of the target node, and the child nodes included in the parent node, to obtain the initial expanded test cases.

[0112] In addition, if any parent test case is not included, it means that the feature parameters corresponding to the set cross attribute are not included in a certain parent test case. In this case, the subtrees corresponding to the target node in the two parent test cases cannot be directly swapped. Therefore, in this case, the previous node of the target node in the target parent test case that includes the target node corresponding to the cross attribute can be determined as the update node. The subtrees with the update node as the root node in the two parent test cases are swapped to obtain the initial expanded test case.

[0113] Furthermore, if neither of the two parent test cases includes it, it means that neither of the two parent test cases includes the feature parameters corresponding to the set cross attribute. In this case, cross crossing can be omitted, or nodes in the two parent test cases can be randomly selected for cross crossing. This specification does not impose any restrictions on this.

[0114] Example, Figure 2b This is a cross-use case diagram provided in one embodiment of this specification, such as... Figure 2b As shown, parental use case 1 and parental use case 2 are represented by two tree structures, where each node in the tree represents a feature parameter of the parental use case. If the algorithm decides to perform a crossover operation and set attribute d as the crossover attribute, it will first check whether a target node corresponding to this attribute exists in either of the two parental use cases. Figure 2bAs shown, both parent test cases contain the target node D corresponding to attribute d. Therefore, the subtrees corresponding to node D can be directly swapped, which will generate initial expanded test case 1 and initial expanded test case 2, that is, directly replacing parent nodes C1 and C2, and their corresponding child nodes, i.e., swapping [C1, D1, E1, F1] and [C2, D2, F2]. Otherwise, if the target node corresponding to the cross attribute cannot be found in a parent test case, such as when the cross attribute is attribute e, parent test case 1 includes the target node E corresponding to attribute e, but parent test case 2 does not include the target node E corresponding to attribute e, then the previous updated node of the target node can be searched in the target parent test case (i.e., parent test case 1). Figure 2b Let node D be the node in the middle. Under certain possibilities, the subtrees rooted at nodes D1 and D2 in the two parent test cases will be swapped, generating initial expanded test case 3 and initial expanded test case 4, as follows. Figure 2b As shown, nodes D1 and D2 have no child nodes, so nodes D1 and D2 are directly swapped. This process may be repeated until the swap is completed or the root attribute is reached. In the latter case, the initial expansion use case (i.e., the child use case) remains the same as the parent use case.

[0115] In the embodiments of this specification, once two parent test cases are selected, the crossover operation will be performed with a certain probability when offspring are generated. A multi-level crossover strategy is designed when performing the crossover operation, which improves the variability of the initial expanded test cases generated by the genetic mutation of the parent test cases, thereby improving the richness and quality of the subsequently obtained expanded test cases.

[0116] In one optional implementation of this embodiment, the step of mutating the initial expanded test cases according to a pre-created test case gene pool to obtain expanded test cases corresponding to the initial test cases includes:

[0117] For the target leaf node in the initial expanded use case, the mutation rate of the target leaf node is calculated based on the pre-created use case gene pool, wherein the target leaf node is any leaf node in the initial expanded use case;

[0118] Based on the mutation rate, determine whether the target leaf node should be mutated;

[0119] If so, the target gene is obtained from the private gene pool corresponding to the target leaf node, and the target leaf node is assigned a value according to the target gene to obtain the expanded test case corresponding to the initial test case.

[0120] It should be noted that after performing the hierarchical crossover operation, initial expanded test cases can be obtained. Furthermore, the leaf nodes of these initial expanded test cases can be mutated using the gene pool. Specifically, for each leaf node in the initial expanded test cases, the mutation rate can be calculated based on a pre-created test case gene pool. Then, based on the determined mutation rate, it can be determined whether the leaf node needs to be mutated. If so, a gene (i.e., feature parameter) is randomly selected from the private gene pool corresponding to that leaf node and reassigned to it, resulting in the mutated expanded test cases.

[0121] In this context, the private gene pool refers to the unique gene pool for each parameter in each use case, i.e., the private gene pool corresponding to each node. The application-dimensional gene pool (i.e., the pre-created use case gene pool) is a set of private gene pools corresponding to each node of each use case. Each node included in each use case has its own private gene pool, which contains genes that can replace the feature parameters of the corresponding node.

[0122] In practice, the mutation rate of the target leaf node can be calculated using the following formula (5):

[0123]

[0124] in, δ is the mutation rate of leaf node m in the initial augmented use case i; m It is a variation constant; This represents the diversity of the two initial expanded use cases (i.e., the two parent use cases). Represents the initial expanded use case t a and initial expanded use case t b The similarity between X and Y is given by hanming(x, y), where hanming(x, y) represents the Hamming distance between X and Y, and Z represents the number of feature parameters included in the initial augmentation use case. Represents the initial expanded use case t a The i-th feature parameter.

[0125] In the embodiments of this specification, the leaf node can be mutated based on the private gene pool corresponding to the leaf node included in the initial expanded test case. The private gene pool provides a reference for the mutation of the feature parameters of the initial expanded test case, which improves the variability of the expanded test cases generated by genetic mutation and improves the reliability of genetic mutation, thereby improving the richness and quality of the obtained expanded test cases.

[0126] In an optional implementation of this embodiment, before calculating the mutation rate of the target leaf node based on the pre-created use case gene pool, the method further includes:

[0127] Obtain valid features from the test case execution data corresponding to each interface under test;

[0128] Retrieve the enumerated and static fields from the code scan;

[0129] Based on the effective features, the enumerated fields, and the static fields, construct the use case gene pool corresponding to the application under test.

[0130] It should be noted that before calculating the mutation rate, a test case gene pool can be created first. This test case gene pool is a collection of test case genes at the application dimension, consisting of private gene pools corresponding to each feature parameter of each test case. In the generation of interface test cases, both the main input parameters of the interface and the mock return values ​​of sub-calls contain a large number of feature parameters with business semantics. Therefore, if only simple random mutation is used when mutating parameters, the efficiency will be very low. Based on this, the concept of a test case gene pool is proposed in the embodiments of this specification. This test case gene pool is established at the entire application dimension because the business semantics of different interfaces within the same application will have overlapping and similar parts. If the test case gene pool is constructed only at the single interface dimension, it will lead to insufficient sufficiency of feature parameters.

[0131] It's important to note that the test case gene pool originates from valid feature fields in online test case execution data, as well as enumerated and static fields obtained from code scanning. Test cases are composed of nested key-value pairs; fields represent the values ​​within these pairs. The test case gene pool stores all possible values ​​corresponding to a given key. Code refers to the executable code of the application under test. Enumerated and static fields are values ​​that programmers stored as variables or constants in the code during its creation. These values ​​are typically related to certain feature parameters in the test cases. Therefore, scanning the code to obtain enumerated and static fields supplements the test case gene pool, improving the sufficiency of feature parameters within it.

[0132] In one optional implementation of this embodiment, the test case execution data consists of nested key-value pairs, and the test case gene pool stores the key values ​​corresponding to any key;

[0133] After constructing the test case gene pool corresponding to the application under test based on the effective features, the enumerated fields, and the static fields, the method further includes:

[0134] The use case gene pool is expanded based on the key-value pairs of the use case execution data.

[0135] It should be noted that the execution data of each test case used to construct the test case gene pool is stored in the form of key-value pairs. Therefore, for the genes (i.e., valid fields) in the gene test case pool, they can be supplemented based on the similarity of key values ​​and value values ​​of the test case execution data, thereby expanding the valid features (i.e., value values) of the test case execution data stored in the test case gene pool and improving the sufficiency of feature parameters in the test case gene pool.

[0136] In addition, enumerated fields and static fields are added to the use case gene pool as supplementary information and are not used to expand it.

[0137] In an optional implementation of this embodiment, expanding the use case gene pool based on the key-value pairs of the use case execution data includes:

[0138] Calculate the matching value between each key to be supplemented and the key to be matched. For each key to be supplemented, select the key with the highest matching value that is greater than the confidence threshold as the expanded field corresponding to the key to be supplemented. Then, merge the key to be supplemented with the expanded field; and / or,

[0139] Determine the cosine distance between the text vector of the value to be supplemented and the vectors of the entire text set. Select the texts with a cosine distance less than a threshold as the texts to be fused corresponding to the value to be supplemented. Then, fuse the value to be supplemented and the texts to be fused.

[0140] It should be noted that the first round can use key similarity and strong similarity matching fields between the keys to be supplemented. The Needleman-Wunsch algorithm is used to calculate the matching score between each key to be supplemented and the key to be matched. For each key to be supplemented, the key with the highest matching score that is greater than the confidence threshold is selected. Here, the keys to be supplemented are the individual keys in the test case execution data corresponding to the interface under test, and the keys to be matched are all the keys in the test case execution data of each dimension of the application under test.

[0141] Additionally, the second approach supplements the strong correlation matching field through value similarity. Each feature set in the use case gene pool (i.e., the set of all genes corresponding to that feature in the use case gene pool) is treated as naturally segmented text. Each feature set is equivalent to a text, and the entire gene pool, comprising all genes included in the use case gene pool, is equivalent to a text set. The TF-IDF algorithm is used to vectorize the text, obtaining text vectors and the vector space of the entire text set. The cosine distance between the text vectors transformed from the features of the existing input parameters / mock points and the entire text set is calculated. Texts with a cosine distance less than a threshold are selected as the texts to be fused. Here, the existing input parameters / mock points refer to the key-value pairs contained in the use case execution data currently cleaned from the online database. From the perspective of the actual system, key-value pairs can be distinguished into input parameter key-value pairs and mock point key-value pairs.

[0142] Example, Figure 2c This is a schematic diagram illustrating the expansion of a use case gene pool according to one embodiment of this specification, as shown below. Figure 2c As shown, in the first round, the value corresponding to "XXX.XXX.key1" can be added to the value corresponding to "XXX.XXX.key2" through key value similarity, thus supplementing the key value strong similarity matching field. In the second round, the value similarity can be added to the value corresponding to "value1, value2 and value3" through value similarity, thus supplementing the value strong correlation matching field.

[0143] In the embodiments of this specification, two rounds of expansion can be performed by using the similarity of key and value, which improves the sufficiency of the feature parameters in the constructed use case gene pool.

[0144] It should be noted that this solution is an interface test case generation method based on genetic algorithms. The overall architecture of applying genetic algorithms to interface test case generation is as follows: Figure 2d As shown, it includes two core modules: a core algorithm designed to effectively address the characteristics of generating Internet interface test cases, namely a genetic algorithm, and an algorithm execution environment designed to stably and quickly perform actual calls to the interface under test of the application under test, and collect various execution information during the execution process.

[0145] like Figure 2dAs shown, the first step is to prepare seed input parameters, which involves acquiring a large amount of test case execution data online. This data is then input into the algorithm execution environment (i.e., the input parameters). The execution environment can execute the input test case data through API calls, mocking, and execution monitoring of the application under test, and output corresponding execution information. This means the genetic algorithm obtains the execution information output by the execution environment. Based on this information, each test case execution data is evaluated, and the best initial test cases are selected. Two random initial test cases are then selected as parent test cases for crossover, followed by mutation to obtain the next generation of test cases, thus expanding the test cases. This process is continuously iterated. During crossover and mutation, feature parameter analysis (i.e., the range, interval, and correlation of feature parameters) can constrain the mutation range, and code analysis (i.e., parameter weights and control flow) can provide the mutation weights of each feature parameter.

[0146] Figure 2e This is a test case generation architecture diagram provided in one embodiment of this specification, such as... Figure 2e As shown, online test case execution data is obtained, and then clustered and filtered to obtain seed test cases. Based on CFG analysis (i.e., control flow diagram analysis) and pre-running of seed test cases, the target link can be determined. Then, based on the seed test cases and the target link, the MLNO genetic algorithm can be used. First, fitness is calculated (including branch distance and link depth, and execution time can also be considered). Then, based on the calculated fitness, the seed test cases are sorted, that is, test cases are sorted based on the optimal fitness. Then, test cases are crossed based on the set cross attributes. Finally, test cases are mutated based on the genes in the test case gene pool to generate new candidate test cases, that is, expand the test cases. After the expanded test cases are generated, they can be continuously iterated to obtain the final expanded test cases. The test cases are input into the test interface of the application under test, and the test interface of the application under test can be tested. The AGENT in the application under test can return execution information to the MLNO algorithm for subsequent test case expansion.

[0147] Figure 2f This is a schematic diagram of the environment architecture of a genetic algorithm provided in one embodiment of this specification, such as... Figure 2f As shown, the entire test case generation training environment is built upon Java-agent technology. Java-agent acts as the execution entity, controlling the algorithm. The algorithm's lifecycle is also controlled by the Java-agent program through interaction with external servers via the aggregation of Jetty's HTTP service. The lifecycle is as follows... Figure 2g As shown, it is divided into 5 lifecycles: agen mounting, initialization, start algorithm, end algorithm, and agen unloading.

[0148] Here, "agen mounting" refers to mounting the Java agent onto the target application's Java process. Initialization is divided into two parts: one is the initialization of basic objects, including the scope of mocking, the scope of instrumentation, TR / HTTP client initialization, seed traffic pre-running, etc.; the other part is the bytecode modification of ASM. Algorithm start: Basic function initialization, algorithm iterative execution. Algorithm end: Direct termination or termination at a specified time using a timer, stopping algorithm execution, obtaining generated test cases, and returning them in a formatted format. Agen unloading: Unloading the Java agent from the target process; unloading does not affect the normal operation of the application.

[0149] It should be noted that the test case execution environment relies on java-agent. The algorithm needs to be continuously optimized and iterated. Each iteration requires a stable execution environment, external data mocking, and execution path monitoring. java-agent is a thread mounted in the application, which can easily obtain classes and loaders in the application. By obtaining the classes and loaders, classes can be modified through injection to achieve the effects of test case execution monitoring and data mocking.

[0150] Figure 2h This is a schematic diagram of a use case execution provided in one embodiment of this specification, such as... Figure 2h As shown, the test case is executed by obtaining the class of the current interface input parameter through the Java-agent, using Fastjson to deserialize the data into a specific parameter object, and then executing the test case through the generic call of the RPC interface / HTTP call.

[0151] The mocking mechanism involves numerous external calls to the interface. For a complete test case, the return values ​​of these external calls are essentially part of the test case's input parameters. Therefore, mocking is necessary for the entire test case to run correctly. Both the original and generated test cases in the traffic are strings serialized using Fastjson. Different external calls and frameworks employ different mocking techniques, obtaining information through instrumentation, processing it to generate concrete objects, and then returning them to the upper-layer application. The main mocking techniques are as follows: iBatis framework method return mocking: Some iBatis framework methods return generic types, making it impossible to directly obtain the actual return type via reflection. Therefore, this type needs to be obtained beforehand. We analyze the code to obtain the correspondence between `sqiid` and the actual object type, and then use the built-in Groovy script to generate a Fastjson `TypeReference` object for deserialization. Mocking proxy objects such as `tr` calls: We directly obtain the object's methods in the proxy class and then use reflection to obtain the method's return generic type to generate the object. Mocking ordinary method return values: This part directly obtains the return type of a single method through reflection and generates the object. Method input parameter recording: A complete test case includes not only the return value and input parameters of the main call, but also the return value and input parameters of the mock point. The return value can be generated directly during test case generation, while the input parameters are the results of program execution. This part of the data also needs to be recorded. The recording is also done by instrumentation, and the corresponding parameter values ​​are obtained from the local variable table of the instrumented method.

[0152] In addition, execution path monitoring is an indispensable part of calculating branch distance and branch depth in algorithms. Since ordinary if / else branches and switch branches are represented differently in bytecode, a combination of two monitoring schemes is used to monitor the program execution path. Jump instruction monitoring: Before the jump(IF_***) branch, the data in the dup operand stack used for branch jump calculation is used. `truedistance` represents the distance of the conditional jump, with 0.0 indicating a jump, and a larger value indicating a greater distance from the jump (`falsedistance`), and vice versa. Switch instruction monitoring: Calculate the branch distance of all cases. Add an if condition judgment to each case before the switch, and use the switch condition value in the dup operand stack. Then, use this if condition judgment. The calculation of the default case requires special handling because the range of the default is relatively broad and difficult to count. A separate switch is generated before the switch to be instrumented, with the same conditions as the original switch. The switch's case conditions jump to a `caseLabel`. Two stubs are added before and after the default case to count cases that cover and do not cover the default case. The `caseLabel` is placed before these two stubs to collect the data.

[0153] This specification provides an embodiment of a method for generating interface test cases. The method involves obtaining test case execution data corresponding to the interface under test of the application under test; clustering and filtering the test case execution data to obtain seed test cases; obtaining the execution information of the seed test cases on the interface under test; selecting initial test cases from the seed test cases based on the execution information; performing cross-mutation on the initial test cases according to a pre-created test case gene pool to obtain extended test cases corresponding to the initial test cases; and generating target test cases for the interface under test based on the initial test cases and the extended test cases. In this approach, test case execution data corresponding to the interface under test of the application under test can be obtained, which is essentially real online traffic data. Seed test cases can be constructed using this real online traffic data. Based on the actual execution of the seed test cases on the interface under test, initial test cases are selected. Subsequently, cross-mutation is performed on these initial test cases to obtain extended test cases corresponding to them. This intelligently and automatically generates a large number of test cases corresponding to the interface under test of the application under test. Experiments are then conducted on real interfaces of the real application using these seed test cases, resulting in a large number of test cases generated efficiently and with high quality, and the generated test cases have high coverage of the execution branches of the interface under test.

[0154] Corresponding to the above method embodiments, this specification also provides embodiments of an interface test case generation device. Figure 3This diagram illustrates the structure of an interface test case generation apparatus according to one embodiment of this specification. Figure 3 As shown, the device includes:

[0155] The module 302 is configured to acquire test case execution data corresponding to the interface to be tested of the application under test, and to perform clustering and filtering on the test case execution data to obtain seed test cases;

[0156] The filtering module 304 is configured to obtain the execution information of the seed test cases on the interface to be tested, and filter the initial test cases from the seed test cases according to the execution information;

[0157] The generation module 306 is configured to perform cross-mutation on the initial test cases according to a pre-created test case gene pool to obtain extended test cases corresponding to the initial test cases, and generate target test cases for the interface to be tested based on the initial test cases and the extended test cases.

[0158] Optionally, module 302 is further configured as follows:

[0159] Identify the valid features and structural differences in the execution data of the aforementioned use cases;

[0160] Seed use cases are determined from the use case execution data based on the effective features and structural differences.

[0161] Optionally, the filtering module 304 is further configured as follows:

[0162] Based on the execution information, a control flow diagram corresponding to the interface under test is generated, and based on the control flow diagram, the uncovered target link corresponding to the interface under test is determined.

[0163] Determine the fitness score of the seed use case to each target link, and generate the fitness vector of the seed use case based on each fitness score, wherein the value of each dimension in the fitness vector is the fitness score of the seed use case to the corresponding target link;

[0164] For each target link, the screening probability of each seed use case is determined based on the fitness score of each seed use case;

[0165] Initial test cases are selected from each of the seed test cases based on the selection probability.

[0166] Optionally, the filtering module 304 is further configured as follows:

[0167] Determine the branch distance and link depth from the seed use case to each target link;

[0168] Based on the branch distance and link depth from the seed use case to each target link, determine the fitness score of the seed use case to each target link.

[0169] Optionally, the filtering module 304 is further configured as follows:

[0170] The seed use cases are sorted according to their fitness scores, and the selection probability of each seed use case is determined based on the sorting results.

[0171] Optionally, the generation module 306 is further configured as follows:

[0172] Select parent test cases from the initial test cases and obtain the set cross attributes;

[0173] Based on the cross attributes, the parent use cases are cross-referenced to obtain initial expanded use cases;

[0174] Based on the pre-created test case gene pool, the initial expanded test cases are mutated to obtain expanded test cases corresponding to the initial test cases.

[0175] Optionally, the parental use case is a tree structure, and the nodes in the tree structure are the feature parameters included in the parental use case; the generation module 306 is further configured to:

[0176] Based on the cross attribute, determine whether the tree structure corresponding to the parent use case includes the target node corresponding to the cross attribute;

[0177] If all are included, then directly swap the subtrees corresponding to the target node in the parent use case to obtain the initial expanded use case;

[0178] If any parent use case is not included, then the node preceding the target node in the target parent use case is determined as the update node, and the subtrees of the parent use case rooted at the update node are swapped to obtain the initial expanded use case, wherein the target parent use case is a parent use case that includes the target node corresponding to the cross attribute.

[0179] Optionally, the generation module 306 is further configured as follows:

[0180] For the target leaf node in the initial expanded use case, the mutation rate of the target leaf node is calculated based on the pre-created use case gene pool, wherein the target leaf node is any node in the initial expanded use case;

[0181] Based on the mutation rate, determine whether the target leaf node should be mutated;

[0182] If so, the target gene is obtained from the private gene pool corresponding to the target leaf node, and the target leaf node is assigned a value according to the target gene to obtain the expanded test case corresponding to the initial test case.

[0183] Optionally, the generation module 306 is further configured as follows:

[0184] Obtain valid features from the test case execution data corresponding to each interface under test;

[0185] Retrieve the enumerated and static fields from the code scan;

[0186] Based on the effective features, the enumerated fields, and the static fields, construct the use case gene pool corresponding to the application under test.

[0187] Optionally, the use case execution data consists of nested key-value pairs, and the use case gene pool stores the key-value pairs corresponding to any key; the generation module 306 is further configured to:

[0188] The use case gene pool is expanded based on the key-value pairs of the use case execution data.

[0189] Optionally, the generation module 306 is further configured as follows:

[0190] Calculate the matching value between each key to be supplemented and the key to be matched. For each key to be supplemented, select the key with the highest matching value that is greater than the confidence threshold as the expanded field corresponding to the key to be supplemented. Then, merge the key to be supplemented with the expanded field; and / or,

[0191] Determine the cosine distance between the text vector of the value to be supplemented and the vectors of the entire text set. Select the texts with a cosine distance less than a threshold as the texts to be fused corresponding to the value to be supplemented. Then, fuse the value to be supplemented and the texts to be fused.

[0192] This specification provides an embodiment of an interface test case generation device. The device acquires test case execution data corresponding to the interface under test of the application under test, performs clustering and filtering on the test case execution data to obtain seed test cases; acquires the execution information of the seed test cases on the interface under test, and filters initial test cases from the seed test cases based on the execution information; performs cross-mutation on the initial test cases according to a pre-created test case gene pool to obtain extended test cases corresponding to the initial test cases, and generates target test cases for the interface under test based on the initial test cases and the extended test cases. In this case, test case execution data corresponding to the interface under test of the application under test can be acquired, which is online real traffic data. Seed test cases can be constructed using online real traffic data. Based on the actual execution of the seed test cases on the interface under test, initial test cases are filtered out. Subsequently, cross-mutation is performed on the initial test cases to obtain extended test cases corresponding to the initial test cases, thereby intelligently and automatically generating a large number of test cases corresponding to the interface under test of the application under test. Experiments are conducted on the real interfaces of the real application using the seed test cases, efficiently and with high quality generating a large number of test cases, and the generated test cases have high coverage of the execution branches of the interface under test.

[0193] The above is a schematic scheme of an interface test case generation device according to this embodiment. It should be noted that the technical solution of this interface test case generation device and the technical solution of the interface test case generation method described above belong to the same concept. For details not described in detail in the technical solution of the interface test case generation device, please refer to the description of the technical solution of the interface test case generation method described above.

[0194] Figure 4 A structural block diagram of a computing device 400 according to one embodiment of this specification is shown. The components of the computing device 400 include, but are not limited to, a memory 410 and a processor 420. The processor 420 is connected to the memory 410 via a bus 430, and a database 450 is used to store data.

[0195] The computing device 400 also includes an access device 440, which enables the computing device 400 to communicate via one or more networks 460. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 440 may include one or more of any type of wired or wireless network interface (e.g., Network Interface Controller (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, Wi-MAX (Worldwide Interoperability for Microwave Access) interface, Ethernet interface, Universal Serial Bus (USB) interface, cellular network interface, Bluetooth interface, Near Field Communication (NFC) interface, and so on.

[0196] In one embodiment of this specification, the aforementioned components of the computing device 400 and Figure 4 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 4 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0197] The computing device 400 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. The computing device 400 can also be a mobile or stationary server.

[0198] The processor 420 is configured to execute the following computer-executable instructions to perform the following steps:

[0199] Obtain test case execution data corresponding to the interface to be tested of the application under test, and perform clustering and filtering on the test case execution data to obtain seed test cases;

[0200] Obtain the execution information of the seed test cases on the interface to be tested, and select initial test cases from the seed test cases based on the execution information;

[0201] Based on the pre-created test case gene pool, the initial test cases are cross-mutated to obtain the extended test cases corresponding to the initial test cases, and the target test cases of the interface to be tested are generated based on the initial test cases and the extended test cases.

[0202] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the interface test case generation method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the interface test case generation method described above.

[0203] An embodiment of this specification also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, are used to implement the steps of the method for generating interface test cases according to any one of the claims.

[0204] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the interface test case generation method described above belong to the same concept. Details not described in detail in the technical solution of the storage medium can be found in the description of the technical solution of the interface test case generation method described above.

[0205] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0206] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0207] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0208] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0209] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A method for generating interface test cases, comprising: Obtain test case execution data corresponding to the interface to be tested of the application under test, determine the effective features and structural differences in the test case execution data, and perform clustering and filtering on the test case execution data based on the effective features and structural differences to obtain seed test cases; The execution information of the seed test case on the interface under test is obtained. Based on the execution information, a control flow diagram corresponding to the interface under test is generated. Based on the control flow diagram, the uncovered target links corresponding to the interface under test are determined. The fitness scores of the seed test cases to each target link are determined. Based on each fitness score, a fitness vector of the seed test case is generated. For each target link, initial test cases are selected from the seed test cases based on the fitness scores of each seed test case. The value of each dimension in the fitness vector is the fitness score of the seed test case to the corresponding target link. Based on a pre-created test case gene pool, the initial test cases are cross-mutated to obtain extended test cases corresponding to the initial test cases. Based on the initial test cases and the extended test cases, target test cases for the interface to be tested are generated, wherein the genes in the test case gene pool are the parameters included in the reference test cases.

2. The method for generating interface test cases according to claim 1, wherein determining the fitness score of the seed test case to each target link includes: Determine the branch distance and link depth from the seed use case to each target link; Based on the branch distance and link depth from the seed use case to each target link, determine the fitness score of the seed use case to each target link.

3. The method for generating interface test cases according to claim 1, wherein determining the selection probability of each seed test case based on the fitness score of each seed test case includes: The seed use cases are sorted according to their fitness scores, and the selection probability of each seed use case is determined based on the sorting results.

4. The method for generating interface test cases according to claim 1, wherein the step of cross-mutating the initial test cases according to a pre-created test case gene pool to obtain expanded test cases corresponding to the initial test cases includes: Select parent test cases from the initial test cases and obtain the set cross attributes; Based on the cross attributes, the parent use cases are cross-referenced to obtain initial expanded use cases; Based on the pre-created test case gene pool, the initial expanded test cases are mutated to obtain expanded test cases corresponding to the initial test cases.

5. The method for generating interface test cases according to claim 4, wherein the parent test cases are tree structures, and the nodes in the tree structure are the feature parameters included in the parent test cases; the step of crossing the parent test cases according to the cross attribute to obtain initial expanded test cases includes: Based on the cross attribute, determine whether the tree structure corresponding to the parent use case includes the target node corresponding to the cross attribute; If all are included, then directly swap the subtrees corresponding to the target node in the parent use case to obtain the initial expanded use case; If any parent use case is not included, then the node preceding the target node in the target parent use case is determined as the update node, and the subtrees of the parent use case rooted at the update node are swapped to obtain the initial expanded use case, wherein the target parent use case is a parent use case that includes the target node corresponding to the cross attribute.

6. The method for generating interface test cases according to claim 4, wherein the step of mutating the initial expanded test cases according to a pre-created test case gene pool to obtain expanded test cases corresponding to the initial test cases includes: For the target leaf node in the initial expanded use case, the mutation rate of the target leaf node is calculated based on the pre-created use case gene pool, wherein the target leaf node is any leaf node in the initial expanded use case; Based on the mutation rate, determine whether the target leaf node should be mutated; If so, the target gene is obtained from the private gene pool corresponding to the target leaf node, and the target leaf node is assigned a value according to the target gene to obtain the expanded test case corresponding to the initial test case.

7. The method for generating interface test cases according to claim 6, before calculating the mutation rate of the target leaf node based on the pre-created test case gene pool, further comprising: Obtain valid features from the test case execution data corresponding to each interface under test; Retrieve the enumerated and static fields from the code scan; Based on the effective features, the enumerated fields, and the static fields, construct the use case gene pool corresponding to the application under test.

8. The method for generating interface test cases according to claim 7, wherein the test case execution data consists of nested key-value pairs, and the test case gene pool stores the key values ​​corresponding to any key; After constructing the test case gene pool corresponding to the application under test based on the effective features, the enumerated fields, and the static fields, the method further includes: The use case gene pool is expanded based on the key-value pairs of the use case execution data.

9. The method for generating interface test cases according to claim 8, wherein expanding the test case gene pool based on the key-value pairs of the test case execution data includes: Calculate the matching value between each key to be supplemented and the key to be matched. For each key to be supplemented, select the key with the highest matching value that is greater than the confidence threshold as the expanded field corresponding to the key to be supplemented. Then, merge the key to be supplemented with the expanded field; and / or, Determine the cosine distance between the text vector of the value to be supplemented and the vectors of the entire text set. Select the texts with a cosine distance less than a threshold as the texts to be fused corresponding to the value to be supplemented. Then, fuse the value to be supplemented and the texts to be fused.

10. An apparatus for generating interface test cases, comprising: The acquisition module is configured to acquire test case execution data corresponding to the interface to be tested of the application under test, determine the effective features and structural differences in the test case execution data, and perform clustering and filtering on the test case execution data based on the effective features and structural differences to obtain seed test cases; The filtering module is configured to obtain the execution information of the seed test case on the interface under test, generate a control flow diagram corresponding to the interface under test, determine the uncovered target link corresponding to the interface under test based on the control flow diagram, determine the fitness score of the seed test case to each target link, generate the fitness vector of the seed test case based on each fitness score, and for each target link, filter initial test cases from the seed test cases based on the execution information according to the fitness score of each seed test case, wherein the value of each dimension in the fitness vector is the fitness score of the seed test case to the corresponding target link; The generation module is configured to perform cross-mutation on the initial test cases according to a pre-created test case gene pool to obtain extended test cases corresponding to the initial test cases, and generate target test cases for the interface to be tested according to the initial test cases and the extended test cases, wherein the genes in the test case gene pool are the parameters included in the reference test cases.

11. A computing device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions: Obtain test case execution data corresponding to the interface to be tested of the application under test, determine the effective features and structural differences in the test case execution data, and perform clustering and filtering on the test case execution data based on the effective features and structural differences to obtain seed test cases; The execution information of the seed test case on the interface under test is obtained. Based on the execution information, a control flow diagram corresponding to the interface under test is generated. Based on the control flow diagram, the uncovered target links corresponding to the interface under test are determined. The fitness scores of the seed test cases to each target link are determined. Based on each fitness score, a fitness vector of the seed test case is generated. For each target link, initial test cases are selected from the seed test cases based on the fitness scores of each seed test case. The value of each dimension in the fitness vector is the fitness score of the seed test case to the corresponding target link. Based on a pre-created test case gene pool, the initial test cases are cross-mutated to obtain extended test cases corresponding to the initial test cases. Based on the initial test cases and the extended test cases, target test cases for the interface to be tested are generated, wherein the genes in the test case gene pool are the parameters included in the reference test cases.

12. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the method for generating interface test cases according to any one of claims 1 to 9.

Images