Automatic test case generation method and device and medium

Abstract

The invention relates to the technical field of automatic testing, and discloses an automatic test case generation method and device and a medium, and the method comprises the steps: constructing test case knowledge bases of different fields, and carrying out dynamic and static joint feature analysis on code libraries corresponding to field test data; performing intention recognition on the test demand data, and performing atomization operation on the test demand data according to the test demand intention; identifying a test demand code block associated with the test demand data; generating a basic test case of the test demand code block according to the atomization parameter, and injecting an abnormal stream into the basic test case according to the atomization parameter to obtain a target test case; and selecting a similar test case corresponding to the target test case from the test case knowledge base, performing regression test on the test demand code block by using the regression test case, and optimizing the regression test case according to a test result to obtain an automatic test case. According to the invention, the coverage rate during test case generation can be improved.

Description

Technical Field

[0001] The present invention relates to the technical field of automated testing, and particularly to a method, device, and medium for generating automated test cases. Background Art

[0002] During the software development process, by generating test cases, comprehensive testing can be carried out on aspects such as the functionality, performance, and security of the software, helping to discover defects and vulnerabilities in the software, ensuring that the software product meets the needs and expectations of users, and improving the stability and reliability of the software.

[0003] Existing test case generation techniques include generating test cases using predefined rules (such as code coverage tools), but the rule maintenance cost is high and it is difficult to cover complex business logics, or generating test cases through large prediction models, but the models are not optimized for the testing field, the generated results require a large amount of manual correction, and there is a lack of deep integration ability with the test framework, resulting in a low coverage rate when generating test cases. Summary of the Invention

[0004] The present invention provides a method, device, and medium for generating automated test cases, and its main purpose is to solve the problem of low coverage rate when generating test cases.

[0005] To achieve the above object, a method for generating automated test cases provided by the present invention includes: Constructing test case knowledge bases for different fields based on pre-acquired domain test data, and performing dynamic and static joint feature analysis on the code library corresponding to the domain test data to obtain test features of the code in the code library; Performing intent recognition on pre-acquired test requirement data to obtain test requirement intents, and performing atomization operations on the test requirement data according to the test requirement intents to obtain atomized parameters; Identifying test requirement code blocks associated with the test requirement data in the code library according to the test requirement intents and the test features; Generating basic test cases for the test requirement code blocks according to the atomized parameters, and injecting abnormal flows into the basic test cases according to the atomized parameters to obtain target test cases; Selecting similar test cases corresponding to the target test cases in the test case knowledge base, and adding the similar test cases to the target test cases to obtain regression test cases; Performing regression testing on the test requirement code blocks using the regression test cases to obtain test results, and optimizing the regression test cases according to the test results to obtain automated test cases.

[0006] Optionally, constructing a test case knowledge base for different domains based on pre-acquired domain test data includes: Determining code snippets and code coverage data for different domains according to pre-acquired domain test data; Constructing a local abstract syntax tree for the code snippet, extracting code features of the code snippet according to the local abstract syntax tree, and vectorizing the code features to obtain vectorized code; Extracting the associated requirement identifier between the test case and the test requirement in the domain test data; Taking the vectorized code, the code coverage data, and the associated requirement identifier as the node attributes of a pre-created test case node; Constructing a knowledge graph relationship based on the test case nodes with node attributes, and generating a test case knowledge base for different domains according to the knowledge graph relationship.

[0007] Optionally, performing a static and dynamic combined feature analysis on the code library corresponding to the domain test data to obtain test features of the code in the code library, including: Constructing a global abstract syntax tree according to the code library corresponding to the domain test data, and extracting static features of the code in the code library according to the global abstract syntax tree; Performing data flow tracing on the global abstract syntax tree to obtain data flow features; Performing dynamic instrumentation on the code library to obtain instrumentation features; Determining dynamic features of the code in the code library according to the data flow features and the instrumentation features; Combining the static features, the dynamic features, and the risk rules in a pre-acquired risk pattern library as test features of the code in the code library.

[0008] Optionally, performing an atomization operation on the test requirement data according to the test requirement intention to obtain atomized parameters, including: Splitting the requirement text corresponding to the test requirement data into requirement sentences; Extracting the operation action, operation parameter, and operation constraint corresponding to the test requirement intention from the requirement sentences one by one; Determining the operation action, the operation parameter, and the operation constraint as atomized parameters.

[0009] Optionally, identifying a test requirement code block associated with the test requirement data in the code library according to the test requirement intention and the test features, including: Identifying the code entry point corresponding to the test requirement data according to the test requirement intention and the static features in the test features; Identify the code dependency graph corresponding to the test requirement data according to the test requirement intention and the dynamic features in the test features; Match the node data in the code dependency graph with the risk rules in the test features to obtain high-risk nodes, and generate a code high-risk path corresponding to the test requirement intention according to the high-risk nodes; Determine the test requirement code block associated with the test requirement data through the code entry point, the code dependency graph, and the code high-risk path. Optionally, generating a basic test case for the test requirement code block according to the atomization parameter includes: Identify the target operation action in the atomization parameter corresponding to the test requirement code block; Determine the target operation parameter corresponding to the test requirement code block according to the target operation action; Generate the normal flow of the test requirement code according to the target operation parameter; Generate a basic test case for the test requirement code block through the normal flow.

[0010] Optionally, injecting an abnormal flow into the basic test case according to the atomization parameter to obtain a target test case includes: Extract a list of constraint conditions for the test requirement code block according to the operation constraints in the atomization parameter; Solve the opposite constraint condition corresponding to each constraint condition in the list of constraint conditions; Add the opposite constraint condition to the basic test case to obtain a target test case.

[0011] Optionally, selecting a similar test case corresponding to the target test case in the test case knowledge base includes: Calculate the case similarity between the target test case and the test cases in the test case knowledge base; When the case similarity is greater than or equal to a preset similarity threshold, select the test case in the test case knowledge base as the similar test case corresponding to the target test case.

[0012] To solve the above problems, the present invention also provides an electronic device, which includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the above-mentioned automated test case generation method.

[0013] To solve the above problems, the present invention also provides a computer-readable storage medium storing at least one computer program, and the at least one computer program is executed by a processor in an electronic device to implement the above-mentioned automated test case generation method.

[0014] In the embodiment of the present invention, by constructing a test case knowledge base, previous test cases can be reused, avoiding writing test cases from scratch every time; by performing intention recognition and atomization operations on test requirement data, basic test cases can be generated more accurately, and target test cases can be obtained by injecting exception flows, making the test cases more targeted and improving the test coverage and effectiveness; using regression test cases for regression testing and optimizing to obtain automated test cases according to the test results, enriching the test scenarios and realizing the automation of the test process. Therefore, the automated test case generation method, device and medium proposed by the present invention can solve the problem of low coverage rate when generating test cases. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 It is a schematic flowchart of an automated test case generation method provided by an embodiment of the present invention; Figure 2 It is a comparison diagram of test effects provided by an embodiment of the present invention; Figure 3 It is a schematic structural diagram of an electronic device for implementing the automated test case generation method provided by an embodiment of the present invention.

[0016] The implementation, functional features and advantages of the object of the present invention will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0017] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0018] An embodiment of the present application provides a method for generating automated test cases. The execution subject of the method for generating automated test cases includes, but is not limited to, at least one of electronic devices such as a server, a terminal, etc. that can be configured to execute the method provided in the embodiment of the present application. In other words, the method for generating automated test cases can be executed by software or hardware installed on a terminal device or a server device, and the software can be a blockchain platform. The server includes, but is not limited to: a single server, a server cluster, a cloud server, or a cloud server cluster, etc. The server can be an independent server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, Content Delivery Network (CDN), and big data and artificial intelligence platforms.

[0019] Referring to Figure 1 As shown, it is a schematic flowchart of the method for generating automated test cases provided by an embodiment of the present invention. In this embodiment, the method for generating automated test cases includes: S1. Based on the pre-acquired domain test data, construct test case knowledge bases for different domains, and perform dynamic and static combined feature analysis on the code libraries corresponding to the domain test data to obtain the test features of the code in the code libraries.

[0020] In the embodiment of the present invention, domain test data refers to the data collected and accumulated during the testing process in a specific domain (such as finance, Internet of Things, medical, etc.), including various information related to testing, such as code snippets, test cases, test requirements, test results, code coverage data, etc.; the test case knowledge base is a resource library that centrally stores and manages information related to test cases in different domains, organizes data in the form of a knowledge graph, includes test case nodes and the relationships between the nodes, and each test case node includes attribute information such as vectorized code related to the test case, code coverage data, associated requirement identifiers, etc.

[0021] In the embodiment of the present invention, the constructing test case knowledge bases for different domains based on the pre-acquired domain test data includes: Determine the code snippets and code coverage data for different domains according to the pre-acquired domain test data; Construct a local abstract syntax tree of the code snippet, extract the code features of the code snippet according to the local abstract syntax tree, and vectorize the code features to obtain vectorized code; Extract the associated requirement identifiers between the test cases and test requirements in the domain test data; Take the vectorized code, the code coverage data, and the associated requirement identifier as the node attributes of a pre-created test case node; Construct a knowledge graph relationship based on the test case nodes with assigned node attributes, and generate test case knowledge bases in different domains according to the knowledge graph relationship.

[0022] Specifically, from the pre-obtained domain test data, filter out the code snippets related to testing. A code snippet is a part of the code that implements a specific function or requirement. At the same time, determine the code coverage data of the code snippet. The code coverage data reflects the coverage degree of the test case for the code, such as which code lines are executed and which code branches are covered. For the determined code snippet, use abstract syntax tree (AST) parsing to convert the code into the form of an abstract syntax tree, that is, construct the abstract syntax tree corresponding to a single code snippet, namely the local abstract syntax tree. The local abstract syntax tree represents the syntax structure of the code in a tree structure and can clearly show the logical relationship of the code. Extract the code features from the abstract syntax tree. The code features can include function call relationships, variable usage, conditional judgments, etc. Then perform vectorization processing on the code features, that is, convert them into vector forms for easy processing and comparison by the computer.

[0023] Specifically, in the domain test data, determine the association relationship between the test case and the test requirement, and extract the associated requirement identifier. The associated requirement identifier is the unique identifier of the requirement or other information that can clearly represent the corresponding relationship between the test case and the requirement. That is, the test case is triggered by the test requirement, and the test requirement needs to be verified by the test case, that is, clarify the corresponding relationship between the requirement and the test case, which is beneficial to establish the connection between the requirement and the test case in the knowledge base so as to find the corresponding test case according to the requirement during the test process. Then add the vectorized code, the code coverage data, and the associated requirement identifier as the attributes of the node to the pre-created test case node. That is, each test case node contains the code information, coverage situation, and requirement association information related to the test case, enabling the test case node to comprehensively describe the relevant information of a test case. Then, according to the attributes of the test case node and the association relationship between them, construct a knowledge graph relationship. A knowledge graph is a way to represent knowledge in a graphical structure, where nodes represent entities (such as test cases, requirements, etc.), and edges represent the relationships between entities (such as the relationship that a test case covers a requirement). By constructing the knowledge graph relationship, clearly represent each test case node and its relationship with the requirement, and thus generate test case knowledge bases in different domains according to the constructed knowledge graph relationship.

[0024] Furthermore, in order to understand the structure and logical framework of the code and obtain the behavioral details of the code during actual operation, so as to comprehensively cover various behaviors of the code, it is necessary to perform static and dynamic combined analysis on the code, so as to more accurately determine the test features of the code.

[0025] In the embodiments of the present invention, the test feature refers to the information that can comprehensively describe the characteristics of the code obtained through static and dynamic combined feature analysis of the code library, such as high-risk paths, code entry points, and code call relationship graphs.

[0026] In the embodiments of the present invention, performing static and dynamic combined feature analysis on the code library corresponding to the domain test data to obtain the test features of the code in the code library includes: Constructing a global abstract syntax tree according to the code library corresponding to the domain test data, and extracting the static features of the code in the code library according to the global abstract syntax tree; Performing data flow tracing on the global abstract syntax tree to obtain data flow features; Performing dynamic instrumentation on the code library to obtain instrumentation features; Determining the dynamic features of the code in the code library according to the data flow features and the instrumentation features; Combining the static features, the dynamic features and the risk rules in the pre-obtained risk pattern library into the test features of the code in the code library.

[0027] Specifically, call the build_ast function to perform static analysis on the code library, convert the code into an abstract syntax tree, then construct the abstract syntax trees corresponding to all the code in the complete code library, that is, the global abstract syntax tree; the global abstract syntax tree can clearly display the structure and logic of the code, including function calls, conditional judgments, loops, etc. Based on the constructed global abstract syntax tree, use the track_variables function to perform data flow tracing, and the data flow tracing process will record the definition and usage of variables, as well as the flow path of data in the code, which helps to discover potential security vulnerabilities and logical errors; use the dynamic_probe function to perform dynamic instrumentation on the code library, insert monitoring code into the code, and when the program runs, the monitoring code will record the execution path information of the code, such as which code blocks are executed and the order of execution.

[0028] Specifically, the static features include the structural information of the code, such as function definitions, variable declarations, control flow structures, and the syntactic information of the code. For example, the list_public_methods function is used to find the public methods in the code library, and public methods are often the entry points of the code, which are related to the invocation and execution of requirements. The call graph of the code is generated through the map_call_graph function to show the call relationships between various modules, functions, or classes in the code, helping to understand the dependency structure of the code. The dynamic features describe the behavior of the code during runtime. By combining data flow features and instrumentation features, the dynamic features of the code can be comprehensively determined. For example, through data flow tracing and instrumentation, under specific inputs, it can be determined which code paths are executed, how variables change as the code executes, and the execution frequencies of different parts of the code. For instance, by combining the abstract syntax tree, data flow information, and predefined risk rules (such as SQL injection, race conditions, etc.), the detect_high_risk_paths function is called to detect high-risk paths in the code, and high-risk paths are usually closely related to the security and correctness of the requirements. Thus, the static features, dynamic features, and risk rules in the pre-acquired risk pattern library are combined to form complete code test features.

[0029] Furthermore, in order to accurately match test cases with test requirements, it is necessary to identify the intent of the test requirements to determine the test category of the test requirements.

[0030] S2. Identify the intent of the pre-acquired test requirement data to obtain the test requirement intent, and perform an atomization operation on the test requirement data according to the test requirement intent to obtain atomized parameters.

[0031] In the embodiments of the present invention, the test requirement intent refers to the test intent corresponding to the test requirement data, including but not limited to functionality, performance, and security. Among them, the requirement document or requirement description is obtained and preliminarily processed through natural language processing (NLP) technology. For example, the spaCy_NER function is used for named entity recognition to determine the key entities in the requirement, such as users, orders, products, etc.; the BertClassifier is used for intent classification to determine whether the requirement belongs to categories such as functional requirements, performance requirements, or security requirements.

[0032] Furthermore, in order to perform testing more effectively, it is necessary to refine and decompose the test requirements to transform them into more specific and operable elements, so that the specific goals and requirements of the test can be clearly defined.

[0033] In the embodiments of the present invention, the atomized parameter refers to the smallest test unit obtained after performing an atomization operation on the test requirement data, which has clear operation actions, operation parameters, and operation constraints.

[0034] In an embodiment of the present invention, the atomization operation on the test requirement data according to the test requirement intention to obtain atomization parameters includes: Splitting the requirement text corresponding to the test requirement data into requirement sentences; Extracting operation actions, operation parameters, and operation constraints corresponding to the test requirement intention from the requirement sentences one by one; Determining the operation actions, the operation parameters, and the operation constraints as atomization parameters.

[0035] Specifically, the requirement text corresponding to the test requirement data is split into independent sentences according to grammar rules or semantic logic. Each sentence can be used as an independent analysis unit. For each requirement sentence after splitting, according to the pre-determined test requirement intention (for example, functional test intention, performance test intention, or security test intention, etc.), key information is extracted from it. The key information includes operation actions, operation parameters, and operation constraints. Among them, the operation action is the specific behavior or operation described in the requirement, such as user login; the operation parameter is the input or related data involved in the operation action, such as username and password; the operation constraint represents the limiting conditions for the operation action or operation parameter, such as the password length being greater than 6. Thus, the operation action, operation parameter, and operation constraint are encapsulated into an atomic operation object.

[0036] Exemplarily, when splitting the requirement text into multiple atomic operations, each sentence in the requirement text is traversed. The extract_verb_phrase function is used to extract action information (such as user login, placing an order for goods), the extract_noun_phrases function is used to extract parameter information (such as username, password, product ID), and the extract_constraints function is used to extract constraint conditions (such as password length ≥ 6, order amount > 0). These information are encapsulated into atomic operation objects and stored in a list.

[0037] Furthermore, the test requirement intention describes the goal and direction of the test. For example, it is to perform a functional test, a performance test, or a security test, etc. In order to improve the efficiency and accuracy of the test, it is necessary to combine the test requirement intention and the test characteristics to more precisely locate the specific code block to be tested in the code library.

[0038] S3. Identifying the test requirement code block associated with the test requirement data in the code library according to the test requirement intention and the test characteristics.

[0039] In an embodiment of the present invention, the test requirement code block refers to a group of codes in the code library associated with specific test requirement data.

[0040] In an embodiment of the present invention, identifying the test requirement code block associated with the test requirement data in the code library according to the test requirement intention and the test characteristics includes: Identifying the code entry point corresponding to the test requirement data according to the test requirement intention and the static characteristics in the test characteristics; Identifying the code dependency graph corresponding to the test requirement data according to the test requirement intention and the dynamic characteristics in the test characteristics; Matching the node data in the code dependency graph with the risk rules in the test characteristics to obtain high-risk nodes, and generating a code high-risk path corresponding to the test requirement intention according to the high-risk nodes; Determining the test requirement code block associated with the test requirement data through the code entry point, the code dependency graph, and the code high-risk path.

[0041] Specifically, according to the extracted key information, mark the code blocks related to the requirements, that is, identify the code entry point according to the static characteristics, and identify the code dependency graph according to the dynamic characteristics. For example, if the requirement is user login, then the entry point method related to the login function, the dependent verification method, and the code blocks involved in security processing will all be marked; load the predefined risk patterns from the rule library (such as configuration files, databases), support multiple risk types (such as SQL injection, race conditions, null pointer references, etc.), then traverse the code dependency graph of the code, query the nodes that match the patterns defined in the risk rules, such as marking the matching high-risk functions, and perform data flow tracing on the marked nodes to obtain the code high-risk path.

[0042] Specifically, match the atomized requirement operations with the marked associated code blocks. For example, if the atomic operation is user login, it may correspond to the login method and its related dependent code in the code. Then, by establishing a mapping relationship, the specific implementation location of each requirement operation in the code can be clarified.

[0043] Furthermore, in order to ensure the quality and reliability of the software, it is necessary to write comprehensive and effective test cases for different test requirements.

[0044] S4. Generating a basic test case for the test requirement code block according to the atomized parameters, and injecting an abnormal flow into the basic test case according to the atomized parameters to obtain a target test case.

[0045] In an embodiment of the present invention, the basic test case is constructed based on the atomized analysis of the test requirements, starting from the target operation actions and parameters, and following the logic of the normal flow.

[0046] In the embodiments of the present invention, the basic test cases for generating the test requirement code block according to the atomization parameters include: Identifying the target operation action in the atomization parameters corresponding to the test requirement code block; Determining the target operation parameters corresponding to the test requirement code block according to the target operation action; Generating the normal flow of the test requirement code according to the target operation parameters; Generating the basic test cases for the test requirement code block through the normal flow.

[0047] Specifically, the atomization parameters are the basic elements obtained by decomposing the test requirement data. Among them, the operation action describes the specific behavior that needs to be executed in the test requirement. For the test requirement code block, the key operation action needs to be determined first. For example, in the test requirement code block related to the user login function, the target operation action in the atomization parameters may be to input the username and password, click the login button, etc. The operation parameters are the specific data or conditions required when the operation action is executed. Taking the operation action of inputting the username and password as an example, the target operation parameters are the specific username and password values.

[0048] Specifically, the normal flow refers to the process that the test requirement code should follow under ideal conditions, executing in the correct order of the target operation parameter input and the operation action. According to the determined target operation parameters, each operation action is combined in a reasonable order to form a coherent execution process, that is, the normal flow of the test requirement code. For example, in the user login function, the normal flow may be to first input the correct username and password, then click the login button, and after the system verification passes, jump to the main page. According to the determined target operation parameters, each operation action is combined in a reasonable order to form a coherent execution process, which is the normal flow of the test requirement code. The basic test cases are constructed based on the normal flow, describing a complete test scenario, including the preconditions, execution steps, and expected results of the test. According to the operation actions and parameters determined in the normal flow, the specific steps of the test are described in detail, as well as the results expected after the execution of these steps.

[0049] Exemplarily, using the generate_base_case function, the basic test path is generated according to the parameters of the atomic operation, and the basic test path simulates the execution process of the system under normal conditions, which is used to verify whether the basic functions of the system are normal. For example, for the user login requirement, the basic test path may include inputting the correct username and password, and then verifying whether the login is successful.

[0050] Furthermore, during the actual operation of the software, various abnormal situations may occur, such as inputting data that does not meet the requirements, insufficient system resources, network interruption, etc. To more comprehensively test the robustness and reliability of the software, relying solely on basic test cases is not enough, and abnormal situations need to be considered.

[0051] In the embodiments of the present invention, the target test case refers to a test case obtained by injecting an abnormal flow (i.e., adding opposite constraint conditions) on the basis of the basic test case, which not only includes the test scenarios of the software under normal circumstances but also covers the test scenarios of various abnormal situations.

[0052] In the embodiments of the present invention, injecting an abnormal flow into the basic test case according to the atomization parameters to obtain a target test case includes: Extracting a list of constraint conditions for the test requirement code block according to the operation constraints in the atomization parameters; Solving the opposite constraint condition corresponding to each constraint condition in the list of constraint conditions; Adding the opposite constraint condition to the basic test case to obtain a target test case.

[0053] Specifically, the operation constraint is a limiting condition for the operation action or operation parameter, and the constraint condition reflects the requirements for input or operation during the normal operation of the software. Extracting the operation constraint from the atomization parameters to form a list of constraint conditions clarifies the limiting conditions for the normal operation of the software; for each extracted constraint condition, it is necessary to solve the opposite constraint condition, which refers to a situation contrary to the normal constraint condition and is used to simulate abnormal input or operation. After obtaining the opposite constraint condition and adding it to the basic test case, since the basic test case was originally designed according to normal situations, adding the opposite constraint condition can simulate the operation scenario of the software under abnormal situations.

[0054] Specifically, the code analysis engine extracts input parameter constraints (such as x>0&&x<100), uses the Z3 solver to generate boundary values that violate the constraints (such as x = 0, x = 100, x = -1), automatically constructs abnormal input test cases and injects them into the simulation environment. Compared with random testing, the defect discovery rate is increased by 45%. That is, by traversing the constraint conditions (code_analysis["constraints"]) in the code analysis results and using the z3_solve function to solve the values that violate these constraint conditions in the violate mode. For example, for the constraint that the password length ≥ 6, the password value with a length less than 6 is solved, and then the value that violates the constraint is added as abnormal input to the basic test path to generate an extended test path, and the extended path is used to test the processing ability of the system under abnormal situations. For example, when an incorrect username or password is input, whether the system can correctly prompt an error message.

[0055] Further, historical test cases, code defect patterns, and business rules are stored in the knowledge base and associated with the current requirements through a semantic matching engine.

[0056] S5. Select similar test cases corresponding to the target test case in the test case knowledge base, and add the similar test cases to the target test case to obtain regression test cases.

[0057] In the embodiment of the present invention, the similar test case refers to a test case in the test case knowledge base that has a high degree of similarity with the target test case in multiple aspects such as operation actions, operation parameters, and expected results.

[0058] In the embodiment of the present invention, the selecting the similar test cases corresponding to the target test case in the test case knowledge base includes: Calculating the case similarity between the target test case and the test cases in the test case knowledge base; When the case similarity is greater than or equal to a preset similarity threshold, select the test case in the test case knowledge base as the similar test case corresponding to the target test case.

[0059] Specifically, the test cases in the test case knowledge base are all vectorized. Then the target test case is vectorized, and the cosine similarity algorithm is used to calculate the similarity between the vectorized target test case and the test cases in the test case knowledge base. When the calculated case similarity is greater than or equal to the similarity threshold, it means that the test case in the knowledge base is similar to the target test case, and it can be selected as the similar test case corresponding to the target test case. That is, use the knowledge_base.query method to query similar test paths in the knowledge base according to the abstract syntax tree features in the code analysis results, and set an appropriate similarity threshold (such as 0.85) to ensure that the queried test paths have a high correlation with the current requirements and the code.

[0060] Exemplarily, when a loop nested structure is detected in the code, the generation of boundary value test cases is automatically triggered (such as the extreme values of loop variables, empty iteration scenarios). Then, compared with the traditional rule engine, the matching accuracy is improved by more than 30% through vectorized code pattern matching (TF-IDF + code abstract syntax tree features).

[0061] Furthermore, integrate the expected results and execution steps of the queried similar test paths with the currently generated test path to generate a regression test path. The regression test path is used to ensure that after the code is modified in the system, the previous functions still work properly and no new problems are introduced. That is, relevant information such as test steps, test data, and expected results in similar test cases are appropriately adjusted and merged according to the specific situation of the target test case, and the selected test cases are added to the target test case to enrich the test content of the target test case, enabling it to more comprehensively test the relevant functions of the software, thereby obtaining regression test cases. A regression test case refers to a test case designed and executed to verify whether the original functions of the software are affected after the software is changed. By executing the regression test cases, potential problems brought about by software modification can be discovered in a timely manner, ensuring that there are no unexpected function regressions or defects during the software iteration process.

[0062] S6. Use the regression test cases to perform regression testing on the test requirement code block, obtain test results, and optimize the regression test cases according to the test results to obtain automated test cases.

[0063] In the embodiments of the present invention, the test results refer to the evaluation information on aspects such as the function, performance, and stability of the code block obtained after performing regression testing on the test requirement code block, such as the execution status (success or failure) of the test case, defect information (such as the location where the defect appears, specific manifestations, and scope of influence), statistical data (such as the number of passed and failed test cases, test coverage), etc.

[0064] Specifically, use a test framework (such as unittest or pytest in Python) to execute the generated test path, record the test results, analyze the problems existing in the system according to the test results, and feedback the problems to the developers for repair. At the same time, reflect on and improve the test path generation process to continuously improve the generation quality and efficiency of the test path.

[0065] Furthermore, regression testing is an important means to ensure that the original functions of the software still work properly after modification or update. However, the initial regression test cases may not be perfect, with problems such as incomplete coverage and insufficient consideration of boundary conditions. By optimizing the regression test cases according to the test results, the quality and effectiveness of the test cases can be improved, and potential defects in the software can be discovered more comprehensively.

[0066] In the embodiments of the present invention, the automated test cases refer to the optimized test cases automatically executed by an automated test tool or script.

[0067] In an embodiment of the present invention, optimizing the regression test cases according to the test results to obtain automated test cases includes: Optimizing the covered code branches, boundary conditions, and similar test cases corresponding to the regression test cases according to the test results; Optimizing the regression test cases according to the covered code branches, the boundary conditions, and the similar test cases to obtain a test optimization result; Updating the test results to the test optimization result and returning to the step of optimizing the covered code branches, boundary conditions, and similar test cases corresponding to the regression test cases according to the test results until the test optimization result meets the preset test result conditions; When the test optimization result meets the preset test result conditions, generating automated test cases.

[0068] Specifically, the test results may show that some code branches are not covered by the regression test cases. In this case, it is necessary to analyze the reasons for the non-coverage according to the test results and adjust the regression test cases so that they can cover these unexecuted code branches. Boundary conditions refer to the maximum value, minimum value, limit value, etc. of the input data. According to the test results, it is necessary to optimize the boundary conditions in the regression test cases and add more boundary value tests to ensure the stability and correctness of the software in boundary situations. If the test results indicate that some similar test cases are redundant or not comprehensive enough, it is necessary to optimize these similar test cases.

[0069] Specifically, after completing the optimization of the covered code branches, boundary conditions, and similar test cases, apply these optimization contents to the regression test cases, such as modifying the input data of the test cases to cover new code branches, adding boundary value test cases, merging or adjusting similar test cases, etc. Execute these optimized regression test cases again to obtain new test results. Each time a test optimization result is obtained, use it as the new test result, analyze and optimize the covered code branches, boundary conditions, and similar test cases again. Through continuous iteration, gradually improve the quality of the test cases until the preset conditions are met. When the test optimization result meets the preset test result conditions after multiple iterations of optimization, it means that the regression test cases have reached a relatively high quality level. At this time, convert the optimized regression test cases into automated test cases.

[0070] Further, such as Figure 2As shown in the figure, it is a comparison chart of the test effects between the present invention and the traditional solution. The test effect of the present invention has been significantly improved. For example, the test case generation speed of the present invention is 5 minutes / case, while that of the traditional solution is 2 hours / case, and the improvement effect is 24 times; the requirement coverage rate of the present invention is 92%, while that of the traditional solution is 68%, and the improvement effect is +35%. The requirement coverage rate refers to the coverage degree of test cases for requirements such as functions, features, and scenarios specified in the software requirement specification, which is measured by calculating the ratio of the covered requirement quantity to the total requirement quantity. Therefore, performing intent recognition and atomization operations on the test requirement data can accurately analyze the test requirements and decompose them into more detailed atomic parameters, so as to generate more targeted basic test cases according to the atomic parameters, ensuring that the test cases can cover more requirement points; secondly, the combined static and dynamic feature analysis comprehensively obtains the test features of the code, which helps to discover more code paths and function points related to the requirements, enabling the test cases to cover more parts of the code library related to the requirements. In addition, selecting similar test cases from the test case knowledge base and adding them to the target test cases further enriches the test scenarios and increases the coverage range of various requirements. These features cooperate with each other, enabling the test cases of the present invention to more comprehensively cover the software requirements. Compared with the traditional solution, the requirement coverage rate has been significantly improved, and the improvement effect is +35%; the boundary condition missing rate of the present invention is 9%, while that of the traditional solution is 41%, and the improvement effect is a 78% reduction in the missing rate. The boundary condition missing rate refers to the proportion of the test cases that do not cover or handle the boundary conditions, that is, the combined static and dynamic feature analysis of the code library plays an important role in reducing the boundary condition missing rate. Through dynamic analysis, the behavior of the code during operation can be observed, making it easier to discover some hidden boundary conditions; static analysis can sort out the possible boundary situations from the code structure. Optimizing the test cases based on the analysis results can consider various boundary conditions more comprehensively, thus reducing the missing of boundary conditions. At the same time, optimizing the regression test cases according to the test results, including continuously adjusting and improving the boundary conditions, also helps to reduce the boundary condition missing rate. Through these measures, the boundary condition missing rate of the present invention is significantly reduced compared with the traditional solution, and the improvement effect is a 78% reduction in the missing rate.

[0071] As Figure 3 shown, it is a schematic structural diagram of an electronic device for implementing an automated test case generation method provided by an embodiment of the present invention.

[0072] The electronic device may include a processor 10, a memory 11, a communication bus 12, and a communication interface 13, and may also include a computer program stored in the memory 11 and executable on the processor 10, such as an automated test case generation program.

[0073] Among them, in some embodiments, the processor 10 may be composed of an integrated circuit. For example, it may be composed of a single packaged integrated circuit, or may be composed of multiple packaged integrated circuits with the same or different functions, including a combination of one or more central processing units (CPUs), microprocessors, digital processing chips, graphics processors, and various control chips. The processor 10 is the control core (Control Unit) of the electronic device, connecting various components of the entire electronic device through various interfaces and lines. By running or executing programs or modules stored in the memory 11 (such as executing an automated test case generation program, etc.), and calling the data stored in the memory 11, it performs various functions of the electronic device and processes data.

[0074] The memory 11 includes at least one type of readable storage medium. The readable storage medium includes flash memory, mobile hard disks, multimedia cards, card-type memories (such as SD or DX memories, etc.), magnetic memories, magnetic disks, optical discs, etc. In some embodiments, the memory 11 may be an internal storage unit of the electronic device, such as the mobile hard disk of the electronic device. In some other embodiments, the memory 11 may also be an external storage device of the electronic device, such as a plug-in mobile hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device. Further, the memory 11 may also include both an internal storage unit and an external storage device of the electronic device. The memory 11 can be used not only to store application software installed on the electronic device and various types of data, such as the code of an automated test case generation program, etc., but also to temporarily store data that has been output or will be output.

[0075] The communication bus 12 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. This bus can be divided into an address bus, a data bus, a control bus, etc. The bus is set to achieve connection communication between the memory 11 and at least one processor 10, etc.

[0076] The communication interface 13 is used for communication between the above-mentioned electronic device and other devices, including a network interface and a user interface. Optionally, the network interface may include a wired interface and / or a wireless interface (such as a WI-FI interface, a Bluetooth interface, etc.), which is generally used to establish a communication connection between this electronic device and other electronic devices. The user interface may be a display, an input unit (such as a keyboard), and optionally, the user interface may also be a standard wired interface or a wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch liquid crystal display, and an OLED (Organic Light-Emitting Diode) toucher, etc. Among them, the display may also be appropriately referred to as a display screen or a display unit, which is used to display the information processed in the electronic device and to display a visual user interface.

[0077] Only the electronic device with components is shown in the figure. Those skilled in the art can understand that the structure shown in the figure does not constitute a limitation on the electronic device, and it may include fewer or more components than shown in the figure, or combine certain components, or have different component arrangements.

[0078] For example, although not shown, the electronic device may further include a power source (such as a battery) for supplying power to each component. Preferably, the power source may be logically connected to the at least one processor 10 through a power management device, so as to implement functions such as charge management, discharge management, and power consumption management through the power management device. The power source may also include any components such as one or more DC or AC power sources, a recharge device, a power failure detection circuit, a power converter or an inverter, and a power status indicator. The electronic device may also include various sensors, a Bluetooth module, a Wi-Fi module, etc., which will not be elaborated here.

[0079] It should be understood that the above embodiments are only for illustration purposes and are not limited by this structure in the scope of the patent application.

[0080] The automated test case generation program stored in the memory 11 of the electronic device is a combination of multiple instructions. When running in the processor 10, it can realize: Construct test case knowledge bases for different fields based on pre-acquired field test data, and perform dynamic and static joint feature analysis on the code library corresponding to the field test data to obtain the test features of the code in the code library; Perform intent recognition on the pre-acquired test requirement data to obtain a test requirement intent, and perform atomization operations on the test requirement data according to the test requirement intent to obtain atomized parameters; Identify the test requirement code block associated with the test requirement data in the code library according to the test requirement intention and the test characteristics; Generate a basic test case for the test requirement code block according to the atomization parameters, and inject an abnormal flow into the basic test case according to the atomization parameters to obtain a target test case; Select a similar test case corresponding to the target test case from the test case knowledge base, and add the similar test case to the target test case to obtain a regression test case; Use the regression test case to perform a regression test on the test requirement code block to obtain a test result, and optimize the regression test case according to the test result to obtain an automated test case.

[0081] Specifically, the specific implementation method of the above instructions by the processor 10 can refer to the description of the relevant steps in the corresponding embodiments of the accompanying drawings, which will not be elaborated here.

[0082] Further, if the integrated module / unit of the electronic device is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. The computer-readable storage medium can be volatile or non-volatile. For example, the computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a mobile hard disk, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM, Read-Only Memory).

[0083] The present invention also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor of an electronic device, it can implement: Construct a test case knowledge base for different fields based on pre-acquired domain test data, and perform dynamic and static joint feature analysis on the code library corresponding to the domain test data to obtain the test characteristics of the code in the code library; Perform intention recognition on pre-acquired test requirement data to obtain a test requirement intention, and perform atomization operation on the test requirement data according to the test requirement intention to obtain atomization parameters; Identify the test requirement code block associated with the test requirement data in the code library according to the test requirement intention and the test characteristics; Generate a basic test case for the test requirement code block according to the atomization parameters, and inject an abnormal flow into the basic test case according to the atomization parameters to obtain a target test case; Select the similar test cases corresponding to the target test case in the test case knowledge base, and add the similar test cases to the target test case to obtain regression test cases. Use the regression test cases to perform regression testing on the test requirement code block, obtain test results, and optimize the regression test cases according to the test results to obtain automated test cases.

[0084] In several embodiments provided by the present invention, it should be understood that the disclosed devices, media, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the modules is only a logical function division, and there may be other division methods in actual implementation.

[0085] The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. [[ID=X]]

[0086] In addition, in each embodiment of the present invention, the functional modules can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated units can be implemented in the form of hardware, or in the form of hardware plus software functional modules.

[0087] For those skilled in the art, it is obvious that the present invention is not limited to the details of the above-mentioned exemplary embodiments, and can be implemented in other specific forms without departing from the spirit or basic characteristics of the present invention.

[0088] Therefore, from any point of view, the embodiments should be regarded as exemplary and non-limiting. The scope of the present invention is not limited only by the above description. Therefore, it is intended to include all changes within the meaning and scope of equivalent elements falling within the protection scope in the present invention.

[0089] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Among them, artificial intelligence (AI) is a theory, method, technology, and application system that uses a digital computer or a machine controlled by a digital computer to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use knowledge to obtain the best results.

[0090] In addition, it is obvious that the term "comprising" does not exclude other units or steps, and the singular form does not exclude the plural form. A plurality of units or devices stated in the system can also be implemented by one unit or device through software or hardware. Terms such as first, second, etc. are used to denote names and do not denote any particular order.

[0091] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to the preferred embodiments, those of ordinary skill in the art should understand that the technical solutions of the present invention can be modified or equivalently replaced without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. An automated test case generation method, characterized in that, The method includes: Constructing test case knowledge bases for different domains based on pre-acquired domain test data, and performing dynamic and static combined feature analysis on the code libraries corresponding to the domain test data to obtain test features of the code in the code libraries; Performing intent recognition on pre-acquired test requirement data to obtain test requirement intents, and performing atomization operations on the test requirement data according to the test requirement intents to obtain atomized parameters; Identifying test requirement code blocks associated with the test requirement data in the code library according to the test requirement intents and the test features; Generating basic test cases for the test requirement code blocks according to the atomized parameters, and injecting abnormal flows into the basic test cases according to the atomized parameters to obtain target test cases; Selecting similar test cases corresponding to the target test cases in the test case knowledge base, and adding the similar test cases to the target test cases to obtain regression test cases; Performing regression testing on the test requirement code blocks by using the regression test cases to obtain test results, and optimizing the regression test cases according to the test results to obtain automated test cases.

2. The automated test case generation method according to claim 1, wherein The constructing test case knowledge bases for different domains based on pre-acquired domain test data includes: Determining code segments and code coverage data for different domains according to pre-acquired domain test data; Constructing local abstract syntax trees for the code segments, extracting code features of the code segments according to the local abstract syntax trees, and vectorizing the code features to obtain vectorized code; Extracting association requirement identifiers between test cases and test requirements in the domain test data; Taking the vectorized code, the code coverage data, and the association requirement identifiers as node attributes of pre-created test case nodes; Constructing knowledge graph relationships according to the test case nodes with node attributes, and generating test case knowledge bases for different domains according to the knowledge graph relationships.

3. The automated test case generation method according to claim 1, wherein The performing dynamic and static combined feature analysis on the code library corresponding to the domain test data to obtain test features of the code in the code library includes: Constructing a global abstract syntax tree according to the code library corresponding to the domain test data, and extracting static features of the code in the code library according to the global abstract syntax tree; Performing data flow tracing on the global abstract syntax tree to obtain data flow features; Performing dynamic instrumentation on the code library to obtain instrumentation features; Determining dynamic features of the code in the code library according to the data flow features and the instrumentation features; Combining the static features, the dynamic features, and risk rules in a pre-acquired risk pattern library as test features of the code in the code library.

4. The automated test case generation method according to claim 1, wherein The performing atomization operations on the test requirement data according to the test requirement intents to obtain atomized parameters includes: Splitting the requirement text corresponding to the test requirement data into requirement sentences; Successively extracting operation actions, operation parameters, and operation constraints corresponding to the test requirement intents in the requirement sentences; Determining the operation actions, the operation parameters, and the operation constraints as atomized parameters.

5. The automated test case generation method according to claim 1, characterized in that Identifying the test requirement code block associated with the test requirement data in the code library according to the test requirement intention and the test characteristics includes: Identifying the code entry point corresponding to the test requirement data according to the static characteristics in the test requirement intention and the test characteristics; Identifying the code dependency graph corresponding to the test requirement data according to the dynamic characteristics in the test requirement intention and the test characteristics; Matching the node data in the code dependency graph with the risk rules in the test characteristics to obtain high-risk nodes, and generating a code high-risk path corresponding to the test requirement intention according to the high-risk nodes; Determining the test requirement code block associated with the test requirement data through the code entry point, the code dependency graph, and the code high-risk path.

6. The automated test case generation method according to claim 1, wherein Generating the basic test cases for the test requirement code block according to the atomization parameters includes: Identifying the target operation action in the atomization parameters corresponding to the test requirement code block; Determining the target operation parameters corresponding to the test requirement code block according to the target operation action; Generating the normal flow of the test requirement code according to the target operation parameters; Generating the basic test cases for the test requirement code block through the normal flow.

7. The automated test case generation method according to claim 1, wherein Injecting an abnormal flow into the basic test cases according to the atomization parameters to obtain target test cases includes: Extracting a list of constraint conditions for the test requirement code block according to the operation constraints in the atomization parameters; Solving the opposite constraint conditions corresponding to each constraint condition in the list of constraint conditions; Adding the opposite constraint conditions to the basic test cases to obtain target test cases.

8. The automated test case generation method according to claim 1, wherein Selecting similar test cases corresponding to the target test cases in the test case knowledge base includes: Calculating the case similarity between the target test cases and the test cases in the test case knowledge base; When the case similarity is greater than or equal to a preset similarity threshold, selecting the test cases in the test case knowledge base as the similar test cases corresponding to the target test cases.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the automated test case generation method according to any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, The computer program, when executed by a processor, implements the automated test case generation method according to any one of claims 1 to 8.

Images