Method and device for testing black and white screen of vehicle-mounted screen and nonvolatile storage medium

Abstract

The application discloses a kind of black-and-white screen test method, device and nonvolatile storage medium of vehicle-mounted screen.Therein, the method comprises: in response to test instruction, the picture of vehicle-mounted screen is projected on preset display area;Based on preset coordinate document and preset automated test case document, generate the test task queue to be executed;Multiple test tasks in test task queue are executed one by one, while, the pixel data in preset monitoring area is acquired, wherein, monitoring area is located in display area;Based on pixel data, determine the test result of currently executed test task, wherein, test result includes black screen phenomenon, white screen phenomenon or normal.The present application solves the technical problems of slow adaptation, high miss rate and lack of evidence chain, which leads to low test efficiency, difficult positioning and high labor cost due to the current image recognition relying on training.

Description

Technical Field

[0001] This invention relates to the field of automotive electronics testing technology, and more specifically, to a method, apparatus, and non-volatile storage medium for testing black-and-white screens of in-vehicle displays. Background Technology

[0002] With the rapid development of smart cockpit technology, in-vehicle central control screens have become the core carrier of human-computer interaction, and the stability of their display status directly affects user experience and product image. If the central control screen displays abnormalities such as a black-and-white screen, it not only hinders interaction but also seriously affects the user experience. To improve testing efficiency and save human resources, the industry is gradually adopting automated testing methods to replace manual testing; however, existing technical solutions still have many pain points.

[0003] Currently, most mainstream automated testing relies on image recognition technology to locate click areas. This method requires a large amount of data to train the model, and once the user interface changes, manual retraining of the model is necessary, resulting in long adaptation cycles and high costs. In addition, image recognition is prone to misjudgment or location failure in situations with occlusion or complex scenes, leading to a high rate of missed detections for black-and-white screen issues. Moreover, most solutions can only identify abnormal phenomena and cannot fully retain the operation sequence and visual evidence at the time of the failure, which is not conducive to developing and locating the root cause. At the same time, existing technologies lack stability under long-term 24 / 7 stress testing, and the test process is prone to stagnation due to script interruptions. Furthermore, some solutions rely on additional hardware such as cameras and robotic arms, increasing testing costs.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This invention provides a method, apparatus, and non-volatile storage medium for testing black-and-white screens in vehicle-mounted displays, in order to at least solve the technical problems of slow adaptation, high false negative rate, low testing efficiency, difficult localization, and high labor costs caused by the current image recognition technology's reliance on training.

[0006] According to one aspect of the present invention, a method for testing the black and white screen of an in-vehicle screen is provided, comprising: projecting the image of the in-vehicle screen onto a preset display area in response to a test command; generating a queue of test tasks to be executed based on a preset coordinate document and a preset automated test case document, wherein the coordinate document includes coordinates of a click operation, coordinates of a long press operation, and start and end coordinates of a swipe operation, and the automated test case document includes test scenarios, operation steps, execution order, and waiting time for each of multiple test cases; executing multiple test tasks in the test task queue one by one, and simultaneously acquiring pixel data within a preset monitoring area, wherein the monitoring area is located in the display area; and determining the test result of the currently executed test task based on the pixel data, wherein the test result includes a black screen phenomenon, a white screen phenomenon, or normal operation.

[0007] Optionally, the test task queue includes multiple modes: sequential execution mode, random execution mode, cyclic execution mode, and specified execution mode. Sequential execution mode means that multiple test tasks are executed in the order of the corresponding test case numbers. Random execution mode means that multiple test tasks are executed in a random order. Cyclic execution mode means that multiple test tasks are executed repeatedly. Specified execution mode means that one of the multiple test tasks is executed multiple times.

[0008] Optionally, based on pixel data, the test result of the currently executed test task is determined, including: when the pixel data includes red component data, blue component data, and green component data, calculating the average value of the red component data, blue component data, and green component data; if the average value is not greater than a first preset threshold, determining the test result as a black screen phenomenon; if the average value is not less than a second preset threshold, determining the test result as a white screen phenomenon; and if the average value is greater than the first preset threshold and less than the second preset threshold, determining the test result as normal.

[0009] Optionally, if the test result is a black screen or white screen, the test case number and name corresponding to the currently executed test task, the time when the black screen or white screen occurs, the screen recording segment and pixel data of the monitored area within the preset time range when the black screen or white screen occurs are obtained and recorded.

[0010] Optionally, if the test result is a black screen or a white screen, the time when the black screen or white screen occurs is determined; if the time when the black screen or white screen occurs exceeds a preset time threshold, the vehicle screen is restarted, and the test task queue continues to be executed after the restart.

[0011] Optionally, after all test tasks in the queue have been completed, a test report is generated. The test report includes the number of test tasks, the number of test tasks that were successfully executed, the number of test tasks that resulted in a black screen or white screen, and the number of test tasks that resulted in a normal test.

[0012] According to another aspect of the present invention, a black-and-white screen testing device for an in-vehicle screen is also provided, comprising: a projection module, configured to project the image of the in-vehicle screen onto a preset display area in response to a test command; a generation module, configured to generate a queue of test tasks to be executed based on a preset coordinate document and a preset automated test case document, wherein the coordinate document includes coordinates of a click operation, coordinates of a long press operation, and start and end coordinates of a swipe operation, and the automated test case document includes test scenarios, operation steps, execution order, and waiting time for each of multiple test cases; an execution module, configured to execute multiple test tasks in the test task queue one by one, and simultaneously acquire pixel data within a preset monitoring area, wherein the monitoring area is located in the display area; and a determination module, configured to determine the test result of the currently executed test task based on the pixel data, wherein the test result includes a black screen phenomenon, a white screen phenomenon, or normal operation.

[0013] According to another aspect of the present invention, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored program, wherein, when the program is running, the device where the non-volatile storage medium is located is controlled to execute any of the above-described methods for testing the black and white screen of an in-vehicle screen.

[0014] According to another aspect of the present invention, a computer device is also provided, the computer device including a processor, the processor being configured to run a program, wherein the program executes any of the above-described methods for testing the black and white screen of an in-vehicle screen.

[0015] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements any of the above-described methods for testing the black and white screen of an in-vehicle screen.

[0016] In this embodiment of the invention, a black-and-white screen testing method for vehicle-mounted screens is adopted. Responding to test commands, the image from the vehicle-mounted screen is projected onto a preset display area. Based on a preset coordinate document and a preset automated test case document, a queue of test tasks to be executed is generated. The coordinate document includes coordinates for click operations, long-press operations, and the start and end coordinates for swipe operations. The automated test case document includes the test scenarios, operation steps, execution order, and waiting time for each of multiple test cases. Multiple test tasks in the test task queue are executed one by one. Simultaneously, pixel data within a preset monitoring area is acquired, where the monitoring area is located within the display area. Based on the pixel data, the test result of the currently executed test task is determined. The test result includes a black screen, a white screen, or normal operation. This achieves the goal of executing tests through ADB projection and preset coordinates, and monitoring black-and-white screens based on the RGB pixel mean. This improves the accuracy and response speed of black-and-white screen recognition, thereby solving the technical problems of slow adaptation, high false negative rates, low testing efficiency, difficult localization, and high labor costs caused by the current reliance on training for image recognition. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0018] Figure 1 A hardware block diagram of a computer terminal for implementing a black-and-white screen testing method for in-vehicle screens is shown.

[0019] Figure 2 This is a flowchart illustrating the black-and-white screen testing method for an in-vehicle screen according to an embodiment of the present invention.

[0020] Figure 3 This is a schematic diagram of the architecture of an automated testing system for a vehicle central control screen (black and white) according to an optional embodiment of the present invention.

[0021] Figure 4 This is a schematic diagram of an automated testing process for a black-and-white screen according to an optional embodiment of the present invention;

[0022] Figure 5 This is a structural block diagram of a black-and-white screen testing device for vehicle-mounted screens provided in an embodiment of the present invention. Detailed Implementation

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

[0024] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0025] According to an embodiment of the present invention, a method for testing a black-and-white screen of an in-vehicle screen is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0026] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal for implementing a black-and-white screen testing method for in-vehicle displays is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors (shown as 102a, 102b, ..., 102n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0027] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0028] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the black-and-white screen testing method for vehicle screens in this embodiment of the invention. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned black-and-white screen testing method for vehicle screens. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0029] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0030] Figure 2 This is a flowchart illustrating a method for testing a black-and-white screen of an in-vehicle display according to an embodiment of the present invention, as shown below. Figure 2 As shown, the method includes the following steps:

[0031] In step S201, in response to the test command, the image of the vehicle screen is projected onto a preset display area.

[0032] In this step, the executing entity can be a host computer, for example... Figure 3 This is a schematic diagram of the architecture of an automated testing system for a vehicle central control screen (black and white) according to an optional embodiment of the present invention. Figure 3 As shown, the host computer is used to build automated test sequences, execute Python scripts, and establish connections with the controller via ADB, etc., and is the control core of the entire test system.

[0033] In response to test commands, the image from the vehicle's central control screen is projected onto a preset display area. This involves the host computer establishing a data communication connection with the vehicle's central control screen via Android Debug Bridge (ADB). Using screen mirroring technology or video stream capture commands, the system acquires the display image from the vehicle's central control screen in real time and synchronously transmits it to the host computer's preset display area for visualization. This step aims to build a software display environment that is synchronized with the vehicle's screen status in real time, enabling the host computer to perform subsequent pixel-level monitoring based on the projected image. Through ADB projection, the host computer can not only intuitively view screen changes during the test, but more importantly, it provides a data source for automatic black-and-white screen determination based on pixel data. The monitoring script extracts pixel information within a preset monitoring frame in the display area, extracting the red, green, and blue channel values ​​to achieve automated, real-time detection of screen display anomalies. This eliminates the need for external cameras or hardware sensors, achieving pure software-level screen status monitoring and ensuring consistency between test data and the actual display status of the vehicle's central control screen.

[0034] Step S202: Based on the preset coordinate document and the preset automated test case document, generate a queue of test tasks to be executed. The coordinate document includes the coordinates of the click operation, the coordinates of the long press operation, and the start and end coordinates of the swipe operation. The automated test case document includes the test scenario, operation steps, execution order, and waiting time of each of the multiple test cases.

[0035] In this step, a queue of test tasks to be executed is generated based on a pre-defined coordinate document and a pre-defined automated test case document. This involves using scripts to parse two decoupled data sources, separating the test logic from the operation parameters, thereby constructing a standardized execution sequence. The coordinate document stores the coordinates of click operations, long-press operations, and the start and end coordinates of swipe operations within the test cases. These coordinates can be obtained using the scrcpy projection tool after ADB projection. The automated test case document serves as the execution basis for the entire automated testing process, primarily defining test scenarios, operation steps, execution order, and waiting times, enabling the test case execution script to automatically complete the central control screen function operations according to the pre-defined business process.

[0036] First, the system reads the step descriptions from the automated test case document and automatically associates them with the corresponding coordinate parameters from the coordinate document, binding the test case steps with coordinate data to form a test task containing complete action instructions and location information. This task queue supports multiple execution modes, including sequential, random, cyclic, and specified execution, allowing for flexible scheduling based on testing needs. This coordinate mapping-based, rather than image recognition-based, approach means that when the user interface layout changes, only the location data in the coordinate document needs to be updated; there's no need to rewrite the test case logic or retrain the recognition model. This significantly improves the reusability of test cases and the efficiency of adapting to UI changes, achieving standardization and automated generation of the test process.

[0037] Step S203: Execute multiple test tasks in the test task queue one by one, and at the same time, acquire pixel data in a preset monitoring area, wherein the monitoring area is located in the display area.

[0038] In this step, the host computer controls the vehicle's infotainment system via automated scripts to perform interactive operations such as clicking and swiping, causing changes in the content displayed on the central control screen. After the screen image is projected onto the host computer, a monitoring process is initiated in parallel. This monitoring process captures a preset monitoring frame area in real time within the projected image and continuously collects the red, green, and blue pixel values ​​within that area. The execution and monitoring processes are independent and synchronous, ensuring uninterrupted capture of screen pixel information throughout the entire process of screen state changes triggered by test case execution. The monitoring area typically covers key function buttons or the main part of the screen. Testers can set the number and area of ​​monitoring frames themselves. By calculating the average pixel color within the area in real time, black and white screen phenomena caused by hardware failure, driver anomalies, or software crashes can be accurately captured. This synchronous mechanism avoids the timing errors caused by the separation of operation and monitoring in traditional testing, achieving tight coupling between test actions and state monitoring. It provides continuous and real-time data support for subsequent determination of whether the screen has a black or white screen anomaly based on pixel average values, thereby effectively improving the timeliness and accuracy of fault detection.

[0039] Step S204: Based on pixel data, determine the test result of the currently executed test task, wherein the test result includes black screen phenomenon, white screen phenomenon, or normal.

[0040] In this step, determining the test result based on pixel data involves acquiring the red, green, and blue pixel values ​​of the monitoring area in real time, calculating their arithmetic mean, and comparing this average with preset black screen and white screen thresholds. When the calculated RGB average is less than or equal to the first preset threshold, the screen is determined to be in a black screen state; when the average is greater than or equal to the second preset threshold, the screen is determined to be in a white screen state; if the average is between the two, the display is considered normal. This process quantifies screen brightness and color distribution, achieving automated identification of black and white screen anomalies and avoiding subjective errors from manual observation. Once a black or white screen phenomenon is detected, the current test task is immediately marked as failed, and subsequent problem recording and anomaly recovery processes are triggered, thereby ensuring the objectivity of the test results and the efficiency of the judgment.

[0041] Through the above steps, the goal of performing tests by ADB projection and preset coordinates and monitoring black and white screens based on the average value of RGB pixels was achieved. This improved the accuracy and response speed of black and white screen recognition, and solved the technical problems of slow adaptation, high false negative rate, low testing efficiency, difficult positioning, and high labor costs caused by the current image recognition reliance on training.

[0042] As an optional embodiment, the test task queue includes multiple modes: sequential execution mode, random execution mode, cyclic execution mode, and specified execution mode. Sequential execution mode means that multiple test tasks are executed in the order of the corresponding test case numbers. Random execution mode means that multiple test tasks are executed in a random order. Cyclic execution mode means that multiple test tasks are executed repeatedly. Specified execution mode means that one of the multiple test tasks is executed multiple times.

[0043] Optionally, the test task queue includes multiple execution modes to adapt to different testing scenarios. Sequential execution mode calls and executes test tasks sequentially according to the order of test case numbers, ensuring the logical coherence of the test process and is suitable for routine functional verification. Random execution mode uses an algorithm to shuffle the execution order of test cases, randomly selecting cases for execution to simulate random user interactions in different scenarios, helping to discover potential logical defects or memory leaks caused by operational sequence dependencies. Loop execution mode sets all or some test tasks to be executed repeatedly a specified number of times, primarily used for long-term stress testing to verify the system's stability under sustained high load and the cumulative effect of black-and-white screen phenomena. Specified execution mode allows specific test cases to be selected individually from the task queue for high-frequency repeated execution, specifically used to reproduce intermittent failures or verify the performance of specific functional modules under extreme conditions.

[0044] As an optional embodiment, determining the test result of the currently executed test task based on pixel data includes: calculating the average value of the red component data, blue component data, and green component data when the pixel data includes red component data, blue component data, and green component data; determining the test result as a black screen phenomenon when the average value is not greater than a first preset threshold; determining the test result as a white screen phenomenon when the average value is not less than a second preset threshold; and determining the test result as normal when the average value is greater than the first preset threshold and less than the second preset threshold.

[0045] Optionally, the RGB three-channel pixel values ​​within the monitoring area are acquired in real time, and the arithmetic mean of these three component data is calculated to characterize the overall brightness level of the area. The calculated average value is then compared with preset black screen and white screen thresholds. When the average value is less than or equal to the first preset threshold (default value can be 10), it indicates extremely low screen brightness, and is determined to be a black screen phenomenon; when the average value is greater than or equal to the second preset threshold (default value can be 245), it indicates extremely high screen brightness, and is determined to be a white screen phenomenon; if the average value is between the first and second preset thresholds, it is determined to be a normal display. Utilizing the significant characteristics of black and white screens in RGB values, simple mathematical calculations replace complex image recognition algorithms, significantly reducing computational resource consumption and improving judgment response speed. It also effectively avoids recognition failures caused by interface element occlusion or layout changes, thereby achieving high-precision, low-latency automated monitoring of black and white screen faults.

[0046] As an optional embodiment, when the test result is a black screen or white screen, the test case number and name corresponding to the currently executed test task, the time when the black screen or white screen occurs, the screen recording segment and pixel data of the monitored area within the preset time range when the black screen or white screen occurs are obtained and recorded.

[0047] Optionally, upon detecting a black or white screen anomaly, a problem logging script is automatically triggered to construct a complete chain of fault evidence. This process first obtains the unique identifier of the test case to which the currently executing test task belongs, including its number and name, thus accurately associating the anomaly with the specific business test scenario. Secondly, it records the precise time of the anomaly occurrence, with millisecond-level accuracy, ensuring the traceability of the fault. Simultaneously, the system backtracks and extracts screen recordings of the monitored area within a preset time window (e.g., 20 seconds before and after) before and after the anomaly, completely preserving the screen's evolution from normal to abnormal state, providing developers with intuitive visual evidence. Furthermore, it saves a snapshot of pixel data when the alarm is triggered, serving as a quantitative basis for determining the black or white screen state. All recorded data is standardized and named according to the test case number, name, and occurrence time (e.g., test case number + name + occurrence time) and archived. This mechanism solves the problem of missing or unreproducible evidence at the moment of anomaly occurrence in traditional testing, significantly shortening the analysis cycle from problem discovery to root cause location, and improving test feedback efficiency and problem repair quality.

[0048] As an optional embodiment, if the test result is a black screen or a white screen, the time when the black screen or white screen occurs is determined; if the time when the black screen or white screen occurs exceeds a preset time threshold, the vehicle screen is restarted, and the test task queue continues to be executed after the restart.

[0049] Optionally, when the test result is a black or white screen, the exact time of the anomaly is first recorded, and a recovery waiting timer mechanism is initiated. If the screen automatically recovers to normal display within a preset time threshold (e.g., 30 seconds), it is considered a temporary fault, and subsequent tests continue; if it fails to recover after exceeding this threshold, the anomaly recovery module is automatically triggered. At this time, the host computer sends a restart command to the vehicle's central control screen via ADB commands, forcibly restarting the vehicle controller. After the restart is complete, the system waits for the vehicle to start and the desktop to load before re-establishing the ADB screen projection connection and restoring screen monitoring and recording functions. Subsequently, the test process automatically continues executing the queue of unfinished test tasks, ensuring the continuity of the test work. This mechanism effectively avoids test interruptions caused by vehicle system crashes or screen glitches, achieving 24 / 7 unattended automated stress testing, significantly reducing manual intervention costs, and improving test efficiency and stability.

[0050] As an optional embodiment, after all test task queues have been completed, a test report is generated. The test report includes the number of multiple test tasks, the number of test tasks that were successfully executed, the number of test tasks that resulted in a black screen or white screen, and the number of test tasks that resulted in a normal test.

[0051] Optionally, after all test tasks have been completed, the report generation module is automatically triggered to statistically summarize the data throughout the process. Based on the execution logs, the report calculates the total number of test tasks, the number of successfully executed tasks, the number of tasks identified as having black or white screen anomalies, and the number of tasks displaying normally. Furthermore, the report integrates key indicators such as anomaly recovery success rate and problem evidence links, forming a structured HTML or PDF document. This automated report generation mechanism replaces traditional manual statistical methods, ensuring the objectivity and completeness of the test data. By quantitatively displaying various test indicators, testers can quickly grasp the stability performance and fault distribution of the vehicle's infotainment screen under various test scenarios, providing intuitive data support for product quality assessment, while also facilitating comparative analysis of historical test data and tracking of version iteration quality.

[0052] As an optional embodiment, Figure 4 This is a schematic diagram of an automated testing process for a black-and-white screen according to an optional embodiment of the present invention, such as... Figure 4 As shown, the testing process may include: installing Python 3.8 or later on the host computer and configuring ADB environment variables; connecting the vehicle infotainment system to the host computer via ADB and executing the `adb devices` command to confirm a normal connection; executing the ADB screen projection command to project the central control screen image to the host computer in real time; obtaining the coordinates and click duration of the clicked area in each step of the test case, and naming and saving them to a coordinate document; adapting the test cases into automated test cases based on the naming in the coordinate document, which must include the test case number, operation name, name of the clicked area, and waiting time.

[0053] Testers load the test script and modify the black / white screen judgment threshold, abnormal response waiting time, test case execution interval, problem video recording duration, monitoring box position and size, test case execution mode, and loop testing according to testing requirements. The vehicle infotainment system is initialized to ensure a consistent starting state before each test case execution: all background applications are closed, the desktop is returned, all pop-ups are closed, and all settings are restored to their initial state to avoid interfering with subsequent test case execution results. A screen projection channel is established with the vehicle infotainment system via ADB, projecting the central control screen to the host computer display area in real time. The screen projection monitoring script is run to check the monitoring area and start screen recording.

[0054] Run the test case execution script, selecting the execution mode (sequential execution, random execution, loop execution, specified test case execution). Based on the action type and target location in the test case, call the coordinates from the coordinate document to implement actions such as click, long press, swipe, and wait. During test case execution, the monitoring script automatically samples pixels within the monitoring box and calculates the RGB average value. Screen monitoring is not interrupted with the test case steps, ensuring timely capture of black and white screen issues. If no black and white screen issue is detected during test case execution, the current test case is considered to have executed successfully. If the RGB average value calculated by the monitoring script meets the black or white screen threshold during test case execution, a black and white screen issue is identified. At this point, the execution of the current test case is immediately paused, and the test case is marked as failed. An automatic issue recording script is executed, saving the time point of the issue occurrence, the RGB average value, the current test case number and name, and screen recordings before and after the issue occurred.

[0055] After a black-and-white screen issue occurs, a 30-second recovery waiting period begins. If the screen automatically returns to normal within this period, the next step is initiated. Otherwise, if the screen fails to recover within the waiting time, the adbreboot command is automatically sent through the exception recovery module to restart the vehicle's infotainment system. After the command is sent, a one-minute wait is performed to ensure the system boots up and the infotainment desktop loads. Then, an ADB screen mirroring connection is automatically established, and screen recording and monitoring resume to ensure test continuity. After a single test case passes or the exception is resolved, the infotainment screen is initialized to ensure a consistent initial state before each test case execution. After all test cases have been executed, the script stops screen recording and monitoring. The report generation module then compiles statistics on the entire testing process: total number of test cases, number of executions, number of passes, number of failures, number of black-and-white screen occurrences, exception recovery success rate, and linking evidence of the problem. An HTML / PDF test report is generated, and the entire automated testing process concludes.

[0056] For example, several possible implementation cases may include:

[0057] Routine Functionality Testing: Execute 20 commonly used function test cases, including music and navigation. The screen status is monitored during the execution of each test case; a test case passes if there are no black or white screen occurrences throughout. If a black or white screen occurs during test case execution, the system immediately saves the corresponding screen recording, time point, and test case number. If the screen does not recover after 30 seconds, the vehicle's infotainment system is automatically restarted, and the remaining test cases are executed after restarting.

[0058] Long-term stress test: Select 10 high-frequency test cases, set the number of times to execute in a loop to n, the system automatically records the number of executions and abnormal situations, and automatically generates a test report after the test is completed.

[0059] In-vehicle UI Change Testing: After a UI change is made to a function, the coordinates of the changed icons are re-collected using an ADB projection tool and updated in the coordinate document. All test cases for this function are executed to verify whether clicks, swipes, and long presses accurately hit the target area; if not, corresponding modifications are made. After the coordinate adaptation test is completed, automated black-and-white screen testing can be performed on this function.

[0060] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0061] Through the above description of the embodiments, those skilled in the art can clearly understand that the black-and-white screen testing method for vehicle screens according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0062] According to an embodiment of the present invention, an apparatus for implementing the above-described method for testing black-and-white screens of vehicle-mounted screens is also provided. Figure 5 This is a structural block diagram of a black-and-white screen testing device for vehicle-mounted screens provided according to an embodiment of the present invention, as shown below. Figure 5 As shown, the device includes a projection module 51, a generation module 52, an execution module 53, and a determination module 54. The device will be described below.

[0063] The projection module 51 is used to project the image from the vehicle screen onto a preset display area in response to a test command.

[0064] The generation module 52, connected to the projection module 51, is used to generate a queue of test tasks to be executed based on a preset coordinate document and a preset automated test case document. The coordinate document includes the coordinates of the click operation, the coordinates of the long press operation, and the start and end coordinates of the swipe operation. The automated test case document includes the test scenario, operation steps, execution order, and waiting time of each of the multiple test cases.

[0065] The execution module 53, connected to the generation module 52, is used to execute multiple test tasks in the test task queue one by one, and at the same time, acquire pixel data in a preset monitoring area, wherein the monitoring area is located in the display area.

[0066] The determination module 54, connected to the execution module 53, is used to determine the test result of the currently executed test task based on pixel data. The test result includes black screen phenomenon, white screen phenomenon, or normal.

[0067] It should be noted that the projection module 51, generation module 52, execution module 53, and determination module 54 mentioned above correspond to steps S201 to S204 in the embodiments. Multiple modules implement the same instances and application scenarios as their corresponding steps, but are not limited to the content disclosed in the above embodiments. It should also be noted that the above modules, as part of the device, can run on the computer terminal 10 provided in the embodiments.

[0068] Embodiments of the present invention may provide a computer device. Optionally, in this embodiment, the computer device may be located in at least one of a plurality of network devices in a computer network. The computer device includes a memory and a processor.

[0069] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the black-and-white screen testing method and apparatus for vehicle-mounted screens in this embodiment of the invention. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned black-and-white screen testing method for vehicle-mounted screens. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to a computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0070] The processor can access information and applications stored in memory via a transmission device to perform the following steps: In response to a test command, project the image from the vehicle screen onto a preset display area; generate a queue of test tasks to be executed based on a preset coordinate document and a preset automated test case document, wherein the coordinate document includes the coordinates of click operations, long-press operations, and the start and end coordinates of swipe operations, and the automated test case document includes the test scenarios, operation steps, execution order, and waiting time for each of the multiple test cases; execute multiple test tasks in the test task queue one by one, while simultaneously acquiring pixel data within a preset monitoring area located in the display area; and determine the test result of the currently executed test task based on the pixel data, wherein the test result includes a black screen, a white screen, or normal operation.

[0071] Optionally, the processor may also execute program code with the following steps: The test task queue includes multiple modes: sequential execution mode, random execution mode, cyclic execution mode, and specified execution mode. The sequential execution mode indicates that multiple test tasks are executed in the order of the corresponding test case numbers. The random execution mode indicates that multiple test tasks are executed in a random order. The cyclic execution mode indicates that multiple test tasks are executed cyclically multiple times. The specified execution mode indicates that one of the multiple test tasks is executed multiple times.

[0072] Optionally, the processor may also execute program code that performs the following steps: determining the test result of the currently executed test task based on pixel data, including: calculating the average value of the red component data, blue component data, and green component data when the pixel data includes red component data, blue component data, and green component data; determining the test result as a black screen phenomenon when the average value is not greater than a first preset threshold; determining the test result as a white screen phenomenon when the average value is not less than a second preset threshold; and determining the test result as normal when the average value is greater than the first preset threshold and less than the second preset threshold.

[0073] Optionally, the processor may also execute program code that performs the following steps: when the test result is a black screen or a white screen, obtain and record the test case number and name corresponding to the currently executed test task, the time when the black screen or white screen occurs, the screen recording segment and pixel data of the monitored area within the preset time range when the black screen or white screen occurs.

[0074] Optionally, the processor may also execute program code that performs the following steps: if the test result is a black screen or a white screen, determine the time when the black screen or white screen occurs; if the time when the black screen or white screen occurs exceeds a preset time threshold, restart the vehicle screen and continue executing the test task queue after restarting.

[0075] Optionally, the processor may also execute program code that performs the following steps: after all test tasks in the queue have been completed, a test report is generated, wherein the test report includes the number of multiple test tasks, the number of test tasks that were successfully executed, the number of test tasks that resulted in a black screen or white screen, and the number of test tasks that resulted in a normal test.

[0076] This invention provides a method for testing black-and-white screens on vehicle-mounted screens. Responding to a test command, the image from the vehicle-mounted screen is projected onto a preset display area. Based on a preset coordinate document and a preset automated test case document, a queue of test tasks to be executed is generated. The coordinate document includes coordinates for click operations, long-press operations, and the start and end coordinates for swipe operations. The automated test case document includes the test scenarios, operation steps, execution order, and waiting times for multiple test cases. Multiple test tasks in the queue are executed sequentially, while pixel data within a preset monitoring area (located in the display area) is acquired. Based on the pixel data, the test result of the currently executed test task is determined. The test result includes a black screen, a white screen, or normal operation. This method achieves the goal of improving the accuracy and response speed of black-and-white screen recognition by using ADB projection and preset coordinates to execute tests and monitoring black-and-white screens based on the RGB pixel mean. This solves the technical problems of slow adaptation, high false negative rates, low testing efficiency, difficult localization, and high labor costs caused by the current reliance on training for image recognition.

[0077] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a non-volatile storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0078] Embodiments of the present invention also provide a non-volatile storage medium. Optionally, in this embodiment, the aforementioned non-volatile storage medium can be used to store the program code executed by the black-and-white screen testing method for vehicle-mounted screens provided in the above embodiments.

[0079] Optionally, in this embodiment, the non-volatile storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0080] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: in response to a test command, projecting the image of the vehicle screen onto a preset display area; generating a queue of test tasks to be executed based on a preset coordinate document and a preset automated test case document, wherein the coordinate document includes the coordinates of a click operation, the coordinates of a long press operation, and the start and end coordinates of a swipe operation, and the automated test case document includes the test scenarios, operation steps, execution order, and waiting time for each of multiple test cases; executing multiple test tasks in the test task queue one by one, while acquiring pixel data within a preset monitoring area, wherein the monitoring area is located in the display area; and determining the test result of the currently executed test task based on the pixel data, wherein the test result includes a black screen phenomenon, a white screen phenomenon, or normal operation.

[0081] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: The test task queue includes multiple modes: sequential execution mode, random execution mode, cyclic execution mode, and specified execution mode. The sequential execution mode indicates that multiple test tasks are executed in the order of the corresponding test case numbers. The random execution mode indicates that multiple test tasks are executed in a random order. The cyclic execution mode indicates that multiple test tasks are executed cyclically multiple times. The specified execution mode indicates that one of the multiple test tasks is executed multiple times individually.

[0082] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: determining the test result of the currently executed test task based on pixel data, including: calculating the average value of the red component data, blue component data, and green component data when the pixel data includes red component data, blue component data, and green component data; determining the test result as a black screen phenomenon when the average value is not greater than a first preset threshold; determining the test result as a white screen phenomenon when the average value is not less than a second preset threshold; and determining the test result as normal when the average value is greater than the first preset threshold and less than the second preset threshold.

[0083] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: when the test result is a black screen or a white screen, obtain and record the test case number and name corresponding to the currently executed test task, the time when the black screen or white screen occurs, the screen recording segment and pixel data of the monitored area within the preset time range when the black screen or white screen occurs.

[0084] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: if the test result is a black screen or a white screen, determine the time when the black screen or white screen occurs; if the time when the black screen or white screen occurs exceeds a preset time threshold, restart the vehicle screen, and continue executing the test task queue after restarting.

[0085] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: after all test task queues have been completed, a test report is generated, wherein the test report includes the number of multiple test tasks, the number of test tasks that were successfully executed, the number of test tasks that resulted in a black screen or white screen, and the number of test tasks that resulted in a normal test.

[0086] Embodiments of the present invention also provide a computer program product, including a computer program. Optionally, in this embodiment, when the computer program is executed by a processor, it can: in response to a test instruction, project the image of the vehicle screen onto a preset display area; generate a queue of test tasks to be executed based on a preset coordinate document and a preset automated test case document, wherein the coordinate document includes the coordinates of a click operation, the coordinates of a long press operation, and the start and end coordinates of a swipe operation, and the automated test case document includes the test scenarios, operation steps, execution order, and waiting time of each of multiple test cases; execute multiple test tasks in the test task queue one by one, and simultaneously acquire pixel data within a preset monitoring area, wherein the monitoring area is located in the display area; and determine the test result of the currently executed test task based on the pixel data, wherein the test result includes a black screen phenomenon, a white screen phenomenon, or normal operation.

[0087] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0088] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0089] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0090] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0091] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

[0093] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for testing the black-and-white screen of an in-vehicle display, characterized in that, include: In response to the test command, the image from the vehicle screen is projected onto the preset display area; Based on a preset coordinate document and a preset automated test case document, a queue of test tasks to be executed is generated. The coordinate document includes the coordinates of click operations, long press operations, and the start and end coordinates of swipe operations. The automated test case document includes the test scenarios, operation steps, execution order, and waiting time for each of the multiple test cases. Multiple test tasks in the test task queue are executed one by one, and pixel data within a preset monitoring area is acquired, wherein the monitoring area is located in the display area; Based on the pixel data, the test result of the currently executed test task is determined, wherein the test result includes black screen phenomenon, white screen phenomenon, or normal.

2. The method according to claim 1, characterized in that, The test task queue includes multiple modes: sequential execution mode, random execution mode, cyclic execution mode, and specified execution mode. The sequential execution mode means that the multiple test tasks are executed in the order of the corresponding test case numbers. The random execution mode means that the multiple test tasks are executed in a random order. The cyclic execution mode means that the multiple test tasks are executed repeatedly. The specified execution mode means that one of the multiple test tasks is executed multiple times.

3. The method according to claim 1, characterized in that, Determining the test result of the currently executed test task based on the pixel data includes: When the pixel data includes red component data, blue component data, and green component data, calculate the average value of the red component data, the blue component data, and the green component data; If the average value is not greater than a first preset threshold, the test result is determined to be a black screen phenomenon; If the average value is not less than the second preset threshold, the test result is determined to be a white screen phenomenon; If the average value is greater than the first preset threshold and less than the second preset threshold, the test result is determined to be normal.

4. The method according to claim 1, characterized in that, Also includes: If the test result is a black screen or a white screen, obtain and record the test case number and name corresponding to the currently executed test task, the time when the black screen or white screen occurs, the screen recording segment of the monitoring area within the preset time range when the black screen or white screen occurs, and the pixel data.

5. The method according to claim 1, characterized in that, Also includes: If the test result is a black screen or a white screen, determine the time when the black screen or white screen occurred. If the black screen or white screen phenomenon lasts for more than a preset time threshold, the vehicle screen will be restarted, and the test task queue will continue to be executed after the restart.

6. The method according to any one of claims 1 to 5, characterized in that, Also includes: After all the test tasks in the queue have been completed, a test report is generated. The test report includes the number of the multiple test tasks, the number of test tasks that were successfully executed, the number of test tasks that resulted in a black screen or white screen, and the number of test tasks that resulted in a normal test.

7. A device for testing the black-and-white screen of an in-vehicle display, characterized in that, include: The projection module is used to project the image from the vehicle screen onto a preset display area in response to test commands; The generation module is used to generate a queue of test tasks to be executed based on a preset coordinate document and a preset automated test case document. The coordinate document includes the coordinates of click operations, long press operations, and the start and end coordinates of swipe operations. The automated test case document includes the test scenarios, operation steps, execution order, and waiting time of each of the multiple test cases. An execution module is used to execute multiple test tasks in the test task queue one by one, and at the same time, acquire pixel data within a preset monitoring area, wherein the monitoring area is located in the display area; The determination module is used to determine the test result of the currently executed test task based on the pixel data, wherein the test result includes black screen phenomenon, white screen phenomenon, or normal.

8. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored program, wherein, when the program is executed, it controls the device where the non-volatile storage medium is located to perform the black-and-white screen testing method for the vehicle screen according to any one of claims 1 to 6.

9. A computer device, characterized in that, include: Memory and processor The memory stores computer programs; The processor is configured to execute a computer program stored in the memory, wherein when the computer program is executed, the processor performs the black-and-white screen testing method for the vehicle screen according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the black-and-white screen testing method for the vehicle screen according to any one of claims 1 to 6.

Images