Testing system and offline recovery method of testing machine

Abstract

The invention provides a test system and a offline recovery method of a test machine, and the test system comprises the test machine which is used for executing a test task; the server is in wired communication connection with the test machine and is used for monitoring the connection state with the test machine; the cloud is in wireless communication connection with the test machine and the server; wherein when the connection state is an offline state, the server side is further used for issuing a power-on restart instruction to the test machine through the cloud side; and when the connection state is a non-signal transmission state, the server side is also used for issuing a restart instruction to the test machine to restart a debugging bridge daemon process, or the server side reactivates a communication bus. Through the test system and the offline recovery method of the test machine provided by the invention, the offline test machine can be rapidly recovered.

Description

Technical Field

[0001] The present invention relates to a field, and in particular to a test system and a method for recovering a test machine from a disconnection. Background Art

[0002] In traditional Android device maintenance, device disconnection is a common problem. Device disconnection refers to the situation where the Android Debug Bridge (adb) on the server cannot recognize the test machine after the test machine is connected to the server via a data cable. Usually, in order to solve the problem of test machine disconnection, you need to manually unplug the data cable or manually restart the test machine to restore adb recognition.

[0003] However, in general, the machine room where the test machine is located is usually far away from the workstation, and the technician needs to go to the machine room and find the offline test machine. This not only increases the travel time, but also requires finding a specific device among many devices, which takes a long time to process. The traditional way of handling device offline has significant delays and inefficiencies. Therefore, there is room for improvement. Summary of the invention

[0004] The object of the present invention is to provide a test system and a method for recovering a test machine from offline, which can quickly recover a test machine that has been offline.

[0005] In order to solve the above technical problems, the present invention is achieved through the following technical solutions:

[0006] The present invention provides a testing system, comprising:

[0007] A testing machine, used to perform testing tasks;

[0008] A server connected to the test machine by wired communication, and used to monitor the connection status with the test machine; and

[0009] The cloud is wirelessly connected to the test machine and the server respectively;

[0010] Wherein, when the connection state is a disconnected state, the server is further used to send a power-on and restart instruction to the test machine through the cloud;

[0011] When the connection state is a state of no signal transmission, the server is further used to send a restart instruction to the test machine through the cloud to restart the debug bridge daemon process, or the server reactivates the communication bus.

[0012] In one embodiment of the present invention, after the server sends a power-on and restart instruction to the test machine through the cloud, if the connection state is still in a disconnected state after a predetermined time, the server issues a disconnected alarm message.

[0013] In one embodiment of the present invention, when the connection state is a state of no signal transmission, the server sends a self-test instruction to the test machine, and the test machine performs self-test according to the self-test instruction. When it is detected that the command line interpreter cannot respond, the server sends a restart instruction to the test machine through the cloud to restart the debug bridge daemon process of the test machine.

[0014] In one embodiment of the present invention, after the server sends a restart instruction to the test machine through the cloud, if the connection state is still in a no-signal transmission state after a predetermined time, the server sends a disconnection alarm message.

[0015] In one embodiment of the present invention, when the connection state is a state of no signal transmission, the server sends a self-test instruction to the test machine, and the test machine performs a self-test according to the self-test instruction. When the command line interpreter of the test machine is able to respond, the server reactivates the communication bus between the server and the test machine.

[0016] In one embodiment of the present invention, after the server reactivates the communication bus with the test machine, if the connection state is still in a no-signal transmission state after a predetermined time has passed, the server issues a disconnection alarm message.

[0017] In one embodiment of the present invention, the server monitors the connection status with the test machine through the heartbeat signal of the test machine. When the test machine has a heartbeat signal, the test machine is in an online state. When the test machine has no heartbeat signal, the test machine is in an offline state or a no signal transmission state.

[0018] The present invention also discloses a disconnection recovery method for a test machine, which is applied to the test system, wherein the server is connected to the test machine by wired communication, and the cloud is connected to the test machine and the server by wireless communication respectively, and the disconnection recovery method comprises:

[0019] The server monitors the connection status with the test machine;

[0020] When the connection state is offline, the server sends a power-on and restart instruction to the test machine through the cloud;

[0021] When the connection state is a state of no signal transmission, the server sends a restart instruction to the test machine to restart the debug bridge daemon process, or the server reactivates the communication bus.

[0022] In one embodiment of the present invention, the step of the server monitoring the connection status with the test machine includes:

[0023] The server determines whether the test machine has a heartbeat signal;

[0024] When the test machine has a heartbeat signal, the connection status between the server and the test machine is online;

[0025] When the test machine has no heartbeat signal, the connection status between the server and the test machine is in a disconnected state or a no signal transmission state.

[0026] In one embodiment of the present invention, when the connection state is a no-signal transmission state, the server sends a restart instruction to the test machine to restart the debug bridge daemon process, or the server reactivates the communication bus, including:

[0027] When the connection state is a state of no signal transmission, the server sends a self-check instruction to the test machine, the test machine performs a self-check according to the self-check instruction, and the server determines whether the command line interpreter of the test machine can respond normally;

[0028] When the command line interpreter fails to respond, the server sends a restart instruction to the test machine through the cloud to restart the debug bridge daemon process of the test machine;

[0029] When the command line interpreter is able to respond, the server reactivates the communication bus with the test machine.

[0030] As described above, the present invention provides a method for recovering from offline of a test system and a test machine. The real connection status of the device is monitored through the system USB bus status. Once the device is found offline, the recovery program is triggered immediately to achieve timely processing. The DeviceOwner authority is used to remotely restart the device and the adbd daemon without manual intervention, and the whole process is automated to improve processing efficiency. The device online status can be monitored in real time, and the device offline or crash can be quickly responded to, saving labor costs. The communication problem caused by the device adbd hanging and the problem that the device displays Online but the Shell pipeline is blocked and cannot communicate are solved, ensuring the continuity and stability of the system, improving the automation of device management and maintenance, and having the advantages of timely processing and high efficiency. It has broad application prospects in large-scale device management and automated operation and maintenance. .

[0031] Of course, any product implementing the present invention does not necessarily need to achieve all of the advantages described above at the same time. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for describing the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative work.

[0033] Figure 1 A schematic diagram of a test system according to an embodiment of the present invention;

[0034] Figure 2 It is a flow chart of a disconnection recovery method of a test machine in one embodiment of the present invention;

[0035] Figure 3 for Figure 2 Flow chart of step S10;

[0036] Figure 4 for Figure 2 Flow chart of step S40;

[0037] In the figure: 100, test machine; 200, server; 300, cloud. DETAILED DESCRIPTION

[0038] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0039] See also Figure 1 The present invention provides a test system that can be applied to the debugging stage of software or application (app) development and launch, which is an important step to ensure its normal functions and performance. To this end, it is usually necessary to use multiple test machines 100 for comprehensive debugging. The software or application to be tested can be installed in each test machine 100 to simulate different user environments and usage scenarios.

[0040] Furthermore, during the debugging process, real-time monitoring of the state of the test machine 100 is one of the key steps. Such monitoring may include but is not limited to the following aspects: resource usage, application logs, user behavior simulation, and error capture and reporting.

[0041] The resource usage may be represented by monitoring the usage of the CPU, memory, disk, and network resources of each test machine 100 to evaluate the performance of the software or app under different load conditions.

[0042] Application logging can be referred to as the collection and analysis of log information generated by applications to help identify potential errors or performance bottlenecks.

[0043] User behavior simulation can be expressed as simulating user operations through scripts or automation tools to verify the responsiveness and stability of the application in actual use.

[0044] Error capture and reporting can be expressed as automatically capturing errors in application operation and generating detailed error reports for developers to diagnose and fix.

[0045] Through the above monitoring methods, the stability, compatibility and performance of the software or app can be comprehensively evaluated, so as to discover and solve potential problems as much as possible before going online, ensuring that the software or application that is finally launched can meet the needs and expectations of users.

[0046] See also Figure 1 In one embodiment, in order to improve the test efficiency, a distributed test system is required to realize an automated and parallel test process by centrally controlling and managing multiple test machines 100. The test system may include multiple test machines 100, a server 200, and a cloud 300.

[0047] In one embodiment, the number of test machines 100 can be multiple. The test machine 100 is used to perform test tasks. The test machine 100 may include but is not limited to electronic devices such as smart phones, tablet computers, smart watches and other wearable devices. For example, the test machine 100 in this embodiment can be a smart phone. Smart phones are the most commonly used type of test machines, and smart phones cover various operating systems (such as iOS, Android) and different brands and models. By installing the software or application to be tested on different smart phones, the use environment of real users can be simulated to test the performance of applications on different devices.

[0048] In one embodiment, the test machine 100 may be provided with a transmission interface, and the server 200 may also be provided with a corresponding transmission interface. A limited communication connection may be achieved between the test machine 100 and the server 200 through the transmission interface. The test machine 100 may receive a test task from the server 200 through the transmission interface between the two.

[0049] In one embodiment, the server 200 can monitor the status of the test machine 100 in real time by monitoring the communication status of the transmission interface between the server 200 and the test machine 100. For example, the communication status of the transmission interface can be monitored through the device status change listener interface (IDeviceChangeListener). The IDeviceChangeListener interface can include three device states: device connected (deviceConnected), device status changed (deviceChanged), and device disconnected (deviceDisconnected).

[0050] Furthermore, deviceConnected refers to being triggered when the test machine 100 is connected, and can record detailed information about the test machine 100 connection and synchronize it to the server 200. deviceChanged refers to being triggered when the state of the test machine 100 changes, capturing changes in the state of the test machine 100 and synchronizing the new state information to the server 200. deviceDisconnected refers to being triggered when the test machine 100 is disconnected, and can record detailed information about the disconnection of the test machine 100 and synchronize the disconnection state to the server 200.

[0051] Furthermore, the server 200 can monitor the changes in the state of the test machine 100 through IDeviceChangeListener to capture the events of device connection, state change and disconnection. Whenever the change in the state of the test machine 100 is detected, the server 200 will record the detailed information of the event and upload the information to the cloud 300. After receiving the change information of the state of the test machine 100, the cloud 300 updates the device state and displays the latest device state.

[0052] In one embodiment, the server 200 may be a background server. The server 200 may be provided with an Android Debug Bridge (adb). The server 200 may use adb to identify and manage the connected test machine 100. adb is a multifunctional command line tool that allows developers to communicate with devices. Through adb, the server 200 may perform various operations, such as installing applications, executing commands, transferring files, etc.

[0053] In actual applications, the server 200 may encounter a situation where it cannot recognize the test machine 100. For example, the Android Debug Bridge Daemon (adbd) of the test machine 100 cannot communicate. For another example, the command line interpreter (Shell) of the test machine 100 cannot communicate.

[0054] Among them, adbd is a background process running on the test machine 100, responsible for processing requests from the server 200. If adbd cannot communicate, the server 200 will not be able to interact with the test machine 100, resulting in failure to identify the test machine 100. The reasons why adbd cannot communicate may include that the USB debugging mode is not enabled on the test machine 100, the adbd process is abnormally terminated or killed by the system.

[0055] Shell is an environment for executing command line instructions on the test machine 100. If the Shell cannot communicate, even if the adb connection is successful, the server 200 cannot execute commands or obtain the operating status of the test machine 100. The reasons why the Shell cannot communicate may include insufficient device permissions, incorrect Shell environment configuration, or exhaustion of system resources causing the Shell to fail to respond.

[0056] In one embodiment, when the server 200 monitors the test machine 100, a listening program can be deployed in the server 200 to receive the heartbeat signal reported by the test machine 100 and monitor the status of the test machine 100. The client program running inside the test machine 100 generates a heartbeat signal regularly, and the heartbeat signal contains information such as the unique identification of the test machine 100, the current timestamp, the CPU and memory usage, and the network connection status. This information is used to indicate the connection status between the test machine 100 and the server 200.

[0057] Specifically, the listening program deployed on the server 200 is responsible for receiving heartbeat signals from multiple test machines 100. The listening program can receive heartbeat signals through TCP / IP or HTTP protocol, and use message queues (such as RabbitMQ, Kafka, etc.) to process and transmit signals. The listening program can verify the integrity and authenticity of the heartbeat signal, and then parse the information in the signal to determine the connection status of the test machine 100. The server 200 aggregates and stores this connection status information for subsequent analysis and processing.

[0058] Furthermore, the server 200 can periodically upload the received heartbeat signal of the test machine 100 to the cloud 300 of the Alibaba Cloud platform. The upload process can be implemented through the API interface or SDK provided by Alibaba Cloud to ensure the security and reliability of data transmission. The cloud 300 can use a relational database (such as MySQL) or a NoSQL database (such as MongoDB) to store the heartbeat signal.

[0059] In one embodiment, the cloud 300 receives and stores the heartbeat signal uploaded by the server 200 and the working status information of the test machine 100 to form a central data warehouse.

[0060] For example, the cloud 300 can be configured to periodically monitor the online status of all test machines 100, that is, to determine whether they are currently online by checking the heartbeat signal update time of each test machine 100. If the cloud 300 does not receive the heartbeat signal of a test machine 100 within a specified time interval, it is determined that the test machine 100 is offline.

[0061] For another example, the server 200 can detect the connection status with the test machine 100 through the heartbeat signal of the test machine 100. When the test machine 100 has a heartbeat signal, the server 200 can consider that the test machine 100 is in an online state. When the test machine 100 has no heartbeat signal, the server 200 can consider that the test machine 200 is in an offline state or a state of no signal transmission.

[0062] In one embodiment, if a test machine 100 does not send a heartbeat signal within a specified time, the server 200 may mark the test machine 100 as offline. Once it is determined that there is an offline test machine 100, the server 200 will send a check instruction to the cloud 300, requesting to check the device status of the transmission interface (USB) connected to the offline test machine 100.

[0063] Furthermore, the server 200 will obtain the currently connected USB device list by running the lsusb command to check whether the test machine is hardware disconnected. If it is detected that the USB connection of the test machine 100 has been disconnected, it indicates that it is a hardware disconnection and further processing is required.

[0064] Furthermore, after confirming that the USB hardware of the test machine is disconnected, the server 200 will trigger a program to remotely restart the test machine. At this time, the server 200 can send a restart command to the offline test machine 100 through the cloud 300, and the restart command can be transmitted to the test machine 100 through the wireless network. Among them, the cloud 300 and the test machine 100 can be connected through a wireless network.

[0065] Furthermore, after receiving the power-on and restart command, the program running inside the offline test machine 100 executes the restart operation. The restart process triggers hardware reconnection and reestablishes the USB connection between the test machine 100 and the server 200. After the test machine 100 completes the restart and reestablishes the connection, the server 200 can run the lsusb command again to check the USB device status to ensure that the test machine is back online.

[0066] In one embodiment, the test machine 100 can complete the restart by running a program for restarting the test machine. The program for restarting the test machine can be used to restart the remote test machine to ensure that the test machine 100 can be restarted to restore to normal state when needed. The program for restarting the test machine enables the application to obtain system administrator privileges by implementing the DeviceOwner privilege. The DeviceOwner is registered through the XML configuration file, and after the device is connected to ADB, the DeviceOwner class is set through the adb shell dpm command to implement the restart operation of the device.

[0067] Of course, after the test machine 100 restarts and re-establishes the connection, the server 200 will continue to monitor the USB device status within a predetermined time (for example, 30 seconds or 1 minute). If the test machine 100 is still offline after the predetermined time, the server 200 will determine that the problem is not resolved. At this time, the server 200 can encapsulate the detailed information of the test machine 100 being offline (such as the test machine ID, offline time, inspection results, etc.) into offline alarm information, and send the offline alarm information to the cloud 300 through the API interface of the Alibaba Cloud platform. After receiving the offline alarm information, the cloud 300 stores the relevant information and updates the status of the test machine 100. The cloud 300 can trigger the alarm mechanism and notify the relevant maintenance personnel through SMS, email or other instant messaging tools to remind them to conduct subsequent inspections and processing.

[0068] In one embodiment, when the server 200 detects that the USB connection of the test machine 100 is not disconnected, that is, the connection state between the test machine 100 and the server 200 is in a state of no signal transmission, at this time, the server 200 can determine whether the command line interpreter (shell) of the test machine 100 can respond normally. For example, the server 200 can send a self-test instruction to the test machine 100, and the test machine 100 can perform a self-test according to the self-test instruction to detect whether its command line interpreter (shell) can respond normally.

[0069] Specifically, when the server 200 confirms that the connection state with the test machine 100 is a no signal transmission state, it needs to further check the command line interpreter (shell) of the test machine 100. For example, the server 200 can verify whether the shell of the test machine 100 can respond normally by executing a simple command (such as echo hello).

[0070] Furthermore, if the shell of the test machine 100 fails to respond normally within the predetermined time, it is determined that the Shell has crashed. Shell crash usually indicates that the adbd process service of the test machine 100 is interrupted. After the server 200 confirms that the Shell has crashed, the server 200 can issue a restart instruction to the test machine 100 through the cloud 300. After receiving the restart instruction, the program running inside the test machine 100 can trigger the restart program of the adbd service to trigger the restart operation of the adbd service. After the adbd service is restarted, the adb tool of the server 200 will re-establish a connection with the adbd service of the test machine 100.

[0071] In one embodiment, the restart program of the adbd service can be used to restart the adbd service of the test machine 100 to restore the communication function of the test machine 100. It is suitable for the scenario where the test machine 100 is suspended and the Shell cannot communicate and the adb daemon process is hung. The restart program of the adbd service implements a server that receives the restart instruction, which can be an HTTP service or a WebSocket service, so that the server 200 can send instructions remotely to restart the adb service of the test machine.

[0072] Further, after restarting the adbd service, the server 200 tries to communicate with the shell of the test machine 100 again to confirm that it can respond to commands normally. If the shell of the test machine 100 can respond normally, it indicates that the adbd service has returned to normal and the problem is solved.

[0073] Furthermore, if the shell of the test machine 100 still fails to respond normally after the predetermined time, the server 200 will determine that it is not resolved, and the communication status of the test machine 100 is still in a state of no signal transmission. The server 200 can encapsulate the detailed information that the command line interpreter cannot respond (such as the test machine ID, detection time, inspection results, etc.) into a disconnection alarm message. The server 200 can send the disconnection alarm information that the command line interpreter cannot respond to the cloud 300 through the API interface of the Alibaba Cloud platform. After receiving the disconnection alarm information, the cloud 300 stores the relevant information and updates the status of the test machine 100. The cloud 300 can trigger the alarm mechanism and notify the relevant maintenance personnel through SMS, email or other instant messaging tools to remind them to conduct subsequent inspections and processing.

[0074] In one embodiment, when the server 200 confirms that the connection status of the test machine 100 is a state of no signal transmission, and the shell of the test machine 100 can respond normally, it means that the test machine 100 still has other problems (such as unstable device communication). The server 200 can trigger a program to restart the USB bus to reactivate the communication bus with the test machine 100.

[0075] In one embodiment, the program for restarting the USB bus can be used to reset the connection status of the communication bus (USB bus) between the test machine 100 and the server 200 to simulate the effect of plugging and unplugging the data cable on site, such as the scenario in which the server 200 can recognize the connection status of the test machine 100, but ADB cannot recognize the test machine 100. The system classes that need to be introduced by the program for restarting the USB bus may include stdio.h, unistd.h, fcntl.h, errno.h, sys / ioctl.h, sys / ioctl.h, and linux / usbdevice_fs.h. Among them, stdio.h represents the standard input and output library. unistd.h represents the UNIX standard library, which provides access to the POSIX operating system API. fcntl.h represents the file control library, which provides operations on file descriptors. errno.h represents a header file that defines error reporting through error codes. sys / ioctl.h represents a header file that provides device control. linux / usbdevice_fs.h represents a Linux USB device file system header file.

[0076] Specifically, first, you can use the open function to open the specified USB device file path in write mode. If the file opening fails, output error information and return an error code. Then, use the ioctl function to call the USBDEVFS_RESET command to reset the USB device. If the reset fails, output error information and close the file descriptor, and return an error code. Finally, after a successful reset, close the file descriptor and return 0 to indicate success.

[0077] In one embodiment, the program for resetting the USB bus implements the reset operation of the specified test machine 100 by introducing header files such as standard input and output, UNIX standard library, file control, error handling, device control, and Linux USB device file system. The program opens the USB device file and calls the ioctl function to execute the USBDEVFS_RESET command to simulate the effect of plugging and unplugging the data cable on site. It is suitable for the scenario where the system can identify the connection status of the test machine 100 but ADB cannot identify the test machine.

[0078] In one embodiment, the server 200 can execute a USB bus restart program to simulate the hardware of the communication bus to complete the disconnection and reconnection process. After the communication bus restart is completed, the server 200 can run the lsusb command again to re-monitor the connection status of the communication bus of the test machine 100. If the connection status of the communication bus of the test machine 100 returns to normal, it indicates that the automatic recovery operation is effective.

[0079] Furthermore, if the test machine 100 is still in a state of no signal transmission after a predetermined time, the server 200 determines that the problem has not been solved. At this time, the server 200 encapsulates the detailed information of the disconnection of the transmission interface (such as the test machine ID, detection time, inspection results, etc.) into offline alarm information. The server 200 sends the offline alarm information to the cloud 300 through the API interface of the Alibaba Cloud platform. After receiving the offline alarm information, the cloud 300 stores the relevant information and updates the status of the test machine 100. The cloud 300 can trigger the alarm mechanism and notify the relevant maintenance personnel through SMS, email or other instant messaging tools to remind them to conduct subsequent inspections and processing.

[0080] It can be seen that in the above scheme, the real connection status of the device is monitored through the system USB bus status. Once the device is found to be offline, the recovery program is triggered immediately to achieve timely processing. The DeviceOwner permission is used to remotely restart the device and the adbd daemon without manual intervention, and the whole process is automated to improve processing efficiency. It can monitor the online status of the device in real time, quickly respond to the device offline or crash, and save labor costs. It solves the communication caused by the device adbd hanging and the device displays Online but the Shell pipeline is blocked and cannot communicate, ensuring the continuity and stability of the system, improving the automation of device management and maintenance, and has the advantages of timely processing and high efficiency. It has broad application prospects in large-scale device management and automated operation and maintenance.

[0081] See also Figure 2 The present invention also provides a test machine offline recovery method, which can be applied to the above test system, and the steps of the test machine offline recovery method can correspond to the above test system one by one. The test machine offline recovery method can include:

[0082] Step S10, the server monitors the connection status with the test machine;

[0083] Step S20: When the connection status is offline, the server sends a power-on and restart instruction to the test machine through the cloud;

[0084] Step S30: When the connection state is a no-signal transmission state, the server sends a restart instruction to the test machine to restart the debug bridge daemon process, or the server reactivates the communication bus;

[0085] See also Figure 3 In one embodiment, when executing step S10, specifically, step S10 may include:

[0086] Step S11, the server determines whether the test machine has a heartbeat signal;

[0087] Step S12: When the test machine has a heartbeat signal, the connection status between the server and the test machine is online;

[0088] Step S13: When there is no heartbeat signal from the test machine, the connection status between the server and the test machine is in a disconnected state or a no signal transmission state.

[0089] See also Figure 4 In one embodiment, when executing step S30, specifically, step S30 may include:

[0090] Step S41: When the connection state is a no-signal transmission state, the server sends a self-test instruction to the test machine, and the test machine performs a self-test according to the self-test instruction. The server determines whether the command line interpreter of the test machine can respond normally.

[0091] Step S42: When the command line interpreter fails to respond, the server sends a restart instruction to the test machine through the cloud to restart the debug bridge daemon process of the test machine;

[0092] Step S43: When the command line interpreter is able to respond, the server reactivates the communication bus with the test machine.

[0093] The embodiments of the present invention disclosed above are only used to help illustrate the present invention. The embodiments do not describe all the details in detail, nor do they limit the invention to the specific embodiments described. Obviously, many modifications and changes can be made according to the content of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the present invention, so that those skilled in the art can understand and use the present invention well. The present invention is limited only by the claims and their full scope and equivalents.

Claims

1. A testing system, characterized in that: include: A testing machine, used to perform testing tasks; A service end, connected to the test machine by wired communication, for monitoring the connection status with the test machine; as well as The cloud is wirelessly connected to the test machine and the server respectively; Wherein, when the connection state is a disconnected state, the server is further used to send a power-on and restart instruction to the test machine through the cloud; When the connection state is a state of no signal transmission, the server is further used to send a restart instruction to the test machine through the cloud to restart the debug bridge daemon process, or the server reactivates the communication bus.

2. The test system according to claim 1, characterized in that: After the server sends a power-on and restart instruction to the test machine through the cloud, if the connection state is still in a disconnected state after a predetermined time, the server issues a disconnected alarm message.

3. The test system according to claim 1, characterized in that: When the connection status is a state of no signal transmission, the server sends a self-test instruction to the test machine, and the test machine performs self-test according to the self-test instruction. When it is detected that the command line interpreter cannot respond, the server sends a restart instruction to the test machine through the cloud to restart the debug bridge daemon process of the test machine.

4. The test system according to claim 1, characterized in that: After the server sends a restart instruction to the test machine through the cloud, if the connection state is still in a no-signal transmission state after a predetermined time, the server sends a disconnection alarm message.

5. The test system according to claim 1, characterized in that: When the connection state is a state of no signal transmission, the server sends a self-test instruction to the test machine, and the test machine performs a self-test according to the self-test instruction. When the command line interpreter of the test machine is able to respond, the server reactivates the communication bus with the test machine.

6. The test system according to claim 1, characterized in that: After the service end reactivates the communication bus with the test machine, if the connection state is still in a no-signal transmission state after a predetermined time has passed, the service end issues a disconnection alarm message.

7. The test system according to claim 1, characterized in that: The server monitors the connection status with the test machine through the heartbeat signal of the test machine. When the test machine has a heartbeat signal, the test machine is in an online state. When the test machine has no heartbeat signal, the test machine is in an offline state or a state without signal transmission.

8. A method for recovering a test machine from offline, characterized in that: The test system applied to any one of claims 1 to 7, wherein the server is connected to the test machine by wired communication, and the cloud is connected to the test machine and the server by wireless communication respectively, and the offline recovery method comprises: The server monitors the connection status with the test machine; When the connection state is offline, the server sends a power-on and restart instruction to the test machine through the cloud; When the connection state is a state of no signal transmission, the server sends a restart instruction to the test machine to restart the debug bridge daemon process, or the server reactivates the communication bus.

9. The offline recovery method of the test machine according to claim 8, characterized in that: The step of monitoring the connection status between the server and the test machine includes: The server determines whether the test machine has a heartbeat signal; When the test machine has a heartbeat signal, the connection status between the server and the test machine is online; When the test machine has no heartbeat signal, the connection status between the server and the test machine is in a disconnected state or a no signal transmission state.

10. The offline recovery method of the test machine according to claim 8, characterized in that: When the connection state is a no-signal transmission state, the server sends a restart instruction to the test machine to restart the debug bridge daemon process, or the server reactivates the communication bus, including: When the connection state is a state of no signal transmission, the server sends a self-check instruction to the test machine, the test machine performs a self-check according to the self-check instruction, and the server determines whether the command line interpreter of the test machine can respond normally; When the command line interpreter fails to respond, the server sends a restart instruction to the test machine through the cloud to restart the debug bridge daemon process of the test machine; When the command line interpreter is able to respond, the server reactivates the communication bus with the test machine.

Images