An intelligent analysis-based automatic test case generation method

Abstract

The application provides an automatic test case generation method based on intelligent analysis, and relates to the technical field of software testing.The automatic test case generation method based on intelligent analysis obtains a requirement document and software source code of software to be detected, performs text preprocessing on the requirement document to obtain a requirement semantic unit, performs abstract syntax tree analysis on the software source code to obtain code structure information, performs semantic role labeling and relation extraction on the requirement semantic unit, constructs a requirement semantic relation graph with a function entity as a node and logical relation, limitation relation and trigger relation as edges, extracts data constraints from the requirement semantic relation graph by using a pre-constructed domain dictionary to generate a boundary constraint rule set and an abnormal scenario rule set, and performs control flow analysis and semantic analysis on the software source code to generate a test path set covering normal paths, boundary paths and abnormal paths.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, specifically to an automated test case generation method based on intelligent analysis. Background Technology

[0002] As software systems grow in scale and business logic complexity, software quality assurance faces severe challenges. In the software development lifecycle, test case design and generation are core components for ensuring the correctness, robustness, and security of software functionality. Traditional manual test case writing methods heavily rely on testers' business understanding and experience, which is not only time-consuming and labor-intensive, but also inefficient and unable to keep up with the rapid iteration pace of development.

[0003] Currently, automated test case generation technologies mainly include symbolic execution and random test generation based on static code analysis, model-based test generation, and test generation based on natural language processing. However, these existing technologies still face several common bottlenecks in practical application: while code analysis-based methods can traverse program paths, they lack an understanding of the semantics of business requirements, and the generated test inputs are mostly mechanical values ​​that satisfy path reachability, making it difficult to reflect the real constraints and exception triggering conditions in real business scenarios.

[0004] Therefore, this invention provides an automated test case generation method based on intelligent analysis. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides an automated test case generation method based on intelligent analysis, comprising the following steps:

[0006] Step S1: Obtain the requirements document and software source code of the software to be tested; perform text preprocessing on the requirements document to obtain requirements semantic units; perform abstract syntax tree parsing on the software source code to obtain code structure information;

[0007] Step S2: Perform semantic role labeling and relationship extraction on the required semantic units to construct a required semantic relationship graph with functional entities as nodes and logical relationships, limiting relationships and triggering relationships as edges; and use a pre-built domain dictionary to extract data constraints from the required semantic relationship graph to generate a set of boundary constraint rules and a set of abnormal scenario rules.

[0008] Step S3: Perform control flow analysis and semantic parsing on the software source code to generate a test path set covering normal paths, boundary paths, and abnormal paths; at the same time, parse the function call relationships, data dependency relationships, and inheritance relationships in the software source code to construct a code semantic knowledge graph with code entities as nodes and call relationships, dependency relationships, and inheritance relationships as edges;

[0009] Step S4: Perform multi-granular semantic association between the results obtained in step S2 and the results obtained in step S3 to generate requirement-code association information. The multi-granular semantic association includes: preliminary mapping based on word vector similarity, implicit dependency supplementation based on semantic propagation, and mapping correction based on natural language summary matching.

[0010] Step S5: Input the requirement-code association information obtained in step S4 into the template-filled constraint solver, and combine it with the data constraints extracted in step S2. The constraint solver will instantiate the natural language constraints into specific legal input data values ​​to generate test cases for normal scenarios, boundary scenarios, and abnormal scenarios.

[0011] Step S6: Execute the generated test cases, collect execution results and code branch coverage information. For uncovered code branches, locate the root cause of path blocking by comparing the differences between the code semantic knowledge graph and the dynamic execution trajectory. Based on the root cause, generate a strategy summary containing root cause analysis and targeted generation strategies, and feed the strategy summary back to step S5 to guide the test case generation model to perform iterative optimization until the preset code branch coverage threshold is reached.

[0012] Step S7: Standardize and convert the evaluated test cases according to the preset format template and output them to the target test management platform.

[0013] Preferably, the method for generating the demand semantic relationship graph in step S2 is as follows:

[0014] Semantic role labeling is performed on the required semantic units to identify predicates and their corresponding semantic arguments, and predicates are mapped to functional entities and semantic arguments are mapped to attribute information associated with the functional entities.

[0015] Simultaneously, dependency parsing is performed to extract triples. Based on the triples, the logical relationships between functional entities, the limiting relationships between functional entities and data constraints, and the triggering relationships between preconditions and functional entities are identified, and the requirement semantic relationship graph is constructed.

[0016] Preferably, the domain dictionary in step S3 is constructed as follows:

[0017] Technical documents, interface documents, and historical defect reports of the business domain to which the software to be tested belong are collected as domain corpus. The TF-IDF algorithm is used to extract high-frequency terms from the domain corpus, and the cosine similarity between the high-frequency terms and the word vectors of the terms in the general boundary vocabulary and the abnormal vocabulary is calculated.

[0018] The word vector representations of the high-frequency terms are obtained using a pre-trained word vector model. For multi-word phrases, the arithmetic mean of the word vectors of the constituent words is taken as their vector representation. The cosine similarity between the word vectors of the high-frequency terms and the word vectors of words in the preset general boundary word list and abnormal word list is calculated.

[0019] When the calculated cosine similarity is greater than or equal to the preset fourth similarity threshold, the high-frequency terms are classified into the corresponding category, and the domain dictionary is formed after manual review and confirmation.

[0020] The formula for calculating the cosine similarity of word vectors is:

[0021]

[0022] These are high-frequency terms. For entries in the general boundary vocabulary and the abnormal vocabulary, High-frequency term Word vectors, For entries in the general boundary vocabulary and the abnormal vocabulary Word vectors of 2, and The dimension is d. For vectors sum vector The dot product is calculated using the following formula: ;

[0023] and They are vectors sum vector The Euclidean norm.

[0024] Preferably, the generation of the test path set in step S3 specifically includes the following steps:

[0025] Step S301: Decompose each method in the software source code into basic blocks, and construct a control flow graph with the basic blocks as nodes and the control transfer relationship between the basic blocks as directed edges, wherein the conditional expression in the conditional jump statement is recorded as the branch condition of the corresponding directed edge.

[0026] Step S302: Enumerate paths from the method entry basic block to the method exit basic block on the control flow graph to obtain a complete set of reachable paths;

[0027] Step S303: Label the path type according to the branch conditions recorded on the directed edges traversed by each path: label the path that does not contain any abnormal branches and whose conditions all take the normal equivalence class as a normal path; label the path that contains boundary value judgment conditions and whose boundary conditions are activated as a boundary path; label the path that contains abnormal handling branches as an abnormal path.

[0028] Step S305: Extract normal paths, boundary paths, and abnormal paths from the annotation results to form the test path set.

[0029] Preferably, the preliminary mapping based on word vector similarity in step S4 specifically includes:

[0030] Step S401: Extract nouns, verbs, and noun phrases from the semantic units of demand as a keyword list;

[0031] Step S402: Perform naming style standardization on the class names and method names in the code structure information extracted in step S1, and split them into independent natural language sequences as a list of code entity names;

[0032] Step S403: Using a pre-trained word vector model, map each keyword in the list of demand keywords and each entity name in the list of code entity names to word vectors respectively; and calculate the cosine similarity between each pair of demand keywords and code entity name word vectors. When the cosine similarity is greater than or equal to a preset first similarity threshold, establish a candidate mapping relationship between the demand keyword and the code entity name.

[0033] Step S404: Based on each requirement semantic unit, select the code entity name with the highest similarity value that has a candidate relationship with it as the mapping result, and generate the requirement-code preliminary mapping table.

[0034] Preferably, the implicit dependency supplementation based on semantic propagation in step S4 specifically includes:

[0035] The code semantic knowledge graph constructed in step S3 is used as a heterogeneous graph, where nodes are code entities and edges are the calling relationships, dependency relationships or inheritance relationships between code entities.

[0036] The code entity nodes determined by the preliminary mapping based on word vector similarity are used as the initial set of activated nodes on the graph, and a feature vector is initialized for each node.

[0037] Message passing of a layered graph attention network is performed on the heterogeneous graph to update node feature representations;

[0038] For any node that is not initially activated, calculate its association score with the set of initially activated nodes. The association score is the average cosine similarity between the node's final feature vector and the final feature vectors of all nodes in the set.

[0039] When the association score of a node is greater than or equal to the preset third similarity threshold, the code entity represented by the node is determined to be an implicit dependency related to the semantics of the requirement, and it is added to the requirement-code association information to obtain the final requirement-code association information.

[0040] Preferably, the mapping correction based on natural language summary matching in step S4 specifically includes:

[0041] First, the abstract syntax tree of the software source code is traversed using the visitor pattern to extract the method name, parameter list, method call, and conditional expression for each method.

[0042] Then, the conditional expression node is recursively parsed to extract the variable names, comparison operators and comparison values ​​referenced in the conditional expression, convert the conditional expression into a natural language conditional phrase, generate a natural language description summary according to a preset template, and finally calculate the TF-IDF vector similarity between the natural language description summary and the corresponding requirement text. If the calculated similarity is lower than the second similarity threshold, it is determined to be a mismatch and removed from the requirement-code preliminary mapping table.

[0043] Preferably, in step S5, the natural language constraints are instantiated into specific legal input data values ​​using a constraint solver, specifically as follows:

[0044] Based on the data constraints extracted in step S2, the constraint type of each data constraint is identified, including numerical constraints, string constraints, and set constraints.

[0045] For numerical constraints, specific numerical values ​​are generated using equivalence class partitioning and boundary value analysis based on the constraint operators and constraint values.

[0046] For string constraints, generate specific strings based on their length and format constraints; for set constraints, generate specific sets based on their element count constraints; and then fill the corresponding input data fields of the test case template with the generated specific input values.

[0047] Fill the specific input values ​​generated above into the input data fields of the corresponding test case template.

[0048] Preferably, the specific method for locating the root cause of path blocking in step S6 is as follows:

[0049] Step S601: Extract the executed method call sequence and the basic block sequence traversed within each method from the dynamic execution trajectory to generate a dynamic execution path graph;

[0050] Step S602: Using the code semantic knowledge graph constructed in step S3 as the complete set of static reachable paths, calculate the set of differential paths in the complete set of static reachable paths that are not covered by the dynamic execution path graph;

[0051] Step S603: For each uncovered path in the set of differential paths, backtrack upstream from its starting basic block to obtain the entry condition expression that must be satisfied to enter the path;

[0052] If the variable value in the entry condition expression is always false in terms of program semantics, or if there is no reachable call chain in the control flow graph for the path, then the root cause type is determined to be logically unreachable.

[0053] If the value of the variable in the entry condition expression depends on the external environment state, and the dynamic execution trajectory shows that the external environment state was not set to a state that satisfies the entry condition expression during the test execution, then the root cause type is determined to be environment state not satisfied.

[0054] If the variable values ​​in the entry condition expression all come from the test input data generated in step S5, and the input data does not contain any combination of values ​​that would make the entry condition expression true, then the root cause type is determined to be a data constraint mapping error.

[0055] Preferably, the generation of a strategy summary in step S6 and its feedback to step S5 specifically includes:

[0056] If the root cause type is a data constraint mapping error, the generated strategy summary includes a recommended list of supplementary input data values; step S5 directly generates supplementary boundary scenario or abnormal scenario test cases based on the recommended list of supplementary input data values.

[0057] If the root cause type is "Environmental state not satisfied", the generated strategy summary includes the name of the missing environmental state variable and its expected value; step S5 adds a description of the environment preparation steps to the precondition field of the test case template based on the environmental state variable and the expected value, and generates supplementary test cases.

[0058] This invention provides an automated test case generation method based on intelligent analysis. It has the following beneficial effects:

[0059] 1. This invention significantly improves the mapping accuracy between requirement text and source code implementation by constructing a requirement semantic relationship graph and a code semantic knowledge graph, and introducing a multi-granular semantic association mechanism based on word vector similarity, implicit dependency supplementation through semantic propagation, and natural language summarization correction. Compared to simple keyword matching in existing technologies, this method can identify functional entities, data constraints, and preconditions in requirement semantic units and accurately associate them with code entities and their call chains and dependency chains. This effectively solves the mapping deviation problem caused by differences in naming styles or implicit dependencies, ensuring that the generated test cases maintain a high degree of consistency with the semantics of business requirements.

[0060] 2. By utilizing normal paths, boundary paths, and abnormal paths extracted from control flow analysis, and combining data constraints extracted from the requirement semantic relationship graph with boundary constraint rule sets and abnormal scenario rule sets expanded from the domain dictionary, a constraint solver transforms natural language constraints into specific input values ​​with equivalence class partitioning and boundary value analysis characteristics. This approach enables the generated test cases to not only cover reachable paths in the code logic but also proactively activate boundary conditions and abnormal triggering branches strongly related to business constraints, compensating for the lack of realism in business scenarios in traditional pure code analysis methods.

[0061] 3. By establishing a closed-loop iterative optimization mechanism based on execution feedback, after test execution, by comparing the difference path set between the static code semantic knowledge graph and the dynamic execution trajectory, the root cause type of uncovered branches can be determined—automatically distinguishing between three situations: logical unreachability, unmet environment state, and incorrect data constraint mapping. A strategy summary containing supplementary value lists or environment preparation steps is then generated and fed back to the test case generation stage. This mechanism endows the system with adaptive correction capabilities, enabling the test case set to continuously approach the preset coverage threshold during iteration, reducing the intervention burden of manually investigating the causes of uncovered parts. Attached Figure Description

[0062] Figure 1 This is a flowchart of the method of the present invention;

[0063] Figure 2 This is a schematic diagram illustrating the test case iteration optimization and root cause localization of the present invention;

[0064] Figure 3 This is a flowchart of the domain dictionary construction and data constraint extraction process of the present invention;

[0065] Figure 4 This is a flowchart illustrating the construction process of the requirement code information for this invention.

[0066] Figure 5 This is a flowchart of the control path set of the present invention;

[0067] Figure 6This is a flowchart of the code semantic knowledge graph of the present invention. Detailed Implementation

[0068] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0069] like Figures 1 to 6 As shown, this invention proposes an automated test case generation method based on intelligent analysis, comprising the following steps:

[0070] Step S1: Obtain the requirements document and software source code of the software to be tested. Perform text preprocessing on the requirements document to obtain the requirements semantic units composed of word sequences and their part-of-speech tags. Perform abstract syntax tree parsing on the software source code to obtain code structure information including class names, method names, parameter names and parameter types.

[0071] Specifically, the text preprocessing and code structure information parsing are as follows: First, the requirements document is segmented into sentences by period, question mark, and exclamation mark. Second, each sentence is segmented into word sequences, and the word sequences are tagged with part-of-speech tags, while stopping words in the stop word list are removed. Finally, a list of structured semantic units consisting of word sequences and their part-of-speech tags is output as the requirements semantic units.

[0072] The parsing of code structure information specifically involves: based on the programming language type of the software source code, calling the abstract syntax tree parser corresponding to that programming language type to parse the source code into an abstract syntax tree;

[0073] Traverse the abstract syntax tree to identify and extract class definition nodes, method definition nodes, and parameter list nodes; extract the class name from the class definition node, the method name from the method definition node, and the parameter name and parameter type from the parameter list node, and store the class name, method name, parameter name, and parameter type in structured data form as code structure information;

[0074] Step S2: Perform semantic role labeling and relationship extraction on the semantic units of the requirements, identify the functional entities, data constraints and preconditions in the requirement text, and generate a semantic relationship graph of the requirements with functional entities as nodes and logical relationships, limiting relationships and triggering relationships as edges;

[0075] Furthermore, by utilizing a pre-built domain dictionary, data constraints are extracted from the demand semantic relationship graph to generate a set of boundary constraint rules and a set of rules for abnormal scenarios;

[0076] The methods for generating boundary constraint rule sets and abnormal scenario rule sets are as follows:

[0077] Boundary constraint rule set: Traverse the attribute value information of each data constraint node in the requirement semantic relationship graph, extract numerical constraints, string constraints and set constraints, generate minimum value boundary, maximum value boundary and intermediate value within the interval based on the value range of numerical constraints using boundary value analysis method, generate empty string, single character, string value of one less than the length limit and string value of the length limit based on the length limit of string constraints, and generate empty set, single element set and maximum capacity set for set constraints. Store the above boundary values ​​in the form of structured rules and generate boundary constraint rule set;

[0078] Abnormal Scenario Rule Set: Based on the boundary constraint rule set, the semantics of each data constraint are expanded using abnormal condition words in the domain dictionary. Numeric constraints are expanded to exceed the limit input and null input, and string constraints are expanded to format error input, empty string input and special character input. The preconditions of functional entities are inverted to generate abnormal scenarios where the preconditions are not met. The above abnormal scenarios are stored in the form of structured rules and an abnormal scenario rule set is generated.

[0079] Step S3: Perform control flow analysis on the software source code, construct a control flow graph to extract branch conditions, and generate a test path set covering normal paths, boundary paths, and abnormal paths; at the same time, parse the function call relationships, data dependency relationships, and inheritance relationships in the software source code, and construct a code semantic knowledge graph with code entities as nodes and call relationships, dependency relationships, and inheritance relationships as edges;

[0080] Step S4: Perform multi-granular semantic association between the requirement semantic relationship graph, boundary constraint rule set, and abnormal scenario rule set obtained in step S2 and the test path set and code semantic knowledge graph obtained in step S3 to generate the final requirement-code association information;

[0081] Specifically, this includes: calculating the vector similarity between keywords in the semantic units of requirements and code entity names, and generating a preliminary requirement-code mapping table;

[0082] On the code semantic knowledge graph, starting from the code entities in the preliminary mapping table, we perform walking sampling and semantic propagation to identify and supplement implicit dependency nodes related to the semantics of the requirements.

[0083] The software source code methods and classes are traversed in a structured manner to generate a natural language description summary corresponding to the source code logic. This description summary is then matched with the semantic units of the requirements to correct the initial requirement-code mapping table and obtain the final requirement-code association information.

[0084] Step S5: Input the requirement-code association information obtained in step S4 into the template-filled test case generator. Combined with the data constraints extracted in step S2, the natural language constraints are instantiated into specific legal input data values ​​through the constraint solver. Normal scenario, boundary scenario, and abnormal scenario test cases containing test case number, preconditions, test steps, specific input data, and expected results are generated respectively.

[0085] Step S6: Execute the generated test cases, collect execution results and code branch coverage information. For uncovered code branches, locate the root cause of path blocking by comparing the differences between the code semantic knowledge graph and the dynamic execution trajectory. Based on the root cause, generate a strategy summary containing root cause analysis and targeted generation strategies, and feed the strategy summary back to Step S5 to guide the test case generation model for iterative optimization until the preset code branch coverage threshold is reached. Code branch coverage, also known as decision coverage, is a fine-grained code coverage metric. It is defined as the ratio of the number of executed code branches (i.e., directed edges in the control flow graph) to the total number of all reachable code branches during software testing.

[0086] The specific method for constructing a code semantic knowledge graph is as follows:

[0087] First, traverse the abstract syntax tree of the software source code, identify the function call expression node, extract the calling function and the callee function, and generate a triplet of "calling function - calling - callee function".

[0088] Then, the read and write operations of each function on global variables, class member variables and input parameters are analyzed, the read dependency and write dependency between functions and data entities are extracted, and "function-read dependency-variable" triples and "function-write dependency-variable" triples are generated;

[0089] Then, analyze the parent class references or interface implementation lists in the class definition nodes, extract the inheritance relationships and interface implementation relationships between classes, and generate "subclass-inheritance-parent class" triples or "class-implementation-interface" triples;

[0090] Finally, the triples are organized using a graph data structure, with code entities as nodes and call relationships, dependency relationships, and inheritance relationships as directed edges, to construct a code semantic knowledge graph.

[0091] Step S7: Standardize and convert the evaluated test cases according to the preset format template and output them to the target test management platform.

[0092] The generation of the demand semantic relationship graph in step S2 is specifically as follows:

[0093] Semantic roles are labeled for the semantic units of the requirements, and predicates and their corresponding semantic arguments are identified. Semantic arguments include the action executor, the action receiver, the time of action occurrence, and the conditions of action occurrence. Predicates are mapped to functional entities and semantic arguments are mapped to attribute information. At the same time, dependency parsing is performed to extract triples. Based on the triples, the logical relationships between functional entities, the limiting relationships between functional entities and data constraints, and the triggering relationships between preconditions and functional entities are identified, and a semantic relationship graph of the requirements is constructed.

[0094] Specifically, as an optional implementation: semantic role labeling of the demand semantic unit specifically involves: for each sentence in the demand semantic unit, identifying the predicate and its corresponding semantic argument, mapping the identified predicate to a functional entity, and mapping the semantic argument to attribute information associated with the functional entity; relation extraction of the demand semantic unit specifically involves: performing dependency parsing on the sentences in the demand semantic unit to extract subject-predicate-object triples and entity-attribute-attribute value triples;

[0095] Based on the triplet identification of the logical relationships between functional entities in the requirement text, the limiting relationships between functional entities and data constraints, and the triggering relationships between preconditions and functional entities, the requirement semantic relationship graph is output with functional entities as nodes and logical relationships, limiting relationships and triggering relationships as edges.

[0096] The domain dictionary is constructed as follows:

[0097] Technical documents, interface documents, and historical defect reports of the business domain to which the software to be tested belong are collected as domain corpus. The TF-IDF algorithm is used to extract high-frequency terms from the domain corpus, and the cosine similarity between the high-frequency terms and the word vectors of the terms in the general boundary vocabulary and the abnormal vocabulary is calculated.

[0098] The word vector representations of high-frequency terms are obtained using a pre-trained word vector model. For multi-word phrases, the arithmetic mean of the word vectors of its constituent words is taken as its vector representation. The cosine similarity between the word vectors of high-frequency terms and the word vectors of words in the pre-set general boundary word list and abnormal word list is calculated.

[0099] When the calculated cosine similarity is greater than or equal to the preset similarity threshold, high-frequency terms are classified into the corresponding categories and a domain dictionary is formed after manual review and confirmation.

[0100] The formula for calculating the cosine similarity of word vectors is:

[0101]

[0102] These are high-frequency terms. For entries in the general boundary vocabulary and the abnormal vocabulary, High-frequency term Word vectors, For entries in the general boundary vocabulary and the abnormal vocabulary The word vector of 2 has a dimension of d. For vectors sum vector The dot product is calculated using the following formula: ;

[0103] and They are vectors sum vector The Euclidean norm, The calculation formula is ; The calculation formula is ;

[0104] Multi-word phrases are calculated by taking the arithmetic mean of the word vectors they form. Where m is the number of words in the phrase. To form word vectors, This represents the total number of multi-word phrases; the matching results are entered into the database after verification by business experts. This embodiment clarifies the vectorization method, threshold setting, and manual verification mechanism to prevent the "domain dictionary" from becoming a black box.

[0105] Calculation results The value is (-1, 1), and the closer the value is to 1, the more similar the semantics are. The preset threshold can be determined experimentally: randomly select 100 pairs of synonyms and 100 pairs of antonyms from the general vocabulary, calculate the similarity respectively, and take the midpoint between the 10th percentile of the similarity of synonyms and the 90th percentile of the similarity of antonyms, for example, 0.70.

[0106] like If the similarity is greater than or equal to the similarity threshold, then it is considered a high-frequency term. and entries Semantic similarity, will Into The category to which it belongs, namely the boundary condition vocabulary category or the abnormal condition vocabulary category;

[0107] like If the similarity is less than the similarity threshold, the two words are determined to be semantically dissimilar, and the matching calculation continues with the next word in the vocabulary.

[0108] If high-frequency terms If the similarity to all terms in the vocabulary is less than the similarity threshold, then the high-frequency term is... Any category not included in this thesaurus will be subject to subsequent manual review to determine its classification or will be discarded.

[0109] The TF-IDF algorithm is specifically as follows:

[0110] word frequency ;

[0111] Inverse document frequency ;

[0112] in The number of times term 't' appears in document 'd'. It is the number of documents containing the term 't'. It represents the total number of documents in the corpus;

[0113] Top-k (k=500) terms are selected as candidates. Word vectors are generated using Word2Vec with fine-tuning of domain corpus. Cosine similarity is calculated with general boundary vocabulary (such as "greater than", "less than or equal to", "null value") and abnormal vocabulary (such as "timeout", "out of bounds", "null pointer"). Finally, the top 500 terms with this value are selected as candidate high-frequency terms.

[0114] The generation of the test path set in step S3 specifically includes the following steps:

[0115] Step S301: Decompose each method in the software source code into basic blocks, and construct a control flow graph with basic blocks as nodes and the control transfer relationship between basic blocks as directed edges. The conditional expression in the conditional jump statement is recorded as the branch condition of the corresponding directed edge.

[0116] Step S302: Enumerate the paths from the method entry block to the method exit block on the control flow graph to obtain the complete set of reachable paths;

[0117] Step S303: Label the path type according to the branch conditions recorded on the directed edges traversed by each path: label the path that does not contain any exception handling branches and whose branch conditions all take the normal equivalence class value as a normal path; label the path whose branch conditions contain boundary value judgment conditions and whose boundary conditions are activated as a boundary path; label the path that contains exception handling branches as an exception path.

[0118] Step S305: Extract normal paths, boundary paths, and abnormal paths from the annotation results to form a test path set.

[0119] Step S4, the preliminary mapping based on word vector similarity, specifically includes:

[0120] Step S401: Extract nouns, verbs and noun phrases from the semantic units of the requirements as a keyword list. Extract keywords for each semantic unit in the semantic units of the requirements, remove words that are function words, punctuation and stop words, and retain nouns, verbs and noun phrases as the keyword list of the requirements.

[0121] Step S402: Perform naming style standardization on the class names and method names in the code structure information extracted in step S1, and split them into independent natural language sequences as a list of code entity names;

[0122] Specifically, the naming style standardization process includes: detecting uppercase letter boundaries in code entity names, splitting camelCase identifiers into single-letter sequences, converting all split word sequences to lowercase, and matching them with general English lexicons and domain lexicons. If the split words are abbreviations or proper nouns, they are retained in their original form or replaced with their full names. For identifiers named with underscores, word sequences are split using underscores as delimiters.

[0123] Step S403: Using a pre-trained word vector model, map each keyword in the demand keyword list and each entity name in the code entity name list to a word vector; and calculate the cosine similarity between each pair of demand keyword and code entity name word vectors. When the cosine similarity is greater than or equal to the preset first similarity threshold, establish a candidate mapping relationship between the demand keyword and the code entity name.

[0124] Step S404: Based on each requirement semantic unit, select the code entity name with the highest similarity value that has a candidate relationship with it as the mapping result, and generate a preliminary requirement-code mapping table.

[0125] The mapping correction based on natural language summary matching in step S4 is as follows: First, the abstract syntax tree of the software source code is traversed through the visitor pattern, and the method name, parameter list, method call and condition expression are extracted for each method.

[0126] Then, the conditional expression node is recursively parsed to extract the variable names, comparison operators and comparison values ​​referenced in the conditional expression, convert the conditional expression into a natural language conditional phrase, generate a natural language description summary according to a preset template, and finally calculate the TF-IDF vector similarity between the natural language description summary and the corresponding requirement text. If the calculated similarity is lower than the second similarity threshold, it is determined to be a mismatch and removed from the requirement-code preliminary mapping table.

[0127] The conditional expression node is recursively parsed to extract the variable names, comparison operators and comparison values ​​referenced in the conditional expression, and the conditional expression is converted into a natural language conditional phrase, such as converting "phone == null" into "phone number parameter is empty";

[0128] The extracted structured information is filled in according to the preset summary template. The summary template includes: a method function description section generated based on the method name and the business semantics of the class; a parameter description section generated based on the formal parameter list and its type; an internal call description section generated based on the method call expression node list; and a conditional branch description section generated based on natural language conditional phrases.

[0129] The method function description section is generated based on the method name and the business semantics of the class, and is formatted as "This method is used for [business action]"; the parameter description section is formatted as "This method receives [parameter type] [parameter name] as input parameters"; the internal call description section is formatted as "This method calls [list of sub-methods] in sequence"; and the conditional branch description section is formatted as "When [condition phrase] is used, [branch action description] is executed".

[0130] The code semantic knowledge graph constructed in step S3 is used as a heterogeneous graph, where nodes are code entities and edges are the calling relationships, dependency relationships or inheritance relationships between code entities.

[0131] The code entity nodes determined by the initial mapping based on word vector similarity are used as the initial set of activated nodes on the graph, and a feature vector is initialized for each node.

[0132] Perform message passing in a layered graph attention network on a heterogeneous graph to update node feature representations;

[0133] For any node that is not initially activated, calculate its association score with the set of initially activated nodes. The association score is the average cosine similarity between the node's final feature vector and the final feature vectors of all nodes in the set.

[0134] When the association score of a node is greater than or equal to the preset third similarity threshold, the code entity represented by the node is determined to be an implicit dependency related to the semantics of the requirement, and it is added to the requirement-code association information.

[0135] In step S5, the natural language constraints are instantiated into specific legal input data values ​​using the constraint solver, specifically as follows:

[0136] Based on the data constraints extracted in step S2, identify the constraint type of each data constraint. The constraint types include numerical constraints, string constraints, and set constraints.

[0137] For numerical constraints, specific values ​​are generated using equivalence class partitioning and boundary value analysis based on the constraint operator and constraint value: if the constraint is "equal to X", then X, X-1, and X+1 are generated as test input values; if the constraint is "greater than or equal to X and less than or equal to Y", then X, Y, (X+Y) / 2, X-1, and Y+1 are generated as test input values.

[0138] For string constraints, specific strings are generated based on their length and format constraints: if the constraint is "length equal to L", then a valid string of length L, a string of length L-1, and a string of length L+1 are generated as test input values; if the constraint is "pure numbers", then a pure number string and a string containing letters are generated as valid and invalid inputs, respectively.

[0139] For set-type constraints, a specific set is generated based on the number of elements: if the constraint is "at least N elements", a set containing N elements and a set containing N-1 elements are generated as valid boundary inputs and invalid boundary inputs, respectively; and the generated specific input values ​​are filled into the input data fields of the corresponding test case template.

[0140] Fill the specific input values ​​generated above into the input data fields of the corresponding test case template.

[0141] In step S6, the root cause of the path blockage is located using the following method:

[0142] Step S601: Extract the executed method call sequence and the sequence of basic blocks traversed within each method from the dynamic execution trajectory to generate a dynamic execution path graph;

[0143] Step S602: Using the code semantic knowledge graph constructed in step S3 as the complete set of static reachable paths, calculate the set of differential paths in the complete set of static reachable paths that are not covered by the dynamic execution path graph;

[0144] The specific calculation is as follows: For each static path in the complete set of static reachable paths, it is represented as an ordered sequence of basic block addresses; for each dynamic execution path in the dynamic execution path graph, it is also represented as an ordered sequence of basic block addresses; a normalized signature is constructed for each static path. The normalized signature is a subsequence generated by retaining the key basic blocks in the path that represent the control flow branch decisions; a key basic block refers to a basic block in the control flow graph that has multiple successor nodes.

[0145] Traverse each static path in the complete set of static reachable paths, calculate its normalized signature, and search for it in the hash set; if the search fails, that is, there is no normalized signature of any dynamic execution path that is the same as the normalized signature of the static path, then mark the static path as uncovered and add it to the set of differential paths;

[0146] Step S603: For each uncovered path in the set of different paths, backtrack upstream from its starting basic block to obtain the entry condition expression that must be satisfied to enter the path;

[0147] If the variable in the entry condition expression is always false in terms of program semantics, or if there is no reachable call chain in the control flow graph for the path, then the root cause type is determined to be logically unreachable.

[0148] If the value of the variable in the entry condition expression depends on the external environment state, and the dynamic execution trajectory shows that the external environment state was not set to a state that satisfies the entry condition expression during the test execution, then the root cause type is determined to be environment state not satisfied.

[0149] If the variable values ​​in the entry condition expression all come from the test input data generated in step S5, and the input data does not contain any combination of values ​​that would make the entry condition expression true, then the root cause type is determined to be a data constraint mapping error.

[0150] "Always false in program semantics" means that a certain conditional expression can never be true, as determined by static analysis (such as constant propagation and value range analysis). "External environment status" includes system time, file status, database connection status, environment variables, etc. "Data constraint mapping error" means that the test data generated in step S5 fails to cover the specific combination of values ​​that makes the branch condition true, and needs to be corrected by feeding back to the constraint rule set in step S2 or the constraint solving logic in step S5.

[0151] Step S6 generates a policy summary and feeds it back to step S5, specifically including:

[0152] If the root cause type is a data constraint mapping error, the generated strategy summary includes a recommended list of supplementary input data values; step S5 directly generates supplementary boundary scenario or abnormal scenario test cases based on the recommended list of supplementary input data values.

[0153] If the root cause type is "Environmental state not satisfied", the generated strategy summary includes the name of the missing environment state variable and its expected value; step S5 adds a description of the environment preparation steps to the precondition field of the test case template based on the environment state variable and the expected value, and generates supplementary test cases.

[0154] Based on the above, the methods for establishing the first similarity threshold to the fourth similarity threshold are as follows:

[0155] The determination of the first similarity threshold follows the principle of combining supervised threshold optimization with business experience, and is used to determine whether the cosine similarity between the word vector of the requirement keyword and the word vector of the code entity name is sufficient to establish a candidate mapping relationship.

[0156] The second similarity threshold is set based on engineering considerations of mismatch tolerance. Its value is usually lower than the first similarity threshold. It is used to determine whether the TF-IDF vector similarity between the natural language description summary generated from the code and the corresponding requirement text is too low, so as to identify and remove mismatch items in the preliminary mapping table.

[0157] The third similarity threshold is set based on a validation set tuning method using semi-supervised learning. It is used to determine whether the average cosine similarity (association score) between the final feature vector of an inactive node and the initial set of activated nodes is high enough after propagation in the graph attention network to identify it as an implicit dependency.

[0158] In summary, this invention effectively bridges the semantic gap between requirement text and code entities by constructing a requirement semantic relationship graph and a code semantic knowledge graph, and introducing a multi-granularity association mechanism that includes initial mapping based on word vector similarity, semantic propagation via graph attention networks, and natural language summarization correction. This ensures that functional entities, data constraints, and preconditions are accurately anchored to code implementation nodes and their implicit dependency links. At the test generation level, control flow analysis is used to extract normal, boundary, and abnormal paths. Combined with a constraint rule set enhanced by a domain dictionary, a constraint solver instantiates natural language constraints into input values ​​with equivalence class partitioning and boundary value analysis characteristics. This allows test cases to proactively activate boundary thresholds and abnormal branches strongly correlated with business rules. Furthermore, this invention establishes a root cause localization mechanism that compares the differences between static knowledge graphs and dynamic execution trajectories. It automatically identifies the blocking type of uncovered branches and generates strategy summaries for iterative optimization, giving the system adaptive correction capabilities and driving the test case set to continuously approach the preset coverage threshold.

[0159] The threshold is set to facilitate comparison. The size of the threshold depends on the amount of sample data and the number of bases set by those skilled in the art for each set of sample data; as long as it does not affect the ratio between the parameter and the quantized value, it is acceptable.

[0160] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0161] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for generating automated test cases based on intelligent analysis, characterized in that, Includes the following steps: Step S1: Obtain the requirements document and software source code of the software to be tested; perform text preprocessing on the requirements document to obtain requirements semantic units; perform abstract syntax tree parsing on the software source code to obtain code structure information; Step S2: Perform semantic role labeling and relationship extraction on the required semantic units to construct a required semantic relationship graph with functional entities as nodes and logical relationships, limiting relationships and triggering relationships as edges; and use a pre-built domain dictionary to extract data constraints from the required semantic relationship graph to generate a set of boundary constraint rules and a set of abnormal scenario rules. Step S3: Perform control flow analysis and semantic parsing on the software source code to generate a test path set covering normal paths, boundary paths, and abnormal paths; at the same time, parse the function call relationships, data dependency relationships, and inheritance relationships in the software source code to construct a code semantic knowledge graph with code entities as nodes and call relationships, dependency relationships, and inheritance relationships as edges; Step S4: Perform multi-granular semantic association between the results obtained in step S2 and the results obtained in step S3 to generate requirement-code association information. The multi-granular semantic association includes: preliminary mapping based on word vector similarity, implicit dependency supplementation based on semantic propagation, and mapping correction based on natural language summary matching. Step S5: Input the requirement-code association information obtained in step S4 into the template-filled constraint solver, and combine it with the data constraints extracted in step S2. The constraint solver will instantiate the natural language constraints into specific legal input data values ​​to generate test cases for normal scenarios, boundary scenarios, and abnormal scenarios. Step S6: Execute the generated test cases, collect execution results and code branch coverage information. For uncovered code branches, locate the root cause of path blocking by comparing the differences between the code semantic knowledge graph and the dynamic execution trajectory. Based on the root cause, generate a strategy summary containing root cause analysis and targeted generation strategies, and feed the strategy summary back to step S5 to guide the test case generation model to perform iterative optimization until the preset code branch coverage threshold is reached. Step S7: Standardize and convert the evaluated test cases according to the preset format template and output them to the target test management platform.

2. The automated test case generation method based on intelligent analysis according to claim 1, characterized in that, The specific method for generating the demand semantic relationship graph in step S2 is as follows: Semantic role labeling is performed on the required semantic units to identify predicates and their corresponding semantic arguments, and predicates are mapped to functional entities and semantic arguments are mapped to attribute information associated with the functional entities. Simultaneously, dependency parsing is performed to extract triples. Based on the triples, the logical relationships between functional entities, the limiting relationships between functional entities and data constraints, and the triggering relationships between preconditions and functional entities are identified, and the requirement semantic relationship graph is constructed.

3. The automated test case generation method based on intelligent analysis according to claim 2, characterized in that, The domain dictionary in step S3 is constructed as follows: Technical documents, interface documents, and historical defect reports of the business domain to which the software to be tested belong are collected as domain corpus. The TF-IDF algorithm is used to extract high-frequency terms from the domain corpus, and the cosine similarity between the high-frequency terms and the word vectors of the terms in the general boundary vocabulary and the abnormal vocabulary is calculated. The word vector representations of the high-frequency terms are obtained using a pre-trained word vector model. For multi-word phrases, the arithmetic mean of the word vectors of the constituent words is taken as their vector representation. Calculate the cosine similarity between the word vectors of the high-frequency terms and the word vectors of terms in the preset general boundary vocabulary and abnormal vocabulary; When the calculated cosine similarity is greater than or equal to the preset fourth similarity threshold, the high-frequency terms are classified into the corresponding category, and the domain dictionary is formed after manual review and confirmation. The formula for calculating the cosine similarity of word vectors is: ； These are high-frequency terms. For entries in the general boundary vocabulary and the abnormal vocabulary, High-frequency term Word vectors, For entries in the general boundary vocabulary and the abnormal vocabulary Word vectors of 2, and The dimension is d. For vectors sum vector The dot product is calculated using the following formula: ; and They are vectors sum vector The Euclidean norm.

4. The automated test case generation method based on intelligent analysis according to claim 3, characterized in that, The generation of the test path set in step S3 specifically includes the following steps: Step S301: Decompose each method in the software source code into basic blocks, and construct a control flow graph with the basic blocks as nodes and the control transfer relationship between the basic blocks as directed edges, wherein the conditional expression in the conditional jump statement is recorded as the branch condition of the corresponding directed edge. Step S302: Enumerate paths from the method entry basic block to the method exit basic block on the control flow graph to obtain a complete set of reachable paths; Step S303: Label the path type according to the branch conditions recorded on the directed edges traversed by each path: label the path that does not contain any abnormal branches and whose conditions all take the normal equivalence class as a normal path; label the path that contains boundary value judgment conditions and whose boundary conditions are activated as a boundary path; label the path that contains abnormal handling branches as an abnormal path. Step S305: Extract normal paths, boundary paths, and abnormal paths from the annotation results to form the test path set.

5. The automated test case generation method based on intelligent analysis according to claim 4, characterized in that, The preliminary mapping based on word vector similarity in step S4 is specifically as follows: Step S401: Extract nouns, verbs, and noun phrases from the semantic units of demand as a keyword list; Step S402: Perform naming style standardization on the class names and method names in the code structure information extracted in step S1, and split them into independent natural language sequences as a list of code entity names; Step S403: Using a pre-trained word vector model, map each keyword in the list of demand keywords and each entity name in the list of code entity names to word vectors respectively; and calculate the cosine similarity between each pair of demand keywords and code entity name word vectors. When the cosine similarity is greater than or equal to a preset first similarity threshold, establish a candidate mapping relationship between the demand keyword and the code entity name. Step S404: Based on each requirement semantic unit, select the code entity name with the highest similarity value that has a candidate relationship with it as the mapping result, and generate the requirement-code preliminary mapping table.

6. The automated test case generation method based on intelligent analysis according to claim 5, characterized in that, The implicit dependency supplementation based on semantic propagation in step S4 specifically includes: The code semantic knowledge graph constructed in step S3 is used as a heterogeneous graph, where nodes are code entities and edges are the calling relationships, dependency relationships or inheritance relationships between code entities. The code entity nodes determined by the preliminary mapping based on word vector similarity are used as the initial set of activated nodes on the graph, and a feature vector is initialized for each node. Message passing of a layered graph attention network is performed on the heterogeneous graph to update node feature representations; For any node that is not initially activated, calculate its association score with the set of initially activated nodes. The association score is the average cosine similarity between the node's final feature vector and the final feature vectors of all nodes in the set. When the association score of a node is greater than or equal to the preset third similarity threshold, the code entity represented by the node is determined to be an implicit dependency related to the semantics of the requirement, and it is added to the requirement-code association information to obtain the final requirement-code association information.

7. The automated test case generation method based on intelligent analysis according to claim 6, characterized in that, The mapping correction based on natural language summary matching in step S4 specifically involves: First, the abstract syntax tree of the software source code is traversed using the visitor pattern to extract the method name, parameter list, method call, and conditional expression for each method. Then, the conditional expression node is recursively parsed to extract the variable names, comparison operators and comparison values ​​referenced in the conditional expression, convert the conditional expression into a natural language conditional phrase, generate a natural language description summary according to a preset template, and finally calculate the TF-IDF vector similarity between the natural language description summary and the corresponding requirement text. If the calculated similarity is lower than the second similarity threshold, it is determined to be a mismatch and removed from the requirement-code preliminary mapping table.

8. The automated test case generation method based on intelligent analysis according to claim 7, characterized in that, In step S5, the natural language constraints are instantiated into specific legal input data values ​​using the constraint solver, specifically as follows: Based on the data constraints extracted in step S2, the constraint type of each data constraint is identified, including numerical constraints, string constraints, and set constraints. For numerical constraints, specific numerical values ​​are generated using equivalence class partitioning and boundary value analysis based on the constraint operators and constraint values. For string constraints, generate specific strings based on their length and format constraints; for set constraints, generate specific sets based on their element count constraints; and then fill the corresponding input data fields of the test case template with the generated specific input values. Fill the specific input values ​​generated above into the input data fields of the corresponding test case template.

9. The automated test case generation method based on intelligent analysis according to claim 8, characterized in that, The specific method for locating the root cause of the path blockage in step S6 is as follows: Step S601: Extract the executed method call sequence and the basic block sequence traversed within each method from the dynamic execution trajectory to generate a dynamic execution path graph; Step S602: Using the code semantic knowledge graph constructed in step S3 as the complete set of static reachable paths, calculate the set of differential paths in the complete set of static reachable paths that are not covered by the dynamic execution path graph; Step S603: For each uncovered path in the set of differential paths, backtrack upstream from its starting basic block to obtain the entry condition expression that must be satisfied to enter the path; If the variable value in the entry condition expression is always false in terms of program semantics, or if there is no reachable call chain in the control flow graph for the path, then the root cause type is determined to be logically unreachable. If the value of the variable in the entry condition expression depends on the external environment state, and the dynamic execution trajectory shows that the external environment state was not set to a state that satisfies the entry condition expression during the test execution, then the root cause type is determined to be that the environment state is not satisfied. If the variable values ​​in the entry condition expression all come from the test input data generated in step S5, and the input data does not contain any combination of values ​​that would make the entry condition expression true, then the root cause type is determined to be a data constraint mapping error.

10. The automated test case generation method based on intelligent analysis according to claim 9, characterized in that, The generation of a policy summary in step S6 and its feedback to step S5 specifically includes: If the root cause type is a data constraint mapping error, the generated strategy summary includes a recommended list of supplementary input data values; step S5 directly generates supplementary boundary scenario or abnormal scenario test cases based on the recommended list of supplementary input data values. If the root cause type is "Environmental state not satisfied", the generated strategy summary includes the name of the missing environmental state variable and its expected value; step S5 adds a description of the environment preparation steps to the precondition field of the test case template according to the environmental state variable and the expected value, and generates supplementary test cases.

Images