monkey測試主要做隨機的黑盒測試，通過不斷輸入偽隨機的事件流來測試應用的穩定性，但是由於monkey太過皮，太過隨機，最后根本無法控制，很容易陷於一個頁面無法出來，或者陷入某個無關緊要的地方無法出來，導致測試結果並不具有很好的意義。
基於上述原因，嘗試了一些二次開發monkey的測試工具，例如maxim，可以通過一些黑白名單控制，或者輸入指定事件流，或者指定不同的測試隨機模式，深度優先或者控件識別等，在使用了之后發現，還是會出現陷入到一個地方出不來的情況，雖然加入了熔斷機制，在一個地方執行了太多次數后可以自動觸發熔斷並拉起，然后還是會進入一個死循環。
當然，基於上述的一些問題，我們可以指定測試哪些頁面，但是會發現如果單個指定某幾個activity，隨機的意義又不是那么大了，我在一個二個頁面進行隨機，如果頁面深度不是很深，那一直在這些頁面測試也沒有多大意義。由此開始思考，什么樣的應用適合進行monkey測試。
以自己的應用來說，主要的頁面功能其實不多，就是一個上課頁面，其余一些小功能都隱藏在一些小地方，而實際測試過程中，基本都沒有觸發到小地方，覆蓋的activity還是不夠的，而上課頁面其實以翻頁為主，一些功能又隱藏在不同的分頁當中，也很難隨機到，因此發現並不太適合做monkey測試。那么什么樣的應用適合做呢？
以直播軟件為例，直播分類，各個直播間，頁面結構比較規律，每個直播間內的結構也都是規律的，因此，即使是隨機點擊，也不會說在一個頁面一直點，因為頁面功能分布，按鈕分布，觸發點分布相對比較規律，不像我們的應用，頁面大部分都是文本顯示，功能點都分布在邊上，並且有的還是需要點擊某些地方才能出現的菜單欄。因此我覺得如果應用頁面功能分布比較規律比較均勻適合做monkey測試，或者說monkey測試的意義也會更大，而如果自身應用頁面結構功能過於簡單，或者頁面排版過於極端（像我們的功能，主要的頁面70%就是文本顯示，其他功能按鈕什么的隱藏較深很難觸發到，容易進去出不來）的，就可以考慮不在monkey測試上投入過多。
因此一些測試還是要根據被測試應用或者項目的特點來進行針對性的測試。