Method and system for automatically generating requirement-driven test cases based on semantic test graph

Abstract

The application relates to the technical field of software test automation, and provides a requirement-driven test case automatic generation method and system based on a semantic test graph, which comprises the following steps: performing multidimensional static analysis on source code, respectively constructing an abstract syntax tree, a control flow graph and a function call graph, and extracting function call relations and data flow dependency relations; taking a function as a node, taking a function call relation as a main edge, and taking a data flow dependency relation as an auxiliary edge to construct a semantic test graph; aggregating function nodes in the semantic test graph into a plurality of function modules; obtaining a plurality of test requirement nodes, calculating semantic similarity between the test requirement nodes and the function modules, establishing a mapping relation from the test requirement nodes to the function modules, and forming a requirement-program structure association graph; based on the requirement-program structure association graph, generating a test intention for each test requirement node, and converting the test intention into an executable test case. The highly corresponding relation between the generated test case and the business requirement is ensured.

Description

Technical Field

[0001] This invention belongs to the field of software test automation technology, and in particular relates to a method and system for automatically generating requirement-driven test cases based on semantic test graphs. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] As software systems continue to grow in size and complexity, software testing plays an increasingly crucial role in ensuring software quality. Software testing typically accounts for 40% to 60% of the total cost of the software development cycle, with test case design and execution consuming a significant amount of time and effort from test engineers. Currently, the industry widely recognizes automated testing as one of the effective ways to address these issues.

[0004] Existing automated testing methods can be mainly divided into the following categories: The first category is code coverage-based test generation methods, such as Search-Based Software Testing (SBST) and symbolic execution-based test generation methods. These methods can systematically explore program execution paths, but their goal is to maximize code coverage rather than verifying whether the software meets business requirements, resulting in a significant semantic gap between the generated test cases and actual business scenarios. The second category is model-based test generation methods. These methods rely on pre-established system behavior models. As the software scales, the cost of manually building and maintaining these models becomes extremely high, limiting their practical application. The third category is large language model-based test generation methods. While these methods can understand natural language requirements, the stability and interpretability of the generated test code are insufficient, making it difficult to guarantee a precise correspondence between test intent and specific program implementation.

[0005] The above methods generally have the following shortcomings: On the one hand, the test generation process is disconnected from the software requirements document, which cannot guarantee that the generated test cases can effectively verify the core business functions of the system; on the other hand, when analyzing the program structure, existing methods usually only consider information in a single dimension (such as only considering control flow or only considering call relationships), ignoring the synergistic effect between function call relationships and data flow dependencies, resulting in inaccurate identification of functional modules, which in turn affects the quality of the association between test cases and requirements. Summary of the Invention

[0006] To address the technical problems mentioned above, this invention provides a method and system for automatically generating requirement-driven test cases based on semantic test graphs. By constructing a semantic test graph that integrates multi-dimensional program structure information, it can comprehensively and accurately depict the functional relationships between functions, improving the accuracy of functional module identification. On this basis, a semantic mapping relationship between requirement nodes and functional modules is established, ensuring a high degree of correspondence between generated test cases and business requirements, thereby automatically generating executable test cases that are highly related to business requirements.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: The first aspect of the present invention provides a method for automatically generating requirement-driven test cases based on semantic test graphs, comprising: Obtain the source code of the software under test, perform multidimensional static analysis on the source code, construct abstract syntax tree, control flow graph and function call graph respectively, and extract function call relationship and data flow dependency relationship; Construct a semantic test graph with functions as nodes, function call relationships as main edges, and data flow dependencies as auxiliary edges; The graph community discovery algorithm is applied to the semantic test graph to aggregate the function nodes in the semantic test graph into several functional modules; Obtain several test requirement nodes, calculate the semantic similarity between the test requirement nodes and each functional module, establish the mapping relationship between the test requirement nodes and the functional modules, and form a requirement-program structure association graph. Based on the requirement-program structure association graph, test intents are generated for each test requirement node, and the test intents are transformed into executable test cases.

[0008] Furthermore, the step of obtaining the test requirement node includes: obtaining the test requirement document, performing dependency parsing on the test requirement document, extracting several test requirement nodes, and describing each test requirement node with a quadruple, which includes operation, target object, constraint condition and expected output.

[0009] Furthermore, the multidimensional static analysis includes: Perform syntax analysis on the source code to generate an abstract syntax tree for each function; Based on the abstract syntax tree, the function body is divided into basic blocks, with the function's start statement as the entry node and the function's return statement or the end of the method body as the exit node. Sequence, branching, looping, and exception handling statements are used as the basis for control transfer. The statements in each basic block are executed sequentially, and the control transfer between basic blocks is represented by directed edges, thus obtaining the control flow graph of each function. Traverse the control flow graph of all functions, identify the method call expression in each function body, extract the call relationship triplet between the caller function and the called function, and construct a global function call graph; Perform data flow analysis within each function, construct variable definition-use chains within the function, and identify data flow dependencies between functions through parameter passing, return values, and global variables.

[0010] Furthermore, the weight of the main edge is determined based on the frequency of function calls.

[0011] Furthermore, the weight of the auxiliary edge is: weight(e_data)=n_shared / (n_total_fi+n_total_fj-n_shared); where n_shared is the number of variables shared between function fi and function fj, and n_total_fi and n_total_fj are the total number of variables of function fi and function fj, respectively.

[0012] Furthermore, the graph community discovery algorithm discovers the community structure in the semantic test graph by iteratively optimizing the modularity function Q, and the modularity function is defined as: Q=(1 / 2m)×Σ[Aij-ki×kj / (2m)]×δ(ci,cj); where Aij is the edge weight between nodes vi and vj in the comprehensive adjacency matrix, the comprehensive adjacency matrix W=α×W_call+(1-α)×W_data, α is the scaling factor, W_call is the weight matrix of the main edge, W_data is the weight matrix of the auxiliary edge; ki is the weighted degree of node vi; m is the sum of all edge weights; ci is the community to which node vi belongs; δ(ci,cj) is the Kronecker function.

[0013] Furthermore, the step of aggregating the function nodes in the semantic test graph into several functional modules includes: performing a graph community detection algorithm on the semantic test graph to obtain several initial functional modules; and performing the following optimization operations on the several initial functional modules: Merging operation: For function pairs from different initial functional modules, if the cross-function data flow dependency density exceeds the first threshold, the initial functional modules containing the function pairs will be merged into the same functional module. Splitting operation: For a pair of functions within the same initial functional module, if the weights of the main edge and the auxiliary edge are both lower than the second threshold, and the cosine similarity of the semantic vectors of the two functions is lower than the third threshold, then the two are split into different functional modules. Verification: Recalculate the cohesion and coupling indices for each functional module. If the cohesion and coupling indices do not meet the constraints, perform a further splitting process on the functional module until all functional modules meet the constraints.

[0014] Furthermore, generating test intents for each test requirement node includes: For each test requirement node, find the associated functional modules in the requirement-program structure relationship graph, perform a depth-first search, enumerate all candidate paths from the entry function to the exit function of the functional module, and select the multiple candidate paths with the highest scores as the test path set; Test intents are generated based on test requirement nodes and test path sets.

[0015] Furthermore, the process of translating test intent into executable test cases includes: Based on the constraints in the test intent and the input parameter type constraints of each function in the test path, generate the test input data: Combine test intent, test input data, and expected output to generate executable test cases.

[0016] A second aspect of the present invention provides a requirement-driven test case automatic generation system based on semantic test graphs, comprising: The program analysis module is configured to: acquire the source code of the software under test, perform multi-dimensional static analysis on the source code, construct abstract syntax trees, control flow graphs and function call graphs respectively, and extract function call relationships and data flow dependencies; The semantic test graph construction module is configured to construct a semantic test graph with functions as nodes, function call relationships as main edges, and data flow dependencies as auxiliary edges. The functional clustering module is configured to perform a graph community discovery algorithm on the semantic test graph and aggregate the function nodes in the semantic test graph into several functional modules. The mapping and association module is configured to: acquire several test requirement nodes, calculate the semantic similarity between the test requirement nodes and each functional module, establish the mapping relationship from the test requirement nodes to the functional modules, and form a requirement-program structure association graph. The test generation module is configured to generate test intents for each test requirement node based on the requirement-program structure association graph, and then convert the test intents into executable test cases.

[0017] Compared with the prior art, the beneficial effects of the present invention are: This invention constructs a semantic test graph that integrates multi-dimensional program structure information, which can comprehensively and accurately depict the functional relationships between functions and improve the accuracy of functional module identification. On this basis, a semantic mapping relationship between requirement nodes and functional modules is established, ensuring a high degree of correspondence between generated test cases and business requirements, thereby automatically generating executable test cases that are highly related to business requirements. Attached Figure Description

[0018] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0019] Figure 1 This is a flowchart of the requirement-driven test case automatic generation method based on semantic test graphs according to Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of multidimensional static analysis according to Embodiment 1 of the present invention; Figure 3 This is an STG diagram of Embodiment 1 of the present invention; Figure 4 This is a schematic diagram of the node attribute structure of Embodiment 1 of the present invention; Figure 5 This is a schematic diagram of the functional module division of Embodiment 1 of the present invention; Figure 6 This is a requirement-program structure mapping diagram of Embodiment 1 of the present invention; Figure 7 This is a schematic diagram of the test case code for Embodiment 1 of the present invention; Figure 8 This is a framework diagram of the requirement-driven test case automatic generation system based on semantic test graphs according to Embodiment 2 of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings.

[0021] It should be noted that the following detailed description is illustrative and intended to provide further explanation of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0022] Terminology Explanation: A semantic test graph (STG) is a directed weighted graph with software functions as nodes, function call relationships and data flow dependencies as edges, and function semantic vector attributes attached to the nodes. It is used to comprehensively express the structural associations and functional semantic relationships between functions in a software system.

[0023] Requirement Node (NR): This refers to the four-tuple representation NR=(Action, Object, Constraint, ExpectedResult) obtained after structured parsing of a single atomic requirement description in a software requirements document. Here, Action is the core action of the requirement description, Object is the target object of the operation, Constraint is the constraint condition, and ExpectedResult is the expected result.

[0024] Functional Module (FM): refers to a subgraph formed by aggregating semantically related function nodes after the STG execution graph community discovery algorithm is refined by data flow. Each functional module corresponds to a cohesive functional unit of the software under test, satisfying the principle of high cohesion and low coupling.

[0025] Requirement Graph (RG): This refers to a bipartite graph constructed by using a set of structured requirement nodes and a set of functional modules as node sets, and using the semantic similarity association between requirement nodes and functional modules as edges. It supports querying related functional modules starting from requirements, or querying related requirements starting from functional modules.

[0026] Definition-Use Chain (DU_Chain): In data flow analysis, this refers to the set of all execution paths of a variable from its assignment (definition) location to its read (use) location. It is used to characterize the propagation relationship of variable values ​​within and between functions.

[0027] Example 1 This embodiment provides a method for automatically generating requirement-driven test cases based on semantic test graphs.

[0028] The requirement-driven test case automatic generation method based on semantic test graphs provided in this embodiment can integrate software requirement semantics with multi-dimensional program structure information, automatically construct precise associations between requirements and program functional modules, and generate high-quality test cases accordingly.

[0029] The requirement-driven test case automatic generation method based on semantic test graphs provided in this embodiment constructs a semantic test graph that integrates function call relationships and data flow dependencies, and uses a graph community discovery algorithm to cluster functional modules, establishing a precise mapping relationship between requirement semantics and program structure. This automatically generates executable test cases that are highly relevant to business requirements, significantly reducing test case design costs and improving the requirement coverage and test quality of software testing.

[0030] To address the shortcomings of existing test case generation methods, such as insufficient semantic understanding of requirements, uninterpretable test intents, and numerous redundant paths, this embodiment proposes the following technical solution: First, semantic parsing is performed on the software requirements document, structuring the requirement information into a four-tuple of requirement nodes containing actions, objects, constraints, and expected results. Second, multi-dimensional static analysis is performed on the source code to construct a syntax tree, control flow graph, and function call graph, extracting definition-usage chains. Based on this, a semantic test graph (STG) is constructed using functions as nodes and call relationships and data flow dependencies as edges. The Louvain graph community discovery algorithm, combined with data flow refinement, aggregates STG nodes into functional modules. Then, a bidirectional mapping from requirement nodes to functional modules is established through semantic similarity calculation, constructing a requirement-program structure association graph. Finally, structured test intents are generated based on the path information in the association graph, and these test intents are transformed into executable test cases. This achieves requirement-driven, end-to-end automated test case generation, significantly improving test coverage, interpretability, and generation efficiency.

[0031] The method for automatically generating requirement-driven test cases based on semantic test graphs provided in this embodiment is as follows: Figure 1 As shown, taking a user authentication module written in Java (including login, registration, and password reset functions) as an example, the complete steps are described.

[0032] Step S1: Semantic parsing of requirements documents and construction of requirements nodes.

[0033] Input the test requirements document (PRD) of the system under test, perform semantic parsing on the natural language descriptions in the requirements document, and output a structured set of requirement nodes NR_Set.

[0034] Step 1-1: Requirements document preprocessing.

[0035] The PRD document is formatted and segmented according to requirement number, function name, and requirement description, with each requirement description extracted as an independent text unit. For requirement documents with mixed Chinese and English, language recognition is performed first, followed by lexical analysis of the Chinese and English parts separately. The requirement description text is then segmented into sentences, using periods, semicolons, and other sentence breakpoints as boundaries to break down complex requirement descriptions into multiple atomic requirement descriptions, each representing an independent functional point or verification point.

[0036] Step 1-2: Parse the quadruple of the requirement node.

[0037] For each atomic requirement description, perform dependency parsing to identify subject-verb-object structures and conditional clauses, and extract the quadruple (Action, Object, Constraint, ExpectedResult) according to the following rules: Step (1-2-1), Action (core operation of the requirement description) extraction: Extract the core verb and its direct object verb from the predicate verb phrase of the requirement description, as the Action value. For example, for the requirement description "[Users log in to the system with the correct username and password]", the Action is "[Log in]". Step (1-2-2), Object (target object of operation) extraction: Extract the target entity from the subject noun phrase or direct object noun phrase in the requirement description, and use it as the Object value. In the example above, Object is [System] or [User Account]. Step (1-2-3), Constraint (precondition or constraint) extraction: Identify conditional clauses (containing patterns such as "when," "if," "under the condition") and constraint expressions such as quantity limits and time limits in the requirement description, and use them as Constraint values. In the example above, Constraint is "Use the correct username and password." Step (1-2-4), ExpectedResult (expected output or state change) extraction: Identify the descriptive fragments in the requirement description that represent the expected state change or output (usually followed by keywords such as "should," "must," "return," etc.), and use them as the ExpectedResult value. In the example above, ExpectedResult is "The system returned a login success response, and the user entered the homepage."

[0038] Taking the requirements document for the user authentication module as an example, the following are some of the requirements nodes obtained after parsing: NR1=(Action=Login, Object=User account, Constraint=Username and password are correct, ExpectedResult=Return 200 status code and generate Session); NR2=(Action=Login,Object=User account,Constraint=Incorrect username or password,ExpectedResult=Returns 401 status code and displays error message); NR3=(Action=Register,Object=New User Account,Constraint=Valid email address and not already registered,ExpectedResult=Account created successfully and verification email sent); NR4=(Action=Reset Password, Object=User Password, Constraint=User Provides Valid Reset Token, ExpectedResult=Password Update Successful and Invalidates All Old Sessions).

[0039] Here, Session refers to a continuous, stateful communication process between a client and a server (or two systems); Token refers to a token / credential.

[0040] Steps 1-3: Deduplication and hierarchical organization of demand nodes.

[0041] The set of requirement nodes obtained from steps 1-2 is deduplicated, merging semantically similar redundant requirement nodes. Based on the functional groupings in the requirement document (e.g., [Login Function], [Registration Function], etc.), a parent-child hierarchical relationship is constructed between requirement nodes. For each requirement node, a semantic vector v_NR is generated using a pre-trained language model (e.g., Bidirectional Encoder Representations from Transformers (BERT) or its Chinese variant), which is used for subsequent similarity calculations with functional modules.

[0042] Step S2: Multidimensional static analysis of source code and extraction of program structure.

[0043] like Figure 2 As shown, the source code of the software project under test is input, and multidimensional static analysis is performed on the source code to construct an abstract syntax tree (AST), a control flow graph (CFG), and a function call graph (CG), and extract the call relationships between functions and data flow dependency information.

[0044] Step 2-1: Construction of Abstract Syntax Tree (AST).

[0045] Using Java source code analysis tools, each source code file (.java file) in the project is subjected to syntax analysis to generate an Abstract Syntax Tree (AST) for each function.

[0046] Extract the following information from the AST: (a) A list of functions (methods), including the method name, class name, access modifier, parameter list (parameter name and parameter type), and return type; (b) Local variable declarations and assignment statements within the method body; (c) The method call expression contained within the method, including the name of the called method and the call parameters; (d) The method's comment text (Javadoc) (if it exists).

[0047] Taking the AuthService class in the user authentication module (a service class responsible for handling user login, registration, and other logic) as an example, AST analysis can identify the following list of functions: login(String username, String password) (login method (username, password)), register(UserDTO userDTO) (registration method (a DTO object encapsulating user information)), resetPassword(String token, String newPassword) (reset password (first verify identity with the token, then pass in the new password)), validateToken(String token) (validate token validity (token string)), sendVerificationEmail(String email) (send verification email (email address), etc.

[0048] Step 2-2: Control Flow Graph (CFG) Construction.

[0049] Based on the ASTs of each function in step 2-1, construct an independent Control Flow Graph (CFG) for each function. Using the function's initial statement as the entry node and the function's return statement or the end of the method body as the exit node, and using sequential, branching (if-else, switch), looping (for, while, do-while), and exception handling (try-catch-finally) statements as the basis for control transfer, divide the function body into basic blocks. Statements within each basic block are executed sequentially, and directed edges represent control transfers between basic blocks. For example, the CFG of the `login` function includes: entry node → parameter validation basic block → database query basic block → (branch: user exists?) → password verification basic block → (branch: password matches?) → session generation basic block → exit node (success path); as well as exception branches such as parameter validation failure path and password error path.

[0050] Steps 2-3: Constructing the Call Graph.

[0051] Traverse the AST of all functions, identify the method call expression within each function body, extract the call relationship triples (caller, callee, line number) between the caller and the called function, and construct a global function call graph (Call Graph). In this graph, nodes represent all functions in the project, and directed edges (fi→fj) indicate that function fi calls function fj. For polymorphic calls (interface method calls), use the Class Hierarchy Analysis (CHA) algorithm to parse the actual called implementation class method to handle interfaces and inheritance relationships in Java.

[0052] Taking the user authentication module as an example, the Call Graph contains the following typical call relationships: login→validateUser (login→verify user information), login→generateSession (login→generate session), login→logLoginAttempt (login→record login log); register→validateEmail (register→verify email format), register→hashPassword (register→hash password), register→saveUser (register→save user information to database), register→sendVerificationEmail (register→send verification email); resetPassword→validateToken (reset password→verify user token), resetPassword→updatePassword (reset password→update password in database), resetPassword→invalidateAllSessions (reset password→invalidate all old sessions of the user), etc.

[0053] Steps 2-4: Data Flow Analysis and Definition - Building with Chains.

[0054] For each function, data flow analysis is performed. Using the Reaching Definition algorithm, the definition set of each variable at each program point is calculated, and a variable definition-use chain (DU_Chain) is constructed within the function. Specifically, for each assignment statement (variable definition point d) and each variable read statement (variable use point u) within the function, if there exists an execution path from d to u without other redefinitions, then a DU chain (d, u) is established.

[0055] Furthermore, identify the data transfer relationships (data flow dependencies) between functions: (a) Parameter passing: If function fi calls function fj with variable v as an actual parameter, then a cross-function DU association is established from the variable definition point of fi to the corresponding formal parameter of fj; (b) Return value passing: If function fi calls function fj and receives its return value and assigns it to variable v, then a cross-function DU association is established from the return statement of fj to the point where variable v of fi is used; (c) Shared State: Identify state sharing between functions through class member variables and record the read and write operations of related functions on shared variables.

[0056] All data flow dependencies between functions are aggregated to form a cross-function data flow dependency set DF_Set.

[0057] like Figure 2 The code shown is defined and used as follows: Definition: The point where a variable is first assigned a value. For example, in the code, String token = genToken(user); is the point where token is defined. Use: The place where a variable is read, used in calculations, or passed as a parameter, such as the use of token in validate(token) and session.create(user,token).

[0058] In this context, token represents a token / temporary credential, String represents a string type, genToken(user) represents generating a token based on user information, validate represents verification, if represents an if statement, session.create(user,token) represents creating a login session for the current user and saving the user and token, and user represents the user object / user information.

[0059] Step S3: Semantic Test Graph (STG) Construction.

[0060] Based on the function information, call relationships, and data flow dependencies extracted in step S2, a semantic test graph STG=(V,E_call∪E_data) is constructed, as follows: Figure 3 As shown, V represents the set of nodes; E_call represents the set of function call edges; and E_data represents the set of data flow dependency edges.

[0061] like Figure 3 The semantic test graph shown can be described as follows: Entry point function node: The login function login() is triggered, initiating the login process; The internal function nodes are executed in parallel. The login() function calls three core branches simultaneously: validateUser(): responsible for user authentication; logAttempt(): logs login attempts; generateSession(): generates a user session. Verification branch details: validateUser() internally calls hashCheck() (password hash verification function) and dbQuery() (database query user information function); Data sharing: The query results of dbQuery() and the session data stored by sessionStore() (session storage function) ultimately flow to the general utility function utils() for further processing (such as data formatting, encryption, etc.).

[0062] Step 3-1: STG node construction and semantic vector generation.

[0063] Each callable function in the project under test is treated as a node vi∈V in the STG; an attribute vector is assigned to each node vi, such as Figure 4 As shown, it includes: function name identifier name(vi) (e.g., login function); function class name class(vi) (e.g., authentication service class AuthService); function input parameter type list params(vi) (e.g., string type String) and return value type ret(vi) (e.g., login response LoginResponse); function semantic vector sem(vi) (e.g., CodeBERT 512-dimensional semantic vector, [0.23, -0.71, ...]).

[0064] The method for constructing the function semantic vector is as follows: the camelCase naming of the function name (e.g., getUserById (get user information based on user ID) is split into get (get), user (user), by (based on), id (identifier)) and the function comment text (Javadoc) are concatenated and input into a pre-trained language model (CodeBERT or sentence-transformers) for encoding to generate a 512-dimensional semantic vector.

[0065] Step 3-2: Call edge construction.

[0066] Based on the Call Graph in steps 2-3, for each call relationship (fi, fj), a directed call edge e_call (vi→vj) is added to the STG, where vi and vj are the STG nodes corresponding to fi and fj, respectively. The initial weight of the call edge e_call is set to 1.0. If function fi calls function fj in multiple places, the weight of the corresponding call edge is increased by 0.2 to reflect the impact of call frequency on the strength of functional association.

[0067] Step 3-3: Data flow edge construction.

[0068] Based on the cross-function data flow dependency set DF_Set from steps 2-4, for function pairs (fi, fj) with data flow dependencies, add a data flow edge e_data(vi, vj) (undirected edge, reflecting bidirectional data association) to the STG. The weight of the data flow edge e_data is calculated according to the following formula: weight(e_data)=n_shared / (n_total_fi+n_total_fj-n_shared); Where n_shared is the number of variables shared between fi and fj, and n_total_fi and n_total_fj are the total number of variables in fi and fj, respectively.

[0069] Steps 3-4: STG connectivity processing and integrity verification.

[0070] Connectivity analysis is performed on the constructed STG to identify isolated nodes (i.e., nodes that are not connected to other nodes by any call edges or data flow edges). For isolated nodes, the cosine similarity between their semantic vectors and the semantic vectors of other nodes is calculated. If the similarity exceeds the threshold θ_sem (default value is 0.7), a semantically similar edge e_sem is added to maintain the overall connectivity of the STG. Finally, the complete semantic test graph STG is output, recording the total number of nodes |V| and the total number of edges |E|.

[0071] Step S4: Clustering and Refinement of Functional Modules.

[0072] The Semantic Test Graph (STG) execution graph community discovery algorithm divides the function nodes in the STG into several functional modules, and refines the clustering results by combining data flow analysis to obtain a set of functional modules FM_Set that satisfies the constraints of high cohesion and low coupling, such as... Figure 5 As shown.

[0073] Step 4-1: Merge the adjacency matrix.

[0074] The STG call edge adjacency matrix W_call and data flow edge adjacency matrix W_data are normalized, with each matrix row-wise normalized to the [0,1] interval. Then, they are weighted and fused using a scaling factor α (default value 0.7) and (1-α) to obtain the comprehensive adjacency matrix W = α × W_call + (1-α) × W_data. The comprehensive adjacency matrix W takes into account both the call intensity and data sharing degree between functions and serves as the input for the subsequent community detection algorithm.

[0075] The proportionality coefficient can be determined by the following formula: α = (w1·w2) / (w1·w2+w3); Where w1 is the type coefficient of the software under test; if the software under test is a business system, the value is 0.7; if the software under test is a data system, the value is 0.3. The call relationship density is w2 = 2·Ecall / (N·(N 1)), Ecall is the total number of call edges (main edges) in the semantic test graph, and N is the total number of function nodes in the STG; data flow dependency strength weight(e) is the weight of the e-th data flow edge, and Edata is the set of data flow edges in the semantic test graph STG.

[0076] By adaptively calculating the proportional coefficient α through formulas, the system characteristics of both services and data can be dynamically adapted. According to the call relationship density and data flow dependency strength, the weights of call edges and data flow edges in the semantic test graph are automatically balanced, enabling the Louvain community discovery algorithm to consider both structural and data associations simultaneously, thereby more accurately partitioning functional modules and improving the matching degree between subsequent test case generation and business requirements.

[0077] Step 4-2: Louvain graph community discovery.

[0078] As Figure 5 shown, the Louvain community discovery algorithm is executed on the comprehensive adjacency matrix W.

[0079] The Louvain algorithm discovers the community structure in the graph by iteratively optimizing the modularity function Q, and the modularity function Q is defined as: Q=(1 / (2m))×Σ[Aij-ki×kj / (2m)]×δ(ci,cj); where Aij is the edge weight between nodes vi and vj in the comprehensive adjacency matrix W, ki is the weighted degree of node vi, ki = Σ j Aij; m is the sum of all edge weights, ci is the community to which node vi belongs, and δ(ci,cj) is the Kronecker function (taking 1 when ci = cj, otherwise taking 0).

[0080] The Louvain algorithm is executed alternately in two stages: The first stage (modularity optimization): For each node, try to move it to the community where its neighbor nodes are located, calculate the modularity gain ΔQ, and select the move that maximizes ΔQ until the modularity cannot be improved by node movement; The second stage (community aggregation): Each community is shrunk into a supernode, the edges between nodes within the community are transformed into self-loops, and the edge weight between communities is the sum of the edge weights between each node. Repeat the first stage on the new graph. The two stages are iteratively executed until the modularity converges, and the final community partitioning result is output. Each community corresponds to an initial functional module.

[0081] Step 4-3: Clustering refinement based on data flow.

[0082] For the initial functional modules output by the Louvain algorithm, fuse the DU chains and perform the following refinement operations: Step (4-3-1) Merge operation: For function pairs (fi,fj) from different communities (i.e., different initial functional modules), if the cross-function data flow dependency density between them (i.e., the ratio of the number of DU chains between the two functions to the total number of variables of the two functions) exceeds the threshold θ_merge (default value 0.3), then merge the initial functional modules where fi and fj are located into the same functional module; Step (4-3-2) Splitting operation: For a function pair (fi,fj) within the same community, if the weight of the calling edge and the weight of the data flow edge are both lower than the threshold θ_split (default value 0.1), and the cosine similarity of the semantic vectors of the two functions is lower than θ_sem, then the two will be split into different functional modules. Step (4-3-3) Refinement Verification: After the refinement operation, recalculate the cohesion index cohesion(FM_k) = (sum of weights of internal edges of the module) / (sum of weights of the maximum possible internal edges of the module) and the coupling index coupling(FM_k) = (sum of weights of external edges of the module) / (total degree of the module) for each functional module. If cohesion(FM_k) < upper limit θ_cohesion (default value 0.5) or coupling(FM_k) > lower limit θ_coupling (default value 0.4), then perform a re-splitting process on the corresponding functional module until all functional modules satisfy the constraints.

[0083] Taking the user authentication module as an example, after clustering and refinement, the following functional modules can be obtained: FM1 (Login Authentication Module): includes functions such as login, validateUser, generateSession, and logLoginAttempt; FM2 (Registration Management Module): includes functions such as register, validateEmail, hashPassword, saveUser, and sendVerificationEmail; FM3 (Password Reset Module): includes functions such as resetPassword, validateToken, updatePassword, invalidateAllSessions; FM4 (Basic Utility Module): includes utility functions shared by all functions, such as database connection (dbConnect), log recording (logRecord), encryption function (encrypt), and token generation function (tokenGen).

[0084] Step S5: Construct the requirement-program structure mapping relationship graph.

[0085] like Figure 6As shown, based on the set of demand nodes NR_Set in step S1 and the set of functional modules FM_Set in step S4, a mapping relationship between the two is established through semantic similarity calculation, and a bidirectional demand-program structure association graph (hereinafter referred to as the demand-program structure association graph) RG is constructed.

[0086] Figure 6 The requirement node set includes: NR1: Login - Valid Credentials; NR2: Login - Incorrect Credentials; NR3: Registration - Valid Email Address; NR4: Password Reset - Valid Token; NR5: Password Reset - Invalid Token. The functional module set includes: FM1: Login Authentication Module; FM2: Registration Management Module; FM3: Password Reset Module; FM4: Basic Tools Module.

[0087] Step 5-1: Functional module semantic vector aggregation.

[0088] For each functional module FM_k in the functional module set FM_Set, the semantic vectors of all the function nodes contained therein are weighted averaged. The weight of the function node is determined by its PageRank value within the functional module (function nodes with higher PageRank values ​​are more core in the module and are given higher weights), resulting in the aggregate semantic vector v_FM_k of the functional module.

[0089] Step 5-2: Semantic similarity calculation and associated edge construction.

[0090] For each demand node NR_i in NR_Set, calculate the cosine similarity between its semantic vector v_NR_i and the aggregated semantic vector v_FM_k of each functional module FM_k in FM_Set: sim(NR_i,FM_k)=(v_NR_i·v_FM_k) / (||v_NR_i||×||v_FM_k||); When the similarity value sim(NR_i, FM_k) exceeds the preset threshold θ_sim (default value 0.6), an association edge from NR_i to FM_k is established in the bidirectional requirement-program structure association graph RG, with the edge weight set to the corresponding cosine similarity value. To ensure that each requirement node is associated with at least one functional module, if the similarity between a requirement node and all functional modules is lower than θ_sim, then the requirement node is associated with the functional module with the highest similarity, and a log warning is triggered.

[0091] Step 5-3: Bidirectional path verification.

[0092] Perform bidirectional path verification on the requirement-program structure association graph RG: Starting from the requirement node, verify whether the associated functional module can cover the expectedResult of the requirement (i.e., whether there is a function call path in the functional module that can produce the expected output); starting from the functional module, verify whether there is a corresponding requirement node associated with it (if a functional module has no requirement node associated with it, then the virtual requirement node is automatically inferred based on the semantics of the functional module in step S4).

[0093] Step S6: Test intent generation and test case output.

[0094] Based on the path information in the requirement-program structure association graph RG, test intents are generated for each requirement node, and the test intents are transformed into executable test cases, outputting the final test case set TC_Set.

[0095] Step 6-1: Critical path extraction.

[0096] For the requirement node NR_i and its associated functional module FM_k, a depth-first search (DFS) is performed on the subgraph corresponding to FM_k in the STG to enumerate all candidate paths from the entry function of FM_k (the function with an in-degree of 0 or the function with the highest external call frequency) to the exit function (the function containing operations related to ExpectedResult). The candidate paths are sorted by the path scoring function score(P), and the top K (default K=3) high-scoring paths are selected as the test path set TP(NR_i,FM_k).

[0097] Step 6-2: Test intent generation.

[0098] Based on the requirement node quadruple (Action, Object, Constraint, ExpectedResult) and the test path P=(f1→f2→...→fn), generate a test intent TI in natural language form, with the format: [Under the premise of satisfying Constraint, perform the Action operation on Object, call the function sequence [f1, f2, ..., fn] in sequence, and verify the system ExpectedResult].

[0099] Taking requirement node NR1 as an example, combined with the test path P=(login→validateUser→generateSession), the test intent TI1 is generated as follows: [Assuming the username and password are correct, perform a login operation on the user account, call the function sequence [login, validateUser, generateSession] in sequence, verify that the system returns a 200 status code and generates a Session].

[0100] Step 6-3: Test data is generated automatically.

[0101] Based on the Constraint information in the test intent TI and the input parameter type constraints of each function in the test path P, the following strategy is used to generate test input data: (a) For equivalence class boundaries in Constraint (e.g., [correct username and password]), generate positive and negative samples using equivalence class partitioning and boundary value analysis. (b) For string type parameters, generate meaningful test data based on the semantics of the parameter name (e.g., username can be set to [test_user_001], password can be set to [Valid@123]). (c) For object type parameters, an object instance that satisfies the constraints is automatically constructed based on the object's class definition.

[0102] Step 6-4: Test case code generation and verification.

[0103] The test intent (TI), test input data, and expected output are combined to generate executable Java test case code according to JUnit 5 format. The generated test cases include: @Test annotations and descriptive method names (e.g., test_Login_WithValidCredentials_ShouldReturnSuccessAndGenerateSession), test preconditions (mock object initialization in @BeforeEach methods), test steps (calling the function under test according to the function call sequence in function call path P), and assertion statements (verifying the consistency between actual output and ExpectedResult). The generated test case set TC_Set is deduplicated (based on both test path and input data deduplication), and the coverage of each requirement node and the function nodes in the STG is calculated. A coverage report is output, along with the final test case set TC_Set.

[0104] Taking the test intent TI1 corresponding to requirement node NR1 as an example, the generated JUnit 5 test case code is as follows: Figure 7 As shown.

[0105] In the absence of requirements documentation, existing methods are generally unable to infer functional semantics from the program structure itself and generate functional-level tests.

[0106] As one implementation method, when the requirement document is missing, if the input PRD requirement document is empty or incomplete, skip step S1, directly execute steps S2 and S3 to construct the STG, and execute step S4 to obtain the functional module set FM_Set. Subsequently, perform the following operations on each functional module FM_k in FM_Set: (a) collect the name identifiers (word sequences after splitting camelCase naming) and Javadoc comment text of all functions in FM_k; (b) concatenate the above text and input it into the pre-trained language model to generate the natural language functional description desc(FM_k) of FM_k; (c) parse desc(FM_k) into a virtual requirement node NR'_k, where Action extracts the core verb from the functional description, Object extracts the operation entity from the functional description, Constraint is set to the default value (such as [all legal inputs]), and ExpectedResult extracts the expected behavior description from the functional description; (d) replace the real requirement node in steps S5 and S6 with the virtual requirement node NR'_k, and continue to execute the subsequent process to complete the functional-level automated test generation.

[0107] As one implementation method, in the incremental update scenario, when the source code of the software under test is partially modified (such as modifying the password verification logic in the login function), the following incremental update process is executed: (a) Code change identification: By comparing the differences in the code version management system (Git), the set of functions that have changed ΔF={login} and the set of caller functions that directly call these functions (such as all functions that directly call login) are identified; (b) STG local update: Only the functions in ΔF and their direct callers are re-executed for the AST, CFG and data flow analysis in step S2, and the attributes and associated edges of the corresponding nodes in the STG are updated; (c) Local re-clustering: Local Louvain re-clustering is performed on the functional modules containing the changed functions. If the change in module degree Q exceeds the threshold ΔQ (default value 0.05), the module is re-divided; (d) Incremental update of test cases: For the requirement nodes associated with the functional modules affected by the change, step S6 is re-executed to generate updated test cases, replace the corresponding old test cases in TC_Set, and output the updated test case set.

[0108] To address the semantic gap between software requirements documents and source code, this embodiment provides a requirement-driven test case automatic generation method based on semantic test graphs. By constructing a semantic test graph (STG) that integrates function call relationships and data flow dependencies, it comprehensively and accurately depicts the functional relationships between functions, achieving a precise mapping from the natural language of requirements to the program structure. This fundamentally solves the bottleneck of insufficient semantic understanding in requirement-driven testing, and improves the accuracy of functional module identification and the requirement coverage of test cases.

[0109] To address the issues of insufficient interpretability and excessive redundant test paths in automatically generated test cases, this embodiment provides a requirement-driven test case automatic generation method based on semantic test graphs. It proposes an intermediate-layer abstraction mechanism based on test intent, combining the requirement node quadruple (Action, Object, Constraint, ExpectedResult) with STG paths to generate structured test intents. These test intents then drive test data generation and test code output. Simultaneously, a dataflow refinement based on definition-use chains is introduced to optimize clustering results, and a path scoring function is used to filter high-value test paths, effectively reducing redundant test cases and resulting in a test case set with high accuracy, simplicity, and maintainability.

[0110] Compared to manually designing test cases, the requirement-driven test case automatic generation method based on semantic test graphs provided in this embodiment automatically completes the entire chain from requirements to executable test code through a two-layer abstraction mechanism of semantic test graphs and test intents. This changes the traditional software testing method that relies on test engineers to manually analyze requirements and code, freeing testers from being limited to reading large amounts of source code and manually writing test scripts. As a result, it significantly saves test case design costs and improves software test coverage and maintenance efficiency.

[0111] In summary, the requirement-driven test case automatic generation method based on semantic test graphs provided in this embodiment achieves the following: First, by constructing a semantic test graph (STG) that integrates multi-dimensional program structure information, it can comprehensively and accurately depict the functional relationships between functions, improving the accuracy of functional module identification. Second, by establishing a semantic mapping relationship between requirement nodes and functional modules, it ensures a high degree of correspondence between generated test cases and business requirements, effectively bridging the requirement-test gap problem of existing methods. Third, even when requirement documents are missing, it can still automatically infer functional descriptions based on program structure semantics and generate functional-level tests, improving the applicability of the method. Fourth, by introducing an incremental update mechanism, it can efficiently update the test case set when requirements or code change, reducing test maintenance costs.

[0112] Example 2 The requirement-driven test case automatic generation system based on semantic test graphs provided in this embodiment, such as... Figure 8 As shown, it includes: (1) Input layer: Input PRD requirements document, project source code, and configuration parameters.

[0113] (2) Core processing layer, including: The requirements parsing module receives software requirements documents, performs semantic parsing on the requirements documents, and structures the requirements information into requirement nodes containing actions, objects, constraints, and expected results, forming a structured set of requirement nodes; that is, it includes: a syntactic parser and a tuple extractor to parse the requirement text; requirement node vectorization: converting natural language requirements into vectors that machines can understand; and hierarchical relationship construction: sorting out the dependencies and hierarchical relationships between requirements. The program analysis module, including an AST parser, a CFG generator, a Call Graph builder, and a DU_Chain analyzer, is used to receive the source code of the software project under test, construct an Abstract Syntax Tree (AST), a Control Flow Graph (CFG), and a Function Call Graph (CallGraph), and extract function call relationships, control flow information, and data flow dependencies. The STG building module is used to construct a semantic test graph (STG) with functions as nodes, call relationships and data flow dependencies as edges, and function semantic labels. The functional clustering module is used to perform graph community discovery algorithm on the semantic test graph STG. It combines data flow definition and uses chains to refine the clustering results, aggregating semantically related function nodes into functional modules that meet the constraints of high cohesion and low coupling. The mapping and association module is used to calculate the semantic similarity between requirement nodes and functional modules, establish the mapping relationship from requirement nodes to functional modules, and construct the requirement-program structure association graph. The test generation module is used to generate test intents based on the path information in the requirements-program structure association graph, and to convert the test intents into executable test cases, outputting a set of test cases.

[0114] The STG building module includes a node attribute submodule, a call edge building submodule, a data flow edge building submodule, and a connectivity verification submodule.

[0115] The functional clustering module includes an adjacency matrix fusion submodule, a Louvain clustering submodule, a data flow refinement submodule, and an internal cohesion and coupling evaluation submodule.

[0116] The mapping and association module includes a semantic vector fusion submodule, a similarity calculation submodule, an association graph construction submodule, and a bidirectional path verification submodule.

[0117] The test generation module includes a critical path extraction submodule, a test intent generation submodule, a test data construction submodule, and a test case formatting submodule.

[0118] (3) Output layer, output: The test case set TC_Set, the requirement coverage report, and the automated test code in JUnit5 (Java's official standard automated testing tool) format.

[0119] It should be noted that each module in this embodiment corresponds one-to-one with each step in Embodiment 1, and their specific implementation processes are the same, so they will not be repeated here.

[0120] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for automatically generating requirement-driven test cases based on semantic test graphs, characterized in that: include: Obtain the source code of the software under test, perform multidimensional static analysis on the source code, construct abstract syntax tree, control flow graph and function call graph respectively, and extract function call relationship and data flow dependency relationship; Construct a semantic test graph with functions as nodes, function call relationships as main edges, and data flow dependencies as auxiliary edges; The graph community detection algorithm is applied to the semantic test graph to aggregate the function nodes in the semantic test graph into several functional modules. This includes: applying the graph community detection algorithm to the semantic test graph to obtain several initial functional modules; and performing the following optimization operations on these initial functional modules: Merging operation: For function pairs from different initial functional modules, if the cross-function data flow dependency density exceeds the first threshold, the initial functional modules containing the function pairs will be merged into the same functional module. Splitting operation: For a pair of functions within the same initial functional module, if the weights of the main edge and the auxiliary edge are both lower than the second threshold, and the cosine similarity of the semantic vectors of the two functions is lower than the third threshold, then the two are split into different functional modules. Verification: Recalculate the cohesion and coupling indices for each functional module. If the cohesion and coupling indices do not meet the constraints, perform a further splitting process on the functional module until all functional modules meet the constraints. Several test requirement nodes are obtained, the semantic similarity between the test requirement nodes and each functional module is calculated, and a mapping relationship between the test requirement nodes and functional modules is established to form a requirement-program structure association graph; among which, A requirement node refers to a four-tuple representation obtained after structured parsing of a single atomic requirement description in a software requirements document. It includes the operation, target object, constraints, and expected output. A functional module refers to a subgraph formed by aggregating semantically related function nodes after the STG execution graph community discovery algorithm has been refined by data flow; The requirement-program structure association graph refers to a bipartite graph constructed by taking the set of structured requirement nodes and the set of functional modules as node sets and using the semantic similarity association between requirement nodes and functional modules as edges. Based on the requirement-program structure relationship diagram, test intents are generated for each test requirement node, and these test intents are then transformed into executable test cases; among them, The generation of test intents for each test requirement node includes: For each test requirement node, find the associated functional modules in the requirement-program structure relationship graph, perform a depth-first search, enumerate all candidate paths from the entry function to the exit function of the functional module, and select the multiple candidate paths with the highest scores as the test path set; Based on the test requirement nodes and test path set, test intents are generated; The process of translating test intent into executable test cases includes: Based on the constraints in the test intent and the input parameter type constraints of each function in the test path, generate the test input data: Combine test intent, test input data, and expected output to generate executable test cases.

2. The method for automatically generating requirement-driven test cases based on semantic test graphs as described in claim 1, characterized in that, The steps for obtaining the test requirement nodes include: obtaining the test requirement document, performing dependency parsing on the test requirement document, and extracting several test requirement nodes.

3. The method for automatically generating requirement-driven test cases based on semantic test graphs as described in claim 1, characterized in that, The multidimensional static analysis includes: Perform syntax analysis on the source code to generate an abstract syntax tree for each function; Based on the abstract syntax tree, the function body is divided into basic blocks, with the function's start statement as the entry node and the function's return statement or the end of the method body as the exit node. Sequence, branching, looping, and exception handling statements are used as the basis for control transfer. The statements in each basic block are executed sequentially, and the control transfer between basic blocks is represented by directed edges, thus obtaining the control flow graph of each function. Traverse the control flow graph of all functions, identify the method call expression in each function body, extract the call relationship triplet between the caller function and the called function, and construct a global function call graph; Perform data flow analysis within each function, construct variable definition-use chains within the function, and identify data flow dependencies between functions through parameter passing, return values, and global variables.

4. The method for automatically generating requirement-driven test cases based on semantic test graphs as described in claim 1, characterized in that, The weight of the main edge is determined based on the frequency of function calls.

5. The method for automatically generating requirement-driven test cases based on semantic test graphs as described in claim 1, characterized in that, The weight of the auxiliary edge is: weight(e_data)=n_shared / (n_total_fi+n_total_fj-n_shared); where n_shared is the number of variables shared between functions fi and fj, and n_total_fi and n_total_fj are the total number of variables of functions fi and fj, respectively.

6. The method for automatically generating requirement-driven test cases based on semantic test graphs as described in claim 1, characterized in that, The graph community discovery algorithm discovers the community structure in the semantic test graph by iteratively optimizing the modularity function Q, which is defined as: Q=(1 / 2m)×Σ[Aij-ki×kj / (2m)]×δ(ci,cj); where Aij is the edge weight between nodes vi and vj in the comprehensive adjacency matrix, the comprehensive adjacency matrix W=α×W_call+(1-α)×W_data, α is the scaling factor, W_call is the weight matrix of the main edge, W_data is the weight matrix of the auxiliary edge; ki is the weighted degree of node vi; m is the sum of all edge weights; ci is the community to which node vi belongs; and δ(ci,cj) is the Kronecker function.

7. A requirement-driven automatic test case generation system based on semantic test graphs, characterized in that: include: The program analysis module is configured to: acquire the source code of the software under test, perform multi-dimensional static analysis on the source code, construct abstract syntax trees, control flow graphs and function call graphs respectively, and extract function call relationships and data flow dependencies; The semantic test graph construction module is configured to construct a semantic test graph with functions as nodes, function call relationships as main edges, and data flow dependencies as auxiliary edges. The functional clustering module is configured to: perform a graph community discovery algorithm on the semantic test graph to aggregate the function nodes in the semantic test graph into several functional modules, including: performing a graph community discovery algorithm on the semantic test graph to obtain several initial functional modules; and performing the following optimization operations on the several initial functional modules: Merging operation: For function pairs from different initial functional modules, if the cross-function data flow dependency density exceeds the first threshold, the initial functional modules containing the function pairs will be merged into the same functional module. Splitting operation: For a pair of functions within the same initial functional module, if the weights of the main edge and the auxiliary edge are both lower than the second threshold, and the cosine similarity of the semantic vectors of the two functions is lower than the third threshold, then the two are split into different functional modules. Verification: Recalculate the cohesion and coupling indices for each functional module. If the cohesion and coupling indices do not meet the constraints, perform a further splitting process on the functional module until all functional modules meet the constraints. The mapping and association module is configured to: acquire several test requirement nodes, calculate the semantic similarity between the test requirement nodes and each functional module, establish the mapping relationship from test requirement nodes to functional modules, and form a requirement-program structure association graph; wherein, A requirement node refers to a four-tuple representation obtained after structured parsing of a single atomic requirement description in a software requirements document. It includes the operation, target object, constraints, and expected output. A functional module refers to a subgraph formed by aggregating semantically related function nodes after the STG execution graph community discovery algorithm has been refined by data flow; The requirement-program structure association graph refers to a bipartite graph constructed by taking the set of structured requirement nodes and the set of functional modules as node sets and using the semantic similarity association between requirement nodes and functional modules as edges. The test generation module is configured to: generate test intents for each test requirement node based on the requirement-program structure association diagram, and transform the test intents into executable test cases; whereby, The generation of test intents for each test requirement node includes: For each test requirement node, find the associated functional modules in the requirement-program structure relationship graph, perform a depth-first search, enumerate all candidate paths from the entry function to the exit function of the functional module, and select the multiple candidate paths with the highest scores as the test path set; Based on the test requirement nodes and test path set, test intents are generated; The process of translating test intent into executable test cases includes: Based on the constraints in the test intent and the input parameter type constraints of each function in the test path, generate the test input data: Combine test intent, test input data, and expected output to generate executable test cases.

Images