如题
额,一般不怎么监控资源,意义不大。
monkey 测试目标是确认有没有崩溃点,所以应用有接入崩溃采集平台,能收集到崩溃信息就可以。
monkey 是用来测试崩溃的,之所以有人管这个叫压力测试,是因为 monkey 可以长时间运行,可以让 APP 承受平时使用不到的强度。
先看你业务上的痛点吧,再谈监控撒,一开始先别求全,先把一两个监控指标真正的在业务中发挥作用,其它的照着来就行。。。
客户端和服务端有些概念是有点差异的,可能你了解了 monkey 测试本质是啥后,应该不会有这么多问题。
常规的 monkey 测试本质上就是随机测试,通过发送随机事件流给应用,这些随机事件流基本可以认为是乱来的(像猴子一样乱点,所以叫 monkey 测试),会有一定的概率会命中某些藏得比较深的崩溃隐患。服务端相对比较接近的概念我理解应该是模糊测试(Fuzz),通过给出各种随机的输入数据,查看系统是否可正常响应,会不会出安全问题。
现在有些更智能点的,不是随机事件,而是识别界面元素后,能点的按钮尽量点,并记录下每个页面,尽可能把每个 app 能点的按钮点一遍,能进的页面进一遍。这种一般也称为智能 monkey 或者叫自动遍历,用处是低成本发现一些 app 可能存在的某些页面进不去/按钮点了会出问题的情况。
但这两类本质上和服务端高并发不一样,其实都不会给 app 带来 “压力”,而且 app 天然就是单人操作的,所以使用场景本身也没有太多类似服务端用户量增加带来的系统资源不足的压力。之所以会有人称为压力,是因为常规 monkey 的随机事件流发送速度可以比人工点击快很多,而这个高速度可以让某些可能引起内存泄漏的操作效果放大,快速发现内存泄漏类问题(内存占用量一旦达到系统最大限制,会直接被系统 Kill 掉,这也是崩溃的一种,所以通过监控崩溃也可以捕获到这类问题)。这点和服务端压力测试会比较接近。
当然,app 也有自己的专项性能测试,这类测试是要监控性能数据的(常见指标包括内存、cpu、网络流量、FPS 流畅度、耗电量等),但这类一般很少用 monkey 或者遍历来做,因为这两类测试都偏随机,无法满足常规性能测试里 “固定模拟场景” 这个需要。
我用了两个 jar 包,framework.jar monkey.jar 然后跑大概半个小时左右,有 crash 或者 oom 就会自己生成日志文件
Monkey 更多是用来测试 App 的稳定性,主要看的是 ANR 和 CRASH 这两个指标,资源类的较少,常看的资源类指标是 CPU、Mem、GPU、FPS、Jank 等有系统 API 可以调用获取
楼主,要是为了测试 app 性能,勉强可以使用 monkey 做协助,但是推荐使用自动遍历测试工具,如:AppCrawler,Fastbot-Android、Maxim 等。如果是测试 App 的稳定性,就用 monkey 看 ANR 和 CRASH 这两个指标。