monkey测试主要做随机的黑盒测试，通过不断输入伪随机的事件流来测试应用的稳定性，但是由于monkey太过皮，太过随机，最后根本无法控制，很容易陷于一个页面无法出来，或者陷入某个无关紧要的地方无法出来，导致测试结果并不具有很好的意义。
基于上述原因，尝试了一些二次开发monkey的测试工具，例如maxim，可以通过一些黑白名单控制，或者输入指定事件流，或者指定不同的测试随机模式，深度优先或者控件识别等，在使用了之后发现，还是会出现陷入到一个地方出不来的情况，虽然加入了熔断机制，在一个地方执行了太多次数后可以自动触发熔断并拉起，然后还是会进入一个死循环。
当然，基于上述的一些问题，我们可以指定测试哪些页面，但是会发现如果单个指定某几个activity，随机的意义又不是那么大了，我在一个二个页面进行随机，如果页面深度不是很深，那一直在这些页面测试也没有多大意义。由此开始思考，什么样的应用适合进行monkey测试。
以自己的应用来说，主要的页面功能其实不多，就是一个上课页面，其余一些小功能都隐藏在一些小地方，而实际测试过程中，基本都没有触发到小地方，覆盖的activity还是不够的，而上课页面其实以翻页为主，一些功能又隐藏在不同的分页当中，也很难随机到，因此发现并不太适合做monkey测试。那么什么样的应用适合做呢？
以直播软件为例，直播分类，各个直播间，页面结构比较规律，每个直播间内的结构也都是规律的，因此，即使是随机点击，也不会说在一个页面一直点，因为页面功能分布，按钮分布，触发点分布相对比较规律，不像我们的应用，页面大部分都是文本显示，功能点都分布在边上，并且有的还是需要点击某些地方才能出现的菜单栏。因此我觉得如果应用页面功能分布比较规律比较均匀适合做monkey测试，或者说monkey测试的意义也会更大，而如果自身应用页面结构功能过于简单，或者页面排版过于极端（像我们的功能，主要的页面70%就是文本显示，其他功能按钮什么的隐藏较深很难触发到，容易进去出不来）的，就可以考虑不在monkey测试上投入过多。
因此一些测试还是要根据被测试应用或者项目的特点来进行针对性的测试。