Method and system for remote testing of devices

A method and system for remote testing of a plurality of devices is disclosed. The method may include receiving a request from a client system to perform testing on a set of remote devices. The local system and the client system are connected via a first network connection and the plurality of remote devices are connected to the local system via a second network connection. The method may further include receiving an input from the client system with reference to a test-suite to perform a testing action on the set of remote devices, generating a test command corresponding to the input, and transmitting the test command to each of the set of remote devices. The method may further include receiving feedback from each of the set of remote devices and transmitting the feedback to the client system.

TECHNICAL FIELD

This disclosure relates generally to device testing, and more particularly to method and system for remote testing of a plurality of devices, for example, Android devices.

BACKGROUND

Test automation frameworks are available that integrate various test components based on unique device and platform configurations, and provide results powered by internal validation algorithms. For example, devices under test may include mobile phones, personal computers (i.e. laptops, desktops, etc.), smartwatches, etc. Further, by way of an example, the devices may be Android-based or iOS-based. However, in scenarios when direct access to the devices is not available, these available test automation frameworks tend to lose their utility.

Some remote testing solutions are available that are based on remote desktop techniques and provide for remotely running automation test cases on remote devices. However, the remote testing techniques are slow and inefficient. For example, remote testing using these remote desktop-based techniques may take twice or thrice the time as compared to performing testing otherwise.

There is, therefore, a need for efficient and effective remote testing solutions for testing a plurality of devices simultaneously.

SUMMARY OF THE INVENTION

In one embodiment, a method of testing a plurality of remote devices is disclosed. The method may include receiving a request from a client system to perform testing on a set of remote devices of a plurality of remote devices. The local system and the client system may be connected via a first network connection. The local system may be configured to obtain and store an identity of each of the plurality of remote devices. The plurality of remote devices may be connected to the local system via a second network connection. The method may further include receiving an input from the client system with reference to a test-suite to perform a testing action on the set of remote devices. The test-suite may be uploaded from the client system to the local system. The method may further include generating a test command corresponding to the input to perform the testing action on the set of remote devices and transmitting the test command to each of the set of remote devices. Each of the set of remote devices is to perform the testing action based on the test command. The method may further include receiving a feedback from each of the set of remote devices and transmitting the feedback to the client system.

In another embodiment, a system for testing a plurality of remote devices is disclosed. The system may include a processor and a memory coupled to the processor. The memory is configured to store a plurality of processor-executable instructions which, upon execution by the processor, may cause the processor to receive a request from a client system to perform testing on a set of remote device of a plurality of remote devices. The system and the client system may be connected via a first network connection. The system may be configured to obtain and store an identity of each of the plurality of remote devices. The plurality of remote devices may be connected to the system via a second network connection. The plurality of processor-executable instructions may further cause the processor to receive an input from the client system with reference to a test-suite to perform a testing action on the set of remote devices. The test-suite may be uploaded from the client system to the system. The plurality of processor-executable instructions may further cause the processor to generate a test command corresponding to the input to perform the testing action on the set of remote devices and transmit the test command to each of the set of remote devices. Each of the set of remote devices is to perform the testing action based on the test command. The plurality of processor-executable instructions may further cause the processor to receive a feedback from each of the set of remote devices and transmitting the feedback to the client system.

DETAILED DESCRIPTION OF THE DRAWINGS

One or more techniques for testing a plurality of remote devices are disclosed. The techniques provide for running automation test cases (i.e. test suites) on remote devices (for example, Android devices) despite the devices being on different networks. The automation test cases may be run from a client system which may be connected to a local system over an Internet connection, via tunneling. The local system may further be connected to the remote devices which are to be tested via a separate network like a USB network or wireless network. Users (i.e. using the client system) can choose any number of remote devices from the list of remote devices connected to the local system for testing. The techniques enable the users to run a test-suite from a browser installed on the client system and view live streaming of the display screens of the remote devices on the client system, while the test execution is in process. The techniques, therefore, provide access to witness the entire test execution in real-time. As such, the techniques provide freedom to create an independent Android device cloud and making it accessible for testing. Further, the techniques provide for generation of test reports based on the test execution that are then made available for downloading at the client system. Moreover, the test reports can also be made publicly available by assigning an IP address and a URL to the test reports, thereby making the test reports shareable and viewable by multiple users who may be distributed across different locations.

Referring now toFIG.1, a block diagram of an environment100for testing of a plurality of remote devices is illustrated, in accordance with an embodiment of the present disclosure. As shown inFIG.1, the environment100may include a client system102, a local system104, and a plurality of remote devices106A,106B, . . .106N (hereinafter, collectively, referred to as plurality of remote devices106).

The client system102may be a computing device, like a desktop, a laptop, a smartphone, a server, etc. The client system102may be configured to connect with the local system104over a first network connection108. The first network connection108may be an Internet-based connection. Further, the plurality of remote devices106may be connected to the local system104over a second network connection110. In some embodiments, the second network connection110may be a Universal Serial Bus (USB) network connection. As such, the local machine104may include a plurality of USB ports into which the plurality of remote devices106may be plugged in using USB compatible data cables. Alternately, the second network connection110may be a wireless network connection. For example, the wireless network may be a Wi-Fi-based network. To this end, the local machine104and the each of the plurality of remote devices106may have Wi-Fi capability.

The client system102may be configured to perform one or more functionalities, which may include sending a request to the local system104to perform testing on the set of remote device of a plurality of remote devices106. To this end, the one or more functionalities may further include providing to the local device104a selection of identities of the set of remote devices from the plurality of remote devices106for performing testing on the set of remote devices. The one or more functionalities may further include receiving an input from a user and forwarding the input to local device104. The input may be in reference to a test-suite to perform a testing action on the set of remote devices. As such, the one or more functionalities performed by the client system102may further include uploading the test-suite to the local system104. In some embodiments, the one or more functionalities performed by the client system102may further include generating a test report corresponding to the remote testing of the set of devices. Further, the one or more functionalities may include displaying the test report via an input/output device. The test report may be downloaded at the client system102.

In order to perform the above-discussed functionalities, the client system102may include a processor102A, a memory102B, and an input/output device102C. The processor102A may include suitable logic, circuitry, interfaces, and/or code that may be configured to perform testing of the plurality of remote devices106. The processor102A may be implemented based on temporal and spatial processor technologies, which may be known to one ordinarily skilled in the art. Examples of implementations of the processor102A may be a Graphics Processing Unit (GPU), a Reduced Instruction Set Computing (RISC) processor, an Application-Specific Integrated Circuit (ASIC) processor, a Complex Instruction Set Computing (CISC) processor, a microcontroller, Artificial Intelligence (AI) accelerator chips, a co-processor, a central processing unit (CPU), and/or a combination thereof.

The memory102B may include suitable logic, circuitry, and/or interfaces that may be configured to store instructions executable by the processor102A. The memory102B may store instructions that, when executed by the processor102A, may cause the processor102A to perform remote testing of the plurality of devices106. The memory102B may be a non-volatile memory or a volatile memory. Examples of non-volatile memory may include, but are not limited to a flash memory, a Read-Only Memory (ROM), a Programmable ROM (PROM), Erasable PROM (EPROM), and Electrically EPROM (EEPROM) memory. Examples of volatile memory may include but are not limited to Dynamic Random-Access Memory (DRAM), and Static Random-Access memory (SRAM). The memory102B may also store various data that may be captured, processed, and/or required by the system.

The client system102may further include the input/output device102C. In some embodiments, the input/output device102C may further include a display and a user interface. By way of an example, the user interface may include a touchscreen, a keyboard, etc. to receive user inputs. For example, the user input may include selection of identities of one or remote devices (i.e. the set of remote devices) from the plurality of remote devices106. Further, the display may include a display screen which is capable of displaying the identities of the plurality of remote devices106, and further display the test report representing the test results of the set of remote devices.

The local system104may be a computing device, like a desktop, a laptop, a smartphone, a server, etc. The local system104may be configured to perform one or more functionalities, which may include receiving a request from the client system102to perform testing on a set of remote devices of a plurality of remote devices106. As mentioned above, the local system104and client system102may be connected via the first network connection108. The local system104may be configured to obtain and store an identity of each of the plurality of remote devices106. The plurality of remote devices106may be connected to the local system104via the second network connection110. The one or more functionalities may further include receiving an input from the client system102with reference to a test-suite to perform a testing action on the set of remote devices. The test-suite may be uploaded from the client system102to the local system104. The one or more functionalities may further include generating a test command corresponding to the input to perform the testing action on the set of remote devices and transmitting the test command to each of the set of remote devices. Each of the set of remote devices may perform the testing action based on the test command. The one or more functionalities may further include receiving a feedback from each of the set of remote devices and transmitting the feedback to the client system102.

In order to perform the above-discussed functionalities, the local system104may include a processor104A and a memory104B. The processor104A may include suitable logic, circuitry, interfaces, and/or code that may be configured to perform testing of the plurality of remote devices106. The processor104A may be implemented based on temporal and spatial processor technologies, which may be known to one ordinarily skilled in the art. Examples of implementations of the processor104A may be a Graphics Processing Unit (GPU), a Reduced Instruction Set Computing (RISC) processor, an Application-Specific Integrated Circuit (ASIC) processor, a Complex Instruction Set Computing (CISC) processor, a microcontroller, Artificial Intelligence (AI) accelerator chips, a co-processor, a central processing unit (CPU), and/or a combination thereof.

The memory104B may include suitable logic, circuitry, and/or interfaces that may be configured to store instructions executable by the processor104A. The memory104B may store instructions that, when executed by the processor104A, may cause the processor104A to perform testing of the plurality of remote devices106. The memory104B may be a non-volatile memory or a volatile memory. Examples of non-volatile memory may include, but are not limited to a flash memory, a Read-Only Memory (ROM), a Programmable ROM (PROM), Erasable PROM (EPROM), and Electrically EPROM (EEPROM) memory. Examples of volatile memory may include but are not limited to Dynamic Random-Access Memory (DRAM), and Static Random-Access memory (SRAM). The memory104B may also store various data that may be captured, processed, and/or required by the system.

The first communication network108may include a communication medium through which the local system104and the client system102may communicate with each other. Examples of the first communication network108may include, but are not limited to, the Internet, a cloud network, a Wireless Fidelity (Wi-Fi) network, a Personal Area Network (PAN), a Local Area Network (LAN), or a Metropolitan Area Network (MAN). Various devices in the environment100may be configured to connect to the first communication network108, in accordance with various wired and wireless communication protocols. Examples of such wired and wireless communication protocols may include, but are not limited to, a Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), Zig Bee, EDGE, IEEE 802.11, light fidelity(Li-Fi), 802.16, IEEE 802.11s, IEEE 802.11g, multi-hop communication, wireless access point (AP), device to device communication, and cellular communication protocols.

Referring now toFIG.2, a functional block diagram200of the client system102is illustrated, in accordance with some embodiments of the present disclosure. The client system102may include one or more modules configured to perform one or more functionalities as discussed above. By way of an example, the one or more modules may include a test requesting module202, a selection requesting module204, an input module206, a test report generating module, and a display module210. It should be noted that the functionalities of the above modules may be performed individually by each module, or alternately the functionalities of multiple modules may be combined in a single module.

The test requesting module202may receive a request from a user to perform testing of the set of remote devices. To this end, the client system102may include the input/output device102C which may provide an interface for allowing a user to make such a request.

The selection requesting module204may be configured to receive a selection of one or more remote devices to create the set of remote devices which are to be tested. The user may provide the selection of identities of the set of remote devices which are to be tested. The selection requesting module204may, therefore, in coordination with the user interface of the input/output device102C, may allow the user to provide selection of the set of remote devices from the plurality of remote devices106.

The input module206may receive an input from the user to perform the testing action on the set of remote devices. It should be noted, in some embodiments, the input may be received with reference to a test-suite to perform a testing action on the set of remote devices. The test-suite may be uploaded from the client system102to the local system104.

The test report generating module208may generate a test report corresponding to the remote testing of the set of devices upon completion of the remote testing. In some embodiments, the display module210may function in coordination with the input/output device102C to display the test report generated by the test report generating module208. For example, the test report may be displayed using the display screen of the input/output device102C. Further, the test report generating module208may provide for downloading the test report at the client system102. Alternately, in some embodiments, the test report may be assigned a public IP address so that the test report can be accessed from any remote location.

Referring now toFIG.3, a functional block diagram300of the local system104is illustrated, in accordance with some embodiments of the present disclosure. The local system104may include one or more modules configured to perform one or more functionalities as discussed above. By way of an example, the one or more modules may include a request receiving module302, an input receiving module304, a test command generating module306, a test command transmitting module308, and a feedback receiving module310. In some embodiments, the local system104may further include a selection module312. It should be noted that the functionalities of the above modules may be performed individually by each module, or alternately the functionalities of multiple modules may be combined in a single module.

The request receiving module302may be configured to receive a request from the client system102to perform testing of the set of remote device of the plurality of remote devices106. The local system104and client system102may be connected via the first network connection108. The local system104may be configured to obtain and store an identity of each of the plurality of remote devices106, once the remote devices106are connected to the local system104. For example, the plurality of remote devices106may include Android-based devices.

In some embodiments, the selection module312may be configured to receive, from the client system102, a selection of identities of the set of remote devices from the plurality of remote devices106for performing testing on the set of remote devices. For example, the local system104may be connected to N number of remote devices; however, a user may want to perform testing on M number of devices (where, M<N). As such, the selection module312may be configured to receive selection of identities of the M number of remote devices (from the N number of remote devices106) from the user on which the testing may be performed.

As already mentioned above, the plurality of remote devices106may be connected to the local system104via the second network connection110. In some embodiments, the second network connection110may be one of a Universal Serial Bus (USB) connection and a wireless network connection. For example, the wireless network may be a Wi-Fi-based network.

In some embodiments, the input receiving module304may receive an input from the client system102with reference to a test-suite to perform a testing action on the set of remote devices. The test-suite may provide various predefined test routines and test commands that can be used to run the test script on the remote devices. The test-suite may be uploaded from the client system102to the local system104.

The test command generating module306may generate a test command corresponding to the input to perform the testing action on the set of remote devices. For example, the test command generating module306may convert the input into a test command executable by the remote devices. Alternately, the input may indicate a selection of a test command from the test suite, and the test command generating module306may fetch the said test command from the test suite based on the input.

The test command transmitting module308may transmit the test command to each of the set of remote devices. As mentioned above, the plurality of remote devices106are connected to the local system104via the second network connection110which may be a Universal Serial Bus (USB) connection or a wireless network connection, e.g. a Wi-Fi-based network. The test command transmitting module308, therefore, may transmit the test command to each of the set of remote devices over the second network connection110, and after converting the test command into a format compatible with the communication protocol applicable to the second network connection110.

The feedback receiving module310may receive feedback from each of the set of remote devices. The feedback receiving module310may further transmit the feedback to the client system102. In some embodiments, the feedback may include streaming of content displayed on a display screen of each of the set of remote devices. As such, transmitting the feedback to the client system102may include the causing to stream on the client system, in real-time, content displayed on a display screen of each of the set of remote devices. Upon completion of the remote testing, one or more test reports may be generated at the client system102. Further, the test reports corresponding to the remote testing may be published on a web page.

Referring now toFIG.4, a flowchart of a method400of testing the plurality of remote devices106is disclosed, in accordance with some embodiments of the present disclosure. In some embodiments, the method400may be performed by the local system104.

In some embodiments, at step402, a tunnel connection may be established between the client system102and the local system104over the first network connection108. In some embodiments, the first network connection108may be an Internet-based connection. The client system102may, therefore, be able to communicate with the local system104via the tunnel connection. In some embodiments, the tunnel connection may be setup using a tunneling tool, for example, “ngrok”, “Localtunnel”, “Served”, “Teleconsole”, “Pagekite”, and the like.

In some embodiments, in order to establish the tunnel connection, a Uniform Resource Locator (URL) corresponding to the local system104may be generated. Further, the generated URL may be shared with the client system102. The local system104may have a localhost server running on it, such that, when instructed, the local system104may starts the localhost server that may be made available on a public network using tunnelling. In other words, the local system104may be configured to act as a local web server that, for example, may be setup through a Django Python Framework. As such, the client system102may be able to access the local system104via a browser installed on the client system using the URL. A user may initiate the connection between the client system102and the local system104by logging in to the public IP address of the local system104.

At step404, a request may be received from the client system102to perform testing on a set of remote devices of the plurality of remote devices106. The local system104and client system102, as mentioned earlier, may be connected via the first network connection108. The plurality of remote devices106may be connected to the local system104via the second network connection110. The second network connection110may be a Universal Serial Bus (USB) connection. In other words, each of the plurality of remote devices106may be connected to the local system104via USB ports and a USB cable. In alternate embodiments, the second network connection110may be a wireless network connection, for example, a Wi-Fi connection. In such embodiments, it should be noted that all of the plurality of remote devices106may be connected to the local system104over a common Wi-Fi network.

It should be further noted that the local system104may be configured to obtain and store an identity of each of the plurality of remote devices106. For example, when the plurality of remote devices106are Android devices, the identity of each remote device may be an associated Android device ID.

The user using the client system102may have the liberty to choose the remote devices that they wish to test and further upload the test cases for automating the test execution. The local system104, in turn forwards the commands to the selected android phone for further processing, as it will be apparent from the subsequent steps of the method400.

In order to receive the request from the client system102to perform testing on a set of remote device of a plurality of remote devices106, the step404may further include a step404A. At step404A, a selection of identities of the set of remote devices may be received. As explained above, the local system104may be connected to N number of remote devices; however, a user may want to perform testing on M number of devices (where, M<N). Therefore, at step404A, a selection of identities of the M number of remote devices (from the N number of remote devices106) on which the testing may be performed may be received.

At step406, an input may be received from the client system102with reference to the test-suite to perform a testing action on the set of remote devices. The test-suite may provide various predefined test routines and test commands that can be used to run the test script on the remote devices106. The test-suite may be uploaded from the client system102to the local system104.

At step408, a test command may be generated corresponding to the input to perform the testing action on the set of remote devices. For example, the input may be converted into a test command executable by the remote devices106. Alternately, the input may indicate a selection of a test command from the test suite, and therefore, at step408, the said test command may be fetched from the test suite based on the input.

Further, at step410, the test command may be transmitted to each of the set of remote devices. Each of the set of remote devices may be configured to perform the testing action based on the test command. As mentioned above, the plurality of remote devices106are connected to the local system104via the second network connection110which may be a Universal Serial Bus (USB) connection or a wireless network connection, e.g. a Wi-Fi-based network. The test command may therefore be transmitted to each of the set of remote devices over the second network connection110after converting the test command into a format compatible with the communication protocol applicable to the second network connection110. It should be noted that for execution of the test command, developer mode may have to be activated for each of the plurality of remote devices106.

At step412, a feedback may be received from each of the set of remote devices. Further, at step410, the feedback may be transmitted to the client system102. In some embodiments, the feedback may include streaming of content displayed on a display screen of each of the set of remote devices. As such, transmitting the feedback to the client system102may include the causing to stream on the client system, in real-time, content displayed on a display screen of each of the set of remote devices.

Once the testing of the remote devices106is complete, a test report may be generated corresponding to the remote testing of the set of devices. In some embodiments, the test report may be displayed on the client system102and may further be made available for downloading at the client system102. Further, an associated log file for the test reports can also be accessed from a test reports section of the web page.

Referring now toFIGS.5A-5B, snapshots of test reports500A,500B are illustrated, in accordance with some embodiments of the present disclosure. as shown in theFIG.5A, the test report500A includes a log of all the remote tests (under “All Tests”) that have been performed along with the time taken for test execution (under “Elapsed”). Further, the test report500A includes a log of the particular remote devices (under “statistics by Tag”) wherein the test results of that particular remote device are presented along with the identity (i.e. “4bfcfa4f”) of the remote device. Alongside, the test report500A may include a start time, an end time, and an elapsed time (i.e. time taken) for the test execution (under “Start/End/Elapsed”). Further, the test report500A includes a log of test status, i.e. whether the remote device was successfully tested or not (“passed” or “failed”). Further, the test report500A may include a suite type (i.e. “Mobile”) that was used for the test.

As shown inFIG.5B, the test report500B may include similar fields and information of the report500A, for example, a log of all the remote tests (under “All Tests”), a log of the particular remote devices (under “statistics by Tag”), a start time (under “Start Time”), an end time (under “End Time”), and an elapsed time (under “Elapsed Time”), a log of test status, and a suite type (i.e. “Mobile”). The test reports500A,500B can be viewed and downloaded at the client system102.

Although the present disclosure has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present disclosure is limited only by the claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the disclosure.