An airborne software test case automatic generation method based on natural language requirement

Abstract

The application discloses a kind of based on natural language demand's airborne software test case automatic generation method, this method includes the following contents: to the input natural language airborne software demand document is read, specification inspection and standardization processing, form standardization demand entry text;Extract input and output variable piece by piece, generate variable interface description model, convert demand logic into functionized demand entry expressed in Python syntax;Based on functionized demand entry, build abstract syntax tree, build conditional logic model and generate the test case of single demand meeting MC / DC coverage criterion;According to variable interface description model, build the call relationship graph between demand entries, carry out semantic execution, result binding and cross-logic unit propagation combination to local test entry, form the test case set of complex demand link-oriented.The method can improve the automation degree, logic consistency and coverage sufficiency of test case generation in airborne software demand verification.

Description

Technical Field

[0001] This invention relates to the field of airborne software testing technology, and more specifically to a method for automatically generating airborne software test cases based on natural language requirements. Background Technology

[0002] Airborne software is a crucial component of avionics systems, enabling information perception, logical computation, control decision-making, and state interaction. Its functional correctness, logical consistency, and operational reliability directly impact the safety and stability of the airborne system. During the development, verification, and airworthiness review of airborne software, requirement-based test case design is a vital technical means to ensure the software meets design requirements and safety specifications. This is especially true for high-level requirements containing input variables, output variables, state constraints, threshold conditions, and complex decision logic. Whether test cases accurately cover the key logical relationships within the requirements directly affects the sufficiency and rigor of the software verification results. With the continuous increase in the functional complexity of airborne systems, the expanding size of requirement documents, and the increasingly complex logical chains, how to efficiently and accurately generate test cases from natural language requirement descriptions has become an important research direction in the field of airborne software testing. Existing technologies typically involve manually reading requirements and then designing tests, using scripts or spreadsheets to semi-structure requirements, and employing formal modeling methods to automatically analyze some requirement logic. However, a unified automated processing chain from natural language requirements to complex test case sets has not yet been established.

[0003] Existing airborne software requirements are typically given in natural language documents, commonly in formats such as PDFs, spreadsheets, and text. Testers generally need to first read, filter, and organize the requirements document, then manually extract variables and analyze the logical processing flow based on the input-output relationships, conditional branches, decision chains, and result constraints in the requirements, and design test inputs and expected outputs accordingly. This approach is feasible when the requirements are small in scale, but when there are many requirements, inconsistent document formats, or ambiguous requirements, the manual processing is easily affected by experience level and misunderstanding biases, leading to inaccurate variable extraction, incomplete identification of logical relationships, and difficulty in ensuring consistency among requirements. To reduce the manual burden, some existing solutions attempt to use scripting tools, table rules, or template methods to convert the format of the requirements and perform preliminary structuring. However, these solutions usually only solve problems such as reading the requirements document, organizing fields, or merging simple statements, and are difficult to further achieve a stable conversion from natural language requirements to a computable logical representation, especially failing to support subsequent conditional modeling and automated test generation.

[0004] On the other hand, for the multi-branch decision logic, multi-condition combination relationships, and multi-requirement correlation links commonly found in airborne software, existing solutions, even if they can achieve some structured processing at the single-requirement level, often still remain in a "manually-driven" test design mode. In scenarios with high coverage requirements, such as when it is necessary to meet the modified condition decision coverage MC / DC criterion, testers still need to analyze each of the multiple atomic conditions in the condition expression and manually construct test inputs that can reflect changes in the decision result. This process is not only labor-intensive but also prone to problems such as insufficient coverage or duplicate test items. Furthermore, most existing technologies conduct test design for single requirements or single logical units, lacking the ability to establish logical unit call relationships based on variable dependencies and to propagate and combine across requirements and logical units, thus making it difficult to form a set of test cases for complex requirement links. For requirement scenarios with upstream and downstream output-input correlations, existing solutions often cannot effectively handle the result binding, variable conflict resolution, and duplicate item removal issues between local test items, thereby affecting the consistency, traceability, and engineering usability of test results.

[0005] Therefore, while existing technologies can solve some problems in requirements document reading, partial structured processing, and local test-aided design, they still suffer from insufficient automation, difficulty in unified modeling of requirements logic, challenges in generating MC / DC coverage, and difficulty in handling complex requirements chains holistically. Based on this, it is necessary to propose a new method for automatically generating airborne software test cases based on natural language requirements. This method should be able to perform unified processing of standardized requirements text generation, Python-like syntax intermediate representation construction, abstract syntax tree modeling, conditional logic modeling, MC / DC coverage constraint solving, and cross-logic unit propagation and combination, all centered around natural language requirements documents. This would improve the efficiency of test case generation, coverage completeness, result consistency, and testing rigor during the airborne software requirements verification process. Summary of the Invention

[0006] The purpose of this invention is to provide an automatic test case generation method for airborne software based on natural language requirements. This method addresses the problems in existing technologies where airborne software requirements are mostly presented in natural language documents, requirement descriptions are inconsistent, logical relationships are difficult to calculate directly, test design relies on manual analysis, and it is difficult to simultaneously achieve MC / DC coverage and cross-requirement propagation. This improves the automation level, test generation efficiency, logical completeness, and test case rigor in the airborne software requirement verification process. This invention constructs a complete processing chain from requirement document input to test case set output, based on airborne software requirements described in natural language. This method reads, inspects, and standardizes the original requirement document, generating standardized requirement text suitable for subsequent processing. Based on this, it progressively converts the natural language requirements into a Python-like intermediate representation and an abstract syntax tree structure, achieving unified modeling of conditional branching relationships, decision chains, and return logic. Further, by combining conditional logic modeling and coverage constraint solving, it automatically generates single requirement test cases that satisfy the MC / DC coverage criterion. Finally, it establishes calling relationships between logical units through dependencies between variables and performs semantic execution, result binding, and cross-logical unit propagation combination on test items, forming a set of test cases for complex requirement chains. Through the above technical solution, this invention achieves a systematic processing from natural language requirements to automatic test case generation.

[0007] To achieve the above objectives, the present invention adopts the following technical solution:

[0008] A method for automatically generating airborne software test cases based on natural language requirements, characterized by the following specific steps:

[0009] Step 1: Based on the input airborne software requirements expressed in natural language, standardize the process, extract the requirement information, and convert the original requirements into standardized requirement item text;

[0010] Step 2: Analyze the standardized requirement text item by item, use the large language model to extract the input variables, output variables and intermediate variables corresponding to each requirement, and generate the variable interface description model corresponding to each requirement; extract the condition triggering relationship, logical combination relationship and output assignment relationship in the standardized requirement text, and convert the natural language form of the requirement into a function-based requirement item with Python-like syntax based on the large language model;

[0011] Step 3: Construct a formal abstract syntax tree structure based on the functional requirement items represented by Python-like syntax, perform unified modeling of conditional branching relationships, decision chains and return logic, complete conditional logic modeling, and generate test cases for individual requirements based on the MC / DC coverage criterion.

[0012] Step 4: Obtain the dependencies between variables through the variable interface description model, establish a call relationship graph between requirement items, determine the call relationship of each requirement logic unit based on the call relationship graph, and perform semantic execution, result binding and cross-logic unit propagation combination on the test input of a single requirement to form a test case set for complex requirement links.

[0013] Furthermore, step 1 specifically includes:

[0014] The input airborne software requirements are provided in document form, which includes one or more of the following formats: PDF document, spreadsheet document, and text document;

[0015] After reading and extracting the text from the document-based airborne software requirements, the different formats of the requirement text are converted into text content in a unified format.

[0016] The extracted text content is checked for standardization. Issues such as missing descriptions, incomplete fields, non-standard formatting, or non-standard descriptions in the requirement items are detected, and prompts are output to indicate the existence of non-standard requirement items.

[0017] The text content that passes the standardization check is uniformly standardized and the expression format is standardized so that each standardized requirement item text includes a requirement identifier, requirement name and requirement description, generating standardized requirement item text for subsequent requirement analysis.

[0018] Furthermore, step 2, generating the variable interface description model corresponding to each requirement, specifically includes:

[0019] Based on the requirements, the corresponding input variables, output variables, and intermediate variables are extracted, and the extracted variables are normalized to obtain variable names in a unified format.

[0020] The input variables are used to represent the external input quantities that the requirement items rely on when performing conditional judgments or calculations. The output variables are used to represent the external output quantities generated after the requirement items are executed. The intermediate variables are used to represent the variables that are calculated or derived from the external input quantities and participate in the generation of external output quantities during the requirement logic processing.

[0021] Based on the value descriptions, status descriptions, comparison relationships, or threshold relationships in the requirement items, extract the variable type, legal value range, optional value set, or threshold constraint for each variable;

[0022] The requirement identifier, requirement name, input variables, output variables, intermediate variable set, variable function type, and variable constraint information are written into a preset field structure to generate a variable interface description model, and to determine the set of variables that need to be processed in the subsequent test case generation process.

[0023] Furthermore, step 2, which involves converting the requirements in natural language form into functional requirements represented by Python-like syntax based on a large language model, specifically includes:

[0024] The standardized requirement item text and the interface description model are input into the large language model, and a preset Python-like grammar transformation rule is applied to the large language model.

[0025] Python-like grammar transformation rules describe intermediate representations of Python-like syntax, including function description structures, statement block structures, conditional branch structures, expression structures, and return structures.

[0026] Based on Python-like grammar transformation rules, the large language model generates function names based on the requirement identifiers in the standardized requirement entry text and the variable interface description model; it also generates function parameter lists based on the variable set in the variable interface description model; based on the statement execution order in the standardized requirement entry text, it generates statement block structures to carry sequentially executed statements in function bodies or branch bodies; based on the condition judgment content, it generates conditional branch structures including one or more of if, elif, and else branches; based on variable names, constant values, comparison operators, and logical operators, it generates expression structures representing conditional expressions; and based on the result output content, it generates return structures including return keywords and return expressions.

[0027] Based on the function description structure, statement block structure, conditional branch structure, expression structure, and return structure, functional requirement entries with Python-like syntax representation are generated.

[0028] Furthermore, the function description structure is used to characterize the logical unit definition corresponding to a single requirement, including a function name, a function parameter list, and a function body; wherein, the function name is generated based on the requirement identifier, the function parameter list is generated based on the variable interface description model of the requirement item, and the function body is used to carry the logical processing statements of the requirement item;

[0029] The statement block structure is used to represent a set of sequentially executed statements in a function body or branch body. The statement block structure determines the inclusion relationship and execution scope between statements through indentation level or statement nesting relationship.

[0030] The conditional branch structure is used to represent the condition judgment logic and branch execution logic in the requirements. The conditional branch structure includes one or more of if branch, elif branch and else branch. The if branch and elif branch respectively include a conditional expression and a corresponding branch statement block. The else branch includes a branch statement block that is executed when none of the preconditions are met.

[0031] The expression structure is used to characterize the conditional expression in the conditional branch structure. The expression structure includes variable names, constant values, comparison operators, and logical operators. The comparison operators are used to represent comparison relationships, and the logical operators are used to represent logical combination relationships between multiple conditions.

[0032] The return structure is used to characterize the output logic of the result after the requirement is processed. The return structure includes a return keyword and a return expression. The return expression corresponds to the output variable, output constant or output result calculated from the input variable and intermediate variable of the requirement item.

[0033] Furthermore, step 3, which involves constructing an abstract syntax tree structure based on a Python-like intermediate representation, specifically includes:

[0034] Lexical analysis is performed on the aforementioned Python syntax intermediate representation to identify keywords, variable names, constants, operators, delimiters, indentation marks, and newline marks, generating a sequence of lexical units;

[0035] The lexical unit sequence is subjected to syntactic analysis, and function definition statements, statement block statements, conditional branch statements, expression statements and return statements are identified according to preset Python-like grammar rules to generate a syntax analysis tree;

[0036] An abstract syntax tree is constructed based on the parsing tree, and the abstract syntax tree includes function definition nodes, statement block nodes, conditional branch nodes, expression nodes, and return nodes;

[0037] The function definition node is used to represent the functional logic unit corresponding to a single requirement; the statement block node is used to represent the sequential execution structure in the requirement item; the conditional branch node is used to represent the conditional judgment structure in the requirement item; the expression node is used to represent conditional expressions, comparison expressions, and logical expressions; and the return node is used to represent the output rules of the output variable.

[0038] Furthermore, step 3 involves unified modeling of conditional branching relationships, decision chains, and return logic to complete conditional logic modeling and generate test cases for a single requirement that meet the MC / DC coverage criterion. Specifically, this includes:

[0039] Extract function definition nodes from the abstract syntax tree, and extract condition branch nodes and return nodes based on the function definition nodes; organize the if branches, elif branches, and else branches in the same condition judgment structure into a decision chain structure according to the execution order; extract the corresponding condition expression and branch statement block for each branch of the decision chain structure, and extract the return node from the branch statement block to generate the execution result structure corresponding to each branch;

[0040] The decision chain structure is used to characterize the branch selection rules of the requirement item, and the execution result structure is used to characterize the output result corresponding to each branch being hit. The decision chain structure and the execution result structure are used together for subsequent conditional logic modeling, constraint coverage solving and test case generation.

[0041] The decision chain is converted into a logical expression that can be processed by the constraint solver, and the atomic conditions in the logical expression are extracted to generate a conditional logic model that includes the overall decision expression, the set of atomic conditions and their combination relationships.

[0042] For each target atomic condition in the conditional logic model, an MC / DC coverage constraint is constructed. The MC / DC coverage constraint is used to limit the truth values ​​of target atomic conditions in two test vectors to be opposite, the truth values ​​of other atomic conditions to be the same, and the results of the overall decision expression to be opposite. Based on the MC / DC coverage constraint, the test cases for a single requirement that satisfy the MC / DC coverage criterion are generated.

[0043] Furthermore, the generation of test cases for a single requirement that satisfy the MC / DC coverage criterion specifically includes:

[0044] For each atomic condition in the conditional logic model, construct test input pairs; change the value of the target atomic condition while keeping the value of the non-target atomic condition unchanged; when the overall judgment result changes with the target atomic condition, determine that the corresponding test input pair satisfies the MC / DC coverage criterion; record the test input pairs that satisfy the MC / DC coverage criterion as test cases for a single requirement.

[0045] Furthermore, step 4, which describes obtaining the dependencies between variables through the variable interface description model and establishing a call relationship graph between requirement items, specifically includes:

[0046] Based on the variable interface description model corresponding to each requirement item, obtain the variable set for each requirement item, determine each requirement item as a requirement logic unit, and use the requirement logic unit as a graph node;

[0047] When the output variable of the upstream demand logic unit matches the input variable of the downstream demand logic unit, a dependency edge is established between the upstream demand logic unit and the downstream demand logic unit, and a call relationship graph between demand items is constructed based on each demand logic unit and its dependency edge.

[0048] Furthermore, step 4, which involves forming a test case set oriented towards complex requirement chains, specifically includes:

[0049] Semantic execution is performed on the single requirement test input corresponding to each requirement logic unit to obtain the output variable value. The input variable assignment, atomic condition truth value, requirement judgment result and output variable value are combined into a local test item.

[0050] The calling relationship is determined based on the calling relationship diagram between the demand items. The local test items of the upstream logic unit are propagated to the downstream logic unit, and the output variable value of the upstream logic unit is used as the input variable value of the downstream logic unit. The consistency of variable assignment is checked on the local test items after propagation and combination.

[0051] When there is a conflict in the values ​​of variables with the same name, the corresponding propagation combination result is discarded; when there is no conflict in the values ​​of variables with the same name, the variable assignment tables of each local test item are merged, the propagation path information, branch hit information and output information are recorded, and test cases for complex requirement links are generated.

[0052] The uniqueness of the test cases for the complex requirement chain is determined, duplicate test cases are removed, and an optimized set of test cases is formed.

[0053] Compared with the prior art, the present invention has the following beneficial effects: The present invention establishes a complete automated processing link from the original requirement document to the final test case set based on the airborne software requirements described in natural language form. It can unify requirement document reading, standardization check, requirement parsing, structure transformation, formal modeling, test generation and propagation into the same technical solution, thereby reducing the reliance on manual line-by-line analysis in the traditional test design process and improving the efficiency of test case generation.

[0054] By converting standardized requirement text into a Python-like intermediate representation and further constructing an abstract syntax tree, a unified expression and formal modeling of the internal conditional branching relationships, decision chains, and return logic of the requirements are achieved. This enables natural language requirements that are originally difficult to process directly to be transformed into analyzable and solvable logical structures, thereby improving the accuracy of requirement logic identification and the stability of subsequent test generation.

[0055] By constructing a conditional logic model and introducing a coverage constraint solving mechanism, test cases that meet the MC / DC coverage criteria can be automatically generated for a single requirement. This transforms the construction process of test inputs from being driven by human experience to an automatic solving process based on the logic model, thereby enhancing the coverage integrity, logical rigor, and verifiability of single requirement tests.

[0056] By establishing calling relationships between logical units through dependencies between variables, and performing semantic computation, result binding, and cross-logical unit propagation and combination on test items, test cases can not only cover single requirement logic, but also be extended and combined along complex requirement chains, thereby improving the consistency, traceability, and engineering applicability of test results in multi-requirement related scenarios.

[0057] Introducing variable consistency verification, conflict resolution, and duplicate entry removal mechanisms during the propagation and combination process can effectively reduce invalid test entries and redundant test cases in the propagation chain, improve the executability, accuracy, and quality of the final test case set, and provide more rigorous and efficient technical support for airborne software requirement verification. Attached Figure Description

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

[0059] Figure 2 This is a flowchart illustrating the generation of standardized requirement text based on natural language requirement documents according to the present invention.

[0060] Figure 3 This is a flowchart illustrating the functionalized requirement entries generated from standardized requirement text using Python syntax, as described in this invention.

[0061] Figure 4 This is a flowchart illustrating the construction of test cases for a single requirement based on functionalized requirement items in this invention.

[0062] Figure 5 This is a flowchart illustrating how test cases for a complex requirement chain are formed from test cases for a single requirement. Detailed Implementation

[0063] The embodiments of the technical solution of the present invention will now be described with reference to the accompanying drawings. The processes, conditions, and experimental methods for implementing the present invention, except as specifically mentioned below, are all common knowledge and general knowledge in the field, and the present invention does not impose any particular limitations.

[0064] like Figure 1As shown, this invention provides an automatic generation method for airborne software test cases based on natural language requirements. First, an airborne software requirement document expressed in natural language is input. The document is then read, extracted, checked for standardization, and processed to extract requirement information such as requirement identifiers, names, and descriptions, generating standardized requirement item text. Subsequently, each standardized requirement item text is analyzed, extracting the input variables, output variables, and intermediate variables corresponding to each requirement. Combined with information such as variable type, value range, possible value set, and threshold constraints, a variable interface description model corresponding to the requirement is generated. Further, the standardized requirement item text and its corresponding variable interface description model are input into a large language model. Following preset Python-like grammar conversion rules, functionalized requirement items represented in Python syntax are generated. After obtaining the functionalized requirement items, a formal abstract syntax tree structure is constructed, and test cases for individual requirements are generated based on the MC / DC coverage criterion. Based on the generated individual requirement test cases, the dependency relationships between variables are further obtained based on the variable interface description models corresponding to each requirement, establishing a call relationship graph between requirement items. Finally, based on the aforementioned call relationship graph, semantic execution, result binding, and cross-logic unit propagation are performed on the single requirement test input. After variable assignment consistency verification and duplicate test case removal, a set of test cases for complex requirement chains is generated.

[0065] The specific process of reading requirements documents and generating standardized requirements item text is as follows: Figure 2 As shown, the process includes steps such as requirement reading and text extraction, document type identification, classification and processing of documents of different formats, generation of unified format text, rule-based processing, structural rule determination, and unified standard processing.

[0066] During the requirements reading and text extraction phase, an airborne software requirements document expressed in natural language is input. This airborne software requirements document can be one or more of the following: a PDF document, a spreadsheet document, or a text document. The original requirements text content is obtained based on the input document.

[0067] In the document type identification and classification stage, the document type of the airborne software requirement document is identified, and classification processing is performed based on the identified document type. For PDF documents, the main text, paragraph content, and tabular requirement content are extracted; for spreadsheet documents, requirement item information is extracted according to row, column, cell content, and header fields; for text documents, requirement content is extracted according to paragraphs, numbering, headings, or preset delimiters. Through the above classification processing of different document formats, the content of requirement documents from different sources and in different formats is converted into a unified format text.

[0068] In the unified format text generation and rule-based processing stage, the basic organizational form of the requirement document and the criteria for determining valid requirement items are defined, enabling subsequent processing to determine whether each requirement item can be entered into the subsequent parsing process as a valid requirement item. The basic organizational form includes the field composition, field order, requirement number format, requirement name position, and requirement description content range of the requirement item; the criteria for determining valid requirement items include the existence of requirement identifier, the completeness of requirement name, whether the requirement description has parsable logical content, whether the text boundaries of the same requirement item are clear, and whether the item format conforms to the preset structure rules, the specific preset structures are listed in Table 1.

[0069] During the structure rule determination phase, it is determined whether the rule-processed requirement text conforms to preset structure rules. When a requirement item is detected to have missing descriptions, incomplete fields, formatting issues, or non-standard expressions, a prompt message is output to indicate the existence of non-standard requirement items. The prompt message is used to identify the location of the non-standard requirement item, missing fields, or content that does not conform to the rules. After correcting the corresponding requirement item according to the prompt message, the corrected requirement text re-enters the preset structure rule determination process until it meets the preset structure rules.

[0070] During the standardization phase, the order of requirement fields is standardized, the format of requirement identifiers is standardized, blank characters and invalid symbols are cleaned up, and multi-line text content of the same requirement item is merged, organizing requirement content from different document sources into a consistent data structure. After the above processing, standardized requirement item text is generated. Each standardized requirement item text includes a requirement identifier, a requirement name, and a requirement description, which are used in subsequent variable interface description model generation, function-based requirement item generation in Python-like syntax, and test case generation processes.

[0071] Table 1. Pre-set Structure Rules for Requirements Documents

[0072]

[0073] The process of standardizing requirement item text to generate variable interface description models and generating functional requirement items in Python-like syntax is as follows: Figure 3As shown, the process includes steps such as standardized requirement item text input, requirement item segmentation, inputting a large language model, variable identification, variable constraint information extraction, variable interface description model generation, application of Python-like grammar transformation rules, and generating functionalized requirement items with Python-like syntax representations based on function description structures, statement block structures, conditional branch structures, expression structures, and return structures. The standardized requirement item text serves as the input for this step, with each standardized requirement item text including at least a requirement identifier, requirement name, and requirement description. After processing by the large language model, the output is functionalized requirement items that satisfy preset Python-like grammar rules. These functionalized requirement items are expressed using a Python-like grammar intermediate representation for subsequent lexical analysis, syntax analysis, and abstract syntax tree construction.

[0074] The input consists of standardized requirement item text. This standardized requirement item text is generated through the aforementioned standardization process, and each text includes a requirement identifier, a requirement name, and a requirement description. The standardized requirement item text is then divided into requirement items, separating text containing multiple requirements into multiple independently processable requirement items, so that each standardized requirement item corresponds to a requirement logic unit to be transformed. This process avoids confusion between variables, conditions, and output content from different requirement items.

[0075] After the requirement items are segmented, the standardized requirement item texts are input into a large language model, and variable recognition rules are applied to the large language model. Based on the requirement description content in the standardized requirement item text, the large language model identifies the input variables, output variables, and intermediate variables corresponding to each requirement item. Input variables represent the external input quantities that the requirement item relies on for conditional judgment or calculation; output variables represent the external output quantities generated after the requirement item is executed; and intermediate variables represent variables calculated or derived from external input quantities during the requirement logic processing and participating in the generation of external output quantities.

[0076] For the identified input variables, output variables, and intermediate variables, further variable name normalization processing is performed. Specifically, when the same variable has Chinese names, English names, abbreviations, or different expressions in the requirement text, they are uniformly mapped to a consistent variable name based on preset variable naming rules; when multiple variables with different expressions point to the same semantic variable, they are merged into the same variable object. Through variable name normalization processing, a unified format of variable names is obtained, which facilitates subsequent Python-like syntax representation, abstract syntax tree construction, and identification of dependencies across requirement logic units.

[0077] Based on variable identification, variable constraint information is further extracted. This constraint information is obtained from the value descriptions, state descriptions, comparison relationships, or threshold relationships in the requirement items, including variable type, legal value range, set of possible values, or threshold constraints. For Boolean variables, their set of possible values ​​is extracted; for enumerated or state-type variables, their set of legal states is extracted; for numerical variables, their value range, threshold boundaries, or comparison constraints are extracted. Through the extraction of variable constraint information, the value conditions under which each variable can participate in constraint solving and test input construction during subsequent test case generation are determined.

[0078] Based on the identified input variables, output variables, intermediate variables, and variable constraint information, a variable interface description model is generated for each corresponding requirement item. This model records the interface relationship between a single requirement item and its variable set, including requirement identifier, requirement name, input variable set, output variable set, intermediate variable set, variable function type, and variable constraint information. Through this variable interface description model, the input boundaries, output boundaries, and intermediate processing variables of a single requirement logic unit can be clearly defined, thereby determining the set of variables that need to be processed during subsequent test case generation.

[0079] After generating the variable interface description model, the standardized requirement item text and the corresponding variable interface description model are used as input to apply preset Python-like grammar transformation rules to the large language model. These Python-like grammar transformation rules constrain the output format of the large language model, ensuring that it converts natural language requirements into functional requirement items represented by Python syntax, according to preset function description structures, statement block structures, conditional branch structures, expression structures, and return structures.

[0080] The function description structure is used to characterize the logical unit definition corresponding to a single requirement, including the function name, function parameter list, and function body. The function name is formed by combining the requirement identifier in the standardized requirement text with the output variable name, reflecting the meaning of the requirement's logical unit. The function parameter list is generated based on the variable set in the variable interface description model, including the input variables upon which the requirement depends for conditional judgments or calculations. The function body carries the logical processing statements for the requirement.

[0081] The statement block structure is used to represent a set of sequentially executed statements within a function body or branch body. Specifically, the statement block structure determines the inclusion relationship and execution scope between statements through indentation levels or statement nesting relationships, giving clear hierarchical boundaries to statements within the function body, if branch statement blocks, elif branch statement blocks, and else branch statement blocks. Through the statement block structure, subsequent lexical analysis, syntax analysis, and abstract syntax tree construction processes can accurately identify sequential execution relationships and branch inclusion relationships.

[0082] The conditional branching structure is used to represent the conditional judgment logic and branch execution logic in the requirements. The conditional branching structure includes one or more of the following: if branch, elif branch, and else branch. The if branch and elif branch each include a conditional expression and a corresponding branch statement block, while the else branch includes a branch statement block executed when none of the preconditions are met. By organizing the conditional judgment content in the requirement text into a branching structure with an execution order, the conditional branching structure provides a foundation for subsequent decision chain extraction and conditional logic modeling.

[0083] The expression structure is used to represent the conditional expressions in the conditional branching structure. The expression structure includes variable names, constant values, comparison operators, and logical operators. Variable names are derived from normalized variable names in the variable interface description model; constant values ​​are derived from thresholds, state values, or output values ​​in the requirement entries; comparison operators represent the comparison relationships between variables and constants, and between variables themselves; and logical operators represent the logical combination relationships between multiple conditions. Through the expression structure, judgment conditions in natural language can be converted into comparison and logical expressions that can be recognized by the subsequent abstract syntax tree.

[0084] The return structure is used to characterize the output logic after requirement processing. The return structure includes a return keyword and a return expression, where the return expression corresponds to the output variable, output constant, or output result calculated from input variables and intermediate variables of the requirement item. Through the return structure, the output results corresponding to different conditional branches can be clearly defined, providing a basis for subsequent semantic execution, result binding, and test case generation.

[0085] Based on the aforementioned function description structure, statement block structure, conditional branch structure, expression structure, and return structure, the large language model generates functionalized requirement items with Python-like syntax representation. In this invention, although the Python-like intermediate representation adopts a syntax style similar to Python, it is not essentially equivalent to the standard Python language. Instead, it is a specialized subset of syntax geared towards requirement logic modeling and test case generation. Standard Python is a general-purpose programming language that supports complex syntax and operational mechanisms such as class definitions, loop structures, exception handling, module imports, comprehensions, generators, decorators, and dynamic object systems. In contrast, the Python-like intermediate representation in this invention retains syntax structures directly related to requirement logic expression, namely function description structures, statement block structures, conditional branch structures, expression structures, and return structures, used to carry input-output relationships, conditional judgment relationships, result output logic, and intermediate variable generation relationships in onboard software requirements. In other words, the Python-like intermediate representation in this invention does not cover all semantic objects of the complete Python language; instead, it focuses on the purpose of requirement transformation and subsequent test generation, specifically constraining and tailoring the syntax.

[0086] In this invention, the Python-like intermediate representation imposes specific constraints on the syntax rules for test generation. Regarding function structure, each requirement is required to be converted into a function description structure with explicit input parameters, explicit output meaning, and explicit return logic. Regarding conditional expression, conditional logic is required to be given as easily parsed logical expressions as possible to facilitate subsequent extraction of atomic conditions and MC / DC coverage constraint solving. Regarding branching structure, priority is given to decision chains composed of if, elif, and else to facilitate unified extraction of conditional chains and branch return information. Regarding return structure, the output result of the requirement is required to be explicitly given via return to facilitate subsequent semantic execution and result binding. Through these constraints, the Python-like intermediate representation can maintain readability while meeting the needs of subsequent abstract syntax tree construction and conditional logic modeling.

[0087] In this invention, constraints are imposed on the output of the Python-like syntax intermediate representation generated by the large language model. These constraints include: outputting only Python-like syntax code, without additional explanatory text; variable names should accurately reflect the names or semantics in the requirement text; all conditional triggering relationships, threshold comparison relationships, logical combination relationships, output assignment relationships, and necessary calculation relationships must be fully implemented; the code must conform to preset Python-like grammar rules; even simple assignment relationships are given in function implementation form; key variables or conditions in the requirement items are not allowed to be omitted; for conditional judgment functions used to represent judgment results, their return value is a boolean type; conditional expressions in conditional judgment statements are written on the same line for subsequent parsing; for multiple conditions, they are connected by logical operators to form compound conditional expressions. These output constraints improve the structural consistency of the Python-like syntax intermediate representation and the stability of subsequent parsing.

[0088] The process of constructing a formal abstract syntax tree structure based on function-based requirement entries represented by Python-like syntax, and generating test cases that satisfy the MC / DC coverage criterion for a single requirement, is as follows: Figure 4 As shown, the steps include lexical analysis, basic grammatical unit generation, syntax recognition, logical structure recognition, abstract syntax tree node construction, hierarchical assembly, abstract syntax tree construction, conditional logic modeling, and single requirement test case generation.

[0089] Specifically, functional requirement entries represented by Python-like syntax are used as input. These functional requirement entries, generated by the preceding steps, include function description structures, statement block structures, conditional branch structures, expression structures, and return structures, used to characterize the functional logic unit, input parameters, conditional judgment process, and output result corresponding to a single requirement.

[0090] In the lexical analysis phase, the functional requirement entries represented by the Python-like syntax are lexically analyzed, decomposing the input character stream into basic syntactic units and generating a sequence of lexical units. These basic syntactic units include keywords, variable names, constants, operators, separators, indentation markers, and newline markers. Keywords include function definition keywords, conditional branch keywords, and return keywords; variable names represent input, output, or intermediate variables in the requirement entry; constants represent numerical, Boolean, or state values ​​in the requirement entry; operators include comparison and logical operators; separators include parentheses, commas, and colons; and indentation and newline markers indicate the hierarchical boundaries of statement blocks. This step transforms the linear Python-like syntax text into a sequence of lexical units that can be processed by subsequent syntax recognition.

[0091] In the syntax recognition phase, the sequence of lexical units is subjected to syntax analysis. Following preset Python-like grammar rules, the logical structure between basic syntax units is identified, generating a syntax analysis tree. Specifically, the syntax recognition process identifies function definition statements, statement blocks, conditional branch statements, expression statements, and return statements. In function definition statements, the function name, function parameter list, and function body are identified; in statement blocks, sequential execution statements and their indentation levels are identified; in conditional branch statements, if branches, elif branches, and else branches and their corresponding branch statement blocks are identified; in expression statements, the combination relationships between variable names, constant values, comparison operators, and logical operators are identified; and in return statements, the return keyword and return expression are identified. Through this syntax recognition process, the inclusion, sequence, and nesting relationships between basic syntax units can be determined.

[0092] After syntax recognition is completed, abstract syntax tree nodes are constructed based on the syntax analysis tree. The abstract syntax tree in this invention is constructed using a combination of a unified node base class and semantically partitioned child nodes. The abstract syntax tree includes function definition nodes, statement block nodes, conditional branch nodes, expression nodes, and return nodes. All nodes have node type information and source location information, used to identify the logical object to which the node belongs and its corresponding positional range in the input text. Through the unified node design, different syntactic components in the intermediate representation of Python-like syntax are converted into structured objects that can be directly accessed and processed by subsequent programs.

[0093] The function definition node represents the functional logic unit corresponding to a single requirement and records the function name, function parameter list, and function body. The statement block node represents the sequential execution structure in a requirement item and carries a set of sequentially executed statements in the function body or branch body.

[0094] Conditional branch nodes are used to represent the conditional judgment structure in a requirement item. For conditional branch statements consisting of if, elif, and else, the conditional branch node stores the main conditional branch, extended conditional branches, and default branch respectively, and attaches the conditional expressions and branch statement blocks corresponding to each branch to the same conditional branch node, thereby preserving the execution order and hierarchical relationship between branches.

[0095] Expression nodes are used to represent conditional expressions, comparison expressions, logical expressions, and other expressions related to requirement logic processing. Conditional expression nodes represent conditional selection relationships; comparison expression nodes represent comparison relationships such as greater than, less than, equal to, not equal to, greater than or equal to, and less than or equal to; logical expression nodes include unary expression nodes for unary operations such as logical NOT, positive, or negative; and binary expression nodes for binary relationships such as addition, subtraction, multiplication, division, logical AND, and logical OR. Return nodes represent the output rules for output variables and record the corresponding return expressions.

[0096] In the hierarchical assembly stage, this invention adopts a top-down, layered distribution abstract syntax tree construction method. Specifically, the function definition node is used as one of the root nodes of a single requirement logic unit; the sequential execution statements in the function body are assembled into statement block nodes; conditional branch nodes are attached to the corresponding statement block nodes, and the conditional expressions and branch statement blocks corresponding to each branch are attached to the conditional branch nodes respectively; expression nodes are attached to conditional branch nodes or return nodes to represent the conditional judgment content or the return expression content; return nodes are attached to the corresponding function body statement block or branch statement block to represent the output result under the corresponding execution path. Through this hierarchical assembly, an abstract syntax tree that reflects the structural relationship between function definition, sequential execution, conditional judgment, expression combination, and return logic is formed.

[0097] After completing node construction and hierarchical assembly, an abstract syntax tree object is constructed. This abstract syntax tree provides the following types of information: first, the function name, parameter list, and function body of each logical unit; second, the hierarchical and sequential execution relationships between statement blocks; third, the organizational relationships between if, elif, and else branches in a conditional branching structure; fourth, the nesting and operational relationships between various expression nodes; fifth, the position of assignment logic within a function and its corresponding assignment expression; and sixth, the position of return logic within a function and its corresponding return expression.

[0098] After constructing the abstract syntax tree, conditional logic modeling is performed based on it. Function definition nodes are extracted from the abstract syntax tree, and conditional branch nodes and return nodes are further extracted from these nodes. For the same conditional judgment structure, the if, elif, and else branches are organized into a decision chain structure according to their execution order. For each branch in the decision chain structure, the corresponding conditional expression and branch statement block are extracted, and a return node is extracted from the branch statement block to generate the execution result structure corresponding to each branch. The decision chain structure represents the branch selection rules for the requirement item, and the execution result structure represents the output result corresponding to each branch being hit.

[0099] Furthermore, the decision chain structure is converted into a logical expression that can be processed by the constraint solver, and atomic conditions are extracted from the logical expression to generate a conditional logic model that includes a global decision expression, a set of atomic conditions, and their combination relationships. The atomic conditions can be standalone Boolean variable conditions or comparison conditions consisting of variable names, constant values, and comparison operators; multiple atomic conditions are combined into a global decision expression through logical operators. This conditional logic model allows the conditional branch logic in the abstract syntax tree to be converted into a formal representation that can be used for constructing and solving covered constraints.

[0100] After generating the conditional logic model, test cases for each individual requirement are generated based on the MC / DC coverage criterion. For each atomic condition in the conditional logic model, it is identified as a target atomic condition, and test input pairs are constructed accordingly. Each test input pair includes a first test vector and a second test vector, each corresponding to a set of input variable assignments. When constructing test input pairs, the values ​​of non-target atomic conditions are kept unchanged, while the values ​​of the target atomic conditions are changed. It is then determined whether the overall decision expression changes with the change in the target atomic condition. When the truth values ​​of the target atomic condition are opposite in the two test vectors, the truth values ​​of other atomic conditions are the same in the two test vectors, and the overall decision expression result is opposite, the test input pair is determined to satisfy the MC / DC coverage criterion.

[0101] For test input pairs that satisfy the MC / DC coverage criterion, they are recorded as test cases for a single requirement. Each test case for a single requirement includes input variable assignments, atomic condition truth values, overall decision results, and output result information related to the corresponding return node. Specifically, input variable assignments represent the specific inputs to the test vector; atomic condition truth values ​​represent the true / false status of each atomic condition under that input; the overall decision result represents the overall value of the decision chain condition logic under that input; and output variable values ​​represent the output result obtained by the corresponding requirement logic unit through semantic execution under that test input. This process ensures that test cases for a single requirement not only cover the key condition judgment logic in the requirement item but also clearly define the corresponding requirement output results under different test inputs. This provides a local testing foundation for subsequent establishment of requirement item call relationship diagrams based on the variable interface description model and cross-logic unit propagation and combination.

[0102] Based on the variable interface description model, a call relationship graph between requirement items is established. This graph is then combined with individual requirement test cases for semantic execution, result binding, and cross-logic unit propagation, ultimately generating a set of test cases for complex requirement chains. The process is as follows: Figure 5 As shown.

[0103] The variable interface description model records information including requirement identifier, requirement name, set of input variables, set of output variables, set of intermediate variables, variable function type, and variable constraint information. Based on the variable interface description model, the variable set for each requirement item is obtained, and each requirement item is defined as a requirement logical unit. Each requirement logical unit serves as a graph node in the requirement item call relationship diagram.

[0104] A call relationship graph for requirement items is established based on the variable transfer relationships between various requirement logic units. When the output variable of one requirement logic unit matches the input variable of another requirement logic unit, the former requirement logic unit is designated as the upstream requirement logic unit, and the latter as the downstream requirement logic unit, establishing a dependency edge between them. Thus, a call relationship graph for requirement items is constructed based on multiple requirement logic units and their dependency edges. This call relationship graph represents the call relationships and data transfer relationships formed from output variables to input variables between different requirement items.

[0105] After establishing the call relationship graph for requirement items, dependencies between requirement units are established based on the call relationship graph. These dependencies are used to determine the order in which requirement logic units propagate and combine across logic units. When an input variable of a downstream requirement logic unit depends on the output variable of an upstream requirement logic unit, the test result of the upstream requirement logic unit should participate in the propagation and combination before the downstream requirement logic unit and be included as part of the input assignment for the downstream requirement logic unit.

[0106] For the test cases generated in the preceding steps targeting a single requirement, semantic execution is performed to form local test entries. Specifically, for each requirement logic unit, the single requirement test input is evaluated according to the condition judgment, assignment processing, and return logic expressed in the functional requirement entry or abstract syntax tree of that requirement logic unit, obtaining the output variable value under the corresponding test input. Subsequently, the input variable assignment, atomic condition truth value, requirement judgment result, and output variable value are combined to form a local test entry. The local test entry is used to represent the complete execution result of a single requirement logic unit under a set of test inputs.

[0107] After establishing the dependency relationships between requirement units and constructing local test entries, cross-logic unit propagation composition is performed. Based on the call relationships determined by the requirement entry call relationship graph, local test entries of upstream logic units are propagated to downstream logic units, and the output variable values ​​of upstream logic units are used as the input variable values ​​of downstream logic units. During the propagation process, the currently accumulated variable assignment table is used as the propagation context; when a local test entry of a downstream logic unit satisfies its upstream dependency requirements, the local test entry is incorporated into the current propagation composition and continues to propagate downstream along the call relationship graph.

[0108] During the cross-logic unit propagation and combination process, a variable assignment consistency check is performed on the local test entries after propagation and combination. It is determined whether the variable assignments in the local test entries to be merged conflict with the assignments of variables with the same name already existing in the current propagation combination. When a conflict exists, the propagation combination result is considered not to meet the variable assignment consistency requirement, the corresponding propagation combination is discarded, and it will not be used for subsequent propagation.

[0109] When there are no conflicting values ​​for variables with the same name, the variable assignments in the local test entries to be merged are added to the variable assignment table of the current propagation combination, and the propagation combination information is recorded. The propagation combination information includes propagation path information, branch hit information, and output information. Specifically, propagation path information records the requirement logic units that the test cases sequentially traverse; branch hit information records the condition branches or decision results that are hit by the corresponding test inputs in each requirement logic unit; and output information records the output variable names and values ​​generated by each requirement logic unit under the corresponding test inputs. Through the above processing, test cases oriented towards complex requirement chains are generated.

[0110] After generating test cases for complex requirement chains, a uniqueness check is performed to determine whether they are duplicate test cases. This uniqueness check is based on variable assignment tables, propagation path information, branch hit information, and output information. If a test case is determined to be duplicated, deduplication is performed on the combined results, retaining only one test case; if a test case is determined not to be duplicated, it is retained in the final result.

[0111] After the above processing, a test case set for complex requirement chains is formed. This test case set includes not only local test information formed after semantic execution of individual requirement test cases, but also chain-level test information formed after propagation and combination along the requirement item call relationship graph across logical units. Through variable assignment consistency checks and duplicate test case removal, invalid propagation combinations and redundant test cases can be reduced, ensuring that the final generated test case set reflects variable propagation relationships, branch hit relationships, and output result relationships in complex requirement chains. The test case set can be output as a result file according to a preset format for subsequent verification platform calls, tester analysis, or automatic execution input during requirement verification processes.

[0112] In summary, this invention provides an automated method for generating airborne software test cases based on natural language requirements. It transforms the original natural language requirement document into standardized requirement text, functional requirement items represented by Python-like syntax, an Abstract Syntax Tree (AST), a conditional logic model, and a final set of test cases, forming a complete automated processing chain from requirement text to test items and then to a test set for complex requirement chains. Compared to traditional methods that rely on manually reading each requirement and constructing test cases, this invention significantly reduces manual design costs, improves test case generation efficiency, and enhances the logical completeness, consistency, and traceability of test cases in complex logical requirement scenarios.

[0113] The scope of protection of this invention is not limited to the above embodiments. Any variations and advantages that can be conceived by those skilled in the art without departing from the spirit and scope of this invention are included in this invention and are protected by the appended claims.

Claims

1. A method for automatically generating airborne software test cases based on natural language requirements, characterized in that, The specific steps include the following: Step 1: Based on the input airborne software requirements expressed in natural language, standardize the process, extract the requirement information, and convert the original requirements into standardized requirement item text; Step 2: Analyze the standardized requirement text item by item, use the large language model to extract the input variables, output variables and intermediate variables corresponding to each requirement, and generate the variable interface description model corresponding to each requirement; extract the condition triggering relationship, logical combination relationship and output assignment relationship in the standardized requirement text, and convert the natural language form of the requirement into a function-based requirement item with Python-like syntax based on the large language model; Step 3: Construct a formal abstract syntax tree structure based on the functional requirement items represented by Python-like syntax, perform unified modeling of conditional branching relationships, decision chains and return logic, complete conditional logic modeling, and generate test cases for individual requirements based on the MC / DC coverage criterion. Step 4: Obtain the dependencies between variables through the variable interface description model, establish a call relationship graph between requirement items, determine the call relationship of each requirement logic unit based on the call relationship graph, and perform semantic execution, result binding and cross-logic unit propagation combination on the test input of a single requirement to form a test case set for complex requirement links.

2. The method for automatically generating airborne software test cases according to claim 1, characterized in that, Step 1 specifically includes: 1-1: The input airborne software requirements are provided in document form, which includes one or more of the following formats: PDF document, spreadsheet document, and text document; 1-2: After reading and extracting the text of the airborne software requirements in the document format, the requirement texts in different formats are converted into text content in a unified format; 1-3: Perform a standardization check on the extracted text content, detect issues such as missing descriptions, incomplete fields, non-standard formatting, or non-standard descriptions in the requirement items, and output prompt messages to indicate the existence of non-standard requirement items. 1-4: Standardize the text content that has passed the standardization check, and unify the expression format so that each standardized requirement item text includes a requirement identifier, requirement name and requirement description, generating standardized requirement item text for subsequent requirement analysis.

3. The method for automatically generating airborne software test cases according to claim 1, characterized in that, Step 2, generating the variable interface description model corresponding to each requirement, specifically includes: Based on the requirements, the corresponding input variables, output variables, and intermediate variables are extracted, and the extracted variables are normalized to obtain variable names in a unified format. The input variables are used to represent the external input quantities that the requirement items rely on when performing conditional judgments or calculations. The output variables are used to represent the external output quantities generated after the requirement items are executed. The intermediate variables are used to represent the variables that are calculated or derived from the external input quantities and participate in the generation of external output quantities during the requirement logic processing. Based on the value descriptions, status descriptions, comparison relationships, or threshold relationships in the requirement items, extract the variable type, legal value range, optional value set, or threshold constraint for each variable; The requirement identifier, requirement name, input variables, output variables, intermediate variable set, variable function type, and variable constraint information are written into a preset field structure to generate a variable interface description model, and to determine the set of variables that need to be processed in the subsequent test case generation process.

4. The method for automatically generating airborne software test cases according to claim 1, characterized in that, Step 2, which involves converting the requirements in natural language form into functional requirements represented by Python syntax based on a large language model, specifically includes: The standardized requirement item text and the interface description model are input into the large language model, and a preset Python-like grammar transformation rule is applied to the large language model. Python-like grammar transformation rules describe intermediate representations of Python-like syntax, including function description structures, statement block structures, conditional branch structures, expression structures, and return structures. Based on Python-like grammar transformation rules, the large language model generates function names based on the requirement identifiers in the standardized requirement entry text and the variable interface description model; it also generates function parameter lists based on the variable set in the variable interface description model; based on the statement execution order in the standardized requirement entry text, it generates statement block structures to carry sequentially executed statements in function bodies or branch bodies; based on the condition judgment content, it generates conditional branch structures including one or more of if, elif, and else branches; based on variable names, constant values, comparison operators, and logical operators, it generates expression structures representing conditional expressions; and based on the result output content, it generates return structures including return keywords and return expressions. Based on the function description structure, statement block structure, conditional branch structure, expression structure, and return structure, functional requirement entries with Python-like syntax representation are generated.

5. The method for automatically generating airborne software test cases according to claim 4, characterized in that, The function description structure is used to characterize the logical unit definition corresponding to a single requirement, including a function name, a function parameter list, and a function body; wherein, the function name is generated based on the requirement identifier, the function parameter list is generated based on the variable interface description model of the requirement item, and the function body is used to carry the logical processing statements of the requirement item; The statement block structure is used to represent a set of sequentially executed statements in a function body or branch body. The statement block structure determines the inclusion relationship and execution scope between statements through indentation level or statement nesting relationship. The conditional branch structure is used to represent the condition judgment logic and branch execution logic in the requirements. The conditional branch structure includes one or more of if branch, elif branch and else branch. The if branch and elif branch respectively include a conditional expression and a corresponding branch statement block. The else branch includes a branch statement block that is executed when the preconditions are not met. The expression structure is used to characterize the conditional expression in the conditional branch structure. The expression structure includes variable names, constant values, comparison operators, and logical operators. The comparison operators are used to represent comparison relationships, and the logical operators are used to represent logical combination relationships between multiple conditions. The return structure is used to characterize the output logic of the result after the requirement is processed. The return structure includes a return keyword and a return expression. The return expression corresponds to the output variable, output constant or output result calculated from the input variable and intermediate variable of the requirement item.

6. The method for automatically generating airborne software test cases according to claim 1, characterized in that, Step 3, which involves constructing an abstract syntax tree structure based on a Python-like intermediate representation, specifically includes: Lexical analysis is performed on the aforementioned Python syntax intermediate representation to identify keywords, variable names, constants, operators, delimiters, indentation marks, and newline marks, generating a sequence of lexical units; The lexical unit sequence is subjected to syntactic analysis, and function definition statements, statement block statements, conditional branch statements, expression statements and return statements are identified according to preset Python-like grammar rules to generate a syntax analysis tree; An abstract syntax tree is constructed based on the parsing tree, and the abstract syntax tree includes function definition nodes, statement block nodes, conditional branch nodes, expression nodes, and return nodes; The function definition node is used to represent the functional logic unit corresponding to a single requirement; the statement block node is used to represent the sequential execution structure in the requirement item; the conditional branch node is used to represent the conditional judgment structure in the requirement item; the expression node is used to represent conditional expressions, comparison expressions, and logical expressions; and the return node is used to represent the output rules of the output variable.

7. The method for automatically generating airborne software test cases according to claim 1, characterized in that, Step 3 involves unified modeling of conditional branching relationships, decision chains, and return logic to complete conditional logic modeling and generate test cases for a single requirement that meet the MC / DC coverage criterion. Specifically, this includes: Extract function definition nodes from the abstract syntax tree, and extract condition branch nodes and return nodes based on the function definition nodes; organize the if branches, elif branches, and else branches in the same condition judgment structure into a decision chain structure according to the execution order; extract the corresponding condition expression and branch statement block for each branch of the decision chain structure, and extract the return node from the branch statement block to generate the execution result structure corresponding to each branch; The decision chain structure is used to characterize the branch selection rules of the requirement item, and the execution result structure is used to characterize the output result corresponding to each branch being hit. The decision chain structure and the execution result structure are used together for subsequent conditional logic modeling, constraint coverage solving and test case generation. The decision chain is converted into a logical expression that can be processed by the constraint solver, and the atomic conditions in the logical expression are extracted to generate a conditional logic model that includes the overall decision expression, the set of atomic conditions and their combination relationships. For each target atomic condition in the conditional logic model, an MC / DC coverage constraint is constructed. The MC / DC coverage constraint is used to limit the truth values ​​of target atomic conditions in two test vectors to be opposite, the truth values ​​of other atomic conditions to be the same, and the results of the overall decision expression to be opposite. Based on the MC / DC coverage constraint, the test cases for a single requirement that satisfy the MC / DC coverage criterion are generated.

8. The method for automatically generating airborne software test cases according to claim 7, characterized in that, The generation of test cases for a single requirement that satisfy the MC / DC coverage criterion specifically includes: For each atomic condition in the conditional logic model, construct test input pairs; change the value of the target atomic condition while keeping the value of the non-target atomic condition unchanged; when the overall judgment result changes with the target atomic condition, determine that the corresponding test input pair satisfies the MC / DC coverage criterion; record the test input pairs that satisfy the MC / DC coverage criterion as test cases for a single requirement.

9. The method for automatically generating airborne software test cases according to claim 1, characterized in that, Step 4 describes obtaining the dependencies between variables through the variable interface description model and establishing a call relationship graph between requirement items, specifically including: Based on the variable interface description model corresponding to each requirement item, obtain the variable set for each requirement item, determine each requirement item as a requirement logic unit, and use the requirement logic unit as a graph node; When the output variable of the upstream demand logic unit matches the input variable of the downstream demand logic unit, a dependency edge is established between the upstream demand logic unit and the downstream demand logic unit, and a call relationship graph between demand items is constructed based on each demand logic unit and its dependency edge.

10. The method for automatically generating airborne software test cases according to claim 1, characterized in that, Step 4, which involves forming a test case set for complex requirement chains, specifically includes: Semantic execution is performed on the single requirement test input corresponding to each requirement logic unit to obtain the output variable value. The input variable assignment, atomic condition truth value, requirement judgment result and output variable value are combined into a local test item. The calling relationship is determined based on the calling relationship diagram between the demand items. The local test items of the upstream logic unit are propagated to the downstream logic unit, and the output variable value of the upstream logic unit is used as the input variable value of the downstream logic unit. The consistency of variable assignment is checked for the local test items after propagation and combination. When there is a conflict in the values ​​of variables with the same name, the corresponding propagation combination result is discarded; when there is no conflict in the values ​​of variables with the same name, the variable assignment tables of each local test item are merged, the propagation path information, branch hit information and output information are recorded, and test cases for complex requirement links are generated. The uniqueness of the test cases for the complex requirement chain is determined, duplicate test cases are removed, and an optimized set of test cases is formed.

Images