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

2023年6月21日发(作者：)

移动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.06. 升级中⽤户数据、设置、状态的保留，注意新版本已去掉的状态或设置；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导出到d盘adb shell logcat -b radio 查看⽆线通信⽇志adb shell logcat -b radio > d: 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 qqadb 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 -v 500它启动指定的应⽤程序，并向其发送500个伪随机事件： 使⽤android⾃动化测试⼯具monkeyrunner启动应⽤时，需要填写被测程序的包名和启动的Activity。使⽤monkey help 命令查看命令参数 C:Userschenfenping>adb shell monkey -help1 参数： -p ⽤于约束限制，⽤此参数指定⼀个或多个包（Package，即App）。指定包之后，monkey将只允许系统启动指定的APP,如果不指定包，将允许系统启动设备中的所有APP.指定⼀个包： adb shell monkey -p 10指定多个包：adb shell monkey -p –p -p 100不指定包：adb shell monkey 1002 参数: -v ⽤于指定反馈信息级别（信息级别就是⽇志的详细程度），总共分3个级别，分别对应的参数如下表所⽰：⽇志级别 Level0⽰例 adb shell monkey -p –v 100 说明缺省值，仅提供启动提⽰、测试完成和最终结果等少量信息⽇志级别 Level 1⽰例 adb shell monkey -p –v -v 100 说明提供较为详细的⽇志，包括每个发送到Activity的事件信息⽇志级别 Level 2⽰例 adb shell monkey -p –v -v –v 100 说明最详细的⽇志，包括了测试中选中/未选中的Activity信息3 参数： -s⽤于指定伪随机数⽣成器的seed值，如果seed相同，则两次Monkey测试所产⽣的事件序列也相同的。 Monkey 测试1：adb shellmonkey -p -s 10 100 Monkey 测试2：adb shell monkey -p –s 10 100 两次测试的效果是相同的，因为模拟的⽤户操作序列（每次操作按照⼀定的先后顺序所组成的⼀系列操作，即⼀个序列）是⼀样的。4 参数： --throttle<毫秒> ⽤于指定⽤户操作（即事件）间的时延，单位是毫秒； adb shell monkey -p --throttle5000 100在monkey测试中常⽤的命令组合有：1、monkey -p ckage -v 500简单的输出测试的信息。2、monkey -p ckage -v -v 500以深度为⼆级输出测试信息。3、monkey -p ckage -s 数字 -v 500为随机数的事件序列定⼀个值，若出现问题下次可以重复同样的系列进⾏排错。4、monkey -p ckage -v --throttle 3000 500为每⼀次执⾏⼀次有效的事件后休眠3000毫秒。Monkey测试的⼀个实例通过这个实例，我们能理解Monkey测试的步骤以及如何知道哪些应⽤程序能够⽤Monkey进⾏测试。Windows下（注：2—4步是为了查看我们可以测试哪些应⽤程序包，可省略）：1、通过eclipse启动⼀个Android的emulator2、在命令⾏中输⼊：adb devices查看设备连接情况C:Documents and SettingsAdministrator>adb devicesList of devices attachedemulator-5554 device3、在有设备连接的前提下，在命令⾏中输⼊：adb shell 进⼊shell界⾯C:Documents and SettingsAdministrator>adb shell4、查看data/data⽂件夹下的应⽤程序包。注：我们能测试的应⽤程序包都在这个⽬录下⾯C:Documents and SettingsAdministrator>adb shell# ls data/datals data/data5、以ator2作为对象进⾏MonkeyTest #monkey -p ator2 -v 500运⾏过程中，Emulator中的应⽤程序在不断地切换画⾯。按照选定的不同级别的反馈信息，在Monkey中还可以看到其执⾏过程报告和⽣成的事件。测试过程中，在输出monkeylog的⼀个⼩错误跑monkey的时候或者想抓程序log导出时，有时会提⽰：cannot create D:: read-only file system 为什么有时候可以有时候不可以？ 后来发现跟使⽤使⽤习惯不⼀样，⼀会是先进⼊adb shell 再⽤命令，⼀会是直接命令进⼊。 进⼊adb shell后再⽤命令就会失败~ 正确⽅法：退出shell或者执⾏命令时先不要进shell C:Documents and SettingsAdministrator>adb shell monkey -p 包名 -v300 >e: 进⼊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或者异常，接下来要看⽂档。找出错误点，然后打包给开发。

2023年6月21日发(作者：)

移动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.06. 升级中⽤户数据、设置、状态的保留，注意新版本已去掉的状态或设置；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导出到d盘adb shell logcat -b radio 查看⽆线通信⽇志adb shell logcat -b radio > d: 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 qqadb 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 -v 500它启动指定的应⽤程序，并向其发送500个伪随机事件： 使⽤android⾃动化测试⼯具monkeyrunner启动应⽤时，需要填写被测程序的包名和启动的Activity。使⽤monkey help 命令查看命令参数 C:Userschenfenping>adb shell monkey -help1 参数： -p ⽤于约束限制，⽤此参数指定⼀个或多个包（Package，即App）。指定包之后，monkey将只允许系统启动指定的APP,如果不指定包，将允许系统启动设备中的所有APP.指定⼀个包： adb shell monkey -p 10指定多个包：adb shell monkey -p –p -p 100不指定包：adb shell monkey 1002 参数: -v ⽤于指定反馈信息级别（信息级别就是⽇志的详细程度），总共分3个级别，分别对应的参数如下表所⽰：⽇志级别 Level0⽰例 adb shell monkey -p –v 100 说明缺省值，仅提供启动提⽰、测试完成和最终结果等少量信息⽇志级别 Level 1⽰例 adb shell monkey -p –v -v 100 说明提供较为详细的⽇志，包括每个发送到Activity的事件信息⽇志级别 Level 2⽰例 adb shell monkey -p –v -v –v 100 说明最详细的⽇志，包括了测试中选中/未选中的Activity信息3 参数： -s⽤于指定伪随机数⽣成器的seed值，如果seed相同，则两次Monkey测试所产⽣的事件序列也相同的。 Monkey 测试1：adb shellmonkey -p -s 10 100 Monkey 测试2：adb shell monkey -p –s 10 100 两次测试的效果是相同的，因为模拟的⽤户操作序列（每次操作按照⼀定的先后顺序所组成的⼀系列操作，即⼀个序列）是⼀样的。4 参数： --throttle<毫秒> ⽤于指定⽤户操作（即事件）间的时延，单位是毫秒； adb shell monkey -p --throttle5000 100在monkey测试中常⽤的命令组合有：1、monkey -p ckage -v 500简单的输出测试的信息。2、monkey -p ckage -v -v 500以深度为⼆级输出测试信息。3、monkey -p ckage -s 数字 -v 500为随机数的事件序列定⼀个值，若出现问题下次可以重复同样的系列进⾏排错。4、monkey -p ckage -v --throttle 3000 500为每⼀次执⾏⼀次有效的事件后休眠3000毫秒。Monkey测试的⼀个实例通过这个实例，我们能理解Monkey测试的步骤以及如何知道哪些应⽤程序能够⽤Monkey进⾏测试。Windows下（注：2—4步是为了查看我们可以测试哪些应⽤程序包，可省略）：1、通过eclipse启动⼀个Android的emulator2、在命令⾏中输⼊：adb devices查看设备连接情况C:Documents and SettingsAdministrator>adb devicesList of devices attachedemulator-5554 device3、在有设备连接的前提下，在命令⾏中输⼊：adb shell 进⼊shell界⾯C:Documents and SettingsAdministrator>adb shell4、查看data/data⽂件夹下的应⽤程序包。注：我们能测试的应⽤程序包都在这个⽬录下⾯C:Documents and SettingsAdministrator>adb shell# ls data/datals data/data5、以ator2作为对象进⾏MonkeyTest #monkey -p ator2 -v 500运⾏过程中，Emulator中的应⽤程序在不断地切换画⾯。按照选定的不同级别的反馈信息，在Monkey中还可以看到其执⾏过程报告和⽣成的事件。测试过程中，在输出monkeylog的⼀个⼩错误跑monkey的时候或者想抓程序log导出时，有时会提⽰：cannot create D:: read-only file system 为什么有时候可以有时候不可以？ 后来发现跟使⽤使⽤习惯不⼀样，⼀会是先进⼊adb shell 再⽤命令，⼀会是直接命令进⼊。 进⼊adb shell后再⽤命令就会失败~ 正确⽅法：退出shell或者执⾏命令时先不要进shell C:Documents and SettingsAdministrator>adb shell monkey -p 包名 -v300 >e: 进⼊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或者异常，接下来要看⽂档。找出错误点，然后打包给开发。