Aerospace field test case generation method based on knowledge graph

Abstract

The invention discloses an aerospace field test case generation method based on a knowledge graph. The method comprises the following steps: establishing a test field knowledge graph model comprising four layers of entities, namely a test item, a test case, a test process and a problem list; identifying test entities from a historical test document, and establishing inclusion, execution, generation and association relationships among the entities; filling the identified entities and relationships into the knowledge graph model to construct a knowledge graph, and optimizing the constructed knowledge graph; based on an input test item of a to-be-tested item, recommending a most relevant test case entity and a relevant test process and question list information thereof in the constructed and optimized knowledge graph; and inputting the recommended test case, test process and question list information into the large model to generate a structured test case text conforming to a project language style and a test environment. The invention aims to solve the problems of insufficient structuralization, weak reasoning ability and poor dynamic adaptability of the existing test case generation.

Description

Technical Field

[0001] This invention relates to the field of software testing and artificial intelligence, and in particular to a method for generating test cases in the aerospace field based on knowledge graphs. Background Technology

[0002] In software testing within the aerospace field, test case generation typically relies on manual writing based on test outlines, resulting in inefficiency, incomplete scenario coverage, and weak test case relevance. Existing technologies, while some solutions attempt to generate test cases through keyword matching or machine learning models, suffer from the following limitations: insufficient structuring: traditional test outlines are often unstructured text, failing to express the semantic relationships between test objectives, test items, and constraints, leading to fragmented test case generation logic; weak reasoning ability: existing methods lack integration with domain knowledge (such as test types and defect patterns), failing to automatically derive test steps for complex scenarios from the test outline; poor dynamic adaptability: when test requirements or system functions change, test cases must be manually rewritten, resulting in high maintenance costs.

[0003] Knowledge graphs, as a structured semantic knowledge base, have been applied in fields such as root cause analysis of faults. However, they have not yet been deeply optimized for the hierarchical structure and dynamic evolution characteristics of test items, test cases, test processes, and issue sheets. There is an urgent need for a technical solution that can combine semantic modeling of test outlines, intelligent reasoning, and dynamic updates. Summary of the Invention

[0004] Based on the above analysis, this invention aims to provide a knowledge graph-based test case generation method for the aerospace field, addressing the problems of insufficient structure, weak reasoning ability, and poor dynamic adaptability in existing aerospace software testing processes. It proposes a technical solution that combines semantic modeling of test outlines, intelligent reasoning, and dynamic updates.

[0005] This invention provides a knowledge graph-based method for generating test cases in the aerospace field, the method comprising:

[0006] Establish a test domain knowledge graph model that includes four layers of test entities: test items, test cases, test processes, and issue sheets;

[0007] From historical test documents, natural language processing is used to identify test entities, and a method combining rule base and Bayesian network reasoning is used to identify the relationships between entities.

[0008] The identified entities and relationships are filled into the knowledge graph model to construct a knowledge graph. The constructed knowledge graph is then subjected to conflict detection and conflict entity processing to obtain an optimized knowledge graph.

[0009] Based on the test items of the input project to be tested, the test case list is parsed out. According to the test case list, the most relevant test case entity is matched in the constructed and optimized knowledge graph, and the test process and issue form entity that match the test case entity are output.

[0010] Input the recommended test cases, test procedures, and issue information into the large model, and combine them with the current project context to generate structured test case text that conforms to the project's language style and test environment.

[0011] Furthermore, the relationships between entities include:

[0012] The test item "contains" test cases;

[0013] Test cases "execute" the test process;

[0014] The testing process "generated" a problem form;

[0015] There is a "correlation" relationship between test cases and issue tickets.

[0016] Furthermore, the method of identifying relationships between test entities by combining rule bases and Bayesian network inference includes:

[0017] When the following rules of the rule base are met, the corresponding relationships between entities are established:

[0018] When the unique identifier of a test case contains the unique identifier of a test item and the test phase attributes of both are completely identical, an inclusion relationship is established between the test item and the test case.

[0019] When the unique identifier of the test process contains the unique identifier of the test case, an execution relationship is established between the test case and the test process;

[0020] When the unique identifier character of the test process in the problem form matches the unique identifier character of the test process, the generation relationship between the test process and the problem form is established.

[0021] When the testing process establishes both the execution relationship with test cases and the generation relationship with issue tickets, the association between test cases and issue tickets is automatically established.

[0022] When the rules for establishing an inclusion relationship in the rule base are not met, a conditional probability table is built through Bayesian network inference to estimate the probability that the test item and the test case are related, and to determine whether the test item and the test case can establish an inclusion relationship.

[0023] Furthermore, conflict detection mechanisms include:

[0024] Establish conflict detection rules;

[0025] The Protégé rule detection tool is used to detect entities in the knowledge graph based on conflict detection rules.

[0026] Generate a conflict report, including the conflicting entity ID, conflict attributes, conflict relationships, violated rules, and location path.

[0027] Furthermore, the conflict detection rules include:

[0028] Entity ID uniqueness constraint: Entity IDs in a knowledge graph are unique.

[0029] Test case entity names, priorities, and test types cannot all be the same;

[0030] The number of test processes executed for a single test case shall not exceed a set threshold;

[0031] Test case priority is only allowed to be "high / medium / low".

[0032] Furthermore, conflict entity handling includes:

[0033] For duplicate entity IDs, prioritize retaining entities that have been referenced ≥3 times in historical data and delete redundant entities;

[0034] For test cases with identical entity names, priorities, and test types, attribute fusion processing is performed.

[0035] If the number of test processes executed for a single test case exceeds the set threshold, the test processes ranked after the set threshold will be merged with the test processes ranked before the set threshold.

[0036] For test cases whose priority values ​​are not "high / medium / low", change the priority to "high" uniformly.

[0037] Furthermore, the test case list is parsed out in the following way:

[0038] Extract the test case identifier, test case name, and test case description from the "Test Method" field of the test item of the project to be tested. The extracted test case identifier, test case name, and test case description constitute a test case sheet.

[0039] The process of parsing out the test case list includes at least one of the following methods:

[0040] Use regular expression matching to extract content containing explicit numeric serial number features and implicit text serial number features, and extract the test case name and test case description from this content;

[0041] Based on industry experience thesaurus, the function definition title is identified, the function title features are extracted from the "test method" field of the test item, and the test case name and test case description are extracted from the content of the function title features;

[0042] Using hybrid feature parsing, the test case description is obtained by first extracting the serial number feature from the "Test Method" field of the test item. Then, the function title feature is extracted from the obtained test case description. If a new test case description can be obtained, the serial number feature is extracted again. This process is repeated recursively until no new test case description is generated. The test case description obtained from the lowest level of recursion is retained to form the final test case list.

[0043] Furthermore, based on the test case list, the most relevant test case entities matched in the constructed and optimized knowledge graph include:

[0044] Exact matching: When there is a test item in the knowledge graph that is exactly the same as the test item identifier or the test item name of the input test item, the test case entity that matches the test item is used as the recommendation result;

[0045] Fuzzy matching: When an exact match cannot be found, the confidence threshold between the test item of the project under test and the test item in the knowledge graph is calculated based on semantic similarity of name, consistency of attributes, contextual relevance and adoption frequency. If the confidence threshold is ≥0.75, the test item with the highest confidence threshold is selected, and the test case entity matched by the test item is used as the recommendation result.

[0046] Conflict resolution: When multiple test case entities are matched from the knowledge graph for the input test item of the project to be tested, a weighted voting mechanism is used to select the optimal test case entity as the recommendation result.

[0047] Furthermore, the confidence threshold is calculated using the following formula:

[0048] Confidence threshold = 0.4 × name similarity + 0.3 × attribute consistency + 0.2 × context relevance + 0.1 × adoption frequency.

[0049] Furthermore, the method also includes knowledge graph updating. When project test documents are archived, the knowledge graph is updated to extract test item entities from the newly generated project test documents and data, and to calculate the confidence threshold between the test item entity and the test item entities in the knowledge graph.

[0050] If the confidence threshold is less than 0.75, it is considered a new test item entity, and the new test item entity and its matching other three types of entities are added to the knowledge graph.

[0051] If the confidence threshold is ≥0.75, it is considered an existing test item entity. The adoption frequency of test cases matching the test item entity is updated, the confidence threshold is increased, and the probability of test cases matching the existing test item entity in the knowledge graph being recommended is increased.

[0052] The beneficial effects of this technical solution are:

[0053] This invention generates test cases for the aerospace field based on knowledge graphs, which can improve the efficiency of test case generation. Through structured modeling and automatic reasoning, it reduces the time spent manually writing test cases and improves the delivery efficiency of evaluation projects. It also enhances the coverage and accuracy of test case writing by automatically understanding the semantic requirements of the tested project with the help of knowledge graphs and corresponding reasoning algorithms. By using historical data, it avoids the situation where human experience is insufficient, thus improving the coverage and accuracy of test cases. Furthermore, it achieves dynamic adaptability and self-evolution capabilities by dynamically adjusting associated permissions through knowledge graph updates, thereby improving the platform's adaptability.

[0054] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0055] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0056] Figure 1 This is a schematic diagram of a method according to an embodiment of the present invention; Detailed Implementation

[0057] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0058] A specific embodiment of the present invention discloses a method for generating test cases in the aerospace field based on knowledge graphs. The flowchart of the method is shown below. Figure 1 As shown, the specific steps include:

[0059] S1: Establish a test domain knowledge graph model that includes four layers of test entities: test items, test cases, test processes, and issue sheets;

[0060] S2: From historical test documents, natural language processing is used to identify test entities, and a method combining rule base and Bayesian network reasoning is used to identify the relationships between entities;

[0061] S3: Fill the identified entities and relationships into the knowledge graph model to construct a knowledge graph, and perform conflict detection and conflict entity processing on the constructed knowledge graph to obtain an optimized knowledge graph;

[0062] S4: Based on the test items of the input project to be tested, parse out the test case list, match the most relevant test case entity in the constructed and optimized knowledge graph according to the test case list, and output the test process and issue entity that match the test case entity;

[0063] S5: Input the recommended test cases, test procedures, and issue information into the large model, and combine them with the current project context to generate structured test case text that conforms to the project's language style and test environment.

[0064] When implementing S1, a test domain knowledge graph is constructed through four-layer semantic modeling to achieve structured representation and relational reasoning of test entities. This results in a four-layer knowledge graph comprising "test items - test cases - test processes - issue tickets," with the following core entities and entity attributes defined:

[0065] Test item entities have the following attributes: unique identifier, test item name, test item ID, priority, tracing relationship, requirement description, test item description, test method, sufficiency requirements, pass criteria, test type (functional / performance / security), test environment, covered functional points, and test phase.

[0066] For example, a test item entity example is as follows:

[0067]

[0068] Test case entities have the following attributes: unique identifier, test case name, test case identifier, tracing relationship, test description, initialization conditions, prerequisites and constraints, termination conditions, test type, design date, covered functional points, and test phase.

[0069] For example, a test case entity example is as follows:

[0070]

[0071] The test process entity has the following attributes: unique identifier, serial number, input and operation instructions, expected test results, and evaluation criteria.

[0072] For example, a test process entity example is as follows:

[0073]

[0074]

[0075] The problem entity has the following attributes: a unique identifier for the testing process, the problem name, the testing phase, the problem type, the problem level, the problem description, and the developer's comments.

[0076] For example, a sample of a single issue entity is shown below:

[0077]

[0078] In practice, the relationships between entities include:

[0079] The test item "contains" test cases;

[0080] Test cases "execute" the test process;

[0081] The testing process "generated" a problem form;

[0082] There is a "correlation" relationship between test cases and issue tickets.

[0083] Specifically, the semantic relationships between four types of core entities are defined: test items and test cases have an inclusion relationship, as shown in Table 1 below, where one test item contains N test cases; test cases and test processes have an execution relationship, where one test case can execute N test processes; test processes and issue tickets have a generation relationship, where one test process can generate N issue tickets; and test cases and issue tickets have an association relationship, where N test cases can be associated with N issue tickets.

[0084] Table 1

[0085]

[0086] When implementing S2, historical test documentation included:

[0087] Structured data: Excel test case library, JIRA defect management system data;

[0088] Semi-structured data: XML test reports, Markdown test plan documents;

[0089] Unstructured data: Word test summary report, PDF test plan document.

[0090] Specifically, a "column name mapping" method is used to identify test entities for structured data:

[0091] First, create a "standard field dictionary"; then use regular expressions to map the original column names to standard fields; use cell values ​​as entity values ​​and foreign key fields (such as "related requirements") as entity IDs.

[0092] For semi-structured data, the "XPath / table reconstruction" method is used to identify test entities:

[0093] First, split the semi-structured data into "header blocks"; when encountering an ATX header (such as "test range"), assign the next paragraph of text to the "range" entity; when encountering a GitHub-style table, use the function pd.read_html() to convert the GitHub-style table into a DataFrame, and then identify the entity using the "column name mapping" method.

[0094] The following methods are used to identify test entities for unstructured data:

[0095] This program uses Apache Tika to extract text content, processes unstructured data documents using python-docx, applies domain dictionary features (test terminology), identifies entity objects, removes redundant formatting tags, and standardizes dates (YYYY-MM-DD) and status fields (pass / fail).

[0096] During implementation, the method of combining rule base and Bayesian network inference to identify the relationships between test entities includes:

[0097] When the following rules of the rule base are met, the corresponding relationships between entities are established:

[0098] When the unique identifier of a test case contains the unique identifier of a test item and the test phase attributes of both are completely identical, an inclusion relationship is established between the test item and the test case.

[0099] For example, if the test case entity's caseId attribute is represented as case[@caseId="YHDL-001-TC-001"], and the test item entity's itemId attribute is represented as item[@itemId="YHDL-001"], then since the unique identifier of the test case contains the unique identifier of the test item YHDL-001, the test item entity contains the test case.

[0100] When the unique identifier of the test process contains the unique identifier of the test case, an execution relationship is established between the test case and the test process;

[0101] For example, if the test case entity's caseId attribute is represented as case[@caseId="YHDL-001-TC-001"], and the test process entity's caseItemId attribute is represented as caseItem[@caseItemId="YHDL-001-TC-001-001"], since the unique identifier of the test process, YHDL-001-TC-001-001, contains the unique identifier of the test case, YHDL-001-TC-001, then the test process entity establishes an execution relationship with the test case entity.

[0102] When the unique identifier character of the test process in the problem form matches the unique identifier character of the test process, the generation relationship between the test process and the problem form is established.

[0103] For example, if the caseItemId of the issue form entity is the same as the caseItemId of the test process entity, then the test process entity establishes a relationship with the issue form entity.

[0104] When the testing process establishes both the execution relationship with test cases and the generation relationship with issue tickets, the association between test cases and issue tickets is automatically established.

[0105] Understandably, when a testing process establishes both an execution relationship with test cases and a problem ticket generation relationship, then an association is established between the test cases and problem tickets corresponding to that testing process.

[0106] When the rules for establishing an inclusion relationship in the rule base are not met, a conditional probability table is built through Bayesian network inference to estimate the probability that the test item and the test case are related, and to determine whether the test item and the test case can establish an inclusion relationship.

[0107] Specifically, a model P(contains|H1,H2) is constructed using Bayesian network inference. In the model:

[0108] The two text segments covering the functional points of the test item and the functional points of the test case are vectorized using TF-IDF. The semantic similarity between the two semantic vectors is calculated. When the semantic similarity is ≥0.75, H1=1; otherwise, H1=0.

[0109] If any keyword from the test item name appears in the title of the test case, H2 = 1; otherwise, H2 = 0.

[0110] When the rules for establishing an inclusion relationship between test items and test cases in the rule base are not met, the resulting H1 and H2 are input into model P to give the probability that a relationship exists between the test items and test cases:

[0111] With a high correlation probability (≥0.8), the inclusion relationship between test items and test cases is automatically established;

[0112] In the association probability range (0.3–0.8), the inclusion relationship between the test item and the test case is determined manually.

[0113] If the correlation probability is low, it can be directly determined that there is no inclusion relationship between the test item and the test case.

[0114] When implementing S3, the identified entities and relationships are filled into the knowledge graph model to construct the knowledge graph, which is stored using the Neo4j graph database. Conflict detection is performed on the constructed knowledge graph to detect conflicting entities. Conflicting entities are then processed to optimize the constructed knowledge graph and ensure the correctness of the data in the knowledge graph.

[0115] In implementation, the conflict detection mechanism includes:

[0116] Establish conflict detection rules;

[0117] The Protégé rule detection tool is used to detect entities in the knowledge graph based on conflict detection rules.

[0118] Generate a conflict report, including the conflicting entity ID, conflict attributes, conflict relationships, violated rules, and location path.

[0119] For example, the location path for conflict reports is either .git / MERGE_MSG (merge) or .git / rebase-merge / message (rebase), depending on the current operation type. Git is a distributed version control system used to track changes to file content, especially code files.

[0120] Furthermore, the conflict detection rules include:

[0121] Entity ID uniqueness constraint: Entity IDs in a knowledge graph are unique.

[0122] Test case entity names, priorities, and test types cannot all be the same;

[0123] The number of test processes executed for a single test case shall not exceed a set threshold;

[0124] Preferably, the threshold for the number of test processes executed for a single test case is set to 50.

[0125] Test case priority is only allowed to be "high / medium / low".

[0126] Furthermore, besides "high / medium / low," test case priorities can indeed be categorized in other ways, depending on the management needs of the team or project. For example, "extremely high" or "urgent" is common in agile or internet projects, while "critical" is common in projects with security and legal compliance requirements. Allowing only "high / medium / low" values ​​can avoid over-segmentation that might waste effort and reduce communication costs.

[0127] In practice, conflict entity handling includes:

[0128] For duplicate entity IDs, prioritize retaining entities that have been referenced ≥3 times in historical data and delete redundant entities;

[0129] For test cases with identical entity names, priorities, and test types, attribute fusion processing is performed.

[0130] Specifically, the test description attributes of the test case entities are converted into 64-bit hash values ​​using the SimHash algorithm. The Hamming distance between the hash values ​​of two entities is calculated and converted into similarity: similarity = 1 - (Hamming distance / 64). Entities with similarity ≥ 0.85 are merged, and the entity with the "most recent creation time" is selected as the main entity. Null attributes of the main entity are supplemented using attributes of the secondary entity.

[0131] If the number of test processes executed for a single test case exceeds the set threshold, the test processes ranked after the set threshold will be merged with the test processes ranked before the set threshold.

[0132] Specifically, tests are sorted by execution time, with fast tests preceding slow tests. When merging, slow tests are "stuffed" into fast test batches through time windows or executed in parallel with them through parallel merging, in order to reduce the total execution time or the number of batches.

[0133] For test cases whose priority values ​​are not "high / medium / low", change the priority to "high" uniformly.

[0134] When implementing S4, test item data of the project to be tested is input, test case list is parsed, and based on the test case list, the test case knowledge graph of the input project is matched with entities in the knowledge graph. The entire process of outputting test cases and related entities is achieved, realizing targeted recommendation from test items to target entities, and ensuring the relevance, accuracy and diversity of recommendation results.

[0135] Specifically, the test case list is parsed out in the following way:

[0136] Extract the test case identifier, test case name, and test case description from the "Test Method" field of the test item of the project to be tested. The extracted test case identifier, test case name, and test case description constitute a test case sheet.

[0137] The process of parsing out the test case list includes at least one of the following methods:

[0138] Use regular expression matching to extract content containing explicit numeric serial number features and implicit text serial number features, and extract the test case name and test case description from this content;

[0139] For example, the input test item "Test Method" field is:

[0140] "Design effective test cases and use white-box testing and black-box testing methods."

[0141] 1. Initial installation and functional testing are normal.

[0142] Design effective test cases, adopt white-box testing methods, and insert an initial installation card to perform initial installation operations on the module.

[0143] 2. Initial installation function test and anomaly test

[0144] Design invalid test cases and employ black-box testing methods.

[0145] Based on the serial number feature parsing method, the test cases are split into two. The first test case is named "Initial Installation Functionality Test - Normal Test" and its description is "Design valid test cases, use white-box testing methods, insert the initial installation card to perform initial installation operations on the module." The second test case is named "Initial Installation Functionality Test - Abnormal Test" and its description is "Design invalid test cases, use black-box testing methods."

[0146] Based on industry experience thesaurus, the function definition title is identified, the function title features are extracted from the "test method" field of the test item, and the test case name and test case description are extracted from the content of the function title features;

[0147] For example, the input test item "Test Method" field is:

[0148] "Design valid test cases and employ both white-box and black-box testing methods. For initial installation functionality testing, design valid test cases and use white-box testing methods, inserting the initial installation card to perform the initial installation operation on the module. For initial installation functionality testing, design invalid test cases and employ black-box testing methods."

[0149] The function title feature parsing method will split into two test cases. The first test case is named "Initial Installation Function Normal Function Test", and the test description is "Design effective class test cases, use white-box testing methods, insert the initial installation card to perform initial installation operation on the module." The second test case is named "Initial Installation Function Abnormal Function Test", and the test description is "Design invalid class test cases, use black-box testing methods."

[0150] To more accurately parse the test case list, hybrid feature parsing is used to extract the serial number feature from the "Test Method" field of the test item to obtain the test case description. Then, the function title feature is extracted from the obtained test case description. If a new test case description can be obtained, the serial number feature is extracted again. This process is recursively repeated until no new test case description is generated. The test case description obtained from the lowest level of recursion is retained to form the final test case list.

[0151] For example, the input test item "Test Method" field is:

[0152] "Design effective test cases and use white-box testing and black-box testing methods."

[0153] (1) Initial installation device start-up self-test

[0154] Initial installation and boot function testing: 1) Perform hardware checks. Check hard drive, memory, motherboard, and other hardware. 2) Perform software checks. Check BIOS version, driver version, and other software.

[0155] During initial installation and functional testing, the hard drive was removed, and the "no hard drive" information was recorded.

[0156] Using a hybrid feature parsing method, after multiple rounds of recursion, the test cases were finally split into two. The first test case was named "Initial Device Startup Self-Test - Initial Startup Functionality Test - Hardware Check", with the test description "Check hardware such as hard drive, memory, and motherboard." The second test case was named "Initial Device Startup Self-Test - Initial Startup Functionality Test - Software Check", with the test description "Check software such as BIOS version and driver version."

[0157] Furthermore, based on the test case list, the most relevant test case entities matched in the constructed and optimized knowledge graph include:

[0158] Exact matching: When there is a test item in the knowledge graph that is exactly the same as the test item identifier or the test item name of the input test item, the test case entity that matches the test item is used as the recommendation result;

[0159] Fuzzy matching: When an exact match cannot be found, the confidence threshold between the test item of the project under test and the test item in the knowledge graph is calculated based on semantic similarity of name, consistency of attributes, contextual relevance and adoption frequency. If the confidence threshold is ≥0.75, the test item with the highest confidence threshold is selected, and the test case entity matched by the test item is used as the recommendation result.

[0160] Furthermore, the confidence threshold is calculated using the following formula:

[0161] Confidence threshold = 0.4 × name similarity + 0.3 × attribute consistency + 0.2 × context relevance + 0.1 × adoption frequency;

[0162] In the formula, name similarity is the semantic similarity between the test item name of the input test item and the test item name in the knowledge graph, with a value range of 0 to 1.

[0163] Attribute consistency: Compare the overlap between the test items of the input test item and the test items in the knowledge graph in terms of test type, priority, and test environment. The value range is 0 to 1.

[0164] Contextual relevance: The semantic similarity between the test item of the input test project and the test item in the knowledge graph, with a value ranging from 0 to 1;

[0165] Adoption frequency: The frequency with which test cases are selected and executed by test subjects after intelligent recommendation. It is obtained by recording the number of times a test case is recommended and the number of times it is selected and adopted after recommendation in the knowledge graph. The value range is 0 to 1.

[0166] Conflict resolution: When multiple test case entities are matched from the knowledge graph for the input test item of the project to be tested, a weighted voting mechanism is used to select the optimal test case entity as the recommendation result.

[0167] Furthermore, the weighted voting mechanism includes voting dimensions and weights: name similarity (40%), attribute consistency (30%), historical recommendation frequency (20%), and associated fault repair rate (10%); calculate the total voting score for each candidate test case entity, and select the test case entity with the highest score as the recommendation result.

[0168] When implementing S5, test cases, test process information, and issue ticket information recommended based on knowledge graphs are input into the large model. The large model then generates structured test case text that conforms to the project's language style and testing environment based on prompts and the current project context. The prompts can be provided through prompt templates, providing the following elements:

[0169] System instructions: Define the test case generation task and format requirements;

[0170] Current project information and knowledge graph test case information: information such as the test environment and historical test cases of the project under test, as well as the matched test case entities and related information;

[0171] Output format constraints: Use XML tags to define the test case structure.

[0172] For example, a prompt word template is as follows:

[0173] System instruction: You are a test case generation expert. Please generate structured test cases based on the following information.

[0174] Requirements: 1) Include use case ID, title, preconditions, steps, and expected results; 2) Steps should be clear and executable; 3) Cover abnormal scenarios.

[0175] Current project information:

[0176] - Test item: {testItem.name} (Priority: {testItem.priority})

[0177] - Environment information: {testItem.environment}

[0178] -Related Entities: {relatedEntities}

[0179] Knowledge graph test case information:

[0180] {similarTestCases}

[0181] Output format:

[0182] <testcase>

[0183] <id>< / id>

[0184] <title>< / title>

[0185] <precondition>< / precondition>

[0186] <steps>

[0187] <step> Testing process< / step>

[0188] < / steps>

[0189] <expected> Test issues< / expected>

[0190] < / testcase> .

[0191] In implementation, the method also includes knowledge graph updating. When project test documents are archived, the knowledge graph is updated to extract test item entities from the newly generated project test documents and data, and to calculate the confidence threshold between the test item entity and the test item entities in the knowledge graph.

[0192] If the confidence threshold is less than 0.75, it is considered a new test item entity, and the new test item entity and its matching other three types of entities are added to the knowledge graph.

[0193] If the confidence threshold is ≥0.75, it is considered an existing test item entity. The adoption frequency of test cases matching the test item entity is updated, the confidence threshold is increased, and the probability of test cases matching the existing test item entity in the knowledge graph being recommended is increased.

[0194] Specifically, the adoption frequency of test cases that update the entity matching of this test item is obtained using the following formula:

[0195] W = W + 0.01;

[0196] In the formula, W is the frequency of adoption, and 0.01 is a custom increment value for the frequency of adoption.

[0197] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0198] 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 changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for generating test cases in the aerospace field based on knowledge graphs, characterized in that, Includes the following steps: Establish a test domain knowledge graph model that includes four layers of test entities: test items, test cases, test processes, and issue sheets; From historical test documents, natural language processing is used to identify test entities, and a method combining rule base and Bayesian network reasoning is used to identify the relationships between entities. The identified entities and relationships are filled into the knowledge graph model to construct a knowledge graph. The constructed knowledge graph is then subjected to conflict detection and conflict entity processing to obtain an optimized knowledge graph. Based on the test items of the input project to be tested, the test case list is parsed out. According to the test case list, the most relevant test case entity is matched in the constructed and optimized knowledge graph, and the test process and issue form entity that match the test case entity are output. Input the recommended test cases, test procedures, and issue information into the large model, and combine them with the current project context to generate structured test case text that conforms to the project's language style and test environment.

2. The aerospace test case generation method based on knowledge graphs according to claim 1, characterized in that, The relationships between entities include: The test item "contains" test cases; The test case "executes" the test process; The testing process "generated" a problem form; There is a "correlation" relationship between test cases and issue tickets.

3. The aerospace test case generation method based on knowledge graphs according to claim 1, characterized in that, Identifying relationships between test entities using a method combining rule bases and Bayesian network inference includes: When the following rules of the rule base are met, the corresponding relationships between entities are established: When the unique identifier of a test case contains the unique identifier of a test item and the test phase attributes of both are completely identical, an inclusion relationship is established between the test item and the test case. When the unique identifier of the test process contains the unique identifier of the test case, an execution relationship is established between the test case and the test process; When the unique identifier character of the test process in the problem form matches the unique identifier character of the test process, the generation relationship between the test process and the problem form is established. When the testing process establishes both the execution relationship with test cases and the generation relationship with issue tickets, the association between test cases and issue tickets is automatically established. When the rules for establishing an inclusion relationship in the rule base are not met, a conditional probability table is built through Bayesian network inference to estimate the probability that the test item and the test case are related, and to determine whether the test item and the test case can establish an inclusion relationship.

4. The aerospace test case generation method based on knowledge graphs according to claim 1, characterized in that, The conflict detection mechanism includes: Establish conflict detection rules; The Protégé rule detection tool is used to detect entities in the knowledge graph based on conflict detection rules. Generate a conflict report, including the conflicting entity ID, conflict attributes, conflict relationships, violated rules, and location path.

5. The aerospace test case generation method based on knowledge graphs according to claim 4, characterized in that, The conflict detection rules include: Entity ID uniqueness constraint: Entity IDs in a knowledge graph are unique. Test case entity names, priorities, and test types cannot all be the same; The number of test processes executed for a single test case shall not exceed a set threshold; Test case priority is only allowed to be "high / medium / low".

6. The aerospace test case generation method based on knowledge graphs according to claim 1, characterized in that, The conflict entity handling includes: For duplicate entity IDs, prioritize retaining entities that have been referenced ≥3 times in historical data and delete redundant entities; For test cases with identical entity names, priorities, and test types, attribute fusion processing is performed. If the number of test processes executed for a single test case exceeds the set threshold, the test processes ranked after the set threshold will be merged with the test processes ranked before the set threshold. For test cases whose priority values ​​are not "high / medium / low", change the priority to "high" uniformly.

7. The method for intelligent generation of self-evolving test cases based on knowledge graphs according to claim 1, characterized in that, The test case list is parsed using the following method: Extract the test case identifier, test case name, and test case description from the "Test Method" field of the test item of the project to be tested. The extracted test case identifier, test case name, and test case description constitute a test case sheet. The process of parsing out the test case list includes at least one of the following methods: Use regular expression matching to extract content containing explicit numeric serial number features and implicit text serial number features, and extract the test case name and test case description from this content; Based on industry experience thesaurus, the function definition title is identified, and the function title features are extracted from the "test method" field of the test item. The test case name and test case description are then extracted from the content of the function title features. Using hybrid feature parsing, the test case description is obtained by first extracting the serial number feature from the "Test Method" field of the test item. Then, the function title feature is extracted from the obtained test case description. If a new test case description can be obtained, the serial number feature is extracted again. This process is repeated recursively until no new test case description is generated. The test case description obtained from the lowest level of recursion is retained to form the final test case list.

8. The aerospace test case generation method based on knowledge graphs according to claim 1, characterized in that, The process of matching the most relevant test case entities in the constructed and optimized knowledge graph based on the test case list includes: Exact matching: When there is a test item in the knowledge graph that is exactly the same as the test item identifier or the test item name of the input test item, the test case entity that matches the test item is used as the recommendation result; Fuzzy matching: When an exact match cannot be found, the confidence threshold between the test item of the project under test and the test item in the knowledge graph is calculated based on semantic similarity of name, consistency of attributes, contextual relevance and adoption frequency. If the confidence threshold is ≥0.75, the test item with the highest confidence threshold is selected, and the test case entity matched by the test item is used as the recommendation result. Conflict resolution: When multiple test case entities are matched from the knowledge graph for the input test item of the project to be tested, a weighted voting mechanism is used to select the optimal test case entity as the recommendation result.

9. The aerospace test case generation method based on knowledge graphs according to claim 8, characterized in that, The confidence threshold is calculated using the following formula: Confidence threshold = 0.4 × name similarity + 0.3 × attribute consistency + 0.2 × context relevance + 0.1 × adoption frequency.

10. The aerospace test case generation method based on knowledge graphs according to claim 1, characterized in that, The method also includes knowledge graph updating. When project test documents are archived, the knowledge graph is updated to extract test item entities from the newly generated project test documents and data, and to calculate the confidence threshold between the test item entity and the test item entities in the knowledge graph. If the confidence threshold is less than 0.75, it is considered a new test item entity, and the new test item entity and its matching other three types of entities are added to the knowledge graph. If the confidence threshold is ≥0.75, it is considered an existing test item entity. The adoption frequency of test cases matching the test item entity is updated, the confidence threshold is increased, and the probability of test cases matching the existing test item entity in the knowledge graph being recommended is increased.

Images