Mobile Testing black tech _ PHP Tutorial based on dynamic plug-in system

A mobile testing black technology based on dynamic plug-in systems. Baidu MTC is an industry-leading mobile application testing service platform, for the costs and technologies faced by developers in mobile application testing and a mobile testing black technology based on dynamic plug-in systems
Baidu MTC is an industry-leading mobile application testing service platform, providing solutions for the costs, technologies, and efficiency problems faced by developers in mobile application testing. At the same time, we will share the industry's leading Baidu technology, written by Baidu employees and industry leaders.

Author: hyxbiao & tony xin
Email: hyxbiao@gmail.com & jiankangxin@gmail.com

Background

Mobile APP ins are a powerful tool for platform-based products to address system restrictions (65535), module decoupling, and multi-team collaboration. Its biggest characteristic is the dynamic delivery of modules, which brings obvious benefits to the product. However, in Baidu, this system brings new ideas to mobile testing technology.

Mobile Terminal online problem locating scenarios:

• Scenario 1: cloud users report that a function is unavailable. RD guesses several possible causes. the logging information of the client collected online is incomplete and the problem cannot be fully confirmed. In an endless loop, online users continue to expose problems, and offline users cannot replicate stably, so they cannot locate problems in a timely manner. How can this problem be solved?

• Scenario 2: hitting user behavior through the client pre-burial mode usually causes incomplete hitting. However, online issue locating often requires these behavior logs to provide a good reproduction step for problem locating. How can I obtain full logs of user-client interaction through technical means without coding?

• Scenario 3: many offline tools can be SDK-based, which brings a lot of positive benefits to online problem discovery and locating. However, because the testing capability affects the performance of integrated apps, or the development team schedule and other reasons, cannot be integrated, and a large number of online problems cannot be fully exposed. How can this problem be solved elegantly?

• Scenario 4: Baidu's online client small traffic experiment shows that online problems are actually a normal distribution of random events. TOP problems often can be recalled after a small number of users are sampled, without affecting all users

Scenarios of mobile terminal testing:

• Scenario 1: The client test is simple but complex. The simple skill tree of a client tester may include the ability to analyze these problems: ANR, crash, choppy, memory leakage, memory, CPU usage, power analysis, startup speed analysis, and so on. Generally, some QA personnel are not full-stack. In addition, these tools are a collection of tools. How to enable the client tester or non-professional tester without any background. you can analyze all client problems with just a few points.

• Scenario 2: similar to the online problem locating just now, a large number of excellent offline functions cannot be applied to all users, because they are actually hurting the enemy by eight hundred and self-healing by one thousand. How can we recall all problems as much as possible while minimizing user experience loss?

A new idea for mobile terminal online problem locating:

Build a test plug-in based on the plug-in system to integrate all the offline test capabilities that we find useful, and integrate well-known frameworks in the industry, such as dexposed and leakcanary, there are also some good things that are available in the main version but will affect the performance, such as traceviewer, Choreographer, and ActivityLifecycleCallback. All of them are transferred to the cloud plug-in, and distributed to specific target users' mobile phones through the dynamic module small traffic system that has been built on the cloud. problems are continuously exposed.

Nice job !!

How Cloud plug-ins work:
The cloud plug-in itself is a host plug-in. what truly gives full play to its testing capability is a large number of test scenarios built offline, as well as the dynamic loading mechanism of the plug-in itself, in this way, our testing scenario can play its role online. When I mention this, I have to stir fry the old rice in a new pot:

• Parent-parent delegation: under the class loading mechanism of java, the sub-classloader can look up the content loaded by the parent classloader, this provides cloud plug-ins with a prerequisite (multi-process plug-in system) to dynamically search for various types of host information .. Ignore me)

• Dexclassloader: Attackers can load arbitrary JAR files (including dex files), zip files, and apk files of the file system.

• Patchclassloader: only the apk files of data/app/can be loaded. it is often used for splitting multiple dex files.

• Dexfile: it can load dynamic files and extract class information inside the file. this is not available to dexclassloader.

• Shell: The Cloud plug-in needs to integrate the information Upload class in its own scenarios. However, during compilation, the corresponding class cannot be compiled into the plug-in package. In this way, after the plug-in is loaded, the log system of the host can be called back for information collection.

After the preceding steps, the scenario plug-ins in JAR or APK can be dynamically loaded by Cloud plug-ins, at the same time, various types of hosts, local space, and host-related information in the system are read and collected. Hook, reflection, code injection, exception capture, and plug-in are just a means.

Instance:

Note: In the following case, although the problem locating scenario of Cloud plug-ins is described, we will open-source this technology in the form of SDKs, the app integrated with this SDK can do the same, but it is out of the plug-in system and its own security requires the integrated developers to pay attention to their own security. Of course, you can also ignore it. on The root mobile phone, all your apps have been exposed to hackers (BLESS ...)

Body: taking smoothness as an example, let's look at how to quickly build a cloud debugging plug-in case.

Smoothness: it can be understood as the speed at which the android system draws the UI. Theoretically, the program will be smooth only when the human eye receives 60 images within 1 s. At the beginning of the android system, Smoothness was always the target of criticism. when the android 4.1 system was built, the project Buffer was specified, and three major elements were introduced: VSYNC (vertical synchronization), Triple Buffer, and Choreographer. Among them, Choreographer is the goal we are discussing today. It is the coordinator in the entire mechanism, and all loads share a Choreographer object.

Choreographer opens a FrameCallback object. it calls back the doFrame function every time the system draws the object. This function can be used to calculate the number of times the current page is drawn within one second. But the problem is:
Look, it means that although this product is good, it is recommended that you developers still do not use it... In this case, I still wanted to monitor it smoothly .. At this time, we will surely think that we have cloud debugging plug-ins.

The build is very simple. as shown below, you only need to copy this code to any android project and package it. Note that NutXError is only used as the compilation dependency. if you already have a plug-in system, this code can be directly loaded and run.

public class NutFrameMonitor extends BaseCase { private static final String TAG = "NutFrameMonitor"; @Override public void invoke(Context context) { int sdkVersion = 0; try { sdkVersion = Build.VERSION.SDK_INT; } catch (Exception e) { // TODO } if (sdkVersion >= 16) { try { Choreographer.getInstance().postFrameCallback(NutFrameCallback.callback); } catch (Exception e) { // TODO } } } private static class NutFrameCallback implements Choreographer.FrameCallback { static final NutFrameCallback callback = new NutFrameCallback(); private long mLastFrameTimeNanos = 0; private long mFrameIntervalNanos = (long)(500000000) - 1; @Override public void doFrame(long frameTimeNanos) { if (mLastFrameTimeNanos != 0) { final long jitterNanos = frameTimeNanos - mLastFrameTimeNanos; if (jitterNanos > mFrameIntervalNanos) { NutXError error = new NutXError(TAG); error.setDetailMessage("frame Choreographer waste more than 500ms"); error.dump(); } } mLastFrameTimeNanos = frameTimeNanos; Choreographer.getInstance().postFrameCallback(NutFrameCallback.callback); } } } 

Result

The following is a smoothness problem found during the operation of the client (note that the monitoring case is dynamically loaded through the cloud plug-in. At the same time, we can also see that, after the problem of plotting is monitored, every page that the user stays on is also drawn. Then we can reproduce the result along this trace ~
Is it cool ~~~

Postscript

As mentioned above, we have ended our discussion on Baidu's mobile testing technology. However, there are many issues that have not been mentioned, such as the existing automated cases and the compatibility of these mechanisms, for example, some users may find that the system may have compatibility problems. how can we control the problems and ensure that the cloud debugging plug-in (called the nut cloud in fact) can be effectively and timely recycled. In fact, we are confident that we can try this online. On the factory's production line, we have a full set of dynamic module small traffic systems. The Cloud plug-in itself is actually used as a dynamic module. when problems occur online, our cloud plug-in will play its value.

For more information, please pay attention to "Baidu MTC College" http://mtc.baidu.com/academy/article

Baidu MTC is an industry-leading mobile application testing service platform, which provides developers with the cost, technology, and...