Formalized demand modeling and SysML graph automatic test verification method

Abstract

The invention discloses a formalization-based demand modeling and SysML graph automatic test verification method, and belongs to the technical field of computer software development. The method comprises the following steps: demand text format conversion; generating a test case table; carrying out formalized modeling on the demand text; test verification is executed, a test case table is read and assigned to a system model variable, the system runs according to internal modeling logic and generates output, and the output is obtained and written into the test case table at a corresponding position; and designing a test report generation tool. According to the method, the generation efficiency and accuracy of the test data are improved, a complete closed-loop process from demand capture to verification analysis is formed, the standardization and consistency of development are improved, automatic execution of the test cases is realized, verification is completed by automatically comparing model output with an expected result, and the test efficiency is improved. And the method can quickly adapt to demand change and function extension of a complex system.

Description

Technical Field

[0001] The invention relates to a formalized requirement modeling and SysML diagram automatic testing and verification method, belonging to the technical field of computer software development. Background Art

[0002] As the complexity of modern system engineering continues to increase, traditional requirements development and verification methods are increasingly showing their limitations in dealing with changes in complex system requirements, verifying consistency, and improving development efficiency.

[0003] Model-Based Systems Engineering (MBSE), as an emerging system development method, provides a model-based means of demand capture, design, verification and traceability, which significantly improves the efficiency and reliability of the system engineering process. However, existing model-driven methods focus on model creation and management, and demand verification mostly relies on manual analysis and static testing. There is a lack of automated support for demand verification, which makes system consistency verification in complex demand scenarios inefficient. In particular, there is still much room for improvement in terms of clear expression of requirements, the correlation between requirements and models, and the degree of automation of model verification.

[0004] Systems Modeling Language (SysML), as a graphical modeling language that supports system design, is widely used in modeling system structure, behavior, and constraints. The SysML model has the characteristics of visualization and executableness, making it a powerful tool for formal requirements modeling and verification. However, it is still insufficient in terms of automated support for requirements verification. For example, in complex requirements scenarios, the generation and verification process of test cases usually relies on cumbersome manual operations, and it is difficult to achieve an efficient closed loop of requirements and verification. These problems directly restrict the depth and breadth of the application of MBSE methods in engineering. Researchers need to explore the construction of 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 technology has gradually become a research hotspot. Formal methods transform natural language requirements into structured and parsable formal representations, so that requirements can be directly mapped to system models. This method not only improves the clarity and consistency of requirement expression, but also provides a basis for requirement verification and system behavior verification. However, relying solely on formal methods is difficult to meet the full life cycle requirements of complex system development. Developing a model-based automated testing method can detect system design defects in the early stages by combining formal requirement modeling with simulation technology, thereby reducing the cost of later modifications.

[0006] Therefore, how to build an efficient and automated requirements management and verification method, especially how to achieve structured expression of requirements, close association with models, and automated verification processes through formal means, has become a key issue that needs to be solved in the current system engineering field. 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 technology, may provide an integrated solution for requirements modeling and verification. Summary of the invention

[0007] In order to solve the problems existing in the background technology, the present invention provides a method for automatic testing and verification based on formalized requirement modeling and SysML diagrams.

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

[0009] S1: Requirement text format conversion;

[0010] S101: Collection and organization of system requirements;

[0011] S102: After analyzing the structure of the requirement item, identify the key information of the requirement item, and customize the formal grammatical rules of the requirement item;

[0012] S103: manually divide the requirement text consisting of all requirement items into a subject-verb-target structure, and disassemble all requirement items of the requirement text one by one in combination with conditional statements, and translate them into formal text;

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

[0014] S2: Design a requirement text processing tool to input the formalized requirement items to generate a test case table;

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

[0016] S201: Clarify the sentence pattern according to the formal grammar rules of the requirement items, the tool recognizes the sentence pattern and extracts the information required for test verification from the requirement text by calling the corresponding processing function;

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

[0018] S203: Generate input and expected output content using key information and associated requirement files, and merge with blank model output columns into a test case table;

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

[0020] Inputs, including what is needed for the test, are extracted from the requirements text or randomly generated through precondition ranges;

[0021] Expected output, which specifies the behavior or result of the system under the corresponding input conditions, is extracted from the requirement text or generated based on the extracted information or supplemented by referring to the associated requirement documents;

[0022] Model output, leave the column blank to be filled with actual running results during subsequent model execution.

[0023] S204: Design a requirement 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 SysML modeling language to formally model the requirement text;

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

[0026] S302: Add SysML graphics under the system under test module to create a system model according to system requirements;

[0027] S303: Create an activity diagram for the control test module requirements and complete the automated test verification;

[0028] S30301: Classify the requirement items into state switching type and non-state switching type according to whether they involve state switching;

[0029] S30302: Create a state switching type activity diagram to make the execution of the system under test module parallel with the control behavior of the control test module;

[0030] S30303: Create a non-state switching type activity diagram to serially execute input reading, SUT module execution, and output writing.

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

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

[0033] S3030303: Output writing: Write 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: Create a graphical user interface using a user interface modeling diagram to visualize changes in system value attributes; design a user interface modeling diagram to enhance the visualization and interaction capabilities of the system;

[0035] S305: Create a simulation configuration diagram, bind the UI interface and execution target, and customize the model execution.

[0036] S4: Execute test verification, read the test case table and assign it to the system model variable, the system runs according to the internal modeling logic and generates output, obtains the output and writes it into the test case table at the corresponding position;

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

[0038] S402: Operation of the system model: The system performs operations according to the established activity diagram or state diagram to complete the behavior 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 is passed, and finally a comprehensive test 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, and add data after creating a table in the test step module;

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

[0045] S504: writing the verification result into the test result module;

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

[0047] Compared with the prior art, the present invention has the following beneficial effects:

[0048] 1. The present invention formalizes natural language requirements, extracts key information and generates test cases. This solves the problem of time-consuming and error-prone manual operations in the traditional test case generation process, and greatly improves the efficiency and accuracy of test data generation. At the same time, the automatically generated test cases have high coverage and can effectively cope with the testing challenges brought by the diversity of complex system requirements.

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

[0050] 3. The present invention relies on automated model simulation and verification technology to realize the automated execution of test cases, and completes the verification by automatically comparing the model output with the expected results. This method not only improves the verification efficiency, but also can discover potential problems in system design at an early stage, reducing the cost caused by problem repair in the later stage of development.

[0051] 4. The automated test verification process designed by the present invention can quickly adapt to the requirements changes and functional expansion of complex systems. The automatic update of test cases and the efficient execution of the verification process can support multiple rounds of iterative development, which is particularly suitable for high-reliability industrial systems with complex requirements and frequent changes, and can provide a more scientific solution for system development in various fields. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 1 is a flow chart of the present invention;

[0053] Figure 2 It is a formal text to generate a test case table flow chart;

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

[0055] Figure 4 It is the verification activity diagram of the RR system state switching requirement instance;

[0056] Figure 5 is a user interface schematic;

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

[0058] Figure 7 This is a sample test report. DETAILED DESCRIPTION

[0059] The technical solution of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0060] A method for automatic testing and verification based on formalized requirements modeling and SysML diagrams, the method comprising the following steps:

[0061] S1: Requirement text format conversion;

[0062] S101: System requirement items are collected and sorted, mainly by screening and sorting requirement items from various sources. The sources of requirement items mainly include functional requirements provided by stakeholders, specification contents of industry standard documents, and design specifications of existing system architectures. In order to ensure the comprehensiveness and accuracy of requirement items, these sources need to be carefully screened, and redundant, ambiguous or contradictory requirement items need to be cleaned and sorted. Finally, the requirement items are systematically recorded in the requirement document, and are numbered and classified for easy tracking and management;

[0063] S102: After analyzing the structure of the requirement item, identify the key information of the requirement item, and customize the formal grammatical rules of the requirement item;

[0064] S103: manually divide the requirement text consisting of all requirement items into a subject-verb-target structure, and disassemble all requirement items of the requirement text one by one in combination with conditional statements, and translate them into formal text;

[0065] After the collection is completed, the requirement items need to be analyzed in detail to clarify the key contents of the requirement items, including subjects, verbs, goals and related conditions. By identifying these key contents, the logical core of the requirement items can be extracted. Then, according to the characteristics of the requirement items, the grammatical rules for the formalization of the requirement items are formulated. The sentence structure of "subject-verb-goal" is uniformly adopted, and conditional statements (such as GIVEN, WHEN, THEN) are used to express logical relationships. The complex natural language is converted into a structured and easy-to-parse format through the formalization of the requirement text. In this process, it is also necessary to verify the applicability of the grammatical rules and make appropriate adjustments to the grammatical rules to adapt to the diversity of the requirement items.

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

[0067] The formal transformation of requirement items is a key link in the technical route, which involves parsing and reorganizing each requirement item one by one. Specifically, the requirement items are divided into logical units of "subject-verb-target" and reformulated into formal text according to custom grammar rules and conditional statements.

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

[0069] S2: Design a requirement text processing tool to input the formalized requirement items to generate a test case table;

[0070] This step aims to provide a requirement text processing tool to automatically generate 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 demand text processing tool described in S2 includes the following steps:

[0072] S201: Clarify common sentence patterns based on the formal grammatical rules of requirement items, such as "SHOULDHAVE", "SHOULD support transitions" and "SHOULD BE". The tool needs to be able to recognize these sentence patterns and extract the information required for test verification from the requirement text by calling the corresponding processing function; to meet the needs of different scenarios, the tool also needs to support the expansion of sentence pattern rules, and developers can add new rules at any time to cover more requirement types.

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

[0074] S203: Generate input and expected output content using key information and associated requirement files (optional), and merge with blank model output columns into a test case table;

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

[0076] Input, including the initial conditions and parameter settings required for the test, is extracted from the requirement text or randomly generated through the precondition range;

[0077] Expected output, which specifies the behavior or result of the system under the corresponding input conditions, is extracted from the requirement text or generated based on the extracted information or supplemented by referring to the associated requirement documents;

[0078] Model output, leave the column blank to be filled with actual running results during subsequent model execution.

[0079] S204: Use Tkinter tool to design the requirement 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 the requirement text in the interface and view the generated test cases, and export them to Excel files by clicking the Save button for subsequent storage and application.

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

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

[0083] Taking the RR system created by the present invention as an example, its module definition diagram is as follows Figure 3 As shown in the figure, the RR module has two functions: search and tracking. The controlRR module can access the variables of the RR module by inheriting the RR module to complete the reading and modification. The RR module simulation verification model is modeled in the controlRR module.

[0084] S302: Adding SysML graphics such as activity diagrams and state diagrams under the module of the system under test to create a system model according to system requirements;

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

[0086] S303: Create an activity diagram for the control test module requirements and complete the automated test verification;

[0087] S30301: Classify the requirement items into state switching type and non-state switching type according to whether they involve state switching;

[0088] S30302: Create a state switching type activity diagram to make the execution of the system under test module parallel with the control behavior of the control test module;

[0089] For the state switching type requirement items, an activity diagram that can be executed in parallel is designed. The left side of the activity diagram represents the state switching logic of the system under test module, while the right side implements the monitoring and verification of the state switching by the control test module. During the state switching process, the state change of the system under test module is triggered by the input parameters and the model output is generated.

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

[0091] Requirements: The RR system should have the switching function of main airspace search, sliding window search, and guided search mode. Figure 4 .

[0092] First, initialize and read the number of states to be switched. The first search state entered has no preceding search state, is defined as empty, and no search point trace verification is performed.

[0093] State switching: Use branch nodes and collection nodes to make the execution of the RR module and the control behavior of the RR module concurrent.

[0094] The left branch executes the RR module and enters the ZZ state by default. When performing target detection, targetState=0 enters the search mode and executes the state diagram. The default search mode is the main airspace search mode. After switching to this state and completing the execution, searchend is modified to true, indicating that this state has been executed. At this time, the control flow on the right side stays in the waiting branch to continue to execute downward, complete the writing related to the search state, and then modify the value of SearchMode to trigger the search state switch.

[0095] S30303: Create a non-state switching type activity diagram to serially execute input reading, SUT module execution, and output writing.

[0096] For non-state switching requirements, design a serial execution activity diagram and complete the following steps in sequence:

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

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

[0099] S3030303: Output writing: Write 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: Create a graphical user interface using a user interface modeling diagram to visualize changes in system value attributes; design a user interface modeling diagram to enhance the visualization and interaction capabilities of the system;

[0101] The interface content includes key parameters of the module under test (such as status, input, 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 the parameter changes during the system execution process, which is convenient for debugging and verification. Figure 5 shown.

[0102] S305: Create a simulation configuration diagram, bind the UI interface and execution target, and customize the model execution.

[0103] S4: Use SysML modeling tool to simulate and execute test verification, read the test case table and assign it to the system model variable, the system runs according to the internal modeling logic and generates output, and the output is obtained and written into the test case table at the corresponding position;

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

[0105] S402: Operation of the system model: The system performs operations according to the established activity diagram or state diagram to complete the behavior 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 is passed, and finally a comprehensive test 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 automatically generate a standardized Word document containing test requirements, test objectives, test steps and test results. The tool needs to 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. The user enters relevant information through the interface and generates a complete test report with one click. The tool usage interface is as follows Figure 6 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, and add data after creating a table in the test step module;

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

[0113] S504: writing the verification result into the test result module;

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

[0115] In the final stage of automated test verification, the user loads the requirement items and test case tables as input data into the test report generation tool. The tool first parses the requirement items and test case tables, extracts the "input", "expected output" and "model output" information, and then compares the "expected output" and "model output" one by one according to the established verification logic to analyze the verification results. If the verification passes, the tool will record the "pass" status in the generated report; if it fails, there will be inconsistencies in the record. Next, the tool fills the verification process and results into a Word document according to the structure of the four modules of test requirements, test objectives, test steps and test results, and generates a standardized test report file in the specified path for users to view and archive. Through this process, the results of the test verification can be fully presented in a clear and standardized manner. The example figure of the test report generated in this step is as follows Figure 7 shown.

[0116] The present invention uses the method of model-driven system engineering to provide an automated testing method for model verification in the early stage of complex system design, so as to timely discover system defects and improve the efficiency and reliability of system development.

[0117] Through the detailed description of the above specific implementation methods, the present invention proposes a complete technical solution from requirements to verification. Through the 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, solves the shortcomings of traditional requirements management and verification methods in consistency, flexibility, and efficiency, and significantly improves the quality and reliability of complex system development processes.

[0118] The present invention has good applicability and extensibility, and can be applied to the design and development of high-reliability industrial systems such as aerospace and rail transportation, especially in scenarios with complex requirements and frequent changes, and can effectively reduce the risk and cost of system development. In addition, the technical solution of the present invention is not limited to the specific implementation methods described, and technicians in related fields can make appropriate adjustments according to actual needs, such as expanding the formal grammatical rules of requirements, optimizing the verification process, or combining more modeling languages. These adjustments do not deviate from the core idea of ​​the present invention and fall within the scope of protection of the present invention.

[0119] It will be apparent to those skilled in the art that the 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 the spirit or essential features of the invention. 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, and it is intended that all variations within the meaning and range of equivalents of the claims be included in the invention. Any reference numeral in a claim should not be considered as limiting the claim to which it relates.

[0120] In addition, it should be understood that although the present specification is described according to implementation modes, not every implementation mode contains only one independent technical solution. This description of the specification is only for the sake of clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each embodiment may also be appropriately combined to form other implementation modes that can be understood by those skilled in the art.

Claims

1. A method for automatic testing and verification based on formalized requirements modeling and SysML diagrams, characterized in that: The method comprises the following steps: S1: Requirement text format conversion; S2: Design a requirement text processing tool to input the formalized requirement items to generate a test case table; S3: Use SysML modeling language to formally model the requirement text; S4: Execute test verification, read the test case table and assign it to the system model variable, the system runs according to the internal modeling logic and generates output, obtains the output and writes it into the test case table at the corresponding position; 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 of formalized requirements modeling and SysML diagrams according to claim 1, characterized in that: The S1 comprises the following steps: S101: Collection and organization of system requirements; S102: After analyzing the structure of the requirement item, identify the key information of the requirement item, and customize the formal grammatical rules of the requirement item; S103: manually divide the requirement text consisting of all requirement items into a subject-verb-target structure, and disassemble all requirement items of the requirement text one by one in combination with conditional statements, and translate them into formal text; S104: Store the formalized condition-result pairs in a database.

3. The method for automatic testing and verification based on formalized requirements modeling and SysML diagram according to claim 1, characterized in that: The design of the demand text processing tool described in S2 includes the following steps: S201: Clarify the sentence pattern according to the formal grammar rules of the requirement items, the tool recognizes the sentence pattern and extracts the information required for test verification from the requirement text by calling the corresponding processing function; S202: Segment the sentence into multiple parts according to the structure and extract key information from each part; S203: Generate input and expected output content using key information and associated requirement files, and merge with blank model output columns into a test case table; S204: Design a requirement 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.

4. The method of automatic testing and verification based on formalized requirements modeling and SysML diagram according to claim 3, characterized in that: The contents of each column of the test case table in S203 are as follows: Inputs, including what is needed for the test, are extracted from the requirements text or randomly generated through precondition ranges; Expected output, which specifies the behavior or result of the system under the corresponding input conditions, is extracted from the requirement text or generated based on the extracted information or supplemented by referring to the associated requirement documents; Model output, leave the column blank to be filled with actual running results during subsequent model execution.

5. The method of automatic testing and verification based on formalized requirements modeling and SysML diagram according to claim 1, characterized in that: The S3 comprises the following steps: S301: Draw a module definition diagram using SysML, clarify the system structure, add the system under test module and the control test module, define the internal attributes of the module and its initial values, and add the generalization relationship between modules; S302: Add SysML graphics under the system under test module to create a system model according to system requirements; S303: Create an activity diagram for the control test module requirements and complete the automated test verification; S304: Create a graphical user interface using a user interface modeling diagram to visualize changes in system value attributes; design a user interface modeling diagram to enhance the visualization and interaction capabilities of the system; S305: Create a simulation configuration diagram, bind the UI interface and execution target, and customize the model execution.

6. The method of formalized requirement modeling and SysML diagram automatic testing and verification according to claim 5, characterized in that: The S303 comprises the following steps: S30301: Classify the requirement items into state switching type and non-state switching type according to whether they involve state switching; S30302: Create a state switching type activity diagram to make the execution of the system under test module parallel with the control behavior of the control test module; S30303: Create a non-state switching type activity diagram to serially execute input reading, SUT module execution, and output writing.

7. The method of automatic testing and verification based on formalized requirements modeling and SysML diagram according to claim 6, characterized in that: The S30303 includes the following steps: S3030301: Read input: Read input data from the test case table and load it into the system under test module; S3030302: Execution of the system under test module: calling the system under test module to complete the task logic; S3030303: Output writing: Write 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.

8. The method of automatic testing and verification based on formalized requirements modeling and SysML diagram according to claim 1, characterized in that: The S4 comprises the following steps: S401: Loading of test cases: The test case table is read as an input file, and the input column data in the table is extracted row by row and assigned to the corresponding variables in the system model. The variable drives the model to run according to the internal modeling logic; S402: Operation of the system model: The system performs operations according to the established activity diagram or state diagram to complete the behavior 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 is passed, and finally a comprehensive test and verification of the system model is achieved.

9. The method of automatic testing and verification based on formalized requirements modeling and SysML diagram according to claim 8, characterized in that: The S5 comprises 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, and add data after creating a table in the test step module; S503: Process the table data, analyze the expected output and actual model output data in the test case table, compare and determine whether they pass the verification and generate a verification result; S504: writing the verification result into the test result module; S505: Use Tkinter tool to design the test report generation interface, fill the user input module into the document, and add a button to generate the test report at the specified path.

Images