A software testing requirements analysis method based on knowledge graphs

Abstract

This invention discloses a software testing requirements analysis method based on knowledge graphs, comprising the following steps: Step 1: Collecting requirements-side and verification-side data to form a test requirements analysis corpus; Step 2: Extracting semantic objects of requirements, behaviors, and assertions; Step 3: Constructing a three-domain test knowledge graph; Step 4: Generating a test assertion tension field; Step 5: Inputting the test assertion tension field into an improved Hypergraph Transformer model to obtain a test requirement tension propagation feature map; Step 6: Generating a test requirement gap map; Step 7: Obtaining the test requirement decomposition results; Step 8: Updating the three-domain test knowledge graph and the test assertion tension field based on test execution feedback. This invention employs an assertion gap tension resonance mechanism and an improved Hypergraph Transformer model to improve the accuracy of software testing requirement gap identification and decomposition.

Description

Technical Field

[0001] This invention relates to the field of software testing requirements analysis technology, and in particular to a software testing requirements analysis method based on knowledge graphs. Background Technology

[0002] As software systems evolve towards microservices, platformization, and rapid iteration, software requirements are no longer limited to single requirement documents. Interface definitions, business processes, code changes, historical defects, existing test cases, and execution logs all influence the results of test requirements analysis. Before version testing, testers need to identify the functions to be tested, interface behaviors, state changes, abnormal branches, permission boundaries, and assertion coverage from a large amount of heterogeneous data, and further determine which requirements need to be broken down into specific test tasks.

[0003] Current software testing requirements analysis methods largely rely on manual reading of requirements documents and comparison with test case libraries, making the analysis results highly susceptible to the experience of testers. Some automated methods only classify requirements text, extract keywords, or search for similar test cases, failing to express the relationships between requirements, software behavior paths, and test assertions. While knowledge graphs can organize multi-source information, conventional requirements knowledge graphs focus more on displaying entity relationships and are insufficient in identifying test-specific issues such as missing test assertions, broken state paths, uncovered exception branches, and unverified permission boundaries. This leads to insufficient decomposition of test requirements, unclear coverage priorities, and difficulty in timely incorporating test feedback into the requirements analysis process.

[0004] Therefore, how to provide a software testing requirements analysis method based on knowledge graphs is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] One objective of this invention is to propose a software testing requirements analysis method based on knowledge graphs. This invention employs a software testing requirements analysis method based on a three-domain test knowledge graph and a test assertion tension field. It collects requirements-side data and verification-side data around the version of the software under test and the test task identifier to form a test requirements analysis corpus. Through test semantic parsing, it extracts requirement semantic objects, behavior semantic objects, and assertion semantic objects, and constructs a three-domain test knowledge graph, so that the requirements of the software under test, the software behavior path, and the test verification assertions form a unified and related structure.

[0006] Based on the three-domain test knowledge graph, test assertion tension modeling is performed on the requirement verification pressure and assertion coverage gap to generate a test assertion tension field. The test assertion tension field is input into the improved Hypergraph Transformer model, and tension resonance weights are generated through the assertion gap tension resonance mechanism. The propagation characteristics between the three domain nodes are modulated to obtain the tension resonance propagation characteristics. The overlay gap output layer generates a test requirement tension propagation feature map based on the tension resonance propagation characteristics, and identifies test verification gaps and decomposes test requirements accordingly. Then, it updates the three-domain test knowledge graph and test assertion tension field based on test execution feedback, realizing structured analysis, gap identification and closed-loop update of software test requirements.

[0007] A software testing requirements analysis method based on knowledge graphs according to an embodiment of the present invention includes the following steps: Step 1: Collect requirements-side and verification-side data based on the version of the software to be tested and the test task identifier to form a test requirements analysis corpus; Step 2: Perform test semantic parsing on the test requirement analysis corpus, extract requirement semantic objects, behavior semantic objects, and assertion semantic objects to obtain a test requirement semantic object set; Step 3: Construct the relationships between the requirement domain, behavior domain, and assertion domain based on the set of semantic objects of test requirements to obtain a three-domain test knowledge graph; Step 4: Model the test assertion tension of the three-domain test knowledge graph to generate the test assertion tension field; Step 5: Input the test assertion tension field into the improved Hypergraph Transformer model to obtain the test requirement tension propagation feature map. The improved Hypergraph Transformer model includes a three-domain semantic embedding layer, a test scenario hyperedge construction layer, an assertion tension resonance layer, and a coverage gap output layer. The assertion tension resonance layer embeds an assertion gap tension resonance mechanism. Step 6: Identify test verification gaps based on the test requirement tension propagation feature map and generate a test requirement gap map; Step 7: Decompose the semantic objects of the requirements into test requirements based on the test requirement gap diagram to obtain the test requirement decomposition results; Step 8: Receive test execution feedback corresponding to the test requirement breakdown results, update the three-domain test knowledge graph and test assertion tension field based on the test execution feedback, and output the updated test requirement analysis results.

[0008] Optionally, step one specifically includes: Read the version configuration file of the software under test, extract the version number, module identifier, interface identifier and change submission identifier, and concatenate the version number, module identifier, interface identifier and test task identifier into a collection index; Based on the collection index, the requirement description text, interface input and output description, business process node description and change description text are read from the requirement management library, interface management library, business process library and code repository to obtain the requirement-side data; Based on the collection index, existing test cases, defect description texts, defect-related modules, and test execution logs are read from the test management library, defect management library, and execution log library to obtain verification side data; The requirements-side data and verification-side data are converted into unified text fragments, and version tags and source tags are written according to the collection index. Duplicate fragments with the same collection index and the same text hash value are deleted to form a test requirements analysis corpus.

[0009] Optionally, step two specifically includes: Read text fragments from the test requirements analysis corpus, write fragment identifiers, source tags, and collection indexes generated by the software version under test and test task identifiers into the text fragments, and perform preprocessing on the text fragments to remove format specifiers, unify interface names, unify field names, and unify status names to obtain standard text fragments. The standard text fragment is divided into sentences using periods, semicolons, newlines, and list numbers as delimiters, and text position identifiers are generated according to the order in which the sentences appear in the standard text fragment. The clauses are matched with a preset test semantic dictionary, which includes requirement action words, business object words, interface action words, status action words, exception action words, permission constraint words, data boundary words, expected result words, return status words, and verification action words. Sentences that match requirement action words and business object words generate requirement semantic objects; sentences that match interface action words, status action words, exception action words, permission constraint words, or data boundary words generate behavior semantic objects; sentences that match expected result words, return status words, or validation action words generate assertion semantic objects. Write the source tag, collection index, text location identifier, and matched object name into the corresponding semantic object, and merge the requirement semantic objects, behavior semantic objects, and assertion semantic objects with the same collection index and consecutive text location identifiers to obtain the test requirement semantic object set.

[0010] Optionally, step three specifically includes: Map requirement semantic objects in the test requirement semantic object set to requirement domain nodes, behavior semantic objects to behavior domain nodes, and assertion semantic objects to assertion domain nodes, and generate node identifiers based on the object name, object type, source information, and text position relationship carried by the semantic objects. The string matching is performed between the business object name in the requirement semantic object and the interface name, status name, exception name, permission constraint name or data field name in the behavior semantic object. When the match is successful, a requirement behavior association edge is generated between the requirement domain node and the behavior domain node. Based on the interface name, status name, exception name, permission constraint name, or data field name in the behavior semantic object, match it with the return status, output field, log field, or validation condition in the assertion semantic object. When the match is successful, generate a behavior assertion association edge between the behavior domain node and the assertion domain node. Generate a test scenario association chain based on requirement domain nodes, behavior domain nodes, and assertion domain nodes that have the same source information, continuous text position relationship, or the same object name; Write the requirement domain nodes, behavior domain nodes, assertion domain nodes, requirement-behavior association edges, behavior-assertion association edges, and test scenario association chains into a graph database to obtain a three-domain test knowledge graph.

[0011] Optionally, step four specifically involves: Read the requirement domain nodes, behavior domain nodes, and assertion domain nodes associated with the same requirement semantic object from the three-domain test knowledge graph, and generate a requirement verification subgraph. Based on the behavior path size, cross-domain association strength, and assertion node coverage status in the requirement verification subgraph, the requirement verification pressure characteristics are determined. Perform max-min normalization on the demand verification pressure characteristics to obtain normalized demand verification pressure characteristics. Identify assertion coverage gaps based on the association state between behavior domain nodes and assertion domain nodes, and generate assertion coverage gap features based on the assertion coverage gaps; The normalized demand verification pressure features and assertion coverage gap features are input into the tension mapping layer. The tension mapping layer uses linear weighted mapping and Sigmoid function compression to obtain the test assertion tension value. The test assertion tension value is bound to the corresponding requirement domain node, and a test assertion tension field is formed according to the relationship between the requirement domain nodes.

[0012] Optionally, step five specifically includes: The three-domain semantic embedding layer reads the demand domain nodes, behavior domain nodes, assertion domain nodes and test assertion tension values ​​from the test assertion tension field, concatenates the node text features, node domain type features, cross-domain association features and tension features into node joint features, and inputs the node joint features into the linear mapping layer. The linear mapping layer uses fully connected matrix multiplication and superimposed bias to obtain the mapped node features, and then performs layer normalization and missing label masking on the mapped node features to generate three-domain node embedding features. The test scenario hyperedge construction layer uses behavior domain nodes and assertion domain nodes associated with the same requirement domain node as connection objects. It constructs test scenario hyperedges based on test scenario association chains, cross-domain association edges, and assertion gap identifiers generated by assertion coverage gaps. It also writes hyperedge type identifiers, hyperedge tension identifiers, and assertion gap identifiers to test scenario hyperedges and writes isolated node identifiers to unconnected objects. The test scenario hyperedge construction layer generates assertion gap features based on assertion gap identifiers, aggregates the three-domain node embedding features according to the test scenario hyperedge, performs linear projection of query vector, key vector and value vector on the node embedding features within the same test scenario hyperedge, generates attention scores based on the dot product of query vector and key vector, and normalizes the attention scores using the Softmax function to obtain the test scenario hyperedge embedding features. The assertion tension resonance layer invokes the assertion gap tension resonance mechanism to generate tension resonance input features based on assertion gap features and test assertion tension values, and generates tension resonance weights based on the tension resonance input features. The propagation features between demand domain nodes, behavior domain nodes, and assertion domain nodes are modulated based on the tension resonance weights to obtain gap enhancement propagation features. The gap enhancement propagation features are then residually fused and layer normalized with the test scenario hyperedge embedding features to obtain tension resonance propagation features. The covered gap output layer performs residual connection and layer normalization on the tension resonance propagation features, inputs the processed tension resonance propagation features into the nonlinear activation layer, the nonlinear activation layer uses the ReLU function to retain the positive gap response, and then the output mapping layer maps the positive gap response to the corresponding demand domain node to generate a test demand tension propagation feature map carrying the test assertion tension value and tension resonance propagation features.

[0013] Optionally, the assertion notch tension resonance mechanism specifically refers to: Read the behavior domain nodes, assertion domain nodes, assertion gap identifiers and test assertion tension values ​​associated with the same requirement domain nodes from the test scenario hyperedge, and generate assertion gap analysis units; The assertion gap feature is determined based on the connection state between the behavior domain node and the assertion domain node, and the assertion gap feature is concatenated with the test assertion tension value to form the tension resonance input feature; The tension resonance input features are input into the gated mapping layer. The gated mapping layer generates gated intermediate features by using fully connected matrix multiplication and superimposing biases. The gated intermediate features are then converted into tension resonance weights by the Sigmoid function. Based on the tension resonance weight, the propagation characteristics between demand domain nodes, behavior domain nodes and assertion domain nodes are modulated. When the tension resonance weight increases, the propagation intensity from the behavior domain node corresponding to the assertion gap to the demand domain node is increased, and the repeated propagation intensity of the already covered assertion domain node is reduced, thus obtaining the gap-enhanced propagation characteristics. The gap enhancement propagation features and the test scene hyperedge embedding features are residually fused, and the fused features are subjected to layer normalization to obtain the tension resonance propagation features. Update the superedge tension identifier and assertion gap identifier of the corresponding test scenario superedge according to the tension resonance propagation characteristics, and output the tension resonance propagation characteristics to the cover gap output layer.

[0014] Optionally, step six specifically includes: Read the requirement domain nodes, behavior domain nodes, assertion domain nodes, test assertion tension values ​​and tension resonance propagation features corresponding to the same requirement semantic object in the test requirement tension propagation feature map, and generate a gap identification sub-map according to the connection order from requirement domain nodes to behavior domain nodes and from behavior domain nodes to assertion domain nodes. The behavior domain nodes are labeled with types according to interface calls, state transitions, exception triggers, permission constraints, and data boundaries, and the corresponding set of behavior nodes is extracted from the gap identification subgraph based on the type labels. Determine whether each behavior domain node has an assertion domain node with a verification condition. If no assertion domain node with a verification condition exists, generate an assertion gap. Check the continuity between the starting state, intermediate state and ending state according to the direction of the state transition edge. If there is a missing state node or a broken transition direction, generate a state path gap. The abnormal trigger behavior node, permission constraint behavior node, and data boundary behavior node are matched with the abnormal verification conditions, permission verification conditions, and boundary verification conditions in the assertion domain node, respectively. If the matching fails, the corresponding abnormal branch gap, permission boundary gap, and data boundary gap are generated. Write the gap type, gap source node, gap target node, test assertion tension value, and tension resonance propagation characteristics into the corresponding demand domain node, and generate gap edges between the demand domain node and the gap source node to obtain the test demand gap graph.

[0015] Optionally, step seven specifically includes: Read the gap type, gap source node, gap target node and test assertion tension value corresponding to the requirement semantic object in the test requirement gap diagram, and generate requirement decomposition unit; According to the preset gap conversion rules, assertion gaps are converted into assertion supplement test requirements, state path gaps are converted into state transition test requirements, abnormal branch gaps are converted into abnormal handling test requirements, permission boundary gaps are converted into permission verification test requirements, and data boundary gaps are converted into data boundary test requirements. Generate a test object identifier based on the interface name, status name, exception name, permission constraint name, or data field name corresponding to the gap source node, and generate an assertion supplement target based on the verification conditions corresponding to the gap target node; When the gap target node is empty, generate a supplementary assertion target based on the node type of the gap source node and the gap type, and use the supplementary assertion target as the assertion supplement target; Test requirements corresponding to the same requirement semantic object are sorted according to the test assertion tension value, gap type priority, and number of associated gap source nodes to obtain test priority identifiers; Write the test object identifier, assertion supplement target, test priority identifier, and requirement semantic object identifier into the corresponding test requirement to obtain the test requirement decomposition result.

[0016] Optionally, step eight specifically includes: Receive test execution feedback corresponding to the test requirement decomposition results, and extract test requirement identifier, execution status, assertion hit status, defect location results and test case coverage results from the test execution feedback; Based on the test requirement identifier, locate the requirement domain nodes, behavior domain nodes, assertion domain nodes, and gap edges in the three-domain test knowledge graph; When the execution status is executed and the assertion hit status is passed, the coverage status of the corresponding assertion domain node is updated to covered, and the corresponding gap edge is marked as a closed gap. When the execution status is executed and the assertion hit status is failed, a new defect node is added to the three-domain test knowledge graph based on the defect location result, or an existing defect node in the three-domain test knowledge graph is called, and a defect association edge is generated between the corresponding behavior domain node and the defect node, and a high-tension update identifier is written for the corresponding requirement domain node. When the execution status is not executed or the test case coverage result does not contain the corresponding coverage record, the corresponding gap edge is retained as a gap to be covered, and the coverage status of the corresponding assertion domain node is kept as uncovered; The test assertion tension value is recalculated based on the updated coverage status, gap edge status, defect associated edge, and high-tension update identifier. The recalculated test assertion tension value is written into the test assertion tension field, and the updated test requirement analysis results are output.

[0017] The beneficial effects of this invention are: This invention constructs a three-domain test knowledge graph, which integrates requirement semantic objects, behavior semantic objects, and assertion semantic objects into a unified graph structure for association. This allows software test requirement analysis to move beyond simply classifying requirement texts or matching similar test cases. Instead, it enables the simultaneous expression of structural relationships between requirement clauses, interface calls, state transitions, exception triggers, permission constraints, data boundaries, and test assertions, thereby improving the completeness and traceability of test requirement analysis objects from the source.

[0018] By testing the synergistic processing of assertion tension field and assertion gap tension resonance mechanism, it is possible to identify demand nodes with complex behavioral paths but insufficient assertion coverage as high-tension test objects, and enhance the influence of assertion gaps, state path gaps, abnormal branch gaps, permission boundary gaps and data boundary gaps in model propagation, so that the test requirement decomposition results are more in line with the real verification gaps. The improved Hypergraph Transformer model utilizes test scenario hyperedges to perform cross-domain feature aggregation, enhancing the stability of identifying multi-node and multi-relationship test requirements in complex software scenarios. Test execution feedback writes back to the three-domain test knowledge graph and test assertion tension field, enabling the test requirement analysis results to be continuously updated with execution status, assertion hit status, defect location results, and coverage results, thereby improving coverage accuracy and requirement analysis closure capability in iterative testing. Attached Figure Description

[0019] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is an overall flowchart of a knowledge graph-based software testing requirements analysis method proposed in this invention. Figure 2 This is a flowchart illustrating the working principle of the improved Hypergraph Transformer model for software testing requirements analysis based on knowledge graphs, as proposed in this invention. Detailed Implementation

[0020] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0021] refer to Figure 1 and Figure 2 A software testing requirements analysis method based on knowledge graphs includes the following steps: Step 1: Collect requirements-side and verification-side data based on the version of the software to be tested and the test task identifier to form a test requirements analysis corpus; Step 2: Perform test semantic parsing on the test requirement analysis corpus, extract requirement semantic objects, behavior semantic objects, and assertion semantic objects to obtain a test requirement semantic object set; Step 3: Construct the relationships between the requirement domain, behavior domain, and assertion domain based on the set of semantic objects of test requirements to obtain a three-domain test knowledge graph; Step 4: Model the test assertion tension of the three-domain test knowledge graph to generate the test assertion tension field; Step 5: Input the test assertion tension field into the improved Hypergraph Transformer model to obtain the test requirement tension propagation feature map. The improved Hypergraph Transformer model includes a three-domain semantic embedding layer, a test scenario hyperedge construction layer, an assertion tension resonance layer, and a coverage gap output layer. The assertion tension resonance layer embeds an assertion gap tension resonance mechanism. Step 6: Identify test verification gaps based on the test requirement tension propagation feature map and generate a test requirement gap map; Step 7: Decompose the semantic objects of the requirements into test requirements based on the test requirement gap diagram to obtain the test requirement decomposition results; Step 8: Receive test execution feedback corresponding to the test requirement breakdown results, update the three-domain test knowledge graph and test assertion tension field based on the test execution feedback, and output the updated test requirement analysis results.

[0022] In this embodiment, step one specifically includes: Read the version configuration file of the software under test, extract the version number, module identifier, interface identifier and change submission identifier, and concatenate the version number, module identifier, interface identifier and test task identifier into a collection index; Based on the collection index, the requirement description text, interface input and output description, business process node description and change description text are read from the requirement management library, interface management library, business process library and code repository to obtain the requirement-side data; Based on the collection index, existing test cases, defect description texts, defect-related modules, and test execution logs are read from the test management library, defect management library, and execution log library to obtain verification side data; The demand-side data and verification-side data are converted into unified text fragments, and version tags and source tags are written according to the collection index. Duplicate fragments with the same collection index and the same text hash value are deleted to form a test requirement analysis corpus. In the specific implementation process, the test platform reads the version number, module identifier, interface identifier, change submission identifier and list of affected modules from the version configuration table, and reads the task number, test round, test type and execution scope from the test task table; The version number, module identifier, interface identifier, change submission identifier, and task number are concatenated to form the collection index; using the module identifier and interface identifier as query conditions, the requirement clauses, acceptance conditions, interface fields, process nodes, status transition relationships, and list of affected interfaces are read from the requirement management library, interface management library, business process library, and code repository. Using task number and test round as query criteria, retrieve test case steps, assertion content, defect triggering conditions, repair status, and assertion hit records from the test management library, defect management library, and execution log library; The read content is segmented into text fragments according to the source library name, original record number, and paragraph order. Empty fragments with fewer than ten characters and fragments with duplicate text hash values ​​are deleted. Version tags, source tags, and data type tags are written to retain the fragments, providing a traceable text foundation of the same version, task, and interface for testing semantic parsing.

[0023] In this embodiment, step two specifically includes: Read text fragments from the test requirements analysis corpus, write fragment identifiers, source tags, and collection indexes generated by the software version under test and test task identifiers into the text fragments, and perform preprocessing on the text fragments to remove format specifiers, unify interface names, unify field names, and unify status names to obtain standard text fragments. The standard text fragment is divided into sentences using periods, semicolons, newlines, and list numbers as delimiters, and text position identifiers are generated according to the order in which the sentences appear in the standard text fragment. The clauses are matched with a preset test semantic dictionary, which includes requirement action words, business object words, interface action words, status action words, exception action words, permission constraint words, data boundary words, expected result words, return status words, and verification action words. Sentences that match requirement action words and business object words generate requirement semantic objects; sentences that match interface action words, status action words, exception action words, permission constraint words, or data boundary words generate behavior semantic objects; sentences that match expected result words, return status words, or validation action words generate assertion semantic objects. Write the source tag, collection index, text location identifier and the name of the matched object into the corresponding semantic object, and merge the requirement semantic objects, behavior semantic objects and assertion semantic objects with the same collection index and consecutive text location identifiers to obtain the test requirement semantic object set. In the actual implementation process, the test platform reads text fragments with tags, deletes form feeds, tabs, ordinal decorators, and format characters without business meaning; it reads the interface alias table, field alias table, and status alias table, and replaces the interface name, field name, and status name with the standard name; Use periods, semicolons, newlines, list numbers, and field separators as sentence boundaries, and write fragment identifiers, source tags, collection indexes, and text positions for each sentence; Input the clauses into the preset test semantic dictionary. When the requirement action words and business object words are matched, extract the business object name, action words and acceptance conditions to generate the requirement semantic object. When an interface action word, status action word, exception action word, permission constraint word, or data boundary word is hit, the interface name, status name, exception name, permission constraint name, and triggering condition are extracted to generate a behavior semantic object. When a word for expected result, a word for return status, or a word for validation action is hit, the return status, output field, assertion content, and validation conditions are extracted to generate an assertion semantic object. By merging three types of semantic objects with the same collection index, the same source label, and consecutive text positions, and deleting objects with the same name and duplicate source positions, a data foundation with clear semantic boundaries is provided for the construction of the three-domain graph.

[0024] In this embodiment, step three specifically includes: Map requirement semantic objects in the test requirement semantic object set to requirement domain nodes, behavior semantic objects to behavior domain nodes, and assertion semantic objects to assertion domain nodes, and generate node identifiers based on the object name, object type, source information, and text position relationship carried by the semantic objects. The string matching is performed between the business object name in the requirement semantic object and the interface name, status name, exception name, permission constraint name or data field name in the behavior semantic object. When the match is successful, a requirement behavior association edge is generated between the requirement domain node and the behavior domain node. Based on the interface name, status name, exception name, permission constraint name, or data field name in the behavior semantic object, match it with the return status, output field, log field, or validation condition in the assertion semantic object. When the match is successful, generate a behavior assertion association edge between the behavior domain node and the assertion domain node. Generate a test scenario association chain based on requirement domain nodes, behavior domain nodes, and assertion domain nodes that have the same source information, continuous text position relationship, or the same object name; Write the requirement domain nodes, behavior domain nodes, assertion domain nodes, requirement-behavior association edges, behavior-assertion association edges, and test scenario association chains into the graph database to obtain a three-domain test knowledge graph; In the specific implementation process, the test platform takes the test requirement semantic object set corresponding to version number V3.2.6 and test task identifier T-REG-042 as input. The test requirement semantic object set contains 486 requirement semantic objects, 713 behavior semantic objects and 558 assertion semantic objects. Write the data into the requirement domain, behavior domain, and assertion domain according to the object type, and generate node identifiers using the format "collection index + object type + standard object name + text location identifier". Cross-domain matching first performs a standard object name exact match, generating an L1 level related edge if successful; if it fails, it performs an alias match, generating an L2 level related edge if successful; if no match is found, it uses the character triple Jaccard similarity to calculate candidate relationships, generating candidate related edges when the similarity reaches 0.82. After matching, 1246 requirement behavior association edges, 1089 behavior assertion association edges, and 392 test scenario association chains were generated. When the same behavior domain node connects to multiple assertion domain nodes, the assertion priority value is calculated based on the completeness of the verification condition (0.6) and the proximity of the text position (0.4), and the node with the highest value is marked as the main assertion node. When a behavior domain node is not connected to an assertion domain node, a pending assertion tag is written, resulting in a total of 137 behavior domain nodes to be asserted. The nodes, associated edges, test scenario association chains, and pending assertion tags are written into the graph database to obtain a three-domain test knowledge graph containing 1757 nodes and 2727 relationships, providing a graph foundation with the ability to locate assertion gaps and the strength of associations for test assertion tension modeling.

[0025] In this embodiment, step four specifically includes: Read the requirement domain nodes, behavior domain nodes, and assertion domain nodes associated with the same requirement semantic object from the three-domain test knowledge graph, and generate a requirement verification subgraph. Based on the behavior path size, cross-domain association strength, and assertion node coverage status in the requirement verification subgraph, the requirement verification pressure characteristics are determined. Perform max-min normalization on the demand verification pressure characteristics to obtain normalized demand verification pressure characteristics. Identify assertion coverage gaps based on the association state between behavior domain nodes and assertion domain nodes, and generate assertion coverage gap features based on the assertion coverage gaps; The normalized demand verification pressure features and assertion coverage gap features are input into the tension mapping layer. The tension mapping layer uses linear weighted mapping and Sigmoid function compression to obtain the test assertion tension value. Bind the test assertion tension value to the corresponding requirement domain node, and form a test assertion tension field according to the relationship between the requirement domain nodes; In the specific implementation process, the testing platform reads the connected behavior domain nodes, assertion domain nodes, related edges and test scenario related chains with each requirement domain node as the center, and generates 486 requirement verification subgraphs. The requirement verification pressure characteristics consist of the behavior path size, cross-domain association strength, and assertion node coverage status; the behavior path size is determined by the number of interface call chains, state transition chains, and exception trigger chains; the cross-domain association strength is a weighted sum of L1-level association edge weight 1, L2-level association edge weight 0.75, and candidate association edge weight 0.55. The assertion node coverage status is determined by the proportion of assertion domain nodes with verification conditions to the associated behavior domain nodes; maximum and minimum normalization are performed on 486 requirement verification pressure features; When a behavior domain node is not connected to an assertion domain node or an assertion domain node lacks a verification condition, an assertion coverage gap is generated, and a total of 137 gaps are identified. The tension mapping layer linearly weights the demand verification pressure feature (0.55) and the assertion coverage gap feature (0.45), and compresses them into test assertion tension values ​​using the Sigmoid function. Demand domain nodes with tension values ​​of 0.65 or higher are marked as high-tension nodes, resulting in 112 high-tension demand domain nodes. High-tension markers are propagated along business-related edges and shared behavior nodes to form a test assertion tension field, providing quantifiable tension inputs for improving the Hypergraph Transformer model.

[0026] In this embodiment, step five specifically includes: The three-domain semantic embedding layer reads the demand domain nodes, behavior domain nodes, assertion domain nodes and test assertion tension values ​​from the test assertion tension field, concatenates the node text features, node domain type features, cross-domain association features and tension features into node joint features, and inputs the node joint features into the linear mapping layer. The linear mapping layer uses fully connected matrix multiplication and superimposed bias to obtain the mapped node features, and then performs layer normalization and missing label masking on the mapped node features to generate three-domain node embedding features. The test scenario hyperedge construction layer uses behavior domain nodes and assertion domain nodes associated with the same requirement domain node as connection objects. It constructs test scenario hyperedges based on test scenario association chains, cross-domain association edges, and assertion gap identifiers generated by assertion coverage gaps. It also writes hyperedge type identifiers, hyperedge tension identifiers, and assertion gap identifiers to test scenario hyperedges and writes isolated node identifiers to unconnected objects. The test scenario hyperedge construction layer generates assertion gap features based on assertion gap identifiers, aggregates the three-domain node embedding features according to the test scenario hyperedge, performs linear projection of query vector, key vector and value vector on the node embedding features within the same test scenario hyperedge, generates attention scores based on the dot product of query vector and key vector, and normalizes the attention scores using the Softmax function to obtain the test scenario hyperedge embedding features. The assertion tension resonance layer invokes the assertion gap tension resonance mechanism to generate tension resonance input features based on assertion gap features and test assertion tension values, and generates tension resonance weights based on the tension resonance input features. The propagation features between demand domain nodes, behavior domain nodes, and assertion domain nodes are modulated based on the tension resonance weights to obtain gap enhancement propagation features. The gap enhancement propagation features are then residually fused and layer normalized with the test scenario hyperedge embedding features to obtain tension resonance propagation features. The covered gap output layer performs residual connection and layer normalization on the tension resonance propagation features, inputs the processed tension resonance propagation features into the nonlinear activation layer, the nonlinear activation layer uses the ReLU function to retain the positive gap response, and then maps the positive gap response to the corresponding demand domain node through the output mapping layer to generate a test demand tension propagation feature map carrying the test assertion tension value and tension resonance propagation features. In the specific implementation process, the Hypergraph Transformer model was improved to receive the test assertion tension field, with the input containing 1757 three-domain nodes, 2727 graph relationships, 392 test scenario association chains, and 137 assertion coverage gaps; The three-domain semantic embedding layer compresses node text features into a 128-dimensional vector, encodes node domain type features into a 16-dimensional vector, encodes cross-domain association features into a 32-dimensional vector, and maps test assertion tension values ​​into an 8-dimensional tension vector. After concatenating the 184-dimensional node joint features, the bias mapping is superimposed through fully connected matrix multiplication to obtain 128-dimensional mapped node features. The layer normalization numerical stability term is set to 10^-5 to avoid the standard deviation denominator from approaching zero. The test scenario hyperedge construction layer converts 392 test scenario association chains into basic test scenario hyperedges, converts 137 assertion coverage gaps into assertion gap identifiers, establishes gap enhancement hyperedges for the behavior domain nodes corresponding to the assertion gap identifiers, and establishes tension propagation hyperedges for 112 high-tension demand domain nodes. When the number of nodes inside the hyperedge exceeds 24, the 24 nodes closest to the nodes in the required domain are truncated; when there are fewer than 3, isolated node identifiers are added. The query vector, key vector, and value vector are linearly projected onto the embedding features of the nodes inside the hyperedge. The projection dimension is 128, the number of attention heads is 4, and the attention score is normalized using the Softmax function to obtain the hyperedge embedding features of the test scene. The assertion tension resonance layer calls the assertion gap tension resonance mechanism to concatenate the assertion gap features with the test assertion tension values ​​to form tension resonance input features, which are then generated by fully connected matrix multiplication, bias stacking and the Sigmoid function to produce tension resonance weights. When the tension resonance weight reaches 0.60 or above, the propagation intensity of the behavior domain node corresponding to the assertion gap to the demand domain node is enhanced, and the repeated propagation intensity of the already covered assertion domain node is suppressed, thus obtaining the tension resonance propagation feature. The covered gap output layer maps the tension resonance propagation characteristics back to the demand domain nodes, and retains the positive gap response through the ReLU function to generate a test demand tension propagation feature map carrying the test assertion tension value and tension resonance propagation characteristics; By employing three-domain semantic embedding, test scenario hyperedge aggregation, and assertion gap tension resonance processing, local assertion coverage insufficiency is transformed into propagable demand-level gap features, providing a model output basis carrying tension values ​​and propagation evidence for testing and verifying gap identification.

[0027] In this embodiment, the assertion of the notch tension resonance mechanism is specifically as follows: Read the behavior domain nodes, assertion domain nodes, assertion gap identifiers and test assertion tension values ​​associated with the same requirement domain nodes from the test scenario hyperedge, and generate assertion gap analysis units; The assertion gap feature is determined based on the connection state between the behavior domain node and the assertion domain node, and the assertion gap feature is concatenated with the test assertion tension value to form the tension resonance input feature; The tension resonance input features are input into the gated mapping layer. The gated mapping layer generates gated intermediate features by using fully connected matrix multiplication and superimposing biases. The gated intermediate features are then converted into tension resonance weights by the Sigmoid function. Based on the tension resonance weight, the propagation characteristics between demand domain nodes, behavior domain nodes and assertion domain nodes are modulated. When the tension resonance weight increases, the propagation intensity from the behavior domain node corresponding to the assertion gap to the demand domain node is increased, and the repeated propagation intensity of the already covered assertion domain node is reduced, thus obtaining the gap-enhanced propagation characteristics. The gap enhancement propagation features and the test scene hyperedge embedding features are residually fused, and the fused features are subjected to layer normalization to obtain the tension resonance propagation features. Update the hyperedge tension identifier and assertion gap identifier of the corresponding test scenario hyperedge according to the tension resonance propagation characteristics, and output the tension resonance propagation characteristics to the cover gap output layer; In the specific implementation process, the assertion tension resonance layer reads the test scene hyperedge with assertion gap identifiers and obtains 137 assertion gap analysis units; Each assertion gap analysis unit takes demand domain nodes, behavior domain nodes, assertion domain nodes, test assertion tension values, assertion coverage status, and associated edge matching level as inputs. The assertion coverage status and associated edge matching level are encoded as three-dimensional state vectors and three-dimensional matching vectors, respectively. A full assertion gap feature is generated when a behavior domain node is not connected to an assertion domain node; a weak assertion gap feature is generated when a behavior domain node is connected to an assertion domain node but the check condition is empty; a covered assertion feature is generated when a behavior domain node is connected to an assertion domain node with a check condition; the gap strength is generated based on the strength relationship between the full assertion gap feature, the weak assertion gap feature, and the covered assertion feature. The gap strength corresponding to the full assertion gap feature is higher than that of the weak assertion gap feature, and the covered assertion feature does not participate in gap enhancement propagation. The gap strength, test assertion tension value, coverage state vector, matching level vector and behavior domain node embedding features are concatenated into tension resonance input features, which are then input into the gating mapping layer to generate 64-dimensional gating intermediate features, and then compressed into tension resonance weights by the Sigmoid function. When the tension resonance weight is greater than or equal to 0.60, it is marked as a resonance enhancement node; when the tension resonance weight is less than 0.60, it is marked as a normal propagation node. The propagation feature of the behavior domain node to the demand domain node of the resonance enhancement node is multiplied by the product of the tension resonance weight and the enhancement coefficient 1.35. The propagation feature of the covered assertion domain node to the demand domain node is multiplied by the repetition suppression coefficient 0.50. After propagation modulation, 96 assertion gap analysis units generate resonance enhancement nodes, while 41 assertion gap analysis units retain conventional propagation nodes. During residual fusion, the original test scene hyperedge embedding feature of 0.40 and modulation propagation feature of 0.60 are retained, and layer normalization is performed to obtain tension resonance propagation features. Update the hyperedge tension identifier and assertion gap identifier of the corresponding test scenario hyperedge according to the tension resonance propagation characteristics, and output the tension resonance propagation characteristics to the cover gap output layer; By using gap strength encoding, Sigmoid gating, and propagation modulation, the behavior path with insufficient assertion coverage forms a stronger gap response, while suppressing the repetitive influence of covered assertions, thus providing the covered gap output layer with tension resonance propagation characteristics consistent with the main flow of the model.

[0028] In this embodiment, step six specifically includes: Read the requirement domain nodes, behavior domain nodes, assertion domain nodes, test assertion tension values ​​and tension resonance propagation features corresponding to the same requirement semantic object in the test requirement tension propagation feature map, and generate a gap identification sub-map according to the connection order from requirement domain nodes to behavior domain nodes and from behavior domain nodes to assertion domain nodes. The behavior domain nodes are labeled with types according to interface calls, state transitions, exception triggers, permission constraints, and data boundaries, and the corresponding set of behavior nodes is extracted from the gap identification subgraph based on the type labels. Determine whether each behavior domain node has an assertion domain node with a verification condition. If no assertion domain node with a verification condition exists, generate an assertion gap. Check the continuity between the starting state, intermediate state and ending state according to the direction of the state transition edge. If there is a missing state node or a broken transition direction, generate a state path gap. The abnormal trigger behavior node, permission constraint behavior node, and data boundary behavior node are matched with the abnormal verification conditions, permission verification conditions, and boundary verification conditions in the assertion domain node, respectively. If the matching fails, the corresponding abnormal branch gap, permission boundary gap, and data boundary gap are generated. Write the gap type, gap source node, gap target node, test assertion tension value, and tension resonance propagation characteristics into the corresponding demand domain node, and generate gap edges between the demand domain node and the gap source node to obtain the test demand gap graph. In the specific implementation process, the gap identification module reads the node propagation features corresponding to 486 requirement domain nodes in the test requirement tension propagation feature map, and simultaneously reads the test assertion tension value and tension resonance propagation features carried in the test requirement tension propagation feature map; 486 gap identification subgraphs are generated with the same semantic object of demand as the center, and the behavioral domain nodes are divided into five categories: interface call, state transition, exception trigger, permission constraint and data boundary. An assertion gap is generated when no assertion domain node with a valid verification condition exists in the behavior domain node; a state path gap is generated when the state transition chain is discontinuous or the transition direction is opposite to the order of the business process nodes; a corresponding gap is generated when the abnormal trigger behavior node, the permission constraint behavior node, or the data boundary behavior node does not match the corresponding verification condition. A total of 137 testing and verification gaps were identified, including 54 assertion gaps, 31 state path gaps, 28 abnormal branch gaps, 14 permission boundary gaps, and 10 data boundary gaps. The gap type, gap source node, gap target node, test assertion tension value, and tension resonance propagation characteristics are written into the corresponding requirement domain node, and gap edges are generated. This transforms the tension value and propagation characteristics in the test requirement tension propagation characteristic graph into a locatable test verification gap, providing a clear object for test requirement decomposition.

[0029] In this embodiment, step seven specifically includes: Read the gap type, gap source node, gap target node and test assertion tension value corresponding to the requirement semantic object in the test requirement gap diagram, and generate requirement decomposition unit; According to the preset gap conversion rules, assertion gaps are converted into assertion supplement test requirements, state path gaps are converted into state transition test requirements, abnormal branch gaps are converted into abnormal handling test requirements, permission boundary gaps are converted into permission verification test requirements, and data boundary gaps are converted into data boundary test requirements. Generate a test object identifier based on the interface name, status name, exception name, permission constraint name, or data field name corresponding to the gap source node, and generate an assertion supplement target based on the verification conditions corresponding to the gap target node; When the gap target node is empty, generate a supplementary assertion target based on the node type of the gap source node and the gap type, and use the supplementary assertion target as the assertion supplement target; Test requirements corresponding to the same requirement semantic object are sorted according to the test assertion tension value, gap type priority, and number of associated gap source nodes to obtain test priority identifiers; Write the test object identifier, assertion supplement target, test priority identifier, and requirement semantic object identifier into the corresponding test requirement to obtain the test requirement decomposition result; In the specific implementation process, the requirement decomposition module reads 137 test verification gaps and generates requirement decomposition units according to the requirement semantic object identifier; According to the gap conversion rules, assertion gaps, state path gaps, abnormal branch gaps, permission boundary gaps, and data boundary gaps are respectively converted into assertion supplementary test requirements, state transition test requirements, exception handling test requirements, permission verification test requirements, and data boundary test requirements. The test object identifier is generated from the interface name, status name, exception name, permission constraint name, or data field name in the gap source node; the assertion supplement target is primarily generated from the verification conditions in the gap target node, and when the gap target node is empty, the corresponding verification target is generated according to the node type; The test priority value is calculated based on the test assertion tension value of 0.50, the gap type priority of 0.30, and the number of associated gap source nodes of 0.20. After merging identical test objects and identical assertion supplementation targets, 137 gaps generated 126 test requirement breakdown results, including 42 high-priority requirements, 57 medium-priority requirements, and 27 low-priority requirements. Write the test object identifier, assertion supplement target, test priority identifier, and requirement semantic object identifier into the corresponding test requirement to provide a structured task entry point for feedback write-back.

[0030] In this embodiment, step eight specifically includes: Receive test execution feedback corresponding to the test requirement decomposition results, and extract test requirement identifier, execution status, assertion hit status, defect location results and test case coverage results from the test execution feedback; Based on the test requirement identifier, locate the requirement domain nodes, behavior domain nodes, assertion domain nodes, and gap edges in the three-domain test knowledge graph; When the execution status is executed and the assertion hit status is passed, the coverage status of the corresponding assertion domain node is updated to covered, and the corresponding gap edge is marked as a closed gap. When the execution status is executed and the assertion hit status is failed, a new defect node is added to the three-domain test knowledge graph based on the defect location result, or an existing defect node in the three-domain test knowledge graph is called, and a defect association edge is generated between the corresponding behavior domain node and the defect node, and a high-tension update identifier is written for the corresponding requirement domain node. When the execution status is not executed or the test case coverage result does not contain the corresponding coverage record, the corresponding gap edge is retained as a gap to be covered, and the coverage status of the corresponding assertion domain node is kept as uncovered; Based on the updated coverage status, gap edge status, defect associated edge, and high-tension update identifier, the test assertion tension value is recalculated, the recalculated test assertion tension value is written into the test assertion tension field, and the updated test requirement analysis results are output. In the specific implementation process, the feedback update module receives test execution feedback corresponding to the decomposition results of 126 test requirements, and extracts test requirement identifiers, execution status, assertion hit status, defect location results and test case coverage results. In a regression test, out of 126 test requirements, 109 were executed and 17 were not executed. Among the executed test requirements, 82 had assertion hit status as passed and 27 had failed. Based on the test requirement identifier, locate the requirement domain nodes, behavior domain nodes, assertion domain nodes, and gap edges in the three-domain test knowledge graph; If execution passes, update the coverage status of the assertion domain node and mark the gap edge as a closed gap; if execution fails, add a defect node or call an existing defect node, generate a defect association edge between the corresponding behavior domain node and the defect node, and write a high-tension update flag; if execution fails or no coverage record is included, retain the gap to be covered. After the update, there were 82 closed gaps, 27 defect-related gaps, and 28 gaps to be covered; the test assertion tension values ​​were recalculated and written into the test assertion tension field, and the number of high-tension demand domain nodes was adjusted from 112 to 74. By synchronously writing back the graph relationships, assertion coverage status, and tension values ​​through test execution feedback, a closed-loop correction basis is provided for the next round of software test requirements analysis.

[0031] Example 1: To verify the feasibility of this invention in implementation, it was applied to a regression testing requirement analysis scenario for an enterprise-level order settlement platform version V3.2.6. This platform includes eight business modules: user authentication, product retrieval, shopping cart settlement, coupon redemption, inventory deduction, payment callback, refund approval, and order status transition. In version V3.2.6, the order status transition, coupon redemption rules, and payment callback interface have changed. Traditional test requirement analysis mainly relies on testers manually breaking down requirements by reading requirement documents and historical test case libraries, which easily leads to the omission of abnormal branches, permission boundaries, and state transition test points.

[0032] The test task identifier T-REG-042 was used as the task number for this regression test. The test platform read the corresponding data from the requirement management library, interface management library, business process library, code repository, test management library, defect management library, and execution log library. After semantic parsing, 486 requirement semantic objects, 713 behavior semantic objects, and 558 assertion semantic objects were obtained. A three-domain test knowledge graph containing 1,757 nodes and 2,727 relationships was further constructed, which generated 1,246 requirement behavior association edges, 1,089 behavior assertion association edges, and 392 test scenario association chains.

[0033] During the test assertion tension modeling process, a total of 137 nodes in the behavior domain to be asserted were identified, forming a test assertion tension field. After improving the Hypergraph Transformer model to perform propagation analysis on the test assertion tension field, tension resonance propagation features were generated through the assertion gap tension resonance mechanism, and test requirement tension propagation feature maps corresponding to 486 requirement domain nodes were output. After gap identification, a total of 137 test verification gaps were obtained, including 54 assertion gaps, 31 state path gaps, 28 abnormal branch gaps, 14 permission boundary gaps, and 10 data boundary gaps. After requirement decomposition and merging of similar requirements, 126 test requirement decomposition results were generated, including 42 high-priority requirements, 57 medium-priority requirements, and 27 low-priority requirements.

[0034] To verify the analytical effect of this invention, it was compared with traditional manual review methods and common knowledge graph requirements analysis methods. Three test managers with more than 5 years of testing experience reviewed the requirements gaps, decomposition results, and defect association results, and the consistent review results were used as the statistical basis. The statistical objects included the identification of test verification gaps, the decomposition of effective test requirements, the number of duplicate invalid requirements, and the analysis time. The results are shown in Table 1 below.

[0035] Table 1 Comparison of different test requirements analysis methods

[0036] As shown in Table 1, the gap identification accuracy of the method of this invention reaches 93.8%, which is 15.2 percentage points higher than the traditional manual review method and 8.9 percentage points higher than the ordinary knowledge graph requirement analysis method; the gap identification recall rate reaches 91.2%, indicating that assertion gaps, state path gaps, abnormal branch gaps, permission boundary gaps, and data boundary gaps can be more fully discovered; the test requirement decomposition efficiency reaches 90.5%, and the duplicate invalid requirement rate is reduced to 6.1%, indicating that the generated test requirements are more focused on real verification gaps, reducing duplicate decomposition and irrelevant test tasks.

[0037] Among them, gap identification accuracy is used to represent the proportion of identified test verification gaps that have been confirmed as valid by the test manager; gap identification recall is used to represent the proportion of real test verification gaps that have been identified by the method; test requirement decomposition effectiveness is used to represent the proportion of generated test requirements that can be directly entered into the test design or test execution phase; duplicate invalid requirement rate is used to represent the proportion of duplicate, irrelevant or unexecutable test requirements in the decomposition results; high-risk gap coverage is used to represent the proportion of gaps associated with high-tension requirement domain nodes that are included in priority test requirements; and average analysis time is used to represent the time required from data reading to outputting test requirement decomposition results.

[0038] In actual execution feedback, of the 126 test requirements, 109 were executed and 17 were not; among the executed test requirements, 82 had assertion hit status as passed and 27 failed; based on the test execution feedback, the system marked 82 gap edges as closed gaps, generated defect association edges for 27 defect-related gaps, and reserved 28 gaps as gaps to be covered; after the test assertion tension field was updated, the number of high-tension requirement domain nodes was adjusted from 112 to 74, indicating that the test execution feedback can effectively write back the three-domain test knowledge graph and correct the focus of the next round of test requirement analysis.

[0039] This invention unifies requirement descriptions, software behavior paths, and test verification assertions into a single graph structure using a three-domain test knowledge graph. It expresses verification pressure and coverage gaps through a test assertion tension field, and enhances the impact of uncovered behavior paths on model propagation through an assertion gap tension resonance mechanism. This allows test requirement analysis to move beyond text classification or test case similarity retrieval, generating executable test requirement decomposition results based on real test verification gaps. In the regression testing scenario of an order settlement platform, this method improves the accuracy of gap identification, the effectiveness of test requirement decomposition, and the feedback loop update capability, demonstrating significant engineering application value.

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

Claims

1. A software testing requirements analysis method based on knowledge graphs, characterized in that, Includes the following steps: Step 1: Collect requirements-side and verification-side data based on the version of the software to be tested and the test task identifier to form a test requirements analysis corpus; Step 2: Perform test semantic parsing on the test requirement analysis corpus, extract requirement semantic objects, behavior semantic objects, and assertion semantic objects to obtain a test requirement semantic object set; Step 3: Construct the relationships between the requirement domain, behavior domain, and assertion domain based on the set of semantic objects of test requirements to obtain a three-domain test knowledge graph; Step 4: Model the test assertion tension of the three-domain test knowledge graph to generate the test assertion tension field; Step 5: Input the test assertion tension field into the improved Hypergraph Transformer model to obtain the test requirement tension propagation feature map. The improved Hypergraph Transformer model includes a three-domain semantic embedding layer, a test scenario hyperedge construction layer, an assertion tension resonance layer, and a coverage gap output layer. The assertion tension resonance layer embeds an assertion gap tension resonance mechanism. Step 6: Identify test verification gaps based on the test requirement tension propagation feature map and generate a test requirement gap map; Step 7: Decompose the semantic objects of the requirements into test requirements based on the test requirement gap diagram to obtain the test requirement decomposition results; Step 8: Receive test execution feedback corresponding to the test requirement breakdown results, update the three-domain test knowledge graph and test assertion tension field based on the test execution feedback, and output the updated test requirement analysis results.

2. The software testing requirements analysis method based on knowledge graphs according to claim 1, characterized in that, Step one specifically involves: Read the version configuration file of the software under test, extract the version number, module identifier, interface identifier and change submission identifier, and concatenate the version number, module identifier, interface identifier and test task identifier into a collection index; Based on the collection index, the requirement description text, interface input and output description, business process node description and change description text are read from the requirement management library, interface management library, business process library and code repository to obtain the requirement-side data; Based on the collection index, existing test cases, defect description texts, defect-related modules, and test execution logs are read from the test management library, defect management library, and execution log library to obtain verification side data; The requirements-side data and verification-side data are converted into unified text fragments, and version tags and source tags are written according to the collection index. Duplicate fragments with the same collection index and the same text hash value are deleted to form a test requirements analysis corpus.

3. The software testing requirements analysis method based on knowledge graphs according to claim 1, characterized in that, Step two specifically involves: Read text fragments from the test requirements analysis corpus, write fragment identifiers, source tags, and collection indexes generated by the software version under test and test task identifiers into the text fragments, and perform preprocessing on the text fragments to remove format specifiers, unify interface names, unify field names, and unify status names to obtain standard text fragments. The standard text fragment is divided into sentences using periods, semicolons, newlines, and list numbers as delimiters, and text position identifiers are generated according to the order in which the sentences appear in the standard text fragment. The clauses are matched with a preset test semantic dictionary, which includes requirement action words, business object words, interface action words, status action words, exception action words, permission constraint words, data boundary words, expected result words, return status words, and verification action words. Sentences that match requirement action words and business object words generate requirement semantic objects; sentences that match interface action words, status action words, exception action words, permission constraint words, or data boundary words generate behavior semantic objects; sentences that match expected result words, return status words, or validation action words generate assertion semantic objects. Write the source tag, collection index, text location identifier, and matched object name into the corresponding semantic object, and merge the requirement semantic objects, behavior semantic objects, and assertion semantic objects with the same collection index and consecutive text location identifiers to obtain the test requirement semantic object set.

4. The software testing requirements analysis method based on knowledge graphs according to claim 1, characterized in that, Step three specifically involves: Map requirement semantic objects in the test requirement semantic object set to requirement domain nodes, behavior semantic objects to behavior domain nodes, and assertion semantic objects to assertion domain nodes, and generate node identifiers based on the object name, object type, source information, and text position relationship carried by the semantic objects. The string matching is performed between the business object name in the requirement semantic object and the interface name, status name, exception name, permission constraint name or data field name in the behavior semantic object. When the match is successful, a requirement behavior association edge is generated between the requirement domain node and the behavior domain node. Based on the interface name, status name, exception name, permission constraint name, or data field name in the behavior semantic object, match it with the return status, output field, log field, or validation condition in the assertion semantic object. When the match is successful, generate a behavior assertion association edge between the behavior domain node and the assertion domain node. Generate a test scenario association chain based on requirement domain nodes, behavior domain nodes, and assertion domain nodes that have the same source information, continuous text position relationship, or the same object name; Write the requirement domain nodes, behavior domain nodes, assertion domain nodes, requirement-behavior association edges, behavior-assertion association edges, and test scenario association chains into a graph database to obtain a three-domain test knowledge graph.

5. The software testing requirements analysis method based on knowledge graphs according to claim 1, characterized in that, Step four specifically involves: Read the requirement domain nodes, behavior domain nodes, and assertion domain nodes associated with the same requirement semantic object from the three-domain test knowledge graph, and generate a requirement verification subgraph. Based on the behavior path size, cross-domain association strength, and assertion node coverage status in the requirement verification subgraph, the requirement verification pressure characteristics are determined. Perform max-min normalization on the demand verification pressure characteristics to obtain normalized demand verification pressure characteristics. Identify assertion coverage gaps based on the association state between behavior domain nodes and assertion domain nodes, and generate assertion coverage gap features based on the assertion coverage gaps; The normalized demand verification pressure features and assertion coverage gap features are input into the tension mapping layer. The tension mapping layer uses linear weighted mapping and Sigmoid function compression to obtain the test assertion tension value. The test assertion tension value is bound to the corresponding requirement domain node, and a test assertion tension field is formed according to the relationship between the requirement domain nodes.

6. The software testing requirements analysis method based on knowledge graphs according to claim 1, characterized in that, Step five specifically involves: The three-domain semantic embedding layer reads the demand domain nodes, behavior domain nodes, assertion domain nodes and test assertion tension values ​​from the test assertion tension field, concatenates the node text features, node domain type features, cross-domain association features and tension features into node joint features, and inputs the node joint features into the linear mapping layer. The linear mapping layer uses fully connected matrix multiplication and superimposed bias to obtain the mapped node features, and then performs layer normalization and missing label masking on the mapped node features to generate three-domain node embedding features. The test scenario hyperedge construction layer uses behavior domain nodes and assertion domain nodes associated with the same requirement domain node as connection objects. It constructs test scenario hyperedges based on test scenario association chains, cross-domain association edges, and assertion gap identifiers generated by assertion coverage gaps. It also writes hyperedge type identifiers, hyperedge tension identifiers, and assertion gap identifiers to test scenario hyperedges and writes isolated node identifiers to unconnected objects. The test scenario hyperedge construction layer generates assertion gap features based on assertion gap identifiers, aggregates the three-domain node embedding features according to the test scenario hyperedge, performs linear projection of query vector, key vector and value vector on the node embedding features within the same test scenario hyperedge, generates attention scores based on the dot product of query vector and key vector, and normalizes the attention scores using the Softmax function to obtain the test scenario hyperedge embedding features. The assertion tension resonance layer invokes the assertion gap tension resonance mechanism to generate tension resonance input features based on assertion gap features and test assertion tension values, and generates tension resonance weights based on the tension resonance input features. The propagation features between demand domain nodes, behavior domain nodes, and assertion domain nodes are modulated based on the tension resonance weights to obtain gap enhancement propagation features. The gap enhancement propagation features are then residually fused and layer normalized with the test scenario hyperedge embedding features to obtain tension resonance propagation features. The covered gap output layer performs residual connection and layer normalization on the tension resonance propagation features, inputs the processed tension resonance propagation features into the nonlinear activation layer, the nonlinear activation layer uses the ReLU function to retain the positive gap response, and then the output mapping layer maps the positive gap response to the corresponding demand domain node to generate a test demand tension propagation feature map carrying the test assertion tension value and tension resonance propagation features.

7. The software testing requirements analysis method based on knowledge graphs according to claim 6, characterized in that, The assertion gap tension resonance mechanism is specifically as follows: Read the behavior domain nodes, assertion domain nodes, assertion gap identifiers and test assertion tension values ​​associated with the same requirement domain nodes from the test scenario hyperedge, and generate assertion gap analysis units; The assertion gap feature is determined based on the connection state between the behavior domain node and the assertion domain node, and the assertion gap feature is concatenated with the test assertion tension value to form the tension resonance input feature; The tension resonance input features are input into the gated mapping layer. The gated mapping layer generates gated intermediate features by using fully connected matrix multiplication and superimposing biases. The gated intermediate features are then converted into tension resonance weights by the Sigmoid function. Based on the tension resonance weight, the propagation characteristics between demand domain nodes, behavior domain nodes and assertion domain nodes are modulated. When the tension resonance weight increases, the propagation intensity from the behavior domain node corresponding to the assertion gap to the demand domain node is increased, and the repeated propagation intensity of the already covered assertion domain node is reduced, thus obtaining the gap-enhanced propagation characteristics. The gap enhancement propagation features and the test scene hyperedge embedding features are residually fused, and the fused features are subjected to layer normalization to obtain the tension resonance propagation features. Update the superedge tension identifier and assertion gap identifier of the corresponding test scenario superedge according to the tension resonance propagation characteristics, and output the tension resonance propagation characteristics to the cover gap output layer.

8. The software testing requirements analysis method based on knowledge graphs according to claim 1, characterized in that, Step six specifically involves: Read the requirement domain nodes, behavior domain nodes, assertion domain nodes, test assertion tension values ​​and tension resonance propagation features corresponding to the same requirement semantic object in the test requirement tension propagation feature map, and generate a gap identification sub-map according to the connection order from requirement domain nodes to behavior domain nodes and from behavior domain nodes to assertion domain nodes. The behavior domain nodes are labeled with types according to interface calls, state transitions, exception triggers, permission constraints, and data boundaries, and the corresponding set of behavior nodes is extracted from the gap identification subgraph based on the type labels. Determine whether each behavior domain node has an assertion domain node with a verification condition. If no assertion domain node with a verification condition exists, generate an assertion gap. Check the continuity between the starting state, intermediate state and ending state according to the direction of the state transition edge. If there is a missing state node or a broken transition direction, generate a state path gap. The abnormal trigger behavior node, permission constraint behavior node, and data boundary behavior node are matched with the abnormal verification conditions, permission verification conditions, and boundary verification conditions in the assertion domain node, respectively. If the matching fails, the corresponding abnormal branch gap, permission boundary gap, and data boundary gap are generated. Write the gap type, gap source node, gap target node, test assertion tension value, and tension resonance propagation characteristics into the corresponding demand domain node, and generate gap edges between the demand domain node and the gap source node to obtain the test demand gap graph.

9. The software testing requirements analysis method based on knowledge graphs according to claim 1, characterized in that, Step seven specifically involves: Read the gap type, gap source node, gap target node and test assertion tension value corresponding to the requirement semantic object in the test requirement gap diagram, and generate requirement decomposition unit; According to the preset gap conversion rules, assertion gaps are converted into assertion supplement test requirements, state path gaps are converted into state transition test requirements, abnormal branch gaps are converted into abnormal handling test requirements, permission boundary gaps are converted into permission verification test requirements, and data boundary gaps are converted into data boundary test requirements. Generate a test object identifier based on the interface name, status name, exception name, permission constraint name, or data field name corresponding to the gap source node, and generate an assertion supplement target based on the verification conditions corresponding to the gap target node; When the gap target node is empty, generate a supplementary assertion target based on the node type of the gap source node and the gap type, and use the supplementary assertion target as the assertion supplement target; Test requirements corresponding to the same requirement semantic object are sorted according to the test assertion tension value, gap type priority, and number of associated gap source nodes to obtain test priority identifiers; Write the test object identifier, assertion supplement target, test priority identifier, and requirement semantic object identifier into the corresponding test requirement to obtain the test requirement decomposition result.

10. The software testing requirements analysis method based on knowledge graphs according to claim 1, characterized in that, Step eight specifically involves: Receive test execution feedback corresponding to the test requirement decomposition results, and extract test requirement identifier, execution status, assertion hit status, defect location results and test case coverage results from the test execution feedback; Based on the test requirement identifier, locate the requirement domain nodes, behavior domain nodes, assertion domain nodes, and gap edges in the three-domain test knowledge graph; When the execution status is executed and the assertion hit status is passed, the coverage status of the corresponding assertion domain node is updated to covered, and the corresponding gap edge is marked as a closed gap. When the execution status is executed and the assertion hit status is failed, a new defect node is added to the three-domain test knowledge graph based on the defect location result, or an existing defect node in the three-domain test knowledge graph is called, and a defect association edge is generated between the corresponding behavior domain node and the defect node, and a high-tension update identifier is written for the corresponding requirement domain node. When the execution status is not executed or the test case coverage result does not contain the corresponding coverage record, the corresponding gap edge is retained as a gap to be covered, and the coverage status of the corresponding assertion domain node is kept as uncovered; The test assertion tension value is recalculated based on the updated coverage status, gap edge status, defect associated edge, and high-tension update identifier. The recalculated test assertion tension value is written into the test assertion tension field, and the updated test requirement analysis results are output.

Images