Test case generation method for embedded model-oriented

Abstract

The application provides an embedded model-oriented test case generation method, which comprises the following steps: initializing a plurality of branches in a branch tree structure of a test model to obtain a plurality of solving tasks; the solving task comprises a starting state of the test model, the branch and a priority of the branch; inserting each solving task into a priority solving task queue based on the priority of each branch; and generating a target test case corresponding to a target solving task based on a target solving task with the highest priority in the priority solving task queue. Through the priority solving task queue obtained based on each branch in the branch tree structure of the test model, the target test case corresponding to the target solving task can be generated based on the target solving task with the highest priority in the priority solving task queue, thereby improving the generation efficiency of the test case.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method for generating test cases for embedded models. Background Technology

[0002] Model-Driven Development (MDD) has become a key approach for developing complex embedded systems, particularly in safety-critical fields such as automotive and aerospace. This method uses high-level abstract models as the core carrier for defining system behavior, supporting early simulation and verification before system implementation, thereby identifying design flaws in advance. Within the MDD framework, the MathWorks Simulink platform is widely used for modeling, simulating, and verifying dynamic embedded systems. MathWorks Simulink's graphical and module-based development environment allows for intuitive modeling of complex control logic and signal processing procedures; its ability to automatically generate code from verified models is a core advantage that simplifies the development process.

[0003] Automatic generation of test cases for Simulink models is a current research hotspot, with the core objective of improving the efficiency and effectiveness of system testing. Existing methods can be divided into two main categories: solution-based generation methods and search-based generation methods. Solution-based generation methods transform the test case generation problem into a constraint satisfaction problem. They typically first convert the Simulink model into a formal representation, and then use tools such as Satisfiability Modal Theory (SMT) solvers to find inputs that satisfy specific test objectives (such as branch coverage). A common technique is to expand the model logic within a specified number of simulation steps, enabling the backend solver to generate a complete multi-step input sequence. The core advantage of this type of method is its "systematic" nature; within the solver's search range, test cases can be generated for all reachable branches.

[0004] However, solution-based methods may get stuck in "hard branch stagnation" during the solution process, and as the number of states increases, it is difficult to prioritize the solution tasks if there is no mechanism to identify high-value paths, resulting in low efficiency in test case generation. Summary of the Invention

[0005] This invention provides a test case generation method for embedded models to solve the problem of low efficiency in test case generation in the prior art.

[0006] This invention provides a test case generation method for embedded models, comprising: Multiple branches in the branch tree structure of the test model are initialized to obtain multiple solution tasks; the solution tasks include the initial state of the test model, the branches, and the priorities of the branches; Based on the priority of each branch, each solution task is inserted into the priority solution task queue; Based on the highest priority target solving task in the priority solving task queue, target test cases are generated corresponding to the target solving task.

[0007] According to the present invention, a test case generation method for embedded models is provided, wherein initializing multiple branches in the branch tree structure of the test model to obtain multiple solution tasks includes: A depth-first traversal is performed on each of the multiple branches in the branch tree structure of the test model to obtain the branch depth of each branch; Based on the branch depth, the priority of each branch is determined; Based on the priority of all branches and the initial state of the test model, each of the aforementioned solution tasks is generated.

[0008] According to a test case generation method for embedded models provided by the present invention, the step of generating target test cases corresponding to the highest priority target solving task in the priority solving task queue includes: An unreachable branch filter is used to verify whether the target solution task with the highest priority in the priority solution task queue is feasible; the unreachable branch filter stores an unreachable branch blacklist. If the target solution task is feasible, the solver is invoked to generate the target test cases corresponding to the target solution task.

[0009] According to the present invention, a test case generation method for embedded models is provided, the method further includes: If the target test case is successfully generated, increase the priority of other solution tasks with the same initial state; or, If the generation of the target test case fails, the priority of other solution tasks on the same branch and other solution tasks with the same starting state will be reduced.

[0010] According to a test case generation method for embedded models provided by the present invention, if the target test case is successfully generated, the method further includes: Execute the target test case to generate a new state and a new coverage branch for the test model; Determine the difference variables between the new state and the initial state, and increase the priority of solution tasks that depend on the difference variables; The new state is stored in the state set, and the new overlay branch is stored in the overlay record file.

[0011] According to the present invention, a test case generation method for embedded models is provided, the method further includes: Based on the new state and other uncovered branches, a new solution task is generated; Based on the priority of the other uncovered branches, the new solution task is inserted into the priority solution task queue.

[0012] According to the present invention, a test case generation method for embedded models is provided, the method further includes: Traverse the leaf branches in the branch tree structure and query the overlay record file to determine whether the leaf branch already exists in the overlay record file; there are hierarchical dependencies between multiple branches in the branch tree structure; the overlay record file stores reachable branches; If the leaf branch has the overridden record file, mark the leaf branch and its corresponding ancestor branch as reachable branches; If the leaf branch does not contain the overwrite record file, determine whether the leaf branch is a reachable branch.

[0013] According to a test case generation method for embedded models provided by the present invention, determining whether the leaf branch is a reachable branch includes: Construct global symbolic path constraints for the leaf branches; Determine whether the globally symbolized path constraint exists as a sequence of test cases that can be satisfied; If no satisfyable test case sequence exists, the leaf branch is determined to be an unreachable branch, and the leaf branch is stored in the unreachable branch blacklist. If a satisfyable sequence of test cases exists, the leaf branch is determined to be a reachable branch, and the ancestor branch corresponding to the leaf branch is determined to be a reachable branch.

[0014] According to the present invention, a test case generation method for embedded models is provided, the method further includes: Based on the target test cases, generate a repeating sequence; The repeating sequence is executed in all states of the state set.

[0015] According to the present invention, a test case generation method for embedded models is provided, the method further includes: M test cases are randomly selected from the test sequence pool and concatenated in a random order to generate a test sequence; the test sequence pool stores the generated test cases. Randomly select a target starting state from the set of states, and execute the test sequence under the target starting state.

[0016] The present invention also provides a test case generation device for embedded models, comprising: An initialization module is used to initialize multiple branches in the branch tree structure of the test model to obtain multiple solution tasks; the solution tasks include the initial state of the test model, the branches, and the priorities of the branches; The first insertion module is used to insert each of the solution tasks into the priority solution task queue based on the priority of each of the branches. The first generation module is used to generate target test cases corresponding to the highest priority target solving task in the priority solving task queue.

[0017] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the test case generation method for embedded models as described above.

[0018] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the test case generation method for embedded models as described above.

[0019] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the test case generation method for embedded models as described above.

[0020] The present invention provides a test case generation method for embedded models. This method initializes multiple branches in the branch tree structure of the test model to obtain multiple solution tasks. Each solution task includes the initial state of the test model, the branch, and the priority of the branch. Based on the priority of each branch, each solution task is inserted into a priority solution task queue. Based on the highest priority target solution task in the priority solution task queue, a target test case corresponding to the target solution task is generated. By using a priority solution task queue obtained from each branch in the branch tree structure of the test model, the method enables the generation of target test cases based on the highest priority target solution task in the priority solution task queue, thereby improving the efficiency of test case generation. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0022] Figure 1 This is a flowchart illustrating the test case generation method for embedded models provided by the present invention.

[0023] Figure 2 This is a schematic diagram of the test case generation system provided by the present invention.

[0024] Figure 3 This is a schematic diagram of the test case generation device for embedded models provided by the present invention.

[0025] Figure 4 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

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

[0027] To facilitate understanding of the various embodiments of this application, the relevant background knowledge of this application will be introduced first.

[0028] The core components of a Simulink model fall into two categories: "modules" representing mathematical operations or system components, and "connections" representing data flow between components. Modules cover a wide range of functionalities, from basic arithmetic operators to encapsulated subsystems with independent internal logic, while connections between modules define the system's data dependencies and causal relationships. The behavior of most Simulink models is determined by "model states," which are the collection of values ​​stored in internal storage modules (such as Unit Delay and Data Store Memory). These state variables continuously change, and the model's output is determined by both the current input and the current state.

[0029] The goal of model testing is to cover various metrics of the model, including condition coverage, decision coverage, and corrective decision condition coverage. Covering these metrics is a common objective in evaluating the completeness of a test model, but the coverage of different metrics depends not only on the direct input but also on whether the model is in a specific prerequisite state. Therefore, the core requirement for test case generation is to determine the input sequence that can guide the model to traverse the state space, thereby covering the relevant branches.

[0030] Solver-based methods transform the test case generation problem into a constraint satisfaction problem. They typically first convert the Simulink model into a formal representation, then use tools like the SMT solver to find inputs that satisfy specific test objectives (such as branch coverage). A common technique is to expand the model logic within a specified number of simulation steps, enabling the backend solver to generate a complete multi-step input sequence. For example, tools like SLDV use this method to achieve high coverage rates for metrics such as Modified Condition (MC) / Decision Coverage (DC); the AutoMOTGen toolchain completes test case generation through a process of "converting the Simulink model to a Software Analysis Language (SAL) intermediate representation → embedding coverage specifications in the formal model → generating test cases using a model checker." The core advantage of this type of method is its "systematic" nature; within the solver's search range, test cases can be generated for all reachable branches.

[0031] However, the solution-based approach still has significant bottlenecks in terms of scalability and efficiency: First, as the model size and test sequence length increase, the complexity of the constraints will increase exponentially, leading to a "state space explosion"; Second, the computational difficulty of the solver task allocation is high, and the solver may consume a lot of resources on unreachable branches, resulting in serious waste of solution resources, and invalid tasks need to be filtered out in advance.

[0032] In contrast, Search-Based Software Testing (SBST) replaces logical proof with guided optimization. It defines test case generation as a search problem, using heuristic algorithms such as genetic algorithms to "search" for test cases. These methods do not require proving path satisfiability; instead, they are guided by a fitness function that quantifies the "closeness" between the test input and the test objective (e.g., the closer the input signal value is to the module activation threshold, the higher the fitness function score). This mechanism makes SBST highly scalable, enabling it to explore the vast input domains of complex, nonlinear, or black-box models, scenarios where formal analysis is often difficult to implement. For example, the SimCoTest framework improves test quality through a technical path of "discrete / continuous mixed input space search → test objective decomposition based on model structure → genetic algorithm optimization of parameter combinations."

[0033] The core limitation of search-based methods is their insufficient precision when handling depth-dependent and state-dependent logic. While fitness functions can effectively guide the search towards the target input value, they cannot provide effective guidance on "how to reach the necessary prerequisite states"—because the local reward mechanism of the fitness function cannot guide the search to complete the entire sequence of target operations. Therefore, these methods struggle to generate accurate and complex input sequences and cannot satisfy intricate state-dependent path conditions.

[0034] The following is combined Figures 1-2 This invention describes a test case generation method for embedded models.

[0035] Figure 1 This is a flowchart illustrating the test case generation method for embedded models provided by the present invention, as shown below. Figure 1 As shown, the method includes the following steps 101-103.

[0036] Step 101: Initialize multiple branches in the branch tree structure of the test model to obtain multiple solution tasks; the solution tasks include the initial state of the test model, the branches, and the priorities of the branches.

[0037] It should be noted that the test case generation method for embedded models provided by this invention is applicable to scenarios where test models are tested, such as test models in the automotive, aerospace, and other fields. The test model is represented using a Simulink model and is an embedded model. The execution entity of the test case generation method for embedded models provided by this invention can be the test case generation device for embedded models provided by this invention, such as an electronic device, or a control module in the test case generation device for embedded models that executes the test case generation method for embedded models.

[0038] Specifically, the test model is represented by a branch tree structure, which includes multiple branches, each of which is either a leaf branch or an intermediate branch.

[0039] This invention proposes an adaptive solving engine. The adaptive solving engine initializes multiple branches in the branch tree structure of the test model, which can obtain multiple solving tasks. Each solving task includes the initial state of the test model, a branch, and the priority of the branch, that is, it covers the branches starting from the initial state.

[0040] Branch priority can be determined based on heuristic rules, including but not limited to: branch depth, historical solution success rate, and dependence on state. The shallower the branch depth, the higher the branch priority; the higher the historical solution success rate, the higher the branch priority; and the higher the dependence on state, the higher the branch priority.

[0041] It's important to note that the state of the test model is the set of internally stored values ​​during the solution and execution process, and it changes as the solution and execution progresses. The branches of the test model are the set of different execution paths within the test model (e.g., different execution paths generated by if-else, switch, etc. statements). Solving a branch yields a test case; after executing this test case, the test model enters a new state (i.e., its internally stored values ​​change). Furthermore, during the solution and execution process, a set of test model states is maintained. Initially, the set of states only contains the starting state of the test model. After successfully solving the target branch, executing the desired test case will cause the test model to enter a new state, which will be added to the state set.

[0042] Step 102: Based on the priority of each branch, insert each of the solution tasks into the priority solution task queue.

[0043] Specifically, the Priority Solving Task Queue is a dynamic priority solving task queue. It serves as the "task scheduling hub" of the adaptive solver engine, replacing the traditional static task list with a dynamic priority mechanism to allocate solving resources preferentially to tasks with "high success rate and high coverage gain." The Priority Solving Task Queue uses a max-heap data structure and supports online updates of task priorities. The tasks in the queue include the test model's state, branches, and branch priorities.

[0044] The adaptive solver engine can insert each solver task into the priority solver task queue according to the priority of the corresponding branch.

[0045] Step 103: Based on the highest priority target solving task in the priority solving task queue, generate the target test cases corresponding to the target solving task.

[0046] Specifically, the main loop of the adaptive solver engine continuously retrieves the highest priority target solver task from the priority solver task queue. The target solver task includes the target initial state of the test model, the target branch, and the priority of the target branch.

[0047] Based on the target initial state (e.g., S), target branch (e.g., B), and priority of the target branch in the test model included in the target solving task, target test cases corresponding to the target solving task are generated and stored in the test sequence pool (solved input pool).

[0048] The present invention provides a test case generation method for embedded models. This method initializes multiple branches in the branch tree structure of the test model to obtain multiple solution tasks. Each solution task includes the initial state of the test model, the branch, and the priority of the branch. Based on the priority of each branch, each solution task is inserted into a priority solution task queue. Based on the highest priority target solution task in the priority solution task queue, a target test case corresponding to the target solution task is generated. By using a priority solution task queue obtained from each branch in the branch tree structure of the test model, the method enables the generation of target test cases based on the highest priority target solution task in the priority solution task queue, thereby improving the efficiency of test case generation.

[0049] Optionally, the specific implementation of step 101 above includes: A depth-first traversal is performed on each branch in the branch tree structure of the test model to obtain the branch depth of each branch; the priority of each branch is determined based on the branch depth; and each solution task is generated based on the priorities of all branches and the initial state of the test model.

[0050] Specifically, the adaptive solver performs a depth-first traversal of multiple branches in the branch tree structure of the test model to obtain the branch depth of each branch. It's important to note that since deeper branches typically contain more complex cumulative path conditions, such as constraints after multi-step state transitions, branch depth serves as a core heuristic factor for initial priority. Initial priority is inversely proportional to branch depth; that is, shallower branches have higher priority. The adaptive solver prioritizes easily covered basic branches. Therefore, based on branch depth, the priority of each branch can be determined; and based on the priorities of all branches and the initial state of the test model, various solution tasks can be generated.

[0051] Optionally, the specific implementation of step 103 above includes: An unreachable branch filter is used to verify whether the target solution task with the highest priority in the priority solution task queue is feasible; the unreachable branch filter stores an unreachable branch blacklist; if the target solution task is feasible, the solver is invoked to generate the target test case corresponding to the target solution task.

[0052] Specifically, the Unreachable Branch Filter stores a blacklist of unreachable branches, which includes multiple unreachable branches. The adaptive solver uses the Unreachable Branch Filter to verify whether the target branch of the highest priority target solver in the priority solver queue is in the unreachable branch blacklist stored in the Unreachable Branch Filter. If it is, the target solver is verified as infeasible; if it is not, the target solver is verified as feasible, thus avoiding invalid solutions for infeasible target solvers.

[0053] If the objective task is feasible, a solver (such as a constraint solver (CBMC)) can be invoked to request the generation of target test cases corresponding to the objective task, using the target initial state included in the objective task as the context of the path constraints.

[0054] Optionally, the method further includes: Traverse the leaf branches in the branch tree structure and query the coverage record file to determine whether the leaf branch already exists in the coverage record file; there are hierarchical dependencies between multiple branches in the branch tree structure; the coverage record file stores reachable branches; if the leaf branch exists in the coverage record file, mark the leaf branch and its corresponding ancestor branch as reachable branches; if the leaf branch does not exist in the coverage record file, determine whether the leaf branch is a reachable branch.

[0055] Specifically, there are hierarchical dependencies between multiple branches in the branch tree structure. The reachability of a non-leaf branch depends entirely on the reachability of at least one of its child branches. Therefore, the unreachable branch filter does not need to solve all branches, but only needs to focus on the leaf branches. For example, if leaf branch B4 is determined to be reachable, its ancestor branches B2 and B1 will be automatically marked as reachable; if both leaf branches B4 and B5 are determined to be unreachable, then its parent branch B2 will be marked as unreachable in the final branch tree structure traversal, greatly reducing the number of solutions.

[0056] Before using the unreachable branch filter to verify whether the highest priority target solution task in the priority solution task queue is feasible, the unreachable branch filter can traverse the leaf branches (b) in the branch tree structure and query the coverage record file to determine whether the leaf branch already has a coverage record file.

[0057] If a leaf branch has an overriding record file, meaning the leaf branch has been covered by the guided execution engine, then the leaf branch and its corresponding ancestor branch are directly marked as reachable branches, skipping the solution process. This optimization can utilize the "easy-to-cover branch results" of the guided execution engine to concentrate filter resources on uncovered complex branches, further reducing computational overhead.

[0058] If the leaf branch does not have an overriding record file, meaning the leaf branch is not overridden by the execution engine, it can be further determined whether the leaf branch is a reachable branch.

[0059] Optionally, determining whether the leaf branch is a reachable branch includes: Construct a global symbolic path constraint for the leaf branch; determine whether there is a satisfyable test case sequence for the global symbolic path constraint; if there is no satisfyable test case sequence, determine the leaf branch as an unreachable branch and store the leaf branch in the unreachable branch blacklist; if there is a satisfyable test case sequence, determine the leaf branch as a reachable branch and determine the ancestor branch corresponding to the leaf branch as a reachable branch.

[0060] Specifically, global symbolic path constraints are constructed for the leaf branches, which means that all possible states in the test model and the state values ​​stored in the persistent state module (such as the stored value of Unit Delay) are treated as symbolic inputs (without fixed specific values). A solver (such as a constraint solver (CBMC)) is used to determine whether there is a sequence of test cases that can satisfy the global symbolic path constraints.

[0061] If no satisfyable test case sequence exists, the leaf branch can be determined as an unreachable branch and stored in the unreachable branch blacklist (i.e., stored in a shared file). If a satisfyable test case sequence exists, the leaf branch can be determined as a reachable branch, and the ancestor branches corresponding to the leaf branch are recursively identified as reachable branches, eliminating the need for repeated solutions. This allows the adaptive solver engine to check the unreachable branch blacklist before processing the solution task. If a leaf branch is on the blacklist, the solution task corresponding to that leaf branch is discarded, saving solver call costs.

[0062] The purpose of unreachable branch filters is to identify globally unreachable branches in the test model in advance, avoiding wasting computational resources on such "never-coverable" tasks by the constraint solver. In practical engineering, unreachable branches mainly stem from two scenarios: first, fixed model parameters, such as hardware configuration parameters that cannot be modified during execution, causing the preconditions of branches that depend on these parameters to never be satisfied; second, Boolean logic contradictions, such as logically impossible conditions like "input signal > 5 and input signal < 3".

[0063] Optionally, the method further includes: If the target test case is successfully generated, increase the priority of the solution task with the same starting state; or, if the target test case is not generated, decrease the priority of other solution tasks on the same branch and other solution tasks with the same starting state.

[0064] Specifically, if the target test case is successfully generated, the priority of other solving tasks with the same starting state is increased, because the target test case corresponding to the target branch has already been solved from the target starting state S, and the probability of covering other branches starting from the target starting state S is higher.

[0065] Alternatively, if the generation of the target test case fails (i.e., times out or is determined to be an incomplete target solution task (UNSAT)), a punitive weighting factor can be used to reduce the priority of other solution tasks on the same branch and other solution tasks with the same starting state. The punitive weighting factor can be configured to prevent the system from repeatedly exhaustively searching invalid paths. For example, when solving branch B1 from state S2 fails, not only...<S2,B1> The priority is reduced.<S2,B2> The priority of other solution tasks originating from S2 will also be reduced accordingly, and the bootstrap queue will prioritize scheduling other tasks that are more likely to succeed.

[0066] Optionally, if the target test case is successfully generated, the method further includes: Execute the target test case to generate a new state and a new coverage branch for the test model; determine the difference variables between the new state and the initial state, and increase the priority of the solution tasks that depend on the difference variables; store the new state in the state set, and store the new coverage branch in the coverage record file.

[0067] Specifically, upon successful generation of the target test case, the random scheduler receives the target test case from the adaptive solver engine and executes it in a direct application mode, based on the initial state corresponding to the target test case. This generates a new state S' and a new coverage branch for the test model, verifying the validity of the solution result (target test case) and confirming whether target test case i can stably cover target branch B. The differential variables between the new state and the initial state (i.e., "sensitive variables," such as changes in pattern identifiers and key register values) are identified, and the priority of solver tasks dependent on these differential variables is increased. Changes in these differential variables alter the context of the test model, potentially making previously difficult-to-cover branches solvable. The new state is stored in a state set, and the new coverage branch is stored in a coverage record file, completing the basic state and coverage expansion. This direct application mode forms the basis for subsequent complex executions, ensuring that each solution result translates into a clear coverage benefit.

[0068] Optionally, the method further includes: Based on the new state and other uncovered branches, a new solution task is generated; based on the priority of the other uncovered branches, the new solution task is inserted into the priority solution task queue.

[0069] Specifically, the adaptive solver engine pairs the new state S' with other uncovered branches in the test model to generate new solver tasks; based on the priority of the other uncovered branches, the new solver tasks can be inserted into the priority solver task queue to expand the starting states of subsequent solvers.

[0070] For example, if the test model contains branches B1 and B2 that can only be covered by the "gateway" state S1, the initial scheduler might attempt to solve for these branches from other states such as S3 and S4 and fail. The failure penalty will continuously lower the priority of these invalid tasks, ultimately causing...<S1,B1> It becomes the highest priority task in the queue; after a successful solution...<S1,B2> The priority will be immediately increased if executing the target test sequence i generates a new state S2, and branch B3 depends on sensitive variables in S2 (such as the activation of a mode switch), then<S2,B3> It will be given high priority and enter the solution process first.

[0071] Optionally, the method further includes: Based on the target test case, a repeating sequence is generated; the repeating sequence is executed in all states of the state set.

[0072] Specifically, for common "cumulative logic" (such as counters, accumulators, and event-triggered state machines) in embedded models, the test sequence replicator uses a repetitive sequence execution mode to repeatedly execute the target test case N_rep times (N_rep is a configurable parameter), generating a repetitive sequence. This repetitive sequence is executed in all states of the state set. For example, the condition for the output of the AND module in the test model to be true is "the input is ≤2 for 10 consecutive times". A single input cannot trigger this condition, but by repeating the target test case i (with a value of 1) 10 times using the repetitive sequence execution mode, the cumulative constraint can be quickly satisfied, covering this branch. This mode can efficiently trigger branches that depend on "multi-step repeated inputs", avoiding the solver's complex calculations for such long sequence constraints.

[0073] Optionally, the method further includes: M test cases are randomly selected from the test sequence pool and generated into a test sequence by concatenating them in a random order; the test sequence pool stores the generated test cases; a target starting state is randomly selected from the state set, and the test sequence is executed in the target starting state.

[0074] Specifically, the test sequence pool stores the generated test cases. The test sequence assembler uses a long-sequence assembly execution mode to randomly select M test cases from the test sequence pool (SolvedPool), where M is a positive integer and a configurable parameter. These M cases are then concatenated in a random order to generate a test sequence. A target starting state is then randomly selected from the state set (StateSet), and the test sequence is executed under that target starting state. If a new state or new coverage is found after execution, it is immediately reported to the state set (StateSet) and the coverage record file (Coverage Record), triggering the generation of a new solution task. The core value of this long-sequence assembly execution mode is triggering "complex state transitions across test cases."

[0075] For example, combining the test sequence i1 for "mode 1 activation" with the test sequence i2 for "parameter configuration" may guide the test model into the adaptive solution engine, which is difficult to solve directly in the new state of "mode 1 + specific parameters", thereby covering the exclusive branch in this state.

[0076] This application adds newly discovered states to the StateSet, providing a new starting point for the adaptive solver engine. Newly covered branches are updated in the Coverage Record, providing a "covered" basis for the unreachable branch filter. This collaborative mechanism enables the system to both overcome complex branches through the adaptive solver engine and quickly expand the state space through the guided execution engine, ultimately achieving a dual improvement in test coverage and solver efficiency.

[0077] Figure 2 This is a schematic diagram of the test case generation system provided by the present invention, such as... Figure 2 As shown, a feedback loop consisting of an adaptive solving engine and a guided execution engine enables the rapid generation of high-coverage test cases given a test model (Simulink model). The system utilizes multi-threaded concurrent scheduling and shared data structures such as the model state set, the solved input pool, and the unreachable branch blacklist to achieve real-time information synchronization, constructing a closed loop of "accurate solution - broad execution - feedback optimization." The specific implementation process is described below.

[0078] The test model is input into the adaptive solving engine. The engine performs a depth-first traversal of each branch in the test model's branch tree structure to obtain the branch depth. Based on the branch depth, the priority of each branch is determined. The priorities of all branches are paired with the initial state of the test model, and solving tasks are generated. Based on the priority of each branch, each solving task is inserted into a priority solving task queue.

[0079] An unreachable branch filter is used to verify the feasibility of the highest-priority target task in the priority solving task queue. The unreachable branch filter stores an unreachable branch blacklist, which is obtained based on static unreachability analysis. Specifically, the process involves: traversing the leaf branches in the branch tree structure and querying the coverage record file to determine if the leaf branch already exists in the coverage record file; establishing hierarchical dependencies between multiple branches in the branch tree structure; storing reachable branches in the coverage record file; marking the leaf branch and its corresponding ancestor branch as reachable branches when the coverage record file exists for the leaf branch; constructing a global symbolic path constraint for the leaf branch when the coverage record file does not exist for the leaf branch; determining if there is a satisfyable test case sequence for the global symbolic path constraint; determining if there is no satisfyable test case sequence when the leaf branch is unreachable and storing it in the unreachable branch blacklist; and determining if there is a satisfyable test case sequence when the leaf branch is reachable and its corresponding ancestor branch as reachable branches.

[0080] If the target solution task is feasible, the constraint solver is invoked to generate target test cases corresponding to the target solution task, and these test cases are stored in the solved input pool. The adaptive solving engine can also increase the priority of other solution tasks with the same starting state if the target test cases are successfully generated; or, if the target test cases fail to be generated, decrease the priority of other solution tasks on the same branch and other solution tasks with the same starting state.

[0081] The RandomizedScheduler in the Guided Execution Engine can schedule the target test case generated from the test case pool. The Model Executor in the Guided Execution Engine executes the target test case, generating a new state and a new coverage branch for the test model. It determines the difference variables between the new state and the initial state and increases the priority of solution tasks that depend on these difference variables. The new state is stored in the Model State Set, and the new coverage branch is stored in the coverage record file. The Adaptive Solver Engine can generate new solution tasks based on the new state and other uncovered branches; based on the priority of the other uncovered branches, it inserts the new solution tasks into the priority solution task queue.

[0082] The test sequence duplicator in the randomized scheduler can adopt a repeated sequence execution mode, repeatedly executing the target test case N_rep times (N_rep is a configurable parameter), generating a repeated sequence; this repeated sequence is executed in all states of the state set. If a new state or new coverage is found after execution, it will be immediately reported to the state set and coverage record file, triggering the generation of a new solution task.

[0083] The test sequence assembler in the randomized scheduler can adopt a long sequence assembly execution mode. It randomly selects M test cases from the SolvedPool (M is a positive integer, a configurable parameter) and concatenates them in a random order to generate a test sequence. Then, it randomly selects a target starting state from the StateSet and executes the test sequence under that target starting state. If a new state or new coverage is found after execution, it immediately reports back to the StateSet and CoverageRecord, triggering the generation of a new solution task.

[0084] In this application, the core design goal of the adaptive solver engine is to overcome the challenges of handling state-dependent complex branching problems that are difficult to handle with randomized testing and search-based testing. By intelligently scheduling and constraining solver resources, it generates effective test cases while reducing the cost of ineffective solutions. The engine's core logic revolves around "selecting high-priority solver tasks and filtering infeasible tasks," comprising two key modules: a dynamic priority solver task queue and an unreachable branch filter. These two modules work together to ensure that the solver focuses only on feasible tasks that can significantly improve coverage. The guided execution engine, as a cooperating component of the adaptive solver engine, aims to improve the reuse efficiency of solved test cases through broad exploration, rapidly expand the model state space, and balance the depth of "precise solving" with the speed of "state exploration." The core of this engine is a randomized scheduler, which is not limited to a single execution of solved inputs but fully explores the value of each input through a multi-mode execution strategy, while simultaneously discovering new states and new coverage branches, ultimately forming a closed loop of "execution-feedback-new solver task." This ultimately achieves a dual improvement in test coverage and solver efficiency.

[0085] The method provided by this invention improves test coverage while reducing the cost of solving the problem by constructing a closed-loop feedback mechanism of "precise constraint solving - efficient execution exploration".

[0086] The test case generation device for embedded models provided by the present invention will be described below. The test case generation device for embedded models described below and the test case generation method for embedded models described above can be referred to in correspondence.

[0087] Figure 3 This is a schematic diagram of the test case generation device for embedded models provided by the present invention, as shown below. Figure 3 As shown, the test case generation device 300 for embedded models includes: an initialization module 301, a first insertion module 302, and a first generation module 303; wherein, The initialization module 301 is used to initialize multiple branches in the branch tree structure of the test model to obtain multiple solution tasks; the solution tasks include the initial state of the test model, the branches, and the priorities of the branches; The first insertion module 302 is used to insert each of the solving tasks into the priority solving task queue based on the priority of each of the branches. The first generation module 303 is used to generate target test cases corresponding to the target solving task based on the highest priority target solving task in the priority solving task queue.

[0088] The test case generation device for embedded models provided by this invention initializes multiple branches in the branch tree structure of the test model to obtain multiple solution tasks. Each solution task includes the initial state of the test model, the branch, and the priority of the branch. Based on the priority of each branch, each solution task is inserted into a priority solution task queue. Based on the highest priority target solution task in the priority solution task queue, a target test case corresponding to the target solution task is generated. By using a priority solution task queue obtained from each branch in the branch tree structure of the test model, it is possible to generate target test cases corresponding to the target solution task based on the highest priority target solution task in the priority solution task queue, thereby improving the efficiency of test case generation.

[0089] Optionally, the initialization module 301 is specifically used for: A depth-first traversal is performed on each of the multiple branches in the branch tree structure of the test model to obtain the branch depth of each branch; Based on the branch depth, the priority of each branch is determined; Based on the priority of all branches and the initial state of the test model, each of the aforementioned solution tasks is generated.

[0090] Optionally, the first generation module 303 is specifically used for: An unreachable branch filter is used to verify whether the target solution task with the highest priority in the priority solution task queue is feasible; the unreachable branch filter stores an unreachable branch blacklist. If the target solution task is feasible, the solver is invoked to generate the target test cases corresponding to the target solution task.

[0091] Optionally, the test case generation device 300 for embedded models further includes: The priority adjustment module is used to increase the priority of other solution tasks with the same initial state if the target test case is successfully generated; or, If the generation of the target test case fails, the priority of other solution tasks on the same branch and other solution tasks with the same starting state will be reduced.

[0092] Optionally, if the target test case is successfully generated, the test case generation device 300 for the embedded model further includes: The first execution module is used to execute the target test cases and generate new states and new coverage branches of the test model; The first determining module is used to determine the difference variables between the new state and the initial state, and to increase the priority of the solution tasks that depend on the difference variables; The storage module is used to store the new state into a state set and the new overlay branch into an overlay record file.

[0093] Optionally, the test case generation device 300 for embedded models further includes: The second generation module is used to generate a new solution task based on the new state and other uncovered branches; The second insertion module is used to insert the new solution task into the priority solution task queue based on the priority of the other uncovered branches.

[0094] Optionally, the test case generation device 300 for embedded models further includes: The traversal module is used to traverse the leaf branches in the branch tree structure and query the overlay record file to determine whether the leaf branch already exists in the overlay record file; there are hierarchical dependencies between multiple branches in the branch tree structure; the overlay record file stores reachable branches; The marking module is used to mark the leaf branch and its corresponding ancestor branch as reachable branches when the overwrite record file exists in the leaf branch; The second determining module is used to determine whether the leaf branch is a reachable branch when the leaf branch does not have the overwrite record file.

[0095] Optionally, the second determining module is specifically used for: Construct global symbolic path constraints for the leaf branches; Determine whether the globally symbolized path constraint exists as a sequence of test cases that can be satisfied; If no satisfyable test case sequence exists, the leaf branch is determined to be an unreachable branch, and the leaf branch is stored in the unreachable branch blacklist. If a satisfyable sequence of test cases exists, the leaf branch is determined to be a reachable branch, and the ancestor branch corresponding to the leaf branch is determined to be a reachable branch.

[0096] Optionally, the test case generation device 300 for embedded models further includes: The third generation module is used to generate repeating sequences based on the target test cases; The second execution module is used to execute the repeating sequence in all states of the state set.

[0097] Optionally, the test case generation device 300 for embedded models further includes: The first selection module is used to randomly select M test cases from the test sequence pool and concatenate them in a random order to generate a test sequence; the test sequence pool stores the generated test cases. The second selection module is used to randomly select a target starting state from the set of states and execute the test sequence in the target starting state.

[0098] Figure 4 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 4 As shown, the electronic device 400 may include a processor 410, a communication interface 420, a memory 430, and a communication bus 440, wherein the processor 410, the communication interface 420, and the memory 430 communicate with each other through the communication bus 440. The processor 410 can call logical instructions in the memory 430 to execute a test case generation method for an embedded model. This method includes: initializing multiple branches in the branch tree structure of the test model to obtain multiple solution tasks; the solution task includes the initial state of the test model, the branch, and the priority of the branch; inserting each solution task into a priority solution task queue based on the priority of each branch; and generating a target test case corresponding to the target solution task based on the highest priority target solution task in the priority solution task queue.

[0099] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0100] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the test case generation method for embedded models provided by the above methods. The method includes: initializing multiple branches in the branch tree structure of the test model to obtain multiple solution tasks; the solution task includes the initial state of the test model, the branch, and the priority of the branch; inserting each solution task into a priority solution task queue based on the priority of each branch; and generating a target test case corresponding to the target solution task based on the highest priority target solution task in the priority solution task queue.

[0101] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements a test case generation method for embedded models provided by the methods described above. This method includes: initializing multiple branches in a branch tree structure of the test model to obtain multiple solution tasks; the solution tasks include the initial state of the test model, the branches, and the priorities of the branches; inserting each solution task into a priority solution task queue based on the priority of each branch; and generating a target test case corresponding to the target solution task based on the highest priority target solution task in the priority solution task queue.

[0102] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0103] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0104] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A test case generation method for embedded models, characterized in that, include: Multiple branches in the branch tree structure of the test model are initialized to obtain multiple solution tasks; The solution task includes the initial state of the test model, the branches, and the priority of the branches; Based on the priority of each branch, each solution task is inserted into the priority solution task queue; Based on the highest priority target solving task in the priority solving task queue, target test cases are generated corresponding to the target solving task.

2. The test case generation method for embedded models according to claim 1, characterized in that, The process of initializing multiple branches in the branch tree structure of the test model yields multiple solution tasks, including: A depth-first traversal is performed on each of the multiple branches in the branch tree structure of the test model to obtain the branch depth of each branch; Based on the branch depth, the priority of each branch is determined; Based on the priority of all branches and the initial state of the test model, each of the aforementioned solution tasks is generated.

3. The test case generation method for embedded models according to claim 1, characterized in that, The process of generating target test cases corresponding to the highest priority target solving task in the priority solving task queue includes: An unreachable branch filter is used to verify whether the target solution task with the highest priority in the priority solution task queue is feasible; the unreachable branch filter stores an unreachable branch blacklist. If the target solution task is feasible, the solver is invoked to generate the target test cases corresponding to the target solution task.

4. The test case generation method for embedded models according to claim 1 or 3, characterized in that, The method further includes: If the target test case is successfully generated, increase the priority of other solution tasks with the same initial state; or, If the generation of the target test case fails, the priority of other solution tasks on the same branch and other solution tasks with the same starting state will be reduced.

5. The test case generation method for embedded models according to claim 1 or 3, characterized in that, If the target test case is successfully generated, the method further includes: Execute the target test case to generate a new state and a new coverage branch for the test model; Determine the difference variables between the new state and the initial state, and increase the priority of solution tasks that depend on the difference variables; The new state is stored in the state set, and the new overlay branch is stored in the overlay record file.

6. The test case generation method for embedded models according to claim 5, characterized in that, The method further includes: Based on the new state and other uncovered branches, a new solution task is generated; Based on the priority of the other uncovered branches, the new solution task is inserted into the priority solution task queue.

7. The test case generation method for embedded models according to claim 3, characterized in that, The method further includes: Traverse the leaf branches in the branch tree structure and query the overlay record file to determine whether the leaf branch already exists in the overlay record file; there are hierarchical dependencies between multiple branches in the branch tree structure; the overlay record file stores reachable branches; If the leaf branch has the overridden record file, mark the leaf branch and its corresponding ancestor branch as reachable branches; If the leaf branch does not contain the overwrite record file, determine whether the leaf branch is a reachable branch.

8. The test case generation method for embedded models according to claim 7, characterized in that, Determining whether the leaf branch is a reachable branch includes: Construct global symbolic path constraints for the leaf branches; Determine whether the globally symbolized path constraint exists as a sequence of test cases that can be satisfied; If no satisfyable test case sequence exists, the leaf branch is determined to be an unreachable branch, and the leaf branch is stored in the unreachable branch blacklist. If a satisfyable sequence of test cases exists, the leaf branch is determined to be a reachable branch, and the ancestor branch corresponding to the leaf branch is determined to be a reachable branch.

9. The test case generation method for embedded models according to claim 1 or 3, characterized in that, The method further includes: Based on the target test cases, generate a repeating sequence; The repeating sequence is executed in all states of the state set.

10. The test case generation method for embedded models according to claim 1, characterized in that, The method further includes: M test cases are randomly selected from the test sequence pool and concatenated in a random order to generate a test sequence; the test sequence pool stores the generated test cases. Randomly select a target starting state from the set of states, and execute the test sequence under the target starting state.

Images