A remote testing method, system, device, apparatus, and storage medium

CN122527031APending Publication Date: 2026-08-07SHENZHEN GREEN CONNECTION TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
SHENZHEN GREEN CONNECTION TECH CO LTD
Filing Date
2026-04-07
Publication Date
2026-08-07

AI Technical Summary

Technical Problem

[0005]本发明实施例提供一种远程测试方法、系统、设备、装置和存储介质,以解决验证周期长,开发效率低、反馈不及时且效果判断不精确的问题

Benefits of technology

[0017]本发明实施例提供的远程测试方法、系统、设备和存储介质的有益效果在于:通过服务器与工作设备建立远程连接,第一用户可直接将待测试界面图片数据传输至设备端的预设文件夹,无需进行代码编译和固件烧录操作,从而大幅缩短UI迭代周期,提升开发效率。设计方可远程上传界面文件,现场设备按指令自动显示,图像采集设备同时获取真实显示效果并实时回传,使多方能在不同地点同步查看同一设备的真实显示画面,有效解决传统方式中信息传递延迟、失真和反馈滞后的问题。进一步的,通过自动化采集与远程回传,减少了各方频繁往返硬件现场或反复传输视频资料的过程,降低了研发、设计及测试环节的人力占用和沟通成本。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122527031A_ABST
    Figure CN122527031A_ABST
Patent Text Reader

Abstract

The application relates to the technical field of software testing, in particular to a remote testing method, system, device, apparatus and storage medium. The method is applied to a remote testing system comprising a work device, an embedded development board, a display screen and an image acquisition device. The work device stores interface picture data to be tested. The method comprises the following steps: a server establishes a remote connection with the work device, a first user transmits the interface picture data to be tested to a preset picture folder according to a preset naming rule; after receiving an operation instruction of a second user, the picture data is read according to a preset order and time length and displayed on the display screen; the image acquisition device is driven to acquire a screen picture based on the display time length or the operation instruction, an effect image is generated and stored in a preset effect folder, the first user reads the effect image through the work device and performs pixel-level effect inspection, and efficient and accurate closed-loop verification of a remote UI effect is realized. The application can effectively solve the problems of information transmission delay, distortion and feedback lag in the traditional mode.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to a remote testing method, system, device, apparatus, and storage medium. Background Technology

[0002] During the development phase of display products, the confirmation and verification of UI (User Interface) effects is a high-frequency and crucial step, as its quality directly determines the visual presentation and user experience of the final product.

[0003] In the existing development process, UI design companies typically complete the interface design and then deliver the design to solution providers or R&D teams. Developers then use coding to convert the design into an executable program, which is then burned onto a development board or actual hardware device for display verification. This process is not only time-consuming and labor-intensive but may also involve hardware debugging steps such as driver adaptation and display configuration, resulting in a long UI verification cycle and low development efficiency.

[0004] The participants involved in UI design, software development, hardware solutions, and product management are often located in different regions or organizations, making it impossible for them to simultaneously view the display effects on the same hardware in real time. This results in untimely feedback and inaccurate judgment of the effects. Summary of the Invention

[0005] This invention provides a remote testing method, system, device, apparatus, and storage medium to address the problems of long verification cycles, low development efficiency, untimely feedback, and inaccurate effect judgment.

[0006] This invention discloses a remote user interface testing method, applied to a remote testing system, the remote testing system comprising:

[0007] A working device, wherein the working device stores image data of the interface to be tested; An embedded development board is provided with a server and a human-machine interface. The server can be remotely connected to the working device, and the human-machine interface is used to receive user operation commands. A display screen, connected to the embedded development board, is used to display the image of the interface to be tested; An image acquisition device, configured to correspond to the display screen, is connected to the embedded development board and is capable of acquiring the display effect of the display screen; The remote testing method for the user interface includes: A remote connection is established between the server and the working device so that the first user can transfer the image data of the interface to be tested to a preset image folder; When an operation command is received from the second user, the image data of the interface to be tested is read from the image folder and displayed according to the preset display order and display duration based on the operation command; The image acquisition device is driven to acquire images of the display screen based on the display duration and / or the operation command, so as to obtain an effect image and store the effect image in a preset effect folder, so that the first user can read the effect image and perform effect verification through the working device.

[0008] Optionally, the test interface image data includes the test interface image and the display parameters used when displaying the interface image; The step of reading and displaying the test interface image data from the image folder includes: After adjusting the screen parameters of the display screen according to the display parameters, the corresponding image of the interface to be tested is displayed.

[0009] Optionally, the step of transferring the image data of the interface to be tested to the image folder includes: After naming the images of the interface to be tested according to the preset naming rules, they are saved in the image folder.

[0010] Optionally, the step of reading and displaying the test interface image data from the image folder according to the operation command in a preset display order and display duration includes: The test interface images are read in ascending order of their filenames.

[0011] Optionally, the step of reading and displaying the test interface image data from the image folder according to the operation command in a preset display order and display duration further includes: If the duration of displaying the current test interface image has not yet reached the specified display duration, and a switching instruction is received from the second user, then the next test interface image is displayed according to the switching instruction.

[0012] Optionally, after the step of reading the test interface image data from the image folder and displaying it according to the preset display order and display duration based on the operation instruction, the following steps are included: Once all the images of the interface to be tested have been displayed, turn off the display screen and put the remote testing system into standby mode. Clear the cache of the embedded development board.

[0013] The present invention also discloses a remote testing system for implementing the method described above, the remote testing system comprising: A working device, wherein the working device stores image data of the interface to be tested; An embedded development board is provided with a server and a human-machine interface. The server can be remotely connected to the working device, and the human-machine interface is used to receive user operation commands. A display screen, connected to the embedded development board, is used to display the image of the interface to be tested; An image acquisition device, configured to correspond to the display screen, is connected to the embedded development board and is capable of acquiring the display effect of the display screen.

[0014] The present invention also discloses a remote testing device, applied to the remote testing system described above, comprising: A connection module is used to establish a remote connection between the server and the working device, so that the first user can transfer the image data of the interface to be tested to a preset image folder; The display module is used to read the image data of the interface to be tested from the image folder and display it according to the preset display order and display duration when it receives the operation command input by the second user. The acquisition module is used to drive the image acquisition device to acquire images of the display screen based on the display duration and / or the operation command, so as to obtain effect images and store the effect images in a preset effect folder, so that the first user can read the effect images and perform effect verification through the working device.

[0015] The present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.

[0016] The present invention also discloses a remote testing device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the method described above.

[0017] The beneficial effects of the remote testing method, system, device, and storage medium provided in this invention are as follows: By establishing a remote connection between the server and the working device, the first user can directly transmit the interface image data to be tested to a preset folder on the device without code compilation and firmware burning, thereby significantly shortening the UI iteration cycle and improving development efficiency. Designers can remotely upload interface files, and the on-site device automatically displays them according to instructions. The image acquisition device simultaneously acquires the actual display effect and transmits it back in real time, enabling multiple parties to simultaneously view the actual display screen of the same device from different locations, effectively solving the problems of information transmission delay, distortion, and feedback lag in traditional methods. Furthermore, through automated acquisition and remote transmission, the process of frequent trips to the hardware site or repeated transmission of video data by all parties is reduced, lowering the manpower and communication costs in the R&D, design, and testing stages. Attached Figure Description

[0018] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a flowchart illustrating the first embodiment of the remote user interface testing method provided by the present invention; Figure 2 This is a schematic diagram of an embodiment of the remote testing system provided by the present invention; Figure 3 This is a schematic diagram of the structure of an embodiment of the remote testing device provided by the present invention; Figure 4 This is a schematic diagram of an embodiment of the remote testing device provided by the present invention; Figure 5 This is a schematic diagram of an embodiment of the computer-readable storage medium provided by the present invention.

[0019] The labels for the attached figures are as follows: 10. Remote testing system; 11. Working equipment; 12. Embedded development board; 121. Server; 122. Human-computer interaction interface; 13. Display screen; 14. Image acquisition device; 20. Remote testing equipment; 21. Connection module; 22. Display module; 23. Data acquisition module; 30. Remote testing device; 31. Processor; 32. Memory; 40. Computer-readable storage medium; 41. Computer program. Detailed Implementation

[0020] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0021] Please refer to the following: Figure 1 and Figure 2 , Figure 1 This is a flowchart illustrating the first embodiment of the remote user interface testing method provided by the present invention. Figure 2 This is a schematic diagram of an embodiment of the remote testing system provided by the present invention. Figure 2 As shown, the remote testing system 10 includes a work device 11 located at the designer's location, an embedded development board 12 remotely connected to the work device 11, a display screen 13 connected to the embedded development board 12, and an image acquisition device 14. The work device 11 can be a desktop computer, laptop computer, or other conventional office equipment, and it has pre-stored the image data of the interface to be tested (such as UI mockups in PNG and JPG formats) completed by the UI designer.

[0022] The embedded development board 12 is deployed at the location of the R&D personnel (the first user) and serves as the control center of the entire remote testing system 10. A general-purpose embedded development board 12, such as a Raspberry Pi or Banana Pi, can be used. Its performance is well-suited for embedded scenarios, and it is small in size, low in power consumption, highly stable, and easy to deploy and maintain. The embedded development board 12 is equipped with a server 121 and a human-machine interface 122. The server 121 is preferably a Samba server 121, but FTP (File Transfer Protocol Server) servers 121, NFS (Network File System) servers, or similar file-sharing servers 121 can also be used. It can establish a stable remote connection with the designer's work device 11. The server 121 supports file sharing, receiving test interface image data uploaded by the work device 11 and storing it in a designated directory (such as an image folder) within the development board. It can also transmit display effect data collected by the subsequent image acquisition device 14 back to the work device 11, achieving bidirectional data interaction without requiring manual intervention from the R&D personnel during data transmission.

[0023] The human-machine interface 122 is used to receive manual operation commands from a second user (R&D personnel or field testers). The interface can be a simple and convenient operating component such as a tactile button or touch button, directly connected to the GPIO (General Purpose Input / Output) pins of the embedded development board 12, offering fast response and a low barrier to entry. Its core function is to trigger the display and switching of UI images; for example, a short press triggers the playback of an image sequence, another short press switches to the next image, and a long press stops the display, enabling flexible local control over the UI display process.

[0024] The display screen 13 establishes a physical connection with the embedded development board 12 (through common display interfaces such as SPI (Serial Peripheral Interface) and I2C (Inter-Integrated Circuit)). It serves as the actual carrier for the UI effect, directly using the real screen of the display product (such as smart home panels, industrial HMIs, consumer electronics displays, etc.) to ensure that the UI display effect is consistent with the final product, fundamentally solving the problem of discrepancies between traditional simulation testing and real-device display. The core function of the display screen 13 is to read and display the image of the interface to be tested. When the embedded development board 12 receives the operation command input by the second user through the human-machine interface 122, it reads the image of the interface to be displayed uploaded by the working device 11 from the image folder. After decoding and format conversion (such as converting to RGB data supported by the screen), it sends the image to the display screen 13 through the display interface, completing the real-device presentation of the UI effect.

[0025] Image acquisition device 14 is connected to embedded development board 12 (via USB interface) and deployed next to display screen 13. The lens is aimed at the display area of ​​display screen 13 to capture the actual display effect of UI presented on display screen 13. When display screen 13 completes the display of a single UI image, embedded development board 12 automatically triggers image acquisition device 14 to take a picture. The captured image data (such as the actual effect picture) is automatically stored in the preset effect folder of embedded development board 12 and transmitted back to the designer's work device 11 in real time through server 121, so that the designer can remotely view and compare, and accurately judge the details such as color reproduction, brightness, and layout accuracy of UI effect on real device. There is no need for on-site personnel to manually take pictures and transmit them, avoiding the distortion problem of manual shooting and improving the accuracy of testing.

[0026] In one implementation scenario, during the system deployment phase, core parameters of the image acquisition device 14, such as focal length, exposure time, white balance, and color reproduction, are preset or calibrated in advance. By acquiring standard color charts or test images, the device's color shift is corrected to ensure accurate matching between the color space of the captured image and the display color gamut of the target screen. A custom bracket can also be used to fix the relative position, shooting angle, and shooting distance between the acquisition device and the screen; and ambient light sources can be used to ensure uniform and stable lighting, avoiding display distortion caused by reflections and shadows.

[0027] The standardized and debugged image acquisition device 14 can capture a realistic display effect that is highly consistent with the display screen 13. This allows designers to remotely perform pixel-level, parametric, and precise comparison and verification, completely solving the technical pain points of effect distortion and inability to quantify comparison caused by manual shooting.

[0028] The remote user interface testing method provided by this invention includes the following steps: S101: Establish a remote connection between the server and the working device so that the first user can transfer the image data of the interface to be tested to a preset image folder.

[0029] In a specific implementation scenario, server 121, acting as a network server located on the embedded development board 12, establishes a stable and secure remote network connection link with the work device 11 located on the designer's end. This remote connection can be achieved through conventional network communication methods such as LAN, WLAN, and Ethernet, ensuring that the work device 11 and the embedded development board 12 can still perform efficient and reliable bidirectional data interaction even when physically separated.

[0030] Through the aforementioned remote connection mechanism, the first user (such as a designer) can directly interact with the server 121 on the embedded development board 12 via standardized network access methods (such as network neighbor mapping, FTP client access, Samba sharing access, etc.) on their work device 11, and securely and completely transmit and store the image data of the interface to be tested from the local storage system of the work device 11 to the preset image folder inside the embedded development board 12.

[0031] The image folder is a pre-configured and authorized dedicated directory used to centrally collect all interface image data to be tested, providing a stable and unique data source for subsequent display and testing of these images. This mechanism ensures that all interface images to be tested are transmitted remotely over the network, eliminating the need for manual file copying on the embedded development board 12 or for developers to compile and flash the software. This achieves rapid delivery of interface image data with zero hardware contact, zero on-site intervention, and zero development process dependency.

[0032] In other implementation scenarios, when the image data of the interface to be tested is transferred from the working device 11 and stored in the preset image folder inside the embedded development board 12, the file naming and storage operations are strictly performed in accordance with the preset naming rules. These naming rules are standardized specifications that are pre-set and uniformly followed by the system during the initialization or configuration phase. They are used to ensure that all images of the interface to be tested are clearly structured, uniquely ordered, and can be accurately identified by the system and displayed in the correct sequence within the image folder.

[0033] Specifically, before storing the test interface images into the image folder, each image is assigned a unique filename according to a preset naming rule. The preset naming rule can preferably use a numerical sequence naming method, for example, naming the test interface images "001.png", "002.png", "003.png", etc., according to the test order; alternatively, it can be preset to other naming methods based on scene identifiers, module numbers, or test priorities, as long as the filenames can be naturally ordered lexicographically or chronologically.

[0034] By naming and storing UI images according to preset naming rules, the structure and order of the images to be tested within the image folder are ensured to be clear. This allows the system to automatically read and display the images according to the rules, without the need for manual reordering or intervention. This achieves standardized and automated management of UI testing resources, improves testing efficiency, avoids display errors, and enhances the overall stability and maintainability of the system.

[0035] S102: When receiving an operation command input from the second user, the system reads and displays the image data of the interface to be tested from the image folder according to the preset display order and display duration based on the operation command.

[0036] In a specific implementation scenario, the second user (the R&D personnel located at the site of the embedded development board 12) inputs operation commands through the preset human-computer interaction interface 122 (such as a light touch button, a touch button, etc.) on the embedded development board 12. The core function of this operation command is to trigger the start, switch, or stop of the UI display process. It is a local manual triggering method with a very low operation threshold. The second user does not need to have professional R&D or operation skills. The command input can be completed simply by pressing a button.

[0037] The human-machine interface 122 is connected in real time to the background monitoring process of the embedded development board 12. When the second user presses a button, the interface immediately generates a corresponding electrical signal (such as a GPIO level change) and quickly transmits it to the background monitoring process to ensure real-time, delay-free instruction reception. Specifically, the background monitoring process continuously listens for signal input from the human-machine interface 122. Once it receives an operation command from the second user, it immediately parses the command, determines the command type (such as "start display", "switch to the next image", "stop display", etc.), and, based on the parsing result, calls the system's preset display control logic to start the UI display process and complete subsequent image reading and display operations. Specifically, if the command is "start display", the complete image sequence display process is triggered; if the command is "switch to the next image", the display of the current image is interrupted, and the display immediately switches to the next image to be displayed; if the command is "stop display", the entire display process is terminated, and the display screen 13 is controlled to enter standby mode to ensure accurate response to operation commands.

[0038] If the command is "Start Display", the preset display order and display duration are obtained. The preset display order prioritizes "sorting by image naming rules", that is, reading the images of the interface to be tested in the preset image folder in order of their names (e.g., 001.png, 002.png, 003.png, etc.). This naming rule is followed by the first user (designer) when uploading images to ensure that the image display order is consistent with the design logic. At the same time, other methods such as "sorting by image upload time" or "sorting by custom priority" can also be preset according to testing needs to improve the flexibility of the system.

[0039] The preset display duration is the default display time for a single image on the test interface, typically configured to 3-10 seconds (adjustable according to testing needs, such as 5 seconds). This duration ensures that both the second user and the remote first user can clearly observe the UI display effect, while avoiding excessively long display times that could lead to low testing efficiency. During the display of a single image, the background monitoring process continuously listens for operation commands from the human-computer interaction interface 122. If it receives another "switch to next image" command from the second user (such as pressing the button again), it immediately interrupts the display process of the current image, without waiting for the default display duration to end. It directly controls the UI display process to read and display the next image, achieving rapid image switching and improving testing efficiency.

[0040] Based on the operation commands input by the second user, and following a preset display order, the system accurately reads the corresponding test interface image data from the image folder. During the reading process, the test interface image undergoes preprocessing, including image decoding, format conversion (such as converting the test interface image to RGB pixel data supported by the display screen 13), and size adaptation (ensuring that the size of the test interface image matches the resolution of the display screen 13 to avoid stretching, cropping, misalignment, and other issues), ensuring that the test interface image can be displayed correctly on the display screen 13. After preprocessing, the processed test interface image is sent to the display screen 13 through the display interface (such as SPI, I2C, etc.) of the embedded development board 12, controlling the display screen 13 to light up and display the test interface image until the preset display duration is reached, or a switch or stop command is received from the second user, before proceeding to the next step.

[0041] In other implementation scenarios, to achieve precise quantitative control and dynamic optimization of UI display effects, the test interface image data includes the test interface image and the display parameters used when displaying the interface image. Display parameters may include, but are not limited to, brightness, contrast, saturation, color temperature, display orientation, and display area.

[0042] When reading the image data of the interface to be tested from the preset image folder for display, the system reads the current image data of the interface to be tested in the image folder and parses the display parameters from it. The validity and format of these display parameters can be verified first to ensure that the parameter configuration conforms to the system's preset adjustment range. Based on the parsed display parameters, the system adjusts the screen parameters of display screen 13 in real time. For example, if the display parameters specify a 10% increase in brightness, the UI display process will send a corresponding brightness adjustment command to the screen, causing a corresponding change in the screen's backlight brightness or display color brightness; if the display parameters specify contrast adjustment or display orientation rotation, the system will adjust the screen's display driving algorithm or physical display angle accordingly.

[0043] After the screen parameters are adjusted according to the display parameters, the corresponding image data of the interface to be tested is read. After preprocessing such as decoding and format conversion, it is sent to the display screen 13 with adjusted parameters to complete the final presentation. By integrating display parameters into the image data of the interface to be tested and enabling the system to adjust the screen parameters according to these parameters before display, remote and precise control and dynamic optimization of UI display effects are achieved. This mechanism allows designers to remotely adjust hardware parameters such as screen brightness and contrast directly on the work device 11, enabling refined remote verification and optimization of UI display effects. This significantly improves the flexibility and accuracy of UI testing, reduces the cost of cross-regional collaborative development, and provides a standardized and quantifiable display basis for subsequent effect collection and feedback comparison.

[0044] S103: Drive the image acquisition device to acquire images of the display screen based on the display duration and / or operation instructions, so as to obtain effect images and store the effect images in a preset effect folder, so that the first user can read the effect images and perform effect verification through the working device.

[0045] In a specific implementation scenario, to achieve accurate, objective, and remote verification of the UI display effect, the image acquisition device 14 is driven to acquire images of the display screen 13. Specifically, when a test interface image is displayed for a preset display duration, the timing module inside the embedded development board 12 will start synchronously. When the display duration of the image reaches a system-preset threshold (e.g., 50% of the display duration or 1 second before the end), the embedded development board 12 will automatically send a acquisition trigger command to the image acquisition device 14, driving it to take a standardized picture of the current display screen 13, thereby obtaining a standard effect image of the UI image under the standard display duration.

[0046] During the display of a single image, if a second user inputs an operation command such as "switch to next image" or "stop display" through the human-computer interaction interface 122, the background monitoring process of the embedded development board 12 will prioritize driving the image acquisition device 14 to perform a real-time acquisition before responding to the command and executing the screen switch. This is intended to capture the display screen at the moment when the user's focus is on the image, or to verify the screen's response effect in specific interactive scenarios, ensuring the comprehensiveness of the test data.

[0047] Then, the effect image is stored and transmitted back. The acquired effect image files are not stored in isolation, but are uniformly stored in a specially created effect folder by the embedded development board 12 according to preset rules. This folder is associated with the image folder that stores the interface images to be tested, and is remotely accessed and communicated with the working device 11 through the server 121. The file name of the effect image can be consistent with the file name of the corresponding interface image to be tested (e.g., the effect image corresponding to 001.png is named result_001.png) to ensure a one-to-one correspondence between the two, facilitating subsequent quick retrieval and comparison.

[0048] Through the aforementioned mechanism, the first user (designer) located on the work device 11 can directly access and read all effect images in the effect folder via the server 121 through their work device 11. The first user can display the original design drawings side by side with the effect images taken on the actual device, achieving pixel-level, parametric precision comparison. Through comparison, the first user can intuitively and objectively verify key indicators such as color reproduction, brightness consistency, image clarity, and layout accuracy of the UI display effect on the actual device hardware, thereby completing a complete and reliable remote UI effect verification.

[0049] In other implementation scenarios, after the embedded development board 12 has displayed all the images to be tested in the image folder in the preset display order, and has completed the acquisition and storage of the corresponding effect images, the embedded development board 12 automatically executes the system cleanup and resource release process. First, it turns off the display driver and backlight output of the display screen 13, putting the display screen 13 into a blackout state; then, it switches the entire remote test system 10 to a low-power standby mode, stops the running of unnecessary processes, and retains the background monitoring process and the listening function of the human-machine interface 122 to quickly respond to the next operation command; at the same time, it clears the image cache, parameter cache and temporary data cache generated by the embedded development board 12 during this test, releases system memory and storage resources, avoids residual data from interfering with subsequent test tasks, ensures that each test is in an independent, clean and stable operating environment, and improves the long-term reliability of the system and the accuracy of the test results.

[0050] Through the remote connection between server 121 and working device 11, remote, automatic, secure, and accurate transmission of the interface image data to be tested is achieved. This allows designers to update UI test resources at any location at any time, significantly improving the response speed of UI testing and overall R&D efficiency. Without requiring developers to manually compile and burn programs, the automatic reading and display of UI images can be triggered simply through a second user's button operation. This ensures that the display effect of the interface image on the real device screen is consistent with the final product, providing a real and reliable display foundation for subsequent image acquisition and remote verification. Through the linkage acquisition mechanism of image acquisition device 14 with display duration and operation commands, combined with the standardized storage and remote reading function of effect images, closed-loop UI testing is achieved. This ensures that the acquired effect images are real, synchronous, and traceable, allowing the first user to directly obtain objective data reflecting the display effect of the real device hardware remotely. This completely solves the technical pain points of effect distortion, difficulty in comparison, and long verification cycle caused by manual shooting, significantly improving the accuracy and efficiency of UI effect confirmation.

[0051] As described above, in this embodiment, a remote connection is established between the server and the working device. The first user can directly transmit the interface image data to be tested to a preset folder on the device without code compilation or firmware flashing, thus significantly shortening the UI iteration cycle and improving development efficiency. Designers can remotely upload interface files, and the on-site device automatically displays them according to instructions. The image acquisition device simultaneously acquires the actual display effect and transmits it back in real time, enabling multiple parties to simultaneously view the actual display of the same device from different locations. This effectively solves the problems of information transmission delay, distortion, and feedback lag in traditional methods. Furthermore, through automated acquisition and remote transmission, the process of frequent trips to the hardware site or repeated transmission of video data by all parties is reduced, lowering the manpower and communication costs in the R&D, design, and testing stages.

[0052] Please see Figure 3 , Figure 3 This is a schematic diagram of an embodiment of the remote testing device provided by the present invention. The remote testing device 20 includes a connection module 21, a display module 22, and a data acquisition module 23. The connection module 21 is used to establish a remote connection with the working device through a server, so that a first user can transmit the image data of the interface to be tested to a preset image folder; the display module 22 is used to read the image data of the interface to be tested from the image folder and display it according to a preset display order and display duration based on the operation command input by a second user; the data acquisition module 23 is used to drive the image acquisition device to acquire images of the display screen based on the display duration and / or operation command to obtain effect images, and store the effect images in a preset effect folder, so that the first user can read the effect images and perform effect verification through the working device.

[0053] The test interface image data includes the test interface image and the display parameters used when displaying the interface image; the display module 22 is used to adjust the screen parameters of the display screen according to the display parameters and then display the corresponding test interface image.

[0054] The connection module 21 is used to name the images of the interface to be tested according to the preset naming rules and then save them into the image folder.

[0055] Display module 22 is used to read the images of the interface to be tested in ascending order of their filenames.

[0056] The display module 22 is used to display the next image of the interface to be tested if it receives a switching instruction from the second user before the display duration of the current image to be tested has expired.

[0057] Display module 22 is used to turn off the display screen and drive the remote test system into standby mode after all the test interface images have been displayed; and to clear the cache of the embedded development board.

[0058] As described above, in this embodiment, a remote connection is established between the server and the working device. The first user can directly transmit the interface image data to be tested to a preset folder on the device without code compilation or firmware flashing, thus significantly shortening the UI iteration cycle and improving development efficiency. Designers can remotely upload interface files, and the on-site device automatically displays them according to instructions. The image acquisition device simultaneously acquires the actual display effect and transmits it back in real time, enabling multiple parties to simultaneously view the actual display of the same device from different locations. This effectively solves the problems of information transmission delay, distortion, and feedback lag in traditional methods. Furthermore, through automated acquisition and remote transmission, the process of frequent trips to the hardware site or repeated transmission of video data by all parties is reduced, lowering the manpower and communication costs in the R&D, design, and testing stages.

[0059] Please see Figure 4 , Figure 4 This is a schematic diagram of an embodiment of the remote testing device provided by the present invention. The remote testing device 30 includes a processor 31 and a memory 32. The processor 31 is coupled to the memory 32. The memory 32 stores a computer program, which the processor 31 executes during operation to implement the method described above. Detailed steps can be found above and will not be repeated here.

[0060] Please see Figure 5 , Figure 5This is a schematic diagram of an embodiment of the computer-readable storage medium provided by the present invention. The computer-readable storage medium 40 stores at least one computer program 41, which is executed by a processor to implement the method described above. Detailed steps can be found above and will not be repeated here. In one embodiment, the computer-readable storage medium can be a storage chip in a terminal, a hard disk, a portable hard disk, a USB flash drive, an optical disc, or other readable and writable storage tools, or even a server, etc.

[0061] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0062] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0063] It should be understood that the above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit them. Those skilled in the art can modify the technical solutions described in the above embodiments, or make equivalent substitutions for some of the technical features; and all such modifications and substitutions should fall within the protection scope of the appended claims of the present invention.

Claims

1. A method for remote testing of user interfaces, characterized in that, This is applied to a remote testing system, which includes: A working device, wherein the working device stores image data of the interface to be tested; An embedded development board is provided with a server and a human-machine interface. The server can be remotely connected to the working device, and the human-machine interface is used to receive user operation commands. A display screen, connected to the embedded development board, is used to display the image of the interface to be tested; An image acquisition device, configured to correspond to the display screen, is connected to the embedded development board and is capable of acquiring the display effect of the display screen; The remote testing method for the user interface includes: A remote connection is established between the server and the working device so that the first user can transfer the image data of the interface to be tested to a preset image folder; When an operation command is received from the second user, the image data of the interface to be tested is read from the image folder and displayed according to the preset display order and display duration based on the operation command; The image acquisition device is driven to acquire images of the display screen based on the display duration and / or the operation command, so as to obtain an effect image and store the effect image in a preset effect folder, so that the first user can read the effect image and perform effect verification through the working device.

2. The remote user interface testing method according to claim 1, characterized in that, The test interface image data includes the test interface image and the display parameters used when displaying the interface image; The step of reading and displaying the test interface image data from the image folder includes: After adjusting the screen parameters of the display screen according to the display parameters, the corresponding image of the interface to be tested is displayed.

3. The remote user interface testing method according to claim 2, characterized in that, The step of transferring the image data of the interface to be tested to the image folder includes: After naming the images of the interface to be tested according to the preset naming rules, they are saved in the image folder.

4. The remote user interface testing method according to claim 3, characterized in that, The step of reading and displaying the test interface image data from the image folder according to the preset display order and display duration based on the operation command includes: The test interface images are read in ascending order of their filenames.

5. The remote user interface testing method according to claim 2, characterized in that, The step of reading and displaying the test interface image data from the image folder according to the operation command in a preset display order and display duration further includes: If the duration of displaying the current test interface image has not yet reached the specified display duration, and a switching instruction is received from the second user, then the next test interface image is displayed according to the switching instruction.

6. The remote user interface testing method according to claim 1, characterized in that, After the step of reading the test interface image data from the image folder according to the operation command and displaying it in a preset display order and display duration, the following steps are included: Once all the images of the interface to be tested have been displayed, turn off the display screen and put the remote testing system into standby mode. Clear the cache of the embedded development board.

7. A remote testing system, characterized in that, For implementing the method as described in any one of claims 1-6, the remote testing system comprises: A working device, wherein the working device stores image data of the interface to be tested; An embedded development board is provided with a server and a human-machine interface. The server can be remotely connected to the working device, and the human-machine interface is used to receive user operation commands. A display screen, connected to the embedded development board, is used to display the image of the interface to be tested; An image acquisition device, configured to correspond to the display screen, is connected to the embedded development board and is capable of acquiring the display effect of the display screen.

8. A remote testing device, characterized in that, The remote testing system described in claim 7 includes: A connection module is used to establish a remote connection between the server and the working device, so that the first user can transfer the image data of the interface to be tested to a preset image folder; The display module is used to read the image data of the interface to be tested from the image folder and display it according to the preset display order and display duration when it receives the operation command input by the second user. The acquisition module is used to drive the image acquisition device to acquire images of the display screen based on the display duration and / or the operation command, so as to obtain effect images and store the effect images in a preset effect folder, so that the first user can read the effect images and perform effect verification through the working device.

9. A computer-readable storage medium, characterized in that, The device stores a computer program that, when executed by a processor, causes the processor to perform the steps of the method as described in any one of claims 1 to 6.

10. A remote testing device, characterized in that, It includes a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the method as described in any one of claims 1 to 6.