A method for automatically generating test cases for SCADE model

Abstract

The application discloses a kind of test case generation method for SCADE model, by reading the XML document of SCADE model automatic generation, obtain the information of safety state machine in model, the state and transition in safety state machine model are converted into the node and edge in directed graph;Then depth traversal directed graph, obtain state transition path;To alleviate the combination explosion problem of transition condition, using combination test algorithm AETG, optimize transition condition, obtain transition condition path;And using shielding algorithm carries out the logic value of meeting MC / DC coverage, according to the mapping of transition condition restriction to specific data, generate specific test case for each transition condition, to realize a kind of test case generation for SCADE model.

Description

Technical Field

[0001] This invention belongs to the field of model verification and simulation of safety-critical software, specifically involving a method for automatically generating test cases for SCADE models. Background Technology

[0002] A safety-critical system is a system whose failure would threaten human life, cause significant property damage, or severely harm the surrounding environment. Common safety-critical systems include flight control systems, aerospace vehicles, nuclear reactor monitoring systems, and critical care patient monitoring systems. Safety-critical software, as a component of a safety-critical system, directly or indirectly leads to a dangerous state if it fails. Therefore, safety, reliability, and real-time performance are fundamental requirements for such systems and software. For example, the famous explosion of the European Ariane 5 rocket and the 2018 Boeing 737 Max crash were both caused by the failure of onboard software.

[0003] Traditional system design often adopts a text-based approach. However, as the complexity of designed products increases, the shortcomings of the text-based approach have become increasingly apparent, making it unable to meet current challenges. For example, design documents based on natural language descriptions are prone to ambiguity, leading to low communication efficiency; at the same time, natural language is difficult to guarantee the accuracy of semantic descriptions; and text-based designs cannot be simulated, tested, and verified in the early stages, which is not conducive to saving development costs.

[0004] The emergence of Model Based Systems Engineering (MBSE) technology provides an effective means to address these problems. MBSE supports the formalized modeling of system requirements, design, analysis, verification, and validation activities, starting from the conceptual design phase and continuing throughout the development and later lifecycle phases. In recent years, the development of safety-critical systems has primarily adopted the MBSE model.

[0005] The international standard DO-178C for airborne system airworthiness certification software development incorporates model-based development methods (DO-331) and formal methods (DO-333) as important technical supplements to its core standard. DO-331 introduces the concepts of specification models and design models. Specification models describe high-level requirements and are abstract expressions of the functionality, performance, or safety characteristics of software components. Specification models do not define the details of software design. Design models specify the internal data structures, internal data flows, and control flows of software components. Design models describe low-level requirements and software architecture. In MBSE (Basic Software Environment SE), languages ​​such as SysML and AADL are commonly used to describe specification models, while SCADE (Safety-Critical Application Development Environment) and Simulink are widely used for design models. Among these, SCADE is the only truly formal language among mainstream model-based development tools. The SCADE modeling method is based on a synchronous language, which can be derived through a series of rigorous mathematical formulas. Its language is precise, unambiguous, and deterministic, making it suitable for describing the control logic of safety-critical systems and software. Compared to other models, SCADE's compilation tools are SIL4 level safety certified, enabling the conversion from model to code. Test cases generated on this basis can be used not only for testing SCADE models but also for testing the code generated from them. SCADE products, due to their system-wide, model-based development platform encompassing simulation and software implementation, have become the mainstream solution for software modeling, analysis and testing, simulation, and code generation in safety-critical fields.

[0006] However, software development for safety-critical systems is a costly and time-consuming process. The Validation and Verification (V&V) phases consume approximately 50%-70% of software development resources. Despite breakthroughs in static (V&V) techniques, such as model checking and theorem proving, testing remains an irreplaceable technique. Currently, most of the time spent on V&V is devoted to developing test cases to fully test the required functionality of the software (black-box, requirements-based testing) and adequately cover the implementation (white-box, code-based testing). Therefore, automating the test case generation process and providing requirements-based and code-based test suites that meet the most stringent standards for safety-critical systems (e.g., DO-178C) would result in significant time and cost savings. In recent years, Model-Based Testing (MBT) has become a commonly used technique in software testing due to its high testing efficiency. Common MBT techniques include UML modeling and Finite State Machine (FSM) modeling. However, in the field of safety-critical systems, test cases for models are often still written manually.

[0007] Several studies have considered how to automatically generate test cases for formal models. For example, Wakankar et al. used the tool SAL-ATG, which can automatically generate test cases for models developed using the SAL specification language. They employed the MC / DC coverage criterion as the test objectives covered by the generated test cases. For a given SAL specification, a Boolean trap variable representing the test objective is added; if the given test objective is feasible, SAL-ATG generates a test sequence. However, this is not applicable to SCADE models. To use this method, the SCADE model needs to be manually converted to a SAL model, and the Boolean trap variable of the SAL specification also needs to be manually generated. Other studies focus on SCADE models, using counterexamples generated by model checkers as test cases. For instance, Aniculaesei et al. designed a workflow to build test cases according to formal requirements and check test quality through mutation testing. Since the formal verification tool DESIGN VERIFIER, which comes with SCADE, cannot verify LTL properties, the authors considered converting the LTL into an NBA automaton. However, the problem lies in the fact that DESIGNVERIFIER's basic verification technique does not allow the use of SCADE observers to describe liveness attributes. The limitations of formal verification tools mean that automatically generated test cases are clearly insufficient. Furthermore, in MBSE, model correctness is primarily determined through simulation. In fact, to comply with the DO 178C standard, the Modified Decision Condition Coverage (MC / DC) standard must be used to evaluate the model coverage achieved during simulation. Therefore, automatically analyzing the internal data flow and control flow of the SCADE model and generating test cases based on model information, guided by MC / DC coverage, is crucial for reducing testing costs. Summary of the Invention

[0008] Purpose of the invention: To address the problem of how to automatically generate test cases for models in the field of safety-critical systems, this invention proposes an automatic test case generation method for SCADE models, which reduces the cost of manually analyzing models and designing test cases, and improves the efficiency of model testing.

[0009] Technical solution: A method for automatically generating test cases for SCADE models, comprising the following steps:

[0010] Step 1: Obtain the input variables of the specified SCADE model, obtain the value range information of the SCADE model for the input variables, and obtain the model XML document automatically generated by the specified SCADE model;

[0011] Step 2: Use an XML document parser to parse the model XML document to obtain the state information and transition information of the security state machine in the specified SCADE model;

[0012] Step 3: Construct a directed graph using the state information of the safe state machine as nodes and the transition information of the safe state machine as edges;

[0013] Step 4: Use the depth-first search algorithm to traverse the directed graph and obtain all state transition paths; each state transition path consists of n+1 states and n transition conditions, and each transition condition is decomposed into several sub-conditions according to the condition being a logical truth value.

[0014] Step 5: Apply a combined test algorithm to all state transition paths to obtain transition condition paths; each transition condition path is a combination of sub-conditions.

[0015] Step 6: Convert the infix expression of each sub-condition of the migration condition path into Reverse Polish Notation (RPN). Based on the converted RPN, construct a syntax tree. Using the masking algorithm, starting from the root node of the syntax tree, after several adjustments to the position of any leaf node to the leftmost leaf node, reassign the entire syntax tree to obtain abstract test cases for the sub-conditions, thus obtaining an abstract test case set.

[0016] Step 7: Based on the logical values ​​of each abstract test case in the abstract test case set and the value range information of the input variables in the SCADE model, randomly generate a specific value for the input of each abstract test case;

[0017] Step 8: Write all abstract test cases into a test script file to obtain a test case file; use the simulator of the SCADE tool to simulate the test case file and obtain the test results.

[0018] Furthermore, in step 5, the combined testing algorithm is applied to all state transition paths to obtain the transition condition paths, specifically including:

[0019] S510: Get the pathlist, which stores all state transition paths;

[0020] S520: Determine if the path set Pathlist is empty. If it is empty, end the process, indicating that the transition condition paths for all state transition paths have been overwritten, and output the transition condition path set Clist. If it is not empty, jump to S530.

[0021] S530: Retrieve a state transition path `path` from the path set `Pathlist`, obtain the number of transition conditions `Tnum` for that state transition path `path`, remove that state transition path from the path set `Pathlist`, and store the sub-conditions of each transition condition of that state transition path `path` into a tuple `P`. <T i C j>, where T i C represents the transition conditions on the state transition path. j This represents the sub-conditions corresponding to the migration condition;

[0022] S540: Combine the sub-conditions belonging to different migration conditions in pairs and store them in a tuple M. <P x ,P y >, P x ,P y This indicates two sub-conditions belonging to different migration conditions; jump to S550.

[0023] S550: Finding the pair M <P x ,P y The subcondition P that appears most frequently in > t This subcondition P t Add to the migration condition path set Clist, and delete the tuple M. <P x ,P y P appears in > t The tuple; jump to S560;

[0024] S560: Combine all sub-conditions in the migration condition path set Clist with all sub-conditions not in the migration condition path set Clist and store them in a pair. <P m ,P k >, where P m ∈Clist, P k Indicates a subcondition that is not in the current migration condition path set Clist; records the tuple. <P m ,P k In the binary M <P x ,P y The number of occurrences in > will be the number of times P appears. k Add the migration condition path set Clist and remove the tuple M. <P x ,P y P appears in > k The tuple; jump to S570:

[0025] S570: Determine whether the number of sub-conditions in the migration condition path set Clist is less than the number of migration conditions Tnum. If it is not less than Tnum, jump to S520; if it is less than Tnum, jump to S560.

[0026] Furthermore, in step 6, the masking algorithm is used to start from the root node of the syntax tree, and after several adjustments to the position of any leaf node to the leftmost leaf node, the entire syntax tree is reassigned to obtain abstract test cases for the sub-conditions, thereby obtaining an abstract test case set, specifically including:

[0027] S610: Take the condition of the leftmost node of the syntax tree as the first condition, and set the condition of the leftmost node of the syntax tree as the current node. Assign false and true values ​​to the current node respectively. The remaining child nodes take the default values ​​according to the masking algorithm to obtain two sets of abstract test cases.

[0028] S620: Determine if the current condition is the last condition. If yes, end the test and obtain all abstract test cases. If not, shift one condition to the right as the current condition.

[0029] S630: The value of the current condition is obtained by inverting its default value; the current condition is set as a free condition.

[0030] S640: The default value of the free condition is passed to the precondition to the left, and the precondition is set as a free condition;

[0031] S650: If the free condition is the leftmost node of the syntax tree, continue; otherwise, go to S640.

[0032] S660: The remaining undetermined conditions in this set of test cases are filled with their default values. After completion, a new set of test cases is obtained, and the process moves to S620.

[0033] Furthermore, in step 8, all abstract test cases are written into a test script file to obtain a test case file; the test case file is then simulated using the simulator of the SCADE tool to obtain test results, specifically including:

[0034] Write all abstract test cases into the test script file according to the following format to obtain the test case file;

[0035] SSM::set <var> <val>

[0036] SSM::cycle[ <integer>]

[0037] Here, var refers to the name of the variable to be assigned, val refers to the specific value assigned to the var variable, and cycle refers to the number of cycles in which this abstract test case is run;

[0038] After generating test case files with the .sss extension, use the simulator in the SCADE tool to perform simulations and obtain test results.

[0039] Beneficial effects: Compared with the prior art, the present invention has the following advantages:

[0040] (1) This invention obtains the information of the security state machine in the model by reading the XML document automatically generated by the SCADE model, and transforms the state and transition in the security state machine model into nodes and edges in the directed graph; then, it performs a depth-first traversal of the directed graph to obtain the state transition path; in order to alleviate the combinatorial explosion problem of transition conditions, the combinatorial testing algorithm AETG is used to optimize the transition conditions and obtain the transition condition path; and the masking algorithm is used to satisfy the logical values ​​of MC / DC coverage. Based on the mapping of the transition condition constraints to specific data, specific test cases are generated for each transition condition, thereby realizing an automatic test case generation tool for SCADE models, reducing the cost of manual model analysis and test case design, and improving the efficiency of model testing;

[0041] (2) By using the test case set automatically generated by the present invention to test the SCADE model, software defects can be discovered in the early stages of the development process. Attached Figure Description

[0042] Figure 1 A modular architecture diagram of a method for automatically generating test cases for SCADE models;

[0043] Figure 2 An XML document structure diagram of the SCADE safe state machine;

[0044] Figure 3 This is a flowchart of a directed graph depth-first traversal.

[0045] Figure 4 Flowchart for combined testing of the AETG algorithm;

[0046] Figure 5 The algorithm flowchart is hidden. Detailed Implementation

[0047] The objects and functions of the present invention, as well as the methods for achieving these objects and functions, will be clarified by referring to exemplary embodiments. However, the present invention is not limited to the exemplary embodiments disclosed below; it can be implemented in various forms. The purpose of this specification is merely to help those skilled in the art to comprehensively understand the specific details of the invention.

[0048] Embodiments of the present invention will now be described with reference to the accompanying drawings.

[0049] Example 1:

[0050] This embodiment of the method for automatically generating test cases for SCADE models includes the following steps:

[0051] Step 1: Obtain the input and output variables of the specified SCADE model, obtain the value range information of the SCADE model for the input variables, and obtain the model XML document automatically generated by the specified SCADE model;

[0052] Step 2: Use an XML document parser to parse the model XML document to obtain the state information and transition information of the security state machine in the specified SCADE model;

[0053] Step 3: Construct a directed graph using the state information of the safe state machine as nodes and the transition information of the safe state machine as edges;

[0054] Step 4: Use the depth-first search algorithm to traverse the directed graph and obtain all state transition paths; each state transition path consists of n+1 states and n transition conditions, and each transition condition is decomposed into several sub-conditions according to the condition being a logical truth value.

[0055] Step 5: Apply a combined test algorithm to all state transition paths to obtain transition condition paths; each transition condition path is a combination of sub-conditions.

[0056] Step 6: Convert the infix expression of each sub-condition of the migration condition path into Reverse Polish Notation (RPN). Based on the converted RPN, construct a syntax tree. Using the masking algorithm, starting from the root node of the syntax tree, after several adjustments to the position of any leaf node to the leftmost leaf node, reassign the entire syntax tree to obtain abstract test cases for the sub-conditions, thus obtaining an abstract test case set.

[0057] Step 7: Based on the logical values ​​of each abstract test case in the abstract test case set and the value range information of the input variables in the SCADE model, randomly generate a specific value for the input of each abstract test case;

[0058] Step 8: Write all abstract test cases into a test script file to obtain a test case file; use the simulator of the SCADE tool to simulate the test case file and obtain the test results.

[0059] Example 2:

[0060] This embodiment relates to a method for automatically generating test cases for SCADE models, such as... Figure 1 As shown, this method mainly consists of three steps: SCADE model loading, state transition path set generation, and test case set generation. First, SCADE is used to model the document requirements. Java code calls the API provided by SCADE and uses EMF to load the I / O information of the SCADE model components. The safety state machine information is obtained from the automatically generated model XML document from the SCADE model, and the states and transitions in the safety state machine model are transformed into nodes and edges in a directed graph. State transition paths are obtained by depth-first traversal of the directed graph. Since transition conditions in safety-critical systems are usually complex, and combinations of transition conditions can easily lead to state space explosion, the AETG combinatorial testing algorithm is used to optimize the transition conditions and obtain transition condition paths. Finally, to achieve high MC / DC coverage, a masking algorithm is used to select logical values ​​that satisfy MC / DC coverage. Based on the mapping of logical condition constraints to specific data, specific test cases are generated for each logical condition, enabling high MC / DC coverage even with a small number of test cases. This achieves an automatic test case generation method for SCADE models. Because the SCADE tool provides simulation and testing capabilities, the generated test case sets will be saved in the form of test scripts supported by the SCADE tool.

[0061] The specific steps for loading a SCADE model are explained below.

[0062] The SCADE tool supports automatically generating XML documents from the created SCADE model. Loading the SCADE model is primarily achieved through the XML document containing model information provided by the SCADE tool and the API provided by SCADE. SCADE models are stored by operator, with each operator stored separately in an XML .xscade file. The XML document presents a tree structure, as shown below. Figure 2 As shown, among the child nodes of the Operator node, the inputs node stores the data type and name of all inputs of the operator; the outputs node stores the data type and name of all outputs of the operator; the locals node stores the data type and name of all local variables of the operator; the data node stores the data information in the operator, its child node StateMachine stores the name of the safe state machine, its child node State stores the information of the state elements, the child node Transition of the State node stores the information of the transition elements, the child node target of the Transition node stores the target state information of the transition elements, and the condition stores the transition condition information of the transition elements.

[0063] The XML document is parsed using the Dom4J XML parser, a Java XML API for reading and writing XML files. Dom4J can be used to parse the State and Transition of the secure state machine in the SCADE model.

[0064] The parsed State is used as the nodes of the directed graph, and the Condition of the Transition is used as the edges of the directed graph. The directed graph is stored in the form of an adjacency list, thus loading the SCADE model into a directed graph.

[0065] To generate test cases for a SCADE model, you need to obtain the relevant model input variable names and their initial value range information. The Java API provided by the SCADE tool supports obtaining the above information, including: all operators of the model (a SCADE model is composed of several nested operators), constants corresponding to each operator, input variables, and preset input value range information.

[0066] The specific steps for generating the state transition path set are explained below.

[0067] Before generating the specific test case set, a depth-first traversal directed graph algorithm is used to obtain all state transition paths in the directed graph generated from the SCADE model. Due to the complexity of the secure state machine structure, cycles exist in the generated directed graph; therefore, the cycle case must be considered during the depth-first traversal.

[0068] like Figure 3 As shown, the specific depth-first traversal steps include:

[0069] S100: Get all starting vertices of the directed graph G and store them in the Starts set; get all edges of the directed graph G and store them in the Edgelist set;

[0070] S200: Check if the Starts set is empty. If it is empty, end the traversal and obtain the path list. All paths from all starting points to all ending points have been found. The obtained path list is the total number of state transition paths in the directed graph. If it is not empty, take a starting point start from the Starts set and delete the starting point start from the Starts set. Jump to S300.

[0071] S300: Obtain all endpoints of the directed graph G, store them in the Ends set, and jump to S400;

[0072] S400: Check if the Ends set is empty. If it is empty, end the traversal and jump to S200. If it is not empty, take an end point from the Ends set and delete the end point from the Ends set, then jump to S500.

[0073] S500: Determine whether the current path Curpath contains the starting point start. If it does, it means that the current path Curpath is a cycle. Add the current path Curpath to the path set Pathlist, delete the last node of the current path Curpath, exit the current recursion, and jump to S700; if it does not contain the starting point start, jump to S600.

[0074] S600: Traverse the Edgelist set, find all edges that start from the start node, and store them in the Edges set;

[0075] S700: If Edges is empty, it means there is no edge starting from start, or all edges starting from start have been traversed. Exit this level of recursion and jump to S700. If the current level is the first level of recursion, jump to S400. If Edges is not empty, take one edge from Edges and delete it from Edges. Jump to S800.

[0076] S800: Add start to the current path Curpath, and set the target node of edge as the starting point start. Determine if start is the end point end. If yes, add the current path Curpath to the path set Pathlist, delete the last two nodes of the current path Curpath, and jump to S700; otherwise, jump to S500.

[0077] However, in cases where the SCADE model is complex, a state transition path may have multiple transition conditions, and each transition condition can be further decomposed into several sub-conditions based on the condition being true. This can easily lead to a combinatorial explosion problem, increasing the workload and overhead of testing activities.

[0078] Suppose that the state transition path P consists of n+1 states and n transition conditions, and each transition condition is composed of several sub-conditions, i.e., each transition condition T i (1≤i≤n) can be decomposed into C i If there are multiple subconditions, then the result will be C1*C2*C3*...*C n Each migration condition path. Conventional combinatorial testing covers combinations of different values ​​for different parameters in the system, but this embodiment uses the AETG combinatorial testing algorithm, which achieves the effect of covering all pairwise combinations of sub-conditions with fewer sub-condition combinations, such as... Figure 4 As shown, the specific steps are as follows:

[0079] Step 1: Obtain the path list;

[0080] Step 2: Check if the path set Pathlist is empty. If it is empty, end the process, indicating that the migration condition paths of all paths have been overwritten, and output the migration condition path set Clist; if it is not empty, jump to step 3.

[0081] Step 3: Retrieve a state transition path from the path list and remove it from the path list; decompose each transition condition of the state transition path into multiple sub-conditions according to the true conditions, and store them in a tuple P. <T i C j >, where T i C represents multiple transition conditions on a state transition path. j This represents multiple sub-conditions corresponding to the transition condition; now, each transition condition of the state transition path is decomposed into multiple sub-conditions according to the case where the condition is true: For example, if a certain transition condition is (A∨B)∧C, then the cases where the transition condition is true are as follows: (1) A∧B∧C, (2) (3)

[0082] Step 4: Combine all sub-conditions belonging to different migration conditions into pairs and store them in a tuple M. <P x ,P y >;

[0083] Step 5: Find the pair M <P x ,P y The subcondition P that appears most frequently in > t This subcondition P t Add to the migration condition path set Clist, and delete the tuple M. <P x ,P y P appears in > t The binary tuple.

[0084] Step 6: Combine all sub-conditions in the migration condition path set Clist with all sub-conditions not in the migration condition path set Clist, and store them in a tuple. <P m ,P k >; Record the binary tuple <P m ,P k In the binary M <P x ,P y The number of times P appears in >, where P m ∈Clist, P k This indicates a sub-condition that is not in the current migration condition path Clist; the P that appears most frequently will be selected. k Add the current migration condition path Clist and delete the tuple M. <P x ,P y P appears in > k The binary tuple;

[0085] Step 7: Determine whether the number of sub-conditions in the migration condition path set Clist is less than the number of migration conditions. If it is not less than the number of migration conditions, end the process and jump to step 2; if it is less than the number of migration conditions, jump to step 6.

[0086] The AETG algorithm can obtain all the migration condition paths, avoiding the combinatorial explosion problem caused by too many migration conditions and too many sub-conditions decomposed from each true migration condition.

[0087] The specific steps for generating test case sets are explained below.

[0088] The requirements for MC / DC coverage are: all values ​​of each condition in the decision must appear at least once; all possible results of each decision must appear at least once; and each condition must independently affect the result of the decision, meaning that changing the value of this condition, while keeping all other conditions unchanged, will change the result of the decision. To ensure high MC / DC coverage, a masking algorithm is used to generate test cases that satisfy MC / DC coverage. First, a sub-condition is designated as the condition that independently affects the result of the expression. Then, through analysis of the expression, values ​​are assigned to other sub-conditions, thus masking the influence of other sub-conditions on the expression's value, thereby generating abstract test cases.

[0089] Before using the masking algorithm, the infix expression of each transition condition is first converted to Reverse Polish Notation (RPN). For example, the infix expression A and(B or C)or(D and E), where A, B, C, D, and E are all subconditions, is converted to the RPN expression ABC or and DE and or. After obtaining the RPN, a syntax tree is constructed based on the RPN.

[0090] After the syntax tree is constructed, following the masking algorithm, values ​​are assigned to each node sequentially starting from the root node, so that the leftmost node can independently affect the value of the entire expression. For a syntax tree, a transition condition corresponds to an operand or operator; in the previous example, "abcde" and "and or" are nodes. This embodiment visits the binary tree nodes sequentially from right to left and assigns values ​​to each node.

[0091] Since the operators "and" and "or" are both binary operators and both satisfy the commutative law, swapping the left and right subtrees of a node does not affect the value of the entire expression. Following the masking algorithm, the leftmost leaf node of the syntax tree independently affects the value of the entire expression. After constructing the syntax tree, only a few swaps of the left and right subtrees are needed to adjust the position of any leaf node to the leftmost leaf node. Then, reassigning the entire syntax tree yields the MC / DC pair for this subcondition.

[0092] Repeat the above steps until all abstract test cases that satisfy MC / DC coverage for all migration condition paths have been found.

[0093] The process of the masking algorithm is as follows: Figure 5 The specific implementation steps are as follows:

[0094] Step 1: Take the leftmost node condition of the syntax tree as the first condition, and set the leftmost node condition of the syntax tree as the current node. Assign the values ​​false and true to the current node respectively. The remaining child nodes take the default values ​​according to the masking algorithm to obtain two sets of abstract test cases.

[0095] Step 2: Determine if the current condition is the last condition. If yes, end the process, having obtained all abstract test cases; otherwise, shift one condition to the right as the current condition.

[0096] Step 3: The value of the current condition is obtained by inverting its default value; set the current condition as a free condition.

[0097] Step 4: The default value of the free condition is passed to the left of the precondition, and the precondition is set as a free condition;

[0098] Step 5: If the free condition is the leftmost node of the syntax tree, continue; otherwise, go to step 4.

[0099] Step 6: Fill in the remaining undetermined conditions in this set of test cases with their default values. After completion, a new set of test cases is obtained. Proceed to Step 2.

[0100] At this point, an abstract test case set has been obtained. To concretize these abstract test cases, based on the logical values ​​of each test case in the logical test case set and the SCADE model's constraints on the value space of input variables, specific numerical values ​​that conform to both the value range and the abstract test case's constraints are randomly generated for the inputs in each abstract test case. All test cases are then written into a test script file in the following format:

[0101] SSM::set <var> <val>

[0102] SSM::cycle[ <integer>]

[0103] In this example, 'var' in the first line refers to the name of the variable to be assigned, while 'val' refers to the specific value assigned to the 'var' variable. 'Cycle' in the second line refers to the number of cycles in which this test case will run, and must be an integer. A specific example is given below:

[0104] SSM::set Input1 true

[0105] SSM::cycle 1

[0106] After generating test case files with the .sss extension, you can directly use the simulator in the SCADE tool to simulate and obtain test results. At the same time, SCADE TEST provides the detection of MC / DC coverage of test cases. By importing the generated .sss test script file into the SCADE TEST tool, you can obtain the MC / DC coverage achieved by all test cases in the test script.< / integer> < / val> < / var> < / integer> < / val> < / var>

Claims

1. A method for automatically generating test cases for SCADE models, characterized in that: Includes the following steps: Step 1: Obtain the input variables of the specified SCADE model, obtain the value range information of the specified SCADE model for the input variables, and obtain the model XML document automatically generated by the specified SCADE model; Step 2: Use an XML document parser to parse the model XML document to obtain the state information and transition information of the security state machine in the specified SCADE model; Step 3: Construct a directed graph using the state information of the safe state machine as nodes and the transition information of the safe state machine as edges; Step 4: Use the depth-first search algorithm to traverse the directed graph and obtain all state transition paths; each state transition path consists of n+1 states and n transition conditions, and each transition condition is decomposed into several sub-conditions according to the condition being a logical truth value. Step 5: Apply a combined test algorithm to all state transition paths to obtain transition condition paths; each transition condition path is a combination of sub-conditions. Step 6: Convert the infix expression of each sub-condition of the migration condition path into Reverse Polish Notation (RPN). Based on the converted RPN, construct a syntax tree. Using the masking algorithm, starting from the root node of the syntax tree, after several adjustments to the position of any leaf node to the leftmost leaf node, reassign the entire syntax tree to obtain abstract test cases for the sub-conditions, thus obtaining an abstract test case set. Step 7: Based on the logical values ​​of each abstract test case in the abstract test case set and the value range information of the input variables in the specified SCADE model, randomly generate a specific value for the input of each abstract test case; Step 8: Write all abstract test cases into a test script file to obtain the test case file; The test case file is simulated using the simulator of the SCADE tool to obtain the test results; In step 6, the masking algorithm is used. Starting from the root node of the syntax tree, the position of any leaf node is adjusted to the leftmost leaf node several times, and the entire syntax tree is reassigned to obtain abstract test cases for sub-conditions. This results in an abstract test case set, which specifically includes: S610: Take the condition of the leftmost node of the syntax tree as the first condition, and set the condition of the leftmost node of the syntax tree as the current node. Assign false and true values ​​to the current node respectively. The remaining child nodes take the default values ​​according to the masking algorithm to obtain two sets of abstract test cases. S620: Determine if the current condition is the last condition. If yes, end; otherwise, shift one condition to the right as the current condition. S630: The value of the current condition is obtained by inverting its default value; the current condition is set as a free condition. S640: The default value of the free condition is passed to the precondition to the left, and the precondition is set as a free condition; S650: If the free condition is the leftmost node of the syntax tree, continue; otherwise, go to S640. S660: The remaining undetermined conditions in this set of test cases are filled with their default values. After completion, a new set of test cases is obtained, and the process moves to S620. Step 8 specifically includes: Write all abstract test cases into the test script file according to the following format to obtain the test case file; SSM::set <var> <val>< / val> < / var> SSM::cycle[ <integer> ]< / integer> Here, var refers to the name of the variable to be assigned, val refers to the specific value assigned to the var variable, and cycle refers to the number of cycles in which this abstract test case is run; After generating test case files with the .sss extension, use the simulator in the SCADE tool to perform simulations and obtain test results.

2. The method for automatically generating test cases for SCADE models according to claim 1, characterized in that: In step 5, the combined testing algorithm is applied to all state transition paths to obtain the transition condition paths, specifically including: S510: Get the pathlist, which stores all state transition paths; S520: Check if the path set Pathlist is empty. If it is empty, end the process, indicating that the transition condition paths for all state transition paths have been overwritten, and output the transition condition path set Clist. If it is not empty, jump to S530. S530: Retrieve a state transition path `path` from the path set `Pathlist`, obtain the number of transition conditions `Tnum` for that state transition path `path`, remove that state transition path from the path set `Pathlist`, and store the sub-conditions of each transition condition of that state transition path `path` into a tuple `P`. <T i C j >, where T i C represents the transition conditions on the state transition path. j This represents the sub-conditions corresponding to the migration condition; S540: Combine the sub-conditions belonging to different migration conditions in pairs and store them in a tuple M. <P x ,P y >, P x ,P y This indicates two sub-conditions belonging to different migration conditions; jump to S550. S550: Finding the pair M <P x ,P y The subcondition P that appears most frequently in > t The subcondition P t Add to the migration condition path set Clist, and delete the tuple M. <P x ,P y P appears in > t The tuple; jump to S560; S560: Combine all sub-conditions in the migration condition path set Clist with all sub-conditions not in the migration condition path set Clist and store them in a pair. <P m ,P k >, where P m ∈Clist, P k Indicates a subcondition that is not in the current migration condition path set Clist; records the tuple. <P m ,P k In the binary M <P x ,P y The number of occurrences in > will be the number of times P appears. k Add the migration condition path set Clist and remove the tuple M. <P x ,P y P appears in > k The tuple; jump to S570: S570: Determine whether the number of sub-conditions in the migration condition path set Clist is less than the number of migration conditions Tnum. If it is not less than Tnum, jump to S520; if it is less than Tnum, jump to S560.

Images