Test method and device of display screen, equipment and storage medium

Abstract

A method, apparatus, device, and storage medium for testing displays are disclosed. The method includes: determining multiple displays to be tested and display identifiers corresponding to each display; generating multiple initial injection events based on a preset event generation mechanism; determining the correspondence between the multiple initial injection events and the multiple display identifiers; binding each initial injection event to its corresponding display identifier based on the correspondence to obtain multiple final injection events; and executing the final injection events to test at least one display to be tested. The technical solution of this disclosure, by binding different initial injection events to their corresponding display identifiers to obtain multiple final injection events and executing the final injection events, can solve the problem that existing testing tools only support testing the main screen, thereby improving the system's test coverage.

Description

Technical Field

[0001] This disclosure relates to the field of automated testing, and more particularly to a method, apparatus, device, and storage medium for testing displays. Background Technology

[0002] With the gradual development of smart devices, most smart devices contain multiple display terminals or multiple virtual screens. Taking the smart cockpit as an example, a typical smart cockpit system may include a central control screen, a passenger entertainment screen, an instrument panel, a head-up display, and a rear entertainment screen. Consequently, multi-screen collaborative interaction has become a core capability of such smart device systems.

[0003] Therefore, effective automated testing of equipment systems is one of the key technical requirements for ensuring product quality. Currently, the most commonly used testing tools simulate user behavior by injecting a large number of random events into the system under test, thus achieving automated testing. However, this tool only supports testing the main screen; other screens in the system cannot receive test events, resulting in incomplete test coverage. Summary of the Invention

[0004] To address the aforementioned technical problems, this disclosure provides a method, apparatus, device, and storage medium for testing a display screen.

[0005] The first aspect of this disclosure provides a method for testing a display screen, comprising: determining a plurality of display screens to be tested, and display screen identifiers corresponding to each of the plurality of display screens to be tested; generating a plurality of initial injection events based on a preset event generation mechanism; determining the correspondence between the plurality of initial injection events and the plurality of display screen identifiers; binding each initial injection event to its corresponding display screen identifier based on the correspondence to obtain a plurality of final injection events; and executing the final injection events to test at least one display screen to be tested.

[0006] A second aspect of this disclosure provides a display screen testing apparatus, comprising: a display screen determination module for determining a plurality of display screens to be tested and display screen identifiers corresponding to each of the plurality of display screens to be tested; an initial event generation module for generating a plurality of initial injection events based on a preset event generation mechanism; a correspondence determination module for determining the correspondence between the plurality of initial injection events and the plurality of display screen identifiers; a final event determination module for binding each initial injection event to a corresponding display screen identifier based on the correspondence to obtain a plurality of final injection events; and a display screen testing module for executing the final injection events to test at least one display screen to be tested.

[0007] A third aspect of this disclosure provides a computer-readable storage medium storing a computer program for performing the test method for the display screen provided in the first aspect above.

[0008] A fourth aspect of this disclosure provides an electronic device comprising: a processor; a memory for storing processor-executable instructions; and a processor for reading executable instructions from the memory and executing the instructions to implement the test method for the display screen provided in the first aspect above.

[0009] A fifth aspect of this disclosure provides a computer program product that, when instructions in the computer program product are executed by a processor, performs the test method for the display screen provided in the first aspect above.

[0010] The display testing method disclosed herein determines multiple displays to be tested and their corresponding display identifiers; generates multiple initial injection events based on a preset event generation mechanism; determines the correspondence between the multiple initial injection events and the multiple display identifiers; binds each initial injection event to its corresponding display identifier based on the correspondence to obtain multiple final injection events; and executes the final injection events to test at least one display to be tested. This solves the problem that existing testing tools only support testing the main screen, thereby improving the system's test coverage. Attached Figure Description

[0011] Figure 1 A flowchart illustrating a testing method for a display screen provided as an exemplary embodiment of this disclosure.

[0012] Figure 2 A flowchart illustrating a testing method for a display screen provided as another exemplary embodiment of this disclosure.

[0013] Figure 3 A flowchart illustrating a testing method for a display screen provided as yet another exemplary embodiment of this disclosure.

[0014] Figure 4 A flowchart illustrating a testing method for a display screen provided as yet another exemplary embodiment of this disclosure.

[0015] Figure 5 A system block diagram of a test system for a display screen provided as an exemplary embodiment of this disclosure.

[0016] Figure 6 This is a schematic diagram of the structure of a test apparatus for a display screen provided in an exemplary embodiment of the present disclosure.

[0017] Figure 7A schematic diagram of the structure of a test apparatus for a display screen provided as another exemplary embodiment of this disclosure.

[0018] Figure 8 A schematic diagram of the structure of an electronic device provided for an exemplary embodiment of this disclosure. Detailed Implementation

[0019] To explain this disclosure, exemplary embodiments of the disclosure will now be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the disclosure, and not all of them. It should be understood that the disclosure is not limited to exemplary embodiments.

[0020] It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of this disclosure.

[0021] Application Overview Currently, the most commonly used system testing tools in related technologies have the following shortcomings: Main screen testing only: By default, the event injection of related system testing tools only works on the main screen. Other secondary screens in the system (such as the passenger screen, head-up display) or virtual screens dynamically created by the system cannot receive any test events, which makes this part of the logic unable to be effectively verified.

[0022] Unable to simulate concurrent multi-screen interaction: In actual user operations, concurrent or cross-screen interactions often occur on different displays. For example, the central control screen and the passenger screen may be operated simultaneously, or a window may be dragged from the main screen to the secondary screen. However, related system testing tools cannot synchronously generate events across display IDs (identifiers) or execute test actions concurrently on multiple screens.

[0023] To address the aforementioned issues, this disclosure provides a method for testing a display screen. The method involves identifying multiple display screens to be tested, and their respective display screen identifiers; generating multiple initial injection events based on a preset event generation mechanism; determining the correspondence between the initial injection events and the display screen identifiers; binding each initial injection event to its corresponding display screen identifier based on this correspondence to obtain multiple final injection events; and executing the final injection events to test at least one display screen. This method overcomes the limitation of existing testing tools that only support testing the main screen, thereby improving the system's test coverage.

[0024] Exemplary methods Figure 1 This is a flowchart illustrating a testing method for a display screen provided as an exemplary embodiment of the present disclosure. The method of this embodiment can be applied to electronic devices, such as... Figure 1As shown, the method includes steps S11-S15.

[0025] Step S11: Determine multiple displays to be tested, and the display identifiers corresponding to each of the multiple displays to be tested.

[0026] For example, the display screen to be tested in this embodiment includes, but is not limited to, physical display screens and virtual display screens. For instance, in a smart cockpit scenario, a physical display screen can be a central control screen, a passenger entertainment screen, an instrument panel, a head-up display (HUD), a rear entertainment screen, or other physical screens. A virtual display screen can be a split-screen window dynamically created by the system according to multi-tasking requirements, a floating window within an application, or a virtual display interface formed in a specific area through screen projection technology. Therefore, both physical and virtual display screens in the smart cockpit system can be used as the display screen to be tested in step S11. As another example, in a Mixed Reality (MR) device, a user's field of view may be divided into multiple functional virtual screens, which can be used to display navigation information, interactive menus, etc., respectively. Therefore, multiple functional virtual screens in the MR device can be used as the display screen to be tested in step S11.

[0027] In some examples, each display under test has a unique display identifier. This identifier can be a hardware device number or logical address assigned to the display by the system, or it can be a unique identifier used in the system framework to distinguish different display units. This identifier allows for accurate location of the corresponding display under test. For example, the device may store a list of display identifiers (Display ID list), which records the available display identifiers, with different display identifiers corresponding to different display under test.

[0028] Step S12: Generate multiple initial injection events based on the preset event generation mechanism.

[0029] For example, in this embodiment of the disclosure, multiple initial injection events can be generated based on a random event generation mechanism in related technologies. This random event generation mechanism can be a pseudo-random event generation logic built into the system. Its core is to generate a series of events simulating user operations (such as tapping the screen, pressing a button, or tracing a trackball) according to random event type, random event parameters, and random execution sequence. For instance, a standard input event can be generated using a method named MotionEvent.obtain, and this standard input event is the initial injection event.

[0030] It should be noted that the embodiments disclosed herein do not limit the specific implementation of the preset event generation mechanism. Those skilled in the art can select a specific event generation mechanism to generate multiple initial injected events based on factors such as the system type of the device. For example, the preset event generation mechanism under the Android system can be the original Monkey random event generation mechanism, and the preset event generation mechanism under the iOS system can be the XC Test custom random event generation mechanism, etc.

[0031] In some examples, the initial injection events include, but are not limited to, touch events, key events, trackball events, and rotation events. Touch events can simulate user actions such as clicking, swiping, long-pressing, and zooming on the screen; for example, generating a click event at specific coordinates on a virtual display to test interface responsiveness. Key events can simulate the pressing and releasing of physical or virtual keys; for example, testing the control function of steering wheel buttons on the passenger-side entertainment screen in a vehicle system. Trackball events are used to simulate trackball movement, suitable for some display interaction scenarios that support trackball control. Rotation events are used to simulate screen orientation switching to verify the content adaptation of the display under different display directions. For example, testing whether the displayed content changes accordingly as the screen rotates. Furthermore, the preset event generation mechanism can be configured according to testing needs, such as setting the event type ratio, trigger frequency, and operation area, thereby generating diverse initial injection events that conform to actual test scenarios.

[0032] Step S13: Determine the correspondence between multiple initial injection events and multiple display screen identifiers.

[0033] For example, a round-robin allocation method can be used. Suppose there are three displays to be tested, labeled Display A, Display B, and Display C, and six initial injection events E1 to E6 are generated. In the round-robin allocation method, E1 corresponds to Display A, E2 to Display B, E3 to Display C, E4 again to Display A, E5 to Display B, and E6 to Display C. This correspondence is suitable for scenarios where a relatively balanced number of test events is required for each display.

[0034] In some examples, a mapping can be established based on the association between event types and display functions. For instance, if the initial injected event simulates a button event simulating "adjusting the air conditioning temperature," this event is more likely to be associated with the central control screen, and therefore can be mapped to the central control screen's identifier. Similarly, if the initial injected event simulates a button event simulating "play / pause media," it can be mapped to the identifier of the passenger-side entertainment screen or the rear-seat entertainment screen. This approach requires pre-defining matching rules between event types and display functions, allowing events to be more targeted in testing specific functions of specific displays.

[0035] In some examples, a random assignment strategy can be introduced, but to ensure the controllability and reproducibility of the test, random assignment is usually combined with certain weights. For example, different weight values ​​can be set for different display identifiers, with displays with higher weights having a greater probability of being assigned to the initial injection event.

[0036] It should be noted that the present disclosure does not limit the method for determining the correspondence between multiple initial injection events and multiple display screen identifiers, and those skilled in the art can configure it according to actual usage needs.

[0037] Step S14: Based on the correspondence, bind each initial injection event to the corresponding display screen identifier to obtain multiple final injection events.

[0038] For example, in this embodiment of the present disclosure, after determining the correspondence between multiple initial injection events and multiple display screen identifiers through any one or more of the above methods, each initial injection event can be bound to the corresponding display screen identifier based on the correspondence to form the corresponding final injection event.

[0039] In some examples, the method named `setDisplayId` is used in the development / testing domain to specify the ID of the target display screen. Since the `setDisplayId` method is not publicly disclosed, it cannot be directly used by conventional SDKs (Software Development Kits). In a multi-screen environment, to accurately distribute the initial injection event to the corresponding display screen, this disclosure introduces a reflection mechanism. This mechanism allows runtime invocation and access to the `setDisplayId` method, thereby binding the initial injection event to the display screen identifier and obtaining multiple final injection events. Reflection refers to the program dynamically obtaining class structure information (such as fields and methods) at runtime and calling these members without explicit dependencies during the compilation phase. This technology overcomes the limitations of SDK toolkits, accessing undisclosed methods and properties within the system, thus enabling flexible control of system input events in testing tools.

[0040] In other words, reflection allows a program to dynamically obtain class information and invoke its methods at runtime. For initial injected events in the system, they typically contain display-related properties or methods. Although the `setDisplayId` method may not be explicitly stated in the publicly available API (Application Programming Interface) documentation, reflection can be used to locate this method and pass in the corresponding display identifier parameter. For example, for an initial touch event, a reference to its `setDisplayId` method can be obtained through reflection, and then the display identifier corresponding to that event can be passed as a parameter to complete the binding between the event and the corresponding display. After binding, each final injected event carries the corresponding display identifier, ensuring that the event is accurately sent to the corresponding display under test during execution.

[0041] Step S15: Execute the final injection event to test at least one display screen to be tested.

[0042] For example, during the execution of the final injection event, the system precisely routes the event to the corresponding display screen under test based on the display screen identifier carried by each final injection event. For instance, when the final injection event is bound to the identifier of the passenger entertainment screen, the event (such as a touch event simulating clicking the "next track" button) will be directly sent to the passenger entertainment screen, triggering the response logic of the corresponding application on that screen, while the main screen or other displays will not be affected by this event. Furthermore, by executing multiple final injection events, the performance of each display screen under test after receiving different types of events can be determined, such as whether the interface responds correctly, whether the function executes normally, and whether the data is updated accurately, thereby completing a comprehensive test of the display screen and its related system functions.

[0043] In some examples, embodiments of this disclosure can obtain a hidden instance of the InputManager class through reflection and call its injectInputEvent method to inject events for testing one or more displays to be tested. The InputManager class is primarily responsible for managing input events (touch, button, trackball, etc.) across the entire device, including core operations such as event reception, distribution, and injection. The injectInputEvent method is a core member method of the InputManager class, specifically designed to simulate user input events and inject them into the system, making the system believe that the user has actually interacted with the screen, buttons, etc. It is the core API for automating input events.

[0044] The display testing method provided in this disclosure involves determining multiple displays to be tested and their corresponding display identifiers; generating multiple initial injection events based on a preset event generation mechanism; determining the correspondence between the multiple initial injection events and the multiple display identifiers; binding each initial injection event to its corresponding display identifier based on the correspondence to obtain multiple final injection events; and executing the final injection events to test at least one display to be tested. This method solves the problem that existing testing tools only support testing the main screen, thereby improving the system's test coverage.

[0045] like Figure 2 As shown above, in the above Figure 1 Based on the illustrated embodiment, step S14 may include steps S141-S142.

[0046] Step S141: Determine the first target hiding method within the system framework corresponding to the display screen to be tested.

[0047] For example, the first target hiding method in step S141 is mainly used to specify a unique target display screen identifier (DisplayId) for operation, rendering, or testing behavior, and this first target hiding method is not publicly disclosed. For example, the first target hiding method can be the setDisplayId method.

[0048] In some examples, the `setDisplayId` method is responsible for setting the corresponding display identifier for the initial injected event (such as a touch event, button event, etc.), ensuring that the event can be accurately routed to the corresponding display. Since this method is not exposed in the publicly available SDK, it cannot be directly called in conventional development or testing processes. Therefore, in this embodiment, a reflection mechanism is used to call the first target hiding method to bind the initial injected event to the corresponding display identifier.

[0049] Step S142: Invoke the first target hiding method based on reflection mechanism to bind each initial injection event with the corresponding display screen identifier based on the correspondence relationship, so as to obtain multiple final injection events.

[0050] For example, since the first target hiding method is not publicly disclosed, it is not directly accessible. Therefore, in this embodiment, reflection is used to call the first target hiding method to bind the initial injection event with the corresponding display identifier based on the correspondence, thus obtaining the final injection event. In some examples, reflection can be used to obtain the hidden method setDisplayId in the MotionEvent class and call this method at runtime to write the corresponding display identifier into the initial injection event. The MotionEvent class is a core class in the system specifically used to describe user touch behavior. It records all key information such as the time, location, action type, and number of touch points, and is the foundation for handling touch interactions (such as clicks, swipes, and long presses).

[0051] For example, the initial injection event can be bound to the corresponding display identifier using the following procedure to obtain the final injection event: MotionEvent event = MotionEvent.obtain(downTime, eventTime, action,x, y, metaState); Method setDisplayId = MotionEvent.class.getMethod("setDisplayId",int.class); setDisplayId.invoke(event, targetDisplayId); The core of this program is to use Java reflection to set a display ID for a manually created MotionEvent object, thereby achieving dynamic binding of the Display ID. The first code snippet creates a touch event instance using the static method `MotionEvent.obtain`, generating a random initial injection event. The second code snippet uses reflection to obtain a method object named `setDisplayId` with an integer parameter from the MotionEvent class. The third code snippet executes the `setDisplayId` method, setting the `targetDisplayId` (the corresponding display ID) for the Event object created in the first code snippet.

[0052] The display testing method provided in this embodiment determines a first target hiding method within the system framework corresponding to the display to be tested; the first target hiding method is invoked based on a reflection mechanism to bind each initial injection event with the corresponding display identifier based on the correspondence relationship, thereby obtaining multiple final injection events; in this way, multiple virtual / physical displays can be automatically identified and operated in the system using a reflection mechanism, thereby injecting test events into each display.

[0053] like Figure 3 As shown above, in the above Figure 1 Based on the illustrated embodiment, step S15 may include steps S151a-S153a.

[0054] Step S151a: Determine the input management service within the system framework corresponding to the display screen to be tested.

[0055] For example, the input management service in step S151a is mainly used to manage input devices, receive underlying input signals, encapsulate input events, and distribute input events.

[0056] For example, this input management service could be an InputManager class. The InputManager class is primarily responsible for the unified management of all input events on the device, including touch, buttons, trackball, gestures, etc., and is the core hub connecting hardware input and application response. Internally, it maintains the input event receiving queue, distribution logic, and interaction mechanism with system services, and can convert external input signals into system-recognizable event objects and accurately transmit them to the target application or display screen.

[0057] Step S152a: Based on the reflection mechanism, obtain the second target hiding method included in the input management service.

[0058] For example, the second target hiding method in step S152a is mainly used to obtain a unique instance of the input management service and provide a globally unique access point. For instance, the second target hiding method could be the getInstance method, which is used to obtain a unique instance of the InputManager class.

[0059] Furthermore, the `getInstance` method is not publicly disclosed in the system's SDK tools. Therefore, in this embodiment, reflection is used to invoke this method to obtain an instance of the `InputManager` class. For example, the `Class` object of the `InputManager` class can be obtained through reflection, and then its `getDeclaredMethod` method can be called to obtain the `Method` object of the `getInstance` method. Then, the static method can be executed through the `invoke` method of the `Method` object to obtain the second target hidden method `getInstance`.

[0060] Step S153a: Obtain an instance of the input management service through the second target hiding method, and call the injection method in the input management service through the instance to execute the final injection event.

[0061] For example, after obtaining the second target hiding method (such as the getInstance method in the InputManager class) included in the input management service, it is necessary to obtain the hidden instance of the input management service through the second target hiding method, and then call the injection method (such as the injectInputEvent method) in the input management service through the hidden instance, so as to send the final injected event to the system and complete the test of the corresponding display screen.

[0062] In some examples, the `injectInputEvent` method of the `InputManager` class is the core method for performing event injection. This method receives the final injected event as a parameter and passes it to the system's event handling flow, allowing the event to be dispatched to the corresponding display screen under test according to the display screen identifier it carries. For example, after obtaining a hidden instance of the `InputManager` class through the `getInstance` method, the `injectInputEvent` method can be called through this hidden instance to inject the final injected event bound to the corresponding display screen identifier into the system. After receiving these events, the system routes the events to the appropriate display screen for processing based on the display screen identifier carried in the event, thereby achieving independent and accurate testing of multiple display screens under test.

[0063] For example, the following procedure can be used to obtain an instance of the input management service through a second target hiding method, and then use that instance to call the injection method in the input management service to execute the final injection event: Class<?> inputManagerClass = Class.forName("android.hardware.input.InputManager"); Method getInstance = inputManagerClass.getDeclaredMethod("getInstance"); Object inputManager = getInstance.invoke(null); Method injectInputEvent = inputManagerClass.getMethod("injectInputEvent", InputEvent.class, int.class); injectInputEvent.invoke(inputManager, event, 0); The core of this program is to bypass the access restrictions of the system's undocumented APIs through reflection. It first calls the `getInstance` static method of the `InputManager` class to obtain its singleton instance, and then uses this singleton instance to call the `injectInputEvent` method to inject the input event. This method directly operates on the system's input dispatch layer, allowing the injected event to be recognized and processed by the system in a manner completely consistent with real user operations. Specifically, the first code segment loads the `InputManager` class using its fully qualified class name. The second code segment obtains the `getInstance` static method of the `InputManager` class (since `InputManager` is a singleton, this method obtains a unique instance). The third code segment executes the `getInstance` method to obtain the singleton object of the `InputManager` class. The fourth code segment obtains the `injectInputEvent` method of the `InputManager` class, which is the core of the input event injection. The fifth code segment calls the `injectInputEvent` method to inject the custom input event into the system; the parameter 0 indicates asynchronous injection mode.

[0064] The display testing method provided in this embodiment determines the input management service within the system framework corresponding to the display to be tested; obtains the second target hiding method included in the input management service based on the reflection mechanism; obtains an instance of the input management service through the second target hiding method, and calls the injection method in the input management service through the instance to execute the final injection event; thus, it can automatically identify and operate multiple virtual / physical display screens by combining the reflection mechanism and the input management service, inject test events into each display screen, thereby comprehensively evaluating the system stability.

[0065] like Figure 4 As shown above, in the above Figure 1 Based on the illustrated embodiment, step S15 may include steps S151b-S152b.

[0066] Step S151b: Obtain the preset test strategy.

[0067] For example, the preset testing strategies include, but are not limited to, polling tests on multiple displays and concurrent tests on multiple displays. Polling tests involve sequentially executing injection events on each display under test in a preset order, switching to the next display only after completing the test on one display. This method ensures that each display receives independent and orderly testing, making it suitable for scenarios where the sequential nature of the testing process is critical. Concurrent tests involve simultaneously executing injection events on multiple displays under test, causing the testing processes of multiple displays to overlap in time. This more realistically simulates scenarios where multiple displays work simultaneously, effectively verifying the system's performance and stability during multi-screen concurrent processing. For example, concurrent tests can be used to verify scenarios such as simultaneous operation of the central control screen and the passenger side screen, or dragging a window from the main screen to the secondary screen.

[0068] It should be noted that the choice of testing strategy can be flexibly determined according to the actual testing objectives and scenarios. For example, polling test can be used when initially verifying the basic functions of each display screen, and concurrent test can be used when conducting system performance test. This disclosure does not limit this.

[0069] Step S152b: Based on the test strategy, execute the initial injection event included in the final injection event to test the display screen to be tested corresponding to the bound display screen identifier.

[0070] For example, after obtaining the preset test strategy, the test system schedules and executes the final injection events according to the strategy. If the test strategy is a polling test, the system will inject the initial injection events bound to each display screen identifier into the corresponding display screen in a preset display screen order, such as display screen A, display screen B, and display screen C. After injecting the event into display screen A and completing the corresponding response collection and analysis, the event injection for display screen B will be performed, and so on. During this process, the system will record the response time of each display screen to the event, whether the response result meets expectations, and whether there are any abnormal situations such as lag or no response. If the test strategy is a concurrent test, the system will create multiple threads or processes, each thread or process is responsible for injecting its corresponding initial injection event into a specific display screen under test. These injection operations are performed in parallel in time.

[0071] For example, when testing the central control screen and rear-seat entertainment screen of an in-vehicle system, the system can simultaneously inject navigation operation events into the central control screen and video playback control events into the rear-seat entertainment screen to simulate a real-world scenario where the driver and passengers operate different displays simultaneously. In this case, the test system needs to monitor the event injection process of multiple displays simultaneously to evaluate the system's resource allocation capabilities, event processing priorities, and overall stability under multi-task concurrency, such as whether there are issues like event loss, cumulative response delays, or interface rendering conflicts. By executing multiple injection events based on different test strategies, a comprehensive and in-depth test of the display's functionality and the system's overall performance can be conducted from multiple dimensions.

[0072] The display testing method provided in this embodiment obtains a preset testing strategy; based on the testing strategy, it executes the initial injection event included in the final injection event to test the display screen to be tested corresponding to the bound display screen identifier; thus, by executing multiple injection events based on different testing strategies, it is possible to conduct comprehensive and in-depth testing of the display screen's functions and the overall performance of the system from multiple dimensions, so as to comprehensively evaluate the system's performance.

[0073] In some embodiments, step S152b, executing the initial injection event included in the final injection event based on the test strategy to test the display screen to be tested corresponding to the bound display screen identifier, includes one of the following: executing multiple initial injection events included in the final injection event sequentially based on the test strategy to test the display screen to be tested corresponding to the bound display screen identifier; or executing multiple initial injection events included in the final injection event concurrently based on the test strategy to test the display screen to be tested corresponding to the bound display screen identifier.

[0074] For example, multiple initial injection events bound to display screen A can be determined from the final injection events. These events are then injected into display screen A sequentially according to a preset logical order (e.g., the order of clicks, swipes, inputs, etc.). After all test events for display screen A have been injected, events for display screen B are then processed, and the above process is repeated until all events for all displays have been executed. In this mode, the testing process for each display screen is relatively independent, facilitating precise tracking of each display screen's response to events.

[0075] In some examples, a multi-threaded or multi-process approach can be used to simultaneously initiate event injection processes for multiple displays under test. For instance, threads A and B can be created for display A and display B, respectively. Thread A is responsible for injecting at least one initial injection event bound to display A into display A, while thread B is responsible for injecting at least one initial injection event bound to display B into display B in parallel. The execution of these threads overlaps in time, realistically simulating scenarios where multiple users operate different displays simultaneously, thereby evaluating the stability and reliability of the system under multi-tasking loads.

[0076] Figure 5 A system block diagram of a test system for a display screen provided in this disclosure embodiment is shown below. Figure 5 As shown, the test system 50 includes: a display management module 51, a multi-screen event scheduler 52, an extended event injection module 53, a random event generator 54, and a log collection and analysis module 55.

[0077] The display management module 51 is mainly used to detect the currently existing display identifiers (Display IDs), including the display identifiers of the main screen, secondary screen, virtual screen, etc., and to maintain information such as the resolution and physical attributes of each screen.

[0078] The multi-screen event scheduler 52 is mainly used to schedule different initial injection events based on the list of currently available display screen identifiers, and can support polling / concurrent test modes.

[0079] The extended event injection module 53 is mainly used to customize the injectionInputEvent interface of the InputManager class and inject events into the specified display screen.

[0080] The random event generator 54 is primarily used to enhance support for generating events at the "DisplayId + coordinates" level based on a preset random event generation mechanism. It supports generating targeted test sequences through configuration parameters or dynamic strategies. For example, it can generate injection events containing "DisplayId + coordinates" based on the random event generation mechanism built into the system testing tools in related technologies; where DisplayId is the display screen identifier corresponding to the injection event, and coordinates are the coordinate positions of the injection event on the display screen.

[0081] The log collection and analysis module 55 is mainly used to trace the source of anomalies in multiple displays by associating the Display ID with system exception logs (such as application unresponsiveness, crashes, memory issues, etc.).

[0082] based on Figure 5 The present disclosure further provides a method for testing a display screen, comprising: (1) Start the test task: You can specify to test a single display screen or multiple display screens.

[0083] (2) Detect available display identifiers: Obtain the list of electronic device displays through the DisplayManager class.

[0084] For example, the DisplayManager class is a core system service class used to manage device display-related functions. It is mainly responsible for managing all display devices on the device (such as the main screen, external monitors, projection devices, etc.) and provides capabilities such as monitoring the status of display devices and obtaining display information. Furthermore, by calling the getDisplays method of the DisplayManager class, an array of all available display screen objects on the electronic device can be obtained. Each display screen object contains its unique display identifier (Display Id), resolution, display size, and key attribute information such as whether it is the main screen or an external screen.

[0085] (3) Initialize the multi-screen event scheduler: It supports concurrent parallel processing as well as sequential injection. Furthermore, it supports assigning weights to each injected event, which can be configured according to the user's actual strategy.

[0086] (4) Generate multi-screen random injection events: Based on the preset random event generation mechanism, the corresponding display screen is specified at the same time to generate event objects for each display screen.

[0087] (5) Inject events to each display screen.

[0088] Specifically, the above testing method can be implemented through the following steps: ① Constructing an event object: Standard input events are generated using system methods such as MotionEvent.obtain. At this point, the event object has not yet been bound to the corresponding display identifier (Display ID).

[0089] ② Dynamically bind Display ID: Use reflection to obtain the hidden method setDisplayId(int displayId) in the MotionEvent class, and call this method at runtime to write the corresponding display identifier into the event object.

[0090] For example, MotionEvent event = MotionEvent.obtain(downTime, eventTime, action,x, y, metaState); Method setDisplayId = MotionEvent.class.getMethod("setDisplayId",int.class); setDisplayId.invoke(event, targetDisplayId); It is understood that the interpretation of the above procedure has been explained in the example corresponding to step S142, and will not be repeated here.

[0091] ③ Unified event injection: Obtain a hidden instance of the InputManager class through reflection and call its injectInputEvent(InputEvent event, int mode) method to complete event injection.

[0092] For example, Class<?> inputManagerClass = Class.forName("android.hardware.input.InputManager"); Method getInstance = inputManagerClass.getDeclaredMethod("getInstance"); Object inputManager = getInstance.invoke(null); Method injectInputEvent = inputManagerClass.getMethod("injectInputEvent", InputEvent.class, int.class); injectInputEvent.invoke(inputManager, event, 0); It is understood that the interpretation of the above procedure has been explained in the example corresponding to step S153a, and will not be repeated here.

[0093] ④ Anomaly Monitoring and Log Collection: Monitor abnormal situations, such as application unresponsiveness or crashes. Also, monitor resources, such as memory and CPU (Central Processing Unit) usage.

[0094] ⑤ Generate test reports: Statistics on key indicators such as anomaly types and quantities, test duration, page coverage, and memory trends are compiled according to specific dimensions.

[0095] In some embodiments, the software implementation of the testing method provided in this disclosure can be configured as follows.

[0096] Operating system platform: Based on Android 9.0 and above, and requires support for extended calling permissions of DisplayManager, InputManager and WindowManagerGlobal services.

[0097] Implementation languages: Primarily developed using Java and Kotlin, with Shell and Python scripts used as needed to assist in device scheduling and data acquisition.

[0098] Development environment: It can be compiled using the source code environment of open source projects, or it can be run on the test device in the form of App (Application) or jar (Java Archive).

[0099] It should be noted that the above software implementation is only an example, and those skilled in the art can make corresponding settings and specific implementations according to the actual situation.

[0100] As can be seen, this embodiment of the disclosure can dynamically set the corresponding display identifier for the event object using reflection and the setDisplayId method, and then obtain an instance of the InputManage class through reflection and the getInstance method. Because the InputManager class is a system-level service and cannot be directly accessed by ordinary applications, it is necessary to obtain its singleton instance through reflection in order to call the injectInputEvent method to inject test events.

[0101] Thus, the display testing method provided in this disclosure can achieve precise routing of cross-screen input events. This method overcomes the limitation of existing system testing tools that only support main screen event injection, achieving consistency and scalability of event scheduling in multi-screen environments. Simultaneously, by combining reflection mechanisms with the InputManager class, the controllability and stability of input events at the system level are guaranteed, meeting the automated stability testing needs of complex scenarios. These complex scenarios include, but are not limited to: in-vehicle multi-screen scenarios, AR (Augmented Reality) / VR (Virtual Reality) interaction scenarios, and multi-task split-screen scenarios.

[0102] Exemplary device Figure 6A testing apparatus for a display screen provided in this disclosure embodiment, such as Figure 6 As shown, the testing device 60 for the display screen includes a display screen determination module 61, an initial event generation module 62, a correspondence determination module 63, a final event determination module 64, and a display screen testing module 65.

[0103] The display screen determination module 61 is used to determine multiple display screens to be tested, and the display screen identifiers corresponding to each of the multiple display screens to be tested; The initial event generation module 62 is used to generate multiple initial injection events based on a preset event generation mechanism; The correspondence determination module 63 is used to determine the correspondence between multiple initial injection events and multiple display screen identifiers; The final event determination module 64 is used to bind each initial injection event to the corresponding display screen identifier based on the correspondence relationship, so as to obtain multiple final injection events; The display test module 65 is used to execute the final injection event to test at least one display screen to be tested.

[0104] In some embodiments, such as Figure 7 As shown, the final event determination module 64 includes a first method determination unit 641 and a final event determination unit 642.

[0105] The first method determination unit 641 is used to determine the first target hiding method within the system framework corresponding to the display screen to be tested. The final event determination unit 642 is used to call the first target hiding method based on the reflection mechanism, so as to bind each initial injection event with the corresponding display screen identifier based on the correspondence relationship, thereby obtaining multiple final injection events.

[0106] In some embodiments, the display testing module 65 is specifically used to determine the input management service within the system framework corresponding to the display screen to be tested; obtain the second target hiding method included in the input management service based on the reflection mechanism; obtain an instance of the input management service through the second target hiding method, and call the injection method in the input management service through the instance to execute the final injection event.

[0107] In some embodiments, the display testing module 65 is specifically used to obtain a preset testing strategy; based on the testing strategy, execute the initial injection event included in the final injection event to test the display screen to be tested corresponding to the bound display screen identifier.

[0108] In some embodiments, the display testing module 65 is specifically used to obtain a preset testing strategy; based on the testing strategy, sequentially execute multiple final injection events including initial injection events to test the display screen to be tested corresponding to the bound display screen identifier; or, based on the testing strategy, concurrently execute multiple final injection events including initial injection events to test the display screen to be tested corresponding to the bound display screen identifier.

[0109] In some embodiments, the display screen to be tested includes at least: a physical display screen and a virtual display screen.

[0110] In some embodiments, the initial injection event includes at least: touch event, button event, trackball event, and rotation event.

[0111] The beneficial technical effects of the above-described exemplary display testing apparatus 60 can be found in the corresponding beneficial technical effects of the exemplary method section above, and will not be repeated here.

[0112] Exemplary electronic devices Figure 8 This is a structural diagram of an electronic device 80 provided in an embodiment of the present disclosure. The electronic device 80 includes at least one processor 81 and a memory 82.

[0113] The processor 81 may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 80 to perform desired functions.

[0114] The memory 82 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 81 may execute one or more computer program instructions to implement the testing methods and / or other desired functions of the display screens of the various embodiments of this disclosure described above.

[0115] In one example, the electronic device 80 may also include an input device 83 and an output device 84, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0116] The input device 83 may also include, for example, a keyboard, a mouse, etc.

[0117] The output device 84 can output various information to the outside, including, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0118] Of course, for the sake of simplicity, Figure 8 Only some of the components of the electronic device 80 relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device 80 may include any other suitable components depending on the specific application.

[0119] Exemplary computer program products and computer-readable storage media In addition to the methods and apparatus described above, embodiments of this disclosure may also provide a computer program product, including computer program instructions that, when executed by a processor, cause the processor to perform the steps in the display testing methods of various embodiments of this disclosure described in the "Exemplary Methods" section above.

[0120] Computer program products can be written in any combination of one or more programming languages ​​to perform the operations of embodiments of this disclosure. These programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0121] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the steps in the testing methods for the display screens of various embodiments of this disclosure described in the "Exemplary Methods" section above.

[0122] Computer-readable storage media may take the form of any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may include, but is not limited to, systems, apparatuses, or devices that are electrical, magnetic, optical, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0123] The basic principles of this disclosure have been described above with reference to specific embodiments. However, the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0124] Various modifications and variations can be made to this disclosure without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this disclosure and their equivalents, this disclosure is also intended to include such modifications and variations.

Claims

1. A method for testing a display screen, comprising: Identify multiple displays to be tested, and the display identifier corresponding to each of the multiple displays to be tested; Based on a preset event generation mechanism, multiple initial injection events are generated; Determine the correspondence between the plurality of initial injection events and the plurality of display screen identifiers; Based on the aforementioned correspondence, each initial injection event is bound to the corresponding display screen identifier to obtain multiple final injection events; The final injection event is executed to test at least one of the displays to be tested.

2. The method according to claim 1, wherein, Based on the correspondence, each initial injection event is bound to the corresponding display screen identifier to obtain multiple final injection events, including: Determine the first target hiding method within the system framework corresponding to the display screen under test; The first target hiding method is invoked based on the reflection mechanism to bind each initial injection event with the corresponding display screen identifier based on the correspondence, thereby obtaining multiple final injection events.

3. The method according to claim 1, wherein, The execution of the final injection event includes: Determine the input management service within the system framework corresponding to the display screen under test; Based on the reflection mechanism, the second target hiding method included in the input management service is obtained; An instance of the input management service is obtained through the second target hiding method, and the injection method in the input management service is called through the instance to execute the final injection event.

4. The method according to claim 1, wherein, Executing the final injection event to test at least one of the displays under test includes: Obtain the preset test strategy; Based on the test strategy, the initial injection event included in the final injection event is executed to test the display screen to be tested corresponding to the bound display screen identifier.

5. The method according to claim 4, wherein, The step of executing the initial injection event, which includes the final injection event, based on the test strategy to test the display screen to be tested corresponding to the bound display screen identifier includes one of the following: Based on the test strategy, multiple initial injection events included in the final injection events are executed sequentially to test the display screen to be tested corresponding to the bound display screen identifier; Based on the test strategy, multiple initial injection events, including the final injection events, are executed concurrently to test the display screen to be tested corresponding to the bound display screen identifier.

6. The method according to any one of claims 1-5, wherein, The display screen to be tested includes at least: a physical display screen and a virtual display screen.

7. The method according to any one of claims 1-5, wherein, The initial injection events include at least: touch events, button events, trackball events, and rotation events.

8. A testing device for a display screen, comprising: The display screen determination module is used to determine multiple display screens to be tested, and the display screen identifier corresponding to each of the multiple display screens to be tested; The initial event generation module is used to generate multiple initial injection events based on a preset event generation mechanism. A correspondence determination module is used to determine the correspondence between the plurality of initial injection events and the plurality of display screen identifiers; The final event determination module is used to bind each initial injection event to the corresponding display screen identifier based on the correspondence relationship, thereby obtaining multiple final injection events; A display testing module is used to execute the final injection event to test at least one of the display screens under test.

9. A computer-readable storage medium storing a computer program for performing the testing method for the display screen according to any one of claims 1-7.

10. An electronic device, the electronic device comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory and execute the instructions to implement the test method for the display screen according to any one of claims 1-7.

Images