background
In the design of a cloud test platform, the following scenarios need to be considered in the design of the agent:
- Whether the interactive control of the mobile device requires the support of the PC device
There are two main ways to interact with mobile devices, one is to use public protocols such as adb and usbmuxd to interact with data through the debugging method of PC-Mobile as commonly recommended by the official, and the other is to directly implant code in Mobile and interact with the system API and server through code, eliminating the transfer link of PC
- How mobile devices are isolated for test task execution
In the process of using the device, it also needs to consider which APP, which type of APP, which group of people, which test type, etc., so the "atomicity" of a single device needs to be considered when designing
- How to achieve dynamic operation and maintenance and automation of equipment
At the same time, if the maintenance of the device is in a public laboratory or in a remote computer room, the corresponding operations need to be completed remotely, so remote APIs are also required for equipment maintenance, reset, monitoring and other related operations
- Automate framework selection and runtime environments
Automated testing is the main purpose of cloud testing, and the choice of automation framework will affect the expansion of automated testing capabilities, so it is necessary to choose a suitable "basic" automated testing framework
System selection
The Zhihu cloud test platform uses the PC as the server to maintain the mobile device, and the interaction mode is the server-PC-mobile device interaction, the PC deploys the agent code that interacts with the server, uses the socket to communicate to ensure immediacy, and actively consumes the task pool maintained by the server through http, returns the data and loops after the execution, and uses Appium as the "basic" automated test framework for the execution of automated tasks. The system selection is mainly based on the following points:
- Most of the automation frameworks are based on the PC corresponding to the mobile mount USB, and the agent service, automation framework, hardware operation and maintenance, and exception handling all require a stable PC running environment
- The Netty Socket framework can provide stable and instant data exchange
- The processing of task data requires higher precision, so the HTTP request task pool is used
- The automation framework selects Appium, which has certain advantages in all aspects, "mainly because the community is more active", and the isolation of equipment to perform test tasks is also mainly controlled by Appium, as shown in the comparison chart below:
Agent module
The agent module is mainly responsible for the functions of equipment control and maintenance in the cloud test platform, and mainly includes three modules as follows:
Real-time tasks
基于 Netty Socket
The real-time interaction is shown in the following figure:
Mobile device control
Here, the mobile device control is convenient for users to remotely control the operation of the device in a certain way at the remote end, and at the same time see https://github.com/openstf/stf the real-time display screen of the device. stf is a web tool that can remotely debug mobile phones, watches, and pads.
Referring to the use of minicap / minitouch in the nodejs source code of stf, since the Agent platform is written in java / kotlin, and minicap / minitouch is written in C/C++, the manually compiled minicap / minitouch runner is built into the Agent to provide calls.
minicap
GitHub address: https://github.com/openstf/minicap
When the device is connected, the minicap initialization thread will be divided into the following steps to initialize and start the device:
minitouch
GitHub address: https://github.com/openstf/minitouch
When the device is connected, the minitouch initialization thread will also be divided into the following steps to initialize the device:
Agent minitouch / minicap 和 pc 交互图如下:
Scheduled tasks
The advantage of the cloud test platform is that it can dynamically call multiple devices for testing, and the operation of each device is independent, so the minimum granularity of the task operation design is subject to the operation of a single device, so whether it is compatibility testing, installation testing, automated script testing, performance testing, etc., it will be split into a single task on the server side and stored in a multi-dimensional queue in the form of a task pool You only need to get the queue task of the corresponding device to run during the interaction. Different from the immediacy of the interaction required by the remote control of the device, the remote control requires that the instructions must be delivered and returned within milliseconds, and the interaction of automated tasks can tolerate a certain delay, so the HTTP polling method is used in the interaction with the server:
HTTP polling
The detailed process of polling is shown in the following figure:
Equipment maintenance
After the agent is deployed, it will actively listen to the current ADB/USB device connection status, and perform the corresponding steps in the diagram to maintain the connection status of the device when a new device is connected or an existing device is removed, so as to achieve automatic access and removal of mobile devices.
At the same time, in the process of task execution, remote control, offline online and other processes of the device, data maintenance interaction will be carried out with the server, and the status of the device will be synchronized to the server, providing a judgment basis for the server's task processing, queuing strategy, dynamic task allocation, etc
Problems encountered and dealt with
1. minicap / minitouch 设备兼容问题？
Due to the unknown device type in the back, only the specified model device has been specially compatible with the agent inside, except for a few device types that are not naturally supported by stf, no large number of compatibility problems have been found.
2. Is there a problem with the real-time transmission of device images?
At present, most of the task processing is in the company's intranet environment, and only the image data level compression is currently done, and it is foreseeable that in the case of poor network environment, image pixel-level compression may be required.
Image processing is an important part of remote control, and the main processing methods are as follows:
The size of a single image we get from the current mainstream mobile devices should be about 1M, if it is a high-resolution device or iPad, AndroidPad and other devices may be larger, and pure data compression can only achieve a maximum of 100 KB in size.
Under the above premise, we can sacrifice the clarity of a part of the picture in exchange for the smoothness of the operation and network performance, as shown in the figure, we first compress the original image to a certain size according to the proportion, and then render the compressed image on the page to the same size as the device.
In this way, the lost clarity is directly related to the proportion of compression, and the proportion of image compression can be dynamically modified according to the quality of the network in the process of data transmission.
After image compression and data compression, the transmission level of the image can be reduced to the level of 10 KB size, and the size of the image data transfer of most devices fluctuates around 20 KB, and at the same time has good definition.
3. Is there a problem with the stability of the equipment maintenance thread and the automatic processing thread?
When the agent finds problems such as frozen death, freeze, or timeout during the operation of the agent, it will directly send an alarm through IM, and the operation and maintenance can reinitialize the device-related threads through page operations to find and deal with the problems in time.
Author: Chen Kangkang
Source: https://zhuanlan.zhihu.com/p/83373208