最近在做一些monkey压力测试的改进工作，网上也有一些修改Monkey源码的分享，写得挺好的，我不一一赘述。这里介绍我对于monkey源码修改的一些实践，并一一给大家介绍我所说的基于场景化的monkey压力测试。
熟悉monkey的同学或多或少地知道这个工具的优点，这里我关注monkey的某些缺点，比如:无法识别控件，无法判断被测对象出现异常后如何处理等，除了这些，其实对于一些只提供服务的应用，比如微信小程序，这种快应用越来越普及，而这种应用我们无法直接通过monkey去启动测试，其中微信类似于提供了小程序的一个服务平台，此时有同学会说，我启动微信，然后再点击小程序入口不就可以进去了吗？是，这种方法是可以，但是我们要知道monkey是随机启动应用的，因此会存在即使我们点击进入了小程序，但是很快又会回到微信界面，然后有可能再也无法进入到我们想进行monkey压力测试的特定小程序。
要想能满足特定的测试需求，必须对于monkey源码进行改造。monkey源码的改造还是有比较多的案例，包含自带截图、防止禁止网络等。而这里我讲的主要是为了满足场景化测试做的一些改进，范围限制于类似于小程序的接口测试，测试对象是对外提供接口或者组件的服务应用。咋一听，感觉monkey这种随机构造事件的工具跟场景化测试毫无关联。何为场景化呢？我的理解就是根据一定的、有目的地构造测试条件或者背景，同时这些条件或者背景是符合实际用户使用的。那么针对开放出去的接口或者组件如何进行场景化构建从而为monkey压力测试提供测试对象呢？在我们的实践过程中主要采取两种方式:一种来源于已经开发商用的成型的应用，这类应用已经被用于一定商业目的开发出来的，其实已经满足上面提到的要求，第二种就是针对接口的分析，测试同学人为对接口和组件进行组合后开发出成型的应用，达到尽可能多的覆盖所有接口。这些测试对象梳理出来后，我们就可以进行下一步monkey源码改造了。
上面讲了那么多，其实也已经初步说明了本次实践的主要目的：1、让monkey能主动去进入我们指定的小程序 2、当monkey发送intent消息去启动另外一个应用时能主动再跳回到原有的小程序继续执行monkey事件。那么如何做到这些呢？在runMonkeyCycles循环函数里增加一个判断分支，当发现小程序进程未启动或者小程序存在崩溃了，主动拉起小程序，那如何拉起小程序呢？这里我比较简单得做了一个处理，即通过appium去事先获取到小程序入口的坐标传给monkey。然后在MonkeyActivity.java文件里使用intent启动另外应用的时候进行判断,判断intent消息里compnent中packeagename是否是另外一个应用的包名？若是，则再重新拉起小程序，若不是，那就不处理。同时为了让monkey操作过程中可以进行内存泄露和实时截图，这里再引入另外两个工具：procrank和minicap。这两个工具不在monkey里引用，而是通过python脚本，使用启用三个线程，分别执行monkey命令、使用procrank进行内存监控、使用minicap工具进行实时截图。
通过上述几个过程，我们就可以更精确地保证monkey事件的有效执行，从而实现monkey的场景化压力测试。
