An automated testing method and system for in-vehicle infotainment systems

Abstract

The application discloses an automatic test method and system for a vehicle-mounted information entertainment system, and relates to the field of vehicle-mounted information tests, which comprises the following steps: performing a test operation and collecting interface images and CAN signal data; performing multi-algorithm fusion verification on the interface images to obtain three levels of picture verification results; dynamically adjusting the execution strategy of CAN signal verification according to the level of the picture verification results; performing CAN signal verification to obtain signal verification results; triggering a picture secondary check when the picture verification result is suspected to pass and the signal verification result is failed; and generating a test judgment result based on the picture verification result, the signal verification result and the secondary check result. The application realizes dynamic cooperation of picture and CAN signal verification through a two-way linkage mechanism, can distinguish between switch failure and interface normality but function inactivation, simultaneously differentiates signal analysis depth, improves test efficiency and accuracy, and is suitable for smoke test and pressure test of a simplified Android vehicle-mounted system.

Description

Technical Field

[0001] This invention belongs to the field of vehicle information, and particularly relates to an automated testing method and system for vehicle infotainment systems. Background Technology

[0002] Currently, in-vehicle infotainment systems have become the core interface for human-machine interaction in modern cars. However, testing of interactive controls in these systems, such as the comfort stop switch, still primarily relies on manual testing. Testers must manually power on the system, access the corresponding settings page, manually click the switch control, visually observe changes in the interface display, and manually read CAN signals to determine if the switch state has successfully changed and if the function is responding normally. After testing, test data must be manually compiled and test forms filled out. This process is not only inefficient and subjective but also prone to data recording errors and disorganized form archiving, failing to achieve standardized and traceable test records.

[0003] Meanwhile, some in-vehicle systems use customized, simplified Android systems, lacking common automation tools such as uiautomator and adbpull. Traditional automation solutions based on control attribute reading and UI hierarchy traversal are unsuitable. Simply relying on ADB command execution cannot automatically determine whether the operation is actually effective, still requiring manual intervention for verification. Furthermore, existing testing solutions only use a single verification method, lacking dual verification through image comparison and CAN signal analysis. This fails to confirm whether the switch operation is truly transmitted to the vehicle control unit, posing a risk of misjudgment where the interface displays correctly but the actual function is not working, resulting in insufficient test accuracy.

[0004] Based on the above reasons, this invention designs an automated testing method and system for in-vehicle infotainment systems. Summary of the Invention

[0005] The purpose of this invention is to solve the problems in the prior art, and to propose an automated testing method and system for in-vehicle infotainment systems.

[0006] This invention first discloses an automated testing method for an in-vehicle infotainment system, including the following steps: Step S1: Perform test operations, collect interface images before and after the operation, and CAN signal data during the operation; Step S2: Perform multi-algorithm fusion verification on the collected interface image to obtain the image verification result; the image verification result includes at least three levels: fully passed, suspected passed, and failed; Step S3: Based on the level of the image verification result, dynamically adjust the execution strategy of CAN signal verification. The execution strategy includes: if the image verification result is completely passed, then execute the fast verification mode. If the image verification result is "suspected pass", then execute the refined verification mode; If the image verification result is unsuccessful, then the CAN signal verification or the mark verification failure will be terminated. Step S4: Perform CAN signal verification according to the determined execution strategy to obtain the signal verification result; Step S5: When the image verification result is suspected to be passed and the signal verification result is failed, trigger the image secondary verification, re-verify the interface image, and obtain the secondary verification result; Step S6: Based on the image verification result, signal verification result, and secondary verification result, generate the final test judgment result according to the preset linkage judgment rules.

[0007] In the above method, the multi-algorithm fusion verification includes: The interface image is preprocessed, including grayscale conversion, noise reduction, and cropping of the region of interest. Perform pixel-level difference comparison, structural similarity comparison (SSIM), and feature point matching comparison (ORB) respectively to obtain pixel difference values, SSIM similarity values, and ORB feature point matching rates; The pixel difference value, SSIM similarity value, and ORB feature point matching rate are weighted and calculated to obtain the overall image verification score; The overall score is mapped to the level of the image verification result based on the preset multi-level thresholds: an overall score greater than or equal to the first threshold is considered a complete pass, an overall score between the second threshold and the first threshold is considered a suspected pass, and an overall score less than the second threshold is considered a failure.

[0008] In the above method, the weight allocation for the weighted calculation is as follows: pixel difference value accounts for 30%, SSIM similarity value accounts for 40%, and ORB feature point matching rate accounts for 30%; the first threshold is 90 points and the second threshold is 70 points.

[0009] In the above method, the fast verification mode includes: listening to and parsing 1-3 frames of CAN messages corresponding to the comfort stop switch; the refined verification mode includes: continuously listening to 10-20 frames of CAN messages, verifying the validity of the messages, and taking the majority result as the verification conclusion.

[0010] In the above method, the secondary verification of the image uses SSIM and ORB dual algorithms for refined verification. Specifically, it includes: re-performing SSIM structural similarity comparison and ORB feature point matching comparison on the core area of ​​the switch, and then weighting and merging the verification results of the two to obtain the secondary verification result.

[0011] In the above method, if the image verification result is completely passed and the signal verification result is passed, then the double verification is deemed to be passed; If the image verification result is "suspected pass" and the signal verification result is "pass", then the double verification is deemed to have passed. If the image verification result is suspected to be passed, the signal verification result is failed, and the secondary verification result is passed, then the double verification is deemed to have failed, and the exception type is recorded as "the interface displays normally but the underlying function is not effective". If the image verification result is suspected to be passed, the signal verification result is failed, and the secondary verification result is also failed, then the double verification is deemed to have failed, and the exception type is recorded as "failed to switch state"; If the image verification result is not passed, the double verification is directly deemed to have failed.

[0012] The above method also includes an exception log collection step: When an anomaly occurs during image verification, CAN signal verification, or linkage process, the system automatically collects abnormal data, including screenshot files, algorithm parameters and results, original CAN messages, message validity verification results, and linkage execution records. Generate a standardized exception log table and store it in association with the test case identifier.

[0013] The above method also includes an automatic notification step: Pre-store the email addresses of the developers of each functional module; The system automatically matches the corresponding developer based on the type of exception and sends the test report, exception log table, and raw data to that person via email.

[0014] In the above method, the in-vehicle infotainment system is a simplified Android system lacking uiautomator and adb pull tools; the method implements multi-algorithm fusion verification and secondary image verification of interface images using a Python image processing library; the CAN signal verification is implemented by interfacing with the CAN bus using a CAN parsing library; the execution of test operations, acquisition of interface images, and transmission of screenshots are completed using basic ADB commands; the test host integrates the ADB command execution results, image verification results, and CAN parsing results to generate a test report.

[0015] Secondly, the present invention provides an automated testing system for an in-vehicle infotainment system, characterized in that it includes the following components for implementing the above method: Test host; The vehicle's central control unit, as the device under test, receives instructions from the test host and returns screenshots and logs; The image comparison module is used to implement multi-algorithm fusion verification and secondary image verification. The CAN signal parsing module is used to perform differential CAN signal verification. The logging module is used to manage exception logs and test process data; The test report generation module is used to generate standardized test reports and automatically number and save them.

[0016] The beneficial effects of this invention are as follows: 1. This invention performs multi-algorithm fusion verification on interface images to obtain three levels of image verification results, and dynamically adjusts the execution strategy of CAN signal verification according to the level. Compared with the method of performing uniform depth signal verification immediately after the image comparison is passed, this solution adopts a fast verification mode when the image is completely passed, a refined verification mode when it is suspected to be passed, and terminates signal verification when it fails. This avoids invalid CAN message parsing, reduces test resource consumption, and improves test efficiency.

[0017] 2. This solution automatically triggers a secondary image verification when the image verification result is suspected to be passed and the CAN signal verification result is failed. It then performs a refined dual-algorithm verification of the switch's core area using structural similarity and feature point matching. Combined with the linkage judgment rules, it can accurately distinguish between two anomaly types: switch state switching failure and normal interface display but ineffective underlying functions. Existing technologies can only output a binary conclusion of pass or fail; this solution provides fine-grained fault classification results, facilitating developers to quickly locate the root cause of problems.

[0018] 3. This solution is designed for environments where simplified Android systems lack tools such as uiautomator and adbpull. It forms a complete test loop through basic ADB commands, Python image processing libraries, and CAN parsing libraries. It can complete application startup, click operations, screenshot acquisition, image verification, and CAN message parsing without relying on missing system tools. It can be deployed under low hardware conditions and is suitable for unattended smoke testing and stress testing scenarios. It has low deployment costs and high system adaptability. Attached Figure Description

[0019] Figure 1 This is a flowchart of an automated testing method for an in-vehicle infotainment system disclosed in this invention.

[0020] Figure 2 This invention discloses a multi-algorithm fusion verification and hierarchical sub-process in an automated testing method for an in-vehicle infotainment system.

[0021] Figure 3 This is a schematic diagram illustrating the configuration of weight and threshold parameters in an automated testing method for an in-vehicle infotainment system disclosed in this invention.

[0022] Figure 4 This is a flowchart illustrating the rapid verification and refined verification modes in an automated testing method for an in-vehicle infotainment system disclosed in this invention.

[0023] Figure 5 This is a flowchart of the secondary image verification process in an automated testing method for an in-vehicle infotainment system disclosed in this invention.

[0024] Figure 6 This is a flowchart of the linkage judgment rules in an automated testing method for an in-vehicle infotainment system disclosed in this invention.

[0025] Figure 7 This is a flowchart of the abnormal log collection process in an automated testing method for an in-vehicle infotainment system disclosed in this invention.

[0026] Figure 8 This is a system block diagram of an automated testing system for an in-vehicle infotainment system disclosed in this invention. Detailed Implementation

[0027] To facilitate understanding of this application and to make the aforementioned objectives, features, and advantages of this application more apparent, a detailed description of specific embodiments of this application is provided below in conjunction with the accompanying drawings. Numerous specific details are set forth in the following description to provide a thorough understanding of this application, and preferred embodiments are shown in the accompanying drawings. However, this application can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the disclosure of this application. This application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar modifications without departing from the spirit of this application; therefore, this application is not limited to the specific embodiments disclosed below. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified. In the description of this application, "several" means at least one, such as one, two, etc., unless otherwise explicitly specified. It should be noted that when an element is referred to as being "fixed to" another element, it can be directly attached to the other element or there may be an intervening element. When an element is referred to as being "connected to" another element, it can be directly connected to the other element or there may be an intervening element. The terms "vertical," "horizontal," "left," "right," and similar expressions used herein are for illustrative purposes only and do not represent the only possible implementations. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is only for describing particular implementations and is not intended to limit the scope of this application. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0028] Reference Figures 1-8 This invention provides an automated testing method for in-vehicle infotainment systems, the method comprising the following steps: S1: Test operation, collect interface images before and after the operation, as well as CAN signal data during the operation.

[0029] S2: Perform multi-algorithm fusion verification on the collected interface images to obtain image verification results. The image verification results include at least three levels: fully passed, suspected passed, and failed.

[0030] S3: Dynamically adjust the execution strategy of CAN signal verification based on the level of image verification result: if the image verification result is completely passed, execute the fast verification mode; if the image verification result is suspected to be passed, execute the refined verification mode; if the image verification result is failed, terminate CAN signal verification or directly mark the verification as failed.

[0031] S4: Perform CAN signal verification according to the determined execution strategy and obtain the signal verification result.

[0032] S5: When the image verification result is suspected to be passed and the signal verification result is failed, trigger the image secondary verification, re-verify the interface image, and obtain the secondary verification result.

[0033] S6: Based on the image verification results, signal verification results, and secondary verification results, generate the final test judgment result according to the preset linkage judgment rules.

[0034] The working process of this solution is as follows: The test host controls the vehicle's infotainment system to perform a click operation via Appium or ADB commands, simultaneously triggering screenshot capture and CAN message monitoring. The image comparison module first performs multi-algorithm analysis on the screenshot and outputs a tiered result, which directly determines the working depth of the CAN signal analysis module. If the image is deemed potentially passable but CAN analysis fails, the test host automatically commands the image comparison module to perform a secondary, finer comparison of the switch area. All intermediate results and the final judgment are recorded. Its advantages are: by tiering the image verification results and dynamically adjusting the signal verification strategy, unnecessary deep message analysis is avoided, reducing test resource consumption; simultaneously, the reverse-triggered secondary image verification can accurately distinguish between two fault types: physical switch switching failure and abnormal interface display but effective underlying functions, improving the diagnostic capability and accuracy of the test results.

[0035] Furthermore, based on the above methods, a specific implementation of multi-algorithm fusion verification is as follows: (1) The interface image is preprocessed, including grayscale conversion, noise reduction and cropping of the region of interest, retaining only the switch and surrounding key areas to eliminate background interference.

[0036] (2) Perform pixel-level difference comparison, structural similarity comparison and feature point matching comparison respectively to obtain pixel difference value, structural similarity value and feature point matching rate.

[0037] (3) The three values ​​are weighted and calculated to obtain the overall score for image verification.

[0038] (4) Map the comprehensive score to the level of the image verification result according to the preset multi-level threshold: if the comprehensive score is greater than or equal to the first threshold, it is judged as fully passed; if the comprehensive score is between the second threshold and the first threshold, it is judged as suspected passed; if the comprehensive score is less than the second threshold, it is judged as failed.

[0039] During implementation, the test host calls the OpenCV library to perform calculations of the three algorithms in sequence and generates a comprehensive score according to the pre-configured weights. Compared with single-pixel comparison, multi-algorithm weighting can effectively suppress misjudgments caused by dynamic backgrounds, rendering differences or slight icon displacements on the vehicle interface, providing a reliable hierarchical input for subsequent differentiated linkage.

[0040] In one preferred usage method, the weight allocation used in the weighted calculation is as follows: Pixel difference accounts for 30%, structural similarity accounts for 40%, and feature point matching rate accounts for 30%. The preset first threshold is 90 points, and the second threshold is 70 points. The parameter configuration was derived from a certain number of actual vehicle interface samples, ensuring that the three levels of "fully passed," "suspected pass," and "failed" are highly consistent with the actual state of the interface. Thus, during the test execution, the test host can directly apply the set of weights and thresholds by reading the pre-stored configuration file without manual intervention, thereby ensuring the objectivity and reproducibility of the classification results.

[0041] Furthermore, the rapid verification mode is defined as: listening to and parsing 1-3 frames of CAN messages corresponding to the comfort stop switch, while the refined verification mode is defined as: continuously listening to 10-20 frames of CAN messages, validating the acquired messages, removing invalid messages with packet loss, errors, or timing anomalies, and taking the majority of valid parsing results as the verification conclusion. For example, when the image verification result is completely passed, the test host sends a rapid verification command to the CAN parsing module, which only captures the first 3 frames of messages and checks the switch status bits to quickly confirm that the function is effective; when the image verification result is suspected to be passed, a refined verification command is sent, and the module continuously listens to 15 frames of messages, making a final judgment based on the switch status of the majority of frames after validity filtering. This differentiated strategy shortens the testing time in more reliable scenarios, while increasing the sampling rate in uncertain scenarios ensures the accuracy of the judgment, thus improving both efficiency and reliability.

[0042] Regarding the triggering conditions and specific methods for secondary image verification, the following scheme can be adopted: When the image verification result is suspected to be passed and the CAN signal verification result is failed, secondary image verification is triggered. This secondary verification uses a dual algorithm of structural similarity comparison and feature point matching comparison to perform refined verification of the core area of ​​the switch. After receiving the CAN verification failure signal, the test host no longer repeats the pixel-level difference comparison, but directly recalculates the structural similarity value and feature point matching rate of the area, and the two verification results are weighted and merged as the secondary verification result. During implementation, the image used for secondary verification may be the original screenshot after the operation, or it may be an image after higher-precision alignment processing. This mechanism can eliminate misjudgments caused by deviations in the timing of the initial screenshot or slight interface jitter, ensuring that the final judgment result truly reflects the actual state of the switch.

[0043] A detailed implementation of the linkage judgment rule includes several scenarios: if the image verification result is completely passed and the signal verification result is passed, then the double verification is judged to be passed; if the image verification result is suspected to be passed and the signal verification result is passed, then the double verification is also judged to be passed; if the image verification result is suspected to be passed, the signal verification result is failed, and the secondary verification result is passed, then the double verification is judged to be failed, and the exception type is recorded as "the interface displays normally but the underlying function is not effective"; if the image verification result is suspected to be passed, the signal verification result is failed, and the secondary verification result is failed, then the double verification is judged to be failed, and the exception type is recorded as "the switch state switching failed"; if the image verification result is failed, then the double verification is directly judged to be failed, without waiting for the CAN signal result. Inside the test host, the above rules are encoded into conditional branch logic, which is automatically executed after each test and outputs the corresponding judgment code and exception category. In this way, the subsequent test report not only indicates whether it passed or failed, but also clearly points out whether the problem is in the interface layer or the underlying control logic, so that the faulty part can be quickly located without manual reproduction.

[0044] This method also includes an anomaly log collection step. When any anomaly occurs during image verification, CAN signal verification, or linkage processes, such as missing screenshot files, algorithm calculation failures, CAN bus connection interruptions, or message timeouts, the test host will automatically collect anomaly data. The collected data includes: screenshot files at the time of the fault, execution parameters and intermediate results of each algorithm, raw CAN messages, message validity verification records, and timestamps for sending and receiving linkage commands. The system generates a standardized anomaly log table based on this data according to a predefined format and stores it in association with the unique identifier of the current test case. The table uses automatic numbering and naming, and will not overwrite historical logs. Through this method, complete contextual information is retained when an anomaly occurs during testing, facilitating later reproduction and traceability.

[0045] Building upon the aforementioned anomaly log collection, an automatic notification function is also configured, implemented as follows: The email addresses of the development managers for each functional module of the in-vehicle infotainment system are pre-stored in a configuration file on the computer. When a test fails or an anomaly occurs, the test host automatically matches the corresponding developer based on the anomaly type. For example, if the anomaly type is "interface displays normally but underlying functions are not working," it is automatically sent to the CAN network development manager; if the anomaly type is "switch status switching failure," it is sent to the HMI application development manager. The email content includes a test report, anomaly log table, and original screenshots and message data. This notification process is fully automated, requiring no manual intervention, thereby shortening the problem response cycle and improving the efficiency of the R&D closed-loop process.

[0046] For environments where simplified Android in-vehicle systems lack common tools such as uiautomator and adbpull, this method achieves adaptation through a solution composed of the following technical features: (1) The test host directly controls the vehicle's central control unit to complete application startup, page navigation, control click and screenshot capture through ADB basic commands; (2) Transmit the screenshots saved on the vehicle terminal to the test host via ADB basic commands; (3) The screenshots were preprocessed, multi-algorithm fusion verification was performed, and secondary verification was conducted using the Python image processing library; (4) Interact with the vehicle's CAN bus through the CAN parsing library to listen to, parse and verify the validity of the CAN messages corresponding to the comfort stop switch; (5) The test host integrates the ADB command execution results, image verification results, and CAN parsing results to generate a test report. This process does not require the use of uiautomator to obtain control properties or adbpull to transfer large files. Instead, it uses raw ADB commands in conjunction with local image processing and CAN parsing to complete the closed-loop test. This solution has been successfully verified on multiple customized vehicle systems and can achieve unattended smoke and stress testing 24 / 7.

[0047] In one system implementation corresponding to the above method, an automated testing system for an in-vehicle infotainment system is provided. The system includes: a test host, an in-vehicle central control unit, an image comparison module, a CAN signal parsing module, a log recording module, and a test report generation module.

[0048] The test host executes the control, scheduling, and judgment functions of any of the aforementioned test methods. The vehicle's central control unit, as the device under test, receives Appium driver commands, ADB click commands, and screenshot commands from the test host, and returns screenshot files and operation logs. The image comparison module is responsible for multi-algorithm fusion verification and secondary image verification. It internally incorporates various algorithms such as image preprocessing, pixel difference calculation, structural similarity calculation, feature point matching, and weighted scoring. The CAN signal parsing module connects to the vehicle bus via a physical CAN analyzer. Based on the differentiated execution commands sent by the test host, it completes rapid or refined verification and returns the parsing results. The log recording module uniformly manages the abnormal log tables from the image comparison side and the CAN signal side, as well as the linkage processing records during the test process. The test report generation module integrates all data after each test, automatically generates standardized test reports in both Markdown and Excel formats, and saves them using an automatic numbering rule based on the test date and test case ID to ensure that historical records are not overwritten. The various modules of the system exchange instructions and data through the local TCP protocol, which can fully implement the aforementioned methods, thereby improving testing efficiency, distinguishing fault types, enhancing the anti-interference ability of image verification, and realizing the automatic archiving and traceability of test data.

[0049] In terms of hardware, this solution is implemented as follows: The test host connects to the Android system of the vehicle's central control unit via serial port / network to ensure the real-time transmission of commands and capture of screenshots; The vehicle's central control unit connects to the vehicle's CAN node via the CAN bus, while the computer host connects to the CAN bus via a CAN analyzer to enable message listening and parsing. The computer-based system deploys an image comparison module, a CAN signal parsing module, a log recording module, and a test report generation module. Each module interacts with data and transmits commands through local services.

[0050] The communication protocol can be implemented in the following ways: Send driver commands via the AppiumWebDriver protocol to control the startup of in-vehicle applications and page navigation; Send click commands via ADB commands or AppiumID location to control the comfort stop switch operation; The ADBscreencap command controls the in-vehicle system to capture screenshots, and the ADBpull command transmits the screenshots to the local machine. The CAN analyzer is used to listen to and parse the CAN message corresponding to the comfort stop switch using the CAN 2.0 protocol, with the baud rate matched to the vehicle bus configuration. Each module transmits instructions and interacts with data via a local TCP protocol to ensure real-time processing. Test data, verification results, and exception information are all managed by the log recording module, ultimately generating standardized test form documents.

[0051] In terms of the software environment, it can be implemented in the following ways: The computer host has Python 3.8 or above installed, and is configured with Appium-Python-Client, ADB tool, OpenCV for image preprocessing and algorithm implementation, python-CAN for CAN message parsing, pandas for table generation, etc. The vehicle's central control unit can be set to ADB debugging mode without the need to install any additional third-party tools, and it is compatible with a streamlined Android system. The algorithm weights and multi-level thresholds for image verification, the number of fast verification frames and the number of fine-grained verification frames for CAN signal parsing, and the matching relationship between personnel and anomaly types for anomaly notifications are pre-configured in the computer host.

[0052] As is known from common technical knowledge, this invention can be implemented through other embodiments that do not depart from its spirit or essential characteristics. Therefore, the disclosed embodiments described above are merely illustrative and not exhaustive. All modifications within the scope of this invention or its equivalents are included in this invention.

Claims

1. An automated testing method for an in-vehicle infotainment system, characterized in that, Includes the following steps: Step S1: Perform the test operation, collect the interface images before and after the operation, and the CAN signal data during the operation; Step S2: Perform multi-algorithm fusion verification on the collected interface image to obtain the image verification result; the image verification result includes at least three levels: fully passed, suspected passed, and failed; Step S3: Based on the level of the image verification result, dynamically adjust the execution strategy of CAN signal verification. The execution strategy includes: If the image verification result is completely passed, then the quick verification mode will be executed; If the image verification result is "suspected pass", then execute the refined verification mode; If the image verification result is unsuccessful, then the CAN signal verification or the mark verification failure will be terminated. Step S4: Perform CAN signal verification according to the determined execution strategy to obtain the signal verification result; Step S5: When the image verification result is suspected to be passed and the signal verification result is failed, trigger the image secondary verification, re-verify the interface image, and obtain the secondary verification result; Step S6: Based on the image verification result, signal verification result, and secondary verification result, generate the final test judgment result according to the preset linkage judgment rules.

2. The method according to claim 1, characterized in that, The multi-algorithm fusion verification includes: The interface image is preprocessed, including grayscale conversion, noise reduction, and cropping of the region of interest. Perform pixel-level difference comparison, structural similarity comparison (SSIM), and feature point matching comparison (ORB) respectively to obtain pixel difference values, SSIM similarity values, and ORB feature point matching rates; The pixel difference value, SSIM similarity value, and ORB feature point matching rate are weighted and calculated to obtain the overall image verification score; The overall score is mapped to the level of the image verification result based on the preset multi-level thresholds: an overall score greater than or equal to the first threshold is considered a complete pass, an overall score between the second threshold and the first threshold is considered a suspected pass, and an overall score less than the second threshold is considered a failure.

3. The method according to claim 2, characterized in that, The weighted calculation is weighted as follows: pixel difference value accounts for 30%, SSIM similarity value accounts for 40%, and ORB feature point matching rate accounts for 30%; the first threshold is 90 points and the second threshold is 70 points.

4. The method according to claim 1, characterized in that, The rapid verification mode includes: listening to and parsing 1-3 frames of CAN messages corresponding to the comfort stop switch; the refined verification mode includes: continuously listening to 10-20 frames of CAN messages, verifying the validity of the messages, and taking the majority result as the verification conclusion.

5. The method according to claim 1, characterized in that, The secondary verification of the image uses SSIM and ORB dual algorithms for refined verification. Specifically, it includes: re-performing SSIM structural similarity comparison and ORB feature point matching comparison on the core area of ​​the switch, and then weighting and merging the verification results of the two to obtain the secondary verification result.

6. The method according to claim 1, characterized in that, The linkage determination rules include: If both the image verification result and the signal verification result are passed, then the double verification is considered successful. If the image verification result is "suspected pass" and the signal verification result is "pass", then the double verification is deemed to have passed. If the image verification result is suspected to be passed, the signal verification result is failed, and the secondary verification result is passed, then the double verification is deemed to have failed, and the exception type is recorded as "the interface displays normally but the underlying function is not effective". If the image verification result is suspected to be passed, the signal verification result is failed, and the secondary verification result is also failed, then the double verification is deemed to have failed, and the exception type is recorded as "failed to switch state"; If the image verification result is not passed, the double verification is directly deemed to have failed.

7. The method according to claim 1, characterized in that, It also includes the abnormal log collection step: When an anomaly occurs during image verification, CAN signal verification, or linkage process, the system automatically collects abnormal data, including screenshot files, algorithm parameters and results, original CAN messages, message validity verification results, and linkage execution records. Generate a standardized exception log table and store it in association with the test case identifier.

8. The method according to claim 7, characterized in that, It also includes an automatic notification step: Pre-store the email addresses of the developers of each functional module; The system automatically matches the corresponding developer based on the type of exception and sends the test report, exception log table, and raw data to that person via email.

9. The method according to claim 1, characterized in that, The in-vehicle infotainment system is a simplified Android system lacking uiautomator and adb pull tools; in the method, the multi-algorithm fusion verification and secondary image verification of the interface image are implemented using a Python image processing library; the CAN signal verification is implemented by interfacing with the CAN bus using a CAN parsing library; the execution of test operations, acquisition of interface images, and transmission of screenshots are completed using basic ADB commands; the test host integrates the ADB command execution results, image verification results, and CAN parsing results to generate a test report.

10. An automated testing system for an in-vehicle infotainment system, characterized in that, For implementing any one of the methods as claimed in claims 1 to 9, comprising: Test host; The vehicle's central control unit, as the device under test, receives instructions from the test host and returns screenshots and logs; The image comparison module is used to implement multi-algorithm fusion verification and secondary image verification. The CAN signal parsing module is used to perform differential CAN signal verification. The logging module is used to manage exception logs and test process data; The test report generation module is used to generate standardized test reports and automatically number and save them.

Images