移动 App 应用测试方法与思路

【转载】

移动 App 应用测试方法与思路

分析三种主流的移动 App 类型，并给出和普通web测试不一样的地方，给出测试的思路，并给出部分场景组合。 附：安卓 App 测试经常使用 adb命令和 money 命令

移动端测试仍是 PC 端测试，业务测试其实都属于 GUI 测试的范畴，因此基本的测试思路，好比基于页面对象封装和基于业务流程封装的思想是相通的。

三种移动端产品类型介绍

移动端应用的测试其自身特色，和其余传统测试又有一些独特的测试方法与思路。 移动端应用又能够进一步细分为三大类：

• Web App 指的是移动端的 Web 浏览器， 其实和 PC 端的 Web 浏览器没有任何区别，只不过Web 浏览器所依附的操做系统再也不是 Windows 和 Linux 了，而是 iOS 和 Android 了。 Web App 采用的技术主要是，传统的HTML、JavaScript、CSS等Web技术栈，固然 如今HTML5 也获得了普遍的应用。另外，WebApp所访问的页面内容都是放在服务器端的，本质上就是 Web 网页，因此天生就是跨平台的。

• Native App 指的是移动端的原生应用， 对于 Android 是 apk，对于 iOS 就是 ipa。NativeApp 是一种基于手机操做系统（iOS 和 Android），并使用原生程序编写运行的第三方应用程序。 Native App 的开发，Android 使用的语言一般是 Java，iOS 使用的语言是 Objective-C。一般来讲，Native App 能够提供比较好的用户体验以及性能，并且能够方便地操做手机本地资源。

• Hybrid App，是介于 Web App 和 Native App 二者之间的一种 App 形式。 Hybrid App 利用了 Web App 和 Native App 的优势，经过一个原生实现的 NativeContainer 展现HTML5的页面。更通俗的讲法能够归结为，在原生移动应用中嵌入了Webview，而后经过该 Webview 来访问网页。 Hybrid App 具备维护更新简单，用户体验优异以及较好的跨平台特性，是目前主流的移动应用开发模式。

三类不一样移动应用的测试方法

根据它们的特性来总结出它们的测试方法。

• Web App，显然其本质就是Web浏览器的测试，全部GUI自动化测试的方法和技术，好比数据驱动、页面对象模型、业务流程封装等，都适用于 Web App的测试。 若是Web 页面是基于自适应网页设计（即符合ResponsiveWeb设计的规范），并且测试框架若是支持 Responsive Page，那么原则上以前开发的运行在 PC Web 端的 GUI自动化测试用例，不作任何修改就能够直接在移动端的浏览器上直接执行，固然运行的前提是你的移动端浏览器必须支持WebDriver。其中，自适应网页设计（Responsive Web Design）是指，同一个网页可以自动识别屏幕分辨率、并作出相应调整的网页设计技术。

• Native App 的测试，虽然不一样的平台会使用不一样的自动化测试方案，iOS 通常采用XCUITest Driver，而 Android 通常采用 UiAutomator2 或者 Espresso 等，可是数据驱动、页面对象以及业务流程封装的思想依旧适用，彻底能够把这些方法应用到测试用例设计中。

• Hybrid App 的测试，状况会稍微复杂一点，对 Native Container 的测试，可能须要用到XCUITest 或者 UiAutomator2 这样的原生测试框架，而对 Container 中 HTML5 的测试，基本和传统的网页测试没什么区别，因此本来基于 GUI 的测试思想和方法都能继续适用。

惟一须要注意的是，Native Container 和 Webview 分别属于两个不一样的上下文（Context），Native Container 默认的 Context 为“NATIVE APP"，而 Webview 默认的Context 为“WEBVIEW_+ 被测进程名称”。 因此，当须要操做 Webview 中的网页元素时，须要先切换到 Webview 的 Context 下。

web测试和app测试的区别：

相同点：WEB测试和App测试从流程上来讲，没有区别。都须要经历测试计划方案，用例设计，测试执行，缺陷管理，测试报告等相关活动。从技术上来讲，WEB测试和APP测试其测试类型也基本类似，都须要进行功能测试、性能测试、安全性测试、GUI测试等测试类型。

不一样点他们的主要区别在于具体测试的细节和方法有区别，

性能测试，在WEB测试只须要测试响应时间这个要素，在App测试中还须要考虑流量测试和耗电量测试。

兼容性测试：在WEB端是兼容浏览器，在App端兼容的是手机设备。并且相对应的兼容性测试工具也不相同，WEB由于是测试兼容浏览器，因此须要使用不一样的浏览器进行兼容性测试（常见的是兼容IE6，IE8，chrome，firefox）若是是手机端，那么就须要兼容不一样品牌，不一样分辨率，不一样android版本甚至不一样操做系统的兼容。（常见的兼容方式是兼容市场占用率前N位的手机便可），有时候也可使用到兼容性测试工具，但WEB兼容性工具多用IETester等工具，而App兼容性测试会使用Testin这样的商业工具也能够作测试。

安装测试：WEB测试基本上没有客户端层面的安装测试，可是App测试是存在客户端层面的安装测试，那么就具有相关的测试点。

App测试基于手机设备，还有一些手机设备的专项测试。如交叉事件测试，操做类型测试，网络测试（弱网测试，网络切换）交叉事件测试：就是在操做某个软件的时候，来电话、来短信，电量不足提示等外部事件。操做类型测试：如横屏测试，手势测试网络测试：包含弱网和网络切换测试。须要测试弱网所形成的用户体验，重点要考虑回退和刷新是否会形成二次提交。弱网络的模拟，听说能够用360wifi实现设置。升级测试：升级测试的提醒机制，升级取消是否会影响原有功能的使用，升级后用户数据是否被清除了。

从系统架构的层面，WEB测试只要更新了服务器端，客户端就会同步会更新。并且客户端是能够保证每个用户的客户端彻底一致的。可是APP端是不可以保证彻底一致的，除非用户更新客户端。若是是APP下修改了服务器端，意味着客户端用户所使用的核心版本都须要进行回归测试一遍。

如此看来，移动端的测试除了使用的测试框架不一样之外，测试设计自己和 GUI 测试有殊途同归之妙，对于移动端还应该有其余的不一样测试思路和方法。

移动应用专项测试的思路和方法

对于移动应用，顺利完成所有业务功能测试每每是不够的，当移动应用被大量用户安装和使用时，就会暴露出不少以前彻底没有预料到的问题， 好比：

1. 流量使用过多；
2. 耗电量过大；
3. 在某些设备终端上出现崩溃或者闪退的现象；
4. 多个移动应用相互切换后，行为异常；
5. 在某些设备终端上没法顺利安装或卸载；
6. 弱网络环境下，没法正常使用；
7. Android 环境下，常常出现 ANR(Application Not Responding)；

… 这样的问题还有不少，为了不或减小此类状况的发生，因此移动应用除了进行常规的功能测试外，一般还会进行不少移动应用所特有的专项测试。

1. 交叉事件测试

交叉事件测试也叫中断测试，是指 App 执行过程当中，有其余事件或者应用中断当前应用执行的测试。 好比，App 在前台运行过程当中，忽然有电话打进来，或者收到短信，再或者是系统闹钟等等状况。因此，在 App 测试时，就须要把这些常见的中断状况考虑在内，并进行相关的测试。 此类测试目前基本还都是采用手工测试的方式，而且都是在真机上进行，不会使用模拟器。

首先，采用手工测试的缘由是，此类测试每每场景多，并且不少事件很难经过自动化的方式来模拟，好比呼入电话、接收短信等，这些因素都会形成自动化测试的成本太高，得不偿失，因此工程实践中，交叉事件测试每每全是基于手工的测试。

其次，之因此采用真机，是由于不少问题只会在真机上才能重现，采用模拟器测试没有意义。

交叉事件测试，须要覆盖的场景主要包括：

1. 多个 App 同时在后台运行，并交替切换至前台是否影响正常功能；
2. 要求相同系统资源的多个 App 先后台交替切换是否影响正常功能，好比两个 App 都须要播放音乐，那么二者在交替切换的过程当中，播放音乐功能是否正常；
3. App 运行时接听电话；
4. App 运行时接收信息；
5. App 运行时提示系统升级；
6. App 运行时发生系统闹钟事件；
7. App 运行时进入低电量模式；
8. App 运行时第三方安全软件弹出告警；
9. App 运行时发生网络切换，好比，由 Wifi 切换到移动 4G 网络，或者从 4G 网络切换到 3G 网络等；

… 其实你能够发现，这些须要覆盖的场景，也是咱们从此测试的测试用例集，每一场景都是一个测试用例的集合。

第二，兼容性测试

兼容性测试顾名思义就是，要确保App在各类终端设备、各类操做系统本、各类屏幕分辨率、各类网络环境下，功能的正确性。常见的App兼容性测试每每须要覆盖如下的测试场景：

1. 不一样操做系统的兼容性，包括主流的 Andoird 和 iOS 版本；
2. 主流的设备分辨率下的兼容性；
3. 主流移动终端机型的兼容性；
4. 同一操做系统中，不一样语言设置时的兼容性；
5. 不一样网络链接下的兼容性，好比 Wifi、GPRS、EDGE、CDMA200 等；
6. 在单一设备上，与主流热门 App 的兼容性，好比微信、抖音、淘宝等；

…

兼容性测试一般都须要在各类真机上执行相同或者相似的测试用例，因此每每采用自动化测试的手段。 同时，因为须要覆盖大量的真实设备，除了大公司会基于 Appium + Selenium Grid+OpenST去搭建本身的移动设备私有云平台外，其余公司通常都会使用第三方的移动设备云测平台完成兼容性测试。第三方的移动设备云测平台，国外最知名的是 SauceLab，国内主流的是Testin。

第三，流量测试

因为 App 常常须要在移动互联网环境下运行，而移动互联网一般按照实际使用流量计费，因此若是你的App耗费的流量过多，第一会致使用户流量费用增长，第二会会致使功能加载缓慢。

流量测试，一般包含如下几个方面的内容：

1. App 执行业务操做引发的流量；
2. App 在后台运行时的消耗流量；
3. App 安装完成后首次启动耗费的流量；
4. App 安装包自己的大小；
5. App 内购买或者升级须要的流量;

…

流量测试，每每借助于 Android 和 iOS 自带的工具进行流量统计，也能够利用 tcpdump、Wireshark 和 Fiddler 等网络分析工具。

对于 Android 系统，网络流量信息一般存储在/proc/net/dev目录下，也能够直接利用 ADB工具获取实时的流量信息。Android的轻量级性能监控小工具Emmagee，相似于 Windows 系统性能监视器，可以实时显示App运行过程当中CPU、内存和流量等信息。

对于 iOS 系统，可使用 Xcode 自带的性能分析工具集中的 Network Activity，分析具体的流量使用状况。

可是，流量测试的最终目的，并非获得 App 的流量数据，而是要想办法减小 App 产生的流量。减小App消耗的流量不是测试工程师的工做，但了解一些经常使用的 方法，也将有助于你的测试平常工做：

1. 启用数据压缩，尤为是图片；
2. 使用优化的数据格式，好比一样信息量的 JSON 文件就要比 XML 文件小；
3. 遇到既须要加密又须要压缩的场景，必定是先压缩再加密；
4. 减小单次 GUI 操做触发的后台调用数量；
5. 每次回传数据尽量只包括必要的数据；
6. 启用客户端的缓存机制；

…

第四，耗电量测试

耗电量也是一个移动应用可否成功的关键因素之一。在目前的生态环境下，能提供相似服务或者功能的 App每每有不少，若是在功能相似的状况下，App特别耗电、让设备发热比较严重，那么你的用户必定会卸载你的 App 而改用其余 App。最典型的就是地图等导航类的应用，对耗电量特别敏感。

耗电量测试一般从三个方面来考量：

• App 运行但没有执行业务操做时的耗电量；
• App 运行且密集执行业务操做时的耗电量；
• App 后台运行的耗电量;

耗电量检测既有基于硬件的方法，也有基于软件的方法。我所经历过的项目都是采用软件的方法，Android 和 iOS 都有各自本身的方法：Android 经过 adb 命令“adb shell dumpsys battery”来获取应用的耗电量信息耗电测试中，Google推出的history batterian工具很好分析耗电状况；

iOS 经过 Apple 的官方工具 Sysdiagnose 来收集耗电量信息，而后，能够进一步经过Instrument 工具链中的 Energy Diagnostics 进行耗电量分析。

第五，弱网络测试

与传统桌面应用不一样，移动应用的网络环境比较多样，并且常常出现须要在不一样网络之间切换的场景，即便是在同一网络环境下，也会出现网络链接状态时好时坏的状况，好比时高时低的延迟、常常丢包、频繁断线，在乘坐地铁、穿越隧道，和地下车库的场景下常常会发生。

因此，移动应用的测试须要保证在复杂网络环境下的质量。在测试阶段，模拟这些网络环境，在 App 发布前尽量多地发现并修复问题。推荐开源移动网络测试工具：Facebook Augmented TrafficControl（ATC）。

ATC 最好用的地方在于，它可以在移动终端设备上经过Web界面随时切换不一样的网络环境，同时多个移动终端设备能够链接到同一个Wifi，各自模拟不一样的网络环境，相互之间不会有任何影响。也就是说，只要搭建一套ATC就能知足你全部的网络模拟需求。

第六，边界测试

边界测试是指，移动 App在一些临界状态下的行为功能的验证测试，基本思路是须要找出各类潜在的临界场景，并对每一类临界场景作验证和测试。

主要的场景有：

1. 系统内存占用大于 90% 的场景；
2. 系统存储占用大于 95% 的场景；
3. 飞行模式来回切换的场景；
4. App不具备某些系统访问权限的场景，好比App因为隐私设置不能访问相册或者通信录等；
5. 长时间使用 App，系统资源是否有异常，好比内存泄漏、过多的连接数等；
6. 出现 ANR 的场景；
7. 操做系统时间早于或者晚于标准时间的场景；
8. 时区切换的场景；

…

耗电量测试，流量测试，以及app性能测试，如何界定数据是否正常？例如流量消耗是到哪一个值以为有优化空间，内存CPU到哪一个值不正常须要优化

其实并无明确的标准，主要基于一些历史统计数据，主要的作法是和现有版本，以及同类app作比较。

结合一些实际状况测试点简单组合下场景场景：

好比： 出现崩溃：

1. 设备碎片化：因为设备极具多样性，App在不一样的设备上可能有表现不一样;
2. 带宽限制：带宽不佳的网络对App所需的快速响应时间可能不够;
3. 网络的变化：不一样网络间的切换可能会影响App的稳定性;
4. 内存管理：可用内存太低，或非受权的内存位置的使用可能会致使App失败;
5. 用户过多：链接数量过多可能会致使App崩溃;
6. 代码错误：没有通过测试的新功能，可能会致使App在生产环境中失败;
7. 第三方服务：广告或弹出屏幕可能会致使App崩溃;

App的安装与卸载

就是其余web里边没有的场景，最基本的药考虑不一样操做系统，考虑不一样的操做系统版本，考虑不一样手机厂商再操做系统版本修改上的不一样，等等

安装过程当中：

1. 各个选项是否符合概要设计说明;
2. 安装向导的ui测试;
3. 是否支持取消，以及取消后的操做流程（是否有残留);
4. 意外状况处理（司机、重启、断电、断网）;
5. 安装空间不足

安装完成后：

1. 是否正常运行;
2. 安装过程后的文件夹和文件是否写在了指定的目录里边;
3. 是否生成了多余的目录结构和文件;

升级：

1. 升级后功能是否和需求说明同样
2. 测试与升级模块相关的模块的功能是否
3. 升级界面的ui测试（强制/非强制）
4. 升级安装意外状况的测试（死机、重启、断电）
5. 版本验证：1.0版-2.0或者1.0-3.0
6. 升级中用户数据、设置、状态的保留，注意新版本已去掉的状态或设置；
7. 是否能够隔开版本覆盖安装；
8. 是否能够覆盖安装更低版本；
9. 若是升级有忽略本次版本升级，那么当有新的升级版本时，是否还有提示升级；
10. 大版本更新不升级没法使用；

卸载：

1. 系统直接卸载以及卸载时候ui界面测试;
2. 直接删除文件夹，再卸载;
3. 卸载过程当中是否支持取消，取消后的软件状态;
4. 卸载时候意外的状况处理（死机、断网、断电、重启);
5. 卸载安装，安装目录清理，SD卡存储数据不被清理；
6. 在没有更新或者网络时，须要给予用户正确的信息表达；

App的启动与中止

1. 首次启动是否出现欢迎界面，能否进入App，停留时间是否合理;
2. 首次启动后拉取的信息是否正确;
3. 再次启动时间是否符合预期；
4. 再次启动app功能是否异常
5. 再次启动后状态检查：如初始化信息、初始状态、启动对网络；
6. 再次启动进程服务检查：进程名、进程数、服务名、服务数、第三方调用的SDK如GPS；
7. 再次带登录的应用是否再次启动的时候正常登陆；
8. 出现崩溃是否能够再次启动;
9. 手动终止进程、服务是否能够在此启动;
10. 其余系统软件工具中止进程、清理软件数据，是否能够启动；

中断测试

1. 锁屏中断：停留在程序操做界面进行锁屏，恢复后检查操做是否正常；
2. 先后台切换：停留在程序操做界面，经过Home键，进行程序的先后台切换；
3. 加载中断：页面接口请求、界面框架加载时，经过Home键、返回键、快速切换操做进行中断；
4. 系统异常中断：如关机、断电、来电；

流畅度 列表滑动、返回进入、快速点击（这个肉眼很差评判，能够借助GT，通常打分在90分以上是比较好的）

软件兼容 通用软件； 输入法； 安全软件； 通讯类； 竞品软件 同类软件，是否出现冲突；

总结

移动应用根据技术架构的不一样，主要分为 Web App、Native App 和 Hybrid App 三大类，这三类应用的测试方法本质上都属于 GUI 测试的范畴。

从业务功能测试的角度看，移动应用的测试用例设计和传统 PC 端的 GUI 自动化测试策略比较相似，只是测试框架不一样，数据驱动、页面对象模型和业务流程封装依旧适用；

各类专项测试是移动应用的测试重点，也有别于传统 GUI 测试。专项测试包括：交叉事件测试、兼容性测试、流量测试、耗电量测试、弱网络测试和边界测试;

---

附：ADB经常使用命令

adb connect+ip 远程链接Android设备

adb devices 获取设备列表和设备状态

adb install apk路径 安装应用 -r 覆盖安装

adb uninstall apk包名 卸载应用 -k 卸载时保存数据和缓存目录

adb pull 远程路径 本地路径 将Android设备上的文件或者文件夹复制到本地

adb push 本地路径 远程路径 将本地的文件或者文件夹复制到Android设备上

adb start-server 启动adb服务进程

adb kill-server 关闭adb 服务进程

adb reboot 重启设备

adb shell 进入模拟器的shell模式

adb logcat 查看log信息

adb logcat > d:\log.txt 将log导出到d盘

adb shell logcat -b radio 查看无线通讯日志

adb shell logcat -b radio > d:\log.txt

adb version 查看adb命令版本号

adb help 查看adb帮助命令

adb shell pm list packages 查看设备中全部应用的包名

adb shell pm list packages -s 列出系统应用的全部包名

adb shell pm list packages -3 列出除了系统应用的第三方应用包名

adb shell 查看指定应用的包名

pm list packages|grep qq

adb shell pm clear 包名 清除指定应用的缓存

adb shell dumpsys meminfo 查看手机内存使用状况

adb shell dumpsys cpuinfo 查看cpu信息

adb shell dumpsys battery 查看电量信息

附：Monkey简单实用方法

Monkey 就是SDK中附带的一个工具。Monkey是Android中的一个命令行工具，能够运行在模拟器里或实际设备中。它向系统发送伪随机的用户事件流(如按键输入、触摸屏输入、手势输入等)，实现对正在开发的应用程序进行压力测试。Monkey测试是一种为了测试软件的稳定性、健壮性的快速有效的方法。

该工具用于进行压力测试。而后开发人员结合monkey打印的日志和系统打印的日志，分析测试中的问题

优势：

Monkey 测试,全部的事件都是随机产生的，不带任何人的主观性。

缺点：

1. 测试的对象仅为应用程序包，有必定的局限性。
2. Monky测试使用的事件数据流是随机的，不能进行自定义。
3. 可对MonkeyTest的对象，事件数量，类型，频率等进行设置。

Monkey基本语法以下：

$ adb shell monkey [options]

若是不指定options，Monkey将以无反馈模式启动，并把事件任意发送到安装在目标环境中的所有包。下面是一个更为典型的命令行示例，

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

它启动指定的应用程序，并向其发送500个伪随机事件： 使用android自动化测试工具monkeyrunner启动应用时，须要填写被测程序的包名和启动的Activity。

使用monkey help 命令查看命令参数 C:\Users\chenfenping>adb shell monkey -help

1 参数： -p 用于约束限制，用此参数指定一个或多个包（Package，即App）。指定包以后，monkey将只容许系统启动指定的APP,若是不指定包，将容许系统启动设备中的全部APP.

指定一个包： adb shell monkey -p cn.emoney.acg 10

指定多个包：adb shell monkey -p cn.emoney.acg –p cn.emoney.wea -p cn.emoney.acg 100

不指定包：adb shell monkey 100

2 参数: -v 用于指定反馈信息级别（信息级别就是日志的详细程度），总共分3个级别，分别对应的参数以下表所示：

日志级别 Level0

示例 adb shell monkey -p cn.emoney.acg –v 100 说明缺省值，仅提供启动提示、测试完成和最终结果等少许信息

日志级别 Level 1

示例 adb shell monkey -p cn.emoney.acg –v -v 100 说明提供较为详细的日志，包括每一个发送到Activity的事件信息

日志级别 Level 2

示例 adb shell monkey -p cn.emoney.acg –v -v –v 100 说明最详细的日志，包括了测试中选中/未选中的Activity信息

3 参数： -s

用于指定伪随机数生成器的seed值，若是seed相同，则两次Monkey测试所产生的事件序列也相同的。 Monkey 测试1：adb shell monkey -p cn.emoney.acg -s 10 100 Monkey 测试2：adb shell monkey -p cn.emoney.acg –s 10 100 两次测试的效果是相同的，由于模拟的用户操做序列（每次操做按照必定的前后顺序所组成的一系列操做，即一个序列）是同样的。

4 参数： --throttle<毫秒> 用于指定用户操做（即事件）间的时延，单位是毫秒； adb shell monkey -p cn.emoney.acg --throttle 5000 100

在monkey测试中经常使用的命令组合有：

一、monkey -p com.yourpackage -v 500

简单的输出测试的信息。

二、monkey -p com.yourpackage -v -v 500

以深度为二级输出测试信息。

三、monkey -p com.yourpackage -s 数字 -v 500

为随机数的事件序列定一个值，若出现问题下次能够重复一样的系列进行排错。

四、monkey -p com.yourpackage -v --throttle 3000 500

为每一次执行一次有效的事件后休眠3000毫秒。

Monkey测试的一个实例

经过这个实例，咱们能理解Monkey测试的步骤以及如何知道哪些应用程序可以用Monkey进行测试。

Windows下（注：2—4步是为了查看咱们能够测试哪些应用程序包，可省略）：

一、经过eclipse启动一个Android的emulator

二、在命令行中输入：adb devices查看设备链接状况

C:\Documents and Settings\Administrator>adb devices

List of devices attached

emulator-5554 device

三、在有设备链接的前提下，在命令行中输入：adb shell 进入shell界面

C:\Documents and Settings\Administrator>adb shell

四、查看data/data文件夹下的应用程序包。注：咱们能测试的应用程序包都在这个目录下面

C:\Documents and Settings\Administrator>adb shell

# ls data/data

ls data/data

五、以com.android.calculator2做为对象进行MonkeyTest #monkey -p com.android.calculator2 -v 500

运行过程当中，Emulator中的应用程序在不断地切换画面。

按照选定的不一样级别的反馈信息，在Monkey中还能够看到其执行过程报告和生成的事件。

测试过程当中，在输出monkeylog的一个小错误

跑monkey的时候或者想抓程序log导出时，有时会提示：cannot create D:monkeytest.txt: read-only file system 为何有时候能够有时候不能够？ 后来发现跟使用使用习惯不同，一会是先进入adb shell 再用命令，一会是直接命令进入。 进入adb shell后再用命令就会失败~ 正确方法：退出shell或者执行命令时先不要进shell C:\Documents and Settings\Administrator>adb shell monkey -p 包名 -v 300 >e:\text.txt 进入adb shell后就至关于进入linux的root下面，没有权限在里面建立文件~

关于Monkey测试结果分析基本步骤

一. Monkey测试出现错误后，通常的查错步骤为如下几步：

1. 找到是monkey里面的哪一个地方出错

2. 查看Monkey里面出错前的一些事件动做，并手动执行该动做

3. 若以上步骤还不能找出，可使用以前执行的monkey命令再执行一遍，注意seed值要同样--复现

二.通常的测试结果分析：

1. ANR问题：在日志中搜索“ANR”

2. 崩溃问题：在日志中搜索“Exception” Force Close

三. 详细分析monkey日志：

将执行Monkey生成的log，从手机中导出并打开查看该log；在log的最开始都会显示Monkey执行的seed值、执行次数和测试的包名。

首先咱们须要查看Monkey测试中是否出现了ANR或者异常，接下来要看文档。找出错误点，而后打包给开发。

 

做者：友台连接：https://juejin.im/post/5cb2d09ee51d456e2d69a75d来源：掘金著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。