Formalized requirement modeling and automatic test verification method based on sysml diagram

Abstract

This invention, based on formal requirements modeling and SysML diagrams for automated testing and verification, belongs to the field of computer software development technology. The method is as follows: requirements text format conversion; generation of a test case table; formal modeling of the requirements text; execution of testing and verification; reading the test case table and assigning values ​​to system model variables; the system running according to its internal modeling logic and generating output; obtaining the output and writing it into the test case table at the corresponding locations; and designing a test report generation tool. This invention improves the efficiency and accuracy of test data generation, forms a complete closed-loop process from requirements capture to verification analysis, enhances the standardization and consistency of development, achieves automated execution of test cases, and completes verification by automatically comparing model output with expected results. It can quickly adapt to changes in requirements and functional expansions of complex systems.

Description

Technical Field

[0001] This invention relates to a formal requirements modeling and SysML diagram-based automatic testing and verification method, belonging to the field of computer software development technology. Background Technology

[0002] As the complexity of modern systems engineering continues to increase, traditional requirements development and verification methods are showing increasing limitations in handling changes in requirements of complex systems, verifying consistency, and improving development efficiency.

[0003] Model-Based Systems Engineering (MBSE), as an emerging system development methodology, provides a model-centric approach for requirements capture, design, verification, and traceability, significantly improving the efficiency and reliability of the systems engineering process. However, existing model-driven methods largely focus on model creation and management, with requirements verification relying heavily on manual analysis and static testing. The lack of automated support for requirements verification leads to inefficient system consistency verification in complex requirement scenarios. Significant room for improvement remains, particularly in areas such as the clarity of requirements expression, the correlation between requirements and models, and the degree of automation in model verification.

[0004] Systems Modeling Language (SysML), a graphical modeling language supporting system design, is widely used for modeling system structure, behavior, and constraints. SysML models possess visualization and executability features, making them a powerful tool for formal requirements modeling and verification. However, its support for automated requirements verification remains insufficient. For example, in complex requirement scenarios, the generation and verification of test cases often rely on cumbersome manual operations, making it difficult to achieve an efficient closed loop between requirements and verification. These issues directly limit the depth and breadth of MBSE method applications in engineering. Researchers need to explore building a complete closed-loop process from requirements capture to verification to further improve the quality and efficiency of system development.

[0005] In recent years, formal method-based requirement modeling and verification techniques have gradually become a research hotspot. Formal methods transform natural language requirements into structured and parsable formal representations, allowing requirements to be directly mapped into system models. This approach not only improves the clarity and consistency of requirement expression but also provides a foundation for requirement verification and system behavior verification. However, relying solely on formal methods is insufficient to meet the full lifecycle requirements of complex system development. Developing a model-based automated testing method, combining formal requirement modeling with simulation techniques, can identify system design flaws at an early stage, thereby reducing the cost of later modifications.

[0006] Therefore, how to construct an efficient and automated requirements management and verification method, especially to achieve structured expression of requirements, close correlation with models, and automated verification processes through formal means, has become a key issue that urgently needs to be addressed in the field of systems engineering. Combining formal methods with model-driven technology to form a complete "requirements-model-verification" closed-loop process, and through innovative formal modeling and automated verification technologies, may provide an integrated solution for requirements modeling and verification. Summary of the Invention

[0007] To address the problems existing in the background technology, this invention provides a method for formal requirements modeling and automatic testing and verification using SysML diagrams.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: a method for automatic testing and verification based on formal requirements modeling and SysML diagrams, the method comprising the following steps:

[0009] S1: Required text format conversion;

[0010] S101: System requirements item collection and organization;

[0011] S102: After analyzing the structure of the requirement items, identify the key information of the requirement items and define the formal syntax rules for the requirement items;

[0012] S103: Manually divide the requirement text, which consists of all requirement items, into a subject-verb-target structure, and decompose each requirement item in the requirement text into a formalized text by combining conditional statements;

[0013] S104: Store the formalized condition-result pairs in the database.

[0014] S2: Design a requirements text processing tool to generate a test case table by inputting formalized requirements items;

[0015] The design of the text processing tool for the requirements described in S2 includes the following steps:

[0016] S201: Based on the formal grammar rules of the requirement items, the sentence pattern is clearly defined, the tool identifies the sentence pattern and extracts the information required for testing and verification from the requirement text by calling the corresponding processing function;

[0017] S202: Divide the sentence into multiple parts according to its structure and extract the key information from each part;

[0018] S203: Use key information and related requirements documents to generate input and expected output content, and merge them with the blank model output column into a test case table;

[0019] The contents of each column in the test case table described in S203 are as follows:

[0020] Input, including the content required for testing, is extracted from the requirements text or randomly generated from a range of preconditions;

[0021] Expected output: Clearly define the behavior or result that the system will produce under corresponding input conditions. This can be extracted from the requirements text, generated based on the extracted information, or supplemented by referencing related requirements documents.

[0022] The model output leaves empty columns, which will be used to fill in the actual running results during subsequent model execution.

[0023] S204: Design a requirements text processing interface to display the generated test case table in real time, and add a button to save the table as an Excel file.

[0024] S3: Use the SysML modeling language to formally model the requirements text;

[0025] S301: Draw a module definition diagram using SysML, clarify the system structure, add the system under test module and control test module, define the internal attributes of the module and their initial values, and add generalization relationships between modules;

[0026] S302: Create a system model by adding SysML graphics to the modules of the system under test according to system requirements;

[0027] S303: Create activity diagrams for the control test module based on the requirements, and complete automated test verification;

[0028] S30301: Classify requirement items into state-switching type and non-state-switching type based on whether they involve state switching;

[0029] S30302: Create a state transition type activity graph to enable the execution of the system under test module and the control behavior of the control test module to run in parallel;

[0030] S30303: Creates a non-state-switching type activity graph, serially executing input reading, execution of the system under test module, and output writing.

[0031] S3030301: Read Input: Read input data from the test case table and load it into the module of the system under test;

[0032] S3030302: Execution of the system under test module: Calls the system under test module to complete the task logic;

[0033] S3030303: Output Write: Writes the output results generated by the system module under test into the model output column of the test case table for subsequent comparison and analysis.

[0034] S304: Use user interface modeling diagrams to create graphical user interfaces to visualize changes in system value attributes; design user interface modeling diagrams to enhance the system's visualization and interactivity.

[0035] S305: Create simulation configuration diagrams, bind UI interfaces and execution targets, and customize model execution.

[0036] S4: Perform test verification, read the test case table and assign values ​​to the system model variables. The system runs according to the internal modeling logic and generates output. Obtain the output and write it into the test case table in the corresponding position.

[0037] S401: Loading test cases: The test case table is read as an input file, and the data in the input columns of the table is extracted row by row and assigned to the corresponding variables in the system model. The variables drive the model to run according to the internal modeling logic.

[0038] S402: System Model Operation: The system executes operations based on the established activity diagram or state diagram to complete the behaviors corresponding to the requirements;

[0039] S403: Recording of output results: After the operation is completed, the system generates output results, which are automatically recorded in the model output column of the test case table to form a complete input-output pair;

[0040] S404: By comparing the model output with the expected output column in the table, it is determined whether the requirement verification has passed, and finally the comprehensive testing and verification of the system model is achieved.

[0041] S5: Design a test report generation tool, input the requirement items and test case tables into the test report generation tool for analysis and verification, and generate a test report.

[0042] S501: Create a blank template and add four modules: test requirements, test objectives, test steps, and test results;

[0043] S502: Read the test case table file, create the table in the test steps module, and add the data;

[0044] S503: Process the tabular data, analyze the expected output and actual model output data in the test case table, compare and determine whether the verification is passed and generate the verification result;

[0045] S504: Write the verification results into the test results module;

[0046] S505: Use the Tkinter tool to design the test report generation interface, fill the document with user input in modules, and add buttons to generate the test report at a specified path.

[0047] Compared with the prior art, the beneficial effects of the present invention are:

[0048] 1. This invention formalizes natural language requirements, extracts key information, and generates test cases. This solves the problems of time-consuming and error-prone manual operations in traditional test case generation, significantly improving the efficiency and accuracy of test data generation. Simultaneously, the automatically generated test cases have high coverage, effectively addressing the testing challenges posed by the diverse requirements of complex systems.

[0049] 2. This invention forms a complete closed-loop process from requirement capture to verification analysis through formal requirement modeling, automatic test case generation, model simulation execution, and result verification. Compared with the disconnect between requirements and verification in traditional methods, this closed-loop process ensures that requirements can be tracked and verified throughout the entire system development process, effectively improving the standardization and consistency of development.

[0050] 3. This invention relies on automated model simulation and verification technology to automate the execution of test cases and complete verification by automatically comparing the model output with the expected results. This method not only improves verification efficiency but also identifies potential problems in system design at an early stage, reducing the costs incurred in fixing these problems later in the development process.

[0051] 4. The automated testing and verification process designed in this invention can quickly adapt to changes in the requirements and functional expansions of complex systems. The automatic updating of test cases and the efficient execution of the verification process can support multiple rounds of iterative development, and are especially suitable for high-reliability industrial systems with complex and frequently changing requirements. It can provide a more scientific solution for the development of systems in various fields. Attached Figure Description

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

[0053] Figure 2 It is a flowchart for generating test case tables from formal text;

[0054] Figure 3 This is a schematic diagram of the formal modeling module definition;

[0055] Figure 4 This is an activity diagram verifying the requirement instance of the RR system state switching class;

[0056] Figure 5 This is a user interface diagram;

[0057] Figure 6 This is a schematic diagram of the test report generation tool interface;

[0058] Figure 7 This is a sample image of a test report. Detailed Implementation

[0059] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the invention, not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0060] A formal requirements modeling and SysML diagram-based automatic testing and verification method is proposed, comprising the following steps:

[0061] S1: Required text format conversion;

[0062] S101: System requirement item collection and organization is mainly accomplished by screening and organizing requirement items from various sources. These sources primarily include functional requirements provided by stakeholders, specifications from industry standard documents, and design descriptions of existing system architectures. To ensure the comprehensiveness and accuracy of the requirement items, these sources must be carefully screened, and redundant, ambiguous, or contradictory requirement items must be cleaned up and organized. Finally, the requirement items are systematically recorded in the requirements document and numbered and categorized for easy tracking and management later.

[0063] S102: After analyzing the structure of the requirement items, identify the key information of the requirement items and define the formal syntax rules for the requirement items;

[0064] S103: Manually divide the requirement text, which consists of all requirement items, into a subject-verb-target structure, and decompose each requirement item in the requirement text into a formalized text by combining conditional statements;

[0065] After collection, a detailed analysis of the requirement entries is necessary to identify their key elements, including the subject, verb, target, and related conditions. Identifying these key elements allows for the extraction of the logical core of the requirement entries. Next, based on the characteristics of the requirement entries, formalized grammatical rules are developed. A consistent "subject-verb-target" sentence structure is adopted, using conditional statements (such as GIVEN, WHEN, THEN) to express logical relationships. This formalization of the requirement text transforms complex natural language into a structured, easily parsed format. During this process, the applicability of the grammatical rules also needs to be verified, and appropriate adjustments made to accommodate the diversity of requirement entries.

[0066] S104: Store the formalized condition-result pairs in the database.

[0067] Formalizing requirement items is a crucial step in the technical approach, involving the analysis and reorganization of each requirement item. Specifically, requirement items are divided into logical units of "subject-verb-target," and then reformulated into formal text according to custom grammar rules and conditional statements.

[0068] For example, the original requirement, "The system should cover angles from 30° to 60° in search mode," can be translated as "WHEN [system in search mode] THEN [coverage angle range] SHOULD BE [30° to 60°]." This formalized expression not only clarifies the requirement logic but also facilitates subsequent processing and verification.

[0069] S2: Design a requirements text processing tool to generate a test case table by inputting formalized requirements items;

[0070] This step aims to provide a requirement text processing tool that automatically generates a structured test case table from the formalized requirement items, covering input, expected output, and model output columns, laying the foundation for subsequent testing and verification.

[0071] The design of the text processing tool for the requirements described in S2 includes the following steps:

[0072] S201: Identify common sentence patterns based on the formal syntax rules of the requirement items, such as "SHOULDHAVE", "SHOULD support transitions", and "SHOULD BE". The tool should be able to recognize these sentence patterns and extract the information needed for testing and verification from the requirement text by calling the corresponding processing functions. To adapt to the needs of different scenarios, the tool should also support the expansion of sentence pattern rules, allowing developers to add new rules at any time to cover more requirement types.

[0073] S202: After identifying the sentence structure, the tool divides the sentence into multiple parts according to its structure and extracts key information from each part, such as the subject, behavior, goal, and additional conditions. This step ensures that each core element in the requirement item can be clearly extracted, providing reliable data for the subsequent generation of test cases.

[0074] S203: Use key information and associated requirements documents (optional) to generate input and expected output content, and merge them with the blank model output columns into a test case table;

[0075] The contents of each column in the test case table are as follows:

[0076] Inputs, including the initial conditions and parameter settings required for testing, are extracted from the requirements text or randomly generated from the range of prerequisites.

[0077] Expected output: Clearly define the behavior or result that the system will produce under corresponding input conditions. This can be extracted from the requirements text, generated based on the extracted information, or supplemented by referencing related requirements documents.

[0078] The model output leaves empty columns, which will be used to fill in the actual running results during subsequent model execution.

[0079] S204: Use the Tkinter tool to design a requirements text processing interface, display the generated test case table in real time, and add a button to save the table as an Excel file.

[0080] The tool needs to provide an intuitive user interface to display the generated test case table in real time. This interface is implemented using the Tkinter tool and includes a preview window and a save function. Users can enter requirement text in the interface and view the generated test cases, and export them as an Excel file by clicking the save button for easy storage and application later.

[0081] S3: Use the SysML modeling language to formally model the requirements text;

[0082] S301: Draw a module definition diagram using SysML to clarify the system structure, add the system under test (SUT) module and the control test module. The SUT module mainly represents the system functions to be tested, while the control test module is responsible for executing automated tests and verifications. Define the internal attributes of the modules (such as state variables and input parameters) and their initial values, and add generalization relationships between modules to ensure they can interact. The control test module needs to access certain parameters of the SUT module to implement test control, which can be achieved by the control test module inheriting from the SUT module.

[0083] Taking the RR system created by this invention as an example, its module definition diagram is as follows: Figure 3 As shown. The RR module has two functions: search and tracking. The controlRR module inherits from the RR module, thus accessing and modifying its variables. The modeling of the RR module simulation verification model is performed in the controlRR module.

[0084] S302: Create a system model by adding SysML diagrams such as activity diagrams and state diagrams to the modules of the system under test according to system requirements;

[0085] Activity diagrams are used to describe the main behavioral logic of a system, such as the task flow under specific input conditions; state diagrams are used to describe the switching logic and triggering conditions between different states of the system. The creation of these behavioral diagrams ensures that the system model can accurately map the requirement description and has a clear logical flow.

[0086] S303: Create activity diagrams for the control test module based on the requirements, and complete automated test verification;

[0087] S30301: Classify requirement items into state-switching type and non-state-switching type based on whether they involve state switching;

[0088] S30302: Create a state transition type activity graph to enable the execution of the system under test module and the control behavior of the control test module to run in parallel;

[0089] For the state transition type requirements, an activity diagram capable of parallel execution is designed. The left side of the activity diagram represents the state transition logic of the system under test (SUT) module, while the right side implements the monitoring and verification of state transitions by the control test module. During the state transition process, input parameters trigger the state change of the SUT module and generate model output.

[0090] The design process is described in detail using the RR system as an example:

[0091] Requirement: The RR system should have the ability to switch between main airspace search, sliding window search, and guided search modes. Verification process as follows: Figure 4 .

[0092] First, initialize by reading the number of states to switch to. The first search state entered has no preceding search state, so it is defined as empty, and no search point verification is performed.

[0093] State transition: Using branch nodes and set nodes, the execution of the RR module and the control behavior of the RR module can be concurrent.

[0094] The left branch executes the RR module, which defaults to the ZZ state. When performing target detection, targetState = 0, entering search mode and executing the state graph. The default search mode is the main spatial domain search mode. After switching to this state and completing its execution, searchend is changed to true, indicating that this state has been completed. At this point, the right side remains in the waiting branch's control flow to continue execution downwards, completing the writing of search state-related information. Then, the value of SearchMode is modified to trigger the search state switch.

[0095] S30303: Creates a non-state-switching type activity graph, serially executing input reading, execution of the system under test module, and output writing.

[0096] For non-state transition requirements, an activity diagram is designed for sequential execution, completing the following steps in turn:

[0097] S3030301: Read Input: Read input data from the test case table and load it into the module of the system under test;

[0098] S3030302: Execution of the system under test module: Calls the system under test module to complete the task logic;

[0099] S3030303: Output Write: Writes the output results generated by the system module under test into the model output column of the test case table for subsequent comparison and analysis.

[0100] S304: Use user interface modeling diagrams to create graphical user interfaces to visualize changes in system value attributes; design user interface modeling diagrams to enhance the system's visualization and interactivity.

[0101] The interface includes key parameters of the system module under test (such as status, input, and output) and control functions (such as status switching buttons and input parameter setting boxes). By updating the interface content in real time, users can intuitively observe parameter changes during system execution, facilitating debugging and verification. A schematic diagram of the user interface is shown below. Figure 5 As shown.

[0102] S305: Create simulation configuration diagrams, bind UI interfaces and execution targets, and customize model execution.

[0103] S4: Use the SysML modeling tool to simulate and execute test verification, read the test case table and assign values ​​to the system model variables. The system runs according to the internal modeling logic and generates output. Obtain the output and write it into the test case table in the corresponding position.

[0104] S401: Loading test cases: The test case table is read as an input file, and the data in the input columns of the table is extracted row by row and assigned to the corresponding variables in the system model. The variables drive the model to run according to the internal modeling logic.

[0105] S402: System Model Operation: The system executes operations based on the established activity diagram or state diagram to complete the behaviors corresponding to the requirements;

[0106] S403: Recording of output results: After the operation is completed, the system generates output results, which are automatically recorded in the model output column of the test case table to form a complete input-output pair;

[0107] S404: By comparing the model output with the expected output column in the table, it is determined whether the requirement verification has passed, and finally the comprehensive testing and verification of the system model is achieved.

[0108] S5: Design a test report generation tool, input the requirement items and test case tables into the test report generation tool for analysis and verification, and generate a test report.

[0109] This step aims to automate the generation of a standardized Word document containing test requirements, objectives, procedures, and results. The tool should be able to read data from the test case table, compare and analyze the "expected output" and "model output," generate verification conclusions, and fill them into the report in a clear format. Users input relevant information through the interface to generate a complete test report with one click. The tool's interface is as follows... Figure 6 As shown.

[0110] S501: Create a blank template and add four modules: test requirements, test objectives, test steps, and test results;

[0111] S502: Read the test case table file, create the table in the test steps module, and add the data;

[0112] S503: Process the tabular data, analyze the expected output and actual model output data in the test case table, compare and determine whether the verification is passed and generate the verification result;

[0113] S504: Write the verification results into the test results module;

[0114] S505: Use the Tkinter tool to design the test report generation interface, fill the document with user input in modules, and add buttons to generate the test report at a specified path.

[0115] In the final stage of automated test verification, the user loads the requirement items and test case table as input data into the test report generation tool. The tool first parses the requirement items and test case table, extracting the "input," "expected output," and "model output" information. Then, it compares the "expected output" and "model output" one by one according to a predetermined verification logic, analyzing the verification results. If the verification passes, the tool records a "pass" status in the generated report; if it fails, it records an inconsistency. Next, the tool fills the verification process and results into a Word document according to the four modules of test requirements, test objectives, test steps, and test results, and generates a standardized test report file in a specified path for the user to view and archive. Through this process, the test verification results are presented completely and clearly in a standardized manner. An example of the test report generated in this step is shown below. Figure 7 As shown.

[0116] This invention employs a model-driven systems engineering approach to provide an automated testing method for early model verification in the design of complex systems, enabling timely detection of system defects and improving the efficiency and reliability of system development.

[0117] Through the detailed description of the above specific implementation methods, this invention proposes a complete technical solution from requirements to verification. By formal modeling of natural language requirements, automated test case generation, model simulation and verification, and automated analysis of test results, a complete closed-loop process from requirements capture to verification is constructed. This method combines the rigor of formal modeling with the efficiency of model-driven verification, addressing the shortcomings of traditional requirements management and verification methods in terms of consistency, flexibility, and efficiency, and significantly improving the quality and reliability of complex system development.

[0118] This invention possesses excellent applicability and scalability, enabling its application in the design and development of high-reliability industrial systems such as aerospace and rail transportation. Particularly in scenarios with complex and frequently changing requirements, it effectively reduces the risks and costs of system development. Furthermore, the technical solution of this invention is not limited to the specific embodiments described. Those skilled in the art can make appropriate adjustments based on actual needs, such as expanding the formal syntax rules for requirements, optimizing the verification process, or incorporating more modeling languages. These adjustments do not depart from the core ideas of this invention and fall within its scope of protection.

[0119] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0120] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for formal requirements modeling and automatic testing and verification using SysML diagrams, characterized in that: The method includes the following steps: S1: Required text format conversion; S2: Design a requirements text processing tool to generate a test case table by inputting formalized requirements items; S1 includes the following steps: S101: System requirements item collection and organization; S102: After analyzing the structure of the requirement items, identify the key information of the requirement items and define the formal syntax rules for the requirement items; S103: Manually divide the requirement text, which consists of all requirement items, into a subject-verb-target structure, and decompose each requirement item in the requirement text into a formalized text by combining conditional statements; S104: Store the formalized condition-result pairs in the database; S3: Use the SysML modeling language to formally model the requirements text; S3 includes the following steps: S301: Draw a module definition diagram using SysML, clarify the system structure, add the system under test module and control test module, define the internal attributes of the module and their initial values, and add generalization relationships between modules; S302: Create a system model by adding SysML graphics to the modules of the system under test according to system requirements; S303: Create activity diagrams for the control test module based on the requirements, and complete automated test verification; S304: Use user interface modeling diagrams to create graphical user interfaces to visualize changes in system value attributes; design user interface modeling diagrams to enhance the system's visualization and interactivity. S305: Create simulation configuration diagrams, bind UI interfaces and execution targets, and customize model execution; S4: Perform test verification, read the test case table and assign values ​​to the system model variables. The system runs according to the internal modeling logic and generates output. Obtain the output and write it into the test case table in the corresponding position. S4 includes the following steps: S401: Loading test cases: The test case table is read as an input file, and the data in the input columns of the table is extracted row by row and assigned to the corresponding variables in the system model. The variables drive the model to run according to the internal modeling logic. S402: System Model Operation: The system executes operations based on the established activity diagram or state diagram to complete the behaviors corresponding to the requirements; S403: Recording of output results: After the operation is completed, the system generates output results, which are automatically recorded in the model output column of the test case table to form a complete input-output pair; S404: By comparing the model output with the expected output column in the table, it is determined whether the requirement verification has passed, and finally the comprehensive testing and verification of the system model is achieved. S5: Design a test report generation tool, input the requirement items and test case tables into the test report generation tool for analysis and verification, and generate a test report.

2. The method for automatic testing and verification based on formal requirements modeling and SysML diagrams according to claim 1, characterized in that: The design of the text processing tool for the requirements described in S2 includes the following steps: S201: Based on the formal grammar rules of the requirement items, the sentence pattern is clearly defined, the tool identifies the sentence pattern and extracts the information required for testing and verification from the requirement text by calling the corresponding processing function; S202: Divide the sentence into multiple parts according to its structure and extract the key information from each part; S203: Use key information and related requirements documents to generate input and expected output content, and merge them with the blank model output column into a test case table; S204: Design a requirements text processing interface to display the generated test case table in real time, and add a button to save the table as an Excel file.

3. The method for automatic testing and verification based on formal requirements modeling and SysML diagrams according to claim 2, characterized in that: The contents of each column in the test case table described in S203 are as follows: Input, including the content required for testing, is extracted from the requirements text or randomly generated from a range of preconditions; Expected output: Clearly define the behavior or result that the system will produce under corresponding input conditions. This can be extracted from the requirements text, generated based on the extracted information, or supplemented by referencing related requirements documents. The model output leaves empty columns, which will be used to fill in the actual running results during subsequent model execution.

4. The method for automatic testing and verification based on formal requirements modeling and SysML diagrams according to claim 3, characterized in that: S303 includes the following steps: S30301: Classify requirement items into state-switching type and non-state-switching type based on whether they involve state switching; S30302: Create a state transition type activity graph to enable the execution of the system under test module and the control behavior of the control test module to run in parallel; S30303: Creates a non-state-switching type activity graph, serially executing input reading, execution of the system under test module, and output writing.

5. The method for automatic testing and verification based on formal requirements modeling and SysML diagrams according to claim 4, characterized in that: S30303 includes the following steps: S3030301: Read Input: Read input data from the test case table and load it into the module of the system under test; S3030302: Execution of the system under test module: Calls the system under test module to complete the task logic; S3030303: Output Write: Writes the output results generated by the system module under test into the model output column of the test case table for subsequent comparison and analysis.

6. The method for automatic testing and verification based on formal requirements modeling and SysML diagrams according to claim 5, characterized in that: S5 includes the following steps: S501: Create a blank template and add four modules: test requirements, test objectives, test steps, and test results; S502: Read the test case table file, create the table in the test steps module, and add the data; S503: Process the tabular data, analyze the expected output and actual model output data in the test case table, compare and determine whether the verification is passed and generate the verification result; S504: Write the verification results into the test results module; S505: Use the Tkinter tool to design the test report generation interface, fill the document with user input in modules, and add buttons to generate the test report at a specified path.

Images