Touch interface test method and device of equipment, equipment and storage medium

Abstract

The invention provides a touch interface testing method and device of equipment, the equipment, a computer program product and a computer readable storage medium. The method comprises the following steps: creating virtual equipment of to-be-tested physical equipment, and intercepting an actual touch event of the to-be-tested physical equipment; analyzing the operation sequence file to obtain first position parameters and first time intervals of the plurality of first touch operations; packaging the first position parameter of each first touch operation into a coordinate event data packet; and based on each coordinate event data packet and the first time interval, calling a virtual device to simulate the to-be-tested physical device to perform a touch interface test. By means of the method and device, high-precision and repeatable automatic testing of the touch interface can be achieved in the environment of isolating physical interference, and the testing efficiency and reliability are improved.

Description

Testing methods, apparatus, equipment and storage media for the touch interface of devices Technical Field

[0001] This application relates to automated testing technology, and more particularly to a method, apparatus, device, and storage medium for testing the touch interface of a device. Background Technology

[0002] Touch interface testing is a crucial step in verifying the functionality, performance, and reliability of the graphical user interface (GUI) on devices equipped with touch interfaces. The core of touch interface testing lies in simulating user touch behavior to verify whether the device and application respond as expected under various operations. This type of testing is widely used in scenarios requiring high stability and reliability, such as conducting long-term aging tests on industrial control panels and in-vehicle infotainment terminals.

[0003] Currently, this type of testing is mainly conducted manually, where testers repeatedly perform a series of preset touch operations on the touch interface. However, during manual testing, the testers' operations are easily affected by subjective factors. For example, the position of each click may slightly deviate, and the time intervals between operations are difficult to maintain precisely. This inconsistency not only reduces testing efficiency but, more seriously, may lead to a lack of stability and reproducibility in the test results, thus failing to effectively guarantee product quality. Summary of the Invention

[0004] This application provides a method, apparatus, computer-readable storage medium, and computer program product for testing the touch interface of a device. These methods enable high-precision, repeatable, and automated testing of the touch interface in an environment isolated from physical interference, thereby improving testing efficiency and reliability.

[0005] The technical solution of this application embodiment is implemented as follows: This application embodiment provides a method for testing the touch interface of a device. The method includes: creating a virtual device for the physical device to be tested and intercepting the actual touch events of the physical device to be tested; parsing an operation sequence file to obtain first position parameters and first time intervals of multiple first touch operations; encapsulating the first position parameters of each first touch operation into a coordinate event data packet; and calling the virtual device to simulate the physical device to be tested for touch interface testing based on each coordinate event data packet and the first time interval.

[0006] This application provides a device for testing the touch interface of a device, comprising: a creation module for creating a virtual device of a physical device to be tested and intercepting actual touch events of the physical device to be tested; a parsing module for parsing an operation sequence file to obtain first position parameters and first time intervals of multiple first touch operations; an encapsulation module for encapsulating the first position parameters of each first touch operation into a coordinate event data packet; and a testing module for calling the virtual device to simulate the physical device to be tested for touch interface testing based on each coordinate event data packet and the first time interval.

[0007] This application provides an electronic device, which includes: a memory for storing computer-executable instructions or computer programs; and a processor for executing the computer-executable instructions or computer programs stored in the memory to implement the method provided in this application.

[0008] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions, which, when executed by a processor, implements a touch interface testing method for a device provided in this application.

[0009] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement a touch interface testing method for a device provided in this application.

[0010] The embodiments of this application have the following beneficial effects: By parsing a preset operation sequence file to obtain the precise first position parameters and first time interval defined therein, and based on this, calling a virtual device to simulate touch, it ensures that the execution position and timing of the touch operation remain strictly consistent in each test, improving the reproducibility and consistency of the test results. Simultaneously, by creating a virtual device to execute the test and intercepting the actual touch events of the physical device under test, this embodiment of the application effectively isolates the test input from the external physical operation, constructing a clean and undisturbed execution environment for touch interface testing, ensuring the effectiveness and reliability of the testing process. Attached Figure Description

[0011] Figure 1 is a schematic diagram of the application mode of the touch interface testing method for a device provided in an embodiment of this application; Figure 2 is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 3A is a schematic diagram of the first process of a touch interface testing method for a device provided in an embodiment of this application; Figure 3B is a schematic diagram of the second process of a touch interface testing method for a device provided in an embodiment of this application; Figure 3C is a schematic diagram of the third process of a touch interface testing method for a device provided in an embodiment of this application; Figure 3D is a schematic diagram of the fourth process of a touch interface testing method for a device provided in an embodiment of this application; Figure 3E is a schematic diagram of the fifth process of a touch interface testing method for a device provided in an embodiment of this application; Figure 4 is a schematic diagram of the overall architecture of the automated touch testing method provided in an embodiment of this application; Figure 5 is a schematic diagram of the workflow of the touch execution service in an embedded device provided in an embodiment of this application.

[0012] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0015] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0016] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0017] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0018] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0019] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0020] 1) JavaScript Object Notation (JSON): A lightweight data-interchange format, JSON is based on a subset of ECMAScript (a scripting language specification defined by the European Computer Association). It uses a completely language-independent text format to store and represent data. JSON has a clear hierarchical structure, is easy for humans to read and write, and is also easy for machines to parse and generate. An application can use a JSON file to store its initial configuration settings. For example, a display device configuration file named config.json might contain the following: {display:{resolution:1920x1080,brightness:85,fullscreen:true}}. This structure allows the application to easily parse and apply settings such as screen resolution, brightness level, and window mode at startup.

[0021] 2) Secure Copy Protocol (SCP): A protocol for secure file transfer over a network. SCP is based on the Secure Shell (SSH) protocol to provide authentication and encryption during data transfer, thereby ensuring the confidentiality and integrity of files transferred between a local host and a remote host or between two remote hosts.

[0022] 3) Secure Shell (SSH): An encrypted network protocol used to securely execute network services over insecure networks. Its main functions are remote login and command execution on remote hosts. This protocol prevents eavesdropping and man-in-the-middle attacks by fully encrypting communication between the client and server.

[0023] 4) User Interface (UI): The medium through which humans interact and exchange information with computers or machines. The user interface includes everything that the user can see and operate. In a graphical environment, it typically encompasses visual elements on the screen such as windows, buttons, text, and menus, as well as the response mechanisms by which the user interacts with the user interface through input devices (such as touchscreens and mice).

[0024] 5) uinput subsystem: An input subsystem module in the Linux kernel, hereinafter referred to as uinput. The uinput subsystem allows user-space programs to create and manage virtual input devices. Through uinput, programs can directly inject input events into the kernel's input core, thereby simulating the behavior of physical input devices (such as keyboards, mice, or touchscreens) at the software level. For example, an application that allows a smartphone to act as a computer remote control can utilize the uinput subsystem. A companion program running on the computer can create a virtual keyboard and mouse through uinput. When the user presses a key on the phone screen, this information is sent to the computer, and the program on the computer then injects the corresponding key event into the kernel through the virtual keyboard, thereby enabling control of other applications on the computer.

[0025] 6) EVIOCGRAB: An I / O (Input / Output) control command in the Linux Input Event Subsystem. When a process sends this command to an open input device file descriptor, that process exclusively grabs the device. Afterward, all input events generated by that physical device will only be delivered to this grabbing process, and no other application in the system will be able to receive events from that device.

[0026] 7) Process nice value: A parameter used in Linux systems to adjust process scheduling priority. The nice value ranges from -20 to +19, where -20 represents the highest priority and +19 represents the lowest priority. The higher a process's nice value, the lower its priority when competing for CPU resources, making it more likely to relinquish CPU time.

[0027] 8) Transmission Control Protocol / Internet Protocol (TCP / IP): A standardized suite of protocols for computer network communication, serving as the core communication architecture for the Internet and most local area networks. Its main function is to define the rules for data transmission within the network, enabling cross-network data encapsulation, routing, and delivery between different devices. Through a layered design (such as the application layer, transport layer, and network layer), this protocol suite breaks down the complex communication process into independent modules, ensuring the reliability, universality, and scalability of data transmission.

[0028] 9) The ioctl function: In Unix / Linux systems, this is a system call function used for device input / output control, and it belongs to the core interface for managing I / O channels. The ioctl function allows user programs to interact with device drivers through command parameters and perform special operations that cannot be completed through standard file operations (such as read / write).

[0029] In related technologies, the mainstream approach to verifying the stability and reliability of a device's touch interface typically relies on manual testing. Specifically, testers repeatedly execute preset touch operation sequences, such as continuous clicking and swiping, on the device screen for extended periods to simulate real and demanding usage scenarios, thereby evaluating the device's performance under continuous operation.

[0030] This manual testing model has significant limitations. First, testers' operations are susceptible to subjective factors. For example, the physical location of each click may slightly deviate, and the time interval between operations is difficult to maintain precisely. This inconsistency directly leads to a lack of stability in the execution of test cases, thus affecting the reproducibility and reliability of test results. Second, for aging tests that need to be executed continuously for tens or even hundreds of hours, relying entirely on manual methods is not only costly and inefficient, but also makes it difficult to guarantee the consistency of operational standards throughout the entire testing cycle. Furthermore, it is difficult to completely avoid accidental interference from the external physical environment during the testing process, threatening the purity of the test data.

[0031] Therefore, there is a need in related technologies for an automated touch interface testing method that can replace manual testing and provide high-precision, highly reproducible test results, in order to solve the problems of poor accuracy, low efficiency, and unreliable results caused by manual testing.

[0032] This application provides a method, apparatus, computer-readable storage medium, and computer program product for testing the touch interface of a device. It solves the problems of resource contention and operational interference of automated testing on the main application of the device while ensuring testing accuracy and repeatability. The following describes exemplary applications of the electronic devices provided in this application. These devices can be implemented as various types of terminals such as laptops, tablets, desktop computers, set-top boxes, smartphones, smart speakers, smartwatches, smart TVs, and in-vehicle terminals. Exemplary applications when the device is implemented as a terminal will be described below.

[0033] Referring to Figure 1, Figure 1 is a schematic diagram of the application mode of the touch interface testing method of the device provided in the embodiment of this application. Figure 1 shows a distributed testing scenario. In order to realize the touch interface testing application of the supporting device, the terminal device 400-2 serves as the test master terminal, which connects to and controls another target terminal device 400-1, which is the device under test, through the network 300. The network 300 can be a wide area network or a local area network, or a combination of the two.

[0034] Terminal device 400-2 is used to create and manage test tasks, acquire touch operation events to generate an operation sequence file containing raw position parameters and raw time parameters, and send this file and execution instructions to terminal device 400-1 via network 300. Simultaneously, terminal device 400-2 can also receive and store test reports returned by terminal device 400-1 for user review.

[0035] Terminal device 400-1 is the physical device to be tested and serves as the execution carrier for touch interface testing. It receives instructions from terminal device 400-2 and executes methods within its own operating system environment to create virtual devices, map position parameters, encapsulate input events, and inject the encapsulated input events into the virtual devices to complete the entire automated testing process.

[0036] Referring to Figure 2, which is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, the electronic device can be a terminal 400, such as terminal device 400-1 in Figure 1. The terminal 400 shown in Figure 2 includes at least one processor 410, a memory 450, at least one network interface 420, and a user interface 430. The various components in the terminal 400 are coupled together via a bus system 440. It is understood that the bus system 440 is used to implement communication between these components. In addition to a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for clarity, all buses are labeled as bus system 440 in Figure 2.

[0037] Processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0038] User interface 430 includes one or more output devices 431 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0039] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 450 may optionally include one or more storage devices physically located away from the processor 410.

[0040] The memory 450 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 450 described in this application embodiment is intended to include any suitable type of memory.

[0041] In some embodiments, memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0042] Operating system 451 includes system programs for handling various basic system services and performing hardware-related tasks, such as framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks; network communication module 452 for reaching other electronic devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including: Bluetooth, WiFi, and Universal Serial Bus (USB); presentation module 453 for enabling the presentation of information (e.g., user interface for operating peripheral devices and displaying content and information) via one or more output devices 431 associated with user interface 430 (e.g., display screen, speaker, etc.); input processing module 454 for detecting and translating one or more user inputs or interactions from one or more input devices 432.

[0043] In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2 shows a touch interface testing apparatus 455 for a device stored in memory 450. This apparatus can be software in the form of programs and plugins, including the following software modules: a creation module 4551, a parsing module 4552, an encapsulation module 4553, and a testing module 4554. These modules are logically related and can therefore be arbitrarily combined or further split according to their implemented functions. The functions of each module will be described below.

[0044] In other embodiments, the apparatus provided in this application can be implemented in hardware. As an example, the apparatus provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the touch interface testing method of the apparatus provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0045] The following will describe the touch interface testing method of the device provided in the embodiments of this application, taking the terminal device as the execution subject, with exemplary applications and implementations of the terminal provided in the embodiments of this application.

[0046] Referring to Figure 3A, which is a first flowchart of the touch interface testing method of the device provided in the embodiment of this application, the steps shown in Figure 3A will be described in conjunction with the steps shown in Figure 3A.

[0047] In step 101, a virtual device of the physical device to be tested is created, and the actual touch events of the physical device to be tested are intercepted.

[0048] For example, the physical device under test is the target hardware entity of this automated test, such as an industrial control panel; a virtual device refers to a hardware device simulated by software in the operating system, specifically a simulated touch screen. A virtual device can send touch events just like real hardware. Interception is a mechanism that exclusively obtains access to a device. It refers to capturing all input events generated by the physical device through specific calls, ensuring that these events are only received by the test program, thereby avoiding interference with the upper-level graphical interface.

[0049] For example, creating a virtual device for the physical device under test can be achieved by the test program calling a specific interface provided by the operating system (such as the uinput subsystem of Linux) to register and create a virtual input device node with the same functionality as the physical touch screen at the software level; interception can be achieved by the test program opening and locking the device file representing the real physical touch screen, obtaining exclusive read rights to the events of the device file, so that all input data streams from the physical touch screen are redirected to the test program and are not distributed.

[0050] For example, on the physical device under test (typically a Linux operating system), the test execution program utilizes the uinput subsystem interface provided by the kernel to register and create a virtual input device (such as a virtual touchscreen) in user space. Simultaneously, the program opens the device file representing the physical touchscreen and sends the EVIOCGRABI / O control command to that device file to obtain exclusive access to the physical device. The industrial control panel under test runs a Linux system, and the device node corresponding to its physical touchscreen is / dev / input / event0. After the test program starts, it calls the uinput-related functions and successfully creates a new device node / dev / input / event1 as the virtual touchscreen. Subsequently, the program opens / dev / input / event0 and uses the ioctl function to send the EVIOCGRAB command to / dev / input / event0. After this, any event data from touch operations on the physical surface of the industrial control panel is only received by the test program and is not passed to the upper-level graphical interface program.

[0051] In this embodiment, events are injected by creating virtual devices, and external interference is eliminated by intercepting physical events. This ensures that the input to the testing process comes entirely from a preset operation sequence, thereby guaranteeing the stability and reliability of the test. This achieves the effect of building a clean and controlled execution environment for automated testing.

[0052] In step 102, the operation sequence file is parsed to obtain the first position parameters and first time intervals of multiple first touch operations.

[0053] For example, the operation sequence file is a pre-edited script file that records all the touch operation instructions that need to be executed for automated testing; the first position parameter refers to the precise screen coordinates (such as X and Y values) defined in the operation sequence file for each touch operation; and the first time interval is the delay time defined in the file, which is how long to wait before executing the next operation after the current operation is completed.

[0054] In some embodiments, referring to FIG3B, FIG3B is a second flowchart of a device touch interface testing method provided in an embodiment of the present application. Step 102 shown in FIG3A can be implemented by steps 1021 to 1023, which will be described in detail below.

[0055] In step 1021, the operation sequence file is parsed to obtain touch operation information of multiple first touch operations.

[0056] Here, the touch operation information includes the original position parameters and the original time parameters.

[0057] For example, parsing a sequence of operation files is a structured data extraction process. For instance, given a JSON file containing [{x:120,y:340,interval:1500},{x:560,y:800,interval:2000}], each object is read sequentially, and the x and y field values ​​of each object are extracted as raw position parameters, while the interval (time interval) field value is extracted as a raw time parameter. These parameter combinations form the raw data foundation for subsequent steps involving coordinate transformation and time control.

[0058] In step 1022, the original time parameter is determined as the first time interval of the first touch operation.

[0059] For example, determining the raw time parameter as the first time interval of the first touch operation is a direct assignment process, that is, adopting the raw time value read from the file as the delay interval in the test execution without modification.

[0060] For example, after parsing the raw time parameter in step 1021, this value is assigned to the first time interval variable of the current touch operation. For instance, for the parsed raw time parameter 1500, the first time interval to wait after the current operation is completed is determined to be 1500 milliseconds. The test execution engine will use this value to precisely control the rhythm between two touch operations, ensuring consistency with the intention during recording.

[0061] In step 1023, the original position parameters are subjected to coordinate mapping processing to obtain the first position parameters of the first touch operation.

[0062] For example, this approach aims to address compatibility issues between test scripts and devices with screens of different resolutions by using mathematical conversion to transform coordinates based on the source device's resolution into equivalent coordinates suitable for the current device under test.

[0063] The following example, using actual data, illustrates the coordinate mapping process, which includes the following steps: First, obtain the resolution of the source interface during script recording (e.g., 1920x1080). Then, obtain the screen resolution of the physical device under test (e.g., 800x480). Next, calculate the scaling ratios for the X and Y axes: Scale_X = 800 / 1920, Scale_Y = 480 / 1080. Finally, multiply the parsed original position parameters by the scaling ratios. For example, for the original position parameters (960, 540), the first position parameter obtained after mapping is (960*Scale_X, 540*Scale_Y) = (400, 240). Thus, a click operation originally at the center point of a 1920x1080 screen can be accurately mapped to the center point of an 800x480 screen.

[0064] In some embodiments, step 1023 shown in FIG3B can be implemented in the following manner: obtaining the source interface size and the screen resolution of the physical device under test, wherein the source interface size is the size of the interface corresponding to the coordinate system of the original position parameter; calculating the coordinate scaling ratio based on the source interface size and the screen resolution; and converting the original position parameter into a first position parameter based on the coordinate scaling ratio.

[0065] For example, by establishing a size ratio between the recording interface and the test interface, the coordinate points are proportionally converted, thus ensuring that the relative position of touch operations remains consistent across different devices. For instance, the test program reads the source interface dimensions from the metadata of the operation sequence file; for example, the source interface dimensions are width SrcWidth = 1920 and height SrcHeight = 1080. Simultaneously, by calling the application programming interface (API) of the physical device under test, the program obtains the current screen resolution of the physical device under test; for example, the screen resolution is width TgtWidth = 800 and height TgtHeight = 480. Next, based on these two sets of size data, the program calculates the coordinate scaling ratios in the horizontal and vertical directions, respectively. The calculation formulas are: Scale_X = TgtWidth / SrcWidth = 800 / 1920; Scale_Y = TgtHeight / SrcHeight = 480 / 1080. Finally, the program multiplies the parsed original position parameters (e.g., (960, 540)) by the calculated coordinate scaling ratios to obtain the final first position parameters. The calculation process is as follows: NewX = 960 * Scale_X = 400; NewY = 540 * Scale_Y = 240. Therefore, the first positional parameter after transformation is (400, 240).

[0066] In this embodiment, the recording of absolute coordinates is separated from the execution of relative positions by explicitly executing the mapping process of obtaining size, calculating scale, and transforming coordinates step by step. This approach frees the operation script from being tied to a specific screen resolution, allowing a single recording script to automatically adapt to devices of various sizes. This greatly improves the reusability and maintainability of test cases and reduces the cost and complexity of automated testing in multi-device environments.

[0067] In this embodiment, by dividing file parsing into three independent steps—extracting raw values, determining time, and mapping coordinates—the processing of test script data becomes clearer and more modular. In particular, the introduction of coordinate mapping processing greatly enhances the portability and reusability of the test scripts, allowing a single recorded script to run on devices with various screen sizes without modification, significantly improving the efficiency and flexibility of automated testing.

[0068] Referring again to Figure 3A, in step 103, the first position parameter of each first touch operation is encapsulated into a coordinate event data packet.

[0069] This section describes the process of converting the first position parameters obtained through coordinate mapping into a standardized data structure that conforms to the specifications of the underlying input submodule, in preparation for subsequent event injection.

[0070] In some embodiments, referring to FIG3C, FIG3C is a third flowchart of a device touch interface testing method provided in an embodiment of the present application. Step 103 shown in FIG3A can be implemented by steps 1031 to 1034, which will be described in detail below.

[0071] In step 1031, the following processing is performed on the first position parameter of each first touch operation: the first position parameter is parsed to obtain the horizontal coordinate value and vertical coordinate value of the first touch operation.

[0072] Here, the independent horizontal and vertical coordinate components are separated from an integrated position parameter.

[0073] For example, the first position parameter obtained in step 1023 is a tuple containing two elements, such as (400, 240). The program accesses the first element of the tuple as the horizontal coordinate value 400 and the second element as the vertical coordinate value 240.

[0074] In step 1032, the click state parameter corresponding to the first touch operation is determined, wherein when the click state parameter is a first value, it indicates that the touch is released, and when the click state parameter is a second value, it indicates that the touch is pressed.

[0075] Here, the touch operation is given behavioral attributes, which clarify whether the event is the action of pressing the finger on the screen or the action of lifting the finger off the screen.

[0076] For example, based on the operation type definition in the operation sequence file, such as a click operation, the program determines that two states need to be generated: pressed and released. In the Linux input event framework, a click state parameter of 1 indicates a touch press, and a click state parameter of 0 indicates a touch release. Therefore, for a click operation, the program first determines a click state parameter of 1, and then determines a click state parameter of 0, to simulate a complete touch action.

[0077] In step 1033, the horizontal coordinate values, vertical coordinate values, and click status parameters are combined into an input event sequence.

[0078] Here, the scattered coordinates and status information are arranged in the order and format specified by the input sub-module to form a logically continuous event report.

[0079] For example, to simulate a touch press operation, the test program generates multiple basic input events sequentially. First, it generates an event of type absolute displacement, with a horizontal coordinate and a value of 400; then it generates another event of type absolute displacement, with a vertical coordinate and a value of 240; next, it generates a button event, with a touch code and a value of 1; finally, it generates a synchronization event. These four events together constitute a logically complete sequence of input events.

[0080] In step 1034, the input time series is encapsulated into a coordinate event data packet.

[0081] Here, the logical sequence of events in the previous process is converted into a binary data structure that the core of the operation can directly interpret.

[0082] For example, in a Linux environment, a coordinate event data packet is typically a binary data block following a specific structure. For each event in the input event sequence, the program populates each event with a standard structure containing a timestamp, type, code, and value. For instance, for a horizontal coordinate event, the type field is set to the value corresponding to the absolute displacement event, the code field is set to the value corresponding to the horizontal coordinate, and the value field is set to 400. Concatenating the structures corresponding to all events in the sequence forms the final coordinate event data packet to be injected.

[0083] In this embodiment, the encapsulation process of position parameters is decomposed into four fine steps: parsing coordinates, determining states, combining sequences, and encapsulating data packets. This achieves atomic-level precise construction of underlying input events. This method simulates the complete process of event reporting by a real hardware driver, ensuring a high degree of consistency between the injected touch events and physical touch operations at the core operation level. This enables more realistic and reliable automated verification of the touch interface.

[0084] Referring to Figure 3A, in step 104, based on each coordinate event data packet and the first time interval, a virtual device is invoked to simulate the physical device under test for touch interface testing.

[0085] Here, the prepared coordinate event data packets and time intervals are actually converted into touch actions on the screen by writing data to the virtual device, thereby driving the interface of the application under test to interact.

[0086] In some embodiments, referring to FIG3D, FIG3D is a fourth flowchart of a device touch interface testing method provided in an embodiment of the present application. Step 104 shown in FIG3A can be implemented by steps 1041 to 1044, which will be described in detail below.

[0087] In step 1041, the input order of the coordinate event data packet is determined according to the execution order of the multiple first touch operations.

[0088] Here, to ensure that the logic of test execution is completely consistent with the design intent in the operation sequence file, a clear and immutable event injection queue is established.

[0089] For example, after parsing the operation sequence file in step 102, an ordered list or queue containing multiple touch operations is obtained. For instance, the first element of the list might be a click on the login button, and the second element might be a click on an input field. In this step, the program directly uses this inherent order to determine the coordinate event data packet corresponding to the login button click and obtain the coordinate event data packet corresponding to the input field click.

[0090] In step 1042, for each first touch operation, the first time interval corresponding to the first touch operation is used as the time interval between the coordinate event data packet encapsulating the first touch operation and the next coordinate event data packet.

[0091] Here, the time parameters parsed from the operation sequence file are converted into the specific waiting time between the injection of two consecutive events by the test execution engine, so as to accurately reproduce the operation rhythm during recording.

[0092] For example, if the time interval defined for the first operation in the operation sequence file is 500 milliseconds, and for the second it is 1000 milliseconds, after the coordinate event data packet injection corresponding to the first operation is completed, the test execution engine calls a delay function, such as `usleep`, to wait for 500 milliseconds. After the wait is over, the injection of the coordinate event data packet corresponding to the second operation begins.

[0093] In step 1043, based on the first time interval and the input order, and based on each coordinate event data packet, the virtual device is invoked to perform the following touch interface test in a loop: simulate the physical device under test and execute the first touch operation corresponding to the coordinate event data packet.

[0094] The above-described loop execution process is the core loop of test execution. It combines the preset sequence and time to drive the continuous injection of events, thereby realizing the unattended execution of the automated test process.

[0095] For example, the test program starts a for loop that iterates through the event packet queue determined in step 1041. In each iteration, the test program opens the already created virtual device node, such as / dev / input / event1, and uses the write function to write the coordinate event packet of the current loop to that device file. After writing, the program reads the time interval corresponding to the operation and executes a delay of the corresponding duration. The loop continues until all packets in the queue have been injected.

[0096] In some embodiments, simulating the physical device under test in step 1043 and executing the first touch operation corresponding to the coordinate event data packet can be achieved in the following way: writing the coordinate event data packet into the kernel subsystem of the physical device under test through a virtual device; routing the coordinate event data packet to the target display program by the kernel subsystem; and calling the target display program to perform the following processing based on the coordinate event data packet: performing interface switching processing according to the horizontal coordinate value, vertical coordinate value and click status parameter in the coordinate event data packet.

[0097] For example, when the test program writes a coordinate event packet to a virtual device file node via a `write()` call, the data enters the Linux kernel's input subsystem. The input subsystem recognizes this as an input event and, based on the current window focus and event subscription rules, forwards the event to the target display program running in the foreground. Upon receiving the event in its own event loop, the target display program parses the coordinates and state of the event and triggers the corresponding user interface logic, such as a button click response function. For instance, the packet is written to ` / dev / input / event1`. The kernel detects this as a touch event and routes it to the industrial control software being displayed. The user interface framework of the industrial control software receives a press event at coordinates (400, 240), detects that these coordinates are within the area of ​​the start button, and calls the `on_start_button_click()` function bound to that button to execute the logic related to starting the device, which may cause the interface to jump to a new status page.

[0098] In this embodiment of the application, by simulating the physical device under test and performing the first touch operation, the beneficial effect of clarifying the complete technical path from the injection of the simulated event to the final generation of the actual user interface response is achieved. The simulation operation at the software level is described in detail as being transformed into program behavior that is no different from the real physical operation, thus verifying the effectiveness of the entire testing method.

[0099] In step 1044, the touch interface test is stopped when the virtual device performs the touch interface test for a preset duration or the number of cycles reaches a preset number.

[0100] For example, the condition for stopping the test can be set to the duration of the virtual device's loop to perform the touch interface test for a preset duration or the number of loops reaches a preset number. This provides a clear and configurable termination condition for automated testing, especially durability or aging testing, to prevent the test from running indefinitely.

[0101] For example, during the touch interface test, an execution strategy can be configured for the operation sequence file, such as {loop_count:100, duration_minutes:60}. Before the main loop begins, the test program initializes a loop counter and a timer. After each complete execution of the operation sequence, the loop counter is incremented. The test program checks if the counter has reached 100, or if the total duration recorded by the timer has exceeded 60 minutes. Once either condition is met, the test program will exit the main loop and end the current touch interface test.

[0102] In this embodiment, a fully functional and flexibly controlled automated test execution engine is constructed by determining the execution sequence, application interval, cyclic injection, and conditional termination. This engine can not only accurately reproduce complex operation sequences and timing rhythms, but also support test scenarios that require long-term, repetitive execution, such as stress testing and aging testing, greatly expanding the application scope and practical value of automated testing.

[0103] In some embodiments, referring to FIG3E, FIG3E is a fifth flowchart of a device touch interface testing method provided in an embodiment of the present application. When performing step 104, steps 105 to 106 can also be performed, which will be described in detail below.

[0104] In step 105, during the execution of the touch interface test, at least one performance metric of the physical device under test is monitored.

[0105] Here, performance metrics include: interface response speed, click success rate, and main program resource utilization.

[0106] For example, while automating operations, objective data that can quantify the quality and stability of the application software under test is collected in parallel to evaluate its performance under real-world operational loads. Performance metrics include interface responsiveness, click success rate, and main program resource utilization.

[0107] To assess interface response speed, the monitoring module records a timestamp T1 before a click event is injected into the test program. Subsequently, it continuously captures screen images and uses image comparison or feature point recognition to determine whether the expected interface change (such as a new window popping up) has been completed. When the change is complete, a timestamp T2 is recorded. The interface response speed is T2 minus T1.

[0108] Click success rate is calculated as follows: For each click operation, an expected result is predefined in the operation sequence file, such as the appearance of a specific image region. After click injection, the monitoring module checks whether the screen state matches the expected result within a preset timeout period. If they match, it is counted as a successful click. The final success rate is equal to the number of successful clicks divided by the total number of clicks.

[0109] The main program resource utilization is monitored by the monitoring module periodically executing commands (e.g., executing top-b-n1-p[PID] on a Linux device) or reading specific files (e.g., / proc / [PID] / stat) using the process ID of the physical device under test, and parsing the CPU utilization and memory usage of the main program during execution.

[0110] In step 106, a test report is generated based on performance metrics.

[0111] For example, generating a test report refers to summarizing, organizing, and visualizing the operation logs, performance monitoring data, and final results throughout the entire testing process, forming a clearly structured and detailed test archive. After the test execution is complete, all collected data can be aggregated to generate an HTML format report file. This report file is used to display to developers, allowing them to intuitively understand the test results. The report file includes the following sections: a test overview, including test start and end times, total time, operation sequence names, and summary information such as click success rate.

[0112] A detailed list of steps can be provided in a table, listing each touch operation performed in sequence, and whether the operation was successful or failed, along with a screenshot of the failure.

[0113] Performance graphs plot the main program's resource usage and interface response speed data over time, making performance fluctuations and trends readily apparent. For example, memory usage curves can visually indicate the risk of memory leaks.

[0114] In this embodiment, by simultaneously monitoring performance metrics and generating reports during the automated testing process, testing is elevated from simply verifying whether functions are normal to a comprehensive quantitative assessment of software quality. This not only uncovers functional defects but also reveals hidden performance bottlenecks, memory leaks, and other stability issues. Furthermore, it provides developers with precise data support and intuitive graphical evidence for program optimization, improving human-computer interaction efficiency.

[0115] In some embodiments, before creating a virtual device for the physical device to be tested in step 101, the following processing may also be performed: obtaining touch operation events and obtaining an operation sequence file containing original position parameters and original time parameters.

[0116] For example, an automated test script generation mechanism is used, which involves a recording program to capture the actual touch operations of testers on physical devices and automatically convert these actual touch operations into script files that can be parsed and executed by subsequent automated test processes.

[0117] For example, a tester starts an event recording program on a physical device. This program connects to the device's input event driver and begins listening for all touch actions on the screen. The tester then manually performs actions according to a pre-defined test scenario, such as first clicking the icon of application A, waiting for the application to launch, and then swiping the screen to browse content. Throughout this process, the recording program captures the details of these actions in real time: recording the screen coordinates of clicking the application A icon (e.g., 120, 250) as a set of raw position parameters, calculating the time difference between the end of this click and the start of the next swipe (e.g., 2500 milliseconds) as raw time parameters, and capturing the start and end coordinates of subsequent swipes as another set of raw position parameters. When the tester finishes recording, the program formats all the captured position and time parameters in chronological order and saves the formatted result as a file, such as a JSON file. This file is the operation sequence file used in subsequent steps.

[0118] This application provides a record-playback test case generation method, which allows testers to quickly create complex automated test scripts through intuitive, WYSIWYG manual operations. This greatly reduces the technical threshold and workload of writing automated test cases. Especially for operations involving complex gestures or irregular paths, the recording method has significant advantages in efficiency and accuracy compared to manual coding.

[0119] This application implements an automated, cross-platform, and high-precision touch interface testing method. By constructing virtual devices, mapping coordinate parameters, encapsulating input events, and injecting execution into the core technical process, it can accurately reproduce user operation sequences containing complex gestures and precise time intervals without the need for physical device intervention. This not only solves the dependence of traditional automated testing solutions on specific device resolutions and significantly improves the reusability of test scripts, but also ensures a high degree of consistency between test operations and real user behavior through event-level low-level simulation. Simultaneously, during test execution, it monitors multiple performance indicators such as interface response speed and click success rate, and ultimately generates a comprehensive test report including performance curves and detailed operation logs. This elevates testing from simple functional verification to a comprehensive quantitative evaluation of software quality, providing intuitive and accurate data support for program optimization.

[0120] In this embodiment, the above-described method achieves an automated, cross-platform, and high-precision touch interface testing. When the test begins, by constructing a virtual device, mapping coordinate parameters, encapsulating underlying events, and injecting them into the core technical process, it can accurately reproduce user operation sequences containing complex gestures and precise time intervals. This not only solves the dependence of traditional automated testing solutions on specific device resolutions and significantly improves the reusability of test scripts, but also ensures a high degree of consistency between test operations and real user behavior through event-level low-level simulation. Simultaneously, during test execution, multi-dimensional performance indicators such as interface response speed and click success rate are monitored, and a comprehensive test report including performance curves and detailed operation logs is generated. This elevates testing from simple functional verification to a comprehensive quantitative evaluation of software quality, providing intuitive and accurate data support for program optimization.

[0121] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0122] With the widespread adoption of touch-interactive devices such as smartphones, tablets, in-vehicle systems, and industrial control terminals, the stability and responsiveness of graphical user interfaces (GUIs) have become key indicators for measuring product quality. To ensure that products meet high quality standards before delivery, automated GUI testing has gradually replaced traditional manual testing, becoming a core component of the software development and quality assurance process.

[0123] However, in specific professional fields, especially industrial control, existing mainstream automated testing frameworks have revealed significant limitations. For example, Selenium or Appium, widely used automated testing tools for web and mobile devices, were originally designed primarily for standardized browser environments and mainstream mobile operating systems. When faced with industrial control equipment running customized embedded Linux systems, they often have poor applicability or cannot be directly applied. More critically, many testing schemes require the installation of heavyweight agent programs on the device under test (DUT), which not only consumes the device's valuable computing and storage resources but may also alter its original operating environment, thus affecting the accuracy of performance test results. This problem is particularly pronounced on embedded devices such as those used in industrial control systems, where memory and processing power are already limited, resulting in a long-standing lack of dedicated and efficient automated testing solutions in this field.

[0124] Therefore, in the field of industrial control, the testing of touch interfaces for embedded devices has long regressed to a mode that relies on manual operation. This has directly led to a series of problems such as poor operational consistency, inability to guarantee stable execution of long-term continuous testing, and difficulty in achieving remote unattended testing.

[0125] To further illustrate how the technical solutions of this application's embodiments are applied in real-world environments, the following will use a typical industrial control equipment stability testing scenario as an example to explain the practical application of the automated touch testing method provided in this application's embodiments. In such scenarios, manufacturers need to perform long-term (e.g., 72 hours) continuous touch operations on newly developed industrial control screens equipped with small-memory embedded Linux to verify the stability and reliability of the industrial control screens under harsh environments. Traditional testing methods heavily rely on manual operation, which is not only costly but also makes it difficult to guarantee the consistency and repeatability of operations, especially on resource-constrained equipment, where effective automation solutions are lacking. The automated touch testing method provided in this application's embodiments aims to solve these problems, providing an accurate, stable, and interference-free automated testing solution.

[0126] Referring to Figure 4, which is a schematic diagram of the overall architecture of the automated touch testing method provided in this application embodiment, the architecture can be physically divided into two parts: a desktop terminal 401 and an embedded device 402. The embedded device 402 is the specific entity carrying and executing the testing method described in this application embodiment, corresponding to the terminal device 400-1 mentioned above. The desktop terminal 401 serves as an external test control and management platform, and the two communicate via TCP / IP network transmission. The desktop terminal 401, as the initiator of the test task, is mainly responsible for recording and sending operation instructions. The desktop terminal 401 includes a desktop emulation program, operation recording files, and a TCP transmission control module. The embedded device 402, as the executor of the test task, is responsible for receiving instructions and accurately reproducing touch operations. Its core is a touch execution service running on a single-process integrated architecture 403. This service works in conjunction with modules such as the virtual device 404, the physical device 405, the Linux kernel Input subsystem 406, and the display program 407. In a typical testing process, this automated touch testing method records operations on the desktop (401) and then transmits them over the network to the embedded device (402) for touch operation execution. The goal of the desktop (401) operation recording stage is to generate a high-precision, standardized operation recording file. To address inconsistencies with manual operations, the desktop emulation program utilizes mechanisms such as event filters to monitor mouse click events in real time, accurately capturing the pixel coordinates of the click location and microsecond-level timestamps. The captured data is encapsulated into a simplified data structure containing only the execution time interval, X-coordinate, and Y-coordinate to reduce data redundancy. Finally, the operation sequence is stored as a JSON file. This file structure contains an array named `events`, whose members are multiple click event objects. Each object contains three parameters: `interval`, representing the time interval (in microseconds) since the last click event; `x`, representing the X-coordinate of the click; and `y`, representing the Y-coordinate of the click.

[0127] The network transmission phase is responsible for securely and efficiently transferring the recorded file to the target device. In some embodiments, the SCP transfer protocol is used to transfer the JSON file generated by the desktop client 401 to a specified directory on the embedded device 402. After the transfer is complete, the touch execution service on the embedded device 402 is remotely activated via the SSH command to start the automated testing process.

[0128] The touch execution service runs automatically on a single-process integrated architecture 403 within the embedded device 402. Referring to Figure 5, which is a schematic diagram of the workflow of the touch execution service provided in this embodiment of the application within an embedded device, the details are as follows.

[0129] In step 201, the service is initialized and a virtual input device is created.

[0130] The touch execution service on the single-process integrated architecture 403 initializes by calling the Linux kernel's uinput subsystem 406 to create a virtual device 404, such as / dev / input / event1. Simultaneously, to avoid interference from external physical touch during testing, the service exclusively takes over the physical device 405 corresponding to the physical touchscreen 408, such as / dev / input / event0, by sending the EVIOCGRABI / O control command. After initialization, the touch execution service enters the execution phase, processing the JSON file that serves as the input for operation instructions. This JSON file is a standardized operation script generated by the simulation program on the desktop 401 by recording the precise coordinates and time intervals of mouse clicks, and has been pre-transmitted to the embedded device 402. The touch execution service reads and accesses this JSON file based on the file path received at startup, preparing for subsequent parsing and execution.

[0131] Step 202: Parse the JSON file.

[0132] The touch execution service opens the JSON file transmitted from the desktop via a 401 error, parses the JSON file, extracts the event sequence containing time intervals and coordinate values, and forms coordinate data.

[0133] Step 203, conversion and encapsulation.

[0134] Because the resolution of the interface used for recording on the desktop 401 may differ from the physical resolution of the screen on the embedded device 402, coordinate mapping is required. This conversion process calculates the scaling ratio of the X and Y axes based on four parameters: the width and height of the desktop 401 interface, the width and height of the embedded interface, and then converts the desktop 401 coordinates into the actual click coordinates on the embedded device according to the scaling ratio. The converted coordinates are encapsulated into a coordinate event packet, which is a standard input_event sequence recognizable by the Linux kernel Input subsystem 406. A complete click operation is encapsulated as a press-coordinate-synchronize-release sequence. Specifically, this is achieved by setting the click status parameter BTN_TOUCH to 1 to indicate a click, then sending the X-axis coordinate parameter ABS_X and the Y-axis coordinate parameter ABS_Y containing the converted coordinates, and finally setting the click status parameter BTN_TOUCH to 0 to indicate a release.

[0135] Step 204: Send coordinate event.

[0136] The encapsulated coordinate event packet is sent to the created virtual device 404. Step 205 is executed after step 204.

[0137] Step 205: Process the coordinate event and switch the user interface.

[0138] After receiving an event from the virtual device 404, the Linux kernel Input subsystem 406 treats the event as actual touch input and routes it to the currently active display program 407. After processing the coordinate event, the display program 407 executes corresponding interface updates based on the instructions, such as switching user interfaces, ultimately producing the touch simulation result.

[0139] In some embodiments, after step 204, step 206 is also performed to delay the processing of the next coordinate value.

[0140] After the current event is processed, the touch execution service continues processing the next event from the JSON's `events` array. Before processing the next coordinate value, the touch execution service performs a precise delay based on the current event's time interval parameter. This mechanism ensures that the execution rhythm of continuous clicks is completely consistent with the recording, thus guaranteeing the repeatability of the test. The test process repeats continuously, from step 203 to steps 204 and 206, until all events have been processed.

[0141] Furthermore, to address the issue of test programs interfering with the main application of devices with limited memory, this application employs a non-interference operation strategy. To cope with resource constraints, the touch execution service adopts a single-process integrated architecture, integrating all functions such as file reception, parsing, event conversion, and injection into a single process, significantly reducing memory usage and inter-process communication overhead. During runtime, by setting the nice value of this service process to 19 (lowest priority), it is ensured that the device's main application can obtain CPU resources preferentially. Simultaneously, this service process can be bound to non-critical CPU cores through CPU affinity, further achieving physical resource isolation from the main program.

[0142] The following description further illustrates the exemplary structure of the touch interface testing device 455 provided in this application embodiment as a software module. In some embodiments, as shown in FIG2, the software module stored in the touch interface testing device 455 of the device in the memory 450 may include: a creation module 4551, used to create a virtual device of the physical device to be tested and intercept the actual touch events of the physical device to be tested; a parsing module 4552, used to parse the operation sequence file to obtain the first position parameters and first time interval of a plurality of first touch operations; an encapsulation module 4553, used to encapsulate the first position parameters of each first touch operation into a coordinate event data packet; and a testing module 4554, used to call the virtual device to simulate the physical device to be tested for touch interface testing based on each coordinate event data packet and the first time interval.

[0143] In some embodiments, the parsing module 4552 is further configured to: parse the operation sequence file to obtain touch operation information of a plurality of first touch operations, wherein the touch operation information includes original position parameters and original time parameters; determine the original time parameters as the first time interval of the first touch operation; and perform coordinate mapping processing on the original position parameters to obtain the first position parameters of the first touch operation.

[0144] In some embodiments, the parsing module 4552 is further configured to: obtain the source interface size and the screen resolution of the physical device under test, wherein the source interface size is the size of the interface corresponding to the coordinate system where the original position parameter is located; calculate the coordinate scaling ratio based on the source interface size and the screen resolution; and convert the original position parameter into the first position parameter based on the coordinate scaling ratio.

[0145] In some embodiments, the encapsulation module 4553 is further configured to: perform the following processing on the first position parameter of each first touch operation: parse the first position parameter to obtain the horizontal coordinate value and the vertical coordinate value of the first touch operation; determine the click state parameter corresponding to the first touch operation, wherein the click state parameter is a first value indicating touch release, and the click state parameter is a second value indicating touch press; combine the horizontal coordinate value, the vertical coordinate value, and the click state parameter into an input event sequence; and encapsulate the input time sequence into the coordinate event data packet.

[0146] In some embodiments, the test module 4554 is further configured to: determine the input order of the coordinate event data packets according to the execution order of the plurality of first touch operations; for each first touch operation, use the first time interval corresponding to the first touch operation as the time interval between the coordinate event data packet encapsulating the first touch operation and the next coordinate event data packet; based on the first time interval and the input order, and for each coordinate event data packet, call the virtual device to cyclically execute the following touch interface test: simulate the physical device under test and execute the first touch operation corresponding to the coordinate event data packet; when the duration of the virtual device cyclically executing the touch interface test reaches a preset duration, or the number of cycles reaches a preset number, stop the touch interface test.

[0147] In some embodiments, the test module 4554 is further configured to: write the coordinate event data packet into the kernel subsystem of the physical device under test through the virtual device; route the coordinate event data packet to the target display program by the kernel subsystem; and, based on the coordinate event data packet, call the target display program to perform the following processing: perform interface switching processing according to the horizontal coordinate value, vertical coordinate value and click status parameter in the coordinate event data packet.

[0148] In some embodiments, when the virtual device is invoked to simulate the physical device under test for touch interface testing based on each coordinate event data packet and the first time interval, the test module 4554 is further configured to: monitor at least one performance indicator of the physical device under test during the execution of the touch interface test, the performance indicator including: interface response speed, click success rate and main program resource utilization rate; and generate a test report based on the performance indicator.

[0149] This application provides a computer program product, which includes computer-executable instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the touch interface testing method of the device described in this application.

[0150] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the touch interface testing method of the device provided in this application, such as the touch interface testing method of the device shown in FIG3A.

[0151] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0152] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0153] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0154] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0155] In summary, this application provides a complete automated touch testing solution for resource-constrained embedded devices through precise desktop recording, lightweight network transmission, and efficient, interference-free single-process execution services on the embedded device side. This solution effectively solves the technical challenges of inconsistent operation, high resource consumption, and system interference in traditional testing methods by employing transparent virtual device proxy, a single-process integrated architecture, and an industrial-grade interference-free operation strategy. It provides a reliable technical foundation for continuous aging testing and performance verification of devices such as industrial control panels.

[0156] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for testing the touch interface of a device, characterized in that, The method includes: creating a virtual device for the physical device under test and intercepting actual touch events of the physical device under test; parsing an operation sequence file to obtain first position parameters and first time intervals for multiple first touch operations; encapsulating the first position parameters of each first touch operation into a coordinate event data packet; and, based on each coordinate event data packet and the first time interval, calling the virtual device to simulate the physical device under test for touch interface testing.

2. The method according to claim 1, characterized in that, The step of parsing the operation sequence file to obtain the first position parameters and first time intervals of multiple first touch operations includes: parsing the operation sequence file to obtain touch operation information of multiple first touch operations, wherein the touch operation information includes original position parameters and original time parameters; determining the original time parameters as the first time interval of the first touch operation; and performing coordinate mapping processing on the original position parameters to obtain the first position parameters of the first touch operation.

3. The method according to claim 2, characterized in that, The step of performing coordinate mapping processing on the original position parameters to obtain the first position parameters of the first touch operation includes: obtaining the source interface size and the screen resolution of the physical device under test, wherein the source interface size is the size of the interface corresponding to the coordinate system where the original position parameters are located; calculating the coordinate scaling ratio based on the source interface size and the screen resolution; and converting the original position parameters into the first position parameters based on the coordinate scaling ratio.

4. The method according to claim 1, characterized in that, The step of encapsulating the first position parameter of each first touch operation into a coordinate event data packet includes: performing the following processing on the first position parameter of each first touch operation: parsing the first position parameter to obtain the horizontal coordinate value and vertical coordinate value of the first touch operation; determining the click state parameter corresponding to the first touch operation, wherein the click state parameter is a first value indicating touch release, and the click state parameter is a second value indicating touch press; combining the horizontal coordinate value, the vertical coordinate value, and the click state parameter into an input event sequence; and encapsulating the input time sequence into the coordinate event data packet.

5. The method according to claim 1, characterized in that, The step of invoking the virtual device to simulate the physical device under test for touch interface testing based on each coordinate event data packet and the first time interval includes: determining the input order of the coordinate event data packets according to the execution order of the plurality of first touch operations; for each first touch operation, using the first time interval corresponding to the first touch operation as the time interval between the coordinate event data packet encapsulating the first touch operation and the next coordinate event data packet; based on the first time interval and the input order, invoking the virtual device to cyclically execute the following touch interface test based on each coordinate event data packet: simulating the physical device under test and executing the first touch operation corresponding to the coordinate event data packet; stopping the touch interface test when the duration of the virtual device cyclically executing the touch interface test reaches a preset duration or the number of cycles reaches a preset number.

6. The method according to claim 5, characterized in that, The step of simulating the physical device under test and executing the first touch operation corresponding to the coordinate event data packet includes: writing the coordinate event data packet into the kernel subsystem of the physical device under test through the virtual device; routing the coordinate event data packet to the target display program by the kernel subsystem; and, based on the coordinate event data packet, calling the target display program to perform the following processing: performing interface switching processing according to the horizontal coordinate value, vertical coordinate value, and click status parameter in the coordinate event data packet.

7. The method according to any one of claims 1 to 6, characterized in that, When the virtual device is invoked to simulate the physical device under test for touch interface testing based on each coordinate event data packet and the first time interval, the method further includes: monitoring at least one performance indicator of the physical device under test during the execution of the touch interface test, the performance indicator including: interface response speed, click success rate and main program resource utilization rate; and generating a test report based on the performance indicator.

8. A touch interface testing device for a device, characterized in that, The device includes: a creation module for creating a virtual device for the physical device under test and intercepting actual touch events of the physical device under test; a parsing module for parsing an operation sequence file to obtain first position parameters and first time intervals for multiple first touch operations; an encapsulation module for encapsulating the first position parameters of each first touch operation into a coordinate event data packet; and a testing module for calling the virtual device to simulate the physical device under test for touch interface testing based on each coordinate event data packet and the first time interval.

9. An electronic device, characterized in that, The electronic device includes: a memory for storing computer-executable instructions or computer programs; and a processor for executing the computer-executable instructions or computer programs stored in the memory to implement the touch interface testing method of the device according to any one of claims 1 to 7.

10. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, the touch interface testing method of the device according to any one of claims 1 to 7 is implemented.

Images