An AI model-based software test case adaptive generation method and system

Abstract

This invention relates to the field of software testing technology and discloses an adaptive software test case generation method and system based on an AI model. The method includes: performing requirement semantic parsing and structured representation; performing code analysis and multi-dimensional feature extraction; calculating semantic similarity and graph alignment based on requirement semantic graphs and code semantic feature graphs; acquiring historical test case data and performing entity linking and association analysis based on requirement-code mapping relationships; identifying test scenarios and prioritizing them; generating test cases; performing quality assessment on the test case set, removing redundant test cases and supplementing missing test cases; evaluating the execution effect of test cases from multiple dimensions and continuously optimizing them. This invention effectively solves the problem of the separation between requirement and code analysis in traditional methods by establishing an intelligent mapping mechanism between requirements, code, and test cases.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and more specifically, to a method and system for adaptive generation of software test cases based on an AI model. Background Technology

[0002] With the increasing complexity of software systems and the widespread application of agile development models, especially the popularization of microservice architecture, software testing faces unprecedented challenges. In a distributed microservice environment, a complete business process often spans multiple service nodes, with services interacting in complex ways through RESTful APIs, message queues, and other methods. The failure of any one service can trigger a cascading effect. Traditional manual test case writing is not only time-consuming and labor-intensive, but also struggles to effectively cover various interaction scenarios between services, particularly testing fault tolerance mechanisms such as service degradation, circuit breaking, and retries under abnormal conditions. In the context of rapid requirement iteration, testing teams need to generate a large number of test cases covering new features and regression testing of existing features in a short period. Traditional methods can no longer meet the demands of rapid delivery, making testing a key bottleneck restricting software delivery speed.

[0003] Existing methods for automatically generating test cases suffer from the following technical problems: First, there's the disconnect between semantic understanding of requirements and code structure analysis. Existing technologies either rely solely on semantic analysis based on requirement documents, resulting in test cases that lack coverage of the actual execution path of the code, or they rely solely on path analysis based on code structure, potentially leading to test cases that deviate from actual business requirements and fail to establish an effective traceability relationship between requirements and code. Second, there's the issue of structured representation and reuse of test knowledge. While the software testing field has accumulated rich testing experience and knowledge, much of this knowledge exists in unstructured form, making it difficult for AI models to effectively utilize, resulting in a lack of historical experience to guide test case generation. Third, test case generation lacks an adaptive optimization mechanism. Existing methods mostly employ static generation strategies, failing to dynamically adjust based on test execution feedback, leading to high redundancy and insufficient defect detection capabilities in the generated test cases. Summary of the Invention

[0004] This invention provides a method and system for adaptive generation of software test cases based on an AI model, which solves the technical problems of low efficiency, difficulty in adapting to rapid iterative development pace, and difficulty in ensuring test coverage and quality in related technologies.

[0005] This invention provides an adaptive method for generating software test cases based on an AI model, comprising the following steps: Obtain the original requirements document, perform semantic parsing and structured representation of the requirements, and obtain the requirements semantic graph; Obtain the software source code, perform code analysis and multi-dimensional feature extraction to obtain a code semantic feature map; Semantic similarity calculation and graph alignment are performed based on the requirement semantic graph and code semantic feature graph to obtain the requirement-code mapping relationship; historical test case data is obtained, and entity linking and association analysis are performed in combination with the requirement-code mapping relationship to obtain the test knowledge graph; Based on the test knowledge graph, test scenarios are identified and prioritized to obtain a test scenario priority list. Based on the test scenario priority list and test knowledge graph, test cases are generated to obtain a test case set. The test case set is evaluated for quality, redundant test cases are removed and missing test cases are added to obtain an optimized test case set; Based on the optimized test case set, the performance of test cases is evaluated from multiple dimensions and continuously optimized to obtain an updated test case generation strategy.

[0006] In a preferred embodiment, the step of performing demand semantic parsing and structured representation includes: Perform format checks on the original requirements document, identify the document type, call the corresponding text extraction tool, extract the plain text content in the document, and remove non-requirement description content; A bidirectional transformer model is used to perform deep semantic encoding on the requirement sentence, and a self-attention mechanism is used to capture the semantic dependencies between words in the sentence to obtain the semantic vector of the requirement sentence. A named entity recognition model is used to identify business entities and their type tags in the requirements. Entity types include functional modules, business objects, operation actions, data attributes, and constraints. A relation extraction model is used to obtain semantic relation triples between entities. The relation types include call relations, data flow relations, constraint relations, and dependency relations. Each demand entity is treated as a node in the graph, and relation triples are transformed into directed edges in the graph to construct a demand semantic graph.

[0007] In a preferred embodiment, the code analysis and multidimensional feature extraction include: Obtain the software source code, select the appropriate parser tool for different programming languages, input the code file into the parser, and build an abstract syntax tree; For each function in the abstract syntax tree, analyze the execution order of statements and control transfer within the function body to obtain a control flow graph; Traverse the nodes of the control flow graph, identify the definition and usage of variables in each node, use reach-definition analysis to establish the mapping relationship from definition to usage, and construct a data dependency graph of variables; Scan the function call statements in the code, identify the names of the called functions and the call locations, and build a call relationship graph between services; By merging and integrating the control flow graph, data dependency graph, and call relationship graph, a unified code semantic feature graph is obtained.

[0008] In a preferred embodiment, the step of obtaining the test knowledge graph includes: The requirement entities and code elements are encoded using a pre-trained language model, cosine similarity is calculated, and a graph alignment algorithm is used to obtain the requirement code mapping relationship. Extract historical test cases, parse the text to obtain a structured test case representation, and establish links between test cases and requirement nodes and code nodes; By integrating requirement nodes, code nodes, test case nodes, and defect nodes into the same graph structure, a test knowledge graph is obtained.

[0009] In a preferred embodiment, the step of obtaining the test scenario priority list includes: Using the requirement node corresponding to the target requirement as the seed node, multi-hop neighbor expansion is performed in the test knowledge graph to obtain the task-related subgraph. The task-related subgraph is input into the graph neural network model. Through multiple graph convolutional layers or graph attention layers, the nodes update their own feature representation by aggregating the features of their neighbors, resulting in a set of node embedding vectors. Filter the nodes related to the test in the task-related subgraph, extract the embedding vectors of these nodes, and use a clustering algorithm to group the nodes, with each cluster representing a test scenario; For each test scenario, the number of historical defects associated with code nodes within the scenario is counted, the complexity index of the code involved in the scenario is calculated, a risk scoring model is established, and the test scenarios are sorted in descending order according to the risk score.

[0010] In a preferred embodiment, generating test cases includes: Extract the node embedding vectors of the test scene and aggregate them to obtain a set of scene feature vectors; Select an appropriate test template, fill in the scenario requirement description, and form a test case framework set; The set of scene feature vectors is used as input to the sequence-to-sequence model, and a set of test step sequences is generated using a constraint decoding strategy. Parameter constraints are obtained from the code semantic feature map, and a test data set is generated using a constraint solver. The application of business rules inference and prediction system outputs the expected result set; Transform test steps, test data, and expected results into a set of executable test cases.

[0011] In a preferred embodiment, the step of obtaining the optimized test case set includes: Configure the test execution environment, execute the test case set in batches, collect coverage information through code instrumentation, and build a coverage matrix. Count the number of code units exclusively covered by each test case, calculate the importance weight of the code units covered by the test case, and obtain a set of contribution scores. Calculate the coverage similarity between test cases, compare the coverage contribution and execution time of test case pairs, and filter them to obtain a simplified set of test cases; Analyze the coverage matrix to identify lines of code and branches not covered by any test cases, perform path condition analysis on the uncovered code branches, and generate a supplementary set of test cases. The supplementary test case set is added to the simplified test case set to obtain the optimized test case set.

[0012] In a preferred embodiment, the step of obtaining the updated test case generation strategy includes: Collect data during test execution, calculate the performance score for each test case, aggregate the performance scores of the test cases to the test scenario level, and generate a test performance evaluation report. The test case generation process is modeled as a Markov decision process, a policy network is constructed, the policy network is trained, and a policy optimization model is obtained. Collect test execution data from historical projects, construct an offline dataset, and use an offline reinforcement learning algorithm to learn policies from the offline data to obtain a pre-trained policy model; The actions output by the strategy optimization model are mapped to the test case generation model, and the test case generation model is retrained using new test feedback data to obtain an updated test case generation model. Establish a real-time collection pipeline for test feedback data, use incremental learning algorithms to update the model, and obtain an updated test case generation strategy.

[0013] In a preferred embodiment, the step of performing demand semantic parsing and structured representation further includes: Semantic role labeling and rule template matching are used to identify semantic phrases, extract entities and numerical ranges from constraints, and represent constraints as structured expressions containing constraint variables, operators and constraint values. Perform topological sorting and hierarchical partitioning on the demand semantic graph, assign a unique identifier to each node in the graph, and establish a node index.

[0014] In a preferred embodiment, an AI model-based adaptive software test case generation system is used to execute the above-described AI model-based adaptive software test case generation method, comprising: The requirements parsing module is used to obtain the original requirements document, perform requirements semantic parsing and structured representation, and obtain the requirements semantic graph. The code analysis module is used to acquire software source code, perform code analysis and multi-dimensional feature extraction, and obtain a code semantic feature map. The knowledge graph construction module performs semantic similarity calculation and graph alignment based on the requirement semantic graph and the code semantic feature graph to obtain the requirement-code mapping relationship; it acquires historical test case data and performs entity linking and association analysis in combination with the requirement-code mapping relationship to obtain the test knowledge graph; The scene recognition module, based on the test knowledge graph, identifies test scenes and prioritizes them to obtain a test scene priority list. The test case generation module generates test cases based on the test scenario priority list and the test knowledge graph, resulting in a test case set. The test case optimization module is used to perform quality assessment on the test case set, remove redundant test cases and add missing test cases to obtain an optimized test case set; The strategy update module evaluates the performance of test cases from multiple dimensions and continuously optimizes them based on the optimized test case set, resulting in an updated test case generation strategy.

[0015] The beneficial effects of this invention are as follows: This invention establishes an intelligent mapping mechanism between requirements, code, and test cases by integrating semantic understanding of requirements, code feature extraction, test knowledge graph construction, and reinforcement learning optimization. This effectively solves the problem of the separation between requirements and code analysis in traditional methods. The test knowledge graph enables structured representation and reuse of knowledge in the testing domain, overcoming the limitations of relying on human experience and fixed rules. Employing an end-to-end deep learning architecture, it can automatically learn test case writing patterns and quality characteristics from historical test data, avoiding complex feature engineering work. For the characteristics of microservice architectures, an end-to-end test case assembly method across service call chains is designed, capable of generating integration test cases covering the entire business process, improving test coverage capabilities for distributed systems.

[0016] The adaptive optimization mechanism introduced in this invention enables the system to continuously improve its test case generation strategy based on actual test results, forming a closed-loop optimization process for test case generation. Through reinforcement learning technology, the system can learn from test execution feedback, dynamically adjusting test scenario priorities and test case generation strategies to achieve precise allocation of test resources. Differentiated generation strategies for various test scenarios generate customized test cases for different types of testing, such as functional testing, boundary testing, and exception testing, improving the relevance and effectiveness of test cases. The system's modular architecture design offers excellent scalability and maintainability, supports multiple programming languages ​​and testing frameworks, and can be seamlessly integrated into existing software development processes, reducing test case writing time and maintenance costs, and accelerating the software product delivery cycle. Attached Figure Description

[0017] Figure 1 This is the main flowchart of an AI model-based adaptive generation method for software test cases in this invention; Figure 2 This is a detailed flowchart of an AI model-based adaptive generation method for software test cases in this invention. Figure 3 This is a module diagram of an AI-based adaptive software test case generation system in this invention. Detailed Implementation

[0018] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, some features described in the examples may be combined in other examples.

[0019] At least one embodiment of the present invention discloses an adaptive method for generating software test cases based on an AI model, such as... Figures 1 to 2 As shown, it includes the following steps: Step 1: Obtain the original requirements document, perform requirements semantic parsing and structured representation, and obtain the requirements semantic graph; Step 1.1, Requirements document preprocessing and text standardization; Based on the original requirements document input, text cleaning and format conversion techniques are employed to obtain a unified format requirements document. Specifically, the original requirements document undergoes format detection to identify whether it is in Word, PDF, or Markdown format. For different formats, appropriate text extraction tools are used to extract the plain text content from the document, removing non-requirement description content such as headers, footers, and image descriptions. The extracted text is then encoded and converted to UTF-8 encoding. The document's chapter structure is identified and preserved, dividing the requirements document into different chapters such as functional requirements, non-functional requirements, and business rules. Within each chapter, the text is segmented into sentences, using punctuation and semantic integrity as segmentation criteria to break long paragraphs into independent requirement description sentences. The sentences undergo standardization processing, including removing redundant spaces and unifying punctuation, resulting in a cleaned sequence of requirement sentences.

[0020] Step 1.2, deep semantic encoding of the requirement text; Based on the cleaned sequence of requirement sentences output in step 1.1, a pre-trained language model, such as the Bidirectional Encoder Representations from Transformers (BERT), is used to obtain the vector representation of the requirement text. Specifically, the requirement sentences are input into the BERT model, which consists of multiple layers of Transformer encoders and uses a self-attention mechanism to capture the semantic dependencies between words in the sentence. For the input sentence, word segmentation is performed, dividing the sentence into a sequence of words or sub-words. A positional encoding is assigned to each word to represent its positional information in the sentence. The word embedding and positional encoding are added together and used as the input to the Transformer encoder. The encoder uses a multi-head self-attention mechanism to calculate the association weights between each word and other words in the sentence, capturing long-distance semantic dependencies. After stacking multiple layers of encoders, each word obtains a deep semantic representation that incorporates contextual information. The vectors of specially marked positions in the sentence are extracted as the semantic representation of the entire sentence, resulting in the semantic vector of the requirement sentence.

[0021] Step 1.3, Requirement entity identification and type classification; Based on the semantic vector of the requirement sentence output in step 1.2, a named entity recognition model is used to obtain the business entities and their type labels in the requirement. Specifically, the word-level semantic vector of the requirement sentence is input into a sequence labeling model composed of a conditional random field or a bidirectional long short-term memory network. The sequence labeling model predicts the entity label for each word, using the BIO labeling system, where B represents the start of an entity, I represents the interior of an entity, and O represents a non-entity. Entity types include functional modules, business objects, operations, data attributes, constraints, etc. For example, in the requirement sentence "Users query their account balance through account services," "users" is identified as a business object, "account services" as a functional module, "query" as an operation, and "account balance" as a data attribute. By learning from a large amount of labeled data, the model can identify key entities in the requirement document. The identified entities are categorized by type, and an entity list is constructed. Each entity contains entity text, entity type, and position information in the original sentence. The resulting entity list is the core component of the requirement, laying the foundation for constructing the requirement semantic graph.

[0022] Step 1.4, Extraction of Requirement Relationships and Construction of Triples; Based on the semantic vector of the requirement sentence output in step 1.2 and the identified entities in the entity list output in step 1.3, a relation extraction model is used to obtain semantic relation triples between entities. Specifically, for each pair of entities in the sentence, the semantic vectors of the two entities and their context vectors are concatenated to form a feature representation of the relation candidate. This feature representation is input into a relation classification model, which uses a multi-layer neural network to predict the semantic relationship between the two entities. Relationship types include call relationships, data flow relationships, constraint relationships, and dependency relationships. For example, there is a provide relationship between "account service" and "query," and an operation object relationship between "query" and "account balance." For entity pairs with a prediction confidence higher than a set threshold, a relation connection is established to form a triple structure, which includes a head entity, a relation type, and a tail entity. All triples are organized into a set to obtain the relational knowledge of the requirement. These triples describe the semantic connections between the elements in the requirement, providing structured support for understanding the business logic of the requirement.

[0023] Step 1.5, Extraction and formal representation of requirement constraints; Based on the semantic vector of the requirement sentence output in step 1.2 and the entity relationships identified in the semantic relationship triples between entities obtained in step 1.4, semantic role labeling and rule template matching are used to obtain the constraint expression of the requirement. Specifically, semantic role labeling is performed on the requirement sentence to identify semantic roles such as agent, patient, instrument, and condition. Attention is paid to phrases representing conditions, restrictions, and scope, such as "when," "if," and "must be satisfied." The entities and numerical ranges involved in these conditional phrases are extracted. For example, for the constraint "account balance is greater than transaction amount," the constraint object "account balance," the comparison operator "greater than," and the constraint value "transaction amount" are extracted. The constraint is represented as a structured expression, which includes constraint variables, operators, and constraint values. For complex combined constraints, logical connectives such as "and" and "or" are identified to construct logical combination relationships of constraints. All constraints are organized into a constraint set, with each constraint associated with a corresponding requirement entity or relationship. The obtained constraints describe the limitations and boundaries that the requirement must satisfy, providing a basis for generating boundary test cases and exception test cases.

[0024] Step 1.6: Construction of the demand semantic graph and generation of structured representation; Based on requirement entities, relation triples, and constraints, a graph construction algorithm is used to obtain a requirement semantic graph. Specifically, each requirement entity is treated as a node in the graph, containing the entity's text, type, and attribute information. Relation triples are transformed into directed edges in the graph, pointing from the head entity to the tail entity, with the relation type labeled on the edges. Constraints are appended to relevant nodes as attributes or special types of edges. For entity references across sentences, the occurrence of the same entity in different sentences is identified using a referencing resolution technique, merging them into a single node. The requirement semantic graph is topologically sorted and hierarchically partitioned to identify the main and auxiliary functional points of the requirement. A unique identifier is assigned to each node in the graph, and a node index is established to facilitate subsequent retrieval and querying. The constructed requirement semantic graph is serialized and stored, persisted using a graph database or JSON format. The resulting requirement semantic graph represents the complete semantics of the requirement document in a structured manner, including the functional points, business objects, operational processes, and constraint rules of the requirement, providing knowledge input from the requirement side for subsequent association with code and generation of test cases.

[0025] In some embodiments, due to the potential for vague, ambiguous, or incomplete descriptions in requirement documents, relying solely on automatic parsing may lead to misunderstandings of the requirements. A human-machine collaborative requirement clarification mechanism can be employed to improve the accuracy and completeness of requirement semantic parsing. Specifically, during the requirement semantic parsing process, entities and relationships with confidence levels below a threshold are marked. The system generates a list of requirement clarification questions, inquiring with testers or requirement analysts about the specific meaning of ambiguous entities or the accuracy of their relationships. Testers confirm or correct the marked entities through an interactive interface, supplementing missing constraints. The system updates the requirement semantic graph based on human feedback, solidifying confirmed entity relationships and recoding corrected content. An active learning strategy is adopted, prioritizing manual annotation of requirement descriptions that significantly impact model uncertainty, accumulating high-quality labeled data for continuous model training. Through human-machine collaboration, combining the automated processing capabilities of machines with human domain knowledge, accurate understanding of requirement semantics is achieved, avoiding incorrect test case generation due to misunderstandings of requirements.

[0026] In some embodiments, since requirement documents may contain a large amount of background information or conceptual definitions irrelevant to testing, parsing all of them would introduce noise. A requirement criticality assessment and filtering mechanism can be employed to focus on core requirements directly related to testing, improving parsing efficiency. Specifically, requirement sentences are categorized into functional requirements, non-functional requirements, background descriptions, and conceptual definitions. An importance score for each requirement sentence related to testing is calculated, based on criteria such as whether the sentence contains operational verbs, describes system behavior, and involves data processing. Requirement sentences with scores below a threshold are filtered out and excluded from the construction of the requirement semantic graph. Non-functional requirements, such as performance and security requirements, are extracted and marked separately as input for generating specific types of test cases. Requirement filtering reduces interference from irrelevant information in subsequent processing, making test case generation more focused on core business logic and improving the relevance and effectiveness of test cases.

[0027] Step 2: Obtain the software source code, perform code analysis and multi-dimensional feature extraction to obtain the code semantic feature map; Step 2.1, Source code preprocessing and language recognition; The process involves acquiring software source code. Based on the source code repository as input, code scanning and language detection technologies are used to obtain a categorized and organized collection of code files. Specifically, the directory structure of the code repository is traversed, all source code files are identified, and the programming language type is determined based on the file extension, supporting mainstream languages ​​such as Java, Python, Go, and JavaScript. Test code, configuration files, third-party libraries, and other files unrelated to business logic are filtered out, focusing on the core code that implements business functions. Each code file undergoes encoding detection and formatting to unify coding style, remove comments and blank lines, and retain the core code of program logic. The organizational relationships between code files, such as package structure and module dependencies, are identified to construct a hierarchical structure of the code files. Metadata is created for each code file, including file path, module, and programming language information. The resulting collection of code files is categorized by language type and module, providing input for subsequent language-specific analysis.

[0028] Step 2.2, Abstract Syntax Tree Parsing and Code Structure Extraction; Based on the categorized and organized code file set output in step 2.1, an abstract syntax tree (AST) representation of the code is obtained using the corresponding parser for the programming language. Specifically, for different programming languages, appropriate parser tools are selected, such as Eclipse JDT for Java, the AST module for Python, and the official parser package for Go. The code files are input into the parser, which performs lexical and syntactic analysis according to the language's syntax rules to construct the AST. The AST is a tree-like representation of the code, with nodes corresponding to the syntactic structure of the code, such as class definitions, method definitions, variable declarations, statement blocks, and expressions. The AST is traversed to extract key code structure information, including class inheritance relationships, method parameters and return types, and variable scope. Function definitions in the code are identified, and function signatures are extracted, including function name, parameter list, and return type. Control structures within the function body are identified, such as conditional branches, loop statements, and exception handling. The extracted code structure information is organized in a tree or graph format, with each node containing the type and attributes of a code element. The resulting AST is a structured representation of the code, providing a foundation for subsequent control flow and data flow analysis.

[0029] Step 2.3, Control Flow Graph Construction and Path Analysis; Based on the abstract syntax tree (AST) representation output in step 2.2, a control flow analysis algorithm is used to obtain a function-level control flow graph. Specifically, for each function in the AST, the execution order of statements and control transfers within the function body are analyzed. Each basic statement block within the function body is taken as a node in the control flow graph. A basic statement block is a sequentially executed sequence of statements without internal control transfers. Control structures such as if statements, switch statements, and loop statements are analyzed to identify the conditions and objectives of control transfers. Directed edges are added to the control flow graph to represent the program execution flow transitioning from one basic block to another, with the transfer conditions labeled on the edges. For conditional branches, multiple edges are drawn from the branch nodes, each corresponding to a different branch condition. For loop structures, a loop is formed in the control flow graph, representing the repeated execution of the loop body. The entry and exit nodes of the functions are identified; the entry node is where the function begins execution, and the exit node is where the function returns. Path enumeration is performed on the control flow graph to identify all possible execution paths from the entry to the exit. The number of paths reflects the complexity of the function. The cyclomatic complexity of the control flow graph is calculated as a measure of code complexity. The resulting control flow graph describes the code's execution logic and branching structure, providing a basis for generating test cases that cover different execution paths.

[0030] Step 2.4, Data Flow Analysis and Variable Dependency Tracking; Based on the abstract syntax tree representation output in step 2.2 and the control flow graph output in step 2.3, a data flow analysis algorithm is used to obtain the variable definition-use chain and data dependencies. Specifically, the nodes of the control flow graph are traversed to identify the variable definitions and uses in each node. A variable definition refers to the statement where the variable is assigned a value, and a variable use refers to the statement where the variable's value is read. Reach-definition analysis is used to calculate all possible definition points that each use point can reach, establishing a mapping relationship from definition to use. For each variable use, its data source is traced to identify all definition statements that affect the variable's value. A data dependency graph of variables is constructed, where the nodes represent the locations of variable definitions and uses, and the edges represent the direction of data flow from definition to use. The data flow of function parameters is analyzed to identify how parameters are used and passed within the function. Access to global variables and object attributes is identified, and data flow across functions is tracked. For complex data structures such as arrays and objects, field-sensitive analysis is performed to track the data flow of specific fields. Critical paths in data dependencies are identified, i.e., the main data flow paths that affect function output. The obtained data dependencies reveal the program's data processing logic, providing support for generating test cases targeting data boundaries and data anomalies.

[0031] Step 2.5, Construction of the service call relationship graph; Based on the function call statements in the abstract syntax tree representation output in step 2.2, a call graph construction algorithm is used to obtain cross-module and cross-service call relationship graphs. Specifically, function call statements in the code are scanned to identify the called function names and call locations. For internal function calls, directed edges from the caller to the callee are established according to the function definition. For cross-module calls, import statements and module dependencies are identified to establish call relationships between modules. For remote calls in a microservice architecture, remote interface call statements such as HTTP requests and RPC calls are identified, and the identifiers and interface paths of the target services are extracted. A call relationship graph between services is constructed, with nodes representing various microservices, edges representing call relationships between services, and the called interfaces and data transfers labeled on the edges. The service call chain is analyzed to identify the complete call path from the entry service to the backend service. The in-degree and out-degree of the services are calculated to assess the importance and scope of influence of the services in the system. Cycles in the call graph are identified, which may represent recursive calls or circular dependencies between services. The call relationships are hierarchically divided to distinguish between frontend services, middleware services, and backend services. The resulting call relationship graph describes the system's service topology and interaction structure, providing architectural guidance for generating end-to-end test cases across services.

[0032] Step 2.6, Multidimensional feature fusion and code semantic feature map generation; Based on the control flow graph output in step 2.3, the data dependency graph output in step 2.4, and the call relationship graph output in step 2.5, a heterogeneous graph fusion technique is used to obtain a unified code semantic feature graph. Specifically, the control flow graph, data dependency graph, and call relationship graph are treated as three different perspectives of code representation, and the graphs are merged and fused. The node types of the three graphs are unified, and code elements such as functions, statements, variables, and services are uniformly represented as graph nodes. Type labels are defined for different types of edges, such as control flow edges, data flow edges, and call edges. The nodes of the three graphs are mapped and merged according to the correspondence of code elements, and nodes with the same code element are merged into one node, retaining multiple edge relationships from different graphs. Topology optimization is performed on the merged graph to remove redundant edges and retain key semantic relationships. Feature vectors are calculated for each node in the graph, and the features include the node's code attributes, structural attributes, and statistical attributes. A globally unique identifier is assigned to each node, and an index of code elements is established. The fused code semantic feature graph is serialized and stored, using a graph database or adjacency list format. The obtained code semantic feature map represents the multidimensional semantics of the code in a unified graph structure, integrating multiple aspects such as control logic, data processing, and service interaction, providing comprehensive knowledge of the code side for subsequent association with requirements and identification of test scenarios.

[0033] In some embodiments, unified analysis faces compatibility challenges due to syntactic and semantic differences between different programming languages. A multi-language adaptation framework for the intermediate representation layer can be employed. The aim is to achieve language-independent code semantic extraction. Specifically, a dedicated front-end parsing module is developed for each supported programming language to convert source code into a unified intermediate representation. The intermediate representation uses a common program representation format, such as LLVM IR or a custom abstract semantic model, shielding language-specific syntactic details. Control flow, data flow, and call relationships are analyzed at the intermediate representation layer; the analysis algorithm is independent of specific programming languages. Language-specific features, such as Python's dynamic typing and Java's reflection mechanism, are specially handled during front-end parsing and converted into a general construct of the intermediate representation. Through the multi-language adaptation framework, unified code analysis in heterogeneous language environments is supported, making it suitable for microservice systems implemented in multiple languages, ensuring the completeness and consistency of code feature extraction.

[0034] In some embodiments, due to the difficulty in statically determining call relationships caused by dynamic languages ​​and reflection mechanisms, the call graph may be incomplete. A hybrid analysis method combining static and dynamic analysis can be employed to improve the coverage of call relationship identification. Specifically, based on static analysis, dynamic instrumentation is performed on the code to record actual function and service calls during program runtime. The program's execution trajectory is collected to identify dynamic call relationships that were not discovered by static analysis. The call relationships obtained from dynamic analysis are then added to the call graph and fused with the results of static analysis. For calls driven by plugin mechanisms or configuration, possible call relationships are inferred by analyzing configuration files and plugin registration information. The call graph is labeled with confidence levels to distinguish between high-confidence statically determined calls and possible dynamic calls. This hybrid analysis method improves the accuracy and completeness of call relationship identification, ensuring that the generated test cases can cover actual service call scenarios.

[0035] Step 3: Perform semantic similarity calculation and graph alignment based on the requirement semantic graph and code semantic feature graph to obtain the requirement-code mapping relationship; obtain historical test case data, and perform entity linking and association analysis in combination with the requirement-code mapping relationship to obtain the test knowledge graph; Step 3.1: Calculate the semantic similarity between requirements and code elements; Based on the requirement semantic graph output in step 1 and the code semantic feature graph output in step 2, a requirement-code matching candidate set is obtained using semantic embedding and similarity calculation methods. Specifically, the text descriptions of requirement entities in the requirement semantic graph are encoded using a pre-trained language model to obtain semantic embedding vectors for the requirement entities. Identifiers and annotations of code elements in the code semantic feature graph are extracted and preprocessed, then encoded using the same language model to obtain semantic embedding vectors for the code elements. The cosine similarity between each requirement entity and each code element is calculated; the similarity value reflects the semantic association between the requirement entity and the code element. The similarity values ​​are sorted, and the top N code elements with the highest similarity for each requirement entity are selected as matching candidates. Threshold filtering is applied to remove candidate matches with too low similarity, retaining meaningful associations. For specific types of requirement entities, such as functional modules, matching with classes or services with the same or similar names is prioritized. For operation-type requirement entities, matching with functions or methods is prioritized. The obtained requirement-code matching candidate set provides initial correspondences for subsequent graph alignment.

[0036] Step 3.2, aligning requirement code based on graph structure; Based on the topological structure of the requirement code matching candidate set output in step 3.1, the requirement semantic graph output in step 1, and the code semantic feature graph output in step 2, a graph alignment algorithm is used to obtain the requirement code mapping relationship. Specifically, the requirement semantic graph and the code semantic feature graph are regarded as two graphs to be aligned. Iterative graph matching is performed using the initial similarity between nodes and the structural information of the graph provided by the requirement code matching candidate set. In each iteration, not only the similarity of the nodes themselves is considered, but also the matching situation of the node's neighbors. The confidence of the matching is enhanced by the consistency of the neighbors. A graph kernel method or graph neural network is used to learn the structural embedding representation of the nodes. The structural embedding reflects the topological position and connection pattern of the nodes in the graph. Combining semantic embedding and structural embedding, a comprehensive node similarity is calculated, and the score of the matching candidate is updated. After multiple rounds of iteration, the high-confidence node correspondence is gradually determined, and the mapping from requirement nodes to code nodes is established. For one-to-many or many-to-one mapping cases, reasonable aggregation or splitting is performed. The determined mapping relationship is represented as an edge across the graph, connecting the corresponding nodes in the requirement graph and the code graph. The obtained requirement-code mapping relationship realizes the traceability link between requirements and code, clarifies which code implements which requirements, and provides a basis for requirement coverage of test cases.

[0037] Step 3.3, Structured analysis of historical test cases; Based on historical test case data, a structured test case representation is obtained using test case parsing technology. Specifically, historical test cases are extracted from the test management system or test case documents. Test cases typically include fields such as test case title, preconditions, test steps, test data, and expected results. Text parsing is performed on each field of the test case to identify key information. Test steps are decomposed, breaking each step down into the operation object, operation action, and operation parameters. Preconditions are parsed to identify the test environment and data preparation requirements. Expected results are parsed to extract the expected output or state change. Test cases are categorized according to test type tags such as functional testing, boundary testing, and exception testing. Execution records of test cases are extracted, including execution time, execution results, and defects found. The association between test cases and requirements and code is identified; some test cases may already be labeled with associated requirement numbers or involved code modules. The parsed information is organized into a structured test case representation, with each test case as an entity containing its attributes and content. The resulting structured test case representation provides test dimension information for the construction of a knowledge graph.

[0038] Step 3.4: Entity linking test cases with requirement code; Based on the structured test case representation output in step 3.3 and the requirement code mapping relationship output in step 3.2, entity linking technology is used to obtain the test case association relationship. Specifically, the content of the structured test case representation output in step 3.3 is analyzed to extract the functional points, business objects, and operational actions involved in the test cases. The extracted elements are matched with the entities in the requirement semantic graph output in step 1 to establish links from test cases to requirement nodes. For test cases with marked requirement numbers, the association with the corresponding requirement node is directly established. For unmarked test cases, the most relevant requirement node is found through semantic similarity matching. The code modules or functions involved in the test cases are analyzed, and the links from test cases to code nodes in the code semantic feature graph output in step 2 are established through name or path matching of code elements. For code coverage information in the test execution record, it is directly associated with the covered code node. Test case nodes are established, and test cases are treated as independent nodes in the graph, connected to related requirement nodes and code nodes through directed edges. The edge type represents the association relationship, such as test coverage, requirement verification, etc. The obtained test case association relationship links test cases with requirements and code, forming a traceability network among the three.

[0039] Step 3.5, Integration and Correlation Analysis of Defect Data; Based on historical defect data, defect association analysis is used to obtain defect association information. Specifically, defect records are extracted from the defect management system, including defect description, defect type, severity, discovery time, and fix code. Text analysis is performed on the defect description to identify the functional points and problem phenomena involved. The defect is associated with the test case that discovered it, establishing a link between the defect and the test case node in the test case association relationship output in step 3.4. The code commit records for defect fixes are analyzed to identify the code files and functions involved in the fix, establishing a link between the defect and the code node in the code semantic feature graph output in step 2. Based on the functional points involved, the defect is associated with the corresponding requirement node in the requirement semantic graph output in step 1. Cluster analysis is performed on the defects to identify code regions and requirement modules with high defect density, which require focus in subsequent testing. The distribution of different types of defects is statistically analyzed to identify common defect patterns, such as null pointer exceptions, boundary overflows, and concurrency conflicts. The defects are treated as nodes in the graph and connected to related code, requirements, and test cases through edges. The obtained defect association information provides historical experience for optimizing the testing strategy, and the intensity of test case generation should be increased in high-defect areas.

[0040] Step 3.6: Test the fusion and construction of the knowledge graph; Based on the requirement semantic graph output in step 1, the code semantic feature graph output in step 2, the test case associations output in step 3.4, and the defect association information output in step 3.5, a heterogeneous graph fusion method is used to obtain a test knowledge graph. Specifically, four types of entity nodes—requirement nodes, code nodes, test case nodes, and defect nodes—are integrated into the same graph structure. A unified node type system and edge type system are defined. Node types include requirement entities, code elements, test cases, defect records, etc., and edge types include implementation relationships, coverage relationships, call relationships, data flow relationships, discovery relationships, etc. The various associations established in the previous steps are transformed into graph edges, connecting related nodes. Global topology optimization is performed on the graph, removing isolated nodes, merging duplicate nodes, and enhancing the graph's connectivity. Attributes are assigned to each node and edge in the graph. Node attributes include entity description, type, creation time, etc., and edge attributes include relationship strength, confidence, etc. Community discovery or module partitioning is performed on the graph to identify closely related node groups, which often correspond to functional modules or business domains of the system. A multi-layered index is built for the graph, supporting efficient node queries and subgraph retrieval. The constructed test knowledge graph is persistently stored in a graph database, such as Neo4j or JanusGraph, supporting complex graph queries and traversal operations. The resulting test knowledge graph is a multi-dimensional, multi-layered knowledge network that comprehensively represents the complex relationships between requirements, code, tests, and defects, providing rich knowledge support for intelligent test case generation.

[0041] In some embodiments, due to the lack of historical test data in the early stages of a project, the construction of a knowledge graph faces a cold start problem. A knowledge graph pre-training method based on transfer learning can be adopted. The aim is to accelerate the construction of the knowledge graph by leveraging external knowledge. Specifically, requirement documents, code, and test cases from open-source projects are collected to construct a general-domain test knowledge graph as a base graph. The base graph is pre-trained to learn the general association patterns between requirements, code, and test cases. The base graph is used as initial knowledge and applied to the target project. Through the transfer of nodes and edges in the graph, an initial knowledge structure is provided for the target project. A small amount of data from the target project is used to fine-tune the transferred graph, adjusting node attributes and edge weights to adapt the graph to the characteristics of the target project. As test data from the target project accumulates, the graph is continuously updated and expanded, gradually replacing the transferred general knowledge. Through transfer learning, the data requirements for knowledge graph construction are reduced, the cold start cycle of the project is shortened, and the test case generation method can be quickly applied to new projects.

[0042] Step 4: Based on the test knowledge graph, identify test scenarios and prioritize them to obtain a test scenario priority list; Step 4.1, extracting the subgraph of the target requirement; Based on the requirement node identifiers of the target testing requirements, a subgraph sampling algorithm is used to obtain a task-related subgraph from the test knowledge graph output in step 3. Specifically, the requirement node corresponding to the target requirement is used as a seed node, and multi-hop neighbor expansion is performed in the test knowledge graph. Starting from the seed node, a breadth-first or depth-first traversal is performed along the edges to visit adjacent nodes. A hop limit is set for expansion, such as 2 hops or 3 hops, to control the size of the subgraph. During the expansion process, edges with high association strength are prioritized for expansion, and the association strength is represented by the edge weight or confidence. All nodes and edges visited during the traversal are collected to form the task-related subgraph of the target requirement. The task-related subgraph contains code elements, historical test cases, and defect information that are directly or indirectly related to the target requirement. The subgraph is pruned to remove nodes that are irrelevant to testing, such as pure configuration nodes or document nodes. The resulting task-related subgraph focuses on the testing scope of the target requirement, reduces interference from irrelevant information, and provides accurate knowledge input for subsequent scene identification.

[0043] Step 4.2, learning node embeddings in the graph neural network; Based on the task-related subgraph output in step 4.1, a graph neural network model is used to obtain a set of node embedding vectors. Specifically, the feature vectors of the nodes in the task-related subgraph are initialized, and the feature vectors are obtained by encoding the node's attributes and text descriptions. The task-related subgraph is input into the graph neural network model, which includes multiple layers of graph convolutional layers or graph attention layers. In each layer, nodes update their own feature representation by aggregating the features of their neighbors. The aggregation operation is performed through weighted summation or attention mechanisms, and the weights reflect the degree of influence of neighboring nodes on the current node. The graph attention mechanism dynamically calculates attention weights based on the semantic relevance between nodes, giving more weight to neighbors with high relevance. After multiple layers of feature propagation and aggregation, the node feature embeddings integrate information from the local neighborhood and the global graph structure. The node embedding vectors capture the node's role and contextual relationships in the graph. The trained graph neural network is then fed the task-related subgraph, and forward propagation is used to obtain the final embedding vectors of each node. The resulting set of node embedding vectors is a high-dimensional semantic representation of the nodes, providing a feature foundation for clustering and similarity calculation in the test scenario.

[0044] Step 4.3, clustering of test scenarios based on embedding; Based on the node embedding vector set output in step 4.2, a clustering algorithm is used to obtain a test scenario set. Specifically, nodes related to testing in the task-related subgraphs are selected, such as requirement nodes, key code nodes, and historical test case nodes. The embedding vectors of these nodes are extracted to form a feature matrix. Clustering algorithms such as K-means clustering or hierarchical clustering are used to group the nodes. The clustering algorithm groups similar nodes into the same class based on the similarity of their embedding vectors. Each cluster represents a test scenario, and the nodes within the cluster together constitute the test scope of that scenario. Each cluster is analyzed to identify the core nodes and boundary nodes of the cluster; the core nodes are representative nodes of the cluster. Scenario labels are generated for each cluster, based on the main types and functional descriptions of the nodes within the cluster. The size and density of the clusters are evaluated; large clusters may represent complex test scenarios requiring more test cases. The resulting test scenario set decomposes the overall test task into multiple sub-scenarios, each corresponding to specific functional points or interaction flows, facilitating the targeted generation of test cases.

[0045] Step 4.4, Risk assessment and prioritization of test scenarios; Based on the test scenario set and historical defect data output in step 4.3, a risk assessment model is used to obtain a test scenario priority list. Specifically, for each test scenario, the number of historical defects associated with code nodes within the scenario is counted; scenarios with a high number of defects have higher risk. The complexity metrics of the code involved in the scenario are calculated, such as cyclomatic complexity and lines of code; complex code is more prone to errors. The importance of the requirements involved in the scenario is analyzed; requirements for core business functions have high priority. The frequency of code changes in the scenario is assessed; code that has been frequently modified recently is more unstable and requires focused testing. The test coverage history of the scenario is analyzed; scenarios with insufficient historical coverage need supplementary testing. Considering the above factors, a risk scoring model is established to calculate a risk score for each test scenario. The higher the risk score, the higher the test priority of the scenario. Test scenarios are sorted in descending order of risk score to obtain a test scenario priority list. With limited test resources, test cases are generated and executed first for high-priority scenarios to ensure coverage of key risks. The resulting test scenario priority list guides the rational allocation of test resources, improving the targeting and efficiency of testing.

[0046] In some embodiments, since code changes may affect multiple test scenarios, it is necessary to identify the scope of the change's impact. An impact analysis method based on code changes can be used. The aim is to accurately locate the scenarios requiring regression testing. Specifically, this involves obtaining code change records from the code version control system and identifying the changed files and functions. The changed code nodes are located in the test knowledge graph, and impact propagation analysis is performed along call relationships and data dependencies. All nodes that directly or indirectly depend on the changed code are identified; these nodes constitute the scope of the change's impact. Nodes within the scope of impact are associated with corresponding test scenarios to determine the set of affected test scenarios. The affected test scenarios are prioritized to ensure that change-related functions are adequately tested. Through impact analysis, full regression testing can be avoided, test execution time reduced, and the quality of the change guaranteed.

[0047] Step 5: Based on the test scenario priority list and test knowledge graph, generate test cases to obtain a test case set; Step 5.1, Feature encoding of the test scenario; Based on the test scenario priority list output in step 4, feature aggregation and encoding methods are used to obtain a set of scenario feature vectors. Specifically, the embedding vectors of requirement nodes, code nodes, and historical test case nodes included in the test scenario are extracted. The embedding vectors of all nodes within the scenario are aggregated using average pooling or attention-weighted pooling to obtain scenario-level feature representations. During aggregation, core nodes are assigned higher weights, as they contribute more to the scenario's features. Structural features of the scenario are extracted, such as the number of services involved, call chain length, and branch complexity. The structural features are concatenated with the node embedding features to form a multimodal scenario feature vector. The scenario features are normalized to unify the scale range of the features. The resulting set of scenario feature vectors serves as the input to the subsequent test case generation model, containing the semantic and structural information of the scenario.

[0048] Step 5.2, Test case framework generation; Based on the test scenario types and testing strategies in the test scenario priority list output in step 4, a test case framework set is obtained using a test case template library. Specifically, a test case template library is maintained, with templates categorized by test type, including functional test templates, boundary test templates, exception test templates, performance test templates, etc. Applicable test templates are selected according to the characteristics of the test scenario; for example, if the scenario involves data input verification, a boundary test template is selected. The test template defines the structural framework of the test case, including preconditions, the order of test steps, and the form of the expected result. The scenario requirement description is filled into the corresponding fields of the template to form a preliminary test case framework. The template contains placeholders to identify the content that needs to be specified, such as specific operation objects, input data values, and expected output values. The resulting test case framework set provides structured constraints to ensure that the generated test cases conform to the specified format.

[0049] Step 5.3, generation of test steps for sequence-to-sequence models; Based on the scene feature vector set output in step 5.1 and the test case framework set output in step 5.2, a sequence-to-sequence model using the Transformer architecture is employed to obtain a test step sequence set. Specifically, the scene feature vector set output in step 5.1 is used as the encoder input to the model. The encoder extracts deep representations of the features through a multi-layer self-attention mechanism. The placeholder sequence of the test case framework set output in step 5.2 is used as the initial input to the decoder. The decoder generates the test step text stepwise in an autoregressive manner. In each generation step, the decoder predicts the next word or subword based on the generated content and the encoder output. A constraint decoding strategy is adopted to restrict the generated content to conform to the grammatical specifications of test cases, such as requiring test steps to include operation verbs and operation objects. Lexical constraints from the testing domain are introduced to prioritize the generation of test terms and common operations, avoiding the generation of meaningless or erroneous text. Historical test cases in the test knowledge graph output in step 3 are used as a reference. Through an attention mechanism, attention is paid to historical test cases similar to the current scenario, and their expression methods are borrowed. During the generation process, placeholders in the template are dynamically filled to concretize the abstract test steps. The generated test steps undergo post-processing, including syntax checking and semantic consistency verification, to ensure logical coherence. The resulting set of test step sequences provides a detailed description of the test operation flow, ensuring readability and executableness.

[0050] Step 5.4, Intelligent generation of test data; Based on the test step sequence set output in step 5.3 and the data constraints of the code in the code semantic feature graph output in step 2, constraint solving and data generation techniques are used to obtain the test data set. Specifically, the input parameters involved in the test step sequence set output in step 5.3 are analyzed to extract the parameter types, value ranges, and constraints. Parameter validity constraints are obtained from the data flow analysis of the code semantic feature graph output in step 2, such as parameters must be positive integers and string lengths not exceeding a certain value. For boundary test scenarios, boundary value data is generated, including minimum, maximum, and critical values. For abnormal test scenarios, abnormal data violating constraints is generated, such as null values, negative values, and excessively long strings. For functional test scenarios, typical normal data is generated, covering common usage scenarios. A constraint solver is used to generate data combinations that meet the conditions based on the parameter constraints. For complex data structures such as objects and arrays, data for each field is generated recursively. For data dependent on external resources such as file paths and database records, placeholders are provided or simulated data is generated. The generated test data is verified to ensure that the data conforms to parameter constraints and business rules. The test data is then populated into the test steps to form a complete test operation. The resulting test data set covers normal, boundary, and abnormal situations, improving the coverage of test cases and the ability to detect defects.

[0051] Step 5.5, Inference and generation of expected results; Based on the test step sequence set output in step 5.3, the test data set output in step 5.4, and the requirement specification in the requirement semantic graph output in step 1, rule-based reasoning and model prediction methods are used to obtain the expected result set. Specifically, business rules and constraints related to the test scenario are extracted from the requirement semantic graph output in step 1. Based on the operations in the test step sequence set output in step 5.3 and the input data in the test data set output in step 5.4, business rules are applied for reasoning to predict the system's output or state changes. For simple functions, rule-based reasoning is used; for example, valid input data is expected to return a success state, while invalid input data is expected to return an error message. For complex business logic, symbolic execution or path analysis of the code semantic feature graph output in step 2 is used to simulate the code execution process and deduce the output results. Referring to the expected results of similar scenarios in historical test cases in the test knowledge graph output in step 3, the expected results of the current test case are generated through analogy and transfer. A consistency check is performed on the generated expected results to ensure consistency with the requirement specification and business rules. For tests involving databases or external systems, the expected database state or external system response is generated. The expected results are represented in a structured form, including return values, status codes, output messages, and database records. The resulting set of expected results provides a basis for determining test execution and is an important component of test cases.

[0052] Step 5.6, Formatting and Executing Test Cases; Based on the test step sequence set output in step 5.3, the test data set output in step 5.4, and the expected result set output in step 5.5, a test case set is obtained using test script generation technology. Specifically, a target testing framework, such as JUnit, PyTest, or Selenium, is selected, and the framework is determined according to the test type. The test step sequence set output in step 5.3 is converted into API calls of the testing framework, such as converting page operations into Selenium's element location and click methods. The test data set output in step 5.4 is embedded into the test code as function parameters or variable assignments. The expected result set output in step 5.5 is converted into assertion statements, which verify the consistency between the actual output and the expected output. Precondition code for the test cases is generated, including environment initialization, data preparation, and simulation of dependent services. Post-cleanup code for the test cases is generated, including resource release, data cleanup, and state restoration. The generated test code is subjected to syntax checking and compilation verification to ensure the correctness of the code. Comments and documentation are added to the test cases, explaining the test purpose, test data source, and the basis for the expected results. Test cases are organized according to the directory structure of the test framework to generate test suites. The resulting set of test cases can be executed directly in the test environment, achieving automated conversion of test case descriptions into code.

[0053] In some embodiments, since the sequence generation model may generate test steps that do not conform to the actual operation process, a post-generation verification and repair mechanism based on workflow constraints can be adopted. The aim is to ensure that the generated test steps are logically correct and executable. Specifically, a workflow model for test operations is defined, including dependencies and sequential constraints between operations. A workflow consistency check is performed on the generated test step sequence to identify steps that violate constraints. For example, a login operation must precede other business operations, and data deletion operations must prevent access to the data afterward. Steps that violate constraints are automatically repaired by adjusting the step order or supplementing missing prerequisite steps. The repaired test steps are then re-verified to ensure that the repair does not introduce new errors. Through this verification and repair mechanism, the quality of generated test cases is improved, and invalid or erroneous test cases are reduced.

[0054] In some embodiments, since testing in a microservice architecture needs to be performed across multiple services, single-service test cases cannot cover end-to-end scenarios. A service orchestration-based end-to-end test case assembly method can be adopted. The aim is to generate cross-service integration test cases. Specifically, based on the service call chain involved in the test scenario, single-service test cases that need to be combined are identified. Data flow matching is performed on the test cases of each service in the call chain to ensure that the output of the upstream service is consistent with the input data type and format of the downstream service. Data transfer code between services is generated to simulate interface calls or message passing between services. Cross-service transactions and consistency are handled, and appropriate synchronization waiting and retry mechanisms are set. An orchestration script for end-to-end test cases is generated, and the script executes the test steps of each service sequentially according to the service call order. The integration test environment for the end-to-end test cases is deployed and configured to ensure that each service is available and network connected. Through service orchestration, cross-service business process testing is achieved, improving the verification capability of system-level functions.

[0055] Step 6: Perform a quality assessment on the test case set, remove redundant test cases and add missing test cases to obtain an optimized test case set; Step 6.1, Initial execution of test cases and coverage collection; Based on the test case set output in step 5, automated test execution tools are used to obtain execution results and coverage data. Specifically, the test execution environment is configured, including deploying the application under test, preparing test data, and starting dependent services. The test case set is executed in batches, with the test framework executing the cases sequentially according to their priority. During execution, coverage information is collected using code instrumentation techniques, recording the lines of code, branches, functions, etc., triggered during the execution of each test case. The execution results of the test cases are recorded, including pass, fail, and error statuses. For failed test cases, the failure reasons and exception stack information are recorded. The execution time of the test cases is statistically analyzed, and test cases with long execution times are identified. The coverage data of all test cases is summarized, and overall metrics such as line coverage, branch coverage, and path coverage are calculated. A coverage matrix is ​​constructed, where rows represent test cases, columns represent code units, and matrix elements indicate whether a test case covers that code unit. The obtained execution results and coverage data provide a quantitative basis for the quality assessment and optimization of test cases.

[0056] Step 6.2, Evaluation of test case coverage contribution; Based on the execution results and coverage data output in step 6.1, a contribution score set is obtained using a contribution calculation method. Specifically, for each test case, the number of code units exclusively covered is counted, i.e., code covered only by that test case and not by other test cases. Test cases with a high number of exclusively covered code units are irreplaceable and have a high contribution. The importance weight of the code units covered by the test case is calculated, with core functions and high-risk code having higher weights. The higher the proportion of important code covered by a test case, the higher its contribution. The uniqueness of the code paths covered by the test cases is analyzed; test cases covering rare execution paths help discover deep defects and have a high contribution. Combining exclusive coverage, code importance, and path uniqueness, a comprehensive coverage contribution score for the test cases is calculated. The test cases are sorted according to their contribution scores to identify high-contribution and low-contribution test cases. The resulting contribution score set is used to guide the selection and simplification of test cases.

[0057] Step 6.3, Identification and simplification of redundant test cases; Based on the contribution score set and test case similarity analysis output in step 6.2, a test case simplification algorithm is used to obtain a simplified test case set. Specifically, the coverage similarity between test cases is calculated, which is the ratio of the intersection to the union of the covered code units. Highly similar test case pairs are identified, as these test cases cover code with high overlap and redundancy. For similar test case pairs, their coverage contribution and execution time are compared, retaining test cases with high contribution and short execution time, and eliminating redundant test cases. Test cases with very low contribution and completely covered by other test cases are directly eliminated. A greedy algorithm or set coverage algorithm is used to select the minimum number of test cases to achieve the set coverage target. During the simplification process, it is ensured that each critical code unit is covered by at least one test case to avoid excessive simplification leading to a decrease in coverage. The coverage of the simplified test case set is verified to ensure that the overall coverage index has not decreased significantly. The resulting simplified test case set reduces the number of test cases while maintaining coverage, thus improving test execution efficiency.

[0058] Specifically, a multi-dimensional similarity analysis method is used to identify highly similar test case pairs. For coverage similarity, the intersection and union of the code units covered by two test cases are calculated, and the ratio of the intersection to the union is used as the coverage similarity index; a higher ratio indicates a greater degree of coverage overlap. For semantic similarity, the test step description text of the test cases is vectorized, and the degree of semantic similarity is evaluated by calculating the cosine distance between the vectors; a smaller distance indicates a more similar test logic. For data similarity, the types, numerical ranges, and constraints of the input parameters used by the test cases are compared, and the proportion of identical data features is used as the data similarity. The overall similarity is calculated using a weighted average method based on the similarity scores of the three dimensions. When the overall similarity exceeds a preset threshold, the two test cases are marked as highly similar pairs. The identified similar test case pairs are then grouped and clustered. Test cases with similarity exceeding the threshold are grouped into the same redundant group. Within each redundant group, the best representative test case is selected and retained based on coverage contribution and execution efficiency, while the remaining test cases are deleted as redundant test case candidates.

[0059] Step 6.4: Identification of uncovered code and generation of supplementary use cases; Based on the execution results and coverage data output in step 6.1, a supplementary test case set is obtained using a coverage gap analysis method. Specifically, the coverage matrix in the execution results and coverage data output in step 6.1 is analyzed to identify lines and branches of code not covered by any test cases; these constitute coverage gaps. The importance of the code with coverage gaps is assessed, focusing on coverage gaps in core business logic and error handling code. Path condition analysis is performed on uncovered code branches to identify the input constraints that trigger those branches. Symbolic execution or constraint solving techniques are used to generate test input data that satisfies the path constraints. Based on the generated test input, supplementary test cases are constructed, with the goal of covering the uncovered code paths. The supplementary test cases are executed and verified to confirm that they indeed cover the target code. The supplementary test cases are added to the simplified test case set output in step 6.3, and the coverage matrix is ​​updated. Gap analysis and supplementary test case generation are repeated until the coverage reaches the predetermined target or cannot be improved further. The resulting supplementary test case set fills the coverage gaps and improves the comprehensiveness of the tests.

[0060] Step 6.5: Dynamically adjust the priority of test cases; Based on the execution history and defect discovery records of test cases, a dynamic priority adjustment strategy is adopted to obtain an optimized test case set. Specifically, the number and severity of defects found in each test case throughout history are statistically analyzed, and test cases with strong defect discovery capabilities are given higher priority. The code changes covered by the test cases are analyzed, and test cases covering recently changed code are given higher priority, with regression tests being executed first. Considering the execution time of test cases, test cases that can provide high coverage in a short time are prioritized when time is limited. For test cases that have not been executed for a long time, their priority is appropriately increased to ensure comprehensive test coverage. Reinforcement learning or multi-armed gambler algorithms are used to dynamically adjust priorities based on test case execution feedback, balancing exploration and utilization. Test cases are sorted according to the adjusted priorities to generate an optimized test execution plan. In the continuous integration environment, relevant test case sets are dynamically selected for execution based on the scope of changes in each code commit, improving test feedback speed. This results in an optimized test case set, ensuring efficient use of test resources and maximizing test effectiveness within a limited time.

[0061] In some embodiments, the portability and repeatability of test cases are affected because the execution of test cases may depend on specific environment configurations and test data. A test environment containerization and test data management mechanism can be adopted to improve the stability and reproducibility of test case execution. Specifically, the test environment is packaged as a Docker container, containing all components such as the application under test, dependent services, and testing tools. The required container configuration is defined for each test case, and the container environment is automatically launched during test execution. Test data is version-managed, and test data is initialized using database snapshots or data scripts. Test data is automatically restored to its initial state before each test execution to ensure test independence. Through environment containerization and data management, the impact of environmental differences on test results is eliminated, improving test reliability.

[0062] Step 7: Based on the optimized test case set, evaluate the test case execution effect from multiple dimensions and continuously optimize to obtain an updated test case generation strategy; Step 7.1, multi-dimensional evaluation of test results; Based on the test execution results data of the optimized test case set output in step 6, a multi-dimensional indicator calculation method is used to obtain a test effectiveness evaluation report. Specifically, various data are collected during the test execution process, including test case pass rate, number of defects found, defect severity, code coverage, execution time, etc. An effectiveness score is calculated for each test case, taking into account coverage contribution, defect finding capability, and execution efficiency. For defect finding capability, the number of defects found by the test cases is counted, with higher severity defects assigned higher weight. For execution efficiency, the unit time coverage of the test cases is calculated, i.e., the number of lines of code or branches covered per second. The effectiveness scores of the test cases are aggregated at the test scenario level to evaluate the testing value of different test scenarios. High-value and low-value scenarios are identified; high-value scenarios are those with a high return on investment, while low-value scenarios may involve overtesting or improper test design. The overall effectiveness of the testing strategy is evaluated, including macro-level indicators such as overall coverage, total number of defects found, and testing cost. A test effectiveness evaluation report is generated, visually displaying the distribution and trends of each dimension of indicators. The resulting test effectiveness evaluation report provides quantitative feedback signals for strategy optimization.

[0063] Step 7.2, Construction of a policy model based on reinforcement learning; Based on the test performance evaluation report output in step 7.1, a reinforcement learning framework is used to obtain a policy optimization model. Specifically, the test case generation process is modeled as a Markov decision process, where the state includes current requirement characteristics, code state, the set of generated test cases, coverage, etc. Actions are the decisions made during test case generation, including selecting test scenarios, determining test types, and adjusting generation parameters. The reward function is designed based on the test performance evaluation report results: positive rewards are given for discovering defects and improving coverage, while negative rewards are given for excessive execution time. A policy network is constructed, with the current state as input and the probability distribution of actions as output. The policy network is implemented using a deep neural network, including multiple fully connected layers or recurrent network layers. The policy gradient algorithm or actor-critic algorithm is used to train the policy network, aiming to maximize the expected value of the cumulative reward. During training, trajectory data of state, action, and reward are collected through interaction with the test environment. The policy gradient is calculated using the trajectory data, and the parameters of the policy network are updated to optimize the policy towards higher rewards. A baseline function or value network is introduced to reduce the variance of the policy gradient and accelerate training convergence. The resulting strategy optimization model can intelligently decide on the strategy for generating test cases based on the current test state, thereby achieving adaptive test generation.

[0064] Step 7.3, Offline reinforcement learning policy pre-training; Based on historical test data, an offline reinforcement learning approach is used to obtain a pre-trained policy model. Specifically, test execution data from historical projects is collected, including test cases, execution results, and defect information, to construct an offline dataset. Sequences of states, actions, and rewards are extracted from the offline dataset, using the historical testing process as an experience trajectory. Offline reinforcement learning algorithms, such as batch constrained Q-learning or conservative Q-learning, are used to learn policies from the offline data. Offline learning avoids online interaction with the environment, reduces dependence on actual test execution, and shortens the training cycle. The offline learning algorithm learns effective policies implicit in historical data through behavior cloning and value function estimation. The learned policies are evaluated, and their effectiveness is verified in a simulated environment or small-scale testing. The pre-trained policy model is used as the initialization for new project test policies, fine-tuned through a small amount of online learning, and quickly adapted to new projects. The resulting pre-trained policy model utilizes historical experience, accelerating the learning process of test policies for new projects and improving cold start performance.

[0065] Step 7.4, update the parameters of the test case generation model; Based on the strategy optimization model output in step 7.2, an updated test case generation model is obtained using the model parameter transfer method. Specifically, the actions output by the strategy optimization model in step 7.2 include strategy parameters such as the selection weight of test scenarios and the generation probability of test types. These strategy parameters are mapped to the hyperparameters or model weights of the test case generation model. For the selection weight of test scenarios, the parameters of scenario clustering and priority ranking are adjusted to increase the weight of high-value scenarios. For the generation probability of test types, the generation ratio of different types of test cases, such as boundary tests, anomaly tests, and performance tests, is adjusted. The decoding strategy of the sequence generation model is adjusted, such as adjusting the width of the beam search and the sampling temperature parameter, affecting the diversity and quality of the generated data. The parameters of the constraint solver are optimized, adjusting the depth and breadth of the solution to balance the solution efficiency and the quality of the solution. Model fine-tuning technology is used to retrain the generation model using new test feedback data and update the model's weight parameters. During the fine-tuning process, the general knowledge of the pre-trained model is retained while adapting to the specific needs of the current project. The updated generation model is validated by generating a small batch of test cases to evaluate the improvement in generation quality. The resulting updated test case generation model can generate higher quality test cases that better meet current testing needs, achieving adaptive optimization of the model.

[0066] Step 7.5, Establishing a continuous learning mechanism; Based on continuous feedback from test execution, an updated test case generation strategy is derived using online learning and incremental update methods. Specifically, a real-time collection pipeline for test feedback data is established, automatically collecting performance evaluation data after each test execution. New feedback data is added to the training dataset, and the model is updated using an incremental learning algorithm, eliminating the need for retraining from scratch. Model updates employ a periodic or event-triggered mechanism, triggering updates when a sufficient amount of new data is accumulated or a significant change in test performance is detected. During the model update process, a forgetting mechanism is used to reduce the weight of outdated historical data or remove it, preventing the model from being misled by stale data. Online A / B testing is conducted on the updated model to compare the performance of the old and new models in actual tests, verifying the effectiveness of the update. Based on the A / B test results, a decision is made on whether to formally deploy the new model or conduct further optimization. A model version management system is established, saving snapshots of the model from each update, supporting model rollback and comparative analysis. Through the continuous learning mechanism, the test generation system can continuously improve itself as the software evolves and testing experience accumulates, maintaining a high efficiency in test case generation over the long term. The resulting updated test case generation strategy achieves adaptive evolution and continuous optimization of the test system.

[0067] In some embodiments, the validity of test results may be affected by differences between the test environment and the production environment. Test environment simulation and production data anonymization techniques can be employed to improve the realism and validity of the tests. Specifically, a test environment highly consistent with the production environment is constructed, including hardware configuration, network topology, and third-party services. Service virtualization technology is used to simulate the behavior of externally dependent services, ensuring the independence of the tests. Production data is anonymized, removing sensitive information before being imported into the test environment, ensuring the authenticity of the test data. Environment simulation enhances the ability of tests to discover production problems and increases the confidence level of the tests.

[0068] In some embodiments, reinforcement learning training requires numerous test executions, resulting in high training costs. A simulator-based virtual testing environment can be employed to accelerate policy learning and reduce training costs. Specifically, a lightweight simulator for the system under test is constructed, capable of quickly responding to test inputs and returning predicted test results. The simulator learns the system's input-output behavior based on static code analysis and historical execution data. During the policy training phase, the simulator replaces real test executions, rapidly acquiring a large amount of interaction data. The simulator is periodically calibrated using the results of real test executions to improve simulation accuracy. The virtual testing environment enhances the efficiency of policy training and shortens the model iteration cycle.

[0069] An AI-based adaptive software test case generation system, such as... Figure 3 As shown, the method for adaptive generation of software test cases based on an AI model, as described above, includes: The requirements parsing module is used to obtain the original requirements document, perform requirements semantic parsing and structured representation, and obtain the requirements semantic graph. The code analysis module is used to acquire software source code, perform code analysis and multi-dimensional feature extraction, and obtain a code semantic feature map. The knowledge graph construction module performs semantic similarity calculation and graph alignment based on the requirement semantic graph and the code semantic feature graph to obtain the requirement-code mapping relationship; it acquires historical test case data and performs entity linking and association analysis in combination with the requirement-code mapping relationship to obtain the test knowledge graph; The scene recognition module, based on the test knowledge graph, identifies test scenes and prioritizes them to obtain a test scene priority list. The test case generation module generates test cases based on the test scenario priority list and the test knowledge graph, resulting in a test case set. The test case optimization module is used to perform quality assessment on the test case set, remove redundant test cases and add missing test cases to obtain an optimized test case set; The strategy update module evaluates the performance of test cases from multiple dimensions and continuously optimizes them based on the optimized test case set, resulting in an updated test case generation strategy.

[0070] In one embodiment of the present invention, a specific example is provided: A financial institution's online payment system consists of 20 microservices, including user authentication, account services, payment services, risk control services, and notification services. The system is developed using a hybrid Java and Go language, and processes millions of transactions daily. The testing team needs to quickly generate test cases covering new features and regression tests in twice-weekly version iterations.

[0071] Using the method of this invention, the requirement document for this iteration is obtained, which describes the newly added QR code payment function. Through the semantic parsing of the requirements in step 1, the system identifies the core requirement entities, including "QR code generation", "scan to pay", "payment confirmation", and the constraints "payment amount is greater than 0 and does not exceed the single transaction limit" and "QR code is valid for 30 minutes".

[0072] Through code feature extraction in step 2, the system analyzed the newly added code of payment service, account service, and risk control service, constructed a code semantic feature graph containing 85 function nodes and 320 call edges, and identified 7 service interfaces involved in the cross-service call chain.

[0073] Through the knowledge graph construction in step 3, the system aligned the requirement nodes with the newly added code functions, establishing 42 traceability links from requirements to code. Integrating historical test data, 12 defect records were found in the payment amount verification module, which were marked as high-risk areas.

[0074] Through step 4, the system identified five test scenarios: QR code generation scenario, normal QR code payment scenario, payment amount boundary scenario, QR code timeout scenario, and risk control interception scenario. Based on risk assessment, the payment amount boundary scenario and the risk control interception scenario were rated as high priority.

[0075] Through test case generation in step 5, the system generates a total of 35 test cases for 5 test scenarios, including 18 functional test cases, 10 boundary test cases, and 7 exception test cases. The test cases contain detailed test steps, test data, and expected results, and automatically generate executable JUnit test code.

[0076] Table 1 shows an example of QR code generation test data: Table 1: Example of QR code generation test data; Table 2 shows an example of QR code payment test data: Table 2: Example of QR code payment test data; Through test case optimization in step 6, the system executed these 35 test cases, and the collected coverage data showed that the line coverage reached 89% and the branch coverage reached 82%. The system identified and simplified 3 redundant test cases, and found that an exception handling branch of the risk control service was not covered, so it automatically generated 2 targeted test cases to supplement it. The final test case set contained 34 test cases, and the coverage was improved to 92%.

[0077] The test revealed five defects, including two boundary value handling errors, two omissions in exception handling, and one service call timeout issue with no retry. These defects were fixed before the release, ensuring system quality.

[0078] Based on the feedback optimization in step 7, the system updated its testing strategy according to the defect patterns discovered in this test, and increased the intensity of test case generation for timeout and retry mechanisms in the next iteration. After three iteration cycles of continuous optimization, the defect discovery rate of test cases increased from 1.2 defects per 100 test cases to 2.5 defects per 100 test cases, thus improving testing efficiency.

[0079] Compared to traditional manual test case writing, this invention reduces test case writing time from an average of 20 minutes per case to 5 minutes of manual review after automatic generation, increasing test case generation efficiency by four times. Test coverage increases from an average of 75% for manually written test cases to over 90%. Test case maintenance costs are reduced; test cases are automatically updated after requirement changes, eliminating the need for manual modification.

[0080] This application example fully verifies the effectiveness and practicality of the method of the present invention in the testing of actual financial payment systems, and provides an intelligent solution for software testing of complex microservice architectures.

[0081] The embodiments of the present invention have been described above. However, the embodiments are not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make more equivalent embodiments under the guidance of the present embodiments, and all of them are within the protection scope of the present embodiments.

Claims

1. A method for adaptive generation of software test cases based on an AI model, characterized in that, Includes the following steps: Obtain the original requirements document, perform semantic parsing and structured representation of the requirements, and obtain the requirements semantic graph; Obtain the software source code, perform code analysis and multi-dimensional feature extraction to obtain a code semantic feature map; Semantic similarity calculation and graph alignment are performed based on the requirement semantic graph and the code semantic feature graph to obtain the requirement-code mapping relationship; Obtain historical test case data, combine it with the requirement code mapping relationship to perform entity linking and association analysis, and obtain the test knowledge graph; Based on the test knowledge graph, test scenarios are identified and prioritized to obtain a test scenario priority list. Based on the test scenario priority list and test knowledge graph, test cases are generated to obtain a test case set. The test case set is evaluated for quality, redundant test cases are removed and missing test cases are added to obtain an optimized test case set; Based on the optimized test case set, the performance of test cases is evaluated from multiple dimensions and continuously optimized to obtain an updated test case generation strategy.

2. The adaptive generation method for software test cases based on an AI model according to claim 1, characterized in that, The process of performing semantic parsing and structured representation of requirements includes: Perform format checks on the original requirements document, identify the document type, call the corresponding text extraction tool, extract the plain text content in the document, and remove non-requirement description content; A bidirectional transformer model is used to perform deep semantic encoding on the requirement sentence, and a self-attention mechanism is used to capture the semantic dependencies between words in the sentence to obtain the semantic vector of the requirement sentence. A named entity recognition model is used to identify business entities and their type tags in the requirements. Entity types include functional modules, business objects, operation actions, data attributes, and constraints. A relation extraction model is used to obtain semantic relation triples between entities. The relation types include call relations, data flow relations, constraint relations, and dependency relations. Each demand entity is treated as a node in the graph, and relation triples are transformed into directed edges in the graph to construct a demand semantic graph.

3. The adaptive generation method for software test cases based on an AI model according to claim 1, characterized in that, The code analysis and multidimensional feature extraction include: Obtain the software source code, select the appropriate parser tool for different programming languages, input the code file into the parser, and build an abstract syntax tree; For each function in the abstract syntax tree, analyze the execution order of statements and control transfer within the function body to obtain a control flow graph; Traverse the nodes of the control flow graph, identify the definition and usage of variables in each node, use reach-definition analysis to establish the mapping relationship from definition to usage, and construct a data dependency graph of variables; Scan the function call statements in the code, identify the names of the called functions and the call locations, and build a call relationship graph between services; By merging and integrating the control flow graph, data dependency graph, and call relationship graph, a unified code semantic feature graph is obtained.

4. The adaptive generation method for software test cases based on an AI model according to claim 1, characterized in that, The steps for obtaining the test knowledge graph include: The requirement entities and code elements are encoded using a pre-trained language model, cosine similarity is calculated, and a graph alignment algorithm is used to obtain the requirement code mapping relationship. Extract historical test cases, parse the text to obtain a structured test case representation, and establish links between test cases and requirement nodes and code nodes; By integrating requirement nodes, code nodes, test case nodes, and defect nodes into the same graph structure, a test knowledge graph is obtained.

5. The adaptive generation method for software test cases based on an AI model according to claim 1, characterized in that, The steps for obtaining the test scenario priority list include: Using the requirement node corresponding to the target requirement as the seed node, multi-hop neighbor expansion is performed in the test knowledge graph to obtain the task-related subgraph. The task-related subgraph is input into the graph neural network model. Through multiple graph convolutional layers or graph attention layers, the nodes update their own feature representation by aggregating the features of their neighbors, resulting in a set of node embedding vectors. Filter the nodes related to the test in the task-related subgraph, extract the embedding vectors of these nodes, and use a clustering algorithm to group the nodes, with each cluster representing a test scenario; For each test scenario, the number of historical defects associated with code nodes within the scenario is counted, the complexity index of the code involved in the scenario is calculated, a risk scoring model is established, and the test scenarios are sorted in descending order according to the risk score.

6. The adaptive generation method for software test cases based on an AI model according to claim 1, characterized in that, The generated test cases include: Extract the node embedding vectors of the test scene and aggregate them to obtain a set of scene feature vectors; Select an appropriate test template, fill in the scenario requirement description, and form a test case framework set; The set of scene feature vectors is used as input to the sequence-to-sequence model, and a set of test step sequences is generated using a constraint decoding strategy. Parameter constraints are obtained from the code semantic feature map, and a test data set is generated using a constraint solver. The application of business rules inference and prediction system outputs the expected result set; Transform test steps, test data, and expected results into a set of executable test cases.

7. The adaptive generation method for software test cases based on an AI model according to claim 1, characterized in that, The steps to obtain the optimized test case set include: Configure the test execution environment, execute the test case set in batches, collect coverage information through code instrumentation, and build a coverage matrix. Count the number of code units exclusively covered by each test case, calculate the importance weight of the code units covered by the test case, and obtain a set of contribution scores. Calculate the coverage similarity between test cases, compare the coverage contribution and execution time of test case pairs, and filter them to obtain a simplified set of test cases; Analyze the coverage matrix to identify lines of code and branches not covered by any test cases, perform path condition analysis on the uncovered code branches, and generate a supplementary set of test cases. The supplementary test case set is added to the simplified test case set to obtain the optimized test case set.

8. The adaptive generation method for software test cases based on an AI model according to claim 1, characterized in that, The steps for obtaining the updated test case generation strategy include: Collect data during test execution, calculate the performance score for each test case, aggregate the performance scores of the test cases to the test scenario level, and generate a test performance evaluation report. The test case generation process is modeled as a Markov decision process, a policy network is constructed, the policy network is trained, and a policy optimization model is obtained. Collect test execution data from historical projects, construct an offline dataset, and use an offline reinforcement learning algorithm to learn policies from the offline data to obtain a pre-trained policy model; The actions output by the strategy optimization model are mapped to the test case generation model, and the test case generation model is retrained using new test feedback data to obtain an updated test case generation model. Establish a real-time collection pipeline for test feedback data, use incremental learning algorithms to update the model, and obtain an updated test case generation strategy.

9. The adaptive generation method for software test cases based on an AI model according to claim 2, characterized in that, The process of performing semantic parsing and structured representation of requirements also includes: Semantic role labeling and rule template matching are used to identify semantic phrases, extract entities and numerical ranges from constraints, and represent constraints as structured expressions containing constraint variables, operators and constraint values. Perform topological sorting and hierarchical partitioning on the demand semantic graph, assign a unique identifier to each node in the graph, and establish a node index.

10. An adaptive software test case generation system based on an AI model, characterized in that, An adaptive software test case generation method based on an AI model, as described in any one of claims 1-9, comprises: The requirements parsing module is used to obtain the original requirements document, perform requirements semantic parsing and structured representation, and obtain the requirements semantic graph. The code analysis module is used to acquire software source code, perform code analysis and multi-dimensional feature extraction, and obtain a code semantic feature map. The knowledge graph construction module performs semantic similarity calculation and graph alignment based on the requirement semantic graph and the code semantic feature graph to obtain the requirement-code mapping relationship; it acquires historical test case data and performs entity linking and association analysis in combination with the requirement-code mapping relationship to obtain the test knowledge graph; The scene recognition module, based on the test knowledge graph, identifies test scenes and prioritizes them to obtain a test scene priority list. The test case generation module generates test cases based on the test scenario priority list and the test knowledge graph, resulting in a test case set. The test case optimization module is used to perform quality assessment on the test case set, remove redundant test cases and add missing test cases to obtain an optimized test case set; The strategy update module evaluates the performance of test cases from multiple dimensions and continuously optimizes them based on the optimized test case set, resulting in an updated test case generation strategy.

Images