background

As Meituan-Dianping has expanded and its r&d team has grown, demand for test phones has grown significantly. This is not a small expense for the company, but the existing test cell phone resources are unevenly distributed and the utilization rate is very limited, which makes it difficult for each team to cover multiple models in the development and testing process. How to make reasonable and efficient use of these testing mobile phone resources is a difficult problem in front of us.

Existing scheme

In order to solve these problems, some mobile phone management and online debugging tools or platforms have emerged in the industry. The most common ones are:

  • OpenSTF
  • Baidu MTC remote real machine debugging
  • The cloud telephony of Testin
  • Tencent WeTest’s Cloud real machine
  • Ali MQC remote real machine rental

OpenSTF is an open source project, and most other platforms are also based on the principle of OpenSTF. Therefore, we conducted an in-depth study of the OpenSTF project.

Problems encountered

We first built according to OpenSTF’s official scheme and applied it in a small scale, but gradually we found some problems with it:

  • There are too many modules with tight coupling and great difficulty in decoupling. Every modification requires updating all modules, which makes rapid iterative development difficult.

  • Some technology selection is backward. Due to OpenSTF’s early emergence, some technologies have fallen behind the current mainstream. For example, The OpenSTF front-end was developed using AngularJS 1.0, which has lagged behind other popular frameworks in terms of ecochain; Database selection of non-relational database RethinkDB, in terms of data calculation and performance is weaker than MySQL and other relational databases, RethinkDB data is less, not easy to develop and maintain.

  • OpenSTF screen image transmission is carried out in the way of single image transmission, and the picture quality cannot be adjusted by users. In practical application, the bandwidth is very high, and there will be serious lag phenomenon in the case of poor network, resulting in poor experience.

Our plan

Architecture design

According to the needs of business scenarios, and absorbing the advantages of OpenSTF structure, we adopt the modular design scheme of Agent/Server model. The functions of the main modules are described as follows:

  • The Agent module. The Agent module is similar to the Provider of OpenSTF. It is deployed on the server or the user’s computer. The Agent connects to the real mobile phone, dynamically proxies the screen image of the mobile phone to the Websocket server through Websocket, and then transfers messages through the message center.

  • The Server module. Server is used for centralized management and scheduling of mobile phones. Different from OpenSTF structure, our Server includes Web Server, Websocket Server, dynamic proxy and message processing service. The Server dynamically proxies the user access to the corresponding Web Server and Websocket Server, and transmits messages to the message center through the message processing module to realize the interaction between the user and the Agent mobile phone.

  • Data storage module. The data storage module is used to save the data of the whole platform, such as the status of mobile phones, user usage records and so on. The data storage module is composed of MySQL database and an RPC service. The Server no longer reads and writes the database directly, but reads and writes the data through an RPC service.

  • Message center. Similar to the triProxy function of OpenSTF, it is a hub connecting mobile phones and servers. The message center mainly processes messages such as screen operations and status changes of mobile phones.

Through modular design, the project structure is clearer than OpenSTF. Here is the design of the whole system:

Advantages of architecture

Agent module we directly reuse most of the OpenSTF provider functions, including MinicAP, Minitouch and so on. Based on this, we also extended some of OpenSTF’s missing features, such as:

  • Secondary development was made on the basis of provider to support picture quality/frame rate adjustment (more on that below).

  • Add the health check function to check whether the mobile phone network is normal and whether the network agent is configured.

  • Add the Inspector feature for easy access to the UI control tree (more on that later).

  • Agent versions are differentiated so that the Web terminal can display and hide corresponding functions based on Agent versions.

In the Server module, we introduced the dynamic proxy mechanism, and re-developed the Web part, using Vue 2.0 + iView to achieve, database using MySQL.

Compared with OpenSTF’s native architecture, it has the following advantages:

  • Low coupling of modules makes development and deployment easier. It is very difficult to develop and deploy OpenSTF on the basis of the large number of various functional modules and tight code coupling. We divided the whole project into four modules: Server, Agent, message center and data storage. The functions and codes of the four modules are independent, basically without coupling relationship, supporting rapid iterative development and convenient deployment.

  • Front-end frameworks are more mainstream and cost less to develop and maintain. The OpenSTF front-end was implemented using AngularJS 1.0. AngularJS 1.0 has been deprecated, third-party components have largely ceased to be supported, the AngularJS 2.0 community and ecosystem is immature, and we adopted the Vue 2.0 front-end framework. Vue 2.0 is relatively mature and has a large number of applications in the United States, enabling rapid development of high-quality Web functions.

  • The database has strong performance, flexible design and convenient maintenance. OpenSTF uses RethikDB as the database. RethikDB is a NoSQL database, which has many disadvantages, such as poor performance in processing a large amount of data, lack of data, difficult troubleshooting and database maintenance. And we use the MySQL database, a good solution to these problems, and to achieve the separation of Server module and data read and write, so that when updating the database table structure, there is no need to modify the Server side code, as long as the interface format of RPC service is consistent, development and maintenance is more convenient.

In addition to these basic features, we have also developed some feature features, which are described in detail below.

features

Integrate with client automation

In order to make reasonable and efficient use of test mobile phone resources, we combine with client automation, mainly in two aspects:

  • Deep integration with the cloud measurement platform within the group. Agent code is deployed on the server node of the cloud testing platform to provide automation process display and remote debugging functions for the creators of automation tasks of the cloud testing platform, and open the idle mobile phones of the cloud testing platform to more people.

  • Open apis. We have opened some apis for ordinary users to query the status of the phone, occupy the phone, connect to ADB debugging, etc. Users can use scripts to call the API, and then perform automated tests directly on the platform’s phones.

A booking

When a mobile phone is busy, the user must wait for the mobile phone to be idle before using it. As the mobile phone idle time is uncertain, it will bring great inconvenience to the user. In order to solve this problem, we developed the mobile phone reservation function. Users can reserve a busy mobile phone. When the mobile phone is idle, it will automatically occupy 15 minutes for the reserving user and notify the reserving person through instant messaging tool.

Quality regulation

The core of the remote debugging platform is to obtain the screen image in real time. Due to the large network bandwidth required for screen transmission, there will be a lag phenomenon in the case of poor network. Therefore, we have made some fluency optimizations for different networks. Here are the details.

Screen capture works by taking high-speed screenshots — up to 60 per second — through Minicap and displaying them on the Web. The first is to adjust the quality of screenshots. Minicap itself supports adjusting the picture quality (OpenSTF has a fixed 80% compression ratio). The key codes are as follows:

var rate =  Number(match[6])
    if (rate > 2 && rate < 100) {
      log.info(rate)
      if (rate > 30) {
        options.screenJpegQuality = 80
      }else if (rate > 15) {
        options.screenJpegQuality = 50
      }else {
        options.screenJpegQuality = 20
      }

      frameProducer.restart()
      framerate = rate
    }
Copy the code

The second is to adjust the number of pictures sent per second, that is, the frame rate. We can control the number of pictures sent on the Agent, and the key codes are as follows:

# First modify the framerate send part:
function wsFrameNotifier(frame) {  
  if (latesenttime == 0 || Date.now()-latesenttime > 1000/framerate) {  
    latesenttime = Date.now()  
    return send(frame, {  
      binary: true}}})Add the code to adjust the frame rate:
case 'rate':  
  var rate =  Number(match[6])  
  if (rate > 2 && rate < 100) {  
    framerate = rate  
  }  
  break
Copy the code

So, how much frame rate and image compression ratio can be adjusted to meet the needs of different network environments? Let’s start with a set of statistics:

Picture compression ratio Image size
100% 69.82 KB
80% 46.78 KB
50% 41.87 KB
20% 37.84 KB
10% 35.84 KB

The table shows the image compression experiment conducted by Minicap. From the data, we can see that when the image quality is reduced to 80%, the image size is significantly reduced, but the image quality is not significantly decreased. Continue to reduce image quality, image size reduction is limited. Let’s look at another set of data:

Frame rate Picture compression ratio Actual flow
60 100% 4.02 M/S
60 80% 2.74 M/S
60 50% 2.41 M/S
30 80% 1.43 M/S
30 50% 1.22 M/S
30 20% 1.10 M/S
15 50% 0.63 M/S
15 20% 0.55 M/S
15 10% 0.52 M/S

The table shows the actual traffic data generated by various combinations of frame rates and compression ratios.

From the data, we can see that under the combination of the highest frame rate and compression ratio, the flow reaches 4M/S, while when the compression ratio is 80%, the flow decreases to 2.7m /S, which is a very obvious decrease. Considering the actual network conditions, we chose 60 frames and 80% compression as the high quality option.

When the image quality drops from 80% to 50%, the image size does not decrease significantly, so reducing the frame rate is a good option. When the frame rate is reduced to 30 frames, the traffic is reduced by half. 1.2m /S traffic can meet most network conditions, and 30 frames can guarantee smooth operation, so 30 frames, 50% compression ratio becomes the medium quality option.

Low picture quality is mainly to ensure normal use in poor network environment, 500K/S traffic is the red line. We chose 15 frames and 20% compression ratio as the low quality option, where the image quality and frame rate are lower, but the basic experience is guaranteed.

In addition to reducing the image quality and frame rate to reduce the flow of mobile phone screen image transmission, the use of H264 image compression into video transmission is also an effective way to reduce the flow. Compared with pictures, the image compression rate will be higher, and users will have a better operation experience. However, the principle of image compression coding is more complex, and related technologies are still being studied.

App Mock

In the process of App testing, packet capture is often needed. In general, we can achieve this by modifying the WiFi agent and using the packet capture tool. However, it is inefficient and inconvenient to switch between multiple tools. With the help of the group’s Mock platform, we developed the one-click Mock function, which can quickly complete the Mock operation of the corresponding App. The advantage is that we can view the requests sent by the App while operating the App, which greatly improves the efficiency of the test.

App Inspector

The App Inspector feature allows users to view the page control tree and page elements while using the real machine on the platform. It also supports Xpath, making it easier and more efficient to find page elements, making it easier to automate UI testing.

We did this with the help of Uiautomator. The basic principle is to write a Uiautomator use case, which is used to obtain the Hierarchy of the current page, and then package the case into a JAR and put it on the Agent. When the control tree is triggered on the Web side, the Agent pushes the JAR package to the mobile phone and runs it. At this time, an XML file will be generated on the mobile phone side. The XML content is then retrieved and parsed in the front end using the cat command. The core code of the use case is as follows:

public class launch extends UiAutomatorTestCase {

    public void testDumpHierarchy() throws UiObjectNotFoundException {
        File file = new File("/data/local/tmp/local/tmp/uidump.xml");
        UiDevice uiDevice = getUiDevice();
        String filename = "uidump.xml"; uiDevice.dumpWindowHierarchy(filename); }}Copy the code

Of course, you can also fetch Hierarchy with the ADB command:

adb shell uiautomator dump /data/local/tmp/uidump.xml
Copy the code

However, this method does not get dynamic pages, such as video playback pages.

Data report

In order to better understand the operation of the platform, we made detailed statistics, mainly from the use times, use time, equipment number, use distribution and other aspects of statistics. At present, we manage nearly 300 mobile phones, with an average of more than 500 r&d staff using our platform every month, using it 280 times a day and using it for more than 60 hours a day.

Other small features

In addition to the above large functions, we also made some thoughtful small functions, such as: detection of mobile network agent, detection of installed application version and installation time, quick installation of the latest version of the test package, support for in-app Schema jump and so on. These small features save developers a lot of time and improve their productivity.

The future planning

IOS Mobile support

Currently, the cloud Telepresence platform only supports Android phones, with support for iOS phones in the works. We have preliminarily completed the development of the main features and expect to see them soon.

Product optimization

We plan to continue to expand product features such as support for Log display and performance data collection. At present, the Yunzhen platform has been running smoothly within Meituan-Dianping for more than two years. We will continue to iterate and refine our products to provide better user experience.

Author’s brief introduction

Dong Chu, head of quality Tools Team of Dianping platform. 7 years of testing and development experience in the Internet industry, joined the former Dianping in 2015. Successively led the development of cloud real machine platform, unit test platform, Web security experiment platform and other projects, committed to using tools to improve the work efficiency of the RESEARCH and development team.

Li Shuai is a senior test development engineer at Dianping. In 2015, I joined the original Dianping and was mainly responsible for the development of cloud real phone platform and testing of the underlying components of the client. Keen to study the cutting-edge technology in the field of testing, and promoted the landing of a number of new technologies.

Recruitment information

Review platform – Platform Quality Center, Base Shanghai, mainly responsible for quality assurance of the platform entrance and basic functions. Platforms include DIANping App, Dianping wechat mini program, PC site: www.dianping.com, M site: m.dianping.com; The main business covers account number, POI, evaluation, video, article, member community, Q&A, operation activities, search recommendation, communication link, operation activities and other basic services. We warmly look forward to your TALENTS in QA, development and algorithm joining the technology department of review platform. Contact email: wenjie.pan#dianping.com