目前使用 monkey 在工作中发现的问题较少，大家是怎么使用的呢？

我们发版流程会固定跑 monkey，而且是好几种类型的 Monkey（自动遍历型、随机时间型都会跑）。

上线后出现的崩溃闪退问题，Monkey 也并未出现，但是查明原因后，特定场景可以通过手工方式触发，有什么办法能让 monkey 跑出类似异常呢

这个没办法。monkey 本身主打的就是随机型动作，特定场景特定操作步骤的事情，不是 monkey 测试范畴要做的。通过跑 monkey，可以快速发现应用是否存在高崩溃率问题，但没法保障所有崩溃或者异常都能跑出来。

要有效控制实际用户手上使用的崩溃率，一般需要通过崩溃监控平台 + 合适的灰度策略，逐步放量并通过监控平台查看整体崩溃率，如果过高就从 top 1 崩溃开始修复，直到崩溃率达到公司或行业标准。

请教一下大佬~Monkey 的操作间隔，以及执行量一般是个什么策略呢？还有这两个，自动遍历型、随机时间型，大致是个什么意思呢？

Monkey 的操作间隔，以及执行量一般是个什么策略呢？

操作间隔我们没有特别设定，反正上一个事件跑完下一个立马接上。至于执行量，这个由业务根据情况设定，一般至少跑 2 个小时。

还有这两个，自动遍历型、随机时间型，大致是个什么意思呢？

自动遍历型，指的是这个程序会识别界面内容，把可以打开的界面、可以点击的按钮全部点击一遍，把程序整体进行遍历。最典型是字节开源的 fastbot 。

随机事件型，指的是不会理会当前程序界面情况，只是无脑把一些事先设定好的随机事件（如点击、长按、滑动等），按一定的比重直接应用到 app 中。最典型的是 android 自带的 monkey 工具。

从时间线以及技术难度上说，最先出现的是随机事件型，然后实际使用会发现对于比较复杂、界面比较多的应用，一些操作路径比较多才能进入的界面经常进不去，而且很容易一直停在某个页面出不去，所以才会诞生自动遍历型，解决覆盖度低的问题。在很多云测平台上，也会把它叫做智能 monkey。

这是 UI 自动化的范畴，想靠 monkey 万能不可能
而且 线上问题多是用户复杂的场景触发 UI 自动化也仅仅是覆盖一部分

受教

以这种特殊场景来说，自动化用例在一开始编写的时候是没有这种流程的，有必要在发现该类问题后将类似流程规划的自动化用例中么

这也是一个困境，如果站在领导的角度看，肯定越详细越好，但是这样自动化维护的成本太高了。
看公司，如果专职做自动化，有时间估计少不了完善这种用例。
如果是主业是业务测试，自动化时间很少，或者根本忙不来，就很难加这种复杂场景的用例

感谢大佬的指点~