在android项目中，我们知道，Android application如果没有充分测试，很容易出现FC(Force Close)的问题。我们这里通过使用Android自带的monkey工具来做大量的软件压力测试，部分性能测试，而且，不需要投入很多精力，并且可以延伸到很多人所不能的方面，节省大量人力物力，提供准确的FC信息。

1.3 试行monkey的计划

如何在我们的项目中，普及monkey？

如何让monkey工具发挥更好的作用？

我们在使用monkey这个工具的时候，打算是分为三阶段来使用的，具体如下：

研发阶段（test level 1）
研发稳定阶段（test level 2）
定制阶段（test level 3）

在第一阶段（test level 1），主要是：手工测试的补充，利用无数次尝试，加强自由测试力度。

这是我们针对我们公司“高要求多需求”的实际情况制定的一个方法。

在长期的QT实践和观察中，我们发现，案例测试，一般可以覆盖一些基本问题，而UR上的很多问题，并非是由案例去发现的，大多是测试者的主观发现，这种方式，我们测试上姑且称之为“无序测试”，同理，案例测试可以称之为“有序”了。

在复杂庞大的android软体环境下，认为因素的“无序”已经无法再逾越一个测试极限，那么这个时候，就应该引入“更加强大，量大”的“无序”动作，monkey应运而生！

我们这阶段，就是引入monkey中“执行次数（count）”这个参数，所有的东西都是在这个参数上做文章，以量变引发质变。

第二阶段（test level 2），主要是：科学安排相关参数，知道需要测试的方向，进行针对测试。

就是设置延时，事件类型等参数，进行针对性测试。我们通过调节这些性能相关的参数，或者控制设置很影响某些模块的事件，以及第一阶段总结的执行次数，来测试衡量模块的性能，稳定性。而做这一工作，单纯的人力是无法做到。

第三阶段（test level 3），主要是：“修改”或者“等待”源码支持，拟定自己的测试步骤，控制事件。

对于monkey，他如其他工具一样，不可能是为oppo定制，所以，有许多自己公司特有的东西，他支持的不好或者不支持，需要我们去改善，我们后期的工作，会深入到源码、机制，进行我们的定制行为。

2 monkey使用

2.1 基本常识

Monkey是自带的，在手机的/system/framework/monkey.jar文件，执行文件位于/system/bin/monkey,是一个shell命令。

monkey的基本架构图，如下：

编辑

相关事宜，也可以参照源码目录：

Monkey是用JAVA写成的,但是我们确可以这样运行:：

“adb shell monkey …..”

为什么？

是因为在/system/bin目录下有一个monkey的shell脚本.内容如下：

#Script to start "monkey" on the device, which has a very rudimentary

# shell.

base=/system

export CLASSPATH=$base/framework/monkey.jar

exec app_process $base/bin com.android.commands.monkey.Monkey $*

exec 会运行起/system/framework/monkey.jar。关于源码研究的，我们在这里不再深入下去了，后续会有一些东西补充上来。

2.2 基本使用

2.2.1 通过adb 来启动monkey

确保目标板“设置->应用程序->开发->USB调试”选项打开。连接目标机后，启动“cmd”命令。

输入“adb devices”命令，可以查看连接的设备，如图：

连接成功后，会反馈如下信息：

由于Monkey运行在模拟器/设备环境中，所以必须用其环境中的shell来进行启动。可以通过在每条命令前加上adb shell来达到目的，也可以进入Shell后直接输入Monkey命令（或者直接启动“adb shell”命令后直接使用monkey命令。），基本语法如下：

$ adb shell monkey [options]

具体如下：

或者

如果不指定options，Monkey将以无反馈模式启动，并把事件任意发送到安装在目标环境中的全部包。下面是一个更为典型的命令行示例，它启动指定的应用程序，并向其发送500个伪随机事件：

$ adb shell monkey -p your.package.name -v 500

例如，测试“com.android.camera”这个包（相机应用），可以输入：

2.2.2 一些命令选项

Monkey包括许多选项，它们大致分为四大类：

基本配置选项，如设置尝试的事件数量。
运行约束选项，如设置只对单独的一个包进行测试。
事件类型和频率。
调试选项。

这里有一个附表，有很详细的介绍，请看

2.2.3 一些测试例子

【使用monkey测试camera】

第一阶段（test level 1）：控制测试次数

指令如下“monkey -v -p com.android.camera x（次数）”

这段时间，技术支持会先预测次数，然后获取问题反馈，增加测试次数，整理次数数据。

测试每一次，大概5分钟

技术意图是：通过高频操作，捡取内存控制不当事件，适用于改动较大阶段

第二阶段（test level 2）：控制次数和时间延时

运行指令如下“monkey -v -p com.android.camera --throttle x y”

这会根据第一阶段的数据，获取相应的次数，根据性能评估测试时延（技术支持事先运行该模块，做一个基本的概率统计）

这段时间，主要是看延时值，参考次数值，需要数据反馈

技术意图：通过统计不同的时延数值和测试次数值，评估性能和稳定性。

控制时间概率

运行：

“monkey -v --pct-touch 60 --pct-nav 30 -p com.android.camera 500”

“monkey -v-v-v --pct-touch 60 --pct-nav 30 --throttle 300 -p com.android.camera 500”等类似复合指令

通过控制事件复杂度，达到界定问题的目的

这种复杂度的控制，是基于大量数据反馈到技术支持侧，通过分布统计，界定问题

2.2.4 执行注意事项

关于“your.package.name”

在开发data目录中，根据项目实际情况寻找开发包名，或者向开发工程师咨询。

试着提供一个命令执行场景：

monkey -v -p com.android.camera --throttle 5000 --pct-anyevent 100 500

这条命令的解释是：

-v 显示默认程度的信息；

-p com.android.camera是指定测试的程序；

--throttle 5000 设定延时；

--pct-anyevent 100设定启动activity的百分比为100%；

--500 执行500次操作。

执行场景：

再执行一下：

monkey -v -p com.android.camera --throttle 5000 500

仔细比较此图，可见各类事件是可以控制的。要是有点经验的话，我们执行“拨号盘”这个模块测试，可以将虚拟键盘事件控制到零，避免不必要事件发生。

2.2.5 侦测到错误后的处理

这里运行一个例子，对mydemo应用进行500次任何触发事件随机压力测试（无时延）

$ adb shell monkey -p com.example.mydemo -v 500

运行后，将出现一些信息，目标机上将会出现“应用程序mydemo意外停止，请重试”，截取的有效信息如图：

注意：只有“cout”= =“events injected” 测试才执行成功。

在一般情况下，我们获取到FC后，会根据小机情况，我们有时可以运行“logcat”指令获取信息，或者，通过adb pull获取小机中的log。

2.2.6 自动化执行脚本

这里有一个实例，就是让测试员运行写好的测试脚本，进行“一键操作”。

大家连上机子，可以运行一个小玩意，附件如下：

这是一个测试拨号键盘的自动化测试执行脚本，你运行后，他自动测试拨号盘2万次，并且把log和bugreport记录到“d：\bat”目录下。

大家也可以在熟悉指令后，运用自己的才智进行这种脚本的编写。

3 总结

Monkey是一个灵活而强大的工具，可以用来提高应用的稳定性，注意它是伪随机的，所以如果不指定-s <seed>（随机数种子）则每次将运行相同的事件序列。

另外，虽然我们可以通过这种高强度的测试，获知相关软体稳定度，但是，目前还无法界定测试指标。比如，多少次才合格？时延设置是多少，可以客观反映系统性能？等。这些问题并非测试软件本身的问题，需要大家在实践中进一步去积累。

这次的探讨就讲到这里，关于test level 3，我相信随着我们了解的深入，后续支持的增加，我将会和大家再分享。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/从前慢现在也慢/article/detail/669356