A test method, device, apparatus and storage medium of a device interface

Abstract

The application relates to the technical field of device testing, in particular to a device interface testing method and device, a device interface testing device and a storage medium. The application first receives a remote testing instruction through a proxy interface; then controls the proxy interface to call a native interface of a device through the testing instruction to test the native interface of the device; and finally acquires a testing result sent by the device through the proxy interface, wherein the testing result is a testing result of the native interface. As can be known from the above analysis, the application sets the proxy interface, the proxy interface records the corresponding relationship between the testing instruction and the native interface, thus the native interface of the device can be called through the proxy interface to test the native interface, thereby realizing the technical effect of remotely testing the native interface of the device. Moreover, the testing result of the application can be saved on a cloud platform through the proxy interface, thereby saving the storage space of the device.

Description

Technical Field

[0001] This invention relates to the field of equipment testing technology, specifically to a testing method, apparatus, device, and storage medium for equipment interfaces. Background Technology

[0002] Devices have many native interfaces, each representing a function of the device. Testing these native interfaces is used to test whether the device functions correctly. Current technology directly operates the native interfaces on the device to test their functionality. For example, if the device is a smart lock, when testing the smart lock's native interfaces, current technology can only test whether they are malfunctioning by directly activating the native interfaces on the smart lock itself, and cannot remotely call the native interfaces to test whether they are malfunctioning.

[0003] In summary, existing technologies cannot achieve native interfaces for remote testing equipment.

[0004] Therefore, existing technologies still need to be improved and enhanced. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a testing method, apparatus, device, and storage medium for device interfaces, resolving the issue that existing technologies cannot remotely test native device interfaces.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] In a first aspect, the present invention provides a method for testing a device interface, comprising:

[0008] Receive remote test commands through the proxy interface;

[0009] The test command controls the proxy interface to call the device's native interface in order to test the device's native interface;

[0010] The test results sent by the device are obtained through the proxy interface, and the test results are the test results of the native interface.

[0011] In one implementation, receiving remote test commands through a proxy interface includes:

[0012] The remote interface of the device is used to register a proxy interface, and the remote test command sent by the remote interface is received through the registered proxy interface.

[0013] In one implementation, the definition of the proxy interface includes:

[0014] The proxy interface is defined by defining the correspondence between remote test commands and the native interface.

[0015] In one implementation, controlling the proxy interface to call the device's native interface via the test instruction to test the device's native interface includes:

[0016] Monitor the current test process information of the native interface;

[0017] Based on the current test progress information, determine the test time;

[0018] During the test, the proxy interface is controlled by the test command to call the device's native interface in order to test the device's native interface.

[0019] In one implementation, obtaining the test results sent by the device through the proxy interface includes:

[0020] The proxy interface is used to obtain the test results sent by the device and the logs generated by the device in relation to those test results.

[0021] In one implementation, when the device is an interactive device, the step of controlling the proxy interface to call the device's native interface via the test instruction to test the device's native interface further includes:

[0022] Create a supporting service interface corresponding to the interaction object of the device;

[0023] The supporting service interface is then returned to the proxy replacement interface of the device, so that the proxy replacement interface has the function of the service interface of the interactive object;

[0024] Control the interaction between the proxy interface and the native interface to test the interactive functions of the device.

[0025] In one implementation, creating a support service interface corresponding to the interaction object of the device includes:

[0026] Obtain the test command of the service interface sent by the device through the proxy replacement interface, and create the support service interface based on the test command.

[0027] Secondly, embodiments of the present invention also provide a testing apparatus for a device interface, wherein the apparatus comprises the following components:

[0028] The instruction receiving module is used to receive remote test instructions through the proxy interface;

[0029] The sending module is used to control the proxy interface to call the device's native interface through the test command in order to test the device's native interface;

[0030] The testing module is used to obtain the test results sent by the device through the proxy interface, and the test results are the test results of the native interface.

[0031] In one implementation, the instruction receiving module includes:

[0032] The instruction receiving unit is used to register a proxy interface using the remote interface of the device, and to receive remote test instructions sent by the remote interface through the registered proxy interface.

[0033] In one implementation, a model is also included to define a proxy interface by defining the correspondence between remote test commands and the native interface.

[0034] In one implementation, the sending module includes:

[0035] A monitoring unit is used to monitor the current test process information of the native interface;

[0036] The test time calculation unit is used to determine the test time based on the current test process information;

[0037] The instruction control unit is used to control the proxy interface to call the device's native interface through the test instruction at the test time, so as to test the device's native interface.

[0038] In one implementation, the test module includes:

[0039] The testing unit is used to obtain the test results sent by the device and the logs generated by the device through the proxy interface.

[0040] In one implementation, when the device is an interactive device, it further includes:

[0041] The interface creation module is used to create supporting service interfaces corresponding to the interaction objects of the device.

[0042] An interface return module is used to return the supporting service interface to the proxy replacement interface of the device, so that the proxy replacement interface has the function of the service interface of the interactive object;

[0043] An interaction module is used to control the interaction between the proxy interface and the native interface in order to test the interactive functions of the device.

[0044] In one implementation, the interface creation module includes:

[0045] An interface creation unit is used to obtain the test instruction of the service interface sent by the device through the proxy replacement interface, and create the supporting service interface according to the test instruction.

[0046] Thirdly, embodiments of the present invention also provide a terminal device, wherein the terminal device includes a memory, a processor, and a device interface test program stored in the memory and executable on the processor, wherein when the processor executes the device interface test program, it implements the steps of the device interface test method described above.

[0047] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a test program for a device interface, wherein when the test program for the device interface is executed by a processor, the steps of the device interface testing method described above are implemented.

[0048] Beneficial effects: This invention establishes a proxy interface that records the correspondence between test commands and native interfaces. Therefore, the native interfaces of the device can be called through the proxy interface to test them, thus achieving the technical effect of remotely testing the device's native interfaces. Furthermore, the test results of this invention can be stored on a cloud platform through the proxy interface, thereby saving device storage space. Attached Figure Description

[0049] Figure 1 This is an overall flowchart of the present invention;

[0050] Figure 2 This is a schematic diagram illustrating the interaction between the controller and the device in an embodiment of the present invention;

[0051] Figure 3 This is a flowchart illustrating the construction process of the distributed testing framework in this embodiment of the invention.

[0052] Figure 4 A structural diagram of the testing device for the device interface provided by the present invention;

[0053] Figure 5 This is a block diagram illustrating the internal structure of a terminal device provided in an embodiment of the present invention. Detailed Implementation

[0054] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments and accompanying drawings. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0055] Research has revealed that devices have numerous native interfaces, each representing a specific function. Testing these native interfaces is crucial for verifying the device's functionality. Current technology involves directly manipulating these interfaces on the device itself to test their functionality. For instance, if the device is a smart lock, current technology only allows testing its native interfaces by directly activating them on the smart lock itself, rather than remotely invoking them.

[0056] To address the aforementioned technical problems, this invention provides a method, apparatus, device, and storage medium for testing device interfaces, resolving the limitation of existing technologies in remotely testing native device interfaces. In specific implementation, a remote test command is first received through a proxy interface; then, the test command controls the proxy interface to call the device's native interface to test it; finally, the test result sent by the device is obtained through the proxy interface, and the test result is the test result of the native interface. This invention, through a proxy interface, achieves the technical effect of remotely testing native interfaces.

[0057] For example, taking smart door locks as an example, the specific process of testing smart door locks using existing technology is as follows:

[0058] First, power on both the smart lock and the display screen. Once powered on, they will automatically form a network, establishing a communication channel between them. When a visitor presses the doorbell on the smart lock, the display screen's image capture function is activated to capture the visitor's face. The smart lock then recognizes the face image to determine whether to allow the visitor entry. The recognition result is the test result for the smart lock. Recognizing the face image and controlling the smart lock's opening and closing based on the recognition result is a native interface of the smart lock.

[0059] As can be seen from the above testing process of existing technologies, existing technologies require a visitor to stand in front of the smart lock and the visitor to ring the doorbell in order to test the native interface of the smart lock. The inability to test the smart lock remotely brings great inconvenience to the testing work.

[0060] To address the aforementioned technical issues, this application first creates a proxy interface (agent) within the controller on the supporting framework. The supporting framework also provides the necessary hardware and software environment for testing smart locks. The proxy interface (agent) acts as the native interface of the smart lock on the supporting framework, recording the correspondence between test commands and the native interface. When a test command (which could be "test the smart lock with a facial image") is sent to the proxy interface (agent), the agent calls the smart lock's native interface to test its facial recognition results, thereby testing the smart lock's opening and closing function based on the facial image. This allows for testing of the native interface. This application only requires the proxy interface (agent) to call the native interface; testers or visitors do not need to stand in front of the smart lock to display facial images, thus enabling remote testing of the smart lock and improving testing convenience.

[0061] The device interface testing method of this embodiment can be applied to terminal devices, which can be terminal products with data processing functions, such as test frameworks. In this embodiment, for example... Figure 1 As shown, the testing method for the device interface specifically includes the following steps:

[0062] S100 receives remote test commands through the proxy interface;

[0063] S200, the proxy interface is controlled by the test command to call the device's native interface in order to test the device's native interface;

[0064] S300, obtain the test results sent by the device through the proxy interface, the test results being the test results of the native interface.

[0065] In Example 1, before testing, a communication link needs to be established between the controller and the device (the object under test). WebSocket communication is used between the controller and the device. WebSocket communication supports full-duplex communication, meaning the controller can send commands to the device, and the device can also send commands to the controller. The specific communication process of the WebSocket protocol is as follows:

[0066] When the controller sends a request to the device, the device receives the request and sends a response, indicating a successful connection between the controller and the device. Only one connection is needed between the controller and the device for continuous data and command transmission without the need for disconnection, reconnection, or repeated operations. This allows for multiple tests between the controller and the device without requiring a communication connection for each test, thus improving testing convenience.

[0067] Using WebSocket communication between the controller and the device has the following technical advantages:

[0068] The controller can send test commands directly to the device without waiting for a connection request. After the device and controller complete their handshake, the controller can continuously send test commands to the device without needing to disconnect and reopen the connection when needed. Furthermore, because the WebSocket protocol uses a small data packet header, it consumes less memory. WebSocket offers more real-time and efficient transmission of test commands, generating smaller commands with less unnecessary information.

[0069] Example 2, as Figure 2 As shown, the agent on the controller side is the proxy interface. The proxy interface is registered using the device's remote interface. After registration, the proxy interface has the function of sending the controller's test commands to the server on the device. The remote interface is a functional interface within the OH device. The main function of this functional interface is to receive data information sent from outside the device. By registering the controller's proxy interface using this functional interface, the proxy interface acquires the function of the device's remote interface. Therefore, the controller can send test commands to the device through its proxy interface (agent) to test the device's native interface.

[0070] This embodiment also defines the correspondence between remote test commands and native interfaces. That is, the device contains several native interfaces, each with a different function. By defining a proxy interface, the correspondence between remote test commands and native interfaces is defined. In other words, when the proxy interface receives a remote test command, the proxy interface needs to know which native interface of the device is being tested.

[0071] In this embodiment, the proxy interface resides on the controller within the framework. The framework's function is to provide the necessary hardware and software environment for testing. Multiple proxy interfaces are configured on the framework, enabling simultaneous testing of the native interfaces of multiple different devices. One proxy interface can test the native interface of one device, and multiple proxy interfaces allow the framework to test the native interfaces of multiple devices simultaneously. The multiple proxy interfaces on the framework are distributed, allowing the framework to test multiple devices concurrently, thus improving testing efficiency. The distributed testing framework provides device scheduling capabilities and pre-configured hardware and software services, supporting test case development and integrating existing testing tools and frameworks. The pre-configured conditions required for testing are completed by the device requesting the host computer, eliminating the need for manual intervention. Test cases are written on the host computer to simultaneously control the testing of multiple devices. The distributed framework provides long-term stable testing services to monitor the testing status of each device over extended periods, preventing information loss and difficulties in locating the problem, thus avoiding mismatches between test results and device information. The distributed testing framework schedules the testing of each device, controlling the testing order of each device.

[0072] This embodiment's framework addresses issues in distributed communication function testing, including multi-device interaction, scenario construction, hardware and software environment dependencies, device performance monitoring, and test result collection. It also provides the ability to integrate various types of testing tools and can be used in conjunction with the testing platform's functions. The stability testing tool improves the efficiency of stability testing for testers. With the help of this tool, stability test scenarios can be quickly constructed, text test cases can be generated, and the definition of model data and testing methods can assist in locating problems during testing and collecting device performance data and test results.

[0073] The distributed testing framework of this embodiment has the following main features: resource networking, node distribution, real-time synchronization, dynamic deployment, high reliability, and good security.

[0074] Among them, resource networking means using the characteristics of the network to achieve the most basic connectivity function between multiple test nodes, realize resource sharing, and build the underlying support structure of the distributed test system.

[0075] Node distribution means that the processing nodes deployed in a distributed testing system are not only physically distributed but also logically distributed. However, the system is transparent to users; users are unaware of which processing node a specific test is occurring on. Real-time synchronization means that the distributed testing system needs to schedule the processing nodes deployed within the system, primarily for coordinating tasks to process various test information. Strict real-time synchronization between nodes and between processes is required. Dynamic deployment means that to ensure collaborative work and load balancing between testing subsystems, the distributed testing system needs to dynamically adjust the collaborative relationships between subsystems and dynamically synchronize the allocation of test tasks across systems.

[0076] It has strong fault tolerance, high reliability, and good security. Distributed testing systems generally adopt a client / server design pattern, consisting of multiple test servers and several test client terminals. The servers and clients are connected via the Internet. With the development of hardware, devices such as GPIB-ENT can be directly connected to the Internet, thus replacing test servers.

[0077] The construction of the distributed testing framework in this embodiment is as follows: Figure 3 As shown, this will include the construction of scenario models, monitoring of device performance indicators, archiving of text test cases, multi-device interaction test scenarios, preparation of pre-built software and hardware environments, and integration of automated testing tools.

[0078] MBT can be applied to embedded systems, transaction processing, communication applications, and other fields. On the other hand, MBT technology can also be applied to systems that adopt development process models such as waterfall, agile, incremental, and V-model.

[0079] MBT testing tools can simplify the construction of test scenarios, monitor the performance metrics of devices during API testing and long-term stability testing of scenario models, and generate text test cases for models, reducing the workload of testers.

[0080] In Example 3, in this example, step S200, controlling the proxy interface to call the device's native interface via the test instruction to test the device's native interface includes: monitoring the current test process information of the native interface; determining the test time based on the current test process information; and at the test time, controlling the proxy interface to call the device's native interface via the test instruction to test the device's native interface.

[0081] For example, if the device is a swivel chair, to test its swivel function, first monitor the current testing progress of the swivel chair. For instance, if the current testing progress is the lifting test, then monitor the lifting test progress. Only after the lifting test is completed should the swivel function be tested. This is because swivel and lifting are two independent functions in the actual use of the chair, and therefore these two functions need to be tested separately.

[0082] If the device includes two related functions, namely the first function and the second function, and these two functions affect each other, and the first function is currently being tested, the test progress of the first function should be monitored, and the test of the second function should begin before the test of the first function is completed.

[0083] In Example 4, in this example, step S300 involves obtaining the test results sent by the device through the proxy interface. The test results are the test results of the native interface. This includes obtaining the test results sent by the device through the proxy interface and the logs generated by the device when the test results are generated.

[0084] In other words, the device not only sends the test results to the framework, but also sends the logs generated by executing the test instructions to the framework, so that the framework can save the test results and logs. This facilitates subsequent analysis of the device's performance based on the test results and logs, and if the test results are abnormal, the logs can be used to analyze the cause of the abnormality, so that maintenance personnel can repair the device based on the cause of the abnormality.

[0085] In Example 5, when the device is an interactive device—that is, when the interactive device needs to interact with another device to achieve its function—the steps for testing the native interface of the interactive device include: obtaining the test instruction of the service interface sent by the device through the proxy replacement interface, and creating the supporting service interface according to the test instruction; returning the supporting service interface to the proxy replacement interface of the device so that the proxy replacement interface has the function of the service interface of the interactive object; controlling the proxy replacement interface and the native interface to interact to test the interactive function of the device; and controlling the proxy interface to call the native interface of the device through the test instruction to test the native interface of the device.

[0086] like Figure 2 As shown, the framework supports the execution of existing single-device test cases and provides additional callable framework support service interfaces for single-device test case execution. Devices can automatically test the required support services by calling the framework support service remote interface through a proxy.

[0087] like Figure 2The framework supports service interfaces, servers, agents, and remote interfaces. This technical approach is used to create a proxy replacement interface agent within the device. After the proxy replacement interface agent is created, execution begins. Figure 2 The technical approach involves using a proxy interface (agent), calling the native OH interface for testing, a server, and returning test results and logs to test the interaction between the interactive device and the created proxy interface (agent).

[0088] In other words, a proxy interface is first established within the device to simulate the interacting device. This involves registering the proxy interface with the supporting service remote interface provided by the framework, enabling the registered proxy interface to possess the functionality of the supporting service (i.e., the device that needs to interact with the device).

[0089] For example, the OH device being tested is a computer, and the interaction between the computer and the printer needs to be tested. Currently, only the computer is available, not the printer. If testing the computer's native interface that drives the printer is required, then a proxy interface agent needs to be registered within the OH device using the framework's supporting remote service interface. This proxy interface agent will then act as the printer driver interface. The computer also sends a request to the framework to call the supporting service (i.e., the auxiliary support service needed to test the computer's original interface) to support the test. After receiving the above request, the framework sends the corresponding service to the proxy interface agent inside the computer. All of the above work is completed before the test begins. When the test starts, the tester sends a test request to the proxy interface agent of the controller on the framework to call the computer's native interface. This invokes the proxy interface agent created inside the computer through the native interface driver to test whether the computer can drive the printer. After the test is completed, the computer sends the test results and logs back to the framework.

[0090] Example 6: The framework provides the necessary test resources for the test; that is, it provides whatever resources the test requires. Taking a smart door lock as an example, the test assesses the smart door lock's ability to open by recognizing a fingerprint or face. To test the smart door lock's noise immunity to fingerprints, the framework provides fingerprints with noise to test the smart door lock's noise immunity. Methods for adding noise to the fingerprints include:

[0091] One hundred fingerprint images were collected, each corresponding to a unique identifier. Ten seed images were also acquired for each master fingerprint through fingerprint simulation, resulting in a total of 3000 seed fingerprint images. These seed images were then converted into real fingerprint images using the CycleGAN model. To maintain consistency with the resolution and aspect ratio of the PolyU dataset images, SRGAN was used to upscale the converted images (256×256) by a factor of four. The resized images were then cropped from the center and adjusted to a resolution of 504×480, forming the final fingerprint image data. Different types of noise were added to all fingerprint images, including Gaussian noise, Rayleigh noise, gamma noise, exponentially distributed noise, uniformly distributed noise, and impulse noise.

[0092] In summary, this invention establishes a proxy interface that records the correspondence between test commands and native interfaces. Therefore, the native interfaces of the device can be invoked through the proxy interface to test them, thus achieving the technical effect of remotely testing the device's native interfaces. Furthermore, the test results of this invention can be stored on a cloud platform through the proxy interface, thereby saving device storage space.

[0093] This embodiment also provides a testing device for device interfaces, such as... Figure 4 As shown, the device comprises the following components:

[0094] Instruction receiving module 01 is used to receive remote test instructions through the proxy interface;

[0095] Sending module 02 is used to control the proxy interface to call the device's native interface through the test command in order to test the device's native interface;

[0096] Test module 03 is used to obtain the test results sent by the device through the proxy interface, and the test results are the test results of the native interface.

[0097] Based on the above embodiments, the present invention also provides a terminal device, the principle block diagram of which can be as follows: Figure 5 As shown, the terminal device includes a processor, memory, network interface, and display screen connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a device interface testing method. The display screen of the terminal device can be a liquid crystal display (LCD) or an e-ink display.

[0098] Those skilled in the art will understand that Figure 5 The schematic diagram shown is only a partial structural diagram related to the present invention and does not constitute a limitation on the terminal device to which the present invention is applied. The specific terminal device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0099] In one embodiment, a terminal device is provided, comprising a memory, a processor, and a test program for a device interface stored in the memory and executable on the processor. When the processor executes the test program for the device interface, it implements the following operation instructions:

[0100] Receive remote test commands through the proxy interface;

[0101] The test command controls the proxy interface to call the device's native interface in order to test the device's native interface;

[0102] The test results sent by the device are obtained through the proxy interface, and the test results are the test results of the native interface.

[0103] 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 computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program 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 by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can 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.

[0104] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A testing method for a device interface, characterized in that, include: By defining the correspondence between remote test commands and native interfaces, a proxy interface is defined. A proxy interface is created within the controller on the supporting framework. The remote test commands are received through the proxy interface, including: registering the proxy interface using the remote interface of the device, and receiving the remote test commands sent by the remote interface through the registered proxy interface. The proxy interface records the correspondence between test commands and native interfaces. The proxy interface has the function of a remote interface. The supporting framework is a distributed test framework with multiple proxy interfaces set up on the framework to enable simultaneous testing of the native interfaces of multiple different devices through the framework. Create a supporting service interface corresponding to the interaction object of the device; The supporting service interface is then returned to the proxy replacement interface of the device, so that the proxy replacement interface has the function of the service interface of the interactive object; Control the interaction between the proxy interface and the native interface to test the interactive functions of the device; The test command controls the proxy interface to call the device's native interface in order to test the device's native interface; The test results sent by the device are obtained through the proxy interface, and the test results are the test results of the native interface; The step of controlling the proxy interface to call the device's native interface via the test command to test the device's native interface includes: Monitor the current test process information of the native interface; Based on the current test progress information, determine the test time; During the test, the proxy interface is controlled by the test command to call the device's native interface in order to test the device's native interface.

2. The testing method for the device interface as described in claim 1, characterized in that, The step of obtaining the test results sent by the device through the proxy interface includes: The proxy interface is used to obtain the test results sent by the device and the logs generated by the device in relation to those test results.

3. The testing method for the device interface as described in claim 1, characterized in that, The creation of the support service interface corresponding to the interaction object of the device includes: Obtain the test command of the service interface sent by the device through the proxy replacement interface, and create the support service interface based on the test command.

4. A testing device for a device interface, characterized in that, The device comprises the following components: The instruction receiving module is used to define a proxy interface by defining the correspondence between remote test instructions and native interfaces. The proxy interface is created in the controller on the supporting framework and receives remote test instructions through the proxy interface. This includes: registering the proxy interface using the remote interface of the device, and receiving the remote test instructions sent by the remote interface through the registered proxy interface. The proxy interface records the correspondence between test instructions and native interfaces. The proxy interface has the function of a remote interface. The supporting framework is a distributed test framework with multiple proxy interfaces set on the framework to enable simultaneous testing of the native interfaces of multiple different devices through the framework. Create a supporting service interface corresponding to the interaction object of the device; The supporting service interface is then returned to the proxy replacement interface of the device, so that the proxy replacement interface has the function of the service interface of the interactive object; Control the interaction between the proxy interface and the native interface to test the interactive functions of the device; The sending module is used to control the proxy interface to call the device's native interface through the test command in order to test the device's native interface; The testing module is used to obtain the test results sent by the device through the proxy interface, wherein the test results are the test results of the native interface; The step of controlling the proxy interface to call the device's native interface via the test command to test the device's native interface includes: Monitor the current test process information of the native interface; Based on the current test progress information, determine the test time; During the test, the proxy interface is controlled by the test command to call the device's native interface in order to test the device's native interface.

5. A terminal device, characterized in that, The terminal device includes a memory, a processor, and a test program for the device interface stored in the memory and executable on the processor. When the processor executes the test program for the device interface, it implements the steps of the test method for the device interface as described in any one of claims 1-3.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a test program for a device interface, which, when executed by a processor, implements the steps of the device interface test method as described in any one of claims 1-3.

Images