Visual modeling-script programming-brain map test case design system and design method for embedded system

Abstract

The application discloses a kind of visual modeling-embedded system-oriented script programming-brain map test case design system and design method, belong to embedded system technical field.The method includes receiving user instruction, selects and enters a kind of design mode, in the selected design mode, test case design is carried out: if visual modeling mode, through drag component, configuration parameter and establish logic connection line complete case design;If script programming mode, through calling special function library script code is written and debugged to complete case design;If brain map mode, through creating hierarchical node, combing test scene and step complete case design;Through data management module, the test case of design completion is saved, and export to standard document or switch to other mode is supported Secondary editing and data intercommunication.The application fuses three kinds of design modes, significantly improves test case design efficiency and logic clarity, greatly enhances team collaboration convenience.

Description

Technical Field

[0001] This invention relates to the field of embedded systems technology, and specifically to a visual modeling-script programming-mind mapping test case design system and method for embedded systems. Background Technology

[0002] Embedded systems are widely used in industrial control, aerospace, and smart devices. Their stability and reliability depend on comprehensive testing and verification, and test case design is a core part of the testing process. Existing embedded system test case design tools have the following technical problems:

[0003] 1. Limited design patterns: Most tools only support a single design pattern (such as pure script writing or simple visual modeling configuration), which cannot adapt to the skill levels and testing scenario requirements of different users. Non-professional programmers find it difficult to operate scripting tools, and complex logical scenarios are difficult to achieve through simple visual modeling tools.

[0004] 2. Difficulty in logical organization: Embedded system testing scenarios are complex and the steps are cumbersome. There is a lack of tools specifically for organizing test logic, which leads to chaotic test case structures, omission of key nodes, and great difficulty in subsequent maintenance and review.

[0005] 3. Low efficiency and reusability: Lack of dedicated component libraries, function libraries and template support, resulting in a large workload of repetitive code writing and parameter configuration; incompatible test case formats generated by different design tools, making data interoperability and reuse impossible;

[0006] 4. Poor collaboration: The lack of team collaboration review functions makes it difficult to share test cases and track modifications, which affects the collaborative efficiency of testing work.

[0007] To address the aforementioned issues, there is an urgent need for a visual modeling, scripting, and mind mapping-based test case design system and methodology for embedded systems, which can resolve the problems associated with traditional methods. Summary of the Invention

[0008] The purpose of this invention is to provide a visual modeling-script programming-mind map test case design system and method for embedded systems. It integrates three design patterns, significantly improves the efficiency and logical clarity of test case design, and greatly enhances the convenience of team collaboration.

[0009] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0010] A visual modeling-script programming-mind map test case design system for embedded systems includes: a mode selection module, which provides an entry point for switching between three test case design modes: visual modeling, script programming, and mind map, and loads the corresponding design interface according to the user's selection;

[0011] The visual modeling test case design module and the connection mode selection module provide a visual drag-and-drop interface, supporting the visual design of test cases through component configuration, parameter settings, and logical connections.

[0012] The programmable script test case design module and the connection mode selection module provide a script editing environment and support the design of complex logic test cases by writing code.

[0013] The mind map-based test case design module and connection mode selection module provide a mind map editing interface, supporting the organization of test case scenarios, steps, and expected results through hierarchical nodes;

[0014] The data management module connects to the visual modeling test case design module, the programmable script test case design module, and the mind map test case design module, and is used to store, convert, import and export, and exchange test case data across modes.

[0015] Furthermore, the mode selection module includes:

[0016] The mode switching unit is used to respond to user operations and seamlessly switch between three design modes;

[0017] The save unit is used to automatically save the current design progress during the switchover process and inherit the configured core data;

[0018] The preference recording unit is used to record the user's frequently used pattern preferences and loads the most recently used design patterns by default when the system starts up.

[0019] The tutorial section is used to view operation guides and typical application scenarios for different modes.

[0020] Furthermore, the visualization modeling use case design module includes:

[0021] The component library unit provides general processing, operation control, and data interaction components.

[0022] The design canvas unit is used to receive components dragged and dropped by the user from the component library unit, and supports establishing serial or parallel execution logic between components through connections.

[0023] The parameter configuration unit provides a parameter configuration interface for the selected component in the canvas.

[0024] Furthermore, the programmable script use case design module includes:

[0025] The code editing unit provides a script editing environment with syntax highlighting, code completion, and syntax checking, and supports multiple scripting languages;

[0026] A dedicated function library unit is used to provide function libraries specifically for embedded system testing;

[0027] The debugging unit supports single-step execution of scripts, setting breakpoints, and viewing variables.

[0028] Furthermore, the mind map-based use case design module includes:

[0029] The mind map editing unit provides a tree-structured mind map editing interface, supporting the addition, deletion, modification, drag-and-drop sorting, and hierarchical adjustment of nodes;

[0030] Core node unit, used to provide standardized core node types;

[0031] The review marking unit is used to add review status markings to mind map nodes. The status includes at least pending review, passed, and needs modification.

[0032] Furthermore, the data management module includes:

[0033] The format conversion unit is used to support the import and export of multiple formats of use case data generated by the three design patterns.

[0034] The data interoperability unit is used to enable mutual referencing and conversion of use case data among the three design patterns.

[0035] This invention also provides a visual modeling-scripting-mind mapping test case design method for embedded systems, applied to the aforementioned visual modeling-scripting-mind mapping test case design system for embedded systems, comprising:

[0036] Step 1: Receive user instructions through the pattern selection module, select and enter a design pattern in the form of visual modeling, script programming, or mind mapping;

[0037] Step 2: Design test cases under the selected design pattern:

[0038] If it is a visual modeling mode, use case design is completed by dragging and dropping components, configuring parameters, and establishing logical connections;

[0039] If it is a script programming mode, the test case design is completed by writing script code and debugging it by calling a dedicated function library;

[0040] If it is a mind map mode, test case design is completed by creating hierarchical nodes and organizing test scenarios and steps;

[0041] Step 3: Save the completed test cases through the data management module, and support exporting them as standard documents or switching to other modes for secondary editing and data exchange.

[0042] Furthermore, in the mind map mode, through review tags, all use cases in the mode can be shared with team members, supporting multi-person collaborative editing.

[0043] In summary, the present invention has at least one of the following beneficial technical effects:

[0044] 1. High adaptability: It provides three design patterns to cover different user needs (visual modeling is suitable for non-professional programmers, script programming is suitable for complex logic design, and mind mapping is suitable for scenario organization), solving the diverse needs of embedded system test case design.

[0045] 2. Improved Design Efficiency: Visual modeling and drag-and-drop reduce repetitive operations, script programming function libraries lower coding difficulty, and mind mapping hierarchical organization simplifies scene breakdown, improving design efficiency by more than 50% compared to traditional single-mode design; supports template reuse and data interoperability, further reducing repetitive workload;

[0046] 3. High logical clarity: The hierarchical structure of the mind map mode makes it easy to organize the test logic, the visual process of the visual modeling makes it easy to see the execution order, and the code logic of the script programming makes it easy to control precisely. The three modes complement each other and reduce the error rate of test case design.

[0047] 4. Excellent collaboration features: Supports multi-person collaborative review, test case sharing, and multi-format export, adapting to team collaboration scenarios; seamless data inheritance when switching modes avoids redundant configuration.

[0048] 5. Usability Optimization: Provides syntax checking, debugging functions, and operation tutorials to lower the barrier to entry; the interface supports personalized settings (such as favorites for frequently used components and text style adjustments) to improve user experience. Attached Figure Description

[0049] Figure 1 This is a schematic diagram of the system structure of the present invention;

[0050] Figure 2 This is a system architecture diagram of the present invention;

[0051] Figure 3 This is a schematic diagram of the method flow of the present invention. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0053] This invention provides a visual modeling-scripting-mind mapping test case design system for embedded systems, comprising:

[0054] The mode selection module provides an entry point for switching between three test case design modes: visual modeling, script programming, and mind mapping, and loads the corresponding design interface according to the user's selection.

[0055] The visual modeling test case design module and the connection mode selection module provide a visual drag-and-drop interface, supporting the visual design of test cases through component configuration, parameter settings, and logical connections.

[0056] The programmable script test case design module and the connection mode selection module provide a script editing environment and support the design of complex logic test cases by writing code.

[0057] The mind map-based test case design module and connection mode selection module provide a mind map editing interface, supporting the organization of test case scenarios, steps, and expected results through hierarchical nodes;

[0058] The data management module connects to the visual modeling test case design module, the programmable script test case design module, and the mind map test case design module, and is used to store, convert, import and export, and exchange test case data across modes.

[0059] The mode selection module includes:

[0060] The mode switching unit is used to respond to user operations and seamlessly switch between three design modes;

[0061] The save unit is used to automatically save the current design progress during the switchover process and inherit the configured core data;

[0062] The preference recording unit is used to record the user's frequently used pattern preferences and loads the most recently used design patterns by default when the system starts up.

[0063] The tutorial section is used to view operation guides and typical application scenarios for different modes.

[0064] The visualization modeling use case design module includes:

[0065] The component library unit provides general processing, operation control, and data interaction components.

[0066] The design canvas unit is used to receive components dragged and dropped by the user from the component library unit, and supports establishing serial or parallel execution logic between components through connections.

[0067] The parameter configuration unit provides a parameter configuration interface for the selected component in the canvas.

[0068] The programmable script use case design module includes:

[0069] The code editing unit provides a script editing environment with syntax highlighting, code completion, and syntax checking, and supports multiple scripting languages;

[0070] A dedicated function library unit is used to provide function libraries specifically for embedded system testing;

[0071] The debugging unit supports single-step execution of scripts, setting breakpoints, and viewing variables.

[0072] The mind map-based use case design module includes:

[0073] The mind map editing unit provides a tree-structured mind map editing interface, supporting the addition, deletion, modification, drag-and-drop sorting, and hierarchical adjustment of nodes;

[0074] Core node unit, used to provide standardized core node types;

[0075] The review marking unit is used to add review status markings to mind map nodes. The status includes at least pending review, passed, and needs modification.

[0076] The data management module includes:

[0077] The format conversion unit is used to support the import and export of multiple formats of use case data generated by the three design patterns.

[0078] The data interoperability unit is used to enable mutual referencing and conversion of use case data among the three design patterns.

[0079] The system architecture diagram of this invention is as follows: Figure 2 As shown, this specifically includes:

[0080] 1. Hardware support layer: Provides the basic operating environment for the system, serves as the carrier for software modules, and is responsible for data storage (such as use case files and configuration parameters) and instruction scheduling (such as module switching and data transmission).

[0081] 2. Data Interaction Layer: Serving as a bridge between the core functional layer and the hardware layer, it enables the storage, format conversion, cross-mode interoperability, and team sharing of use case data, resolving the issue of "incompatibility between the three modes of data";

[0082] 3. Core Functional Layer: This layer contains the core capabilities of the system and serves as the core execution unit for test case design, covering three differentiated design requirements: "visual modeling and drag-and-drop, script programming, and mind-level organization."

[0083] 4. User Interaction Layer: The direct entry point for users to interact with the system, providing a visual interface for mode selection, design operations, and result viewing, reducing the barrier to entry (such as mode tutorials and real-time verification prompts).

[0084] The functional modules of this invention are as described above. The specific functions and implementation mechanisms of the functional modules of this invention will be described in detail below:

[0085] 1. Mode Selection Module

[0086] The specific functions of the mode selection module include:

[0087]

GN_001

[0088]

GN_002

[0089]

GN_003

[0090]

GN_004

[0091] Its implementation mechanism includes:

[0092] (1) The implementation mechanism of function [GN_001] is as follows:

[0093] Interface rendering: A visual panel is built based on the Vue / React / Angular front-end framework, using SVG format icons and explanatory text in three layout modes: Grid / Flex. The icons support responsive scaling. The icon and explanatory areas are encapsulated as independent ModeCard components, including unique mode identifiers, icon paths, and other attributes. Media queries are used to adapt to multiple terminals such as PCs and tablets to ensure interface consistency.

[0094] Interaction logic: Bind a click event to each ModeCard. When triggered, first check the current design state, then call the switchMode core function to switch modes, and update the highlighted state of the interface at the same time. Add a loading state during the click process to avoid repeated operations.

[0095] Data-driven: Maintain a pattern metadata configuration table in JSON or database format. The front end dynamically renders the ModeCard component by pulling the configuration table through an interface, which facilitates subsequent pattern expansion.

[0096] (2) The implementation mechanism of function [GN_002] is as follows:

[0097] Automatic saving mechanism: The saveCurrentProgress() function is triggered before switching modes. The front end serializes the current design data into JSON, calls the backend interface with 300ms debouncing, and stores it in MySQL+Redis cache. The primary key is associated with the design task ID and mode ID. If saving fails, a prompt will pop up, supporting "force switch" or "retry save" to avoid data loss. After switching is completed, the temporary cache of the current mode is cleared.

[0098] Core data inheritance: Define a CoreData data structure containing test targets, key parameters, device models, etc. When switching modes, first fetch the core data from the database or cache, and then inject the initialization function of the new mode; non-core data (such as mode-specific operation records) are not inherited and default values ​​are used; if field requirements are inconsistent, field mapping or default parameters are automatically performed.

[0099] (3) The implementation mechanism of function [GN_003] is as follows:

[0100] Preference data storage: The front end stores the most recently used pattern ID in localStorage (temporary storage) or sessionStorage (permanent storage); when the user is logged in, the pattern ID is bound to the user ID and stored in the user_preference user preference table, which includes fields such as user ID, pattern ID, and update time; in terms of priority, the backend table data is read first when the user is logged in, and the front end localStorage is read when the user is not logged in.

[0101] Startup loading logic: When the application starts, the initApp() initialization function is executed. First, the user's login status is verified, and then the most recently used mode ID is retrieved according to the status (if no ID is found, the default mode ID is used). The loadMode function is called to load the corresponding mode's interface, core data, and historical progress. If loading fails (e.g., the mode is offline), it automatically downgrades to the default mode and prompts the user. After each successful mode switch, the mode preference records of the front end and back end are updated synchronously. The update is confirmed again when the application exits normally.

[0102] Multi-device synchronization: When logging in from multiple devices, the pattern ID of the backend user preference table is pushed in real time via WebSocket to ensure that the default pattern is loaded consistently when different terminals start up.

[0103] (4) The implementation mechanism of function [GN_004] is as follows:

[0104] Tutorial Resource Management: Store the MD / HTML format operation guides and application scenario cases in text, image or video format for each mode to the OSS static resource server or the mode_guide tutorial table (including fields such as mode ID, guide text, and case list); add version numbers to the tutorial content, bind them to the mode version, and update the tutorial synchronously and record logs when the mode is iterated.

[0105] Interactive Tutorial Entry Point: Add a floating "Tutorial" button / icon to the ModeCard component and bind it to the openGuide (modeId) click event; after clicking, a tutorial pop-up window will appear via the Modal component or you will be redirected to a separate tutorial page. It supports rich text, image display, video playback, and functions such as "close" and "print". The front end preloads tutorial summaries of commonly used modes, and the full content is lazy-loaded after clicking. The content is cached on the front end after the user views it for the first time and supports offline viewing.

[0106] Personalized tutorials: Based on the user's operation history of using this mode, the tutorial can highlight functions that the user has not used, or recommend typical application scenarios that match the user's historical test goals.

[0107] 2. Visual Modeling and Use Case Design Module

[0108] The specific functions of the visual modeling and use case design module include:

[0109] The

GN_005

[0110]

GN_006

[0111]

GN_007

[0112]

GN_007-1

[0113]

GN_007-2

[0114]

GN_007-3

[0115]

GN_007-4

[0116]

GN_008

[0117]

GN_009

[0118] Its implementation mechanism includes:

[0119] (1) The implementation mechanism of function [GN_005] is as follows:

[0120] Three-column layout: Based on the Vue3 / React18 framework, the Flex layout is divided into a left component library (fixed width 280px, scrollable when there are too many components), a central design canvas (filling the remaining space), and a right parameter configuration panel (fixed width 320px, collapsible / expandable by default); the layout container is encapsulated as the CaseDesignLayout root component, and the size of each column is uniformly managed through CSS variables, which facilitates theme adjustment and adaptation.

[0121] Component library rendering: Components are categorized into general processing, operation control, and data interaction categories. Category data is stored in a JSON configuration file, which includes category ID, name, and a list of components (component ID, name, icon, etc.). Each component is encapsulated as a CompItem sub-component, bound to a drag-and-drop source identifier, and supports hover highlighting and selected state styles.

[0122] Responsive adaptation: Adapts to different screen sizes through media queries. Large screens (≥1920px) have all three columns fully expanded, medium screens (1200-1919px) have the right column collapsed by default, and small screens (<1200px) have the left column collapsible and the right column displayed as a pop-up. When the layout size changes, the canvas is redrawn to ensure that the positions of components and connections are adapted.

[0123] Panel interaction logic: The parameter panel on the right is hidden by default and only expands automatically when a component is selected in the canvas, and collapses when not selected; a drag-and-drop separator is added between the three columns, which supports manual adjustment of the width of the left / right column. The adjusted size is persisted to localStorage for reuse the next time it is opened.

[0124] (2) The implementation mechanism of function [GN_006] is as follows:

[0125] The drag-and-drop core implementation uses a visual graph editing engine such as AntVX6 / GoJS as the canvas base layer, the left-side CompItem as the drag source, and binds the dragstart event to pass component metadata (component ID, type, default configuration); the central canvas is the drag target, listens for the drop event, and creates a component node at the mouse landing point; during dragging, a semi-transparent component icon is displayed as a preview shadow, and dragging components out of the canvas area is prohibited. If the component exceeds the canvas area, a prompt "Please drag it into the canvas" will be displayed.

[0126] Wiring logic implementation: Based on the EdgeTool wiring tool of X6, anchor points are configured for each component node, defining the input / output terminals that can be connected (e.g., the start node is an output terminal only); when connecting, it automatically recognizes serial (single output terminal to single input terminal) and parallel (single output terminal to multiple input terminals) logic. Serial connections are solid lines, and parallel connections are dashed lines with branch labels; closed-loop connections (e.g., A→B→A) and non-logical connections (e.g., the end node to other nodes) are prohibited. When a violation occurs, the connection turns red and an error message is displayed.

[0127] Topology data storage: The topology structure of components and connections in the canvas is encapsulated as a JSON-formatted CaseTopology object, which includes the case ID, a list of component nodes (node ​​ID, component type, canvas coordinates, parameter configuration), and a list of connections (connection ID, source node ID, target node ID, logical type). After each drag-and-drop or connection operation, the topology data is automatically serialized, temporarily stored in the front-end cache, and periodically synchronized to the MySQL+Redis back-end.

[0128] (3) The implementation mechanism of function [GN_007-1] is as follows:

[0129] Data structure: Define the BaseConfig interface, which includes fields such as test case name, description, priority (high / low), execution environment (test / development), creator, and creation time.

[0130] Configuration rendering: The BaseConfigPanel component is encapsulated, containing elements such as input boxes, dropdown boxes, and text fields. Two-way binding is achieved through v-model (Vue) or useState (React). The basic configuration is a global configuration at the test case level, which is always present at the top of the right panel and is not hidden when switching components. Non-empty validation is added to required fields such as test case names, and the validation is triggered when the focus is lost.

[0131] Data persistence: Basic configuration and topology data are bound and synchronously stored in the backend case_info table, with caseId as the primary key.

[0132] (4) The implementation mechanism of function [GN_007-2] is as follows:

[0133] Data Structure: Define the DataInteractConfig interface, which includes fields such as source system (e.g., ft-2000 board-1), target system, bus type (RapidIO, 1553B, etc.), data transmission information (data content, length, encoding format), and bus configuration parameters.

[0134] Configuration rendering: The DataInteractPanel component is encapsulated to dynamically render the corresponding parameter form based on the selected bus type (e.g., RapidIO displays "rate" and "channel number"); the source / target system supports drop-down selection (options are pulled from the backend system_list table) and manual input; the sent data content supports format preview (e.g., hex encoding is converted to ASCII in real time).

[0135] Parameter adaptation: Parameter templates for different buses are stored in the bus_param_template table. When switching bus types, the corresponding template is automatically loaded and the default parameters are filled in.

[0136] (5) The implementation mechanism of function [GN_007-3] is as follows:

[0137] Data structure: Define the TimeControlConfig interface, which includes fields such as delay type (fixed / dynamic), fixed delay time (unit: ms), and dynamic delay (minimum, maximum, and random).

[0138] Configuration rendering: The TimeControlPanel component is encapsulated to show / hide the corresponding configuration items when switching the delay type. Fixed delay only shows numeric input boxes ≥0, while dynamic delay shows minimum and maximum value input boxes (limited to minimum value ≤ maximum value) and a random switch; numeric validation is added to the input boxes, and real-time prompts are given when the number is not a number or is negative.

[0139] Logical adaptation: Delay parameters are ultimately converted into a format recognizable by the execution engine, such as converting dynamic random delays to Math.random(). (max-min)+min.

[0140] (6) The implementation mechanism of function [GN_007-4] is as follows:

[0141] Data structure: Define the ParallelConfig interface, which includes fields such as the number of parallel branches, branch list (branch ID, branch topology, timeout), and execution strategy (all complete / any one complete).

[0142] Configuration rendering: The ParallelPanel component is encapsulated, providing "Add Branch" and "Delete Branch" buttons. When the number of branches changes, the parallel branch container in the canvas is updated synchronously. Each branch independently displays a "Branch Configuration" entry, which can be clicked to edit the components and connections within the branch. The execution strategy is selected via a dropdown and synchronized to the executeStrategy field of the topology data.

[0143] Logical implementation: Parallel branches in the canvas are managed through "branch container nodes". Each branch is an independent sub-topology, and the sub-topology logic is parsed in parallel by the engine during execution.

[0144] (7) The implementation mechanism of function [GN_008] is as follows:

[0145] Component operation logic:

[0146] Copy: Select the component and click "Copy" to perform a deep copy of the node configuration using cloneNode(nodeId) and generate a new unique ID. By default, the copy is pasted 80px to the right of the original node. Multiple components can be selected and copied in batches, maintaining their relative positions after cloning.

[0147] Delete: Select a component or connection and click "Delete" or press the Delete key to execute the delete function and delete the associated parameter configuration; when deleting a parallel branch, a prompt will appear asking "Do you want to delete the branch and all its internal components?"

[0148] Move Up / Down (Serial Nodes Only): The moveNode function is executed to adjust the order of nodes in the serial link and synchronously update the source / target nodes of the connection; the start node cannot be moved up and the end node cannot be moved down.

[0149] Canvas transformation implementation:

[0150] Zooming: Based on X6's zoom API, bound to mouse wheel events, the zoom ratio is limited to 0.5-2 times; provides "+ / - / reset" zoom buttons, zooms from the center of the canvas, and the zoom ratio is persisted to localStorage.

[0151] Translation: Listen for the mousedown+mousemove events on the canvas. When the left mouse button is pressed and dragged, calculate the offset and perform translation. Prevent the canvas content from being dragged out of the visible area.

[0152] Operation state management: Encapsulate the useCaseOperation hook (React) or operationStore state library (VuePinia) to manage the selected component ID and operation history (keeping up to 50 Undo / Redo snapshots); Read-only users can hide all operation buttons and only view the canvas.

[0153] Interaction experience optimization: Add animations when operating components (such as fading out when deleting); hide connection animations when zooming / panning the canvas to reduce performance consumption; display progress indicators (such as "Copying 3 components...") when performing batch operations.

[0154] (8) The implementation mechanism of function [GN_007-9] is as follows:

[0155] Validation trigger timing: Validation is triggered in real time when parameters are input. A "full validation" button is provided for manual triggering. Full validation is forced before saving / submitting test cases. Submission is prohibited if the validation fails.

[0156] Validation rule system: The validation rules of each component are encapsulated as configuration functions and stored in the validateRules object, covering scenarios such as bus parameter validity, data length matching, and numerical range; it supports dynamic distribution of validation rules from the backend, which are then retrieved by the frontend and merged into validateRules.

[0157] Error notification mechanism: Components that fail validation will have their borders turn red and display an error icon on the canvas, and an error message will be displayed when hovering; parameter input boxes will have their borders turn red and red error text will be displayed below them; a global notification bar will be displayed at the top of the canvas stating "X errors were found in total", and clicking it will jump to the first erroneous component.

[0158] Validation result processing: Validation results are stored in a caseValidateResult object, which contains the total number of errors and error details; the corresponding prompts are automatically cleared after error repair, and the global prompt bar disappears after a full set of errors is repaired; the backend records each validation result to facilitate tracing test case design issues.

[0159] 3. Programmable Script Test Case Design Module

[0160] The specific functions of the programmable script use case design module include:

[0161]

GN_010

[0162]

GN_011

[0163]

GN_012

[0164]

GN_013

[0165]

GN_014

[0166] Its implementation mechanism includes:

[0167] (1) The implementation mechanism of function [GN_0010] is as follows:

[0168] Editor core selection: MonacoEditor (VSCode's underlying kernel) is used as the core of the code editing, and it is wrapped and adapted to Vue3 / React18 frameworks through monaco-editor-vue or @monaco-editor / react; the initial configuration supports switching between multiple languages ​​such as Python, Lua, and Java, custom light / dark themes, adaptive container size, the ability to turn off the small map to simplify the interface, and supports user-defined font size.

[0169] Syntax highlighting implementation: Load Monaco's built-in multi-language syntax package, extend custom highlighting rules for dedicated functions (such as rio_send()) and bus constants (such as CAN_BAUD_500K) for embedded testing scenarios; users can customize color schemes and store them in localStorage for reuse on the next startup; the onDidChangeModelContent event is triggered when code is entered, and the syntax highlighting status is updated synchronously.

[0170] Code completion implementation: Enable Monaco's built-in word and syntax structure completion features (such as Python's if / for); register a custom completion provider that is triggered when a function prefix or "." is entered; the completion data source pulls metadata (function name, parameters, description) from the built-in function library on the backend and builds a completion item that includes function tags, inserted text, and documentation.

[0171] Syntax check implementation: Syntax checks are performed when the editor content changes (300ms debouncing) or when the user clicks the "Validate" button; Python / Lua loads a lightweight version of the right / luacheck engine via WebAssembly to complete the validation locally, and Java calls the backend lightweight javac interface; red wavy lines are displayed in error lines via monaco.editor.setModelMarkers, and the error reason (such as "undefined variable") is displayed on hover.

[0172] (2) The implementation mechanism of function [GN_0011] is as follows:

[0173] Function library encapsulation and storage: The backend encapsulates core function libraries according to functional categories (bus interaction, delay control, etc.), such as the RapidIO bus data sending function rio_send() and the fixed delay function delay_ms(); the backend maintains the script_function_meta table to store function metadata, including function name, language type, parameter list, return value, and documentation; the frontend pulls function metadata to localStorage when it loads for the first time to reduce interface requests.

[0174] Function calls and validation: The function library is automatically injected into the editor context as a global module, so users can call it without manually importing it; the front end validates the number and type of function parameters in real time. For example, if a parameter is missing when calling rio_send(), it will immediately prompt "missing target_sys parameter"; when hovering over a function name, it displays the documentation and sample code pulled from script_function_meta to assist users.

[0175] (3) The implementation mechanism of function [GN_0012] is as follows:

[0176] Template library management: Templates are divided into system templates and custom snippets. System templates are stored in the backend script_template table (containing fields such as template ID, name, language, content, and category), including official templates for login verification, data transmission, etc. Custom snippets are stored in the user_script_snippet table, associated with user ID, and can be private or shared (requires administrator approval). The frontend renders the template list by language and category, and supports keyword search and category filtering.

[0177] Template import and reuse: Clicking the template triggers the importTemplate(templateId) function, which pulls the template code and replaces the editor content or inserts it at the cursor position; the template has reserved placeholders (such as {{SOURCE_SYS}}), and after importing, a parameter configuration pop-up window will pop up. Fill in the parameters and replace them in batches; sample templates are provided, such as a CAN bus data transmission template containing the can_send function.

[0178] Custom snippet saving: After the user selects a code snippet, they fill in the name, category, and description. After the front end verifies that the snippet is not empty and has no syntax errors, the back end stores it and generates a unique snipId. A "My Snippets" panel is provided, which supports editing, deleting, exporting (JSON / text), and sharing custom snippets.

[0179] (4) The implementation mechanism of function [GN_0013] is as follows:

[0180] Debugging the core engine: Python / Lua loads the lightweight pyscript / lua.js engine via WebAssembly and runs it in WebWorker to avoid blocking the main thread; Java calls the backend JPDA debugging interface, and the frontend receives the debugging status via WebSocket; the ScriptDebugger class is encapsulated to manage the debugging session ID, execution status (running / paused / stopped), and current line number.

[0181] Breakpoint Management: Breakpoint data includes fields such as unique ID, line number, whether it is enabled, and condition (optional); clicking on the line number area in the editor triggers the toggleBreakpoint function, and the breakpoint line displays a red dot (gray when disabled); breakpoint information is bound to the test case ID and stored in the script_breakpoint table, and is automatically restored the next time the test case is opened.

[0182] Single-step execution and variable monitoring: Encapsulate "Start / Pause / Single-step execution / Skip / Exit" debugging buttons, bind to the debugging engine API, and single-step execution triggers stepOver (execute the current line) or stepInto (enter the function); the VariablePanel component on the right pulls the current local / global scope variables when debugging is paused, supports manual modification of variable values ​​and synchronization to the debugging context.

[0183] Error location and prompts: The debugging engine captures syntax errors and runtime errors, and parses the error line number and cause; the editor jumps to the error line and marks it with a red background, and the right panel displays the error type, cause, and solution; the backend records error information (use case ID, line number, error message) to facilitate problem tracing.

[0184] (5) The implementation mechanism of function [GN_0014] is as follows:

[0185] Visualization Modeling → Script Code: Read the visualized topology data (nodes, connections, parameters) and parse it into a CaseTopology object; load the target language (Python / Lua / Java) code template and map code snippets according to component type (e.g., data interaction components are mapped to the rio_send() function); replace the template placeholders with the configuration parameters of the visualized components, and call the prettier / black tool to format the code to ensure readability.

[0186] Script code → Visual modeling: The script is converted into an abstract syntax tree through an AST parser (Pythonast / Lualupa / Javajavaparser); the core logic (function calls, delays, parallelism) is extracted and mapped to visual components (such as threading.Thread being mapped to a parallel processing component); unsupported syntax (such as complex loops) generates "custom script nodes" while preserving the original code snippets; nodes are automatically laid out from top to bottom according to the execution order to generate node and connection data for the visual topology.

[0187] Logical consistency check: After conversion, check whether the topology execution order is consistent with the script function call order; display inconsistencies (such as parameter mismatch) in the prompt panel, and support one-click correction; bind the converted content to the same version number, and prompt whether to update the other party synchronously when modifying one party.

[0188] 4. Mind Map-Based Use Case Design Module

[0189] The specific functions of the mind map-based use case design module include:

[0190]

GN_015

[0191]

GN_016

[0192]

GN_017

[0193]

GN_017-1

[0194]

GN_017-2

[0195]

GN_017-3

[0196]

GN_017-4

[0197]

GN_018

[0198]

GN_019

[0199] Its implementation mechanism includes:

[0200] (1) The implementation mechanism of function [GN_0015] is as follows:

[0201] Mind mapping engine selection: The lightweight and scalable MindElixir mind mapping rendering engine is selected and encapsulated as the MindMapEditor component through mind-elixir-vue (Vue3) or custom Hooks (React); the initial configuration supports tree-level expansion from left to right, node dragging, right-click menu, node shortcut menu, and keyboard operation; the canvas container adopts a responsive layout with a width of 100% and an adaptive height, and the side function bar is automatically collapsed on small screens.

[0202] Core node metadata: Defines the MindMapNode interface, including fields such as unique node ID (generated by UUID), parent node ID, node type (test point, scenario, etc.), text content, text style, sorting number, and whether to expand; the root node is fixed as "Test Case Mind Map" by default, which cannot be deleted but can only be renamed; the core node type is managed through the mind_map_node_type configuration table and supports future expansion.

[0203] Interface Layout and Rendering: The overall interface is divided into a left-side function bar (template / export / review), a central mind map canvas, and a right-side node attribute panel, implemented based on Flex layout; it is rendered differently according to node type (e.g., test point nodes are marked in orange), and the node style is customized through mindMap.registerNodeStyle; on the first load, a root node + commonly used core node empty template (test point, scenario, step, expected result) is generated by default to guide users to quickly create hierarchy.

[0204] (2) The implementation mechanism of function [GN_0016] is as follows:

[0205] Basic node operations (add / delete / copy):

[0206] Add a node: Right-click a node or click the shortcut button to trigger the addNode function, which creates a child node based on the parent node ID. The node type name is filled in by default (such as "New Test Point"), and a unique ID is automatically generated. Batch addition is supported. Selecting multiple parent nodes will add child nodes of the same type with one click.

[0207] Delete a node: Selecting a node triggers the deleteNode function, checks if there are any child nodes (if so, it will prompt you), and updates the sorting order of sibling nodes synchronously after deletion.

[0208] Copy Node: Execute the copyNode function to deeply copy the node (including content, styles, and child nodes), paste it under the target parent node, and generate a new ID, which is named by default "[Copy]Original Node Name".

[0209] Drag and drop sorting and hierarchy adjustment:

[0210] Drag and drop sorting: Based on MindElixir's native drag and drop capabilities, listen to the nodeDragEnd event and update the parent node ID and sorting sequence number of the node; core nodes are prohibited from being dragged to non-logical parent nodes (e.g., the expected result node cannot be used as the parent node of the test point), and a "hierarchical logic is illegal" message will be displayed when a violation occurs.

[0211] Hierarchical adjustment: Move up / down by swapping the sorting values ​​of the current node and its neighboring nodes using the adjustNodeOrder function; Promote / demote by modifying the parent node ID using the adjustNodeLevel function (promote to the parent node's sibling, demote to the child node's child node).

[0212] Text editing and style settings:

[0213] Text editing: Double-clicking a node triggers the editNodeContent function, which pops up an editable input box (supports multi-line text). When the focus is lost or Enter is pressed, the new content is saved and the mind map rendering is updated synchronously.

[0214] Style settings: The NodeStylePanel component on the right binds to node style fields, supporting real-time modification of font (SimSun / Microsoft YaHei, etc.), color (color palette selection), and bolding; style modifications are persisted to the backend and automatically restored on the next load.

[0215] Expand / Collapse Control: Clicking the expand / collapse icon on the left side of a node triggers the toggleNodeExpand function to update the node's expand status; a global "Expand All / Collapse All" button is provided to update the expand status of all nodes in batches.

[0216] (3) The implementation mechanism of function [GN_0017-1] is as follows:

[0217] Data structure: Inherit from the MindMapNode interface and add a verifyTarget field to mark core verification nodes (such as "login button function verification" and "data transmission integrity verification").

[0218] Rendering and Validation: The node icon is customized as a "Validation Marker" to distinguish it from other node types; the text content is validated for non-emptiness, and if it is empty when saved, the message "Test point name cannot be empty" will be displayed.

[0219] (4) The implementation mechanism of function [GN_0017-2] is as follows:

[0220] Data structure: Inherit from the MindMapNode interface and add a sceneType field to label the core test scenario type (such as "normal login scenario", "abnormal data input scenario", "boundary scenario").

[0221] Rendering and Association: The node background color is set to light blue, and it supports quick association with "step nodes" via the right-click menu; the scene node has a default prompt "It is recommended to add step / expected result nodes" to guide users to sort out the hierarchy.

[0222] (5) The implementation mechanism of function [GN_0017-3] is as follows:

[0223] Data structure: Inherit the MindMapNode interface and add the following fields: actionFactor (associated with action factors, such as "click", "input", "send"), dataFactor (associated with data factors, such as "account", "password", "test data"), and stepOrder (step number, automatically generated).

[0224] Related configuration: The right-hand attribute panel provides a drop-down selection of "Action Factor / Data Factor" (options are pulled from the test_factor table), which supports multiple selections; when sorting step nodes, the stepOrder number is automatically updated, and the order is re-sorted after deleting a step.

[0225] (6) The implementation mechanism of function [GN_0017-4] is as follows:

[0226] Data structure: Inherit from the MindMapNode interface and add a resultType field to mark the expected system response type (such as "interface response", "data return", "hardware status").

[0227] Rendering and Association: The node icon is set to "Result Marker", and is associated with the parent node (step / scene) by default, displaying "the expected result of the corresponding [parent node name]"; multiple sets of expected results can be added and displayed in sorted order.

[0228] (7) The implementation mechanism of function [GN_0018] is as follows:

[0229] Template storage and management: System templates are stored in the backend mind_map_template table, which contains fields such as template ID, name, description, mind map node JSON data, and category (e.g., "interface test / functional test"). The frontend searches for templates by category and keywords, and after clicking, it pulls the node data and renders it to the mind map canvas.

[0230] Template import logic: Supports uploading .mmap (mind map format) or .json local files, which are parsed into MindMapNode structure. The format validity is verified (such as node type and hierarchical logic). If the format is invalid, the message "Template file parsing failed" will be displayed. When importing templates from the system, the template node data is pulled to replace the current mind map data, and the root node name is retained and editable.

[0231] Multi-format export logic: When exporting to .mmap format, the mind map node data is serialized to generate a file for download; when exporting to .docx format, the front end passes the node data to the back end, and the back end parses the nodes hierarchically based on Apache POI to generate a structured Word document (title hierarchy, table display steps / expected results); it also supports exporting to JSON (directly serializing node data) or images (calling html2canvas to convert the canvas to PNG / JPG, supporting high-definition export).

[0232] (8) The implementation mechanism of function [GN_0019] is as follows:

[0233] Review status definition and storage: Review status is divided into four enumeration types: pending, approved, modified, and rejected; the node data structure is extended to add fields for review status, reviewer ID, review time, and review remarks; when not logged in, review data is temporarily stored in localStorage, and when logged in, it is synchronized to the mind_map_review table, associated with node ID, user ID, and test case ID.

[0234] Interactive logic for marking nodes: Right-click a node or select "Review Status" through the right-hand properties panel to bring up a configuration pop-up window (select status, fill in remarks, select reviewer); execute the updateNodeReviewStatus function to synchronously update the node style (yellow for pending review, green for passed, red for needing modification); support selecting multiple nodes and setting the same review status with one click.

[0235] Collaborative Display and Synchronization: During team collaboration, review status is synchronized in real time using WebSocket. After a reviewer marks a node, the canvas of other collaborators is updated in real time. A "Review Statistics Panel" is provided to display the number of nodes in each status and a list of nodes that have not passed. Clicking on a node will take you to the corresponding node. The backend reviewLog table records each review operation (operator, node ID, status change, time) for easy traceability.

[0236] 5. Implementation mechanism of data management module

[0237] The specific functions of the data management module include:

[0238]

GN_020

[0239]

GN_021

[0240]

GN_022

[0241] Its implementation mechanism includes:

[0242] (1) The implementation mechanism of function [GN_0020] is as follows:

[0243] Format mapping system: The backend maintains the case_format_mapping configuration table, defining the binding relationship between each test case mode and the supported formats. Visual modeling test cases support JSON / XML import and export, script test cases support .py / .lua, and mind map test cases support .mmap / .docx. All three modes support exporting to XLSX / PDF standard documents. The frontend verifies the file extension when uploading files, and the backend verifies the file magic number (e.g., .json checks if the first character is {) to prevent file extension tampering.

[0244] Import parsing engine: JSON / XML format is converted into standardized use case data through front-end preprocessing and back-end parsing tools; .py / .lua files are extracted for core logic and parameters through an AST parser; .mmap files are parsed into JSON mind map nodes, and .docx files are parsed into mind map nodes through Apache POI parsing of text hierarchy mapping; detailed error logs are returned when parsing fails, and "ignore error fields when importing" or "import templates with default values" are supported.

[0245] Export generation logic: When exporting in a pattern-specific format, the visualization test case serializes the topology and parameter data, the script test case generates an executable file, and the mind map test case serializes node data according to the corresponding format; when exporting in a unified standard document, all pattern test cases are first converted into a StandardCase unified structure containing test case names, steps, parameters, etc., and then XLSX (fixed template, supports batch export) is generated based on Apache POI, and PDF (in national standard format) is generated based on iText / ReportLab.

[0246] Import / Export Interaction: The front-end encapsulates import / export components, supporting single-file / batch import (up to 50 files). When exporting, users can select "Current Use Case," "Selected Use Case," or "All Use Cases." Large files (≥10MB) are uploaded / downloaded in chunks with a progress bar to prevent page lag. A prompt appears after the operation is complete, and exported files are automatically downloaded. An error list is displayed when import fails, and one-click download of error logs is supported.

[0247] (2) The implementation mechanism of function [GN_0021] is as follows:

[0248] Storage architecture design: The database adopts a layered design of MySQL. The project table stores project information, the use case main table is associated with the project ID and mode type, the mode detail table stores topology, script, and mind map node data, the tag table and association table implement classification, the version table stores modification difference snapshots, and the modification log table records the operation trajectory; Redis caches hot use cases (accessed ≥10 times in the last 7 days) and search results in the last hour to reduce database pressure.

[0249] Project categorization and search: Project IDs are bound when test cases are created, and the front end displays them in a tree structure, supporting project switching, creation, and deletion (validation is performed on the test case before deletion); basic search is achieved by concatenating SQL conditions (by name, time, and pattern), and advanced full-text search is integrated with Elasticsearch to build indexes, supporting fuzzy search and phrase search; debouncing is triggered when keywords are entered, and suggested associations (historical search terms, popular test case names) are displayed.

[0250] Tag Classification Management: Tags are divided into system-preset tags (such as "functional test") and user-defined tags (private / public, public tags require approval); a single test case can be bound to 1-10 tags, and the front end provides a tag filtering panel that supports filtering by combination of multiple tags.

[0251] Version management mechanism: Each edit and save of a test case automatically generates a new version (major version, minor version), storing only the differences to reduce resource usage; supports version rollback, comparison, and deletion (only for unreleased versions); only the creator / administrator can perform rollback / deletion operations, while ordinary users can only view the version list.

[0252] Modification log recording: Automatically records changes to the case_edit_log table when adding, editing, or deleting test cases, clearly showing the field values ​​before and after the operation; supports querying by test case ID, operator, and time; logs are permanently saved and cannot be deleted; the test case details page has an embedded log panel that displays changes in reverse chronological order for easy tracking of modification history.

[0253] (3) The implementation mechanism of function [GN_0022] is as follows:

[0254] Cross-modal data standardization model: Defines the core interoperableCaseData model, abstracting common data such as test case name, test point, steps (including action / data factors, parameters), and expected results; extracts node data mapping from mind map test cases, visualizes test case parsing topology node transformation, and parses function calls and parameter mappings for script test cases through AST parsing.

[0255] Data mapping rule system: The backend maintains the case_data_mapping configuration table to define cross-mode field mapping rules (such as mapping mind map step descriptions to visual node configurations); when the target mode does not have a corresponding field, the default value is automatically filled or a "custom node / code snippet" is generated and prompted to the user.

[0256] Cross-module reference interaction logic: Each mode editing interface provides an "Import External Data" button, which pops up a use case selection panel (filtered by project / tag / mode); after selecting the source use case, the backend converts it into a standardized model, and then converts it into target mode data according to the mapping rules, which is then loaded and injected by the frontend; after referencing, the association relationship is recorded, and when the source use case is modified, the target use case is prompted to synchronize.

[0257] Data synchronization and consistency verification: Supports manual synchronization (user-triggered update of referenced data) and real-time synchronization (WebSocket push notification after source test case modification); verifies data integrity when referencing, verifies compatibility during synchronization, and prompts user confirmation when exceptions occur; only test cases with permission can be referenced, and are hidden when no permission is granted.

[0258] like Figure 3As shown, the present invention also provides a visual modeling-script programming-mind mapping test case design method for embedded systems, applied to the aforementioned visual modeling-script programming-mind mapping test case design system for embedded systems, comprising:

[0259] Step 1: Receive user instructions through the pattern selection module, select and enter a design pattern in the form of visual modeling, script programming, or mind mapping;

[0260] Step 2: Design test cases under the selected design pattern:

[0261] If it is a visual modeling mode, use case design is completed by dragging and dropping components, configuring parameters, and establishing logical connections;

[0262] If it is a script programming mode, the test case design is completed by writing script code and debugging it by calling a dedicated function library;

[0263] If it is a mind map mode, test case design is completed by creating hierarchical nodes and organizing test scenarios and steps;

[0264] Step 3: Save the completed test cases through the data management module, and support exporting them as standard documents or switching to other modes for secondary editing and data exchange;

[0265] Step 4: In mind map mode, all use cases in all modes can be shared with team members through review tags, supporting multi-person collaborative editing.

[0266] The interaction between each module and the hardware support layer is described below, as shown in Table 1.

[0267]

[0268]

[0269]

[0270]

[0271]

[0272]

[0273]

[0274]

[0275]

[0276] Embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0277] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0278] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0279] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0280] Contents not described in detail in this specification are prior art known to those skilled in the art. It is hereby indicated that the above description is intended to help those skilled in the art understand this invention, but does not limit the scope of protection of this invention. Any equivalent substitutions, modifications, improvements, or simplifications of the above descriptions that do not depart from the essential content of this invention fall within the scope of protection of this invention.

Claims

1. A visual modeling-script programming-mind mapping test case design system for embedded systems, characterized in that, include: The mode selection module provides an entry point for switching between three test case design modes: visual modeling, script programming, and mind mapping, and loads the corresponding design interface according to the user's selection. The mode selection module includes: The mode switching unit is used to respond to user operations and seamlessly switch between three design modes; The save unit is used to automatically save the current design progress during the switching process and inherit the configured core data; it defines a CoreData data structure containing test targets, key parameters, and device models. When switching modes, it first pulls the core data from the database or cache, and then injects the initialization function of the new mode; non-core data is not inherited and default values ​​are used; if the field requirements are inconsistent, it automatically performs field mapping or completes the default parameters. The preference recording unit is used to record the user's frequently used pattern preferences and loads the most recently used design patterns by default when the system starts up. The tutorial section provides operation guides and typical application scenarios for different modes. The visual modeling test case design module and connection mode selection module provide a visual drag-and-drop interface, supporting the visual design of test cases through component configuration, parameter settings, and logical connections. The visual modeling test case design module includes: The component library unit provides general processing, operation control, and data interaction components. The design canvas unit is used to receive components dragged and dropped by the user from the component library unit, and supports establishing serial or parallel execution logic between components through connections. The parameter configuration unit provides a parameter configuration interface for the selected component in the canvas; The programmable script test case design module and the connection mode selection module provide a script editing environment and support the design of complex logic test cases by writing code. The mind map-based test case design module and connection mode selection module provide a mind map editing interface, supporting the organization of test case scenarios, steps, and expected results through hierarchical nodes; The data management module, connected to the visual modeling test case design module, the programmable script test case design module, and the mind map test case design module, is used for storing, formatting, importing, exporting, and cross-modal data exchange of test case data; the data management module includes: The format conversion unit is used to support the import and export of multiple formats of use case data generated by the three design patterns. The data interoperability unit is used to enable mutual referencing and conversion of test case data among the three design patterns; the steps of the mind map test case analysis can be directly imported into the visualization modeling module to generate a visual process, and the parameter configuration of the visual modeling test cases can be synchronized to the script module to generate corresponding code snippets; the InteroperableCaseData core interoperability model is defined, which abstracts common data such as test case name, test point, steps including action / data factors, parameters, and expected results; the mind map test cases extract node data mapping, the visualization test cases parse topology node transformation, and the script test cases parse function calls and parameter mapping through AST parsing.

2. The visual modeling-script programming-mind mapping test case design system for embedded systems according to claim 1, characterized in that, The programmable script use case design module includes: The code editing unit provides a script editing environment with syntax highlighting, code completion, and syntax checking, and supports multiple scripting languages; A dedicated function library unit is used to provide function libraries specifically for embedded system testing; The debugging unit supports single-step execution of scripts, setting breakpoints, and viewing variables.

3. The visual modeling-script programming-mind mapping test case design system for embedded systems according to claim 1, characterized in that, The mind map-based use case design module includes: The mind map editing unit provides a tree-structured mind map editing interface, supporting the addition, deletion, modification, drag-and-drop sorting, and hierarchical adjustment of nodes; Core node unit, used to provide standardized core node types; The review marking unit is used to add review status markings to mind map nodes. The status includes at least pending review, passed, and needs modification.

4. A visual modeling-script programming-mind mapping test case design method for embedded systems, applied to the visual modeling-script programming-mind mapping test case design system for embedded systems as described in any one of claims 1-3, characterized in that, include: Step 1: Receive user instructions through the pattern selection module, select and enter a design pattern in the form of visual modeling, script programming, or mind mapping; Step 2: Design test cases under the selected design pattern: If it is a visual modeling mode, use case design is completed by dragging and dropping components, configuring parameters, and establishing logical connections; If it is a script programming mode, the test case design is completed by writing script code and debugging it by calling a dedicated function library; If it is a mind map mode, test case design is completed by creating hierarchical nodes and organizing test scenarios and steps; Step 3: Save the completed test cases through the data management module, and support exporting them as standard documents or switching to other modes for secondary editing and data exchange.

5. The visual modeling-script programming-mind mapping test case design method for embedded systems according to claim 4, characterized in that, In mind map mode, all use cases in all modes can be shared with team members through review tags, supporting collaborative editing by multiple people.

Images