Novel Android automatic testing method and system based on wireless drive

Abstract

The invention relates to a novel Android automatic test method and system based on wireless drive, after a monitoring application in an Android end test host establishes local communication with an Android system service, the monitoring application receives an operation command sent by a PC end, and automatically starts related permissions required by a test; the monitoring application carries out control identification of the Android end test host according to the operation command, the Android system service carries out automatic test and generates a test result according to the operation command and the identified control, and the monitoring application obtains the test result and sends the test result to the PC end. According to the invention, the test mobile phone is wirelessly connected with the PC terminal, multiple test mobile phones can be connected at the same time for automatic test, the authority can be automatically opened in the test process, and the test efficiency of the automatic test is improved.

Description

Technical Field

[0001] This application relates to the field of automated testing, and particularly to a new Android automated testing method and system based on wireless drive. Background Art

[0002] Currently popular automated testing tools are Appium and Airtest. The Appium automated testing framework is an open-source, cross-platform, multi-language supported mobile application automated tool. Generally speaking, it is a mobile phone App automated tool. It has the characteristic of cross-platform and can perform tests on various mobile devices such as iOS and Android. Appium provides a set of APIs, and developers can use multiple programming languages to write automated scripts. Airtest is a UI automated testing tool based on the Python language, specifically for the automated testing of mobile applications. Its main use is to perform UI function testing and performance testing on Apps on the Android and iOS platforms, and it can support applications on the Android and iOS platforms without modifying the application code.

[0003] However, the above automated testing tools all require a wired connection between the test mobile phone and the computer side. For example, they are connected to the PC side through USB. Only after the connection can automated testing be carried out. This wired connection method is limited by the number of physical interfaces of the PC host, resulting in only a small number of test mobile phones can be automatically tested simultaneously on one PC side. If the test mobile phone needs to be replaced, the physical connection needs to be changed multiple times. At the same time, the test mobile phone needs the user to manually authorize relevant permissions during the automated testing process, which is inconvenient to operate and has low efficiency. Summary of the Invention

[0004] In view of the problems in the prior art, this application provides a new Android automated testing method based on wireless drive, which can realize the wireless connection between the Android-side test host and the PC side, so as to complete automated testing, and can automatically enable permissions during the testing process. The new Android automated testing method based on wireless drive includes the following steps:

[0005] The monitoring application in the Android-side test host establishes local communication with the Android system service;

[0006] The monitoring application receives the operation commands sent by the PC side and automatically enables the relevant permissions required for testing;

[0007] The monitoring application performs control recognition of the Android-side test host according to the operation commands;

[0008] The Android system service performs automated testing based on the operation command and the recognized control and generates a test result;

[0009] The monitoring application obtains the test result and sends the test result to the PC side.

[0010] This application also provides a new Android automated testing system based on a wireless driver, including:

[0011] A communication unit for establishing local communication between the monitoring application in the Android-side test host and the Android system service;

[0012] An authorization unit for the monitoring application to receive the operation command sent by the PC side and automatically enable the relevant permissions required for testing;

[0013] A control recognition unit for the monitoring application to recognize the controls of the Android-side test host according to the operation command;

[0014] A testing unit for the Android system service to perform automated testing based on the operation command and the recognized control and generate a test result;

[0015] A feedback unit for the monitoring application to obtain the test result and send the test result to the PC side.

[0016] Compared with the prior art, in this application, by establishing local communication between the monitoring application of the Android-side test host and the Android system service of the Android-side test host, and at the same time the monitoring application receives the operation command from the PC side, wireless connection between the Android-side test host and the PC side is achieved, greatly solving the problem that it is impossible to connect multiple test mobile phones through USB data cables simultaneously due to the limited number of USB ports on a single PC, and the monitoring application can automatically enable the relevant permissions required for testing, greatly improving the testing efficiency.

[0017] In order to understand this application more clearly, the following will describe the specific implementation manners of this application in conjunction with the accompanying drawings. Description of the Drawings

[0018] Figure 1 It is the method flow chart of the new Android automated testing based on wireless driver in this application;

[0019] Figure 2 It is the method flow chart of the authorization for the new Android automated testing based on wireless driver in this application;

[0020] Figure 3Flowchart of the method for implementing the recording function of the new Android automated test based on wireless drive in this application;

[0021] Figure 4 Flowchart of the method for implementing the playback function of the new Android automated test based on wireless drive in this application;

[0022] Figure 5 Flowchart of the method for implementing multi - device control of the new Android automated test based on wireless drive in this application;

[0023] Figure 6 Schematic diagram of the new Android automated test system based on wireless drive in this application;

[0024] Figure 7 Schematic diagram of the new Android automated test authorization system based on wireless drive in this application;

[0025] Figure 8 Schematic diagram of the new Android automated test recording system based on wireless drive in this application;

[0026] Figure 9 Schematic diagram of the new Android automated test playback system based on wireless drive in this application;

[0027] Figure 10 Schematic diagram of the new Android automated test multi - device control system based on wireless drive in this application. Detailed implementation manners

[0028] To make the objectives, technical solutions and advantages of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0029] Example 1

[0030] Please refer to Figure 1 、 Figure 2 and Figure 3 , Figure 1 The flowchart of the method for the new Android automated test based on wireless drive in this application, Figure 2 The flowchart of the method for the new Android automated test authorization based on wireless drive in this application, Figure 3 The flowchart of the method for implementing the recording function of the new Android automated test based on wireless drive in this application.

[0031] This application provides a new Android automated test method based on wireless drive, including the following steps:

[0032] S11: The monitoring application in the Android - side test host establishes local communication with the Android system service;

[0033] S12: The monitoring application receives the operation commands sent by the PC - side and automatically enables the relevant permissions required for testing;

[0034] S13: The monitoring application performs control recognition on the Android - side test host according to the operation commands;

[0035] S14: The Android system service performs automated testing and generates test results according to the operation commands and the recognized controls;

[0036] S15: The monitoring application obtains the test results and sends the test results to the PC - side.

[0037] For step S11, the monitoring application in the Android - side test host establishes local communication with the Android system service.

[0038] Among them, the Android - side test host includes an Android emulator and a real Android terminal device. In this embodiment, the monitoring application runs in the Android - side test host and includes ADBLib. The ADBLib is an ADB network protocol communication library implemented in Java, which encapsulates a set of ADB debugging communication services and can replace the ADB Server.

[0039] Android Debug Bridge (ADB) is a command-line tool used to directly debug the Android-side test host. The ADB includes a daemon process (Android Debug Bridge daemon, abbreviated as ADB daemon) and a server (Android Debug Bridge Server, abbreviated as ADB Server). The ADB daemon is a daemon process running in the Android-side test host system service, used to execute ADB operation commands. The port range used by the ADB daemon is 5554 - 5585. After the Android-side test host is connected to the PC side, the ADB daemon process will be started, and within the port range used by the ADB daemon, two consecutive ports will be allocated to the Android-side test host. Among them, the even port is used for the PC-side console to connect and interact with the Android-side test host, and the odd port is used for the ADB Server to connect and communicate with the Android-side test host. The ADB Server runs on the PC side. After the ADB Server establishes a connection and maintains communication with the ADB daemon on the odd port, the ADB Server sends ADB operation commands to the ADB daemon. When the ADB Server is started, it will automatically bind and listen on port 5037. In this embodiment, the ADBLib replaces the ADB Server to establish a local Socket connection and maintain communication with the ADB daemon. The ADBLib sends operation commands to the ADB daemon in the form of socket instructions, thereby enabling the monitoring application in the Android-side test host to establish local communication with the Android system service.

[0040] In this embodiment, the ADB daemon and the monitoring application are pre-deployed on the Android-side test host. The adb tcpip 5555 command is executed on the PC side to start the ADB daemon on the Android-side test host. It should be noted that in the embodiments of the present disclosure, the PC side can be briefly connected to the Android-side test host via USB, so as to send the adb tcpip 5555 command to the Android-side test host. After the Android-side test host starts the ADB daemon, the USB connection between the two can be disconnected, and the ADBLib then establishes a local Socket communication with the ADB daemon in the Android system service. Therefore, in this embodiment, it can be considered that the Android test host is no longer restricted by the PC side and the USB connection line when executing automated tasks relying on ADB commands, that is, it can perform automated test tasks offline. Therefore, there is no need to worry that the disconnection between the Android-side test host and the PC side will affect the progress of task execution. At the same time, since the Android test host can perform automated test tasks offline, the Android-side test host does not need to be fixedly placed in the computer room. When testers switch between manual testing and automated testing, there is no need to frequently travel back and forth between the workstations and the computer room, improving the testing efficiency.

[0041] For step S12, the monitoring application receives the operation commands sent by the PC side and automatically enables the relevant permissions required for testing.

[0042] Among them, the operation command is preferably an ADB operation command. The ADB also includes a client (Android DebugBridge Client, abbreviated as ADB Client), which runs on the PC. After establishing a TCP connection with the ADB Server through the 5037 port and maintaining communication, the ADB Client sends ADB operation commands to the ADB Server based on the TCP communication protocol, and one ADB Client can establish connections and maintain communication with multiple ADB Servers. In this embodiment, the ADB Client establishes a TCP connection with the ADBLib and maintains communication, and the ADB Client sends ADB operation commands to the ADBLib based on the TCP communication protocol. Of course, in other embodiments, the ADB Client can also establish a USB connection with the ADBLib, and the ADB Client sends ADB operation commands to the ADBLib based on the USB communication protocol.

[0043] The monitoring application receives the operation commands sent by the PC and automatically enables the relevant permissions required for testing, and further includes the following steps:

[0044] S121, the monitoring application of the Android test host sends a request to the PC for obtaining the running script for automated authorization according to the operation command;

[0045] S122, the PC downloads the corresponding running script from the server according to the request and sends it to the monitoring application of the Android test host;

[0046] S123, the monitoring application of the Android test host receives the running script and sends it to the Android system service;

[0047] S124, the Android system service of the Android test host receives and executes the running script to complete the authorization.

[0048] For step S121, the monitoring application of the Android test host sends a request to the PC for obtaining the running script for automated authorization according to the operation command.

[0049] Among them, in this embodiment, the ADB Lib in the monitoring application sends a request for obtaining the running script for automated authorization to the ADB Client running on the PC based on the TCP communication protocol or the USB communication protocol.

[0050] For step S122, the PC downloads the corresponding running script from the server according to the request and sends it to the monitoring application of the Android test host.

[0051] Among them, the running script is preferably a shell script, and the ADB Client running on the PC sends the running script for automated authorization to the ADB Lib in the monitoring application based on the TCP communication protocol or the USB communication protocol.

[0052] For step S123, the monitoring application of the Android test host receives the running script and sends it to the Android system service.

[0053] Among them, in this embodiment, the ADB Lib of the monitoring application sends the running script to the ADB daemon running in the Android system service in the form of a socket instruction.

[0054] For step S124, the Android system service of the Android test host receives and executes the running script to complete the authorization;

[0055] Among them, in this embodiment, the running script is preferably a shell script. The ADB daemon running in the Android system service executes the running script, and further includes the following sub-steps: First, read the command line in the running script through the command parser Shell of the Android system; Second, interpret and execute the command line through the command parser Shell. The command parser Shell is used to read and interpret the command line in the shell script and then pass it to the operating system for execution. According to the commands in the running script, the operating system completes operations such as opening the application management in the settings of the Android-side test host, then successively opening the application details page of each application to be automatically tested, and enabling all running permissions of the application, thus completing the authorization operation.

[0056] For step S13, the monitoring application completes the control recognition of the Android-side test host according to the operation command.

[0057] Among them, in one embodiment, the monitoring application performs control identification based on AccessibilityService. The AccessibilityService, also known as the accessibility service, is a type of service provided by the Android system. Its core is to programmatically access the UI elements of the Android side of the test host and operate the UI elements. In this embodiment, the monitoring application can access the UI interface in the application to be tested on the Android side test host through AccessibilityService, obtain control information in the UI interface, such as control type, control id, and the position coordinates of the control in the UI interface, etc., and generate a control view tree. The specific way for the monitoring application to traverse the controls in the application interface to be tested on the Android side test host by calling the AccessibilityService is as follows: The monitoring application locates the starting application interface according to the interface identifier of the application interface to be tested. Starting from the starting application interface, the controls in each level of the application interface are traversed in turn according to the depth-first rule. The depth-first rule means that, according to the logical path pointed to by any control, each sub-interface under the logical path is clicked step by step until the bottommost interface under the logical path is clicked, and then the previous level interface is returned to click other interfaces. For example, taking a shopping application as an example, the starting interface is used to select the theme market, which contains controls such as "Imported Foods", "Beauty and Personal Care", "Furniture and Home Appliances", and "Maternal and Infant Products". In the order from left to right and top to bottom, first click the control "Imported Foods" to enter the second-level sub-interface, and then click the control "Imported Milk" in the second-level sub-interface, the control "Imported Yogurt" in the third-level sub-interface, and the control "A Certain Brand Yogurt" in the last-level interface in the aforementioned order, thus completing a depth traversal. Then, click the control corresponding to other brand yogurts in the last-level interface until all are clicked, and then return to the third-level sub-interface and continue to click other components such as "Imported Adult Milk Powder".

[0058] After completing a depth traversal, the monitoring application sorts the controls in the order of obtaining the control coordinates, and a control tree constructed according to the depth-first principle will be obtained. In the control tree, information about all controls in the application, such as control type, control id, and the position coordinates of the control in the UI interface, etc., is recorded. For example, "Imported Foods" -> "Imported Milk" -> "Imported Yogurt" -> "A Certain Brand Yogurt".

[0059] The AccessibilityService is applicable to native pages, which are called native pages. Native pages can make full use of the device's hardware and functions to provide faster loading speeds and smoother interactions. For such native pages, the control tree is obtained through the dump_hierarchy method in the automation framework uiautomator2 and stored in the local library of the Android test host in the form of an XML file classified according to the model and version of the Android test host.

[0060] In one embodiment, when testing non-native pages such as game software and the elements cannot be located through the uiautomator2 framework, the monitoring application can also perform control recognition based on image matching. Image matching is also a method for locating page controls. It is based on the OpenCV image processing library and uses the matchTemplate function in the template matching algorithm to detect the pixel matching degree between the test source image and the template image. When the pixel matching degree reaches the set threshold, it is determined that the matching is successful, that is, the target control is successfully recognized. In this embodiment, the template image is a screenshot of each component in the software to be tested by the tester when developing the automated test operation command, and the template image is stored on the PC side. The operation command includes the storage path of the template image on the PC side; the test source image is an image obtained by taking a screenshot of the current interface component during the automated test process and is used to perform pixel matching with the template image; the set threshold of the pixel matching degree is 98%, that is, when the pixel matching degree between the test source image and the template image is greater than or equal to 98%, it is determined that the matching is successful, and the component in the test source image is consistent with the component in the template image, and the component is successfully recognized.

[0061] In other embodiments, when performing automated testing on the Web UI in the Android test host, such as H5 or applet scenarios, the monitoring application can also perform control recognition based on the ChromeDevTools Protocol. The ChromeDevTools Protocol is a protocol of websocket and also a library in the AccessibilityService. It mainly injects js by combining the Web automation framework selenium to obtain page network data including page layout and various control attributes such as ID, size, and position, thereby realizing control recognition.

[0062] In this application, the method by which the monitoring application identifies the Android - side test host control not only includes the method described in the above - mentioned embodiments, but also any other method for an Android - side test host to identify controls can be applied to the solution of this application.

[0063] For step S14, the Android system service performs an automated test and generates a test result based on the operation command and the identified control.

[0064] Among them, in this embodiment, the test result records the test logs generated when executing each operation command during the automated test process. The test logs record information such as the start timestamp and end timestamp of executing each operation command, the operation type (such as swiping up, tapping, long - pressing, etc.), the execution result, whether an exception occurs, and the exception type. The test result is stored in the form of a.log.

[0065] The operation command is preferably a shell script. The ADB daemon running in the Android system service to execute the operation command further includes the following sub - steps: First, read the command line in the operation command through the command parser Shell of the Android system; Second, interpret and execute the command line through the command parser Shell. The command parser Shell is used to read and interpret the command line in the shell script and then pass it to the operating system for execution. The operating system performs test operations on the Android - side test host according to the commands in the operation command, such as tapping, swiping down, or taking screenshots of the controls of the software under test.

[0066] The operation record is obtained after the monitoring application enables the recording function. When the user opens the monitoring application on the Android - side test host and clicks the start button, the monitoring application will pop up an operation floating window and run in the background, and will automatically jump to the home page of the application under test. Specifically, it further includes the following steps:

[0067] S141, the monitoring application intercepts the user's operations;

[0068] S142, when the user clicks the start button, the monitoring application enables the recording function and records the first operation information of the user that is currently intercepted;

[0069] S143, when the user clicks the end button of the floating window to end the recording, the monitoring application generates the operation record.

[0070] For step S141, the monitoring application intercepts the user's operations.

[0071] When the monitoring application needs to intercept user operations, it will set the flag of the AccessibilityService to enable the AccessibilityService to enter the touch monitoring mode. In this mode, the Android system will not distribute events in the view tree, and various events such as long presses and swipes down will be distributed to the implementation class of the AccessibilityService for processing. At this time, the monitoring application will constantly monitor the get even event and distribute and process the event. When it is not necessary to intercept user operations, the monitoring application will reset the flag of the AccessibilityService and exit the touch monitoring mode.

[0072] For step S142, when the user clicks the start button, the monitoring application enables the recording function and records the currently intercepted operation information of the user.

[0073] The first operation information includes control information and specific operations. The control information includes basic information such as the ID and text of the control, as well as relative layout and screenshot information. The specific operations include operations such as long press, short press, screenshot, swipe up, and swipe down. If the corresponding control cannot be found through the AccessibilityService-based mode, the image search mode can be switched to for searching through image matching. When using the image search mode, the monitoring application will capture an image of the current screen, and the user can select the area for screenshot operation to obtain the test source image.

[0074] For step S143, after the user clicks the end button of the floating window to end the recording, the monitoring application generates the operation record.

[0075] Among them, the operation information includes control information and specific operations. The control information includes basic information such as the ID and text of the control, as well as relative layout and screenshot information. The specific operations include operations such as long press, short press, screenshot, swipe up, and swipe down, preferably a shell script.

[0076] For step S15, the monitoring application obtains the test result and sends the test result to the PC side.

[0077] Among them, the ADBLib in the monitoring application sends the test results to the ADB Client in the PC end based on the TCP communication protocol or the USB communication protocol, and the PC end receives and stores the test results. Testers can view the test results on the PC end. In actual applications, multiple Android test hosts can be used to perform component tests on the same application and upload them to the PC end. The PC end summarizes and deduplicates the test results uploaded by each Android test host, thereby eliminating the random factors of individual Android test hosts and obtaining more stable and accurate test results.

[0078] This application establishes a local Socket communication between the ADBLib in the monitoring application of the Android test host and the ADB daemon in the Android system service of the Android test host. The ADBLib obtains the execution ability of the ADB shell, and the ADBLib acts as an ADB Server and receives the ADB operation commands sent by the ADB Client in the PC end, realizing the wireless connection between the test mobile phone and the PC end. At the same time, the monitoring application realizes automatic authorization, which largely eliminates the headache of handling application permission pop-up windows for users.

[0079] Example 2

[0080] Please refer to Figure 4 , Figure 4 which is the method flow chart for the new Android automation test based on wireless driver in this application to implement the playback function.

[0081] The main difference between the new Android automation test method based on wireless driver in this embodiment and Embodiment 1 is that in one embodiment, the new Android automation test based on wireless driver can implement the playback function, and the new Android automation test method based on wireless driver further includes the following steps:

[0082] S21, the monitoring application locates the target control according to the operation record;

[0083] S22, the Android system service performs operation playback according to the operation record;

[0084] S23, the monitoring application displays the playback information after the playback ends.

[0085] For step S21, the monitoring application locates the target control according to the operation record.

[0086] Among them, the operation information includes control information and specific operations. The control information includes basic information such as the ID and text of the control, as well as relative layout, screenshot information, etc. The specific operations include operations such as long press, short press, screenshot, swipe up, and swipe down. Based on an intelligent search algorithm, the monitoring application will parse the operation records item by item to obtain the position where the user clicks during recording, the type and name of the control operated, information such as the control ID, text, layout, and screenshot. The above information are all attributes of the page control to be searched. The page structure is constructed through these attribute points to obtain the path of the page control. Based on this path, the monitoring application can locate the target control.

[0087] For step S22, the Android system service performs operation playback according to the operation record.

[0088] Among them, in this embodiment, the ADB daemon running in the Android system service performs the playback operation. The operation record is preferably a shell script. The ADB daemon performing the playback operation further includes the following sub-steps: First, read the command line in the operation record through the command parser Shell of the Android system; Second, interpret and execute the command line through the command parser Shell. This command parser Shell is used to read and interpret the command line in the shell script and then pass it to the operating system for execution. The operating system performs operations on the Android-side test host according to the commands in the operation record and in the order of the commands in the operation record, successively to complete the playback of test operations such as clicking, swiping down, or taking screenshots of the controls of the software under test.

[0089] For step S23, display the playback information after the playback operation ends.

[0090] Among them, the playback information includes operation screenshots and operation logs. The operation log records every operation performed on each control during the automated test, including the start timestamp, end timestamp, response time, and response result of each operation, etc.; The operation screenshot records the pictures taken when each control is operated during the automated test.

[0091] Example 3

[0092] Please refer to Figure 5 , Figure 5This is a flowchart of a method for implementing multi-device control with a single device in a new Android automated test based on wireless drive. The main difference between the new Android automated test method based on wireless drive in this embodiment and Embodiment 2 is that the new Android automated test based on wireless drive in this embodiment can achieve multi-device control. The multi-device control means that after multiple Android slave test devices are connected to the Android master test device at the same time, the Android slave test devices can synchronously replay the operations of the Android master test device. The new Android automated test method based on wireless drive further includes the following steps:

[0093] S31, after the Android master test device is connected to other Android slave test devices and maintains a communication state;

[0094] S32, the listening application of the Android slave test device receives the second operation information sent in real time by the Android master test device;

[0095] S33, the Android slave test device performs operation replay according to the second operation information to achieve synchronous testing.

[0096] In one embodiment, the Android-side test slave includes an Android emulator and a real Android terminal device. The ADB daemon and a listening application are pre-deployed on all the Android-side test slaves. According to actual needs, there can be any number of Android-side test slaves. The Android-side test host acts as the Server side, and other Android-side test slaves act as the Client side. Moreover, the Android-side test host and the Android-side test slaves need to be connected to the same WiFi. The Android-side test slaves establish a Socket connection with the Android-side test host to maintain communication. The Android-side test host instantaneously sends the second operation information, such as swiping up, swiping down, long pressing, etc., to the Android-side test slaves through socket instructions. The second operation information is preferably a shell script. After receiving the second operation information, the listening application on the Android-side test slave sends the second operation information to the ADB daemon running in the system service of the Android test slave. The ADB daemon completes the playback of the corresponding operations according to the second operation information, which specifically includes the following sub-steps: First, read the command line in the second operation information through the command parser Shell of the Android system; Second, interpret and execute the command line through the command parser Shell. This command parser Shell is used to read and interpret the command line in the shell script and then pass it to the operating system for execution. The operating system performs playback of test operations such as tapping, swiping down, or taking screenshots of the controls of the software under test on the Android-side test slave according to the commands in the second operation information.

[0097] Of course, the Android-side test host and the Android-side test slaves can also establish a connection to maintain communication through other means such as Bluetooth.

[0098] In this application, the method for the Android-side test host to establish a connection with the Android-side test slaves is not limited to the method described in the above embodiment. Any other method for the Android-side test host to establish a connection with the Android-side test slaves can be applied to the solution of this application.

[0099] This application can achieve controlling multiple Android-side test slaves with one Android-side test host for automated testing, completing compatibility testing, and greatly improving the test efficiency of automated testing.

[0100] Example 4

[0101] The present application also provides a new Android automated testing system based on wireless drive to implement the steps of the new Android automated testing method based on wireless drive described in Embodiment 1.

[0102] Please refer to Figure 6 , Figure 6 For Figure 1 a schematic diagram of the new Android automated testing system based on wireless drive, the new Android automated testing system based on wireless drive includes: a communication unit 11, an authorization unit 12, a control unit 13, a testing unit 14, and a feedback unit 15.

[0103] Among them, the communication unit 11 is used for the monitoring application in the Android-side test host to establish local communication with the Android system service;

[0104] The authorization unit 12 is used for the monitoring application to receive the operation commands sent by the PC side and automatically enable the relevant permissions required for testing;

[0105] The control recognition unit 13 is used for the monitoring application to perform control recognition of the Android-side test host according to the operation commands;

[0106] The testing unit 14 is used for the Android system service to perform automated testing and generate test results according to the operation commands and the recognized controls;

[0107] The feedback unit 15 is used for the monitoring application to obtain the test results and send the test results to the PC side.

[0108] Please refer to Figure 7 , Figure 8 , Figure 9 and Figure 10 , Figure 7 is a schematic diagram of the new Android automated testing authorization system based on wireless drive of the present application, Figure 8 is a schematic diagram of the new Android automated testing recording system based on wireless drive of the present application, Figure 9 is a schematic diagram of the new Android automated testing playback system based on wireless drive of the present application, Figure 10 is a schematic diagram of the new Android automated testing one-machine multi-control system based on wireless drive of the present application.

[0109] In one embodiment, the new Android automated testing system based on wireless drive further includes: an interception unit 141, a recording unit 142, and an operation record generation unit 143.

[0110] The interception unit 141 is configured to intercept the operations of the user by the monitoring application;

[0111] The recording unit 142 is configured to enable the recording function of the monitoring application and record the first operation information of the user currently intercepted;

[0112] The operation record generation unit 143 is configured to generate the operation record by the monitoring application after the recording ends.

[0113] In another embodiment, the new Android automated testing system based on wireless driver further includes: a control positioning unit 21, a first operation playback unit 22, and a playback display unit 23.

[0114] The control positioning unit 21 is configured to locate the target control by the monitoring application according to the operation record;

[0115] The first operation playback unit 22 is configured to perform operation playback by the Android system service according to the operation record;

[0116] The playback display unit 23 is configured to display the playback information after the playback ends by the monitoring application.

[0117] In other embodiments, the new Android automated testing system based on wireless driver further includes: a terminal communication unit 31, an operation information receiving unit 32, and a second operation information playback unit 33.

[0118] The terminal communication unit 31 is configured to establish a connection with other Android slave test hosts after the Android master test host and maintain the communication state;

[0119] The operation information receiving unit 32 is configured to receive the second operation information sent in real time by the Android master test host by the monitoring application of the Android slave test host;

[0120] The second operation information playback unit 33 is configured to perform operation playback according to the second operation information by the Android slave test host to achieve synchronous testing.

[0121] In one embodiment, the new Android automated testing system based on wireless driver further includes: a request sending unit 121, a first script transmission unit 122, a second script transmission unit 123, and a script running unit 124.

[0122] The request sending unit 121 is configured to send a request for obtaining the running script of the automation authorization to the PC side by the monitoring application of the Android test host according to the operation command;

[0123] The first script transmission unit 122 is configured to, according to the request, download a corresponding running script in the server on the PC side and send it to the listening application of the Android test host;

[0124] The second script transmission unit 123 is configured to receive the running script by the listening application of the Android test host and send it to the Android system service;

[0125] The script running unit 124 is configured to receive and execute the running script by the Android system service of the Android test host to complete authorization.

[0126] It should be noted that when implementing a new Android automated test system based on wireless drive, only the above division of each functional module is used as an example for illustration. In practical applications, the above functions can be allocated to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, a new Android automated test system based on wireless drive provided in the above embodiment and a new Android automated test method in Embodiments 1, 2, and 3 belong to the same concept. The implementation process is detailed in the method embodiments and will not be elaborated here.

[0127] This application is not limited to the above embodiments. If various changes or deformations to this application do not depart from the spirit and scope of this application, and if these changes and deformations are within the scope of the claims of this application and equivalent technical scope, then this application also intends to include these changes and deformations.

Claims

1. A new Android automated testing method based on wireless drive, characterized in that, it includes the following steps: The listening application in the Android-side test host establishes local communication with the Android system service; The listening application receives the operation commands sent by the PC side and automatically enables the relevant permissions required for testing; The listening application identifies the controls of the Android-side test host according to the operation commands; The Android system service performs automated testing and generates test results according to the operation commands and the identified controls; The listening application obtains the test results and sends the test results to the PC side.

2. The new Android automated testing method based on wireless drive according to claim 1, characterized in that, it further includes the following steps: The listening application intercepts the user's operations; The listening application enables the recording function and records the first operation information of the user currently intercepted; After the recording ends, the listening application generates an operation record.

3. The new Android automated testing method based on wireless drive according to claim 2, characterized in that, it further includes the following steps: The listening application locates the target control according to the operation record; The Android system service performs operation playback according to the operation record; The listening application displays the playback information after the playback ends.

4. The new Android automated testing method based on wireless drive according to claim 1, characterized in that, it further includes the following steps: After the Android-side test host establishes a connection with other Android-side test slaves and maintains a communication state; The listening application of the Android-side test slave receives the second operation information sent by the Android-side test host in real time; The Android-side test slave performs operation playback according to the second operation information to achieve synchronous testing.

5. The new Android automated testing method based on wireless drive according to claim 1, characterized in that, The listening application receives the operation commands sent by the PC side and automatically enables the relevant permissions required for testing, including: The listening application of the Android-side test host sends a request to the PC side to obtain the running script for automated authorization according to the operation commands; The PC side downloads the corresponding running script in the server according to the request and sends it to the listening application of the Android test host; The listening application of the Android test host receives the running script and sends it to the Android system service; The Android system service of the Android test host receives and executes the running script to complete the authorization.

6. A new Android automated testing system based on wireless drive, characterized in that, it includes: A communication unit for establishing local communication between the listening application in the Android-side test host and the Android system service; An authorization unit, configured to enable the monitoring application to receive an operation command sent by a PC and automatically enable relevant permissions required for testing; A control recognition unit, configured to enable the monitoring application to recognize controls of an Android test host according to the operation command; A test unit, configured to enable the Android system service to perform an automated test and generate a test result according to the operation command and the recognized controls; A feedback unit, configured to enable the monitoring application to obtain the test result and send the test result to the PC; 7. A novel Android automated test system based on a wireless driver according to claim 6, characterized in that, it further includes: An interception unit, configured to enable the monitoring application to intercept user operations; A recording unit, configured to enable the monitoring application to turn on a recording function and record first operation information of the user currently intercepted; An operation record generation unit, configured to enable the monitoring application to generate the operation record after the recording ends; 8. A novel Android automated test system based on a wireless driver according to claim 7, characterized in that, it further includes: A control positioning unit, configured to enable the monitoring application to locate a target control according to the operation record; A first operation playback unit, configured to enable the Android system service to perform operation playback according to the operation record; A playback display unit, configured to enable the monitoring application to display playback information after the playback ends; 9. A novel Android automated test system based on a wireless driver according to claim 8, characterized in that, it further includes: A terminal communication unit, configured to enable the Android test host to establish a connection with other Android test slaves and maintain a communication state; An operation information receiving unit, configured to enable the monitoring application of the Android test slave to receive second operation information sent by the Android test host in real time; A second operation information playback unit, configured to enable the Android test slave to perform operation playback according to the second operation information to implement synchronous testing; 10. A novel Android automated test system based on a wireless driver according to claim 9, characterized in that, it further includes: A request sending unit, configured to enable the monitoring application of the Android test host to send a request for obtaining a running script for automated authorization to the PC according to the operation command; A first script transmission unit, configured to enable the PC to download a corresponding running script in a server according to the request and send it to the monitoring application of the Android test host; A second script transmission unit, configured to enable the monitoring application of the Android test host to receive the running script and send it to the Android system service; A script running unit, configured to enable the Android system service of the Android test host to receive and execute the running script to complete authorization.

Images