Real vehicle 360 image-based performance test method

Abstract

The invention provides a real vehicle 360 image performance testing method, and belongs to the field of automobile electronic testing. The method comprises the following steps: step 1, connecting a vehicle machine with an upper computer; step 2, starting an ADB debugging mode on the vehicle machine; step 3, installing a test auxiliary tool library on the upper computer; 4, intercepting a vehicle end image, and creating a standard view template library; step 5, starting video recording and logging; 6, simulating user operation, and issuing a message instruction; step 7, judging whether the test is passed or not: if so, turning to step 8; if not, turning to step 9; step 8, calculating response delay, and going to step 10; step 9, judging whether to retry or not through exception processing and self-adaptive processing, if so, returning to step 6, and if not, ending the test; step 10, ending recording and log recording; and step 11, judging whether the test needs to be executed circularly, and if not, ending the test. Full-process automation is realized, and the test period is shortened.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of automobile electronic testing, in particular to a real vehicle 360 image performance testing method. BACKGROUND

[0002] With the development of automobile intelligence, the 360 image system has become one of the core functions to ensure driving safety, which needs to support multi-view (front, rear, left, right view, outline view) switching, transparent chassis display, reversing and steering signal triggering activation and other functions, and the performance indicators (such as switching accuracy, activation response time, stability) directly affect the user experience, which needs to be tested rigorously. The existing 360 image testing technology has the following defects: the function test relies on the manual operation of the engineer to switch the view mode of the vehicle screen (or to activate the rear view image by hanging the reverse gear), the test period is long, and it is impossible to perform tens of thousands of stress tests; the test personnel need to visually judge the correctness of the multi-angle (front / rear / left / right / outline view) switching, which cannot quantify the image matching degree and has subjective judgment errors; there is a lack of real-time video recording and detailed log recording mechanism, when the test has problems such as black screen and crash, it is impossible to trace the specific execution steps and error scenarios; the test results only rely on text records, and it is difficult to reproduce the problems; manual testing cannot detect image display abnormalities caused by memory leaks after continuous testing for thousands of times, and cannot meet the stability verification requirements. SUMMARY

[0003] The purpose of the present application is to solve the problems existing in the prior art, and to provide a method for automatically testing the performance of a real vehicle 360 panoramic image system through Android Debug Bridge (ADB) instructions, which covers image acquisition, view switching control and execution monitoring processes.

[0004] The present application is implemented by the following technical solutions: A real vehicle 360 image performance testing method, the steps of the method comprising: Step 1, connect the vehicle machine with the host computer; Step 2, turn on the ADB debugging mode on the vehicle machine; Step 3, install the test auxiliary tool library on the host computer; Step 4, intercept the vehicle end image and create a standard view template library; Step 5, start video recording, record the test process, start the log, and record the execution information; Step 6, the host computer simulates user operations through ADB and sends message instructions through CAN; Step 7, determine whether the test is passed through image verification and UI control state, if yes, go to step 8; if no, go to step 9; Step 8, calculate the response delay and go to step 10; Step 9, determine whether to retry through exception handling and adaptive processing, if yes, return to step 6, if no, go to step 12; Step 10, end recording and log recording, save the recorded video and log to the corresponding path; Step 11, determine whether to loop test, if yes, return to step 6, if no, go to step 12; Step 12, end of test.

[0005] Further, the operation of step 4 includes: selecting a screenshot to obtain a static key frame to obtain a single-frame high-fidelity PNG image; selecting video recording to record a dynamic process to completely save the screen flow within a period of time; creating a standard view template and storing it in a standard view template library.

[0006] Further, the operation of step 5 includes: Step 51, start the vehicle terminal video recording by calling the ADB command through the subprocess library of Python; Step 52, configure the logger through the logging library of Python, and set the log level to INFO; Step 53, generate a test video file, match the video through the Airtest image recognition library, automatically rename the obtained video file, if the matching is successful, name the video file as PASS_usecaseID_timestamp.mp4; if the matching fails, name the video file as FAIL_usecaseID_timestamp.mp4, and superimpose a red text mark; save the video file to the host computer, and write the absolute path of the video file in the log.

[0007] Further, the step 6 includes: Step 61, integrate the CAN communication interface to realize the signal interaction between the host computer and the vehicle CAN bus, the host computer sends messages through ADB instructions to simulate user operations; Step 62, the CAN card converts the message into CAN bus signals and transmits them to the vehicle through the CAN bus to simulate the real vehicle state; Step 63, the vehicle receives and analyzes the CAN bus signals to trigger the 360 image system.

[0008] Further, the step 61 is executed through the Airtest image recognition library and the Poco library: the Airtest image recognition library simulates user click operations and user sliding operations based on image recognition; the Poco library simulates user click operations and user sliding functions based on the UI tree.

[0009] Further, the operation of simulating the real vehicle state in the step 62 comprises: based on the Python written control CAN card program, the control CAN card program calls the Python SDK of the USB-CAN card, and controls the CAN card through the API interface provided by the Python SDK.

[0010] Further, the control CAN card program presets the correspondence between different vehicle states and standard view templates, and constructs and sends CAN messages by calling the function of the corresponding standard view template.

[0011] Further, the operation of judging whether the test passes or not through image verification and UI control state in the step 7 comprises: The Airtest image recognition library calls the function of the standard template in the standard view template library, compares the feature points of the corresponding view in the template with the feature points of the real-time image of the 360 image system, calculates the matching degree using the built-in SIFT algorithm, and judges whether the preset matching degree threshold is reached; The Poco library is used to identify whether the view switching button is successfully responded by monitoring the attribute change of the button control.

[0012] Further, the step 8 is realized by the integration program timestamp record, and the calculation formula is: The response delay = the timestamp after the image matching succeeds - the image matching time - the timestamp recorded when the signal is issued.

[0013] Further, the step 9 is realized by the failure retry mechanism, and the failure retry mechanism is: the type of failure is "non-fatal failure", the configuration file has preset the retry number, and the step 6 is automatically returned for execution; if the preset retry number is reached, the retry still fails, it is determined as an exception, and the test is ended.

[0014] The beneficial effects of the present application are: through ADB instruction simulation user operation (such as view switching), CAN signal simulation vehicle state (such as reversing, turning), realize full-process automation control, can support tens of thousands of continuous testing, efficient completion of stress testing, greatly shorten the test cycle (more than 80% higher than artificial test efficiency); through Airtest image recognition library extracts image key features, and pre-stored template library is quantitatively matched (such as ≥75% is judged as success), and the Poco library is combined to identify the UI control state, realize the objective quantitative verification of image correctness and view switching logic; through real-time video recording (named as PASS / FAIL + timestamp automatically according to the result), detailed log recording (execution steps, ADB instruction, error type), the whole test process can be completely traced back, when the problems such as black screen and crash occur, the error scene can be accurately located through video and log; support long time high frequency continuous testing, combined with abnormal detection mechanism (such as automatically triggering screenshot and log when response timeout, image recognition fails), can accurately capture the stability problems such as image display abnormality and delay increase after continuous testing, and expose the potential risk of system in advance. BRIEF DESCRIPTION OF DRAWINGS

[0015] Figure 1 is the overall flowchart of the method of the present application. DETAILED DESCRIPTION

[0016] The following will be described in detail in combination with the accompanying drawings Figure 1 The present application will be further described in detail: The present application aims to provide a kind of real vehicle 360 image performance test method, by connecting car machine system with host computer, realizes the control and data acquisition of car machine using ADB instruction, combines Airtest image recognition library and Poco UI control recognition library, carries out automation verification to 360 image image correctness, view switching logic, response time, exception handling etc., and realizes the traceability of whole test process by log recording and video recording.

[0017] As shown in the figure, the 360 image performance test method comprises the following steps: Step 1, car machine and host computer connection: the USB port reserved by car machine is connected to host computer by USB line or wireless mode. Specifically, USB connection is suitable for testing environment fixed, needs stable data transmission scene, wireless connection is suitable for mobile testing or car machine is inconvenient to wiring scene.

[0018] Step 2, enable ADB debugging mode on the vehicle's infotainment system: ADB (Android Debug Bridge) is an existing standard tool. To enable the core, simply activate the "ADB debugging" option according to the path specified by the car manufacturer. Only when connecting to the host computer for the first time do you need to confirm "Allow connection" on the vehicle's infotainment system interface. This operation is a permission verification and subsequent connections do not require repeated verification.

[0019] Step 3, Install test tool libraries: Install test auxiliary tool libraries (Python, ADB tools, Airtest image recognition library, Poco UI control recognition library) on the host computer.

[0020] The specific steps are as follows: ① Install Python 3.8 or later (you need to check "Add Python to PATH" to ensure that the pip tool can be called normally); ② Install the corresponding ADB tool for your system. A download link will be provided by searching on Baidu. Click it and execute the "adb devices" command after installation. If the vehicle's device serial number is displayed, it means that the driver configuration is successful; ③ Install Airtest and POCO using the pip command: pip install airtest or pip install AndroidUiautomationPoco.

[0021] Step 4: Capture vehicle-side images and create a standard view template library: Based on testing requirements, use ADB screenshot or video recording to acquire real-time images of the 360-degree imaging interface, create standard view templates, and store them in the standard view template library. Specifically, for static, keyframe images (such as stable front / rear views), screenshots are selected to directly obtain single-frame high-fidelity PNG images. This method is simple (completed with a single command), consumes minimal resources (low impact on vehicle system performance), and requires no post-processing, making it suitable as a benchmark for standard view templates. For dynamic process recordings (such as view switching animations or screen changes during continuous operation), video recording is used to completely preserve the image stream over a period of time, avoiding the loss of intermediate states (such as momentary stuttering or screen flickering during switching) due to improper screenshot interval settings. In this invention, the ADB recording capture frequency cannot exceed 30fps (30 frames per second); for dynamic scenes, 10-30fps (1 frame extracted every 100-33ms) is used to ensure the capture of transition details. All captured images are in PNG format.

[0022] Step 5, Enable Recording and Logging: Enable video recording to record the entire test process; enable logging to automatically record execution steps, ADB commands, error logs, and other information.

[0023] Specifically, including: (1) Video recording: Start recording on the vehicle terminal by calling the ADB command through the Python subprocess library: adbshell screenrecord / sdcard / temp_record.mp4 --time-limit 600 (time-limit is set to 10 minutes to meet the requirements of a single test case). After the test case is completed, pull the file to the host computer via the host computer path adb pull / sdcard / temp_record.mp4.

[0024] (2) Logging: Configure the logger using Python's logging library, set the log level to INFO, and record the following: "timestamp, test case ID, execution steps, ADB / CAN command, result, exception description, file path". The log file is named by date (e.g., "20240725_test.log"), and key information is printed to the console.

[0025] (3) Test video file generation: The video is automatically matched according to the Airtest image recognition library and the pulled video file is automatically renamed. If the match is successful, it is named PASS_case ID_timestamp.mp4 (e.g., "PASS_Case001_202407251430.mp4"); if the match fails, it is named FAIL_case ID_timestamp.mp4, and a red text mark (e.g., "ERROR: Response delay 2.0 seconds") is superimposed on the upper right corner of the video screen using OpenCV. Finally, the file is saved to the "Test Results / Videos" directory on the host computer, and the absolute path of the file is written to the log.

[0026] Step 6: The host computer simulates user operations via ADB and sends message commands via CAN.

[0027] (1) The integrated CAN (Controller Area Network) communication interface is physically connected to the host computer via the USB interface to realize the signal interaction between the host computer and the vehicle's CAN bus; the host computer sends messages by simulating user operations (such as opening 360, switching 360 views, opening the transparent chassis, etc.) through ADB commands. The specific execution depends on the Airtest image recognition library and the Poco library: the Airtest image recognition library provides simulated user click operations (touch function) and simulated user swipe operations (swipe function), while Poco provides simulated user click operations (poco.click function) and simulated user swipe functions (poco.swipe); Airtest is based on image recognition and can match the standard image provided by the labeled view template library in the current screen and then click and swipe. If there are multiple similar images in the current screen, the Airtest image recognition library will make a recognition error. At this time, the Poco library is used. Poco is based on the UI tree, and the elements in the screen will have fixed UI names. Based on these UI names, the user can accurately simulate clicking and swiping to specific controls or positions, eliminating the defects of the Airtest image recognition library.

[0028] (2) The CAN card converts the message into a CAN bus signal and transmits it to the vehicle unit through the bus to realize signal control: control the CAN card to send reversing signal and turn signal to the vehicle unit to simulate the real vehicle state (such as reversing and turning) to trigger different working modes of the 360 ​​imaging system.

[0029] This invention controls the CAN card program using a custom test script written in Python. The integrated CAN communication interface calls the Python SDK (ZLGCAN SDK) provided by the USB-CAN card manufacturer through the CAN card program; and controls the CAN card through the API interface provided by the SDK. The specific process is as follows: Initialize the CAN card: set the baud rate to 500kbps, matching the vehicle's CAN bus baud rate; construct a CAN message (e.g., a reversing signal: message ID=0x0A1, indicating reverse gear); call the API interface (e.g., CAN_SendMsg()) to send the message to the CAN card.

[0030] Furthermore, the program pre-defines the correspondence between different vehicle states and standard view templates (e.g., "reversing" corresponds to ID=0x0A1, "left turn" corresponds to ID=0x0A2). During testing, the program only needs to call the corresponding standard view template function (e.g., send_reverse_signal()) to construct and send CAN messages to the vehicle's infotainment system via the CAN card, simulating real vehicle operation and triggering the 360-degree camera mode switch without manual intervention. Before the template test, PNG images of each normal view (front view, rear view, outline view, transparent chassis) of the 360-degree camera are collected under the same test environment (e.g., same lighting, same vehicle infotainment system position) and stored in the standard view template library as standard view templates. The templates need to be labeled with the view type (e.g., "front view_standard.png").

[0031] (3) The CAN message of the simulated signal triggers the 360-degree imaging system through the process of "vehicle unit receiving signal, signal parsing, and image activation". The specific process is as follows: ① Signal reception: The vehicle unit has a built-in CAN controller that listens to the message signal in the CAN bus in real time. When it receives a message sent by the host computer through the CAN card, it automatically reads the message ID and data segment; ② Signal parsing: The vehicle unit parses the message and identifies the current simulated vehicle state according to the preset "CAN signal - vehicle state" mapping relationship (such as ID=0x0A1, data=0x01 → "shifting to reverse"); ③ Image activation: The control module automatically triggers the corresponding 360-degree imaging mode according to the identified vehicle state (such as "shifting to reverse" triggers the rear view display, "turning left" triggers the left view + outline view display). This triggering logic is completely consistent with the manual operation of a real vehicle (such as shifting to reverse), ensuring the authenticity of the simulated scene. Step 7: Image verification and UI control status determination.

[0032] The Airtest image recognition library is used to compare image content and verify whether the image meets expectations. Specifically, the current image is compared with a standard template image to determine whether it meets expectations. Verification includes checking for black screens, image misalignment, and stitching failures.

[0033] Furthermore, the verification is automatically completed by the Airtest image recognition library combined with the standard view template library preset by this invention. The specific logic and basis are as follows: During the test, the Airtest image recognition library calls the function of the "standard template" in the standard view template library to automatically extract the feature points (edges, textures, color distribution) of the real-time image and compare them with the feature points of the corresponding view in the template. The matching degree is calculated using the built-in SIFT algorithm of Airtest. The verification is based on whether the preset matching degree threshold is reached (the default of this invention is ≥75%, which can be adjusted according to the accuracy requirements). If the matching degree is ≥ the threshold, it is determined that "the image meets expectations"; if it is < the threshold or no feature points are detected, it is determined to be abnormal (such as black screen with no feature points, misalignment causing feature point offset, splicing failure causing feature point loss). Preferably, the abnormal type is automatically classified according to the feature point loss situation (such as "black screen" corresponds to no feature points, "misalignment" corresponds to feature point position offset >10%).

[0034] The Poco library is used to identify the state of in-vehicle UI controls, specifically verifying whether view switching buttons respond successfully (e.g., switching to front view, rear view, outline view, transparent chassis, etc.). Poco's key to detecting button changes is monitoring changes in button control attributes. Changes in button state (e.g., selected / unselected), text, visibility, etc., are reflected in their attribute values. Poco locates the target button, periodically retrieves its target attributes (e.g., selected state, text content, visibility, etc.), and determines the change by comparing the differences in attribute values. However, Poco only applies to button or control changes and cannot monitor issues like 360-degree camera changes, black / white screens, or view stitching failures, as Airtest does.

[0035] If the image verification determines that "the image meets expectations" and the UI control status is normal, proceed to step 8.

[0036] If the image verification determines that "the image does not meet expectations" or the UI control is not in a normal state, proceed to step 9, anomaly detection and adaptive processing.

[0037] Step 8, Calculate Response Delay: The image opening time is identified using the Airtest image recognition library, and the response delay of the imaging system is calculated. The response delay is the time from the triggering of the reversing signal to the display of the image, calculated by the main test control program on the host computer. This program is an integrated program that combines CAN signal control, image recognition, and log recording functions. Delay calculation is achieved through "high-precision timestamp recording," requiring no additional hardware support. The calculation formula is as follows: Response delay = Timestamp after successful image matching - Image matching time - Timestamp recorded when signal is sent Step 9, exception handling and adaptive handling.

[0038] To improve test robustness, this invention incorporates a failure retry mechanism as both an exception handling and adaptive mechanism: when step 7 determines that step 6 (view switching, CAN signal transmission, image matching) has failed, the failure type is assessed to determine if it falls under the category of "non-fatal failure." The program automatically returns to step 6 and repeats the execution. If the retry is successful, the subsequent process continues. If the preset number of retries is reached, and the retry fails, it is considered an exception, and the test ends. This mechanism does not apply to "fatal failures," including vehicle-to-everything (V2X) disconnection and CAN card hardware failure. The number of retries can be flexibly set through the program configuration file (config.ini); the failure retry mechanism is executed using Python's "loop + conditional judgment" logic.

[0039] Taking "view switching" as an example: ① Preset parameters: Define `retry_max = 2` (maximum number of retries) and `retry_interval = 1` (retry interval, in seconds) in the configuration file; ② Loop execution: Put the "view switching" step into a `for` loop, with the loop count being "retry count + 1" (first execution + retry). The code logic is: `retry_count = 0; success = False; while retry_count <= retry_max and not success: try: # Execute view switching: send ADB click command touch(Template("switch button template.png")); # Verify switching result: Poco recognizes control status if poco("rear view control ID").exists(): success = True; print(f"successfully switched after {retry_count} times"); else: raise Exception("control not recognized after switching"); except Exception as e: print(f"failed after {retry_count} times: {e}"); retry_count += 1;` time.sleep(retry_interval); # Retry interval; ③ Result determination: If success = True (a certain execution is successful), break out of the loop and continue with subsequent tests; if success = False after the loop ends (failure after the number of retries has been exhausted), trigger the exception handling process and record "View switching failed, retried {retry_max} times, determined to be an exception" in the log.

[0040] Preferably, when (image recognition fails, control recognition fails, response times out) and retry fails, an error handling process is triggered. The process includes (automatic screenshot, log output, video recording and marking, and whether to pause the current test case as needed). ① Automatic Screenshot: This is an error screenshot, triggered only when an anomaly is detected. The screenshot content is the current vehicle infotainment interface (including the abnormal screen), and the name includes the "FAIL" identifier; ② Log Output: The log file contains both "normal execution log" (e.g., "view switching successful," identified by "[INFO]") and "error log" (e.g., "response timeout," identified by "[ERROR]"). The error log needs to additionally record "exception type and file path" for easy filtering; ③ Video Marking: A double marker is used: "filename identifier + video annotation." The filename identifier is FAIL_use case ID_timestamp.mp4, and the video annotation is: The program automatically calls the OpenCV cv2.putText() function at the moment the exception occurs, overlaying red text (font size 20, color (0,0,255)) in the upper right corner of the video screen. The content is "ERROR: exception type timestamp" (e.g., "ERROR: response timeout 2024-07-25"). The time stamp "14:30:05" will be displayed continuously until the end of the video to ensure that viewers can quickly locate the abnormal time period. 1) Implementation details: ① Implementation using the `snapshot()` function of Airtest. When an exception is triggered, call: `snapshot(filename=f"FAIL_{case_id}_{timestamp}.png", msg=error_msg)`. The function automatically completes the entire process of "screenshotting from the vehicle's infotainment system → fetching to the host computer → saving to the specified directory (e.g., "test results / screenshots")", requiring no manual intervention. ② Log output: Configure a logger using Python's `logging` library. When an exception occurs, call the `logging.error()` function to write an error log: `logging.error(f"Example {case_id} exception: {error_msg}, video path: {video_path}")`, and simultaneously print the error message to the console. ③ Video annotation: This is done in two steps: First, filename annotation is done by renaming the video file using Python's `os.rename()` function: `os.rename(original_path, f"FAIL_{case_id}_{timestamp}.mp4")`. Second, video annotation is done using OpenCV. Read video frames, overlay text, re-encode and save, and finally delete the original unlabeled video and keep the labeled video.

[0041] Step 10, End Recording and Log Recording: After normal execution, recording and logging will stop, and the recorded video and logs will be saved to the corresponding path.

[0042] Step 11: Determine whether steps 6 through 10 need to be repeated. If so, return to step 6 for further stability testing; otherwise, the test is complete.

[0043] By simulating user operations with ADB commands and vehicle status with CAN signals, the entire process is automated, supporting tens of thousands of continuous tests, efficiently completing stress tests, and significantly shortening the test cycle. The above technical solution is only one embodiment of the present invention. For those skilled in the art, based on the principles disclosed in the present invention, it is easy to make various types of improvements or modifications, and not limited to the technical solutions described in the specific embodiments of the present invention. Therefore, the foregoing description is only a preferred option and is not restrictive.

Claims

1. A method for testing the performance of a real vehicle's 360° imaging system, characterized in that: The steps of the method include: Step 1: Connect the vehicle's infotainment system to the host computer; Step 2: Enable ADB debugging mode on the vehicle's infotainment system; Step 3: Install the test auxiliary tool library on the host computer; Step 4: Capture the vehicle-side image and create a standard view template library; Step 5: Start video recording, record the test process, enable logging, and record execution information; Step 6: The host computer simulates user operations via ADB and sends message commands via CAN. Step 7: Determine whether the test passes by verifying the image and the state of the UI controls. If yes, proceed to step 8; otherwise, proceed to step 9. Step 8: Calculate the response delay, then proceed to step 10; Step 9: Through exception handling and adaptive handling, determine whether to retry. If yes, return to step 6; otherwise, proceed to step 12. Step 10: End recording and log recording, and save the recorded video and log to the corresponding path; Step 11: Determine whether the test needs to be executed repeatedly. If yes, return to step 6; otherwise, proceed to step 12. Step 12, test complete.

2. The method for testing the performance of a real-vehicle 360-degree imaging system based on ADB according to claim 1, characterized in that: Step 4 includes: using screenshot to capture static keyframes to obtain a single-frame high-fidelity PNG image; using video recording to capture the dynamic process to completely save the video stream over a period of time; and creating a standard view template and storing it in the standard view template library.

3. The method for testing the performance of a real-vehicle 360-degree imaging system based on ADB according to claim 2, characterized in that: The operations in step 5 include: Step 51: Use Python's subprocess library to call the ADB command to start recording video on the vehicle's infotainment system; Step 52: Configure the logger using Python's logging library and set the log level to INFO; Step 53: Generate a test recording file. Match the video using the Airtest image recognition library and automatically rename the obtained video file. If the match is successful, name the video file PASS_Use Case ID_Timestamp.mp4; if the match fails, name the video file FAIL_Use Case ID_Timestamp.mp4 and overlay a red text mark. Save the video file to the host computer and write the absolute path of the video file into the log.

4. The method for testing the performance of a real-vehicle 360-degree imaging system based on ADB according to claim 3, characterized in that: The operations in step 6 include: Step 61: Integrate the CAN communication interface to realize signal interaction between the host computer and the vehicle's CAN bus. The host computer simulates user operation and sends messages through ADB commands. Step 62: The CAN card converts the message into a CAN bus signal and transmits it to the vehicle's infotainment system via the CAN bus to simulate the real vehicle status. Step 63: The vehicle's infotainment system receives and parses the CAN bus signal, triggering the 360° imaging system.

5. The method for testing the performance of a real-vehicle 360-degree imaging system based on ADB according to claim 4, characterized in that: Step 61 is executed using the Airtest image recognition library and the Poco library: the Airtest image recognition library simulates user click operations and user swipe operations based on image recognition; the Poco library simulates user click operations and user swipe functions based on the UI tree.

6. The method for testing the performance of a real-vehicle 360-degree imaging system based on ADB according to claim 4, characterized in that: The operation of simulating the real vehicle state in step 62 includes: a CAN card control program written in Python, which calls the Python SDK of the USB-CAN card and controls the CAN card through the API interface provided by the Python SDK.

7. The method for testing the performance of a real-vehicle 360-degree imaging system based on ADB according to claim 6, characterized in that: The control CAN card program pre-defines the correspondence between different vehicle states and standard view templates. By calling the functions of the corresponding standard view templates, it constructs and sends CAN messages.

8. The method for testing the performance of a real-vehicle 360-degree imaging system based on ADB according to claim 7, characterized in that: Step 7, which involves determining whether the test passes based on image verification and UI control status, includes the following: The Airtest image recognition library calls functions of standard templates in the standard view template library to compare the feature points of the corresponding view in the template with the feature points of the real-time image of the 360 ​​imaging system, uses the built-in SIFT algorithm to calculate the matching degree, and determines whether the preset matching degree threshold has been reached. The Poco library can be used to identify whether a view switching button is responding successfully by monitoring changes in the properties of a button control.

9. The method for testing the performance of a real-vehicle 360-degree imaging system based on ADB according to claim 8, characterized in that: Step 8 is achieved by calculating the timestamp record through an integrated program. The calculation formula is as follows: Response delay = timestamp after successful image matching - image matching time - timestamp recorded when signal is sent.

10. The method for testing the performance of a real-vehicle 360-degree imaging system based on ADB according to claim 9, characterized in that: Step 9 is implemented through a failure retry mechanism, which is as follows: the failure type is "non-fatal failure" and the configuration file has a preset number of retries, so it automatically returns to step 6; if the preset number of retries is reached and the retries still fail, it is judged as an exception and the test ends.

Images