Visual test system, test method and computer readable storage medium

Abstract

The invention belongs to the technical field of robots, and relates to a visual test system and method and a computer readable storage medium, and the system comprises: 1) a configuration file management module which is used for analyzing and loading test scene data in an external structured configuration file, and providing an access interface for configuration data during operation; the simulation data generation and release module is connected with the configuration file management module and used for generating simulation barrier data conforming to a preset ROS message format according to the currently activated test scene data and performing periodical or event-driven release through an ROS topic release device; and the visual synchronous driving module is connected with the configuration file management module and the simulation data generation and release module. The system has the effect of constructing an efficient, flexible and visual special test verification platform instead of directly realizing an obstacle detection or obstacle avoidance function.

Description

Technical Field

[0001] This invention relates to the field of robotics, and more particularly to a visual testing system, testing method, and computer-readable storage medium. Background Technology

[0002] With the widespread application of intelligent systems such as autonomous mobile robots and self-driving vehicles, obstacle detection, as a core module for environmental perception and safe navigation, is of paramount importance in terms of reliability and accuracy. Currently, the verification and testing methods for obstacle detection modules face the following technical bottlenecks: First, the testing process lacks systematicity and professionalism. Most existing technical solutions focus on the implementation and optimization of the obstacle detection function itself. For example, patent document CN113311804A discloses an environmental detection device and method based on a ROS system, mainly using sensors such as LiDAR to achieve environmental detection and mapping; patent document CN115793657A discloses a control method for vehicle obstacle avoidance and blind spot detection, focusing on real-time obstacle avoidance control based on multi-sensor data fusion. These solutions share the common goal of directly realizing the robot's perception and obstacle avoidance functions, rather than systematically testing and verifying the performance of these functional modules themselves. Therefore, a standardized testing framework specifically for such modules is lacking.

[0003] Second, the configurability and reusability of test scenarios are poor. Traditional testing methods typically hardcode test cases into the program or rely on complex physical experiment setups. Every time the test scenario is modified (such as adjusting the position, number, or motion state of obstacles), developers need to modify the source code and recompile it. The testing process is cumbersome, test scenarios are difficult to reuse and share, resulting in low testing efficiency and difficulty in ensuring the comparability of test results.

[0004] Third, the testing process lacks intuitive visualization and real-time interaction. Although visualization tools such as RVIZ exist in the ROS ecosystem, existing solutions typically limit visualization to displaying raw sensor data or the final planned path. For example, patent document CN116822633A mentions using ROS's RVIZ to display simulation models. However, during testing, there is a lack of a visualization scheme that synchronously, juxtaposes, and compares in real-time the simulated test inputs (i.e., assumed obstacles), the internal logic of the module under test (such as the detection area), and the module's output results (such as the obstacle's presence status). This makes it difficult for testers to intuitively and quickly locate problems and hinders flexible interactive control during testing.

[0005] Fourth, the automation and quantification of testing and evaluation are low. Performance evaluation of obstacle detection modules often relies on manual observation and judgment by testers, lacking automated data recording, comparative analysis, and quantitative indicator generation mechanisms (such as detection latency, false alarm rate, and false negative rate).

[0006] In summary, existing technologies lack a dedicated testing and verification platform for obstacle detection modules that integrates configurable test case management, real-time synchronous visualization, interactive control, and automated evaluation. This is precisely the technical problem that this invention aims to solve. Summary of the Invention

[0007] The purpose of this invention is to provide a visual testing system, testing method, and computer-readable storage medium to solve the technical problem of lacking a dedicated testing and verification platform for obstacle detection modules that integrates configurable test case management, real-time synchronous visualization, interactive control, and automated evaluation. The goal is to build an efficient, flexible, and intuitive dedicated testing and verification platform, rather than directly implementing obstacle detection or obstacle avoidance functions.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: A visualization testing system, deployed on a computing device and communicatively connected to an obstacle detection module under test and a visualization tool, includes: 1) Configuration file management module: used to parse and load test scenario data in external structured configuration files, and provide runtime access interfaces to the configuration data; 2) Simulated data generation and publishing module: connected to the configuration file management module, used to generate simulated obstacle data that conforms to the preset ROS message format based on the currently active test scenario data, and publish it periodically or event-driven through the ROS topic publisher; 3) Visualization Synchronization Drive Module: Connected to the configuration file management module and the simulation data generation and publishing module; 4) Human-computer interaction control module: used to capture user input events and convert the events into control commands, which are then sent to the configuration file management module and / or the simulation data generation and publishing module to perform test scenario switching and process control operations; 5) Test Result Analysis Module: Subscribe to the output topics of the obstacle detection module and the input data of the simulation data generation and publishing module, perform real-time or offline data comparison and analysis, calculate performance indicators, and generate test reports in visualization or text format.

[0009] As a preferred embodiment of the present invention, in 1), the module supports monitoring changes to the configuration file during system operation and enables dynamic hot updates of test scenarios.

[0010] In a preferred embodiment of the present invention, in step 2), this module is responsible for generating ROS visualization marker messages, driving the visualization tool to synchronously render the simulation environment layer, the detection logic layer, and the output state layer. This module also subscribes to the output topics of the obstacle detection module to update the rendering content of the output state layer.

[0011] Another objective of this invention is a testing method for a visual testing system. The visual testing system, as described above, includes the following steps in its testing method: S101. Test Scenario Configuration and Loading Steps: Read at least one predefined test scenario data from an external structured configuration file independent of the program source code. The test scenario data is organized in key-value pairs or a hierarchical structure; its content definition includes: Simulated obstacle set: The attributes of each simulated obstacle include at least a type identifier, spatial coordinates, dynamic or static status identifier, and relative velocity vector when it is dynamic; it also includes meta-information of the test scenario.

[0012] S102. Simulated data stream publishing steps: Based on the loaded test scenario data, construct simulated obstacle information that conforms to the ROS standard message interface, and publish the simulated data stream to the obstacle detection module under test continuously or on demand at a preset frequency through the ROS topic publishing mechanism to simulate the obstacle information input by the real sensor. S103. Synchronous Visualization Rendering Steps: Perform synchronous rendering in a visualization tool connected to the same ROS network; the rendering content includes: 1) Simulated Environment Layer: Based on the test scenario data, render the three-dimensional geometric representation of each simulated obstacle, and use graphic elements that are different from the geometric representation to represent its dynamic attributes; 2) Detection logic layer: Renders the detection area defined inside the obstacle detection module or inferred from its output; the detection area is divided according to safety level or function, and the monitoring area includes one or more of emergency braking area, early warning monitoring area or side blind spot, and is rendered with semi-transparent color blocks for differentiation.

[0013] 3) Output Status Layer: Subscribes to and renders the detection result status information output by the obstacle detection module in real time. This rendering is presented in the form of graphical status indicator lights and / or text labels overlaid on the simulation environment layer, used to intuitively indicate binary or discretized states such as "obstacles exist in front / back / left / right" and "emergency stop".

[0014] S104. Interactive Test Control Steps: Provide a human-computer interaction interface to listen to user input control commands in real time; respond to specific control commands and dynamically change the test process, including but not limited to: immediately switch to another test scenario, pause / resume data publishing, or execute the test sequence step by step; S105. Result Comparison and Report Generation Steps: During or after the test, the actual detection results output by the obstacle detection module are automatically compared with the expected results derived from the current test scenario data; based on the comparison differences, key performance indicators are recorded, including at least the detection response delay, the number of false alarms, and the number of missed alarms; and a structured test report is generated based on the indicators.

[0015] Example 3: A computer-readable storage medium comprising a computer program, which, when executed by a processor, performs the visualization testing system as described above; or Perform the testing methods of the visualization testing system as described above.

[0016] The beneficial effects of this invention are: 1. A pioneering dedicated framework for testing and verification, with a clear positioning: This invention clearly distinguishes itself from solutions that implement specific perception or obstacle avoidance functions, creatively constructing a "meta-testing platform" for verifying the performance of such functional modules. This fundamental distinction in technical purpose and application field constitutes the core innovative basis of this invention.

[0017] 2. It achieves "code decoupling" and dynamic management of test cases, greatly improving testing efficiency and flexibility: By introducing external structured configuration files (such as YAML / JSON) to define test scenarios, testers can freely add, delete, and modify test cases without needing programming skills or modifying source code. This separates test logic from test data, significantly reducing test maintenance costs and improving the reusability and build speed of test scenarios.

[0018] 3. A multi-level synchronous visualization comparison system was constructed, making the testing process highly transparent and intuitive: Simulated input, module internal logic (detection area), and module output results—three key information layers—are synchronously rendered and displayed in a unified spatiotemporal coordinate system. This allows testers to clearly see "what input was given," "where the module should be detected," and "what the module actually output," greatly accelerating the problem localization and logical understanding process.

[0019] 4. Provides convenient interactive test control and optimizes user experience: Through instant interaction methods such as shortcut keys, it supports the switching of test scenarios in seconds and the flexible control of the test process, making exploratory testing, regression testing and demonstration verification extremely efficient.

[0020] 5. An automated quantitative evaluation mechanism has been introduced to improve the objectivity of test conclusions: By automatically comparing the actual output with the expected results and calculating key indicators such as latency, false alarm rate, and false negative rate, subjective qualitative judgments are transformed into objective quantitative data, making performance evaluation more scientific and comparisons between different version modules more reliable. Attached Figure Description

[0021] Figure 1 This is a schematic diagram illustrating the architectural relationship between a test system and external modules provided in one embodiment of the present invention.

[0022] Figure 2 A flowchart of a visualization testing method provided in one embodiment of the present invention.

[0023] Figure 3 This is a structural diagram of the internal modules of a test system provided in one embodiment of the present invention.

[0024] Figure 4 This is a schematic diagram of the multi-level synchronous rendering effect displayed in the visualization tool interface in one embodiment of the present invention. Detailed Implementation

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

[0026] Example 1: like Figures 1 to 4 As shown, a visualization testing system is deployed on a computing device and communicates with the obstacle detection module under test and visualization tools, including: 1) Configuration file management module: used to parse and load test scenario data in external structured configuration files, and provide an interface for accessing the configuration data at runtime; this module supports monitoring changes to configuration files during system operation and enables dynamic hot updates of test scenarios.

[0027] 2) Simulated Data Generation and Publishing Module: Connected to the configuration file management module, this module generates simulated obstacle data conforming to a preset ROS message format based on the currently active test scenario data, and publishes it periodically or event-driven via the ROS topic publisher. This module is responsible for generating ROS visualization marker messages, driving the visualization tool to synchronously render the simulated environment layer, detection logic layer, and output state layer. This module also subscribes to the output topics of the obstacle detection module to update the rendered content of the output state layer.

[0028] 3) Visualization Synchronization Drive Module: Connected to the configuration file management module and the simulation data generation and publishing module; 4) Human-computer interaction control module: used to capture user input events and convert the events into control commands, which are then sent to the configuration file management module and / or the simulation data generation and publishing module to perform test scenario switching and process control operations; 5) Test Result Analysis Module: Subscribe to the output topics of the obstacle detection module and the input data of the simulation data generation and publishing module, perform real-time or offline data comparison and analysis, calculate performance indicators, and generate test reports in visualization or text format.

[0029] The test system (100) runs as a standalone ROS node. It primarily interacts with the following external entities: Obstacle detection module (200): An independent ROS node that subscribes to topics such as / scan (LiDAR) or / object_track_result (analog input) and publishes status topics such as / obstacle_detect / obstacle_exist_3D.

[0030] Visualization tools (300): such as RVIZ, subscribe to topics like / visualization_marker_array to receive rendering instructions.

[0031] Configuration file (400): A YAML file located at ~ / .obstacle_test / scenarios.yaml.

[0032] User (500): Sends control commands to the test system via keyboard.

[0033] Example 2: like Figures 1 to 4 As shown, a testing method for a visualization testing system includes the visualization testing system described above, and the testing method of the visualization testing system includes the following steps: S101. Test Scenario Configuration and Loading Steps: Read at least one predefined test scenario data from an external structured configuration file independent of the program source code, wherein the test scenario data is organized in key-value pairs or a hierarchical structure; as a preferred embodiment of the present invention, in S101, the content definition includes: Simulated obstacle set: The attributes of each simulated obstacle include at least a type identifier, spatial location coordinates, dynamic or static state identifier, and relative velocity vector when it is dynamic; It also includes metadata about the test scenario.

[0034] S102. Simulated data stream publishing steps: Based on the loaded test scenario data, simulated obstacle information conforming to the ROS standard message interface is constructed. Through the ROS topic publishing mechanism, the simulated data stream is continuously or on demand published to the obstacle detection module under test at a preset frequency to simulate the obstacle information input by real sensors. S103. Synchronous Visual Rendering Steps: Perform synchronous rendering in a visualization tool connected to the same ROS network; In S103, the rendered content includes: 1) Simulated Environment Layer: Based on the test scenario data, render the three-dimensional geometric representation of each simulated obstacle, and use graphic elements that are different from the geometric representation to represent its dynamic attributes; 2) Detection logic layer: Renders the detection area defined inside the obstacle detection module or inferred from its output; the detection area is divided according to safety level or function, and the monitoring area includes one or more of emergency braking area, early warning monitoring area or side blind spot, and is rendered with semi-transparent color blocks for differentiation.

[0035] 3) Output Status Layer: Subscribes to and renders the detection result status information output by the obstacle detection module in real time. This rendering is presented in the form of graphical status indicator lights and / or text labels overlaid on the simulation environment layer, used to intuitively indicate binary or discretized states such as "obstacles exist in front / back / left / right" and "emergency stop".

[0036] S104. Interactive Test Control Procedures: Provides a human-computer interaction interface to listen to user input control commands in real time; responds to specific control commands and dynamically changes the test process, including but not limited to: immediately switching to another test scenario, pausing / resuming data publishing, or executing the test sequence step by step; S105. Results Comparison and Report Generation Steps: During or after the test, the actual detection results output by the obstacle detection module are automatically compared with the expected results derived from the current test scenario data; based on the comparison differences, key performance indicators are recorded, including at least the detection response delay, the number of false alarms, and the number of missed alarms; and a structured test report is generated based on the indicators.

[0037] The process includes the following steps: Step S201: The system starts, and the configuration file management module loads and parses the scenarios.yaml file. An example of the file content is shown below. Figure 4 As shown, a scenario called "Rapid Approach to Dynamic Obstacle" (key '2') is defined, which includes a dynamic obstacle of type 'car', with an initial position of (1.5, 0.0) and a speed of 1.5 m / s.

[0038] Step S202: The user presses the '2' key on the keyboard. The human-computer interaction control module captures this event and notifies the configuration file management module to activate the corresponding scenario.

[0039] Step S203: The simulation data generation and publishing module starts publishing simulated obstacle messages to the / object_track_result topic at a frequency of 10Hz based on the activated scenario data. The position of the obstacle in this message is updated every frame according to its velocity, simulating the effect of a forward robot approaching.

[0040] Step S204: The visualization synchronization driver module performs three tasks simultaneously: Based on the simulation data, blue cylindrical markers (representing the vehicle) and green arrow markers (representing the direction of speed) are published to the / visualization_marker_array topic to form the simulation environment layer.

[0041] Publish semi-transparent yellow, pink, and cyan cube markers to the same topic, representing the preset detection logic layer areas in front, to the left, and to the right of the robot, respectively.

[0042] Subscribe to the ` / obstacle_detect / obstacle_exist` topic published by module under test 200. When a message indicating "obstacle exists ahead" is received, render a red output status indicator at a preset position in front of the robot in the visualization interface.

[0043] Step S205: The test result analysis module simultaneously records the time T1 when the simulated obstacle enters the forward detection area and the time T2 when the module under test first reports "obstacle exists ahead". Calculate the response delay ΔT = T2 - T1.

[0044] Step S206: During the test, the user can press other number keys (such as '1', '3') at any time to switch scenarios. When a simulated obstacle enters the emergency braking zone, the test result analysis module will check whether the module under test issues an emergency status signal within a preset threshold time; otherwise, a missed alarm will be recorded.

[0045] Step S207: After the test is completed, the system automatically generates a report, which includes information such as the response delay of each event in this test, false alarm / missed alarm statistics, etc.

[0046] 3. Visual effects, such as Figure 4 As shown, in the RVIZ interface, testers can simultaneously see: Simulation environment layer (401): A blue cylinder (simulated vehicle) and its motion arrow.

[0047] Detection logic layer (402): Semi-transparent yellow (front), pink (left), and cyan (right) area boxes around the robot.

[0048] Output status layer (403): When the detection module is triggered, a red circular indicator light illuminates in front of the robot, along with a status text label (such as "Front Obstacle: Yes") displayed on the side. This juxtaposed display makes the testing process clear at a glance.

[0049] 4. Dynamic Management of Test Scenarios: If a tester wants to add a test case of "pedestrians walking slowly from the side," they simply need to open the scenarios.yaml file with a text editor, add the following snippet, and save it: c: Name: "Pedestrians slowing down on the side" obstacles: - type: 3# person dynamic: 1 x: 0.8 y: 1.0# Left side velocity: 0.5 The testing system can hot-load this new scenario through a file listening mechanism, or the user can directly call the test by pressing the 'c' key after restarting the system. The entire process requires no modification or compilation of any line of program code.

[0050] Technical effectiveness verification: After testing the obstacle avoidance module of the mobile charging robot in the underground parking lot using this invention, the following quantitative results were achieved: Test case build time is reduced by approximately 85%: from an average of 1 hour of coding and debugging per scenario to 10 minutes of editing YAML files.

[0051] Problem localization time is reduced by an average of 70%: With the help of synchronous visualization, most logical errors can be located within 1 minute through observation.

[0052] The execution time for regression testing across all scenarios has been reduced from 4 hours to 15 minutes, thanks to quick switching via keyboard shortcuts and automated comparisons.

[0053] The test scenario library is 100% reusable and can be independently maintained and expanded by testers outside the development team.

[0054] Example 3: A computer-readable storage medium includes a computer program that, when executed by a processor, performs the visualization test system as described above; or performs a test method of the visualization test system as described above.

[0055] In summary: 1. This invention pioneered a dedicated framework for testing and verification, with a clear focus: It explicitly distinguishes itself from solutions that implement specific perception or obstacle avoidance functions, creatively constructing a "meta-testing platform" for verifying the performance of such functional modules. This fundamental distinction in technical purpose and application field constitutes the core innovative basis of this invention.

[0056] 2. It achieves "code decoupling" and dynamic management of test cases, greatly improving testing efficiency and flexibility: By introducing external structured configuration files (such as YAML / JSON) to define test scenarios, testers can freely add, delete, and modify test cases without needing programming skills or modifying source code. This separates test logic from test data, significantly reducing test maintenance costs and improving the reusability and build speed of test scenarios.

[0057] 3. A multi-level synchronous visualization comparison system was constructed, making the testing process highly transparent and intuitive: the three key information layers—simulated input, module internal logic (detection area), and module output results—are synchronously rendered and displayed in a unified spatiotemporal coordinate system. This allows testers to clearly see "what input was given," "where the module should be detected," and "what the module actually output," greatly accelerating the problem localization and logical understanding process.

[0058] 4. Provides convenient interactive test control and optimizes user experience: Through instant interaction methods such as shortcut keys, it supports the switching of test scenarios in seconds and the flexible control of test processes, making exploratory testing, regression testing and demonstration verification extremely efficient.

[0059] 5. An automated quantitative evaluation mechanism has been introduced to improve the objectivity of test conclusions: By automatically comparing the actual output with the expected results and calculating key indicators such as latency, false alarm rate, and false negative rate, subjective qualitative judgments are transformed into objective quantitative data, making performance evaluation more scientific and comparisons between different version modules more reliable.

[0060] All the devices selected in this application are general standard parts or components known to those skilled in the art. Their structures and principles can be learned by those skilled in the art through technical manuals or conventional experimental methods.

[0061] In the description of the embodiments of the present invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in the present invention based on the specific circumstances.

[0062] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0063] Based on the above-described preferred embodiments of the present invention, and through the foregoing description, those skilled in the art can make various changes and modifications without departing from the inventive concept. The technical scope of this invention is not limited to the contents of the specification, but must be determined according to the scope of the claims.

Claims

1. A visualization testing system, deployed on a computing device and communicatively connected to an obstacle detection module under test and a visualization tool, characterized in that, include: 1) Configuration file management module: used to parse and load test scenario data in external structured configuration files, and provide runtime access interfaces to the configuration data; 2) Simulated data generation and publishing module: connected to the configuration file management module, used to generate simulated obstacle data that conforms to the preset ROS message format based on the currently active test scenario data, and publish it periodically or event-driven through the ROS topic publisher; 3) Visualization Synchronization Drive Module: Connected to the configuration file management module and the simulation data generation and publishing module; 4) Human-computer interaction control module: used to capture user input events and convert the events into control commands, which are then sent to the configuration file management module and / or the simulation data generation and publishing module to perform test scenario switching and process control operations; 5) Test Result Analysis Module: Subscribe to the output topics of the obstacle detection module and the input data of the simulation data generation and publishing module, perform real-time or offline data comparison and analysis, calculate performance indicators, and generate test reports in visualization or text format.

2. The visualization testing system as described in claim 1, characterized in that, In section 1), this module supports monitoring changes to configuration files during system operation and enables dynamic hot updates of test scenarios.

3. The visualization testing system as described in claim 2, characterized in that, In section 2), this module is responsible for generating ROS visualization marker messages, driving the visualization tool to synchronously render the simulation environment layer, detection logic layer, and output state layer. This module also subscribes to the output topics of the obstacle detection module to update the rendering content of the output state layer.

4. A testing method for a visual testing system, characterized in that, The visualization testing system, as described in any one of claims 1-3, includes the following steps in its testing method: S101. Test Scenario Configuration and Loading Steps: Read at least one predefined test scenario data from an external structured configuration file that is independent of the program source code. The test scenario data is organized in key-value pairs or a hierarchical structure. S102. Simulated data stream publishing steps: Based on the loaded test scenario data, simulated obstacle information conforming to the ROS standard message interface is constructed. Through the ROS topic publishing mechanism, the simulated data stream is continuously or on demand published to the obstacle detection module under test at a preset frequency to simulate the obstacle information input by real sensors. S103. Synchronous Visual Rendering Steps: Perform synchronous rendering in a visualization tool connected to the same ROS network; S104. Interactive Test Control Procedures: Provides a human-computer interaction interface to listen to user input control commands in real time; responds to specific control commands and dynamically changes the test process, including but not limited to: immediately switching to another test scenario, pausing / resuming data publishing, or executing the test sequence step by step; S105. Results Comparison and Report Generation Steps: During or after the test, the actual detection results output by the obstacle detection module are automatically compared with the expected results derived based on the current test scenario data. Based on the comparison differences, key performance indicators are recorded, including at least the detection response delay, the number of false alarms, and the number of missed alarms. A structured test report is generated based on the aforementioned indicators.

5. The testing method of the visualization testing system as described in claim 4, characterized in that, In S101, the content definition includes: 1) Set of simulated obstacles: The attributes of each simulated obstacle include at least a type identifier, spatial coordinates, dynamic or static status identifier, and relative velocity vector when it is dynamic; 2) It also includes meta-information about the test scenario.

6. The testing method of the visualization testing system as described in claim 5, characterized in that, In S103, the rendered content includes: 1) Simulated Environment Layer: Based on the test scenario data, render the three-dimensional geometric representation of each simulated obstacle, and use graphic elements that are different from the geometric representation to represent its dynamic attributes; 2) Detection logic layer: Renders the detection area defined inside the obstacle detection module or inferred from its output; the detection area is divided according to safety level or function, and the monitoring area includes one or more of emergency braking area, early warning monitoring area or side blind spot, and is rendered with semi-transparent color blocks for differentiation. 3) Output Status Layer: Subscribes to and renders the detection result status information output by the obstacle detection module in real time. This rendering is presented in the form of graphical status indicator lights and / or text labels overlaid on the simulation environment layer, used to intuitively indicate binary or discretized states such as "obstacles exist in front / back / left / right" and "emergency stop".

7. A computer-readable storage medium, characterized in that, Includes a computer program, which, when executed by a processor, performs the visualization testing system as described in any one of claims 1-3; or Perform the test method of the visualization test system as described in any one of claims 4-5.

Images