Method, device, medium and program product for updating device status

Abstract

The purpose of this application is to provide a method, device, medium and program product for updating device status, the method comprising: by continuously running a status monitoring script, opening multiple monitoring threads in the status monitoring script to obtain the connection status of one or more test terminals relative to the test server, wherein each monitoring thread is used to obtain the connection status of test terminals corresponding to different terminal types; and updating the device status information of at least one test terminal in the background database according to the connection status. Based on the monitoring module that has been deployed or installed on the test server, this application combines multi-threading and a simple method of single-script background continuous operation to achieve multi-line automated monitoring of multiple test terminals of different terminal types and synchronous update of information to the background database, which can play an important role in both front-end device information viewing and back-end device pre-execution logic verification in APP automation implementation.

Description

Technical Field

[0001] The present application relates to the field of communications, and in particular to a technology for updating device status. Background Art

[0002] One of the difficulties in automated testing of mobile devices is device status monitoring, which involves monitoring the device's plug-in and unplug status, host connection, device serial number, platform, and operating system version. This information can be provided to third parties for review and to the APP automation platform for logical verification before scheduling the device. Existing device status monitoring technology obtains status information from a single device after connecting to the automation framework UIAutomator / WDA service. Summary of the Invention

[0003] One object of the present application is to provide a method, device, medium, and program product for updating device status.

[0004] According to one aspect of the present application, a method for updating a device status is provided, the method comprising:

[0005] By not hanging up the running status monitoring script, multiple monitoring threads are started in the status monitoring script to obtain the connection status of one or more test terminals relative to the test server, wherein each monitoring thread is used to obtain the connection status of test terminals corresponding to different terminal types;

[0006] According to the connection status, device status information of at least one test terminal in the background database is updated.

[0007] According to one aspect of the present application, a test server is provided, the test server comprising:

[0008] a module configured to, by continuously running a status monitoring script, start multiple monitoring threads in the status monitoring script to obtain the connection status of one or more test terminals relative to the test server, wherein each monitoring thread is configured to obtain the connection status of test terminals corresponding to different terminal types;

[0009] Module one or two is used to update the device status information of at least one test terminal in the background database according to the connection status.

[0010] According to one aspect of the present application, a computer device for updating device status is provided, comprising a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the operation of any of the methods described above.

[0011] According to one aspect of the present application, a computer-readable storage medium is provided, on which a computer program is stored, characterized in that when the computer program is executed by a processor, the operation of any of the methods described above is implemented.

[0012] According to one aspect of the present application, a computer program product is provided, comprising a computer program, which implements the steps of any of the above methods when executed by a processor.

[0013] Compared with the existing technology, the present application starts multiple monitoring threads in the status monitoring script to obtain the connection status of one or more test terminals relative to the test server by running the status monitoring script without hanging up, wherein each monitoring thread is used to obtain the connection status of test terminals corresponding to different terminal types; according to the connection status, the device status information of at least one test terminal in the background database is updated. Therefore, based on the monitoring module that has been deployed or installed on the test server, the present application combines multi-threading and a simple method of running a single script in the background without hanging up, so as to achieve multi-line automatic monitoring of test terminals of multiple different terminal types and synchronous update of information to the background database. It can play an important role in the front-end device information viewing and the back-end device pre-execution logic verification in the APP automation implementation. The application is flexible and scalable, and the device status of test terminals of different terminal types can be automatically monitored by a simple method of running a single script in the background without hanging up. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Other features, objects and advantages of the present application will become more apparent upon reading the detailed description of non-limiting embodiments made with reference to the following drawings:

[0015] Figure 1 A flow chart of a method for updating device status according to one embodiment of the present application is shown;

[0016] Figure 2 A structural diagram of a test server for updating device status according to one embodiment of the present application is shown;

[0017] Figure 3 A schematic diagram showing presentation of device status information of a test terminal according to one embodiment of the present application is shown;

[0018] Figure 4 A schematic diagram showing a presentation of a test terminal according to an embodiment of the present application is shown;

[0019] Figure 5 An exemplary system is shown that can be used to implement the various embodiments described in this application.

[0020] The same or similar reference numerals in the drawings represent the same or similar components. DETAILED DESCRIPTION

[0021] The present application is described in further detail below with reference to the accompanying drawings.

[0022] In a typical configuration of the present application, the terminal, the device of the service network and the trusted party all include one or more processors (eg, a central processing unit (CPU)), an input / output interface, a network interface and a memory.

[0023] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash memory. Memory is an example of a computer-readable medium.

[0024] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PCM), programmable random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device.

[0025] The devices referred to in this application include but are not limited to terminals, network devices, or devices formed by integrating terminals and network devices through a network. The terminals include but are not limited to any mobile electronic product that can interact with a user (for example, through a touchpad), such as a smartphone, a tablet computer, etc. The mobile electronic product can use any operating system, such as the Android operating system, the iOS operating system, etc. Among them, the network device includes an electronic device that can automatically perform numerical calculations and information processing according to pre-set or stored instructions, and its hardware includes but is not limited to a microprocessor, an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable gate array (FPGA), a digital signal processor (DSP), an embedded device, etc. The network device includes but is not limited to a computer, a network host, a single network server, a set of multiple network servers, or a cloud composed of multiple servers; here, the cloud is composed of a large number of computers or network servers based on cloud computing, wherein cloud computing is a type of distributed computing, a virtual supercomputer composed of a group of loosely coupled computers. The network includes but is not limited to the Internet, a wide area network, a metropolitan area network, a local area network, a VPN network, a wireless self-organizing network (Ad Hoc network), etc. Preferably, the device may also be a program running on the terminal, the network device, or a device formed by integrating the terminal and the network device, the network device, the touch terminal, or the network device and the touch terminal via a network.

[0026] Of course, those skilled in the art should understand that the above-mentioned devices are only examples, and other existing or future devices that are applicable to this application should also be included in the scope of protection of this application and are included here by reference.

[0027] In the description of the present application, “plurality” means two or more, unless otherwise clearly defined.

[0028] Figure 1A flowchart of a method for updating device status according to one embodiment of the present application is shown, comprising steps S11 and S12. In step S11, a test server continuously runs a status monitoring script, in which multiple monitoring threads are started to obtain the connection status of one or more test terminals relative to the test server, each monitoring thread being used to obtain the connection status of test terminals corresponding to different terminal types. In step S12, the test server updates the device status information of at least one test terminal in a backend database based on the connection status.

[0029] In step S11, the test server continuously runs a status monitoring script, and multiple monitoring threads are started in the status monitoring script to obtain the connection status of one or more test terminals relative to the test server, wherein each monitoring thread is used to obtain the connection status of test terminals corresponding to different terminal types. In some embodiments, it is necessary to deploy an adb environment and install a tidevice tool library (including a monitoring module) on the test server, wherein the adb environment includes an adbutils tool library (including a monitoring module). In some embodiments, the status monitoring script includes but is not limited to scripts of any form, for example, the status monitoring script can be a Python script. In some embodiments, continuously running the status monitoring script means that the status monitoring script is continuously running in the background of the test server. If the status monitoring script is a Python script, the nohup command can be used to continuously run the status monitoring script. In some embodiments, multiple monitoring threads are started in the status monitoring script to continuously obtain the current connection status of one or more test terminals relative to the test server, wherein each test terminal can establish a connection to the test server via a wireless method (e.g., WiFi), or can also establish a connection to the test server via a wired method (e.g., USB). In some embodiments, each monitoring thread is used to monitor the connection status of test terminals of different terminal types relative to the test server, that is, for each terminal type, a corresponding monitoring thread is started to obtain the connection status of at least one test terminal corresponding to the terminal type relative to the test server. For example, two monitoring threads, android_monitor (Android monitoring thread) and ios_monitor (Apple monitoring thread), are started in the status monitoring script to respectively obtain the connection status of at least one Android test terminal and at least one Apple test terminal relative to the server. In some embodiments, each monitoring thread obtains the connection status of at least one test terminal corresponding to the terminal type relative to the test server by calling the monitoring module corresponding to the terminal type supported by the monitoring thread. In some embodiments, the connection status includes but is not limited to multiple states such as the current connection is normal (adb is available), the current connection is not connected, the USB debugging is not currently enabled, and the current connection is in a state but adb is not available.

[0030] In step S12, the test server updates the device status information of at least one test terminal in the backend database based on the connection status. In some embodiments, the backend database may be located in the test server, or may also be located in another server. In some embodiments, for each test terminal's connection status acquired by the status monitoring script, the test terminal's current device status information may be the same as the connection status, or the current device status information mapped to the connection status may be obtained based on a predetermined mapping relationship. In some embodiments, device status information includes, but is not limited to, device available, device unavailable, etc. In some embodiments, for each test terminal's current device status information, a query is made in the backend database to determine whether a record for the test terminal exists. If not, the current device status information is directly inserted. If so, the device status information of the test terminal in the backend database is directly updated based on the current device status information. Specifically, the update logic may detect whether the test terminal's current device status information is the same as the device status information of the test terminal in the backend database. If different, the device status information of the test terminal in the backend database is updated to the current device status information. If the same, no update is required. This application is based on the monitoring module that has been deployed or installed on the test server, and combines multi-threading and a simple method of single script running in the background without hanging up to achieve multi-line automatic monitoring of test terminals of multiple different terminal types and synchronous update of information to the background database. It can play an important role in the front-end device information viewing and back-end device pre-execution logic verification in the APP automation implementation. The application is flexible and scalable, and through the simple method of single script running in the background without hanging up, it can achieve automatic monitoring of the device status of test terminals of different terminal types.

[0031] In some embodiments, the terminal type includes at least one of the following: an Android terminal; an Apple terminal. In some embodiments, an Android terminal includes but is not limited to any terminal using the Android system, such as an Android phone, an Android computer, an Android tablet, an Android wearable device, etc., and an Apple terminal includes but is not limited to any terminal using the Apple system, such as an Apple phone, an Apple computer, an Apple tablet, an Apple wearable device, etc.

[0032] In some embodiments, the status monitoring script includes configuration information of the background database; wherein, the method further includes: the test server connects to the background database based on the configuration information in the status monitoring script; wherein, the step S12 includes: updating the device status information of at least one test terminal in the connected background database according to the connection status. In some embodiments, the tester can configure the configuration information of the background database in the status monitoring script, and the configuration information includes but is not limited to the IP address, port number, user name, table name, etc. corresponding to the background database, and then the subsequent test server will connect to the corresponding background database based on the configuration information when running the status monitoring script. In some embodiments, when the status monitoring script connects to the background database, the user (tester) will be required to manually enter the sensitive information of the background database such as the connection password in a non-plaintext manner. For example, the connection password of the background database can be entered through the python-getpass module.

[0033] In some embodiments, the method further includes step S13 (not shown). In step S13, the test server calls the first target method in the monitoring module corresponding to the terminal type supported by the monitoring thread in the monitoring thread for each monitoring thread, and obtains the connection status of at least one test terminal corresponding to the terminal type relative to the test server. In some embodiments, for each monitoring thread, a target method provided by the monitoring module corresponding to the terminal type supported (or corresponding) by the monitoring thread is called in the monitoring thread to obtain the data object output by the target method, and the connection status of at least one test terminal corresponding to the terminal type relative to the test server is obtained by parsing the data object, wherein the monitoring module needs to be deployed or installed on the test server in advance. In some embodiments, for the Android monitoring thread, the track_devices() method of the AdbClient class under the adbutils module is called to iteratively output the DeviceEvent object, and then the connection status of at least one Android test device relative to the test server is obtained by parsing the DeviceEvent object. In some embodiments, for the Apple monitoring thread, by calling the watch_device() method of the Usbmux class under the tidevice module, iteratively outputting a dict-data object, and then parsing the dict-data object to obtain the connection status of at least one Apple test device relative to the test server.

[0034] In some embodiments, step S13 includes: for each monitoring thread, calling a first target method in a monitoring module corresponding to a terminal type supported by the monitoring thread once at a predetermined time interval in the monitoring thread, and obtaining the connection status of at least one test terminal corresponding to the terminal type relative to the test server as returned by the first target method. In some embodiments, for each monitoring thread, a target method provided by a monitoring module corresponding to a terminal type supported by the monitoring thread may be called once at a predetermined time interval (e.g., 1 minute) in the monitoring thread, and obtaining the connection status of at least one test terminal corresponding to the terminal type relative to the test server as returned by the target method each time.

[0035] In some embodiments, step S13 includes: for each monitoring thread, calling a second target method in the monitoring module corresponding to the terminal type supported by the monitoring thread in the monitoring thread, obtaining the connection status of at least one test terminal corresponding to the terminal type with respect to the test server, which is called back by the second target method, wherein the monitoring module calls back the second target method once each time the connection status of a test terminal changes. In some embodiments, for each monitoring thread, only a target method provided by the monitoring module corresponding to the terminal type supported by the monitoring thread needs to be called back once in the monitoring thread to obtain the connection status of at least one test terminal corresponding to the terminal type with respect to the test server, which is continuously called back by the target method, wherein each time the connection status of a test terminal changes (for example, a new test terminal establishes a connection with the test server, for example, a test terminal that has established a connection with the test server disconnects from the test server, or for example, a test terminal's current connection status with respect to the test server changes), the monitoring module automatically calls back the current connection status of the test terminal to the monitoring thread through the target method.

[0036] In some embodiments, the step S12 also includes: the test server searches the background database for device records of the one or more test terminals; if there is no device record of the target test terminal and the target device status information corresponding to the connection status of the target test terminal is that the device is available, by calling the third target method in the monitoring module corresponding to the terminal type of the target test terminal, the hardware details information of the target test terminal returned by the third target method is obtained, and the hardware details information and the target device status information are inserted into the background database as device records of the target test terminal; otherwise, according to the connection status, the device status information of at least one test terminal in the background database is updated. In some embodiments, for the connection status of one or more test terminals obtained, a search is first performed to determine whether there are records of the one or more test terminals in the background database. If there is a record of a target test terminal among the one or more test terminals in the background database and the target device status information corresponding to the connection status of the target test terminal is "device available," a target method provided by a monitoring module (e.g., an adbutils module or a tidevice module) corresponding to the terminal type of the target test terminal is called to obtain hardware details of the target test terminal returned by the target method. The hardware details information includes, but is not limited to, terminal type, brand, model, operating system version, bootloader, SDK, mode, ABI, and other information. The hardware details information and the target device status information are then inserted into the background database. In some embodiments, if there is no record of a test terminal in the background database, the device status information of the test terminal in the background database is directly updated based on the connection status of the test terminal.

[0037] In some embodiments, updating the device status information of at least one test terminal in the background database according to the connection status includes: determining the current device status information corresponding to the connection status; and updating the device status information of at least one test terminal in the background database to the current device status information. In some embodiments, for each test terminal, the current device status information mapped by the connection status is first determined according to a pre-set mapping relationship, and then the device status information of the test terminal in the background database is updated to the current device status information. In some embodiments, the device status information mapped to the current normal connection status is device available, and the device status information mapped to other connection statuses such as currently not connected, currently not enabled for USB debugging, currently connected but adb unavailable, etc. is device unavailable. In some embodiments, the current device status information is first monitored to see if it is the same as the device status information of the test terminal in the background database. If they are not the same, the device status information of the test terminal in the background database is updated to the current device status information. If they are the same, no update is required.

[0038] In some embodiments, the method further includes step S14 (not shown). In step S14, the test server performs exception capture on at least one monitoring thread in the status monitoring script. If an exception is detected in the target monitoring thread, the target monitoring thread is reopened. In some embodiments, exception capture is performed on each monitoring thread in the status monitoring script. If an exception is detected in the monitoring thread, the monitoring thread cannot continue to monitor the connection status of the test terminal, and the monitoring thread needs to be reopened in the status monitoring script.

[0039] In some embodiments, step S14 includes: the test server captures an exception of the target monitoring thread used to obtain the connection status of the Apple terminal in the status monitoring script, and if an exception is detected in the target monitoring thread, restarts the USB-TCP conversion service and reopens the target monitoring thread. In some embodiments, the Apple monitoring thread is captured for an exception, and if an exception is detected in the monitoring thread, the USB-TCP conversion (usbmuxd) service on which the tidevice module depends is not stable and often generates exceptions such as ConnectionRefusedError / UsbMuxdError, causing the monitoring thread to have an exception and making it impossible to continue monitoring the connection status of the Apple test terminal. In this case, it is necessary to restart the usbmuxd service and reopen the monitoring thread in the status monitoring script.

[0040] In some embodiments, the method further includes: the test server presenting the device status information of one or more test terminals in the background database to the user. In some embodiments, the test server can present the device status information of one or more test terminals in the background database to the user (tester) through the front end of the automated testing platform. As an example, Figure 3 As shown, in addition to presenting the device status information of one or more test terminals in the background database to the user, the front end of the automated test platform also presents the hardware details information of each test terminal to the user.

[0041] In some embodiments, the method further includes step S15 (not shown). In step S15, in response to a user creating a test project, the test server presents to the user identification information of at least one test terminal whose corresponding device status information in the background data is available for the device, so that the user can select a test terminal to be used for the test project. In some embodiments, in response to a user creating a test project, the test server presents to the user (tester) identification information of at least one test terminal whose corresponding device status information in the background database is available for the device on the creation page of the test project through the front end of the automated testing platform, such identification information including but not limited to the terminal type, terminal brand, terminal model, terminal operating system version, etc. of the test terminal, so that the user can select one of the at least one test terminals as a test terminal to be used for the test project.

[0042] In some embodiments, the step S15 includes: in response to a user creating a test project, the test server presents to the user, based on the project type corresponding to the test project, identification information of at least one test terminal in the background data that matches the project type and whose corresponding device status information is available for the device, so that the user can select a test terminal to be used for the test project. In some embodiments, based on the project type corresponding to the created test project, identification information of at least one test terminal in the background data that matches the project type and whose corresponding device status information is available for the device is presented to the user (tester). As an example, Figure 4 As shown, if the project type is an Android automation project, the test terminal that matches it is an Android test terminal, and the identification information of at least one Android test terminal is presented to the user at the front end of the automated testing platform, so that the user can select one of the at least one Android test terminals as the test terminal to be used for the test project. If the project type is an IOS automation project, the test terminal that matches it is an Apple test terminal, and the identification information of at least one Apple test terminal is presented to the user at the front end of the automated testing platform, so that the user can select one of the at least one Apple test terminals as the test terminal to be used for the test project.

[0043] In some embodiments, the method further includes: the test server, in response to the execution trigger event corresponding to the test task, obtains the device status information of the test terminal used by the test task from the background database, and starts executing the test task if the device status information indicates that the device is available. In some embodiments, before the test task is executed, the device status information of the test terminal used by the test task is first obtained from the background database. If the device status information indicates that the device is available, the test task is started; if the device status information indicates that the device is unavailable, the test task is not started, and the user (tester) is prompted through the front end of the automated testing platform that the test terminal used by the test task is unavailable.

[0044] In some embodiments, the starting execution of the test task includes: obtaining the operating status information of the test terminal from the background database; if the operating status information is unlocked, starting the test task and updating the operating status information of the test terminal in the background database to locked; in response to the completion of the test task execution, updating the operating status information of the test terminal in the background database to unlocked. In some embodiments, the operating status information of the test terminal used for the test task is first obtained from the background database; if the operating status information is locked, the execution of the test task is paused or terminated, and the user (tester) is prompted through the front end of the automated testing platform that the test terminal used for the test task is locked; if the operating status information is unlocked, starting the test task and updating the operating status information of the test terminal in the background database to locked. Then, after the execution of the test task is completed, the operating status information of the test terminal in the background database is updated to unlocked.

[0045] Figure 2 A structural diagram of a test server for updating device status according to one embodiment of the present application is shown. The test server includes a first module 11 and a second module 12. Module 11 is configured to continuously run a status monitoring script, thereby starting multiple monitoring threads within the status monitoring script to obtain the connection status of one or more test terminals relative to the test server, wherein each monitoring thread is configured to obtain the connection status of test terminals corresponding to different terminal types. Module 12 is configured to update the device status information of at least one test terminal in a background database based on the connection status.

[0046] Module 11 is configured to execute a status monitoring script without interruption, and to initiate multiple monitoring threads in the status monitoring script to obtain the connection status of one or more test terminals relative to the test server, wherein each monitoring thread is configured to obtain the connection status of test terminals corresponding to different terminal types. In some embodiments, it is necessary to deploy an ADB environment and install the Tidevice tool library (including a monitoring module) on the test server, wherein the ADB environment includes the AdButils tool library (including a monitoring module). In some embodiments, the status monitoring script includes, but is not limited to, any script format; for example, the status monitoring script can be a Python script. In some embodiments, executing the status monitoring script without interruption means continuously executing the status monitoring script in the background of the test server. If the status monitoring script is a Python script, the nohup command can be used to execute the status monitoring script without interruption. In some embodiments, multiple monitoring threads are initiated in the status monitoring script to continuously obtain the current connection status of one or more test terminals relative to the test server. Each test terminal can establish a connection to the test server wirelessly (e.g., via WiFi) or wiredly (e.g., via USB). In some embodiments, each monitoring thread is used to monitor the connection status of test terminals of different terminal types relative to the test server, that is, for each terminal type, a corresponding monitoring thread is started to obtain the connection status of at least one test terminal corresponding to the terminal type relative to the test server. For example, two monitoring threads, android_monitor (Android monitoring thread) and ios_monitor (Apple monitoring thread), are started in the status monitoring script to respectively obtain the connection status of at least one Android test terminal and at least one Apple test terminal relative to the server. In some embodiments, each monitoring thread obtains the connection status of at least one test terminal corresponding to the terminal type relative to the test server by calling the monitoring module corresponding to the terminal type supported by the monitoring thread. In some embodiments, the connection status includes but is not limited to multiple states such as the current connection is normal (adb is available), the current connection is not connected, the USB debugging is not currently enabled, and the current connection is in a state but adb is not available.

[0047] Module 12 is configured to update the device status information of at least one test terminal in a backend database based on the connection status. In some embodiments, the backend database may be located in a test server, or may also be located in another server. In some embodiments, for each test terminal's connection status acquired by the status monitoring script, the test terminal's current device status information may be the same as the connection status, or the current device status information mapped to the connection status may be obtained based on a predetermined mapping relationship. In some embodiments, device status information includes, but is not limited to, device available, device unavailable, etc. In some embodiments, for each test terminal's current device status information, a query is made to the backend database to determine whether a record for the test terminal exists. If not, the current device status information is directly inserted. If so, the device status information of the test terminal in the backend database is directly updated based on the current device status information. Specifically, the update logic may include detecting whether the test terminal's current device status information is the same as the device status information of the test terminal in the backend database. If different, the device status information of the test terminal in the backend database is updated to the current device status information. If the same, no update is required. This application is based on the monitoring module that has been deployed or installed on the test server, and combines multi-threading and a simple method of single script running in the background without hanging up to achieve multi-line automatic monitoring of test terminals of multiple different terminal types and synchronous update of information to the background database. It can play an important role in the front-end device information viewing and back-end device pre-execution logic verification in the APP automation implementation. The application is flexible and scalable, and through the simple method of single script running in the background without hanging up, it can achieve automatic monitoring of the device status of test terminals of different terminal types.

[0048] In some embodiments, the terminal type includes at least one of the following: Android terminal; Apple terminal. Figure 1 The embodiments shown are the same or similar and therefore will not be described in detail, but are incorporated herein by reference.

[0049] In some embodiments, the status monitoring script includes configuration information of the background database; wherein the test server is further used to: connect to the background database based on the configuration information in the status monitoring script; wherein the first and second modules 12 are used to: update the device status information of at least one test terminal in the background database that has been connected according to the connection status. Figure 1 The embodiments shown are the same or similar and therefore will not be described in detail, but are incorporated herein by reference.

[0050] In some embodiments, the test server further includes a module 13 (not shown). The module 13 is configured to, for each monitoring thread, call the first target method in the monitoring module corresponding to the terminal type supported by the monitoring thread in the monitoring thread to obtain the connection status of at least one test terminal corresponding to the terminal type relative to the test server. Figure 1 The embodiments shown are the same or similar and therefore will not be described in detail, but are incorporated herein by reference.

[0051] In some embodiments, the first three modules 13 are used to: for each monitoring thread, call the first target method in the monitoring module corresponding to the terminal type supported by the monitoring thread once at a predetermined time interval in the monitoring thread, and obtain the connection status of at least one test terminal corresponding to the terminal type relative to the test server returned by the first target method. Figure 1 The embodiments shown are the same or similar and therefore will not be described in detail, but are incorporated herein by reference.

[0052] In some embodiments, the one-three module 13 is used to: for each monitoring thread, call the second target method in the monitoring module corresponding to the terminal type supported by the monitoring thread in the monitoring thread, and obtain the connection status of at least one test terminal corresponding to the terminal type with respect to the test server called back by the second target method, wherein the monitoring module calls back the second target method once each time a change in the connection status of a test terminal is obtained. Figure 1 The embodiments shown are the same or similar and therefore will not be described in detail, but are incorporated herein by reference.

[0053] In some embodiments, the one-two module 12 is further used to: search whether there is a device record of the one or more test terminals in the background database; if there is no device record of the target test terminal and the target device status information corresponding to the connection status of the target test terminal is that the device is available, by calling the third target method in the monitoring module corresponding to the terminal type of the target test terminal, obtain the hardware details information of the target test terminal returned by the third target method, insert the hardware details information and the target device status information as the device record of the target test terminal into the background database; otherwise, update the device status information of at least one test terminal in the background database according to the connection status. Here, the relevant operations are the same as Figure 1 The embodiments shown are the same or similar and therefore will not be described in detail, but are incorporated herein by reference.

[0054] In some embodiments, the updating of the device status information of at least one test terminal in the background database according to the connection status includes: determining the current device status information corresponding to the connection status; and updating the device status information of at least one test terminal in the background database to the current device status information. Figure 1 The embodiments shown are the same or similar and therefore will not be described in detail, but are incorporated herein by reference.

[0055] In some embodiments, the test server further includes a module 14 (not shown). The module 14 is used to capture an exception of at least one monitoring thread in the status monitoring script, and if an exception is captured in the target monitoring thread, reopen the target monitoring thread. Figure 1 The embodiments shown are the same or similar and therefore will not be described in detail, but are incorporated herein by reference.

[0056] In some embodiments, the module 14 is used to: in the status monitoring script, capture an exception in the target monitoring thread used to obtain the connection status of the Apple terminal, and if an exception is detected in the target monitoring thread, restart the USB-TCP conversion service and reopen the target monitoring thread. Figure 1 The embodiments shown are the same or similar and therefore will not be described in detail, but are incorporated herein by reference.

[0057] In some embodiments, the test server is further configured to present the device status information of one or more test terminals in the background database to the user. Figure 1 The embodiments shown are the same or similar and therefore will not be described in detail, but are incorporated herein by reference.

[0058] In some embodiments, the test server further includes a module 15 (not shown). The module 15 is configured to, in response to a user creating a test project, present to the user identification information of at least one test terminal whose corresponding device status information in the background data is available for the device, so that the user can select a test terminal to be used for the test project. Figure 1 The embodiments shown are the same or similar and therefore will not be described in detail, but are incorporated herein by reference.

[0059] In some embodiments, the module 15 is used to: in response to a user creating a test project, present to the user, according to the project type corresponding to the test project, identification information of at least one test terminal in the background data that matches the project type and whose corresponding device status information is available for the device, so that the user can select the test terminal to be used for the test project. Figure 1The embodiments shown are the same or similar and therefore will not be described in detail, but are incorporated herein by reference.

[0060] In some embodiments, the test server is further configured to: in response to an execution trigger event corresponding to the test task, obtain device status information of the test terminal used by the test task from the background database, and start executing the test task if the device status information indicates that the device is available. Figure 1 The embodiments shown are the same or similar and therefore will not be described in detail, but are incorporated herein by reference.

[0061] In some embodiments, the starting of the test task includes: obtaining the operating status information of the test terminal from the background database; if the operating status information is unlocked, starting the test task and updating the operating status information of the test terminal in the background database to locked; in response to the end of the test task execution, updating the operating status information of the test terminal in the background database to unlocked. Figure 1 The embodiments shown are the same or similar and therefore will not be described in detail, but are incorporated herein by reference.

[0062] In addition to the methods and devices described in the above embodiments, the present application also provides a computer-readable storage medium, which stores computer code. When the computer code is executed, the method described in any of the above items is executed.

[0063] The present application also provides a computer program product. When the computer program product is executed by a computer device, the method described in any one of the preceding items is executed.

[0064] The present application also provides a computer device, comprising:

[0065] one or more processors;

[0066] a memory for storing one or more computer programs;

[0067] When the one or more computer programs are executed by the one or more processors, the one or more processors are caused to implement the method as described in any one of the preceding items.

[0068] Figure 5 shows an exemplary system that can be used to implement the various embodiments described in this application;

[0069] like Figure 5In some embodiments, the system 300 can function as any of the devices described in the various embodiments. In some embodiments, the system 300 can include one or more computer-readable media (e.g., system memory or NVM / storage device 320) having instructions and one or more processors (e.g., processor(s) 305) coupled to the one or more computer-readable media and configured to execute the instructions to implement the modules and thereby perform the actions described herein.

[0070] For one embodiment, system control module 310 may include any suitable interface controller to provide any suitable interface to at least one of processor(s) 305 and / or any suitable device or component in communication with system control module 310 .

[0071] The system control module 310 may include a memory controller module 330 to provide an interface to the system memory 315. The memory controller module 330 may be a hardware module, a software module, and / or a firmware module.

[0072] System memory 315 can be used, for example, to load and store data and / or instructions for system 300. For one embodiment, system memory 315 can include any suitable volatile memory, such as a suitable DRAM. In some embodiments, system memory 315 can include double data rate type four synchronous dynamic random access memory (DDR4 SDRAM).

[0073] For one embodiment, system control module 310 may include one or more input / output (I / O) controllers to provide interfaces to NVM / storage device 320 and communication interface(s) 325 .

[0074] For example, NVM / storage 320 may be used to store data and / or instructions. NVM / storage 320 may include any suitable non-volatile memory (e.g., flash memory) and / or may include any suitable non-volatile storage device(s) (e.g., one or more hard disk drives (HDDs), one or more compact disk (CD) drives, and / or one or more digital versatile disk (DVD) drives).

[0075] NVM / storage device 320 may include storage resources that are physically part of the device on which system 300 is installed, or it may be accessible to the device without being part of the device. For example, NVM / storage device 320 may be accessed over a network via communication interface(s) 325.

[0076] Communication interface(s) 325 may provide an interface for system 300 to communicate over one or more networks and / or with any other suitable devices. System 300 may wirelessly communicate with one or more components of a wireless network in accordance with any of one or more wireless network standards and / or protocols.

[0077] For one embodiment, at least one of the processor(s) 305 may be packaged together with the logic of one or more controllers of the system control module 310 (e.g., the memory controller module 330). For one embodiment, at least one of the processor(s) 305 may be packaged together with the logic of one or more controllers of the system control module 310 to form a system-in-package (SiP). For one embodiment, at least one of the processor(s) 305 may be integrated on the same die with the logic of one or more controllers of the system control module 310. For one embodiment, at least one of the processor(s) 305 may be integrated on the same die with the logic of one or more controllers of the system control module 310 to form a system-on-chip (SoC).

[0078] In various embodiments, system 300 may be, but is not limited to, a server, a workstation, a desktop computing device, or a mobile computing device (e.g., a laptop computing device, a handheld computing device, a tablet computer, a netbook, etc.). In various embodiments, system 300 may have more or fewer components and / or a different architecture. For example, in some embodiments, system 300 includes one or more cameras, a keyboard, a liquid crystal display (LCD) screen (including a touchscreen display), a non-volatile memory port, multiple antennas, a graphics chip, an application-specific integrated circuit (ASIC), and a speaker.

[0079] It should be noted that the application can be implemented in software and / or a combination of software and hardware, for example, can be implemented using an application specific integrated circuit (ASIC), a general purpose computer or any other similar hardware device. In one embodiment, the software program of the application can be executed by a processor to realize the steps or functions described above. Similarly, the software program of the application (including relevant data structures) can be stored in a computer-readable recording medium, for example, a RAM memory, a magnetic or optical drive or a floppy disk and similar devices. In addition, some steps or functions of the application can be implemented using hardware, for example, as a circuit that cooperates with a processor to perform each step or function.

[0080] In addition, a part of the present application may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present application through the operation of the computer. Those skilled in the art should understand that the form in which the computer program instruction exists in a computer-readable medium includes but is not limited to a source file, an executable file, an installation package file, etc. Accordingly, the way in which the computer program instruction is executed by the computer includes but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium that can be accessed by the computer.

[0081] Communication media include media by which communication signals containing, for example, computer-readable instructions, data structures, program modules, or other data are transmitted from one system to another. Communication media may include guided transmission media such as cables and wires (e.g., fiber optic, coaxial, etc.) and wireless (unguided transmission) media capable of propagating energy waves, such as acoustic, electromagnetic, RF, microwave, and infrared. Computer-readable instructions, data structures, program modules, or other data may be embodied as, for example, a modulated data signal in a wireless medium such as a carrier wave or similar mechanism such as that embodied as part of spread spectrum technology. The term "modulated data signal" refers to a signal that has one or more of its characteristics changed or set in such a manner as to encode information in the signal. Modulation may be analog, digital, or a hybrid modulation technique.

[0082] By way of example and not limitation, computer-readable storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. For example, computer-readable storage media include, but are not limited to, volatile memory, such as random access memory (RAM, DRAM, SRAM); and non-volatile memory, such as flash memory, various read-only memories (ROM, PROM, EPROM, EEPROM), magnetic and ferromagnetic / ferroelectric memories (MRAM, FeRAM); and magnetic and optical storage devices (hard disks, magnetic tapes, CDs, DVDs); or other media now known or later developed that can store computer-readable information / data for use by a computer system.

[0083] Here, according to one embodiment of the present application, a device is included, which includes a memory for storing computer program instructions and a processor for executing the program instructions, wherein, when the computer program instructions are executed by the processor, the device is triggered to run the methods and / or technical solutions based on the aforementioned multiple embodiments of the present application.

[0084] It is obvious to those skilled in the art that the present application is not limited to the details of the above-mentioned exemplary embodiments, and that the present application can be implemented in other specific forms without departing from the spirit or basic characteristics of the present application. Therefore, from any point of view, the embodiments should be regarded as exemplary and non-restrictive, and the scope of the present application is defined by the appended claims rather than the above description, and it is intended that all changes that fall within the meaning and scope of the equivalent elements of the claims are included in the present application. Any figure mark in the claims should not be regarded as limiting the claims involved. In addition, it is obvious that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices stated in the device claim can also be implemented by one unit or device through software or hardware. Words such as first and second are used to indicate names and do not indicate any particular order.

Claims

1. A method for updating device status, applied to a test server, wherein: The method includes: By continuously running a status monitoring script, multiple monitoring threads are started in the status monitoring script to obtain the connection status of multiple test terminals relative to the test server, wherein each monitoring thread is used to obtain the connection status of test terminals corresponding to different terminal types. The status monitoring script is run in the background of the test server, and for each terminal type, a corresponding monitoring thread is started to obtain the connection status of multiple test terminals corresponding to the terminal type relative to the test server; updating device status information of at least one test terminal in a background database according to the connection status; The method further comprises: For each monitoring thread, the first target method in the monitoring module corresponding to the terminal type supported by the monitoring thread is called in the monitoring thread to obtain the connection status of at least one test terminal corresponding to the terminal type relative to the test server, wherein the connection status is obtained by parsing the data object output by the first target method, and the monitoring module is deployed or installed on the test server in advance.

2. The method according to claim 1, wherein The terminal type includes at least one of the following: Android terminal; Apple Terminal.

3. The method according to claim 1, wherein The status monitoring script includes configuration information of the backend database; The method further comprises: Connecting to a backend database based on the configuration information in the status monitoring script; Wherein, updating the device status information of at least one test terminal in the background database according to the connection status includes: According to the connection status, the device status information of at least one test terminal in the connected background database is updated.

4. The method according to claim 1, wherein For each monitoring thread, calling, in the monitoring thread, a first target method in a monitoring module corresponding to a terminal type supported by the monitoring thread, to obtain a connection status of at least one test terminal corresponding to the terminal type relative to the test server, includes: For each monitoring thread, the first target method in the monitoring module corresponding to the terminal type supported by the monitoring thread is called once at a predetermined time interval in the monitoring thread to obtain the connection status of at least one test terminal corresponding to the terminal type relative to the test server returned by the first target method.

5. The method according to claim 1, wherein For each monitoring thread, calling, in the monitoring thread, a first target method in a monitoring module corresponding to a terminal type supported by the monitoring thread, to obtain a connection status of at least one test terminal corresponding to the terminal type relative to the test server, includes: For each monitoring thread, a second target method in the monitoring module corresponding to the terminal type supported by the monitoring thread is called in the monitoring thread to obtain the connection status of at least one test terminal corresponding to the terminal type relative to the test server, which is called back by the second target method. The monitoring module calls back the second target method once each time a change in the connection status of a test terminal is obtained.

6. The method according to claim 1, wherein The updating of the device status information of at least one test terminal in the background database according to the connection status further includes: Searching a backend database for device records of the plurality of test terminals; if no device record of the target test terminal exists and the target device status information corresponding to the connection status of the target test terminal indicates that the device is available, invoking a third target method in a monitoring module corresponding to the terminal type of the target test terminal to obtain hardware details information of the target test terminal returned by the third target method, and inserting the hardware details information and the target device status information into the backend database as the device record of the target test terminal; Otherwise, the device status information of at least one test terminal in the background database is updated according to the connection status.

7. The method according to claim 1 or 6, wherein: The updating of the device status information of at least one test terminal in the background database according to the connection status includes: Determining current device status information corresponding to the connection status; The device status information of at least one test terminal in the background database is updated to the current device status information.

8. The method according to claim 1, wherein The method further comprises: In the state monitoring script, at least one monitoring thread is exception captured, and if an exception is captured in the target monitoring thread, the target monitoring thread is reopened.

9. The method according to claim 8, wherein The step of capturing an exception of at least one monitoring thread in the status monitoring script and restarting the target monitoring thread if an exception is found in the target monitoring thread includes: In the status monitoring script, an exception is captured for a target monitoring thread used to obtain the connection status of the Apple terminal. If an exception is captured in the target monitoring thread, the USB-TCP conversion service is restarted and the target monitoring thread is reopened.

10. The method according to claim 1, wherein The method further comprises: The device status information of one or more test terminals in the background database is presented to the user.

11. The method according to claim 1, wherein The method further comprises: In response to a user creating a test project, identification information of at least one test terminal whose corresponding device status information in the background data is available for the device is presented to the user, so that the user can select a test terminal to be used for the test project.

12. The method according to claim 11, wherein The method of presenting, in response to a user creating a test project, identification information of at least one test terminal available for a device corresponding to device status information in the background data to the user, so that the user can select a test terminal to be used for the test project, includes: In response to a user creating a test project, based on the project type corresponding to the test project, identification information of at least one test terminal in the background data that matches the project type and whose corresponding device status information is available for the device is presented to the user, so that the user can select the test terminal to be used for the test project.

13. The method according to claim 11 or 12, wherein: The method further comprises: In response to an execution trigger event corresponding to a test task, device status information of a test terminal used by the test task is obtained from the background database. If the device status information indicates that the device is available, the test task is started to be executed.

14. The method according to claim 13, wherein The starting of executing the test task includes: Obtaining the operating status information of the test terminal from the background database, and if the operating status information indicates unlocked, starting to execute the test task, and updating the operating status information of the test terminal in the background database to locked; In response to the completion of the test task execution, the operating status information of the test terminal in the background database is updated to unlocked.

15. A computer device for updating device status, comprising a memory, a processor, and a computer program stored in the memory, characterized in that: The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 14.

16. A computer-readable storage medium having a computer program / instruction stored thereon, characterized in that: When the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 14 are implemented.

17. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 14 are implemented.

Images