《移动App测试的22条军规》

iOS对于 APP的运行机制做出了限制，绝大多数情况下APP进入后台后会马上进入suspend或terminate状态，不能执行代码。URL Schema就是IOS内的APP调用协议。使用iphone configuration utility可以来查看log中有关url schema的字段来测试APP之间的调用。

7．4 Android和iOS就是否支持扩展存储有所不同

SD卡。若使用到SD卡时，在测试过程中拔出SD卡，观察APP对于这种异常情况的处理。

7．5 iOS和Android对Widget的实现和使用不同

都支持小工具Widget，但实现和使用方式都不同。

IOS 8中，Widget只是作为APP的补充和扩展而存在的，所以Widget只能和APP一起打包发布，而不能只打包和发布Widget自己，除此之外，Widget只能显示在通知中心内。

Android中，Widget不仅可以作为APP的补充和扩展而存在，还可以独立于APP向用户提供功能，它不仅可以显示在通知中心内，还可以添加到桌面上。需要覆盖更多的功能入口点。

在具有Widget的APP测试中，需要测试：Widget中进行的操作是否及时同步到APP中；APP中数据及状态变化是否及时反映在Widget里。

Widget的生命周期和APP的生命周期是相互独立的。Widget应该保持功能的单一专注。如果Widget过度依赖于APP的运行数据和状态，这时就可能发生Widget无响应的情况。所以在测试过程中也需要考虑到以下情况：

1、在IOS8中对于可以使用的内存，Widget是远远低于APP的。所以当内存不足时，IOS更倾向于优先关闭Widget，因此我们可以考虑在高内存占用的时候来测试Widget的功能。

2、不同APP的Widget在通知中心共存时，是否有兼容性问题。

7．6 测试Android App对于Dalvik和ART运行环境（RunTime）的兼容性

Android 4.4之前，android app的运行环境是dalvik,不过由于dalvik满足不了android对性能提高的要求，所以google在android 4.4上同时支持了dalvik和art运行环境，并且在android 5.0中把默认的运行环境切换到了ART。

使用Dalvik运行环境，APP在每次运行时其中一部分代码需要机器重新编译，既消耗时间又消耗系统资源，执行效率难免会降低。优点是呆以让各种各样的APP运行在多种硬件架构上。

ART运行环境在APP安装时就把代码转换成机器语言，让APP成为真正的本地APP，启动时间极大提高，运行速度更快，电量消耗更少，系统运行也因此更加流畅。不过安装时间会增加一些。占用存储空间也会增加，通过不超过APP APK文件大小的20%。

7．7 测试iOS App在特定设置下的行为

在IOS设置页面的不同设置下，观察APP的功能、显示和性能。

军规8 及时显示和同步消息

不能只是简单地验证消息在各种情况下是否能正常的显示，还需要考虑到APP中各种缓存对于消息显示的影响。

一般情况在以下的环境中，才会在APP中使用缓存机制：

1，需要提供网络服务；

2，至少一部分数据不需要实时更新；

3，针对某种数据设定固定的过期时间，而不会导致其功能和用户体验出现问题。

APP使用缓存机制有哪些好处呢？

1，减少流量消耗；

2，响应更快；

3，从网络加载数据而出错的情况大大减少，提高了稳定性；

4，一定程度上支持了离线浏览；

5，减轻请求对服务器访问的压力。

设计APP的过程中一般会采取“内存——文件——网络”的结构来设计APP的缓存机制。针对这个特点来设计测试场景。

1、采用内存来缓存数据的方式。一般不用特定去测试；但对于浏览器的APP，则要通过同时打开多个页面，访问同样的网址，来测试是否APP对数据在内存中进行了缓存。

2、采用文件来缓存数据的方式。IOS不支持用户手动清除APP的文件缓存；android则可以通过清除缓存来测试APP是否对于数据文件进行了正确缓存。

3、采用网络来缓存数据的方式，也就是在CDN中缓存数据的情形，测试人员需要等待CDN达到过期时间之后，测试加载数据的时间，并和之前测试的在CDN数据没有过期时的加载时间进行比较，以此验证是否在网络中被正确地缓存了。

4、以上是APP缓存自动过期的场景，还有手动更新数据时，对应的缓存是否得到了更新。

5、对于用户信息这些不常变化的数据，或定期变化的数据，需要在服务器端有推送更新的功能。

注意缓存所占用存储空间的大小。不可能让APP无限制地存储数据。

如果支持多个客户端同进登录同一个帐号，需要测试多个客户端同时登录时，消息是否能被同步到所有设备。

1、需要在android和ios两种操作系统上安装APP，测试消息的同步显示。

2、同一种操作平台上也需要在多个设备上安装APP。

3、操作系统的不同版本间进行测试。

4、观察是否会接收到别的APP上被同步的消息。

军规9 适应特定用户界面对功能和显示的影响

同一款APP在不同设备厂商所提供的用户界面上显示效果会各不相同。

9．1 三星的TouchWiz用户界面

最大的影响就在于其默认字体和Android系统默认字体不一致；

更多的手势操作；

9．2 HTC的Sense用户界面

APP一旦切换到后台，就会终止APP运行，并对APP最后的状态进行截图，再点击APP时，需要重新载入，甚至重新运行；

屏底菜单栏，影响显示面积和分辨率，可能会和APP自带的菜单功能冲突；

默认字体和手势操作。

9．3 LG的UX用户界面

提供了多种手势操作。。

9．4 小米的米柚MIUI用户界面

MIUI用户界面拥有以下特点：

一，用户界面没有应用程序列表，若APP会自动在桌面添加快捷方式，测试不会在桌面上显示两个APP图标；

二，沉浸式状态栏；

三，APP角标计数和显示；

四，手势。

9．5 魅族的Flyme用户界面

1，最独特的定制就要数SmartBar了，需要关注APP对于SmartBar的兼容性；

2，分辨率和显示比例与大众不一致；

3，手势。

9．6 Sony的Xperia UI用户界面

9．7 iOS App的显式效果测试

iOS 8和iphone 6及6 plus，具备了放大显示的功能会让APP在标准显示和放大显示的模式，注意这两种模式的显示效果。确保能够适应这些特点对其功能和显示的影响。

军规10 支持多种文件格式

IOS自带iBooks支持打开PDF文件，Android没有自带打开PDF的文件。

在APP打开PDF文件时，一般来说都是启用单独的进程先下载PDF文件之后再打开。下载完成后，APP最好能做到直接打开已经下载的PDF文件。

不仅要验证PDF文件能正常打开，还要保证用户在查看PDF文件时能放大缩小来查看细节。

10．1 App支持Office文件

excel文件类型下包含了：xlsx\xls\csv

10．2 App支持图片文件

在APP展示和处理图片时至少能对图片进行简单的放大和缩小；尤其是对于GIF图片进行展示时，不能只显示第1帧。

10．3 App支持视频和音频文件

如果APP支持多种文件格式，测试人员不仅要测试APP具有功能兼容性，也需要测试这些功能兼容性是否破坏了用户流畅使用APP的整个流程。总之，对于影响用户粘性的行为需要给予特别重视。

军规11 支持多语言和地区设置

11．1 App不支持多语言和地区设置影响用户输入

11．2 App不支持多语言和地区设置的影响

时间和日期格式；不同语言文字对于显示的影响；对于多语言的复制和粘贴。

只是基本功能性和显示格式的测试。

军规12 重点测试高内存占用的功能

12．1 iOS操作系统的内存管理机制以及对App使用内存的限制是很不透明的

IOS上并没有真正的多任务，也没有swap机制，所以iOS操作系统在内存不足时会对App进行内存战胜预警，如果App持续消耗内存直到iOS操作系统允许的最大值，iOS会直接“杀掉”App进程。

使用Apple公司的Xcode来检查App对内存的使用是否超出了限制。
1.在Xcode下找到开发工具中的Instruments。
2.打开进程监控工具Activity Monitor.
3.选择需要监控的App。
4.从所有进程中筛选出需要显示信息的App进程。
5.选择左上角的红点开始监控，并在结束监控时点击黑色方块按钮。
6.选择显示监控App进程的消息，Activity Monitor会显示App信息的平均值，在这里主要关注App所占用的实时内存量。
7.可以通过IOs Simulator的模拟内在报警来测试App在设备内存不足时会做出什么样的处理。

12．2 Android操作系统的内存管理机制更加透明，对App使用内存的限制也更加灵活

打开/system/build.prop文件来查看App最大可用的Dalvik内存大小是什么

1.dalvik.vm.heapstartsize

App内存分配的初始大小，这个值的大小会影响App的流畅性和设备内存消耗速度。这个值越小，设备内存消耗就会越慢。但由于初始值较小，当一些较大的App需要更大的内存占用时，会引发垃圾回收和App内存调整的策略，使得App变得很慢。反之，这个值越大则设备内存消耗越快，App却会更流畅。

2.dalvik.vm.heapgrowthlimit

指明了受控App（在AndroidManifest.xml中没有设置android:largeHeap=”@bool/config_largeHeap”）的内存最大值（仅仅针对Dalvik中App可使用的内存，不包括native中App可以使用的内存）。虽然dvm heap是可增长的，但是正常情况下它的大小不会超过dalvik.vm.heapgrowthlimit的值。如果受控App的dvm heap size超过这个值，则将会引发内存溢出。

3.dalvik.vm.heapsize

相对于dalvik.vm.heapgrowthlimit,dalvik.vm.heapsize表明不受控情况下的App（在AndroidManifest.xml中没有设置android:largeHeap=”@bool/config_largeHeap”）可以使用内存最大值。无论App是否为受控App，一旦它的dalvik heap size超过这个值，就会直接引起Android操作系统内存溢出。

可以通过以下两种工具来查看App实时的内存占用。
1.使用Android自带的SDK中的ADB命令。连接好设备，并在设备上开发者模式下开启“USB debugging”。输入“adb shell dumpsys meminfo”查看系统下运行的所有进程的内存使用情况；输入”adb shell dumpsys meminfo AppPackageName”查看特定App的内存使用详细信息。
2.使用Android设备Setting里Apps中的Running。测试App对内存的使用情况，避免App对于内存的过度使用。针对高分辨率图片、语音、视频的App，验证App在进行操作时不会出现内存溢出或者App崩溃等问题。

测试人员最好能从技术和用户两个角度对App中这些高内存占用的功能进行测试。

军规13 降低流量和电量消耗

13．1 测试App安装文件的大小和安装过程

用户可以选择手支把App关闭而导致下载资源文件失败。要么需要重新下载这些资源文件，要么就需要用户先删除App，再重新安装App并且下载资源文件，否则用户无法继续使用App。

13．2 测试App占用的存储空间

通过操作系统自带的App占用数据空间的统计功能来查看app占用的存储大小是否过大

13．3 测试App的流量消耗

1.ios7开始，在系统设置中，打开“Cellular”

2.Android中系统设置的“流量使用情况”

3.安装目前流行的流量监控

13．4 测试App对于设备电量的消耗

1.ios8开始，系统设置-通用-Usage-battery usage

2.android中,系统设置的battery

军规14 增量升级必不可少

14．1 测试App的增量升级

在测试App升级的过程中，需要注意的测试细节。
1.登录信息升级后正常显示；
2.如果具有内购功能，需要保证用户在之前版本购买的商品要新的版本上同样可用；
3.涉及到数据库结构变化时，确保数据显示正常；
4.保证升级后的功能和显示正常的同时，也要保证升级前的版本功能和显示也正常。
5.跨版本升级；
6.当新版本的App改变了Mobile Service的API时，更需要注意测试Mobile Service能否同时支持新老版本的APP。

14．2 测试App的删除

数据清理干净，否则文件会占据用户设备的存储空间；可能给恶意软件留有可趁之机，导致用户信息泄漏、对App的破解或服务器的攻击。再次安装，别自动登录。

14．3 测试App数据的清除

Android用户以两种方式清理App数据：
1.只清除App缓存。只是清除了那些缓存的图片等资源文件，并不应该清除用户登录的帐号信息等。
2.清除App的数据。可以在App的应用程序信息页面清除App数据。包括了用户信息和对App的设置及其他的用户数据。回到了被安装后的初始状态。重新登录后，在App中产生的没有同步到云端的信息都不应该被保留。

尽可能在真实设备上进行测试。

军规15 确保成功集成和调用第三方App

15．1 App对第三方App的直接集成

地图类的App被集成在很多App中。应该对第三方的集成和调用的测试过程重点测试这些改动。

15．2 测试App的分享功能

全面覆盖。

15．3 测试App显示外部链接的功能

15．4 测试免费App中集成广告的功能

对广告显示和点击跳转的测试。

15．5 测试App使用社交媒体等账号登录的功能

15．6 测试App推送服务

15．7 测试App关联其他文件的功能

算是一种反向集成。如果App中可以打开某些特定类型的文件的功能，那就需要测试在别的App中以选择使用我们的App打开，需要在别的程序中显示打开这些文件的选项。

15．8 测试App和输入法等App交互的功能

做冒烟测试来验证App与这些输入App的兼容性。

整体来说，对于集成和调动第三方测试，不仅能验证自身功能，也能验证与其他App的兼容性。

军规16 尽量不使用非标准控件

因为后来添加的很多功能代码都是基于之前代码的，而之前的代码都成了App代码的基础设施，随着时间的推移，想要替换这基础设施的开发和测试的代价会越来越大，而不替换这些基础设施，开发和测试的代价会更大。

iOS只会保证更新的代码对原生代码的兼容性，而不会保证对第三方的代码实现和类库的兼容性。要考虑到第三方类库的兼容性、性能、维护问题。

最好的方式是，在一开始就尽量少地使用自定义的控件和第三方的控件以及类库，尽量使用操作系统原生的控件和代码来实现App的功能。

军规17 提前关注操作系统升级

大版本的升级，总会带给用户很多新特性。最好能在新操作系统测试的阶段就了解更多的新操作系统特性。

17．1 iOS 6升级所引入的新特性

更换了使用的地图服务；Passbook；App运行状态保存。

17．2 iOS 7升级所引入的新特性

全新UI设计；新的手势操作；支持App在后台更新；可以调整系统字体大小。

17．3 iOS 8升级所引入的新特性

通知中心的小工具Widget；引入第三方输入法；允许App调用指纹识别。

17．4 Android 4．1升级所引入的新特性

增强了通知栏；桌面小工具Widget可以自动调整大小；增强了辅助功能；扩展了语言和输入法的支持；更好地支持Html5.

17．5 Android 4．4升级所引入的新特性

新的UI设计；App支持全屏模式；提供储存访问框架Srorage access framemwork.

17．6 Android 5．0升级所引入的新特性

全新的UI设计Material Design;增强了通知系统；只保留ART运行系统；增强了安全性；

军规18 尽量减少依赖

减少依赖主要是从App的系统架构入手，尽量减少依赖。

18．1 对于既有Web版本又有App版本的App要减少依赖

首先分析，如果已有的Web 的service使用在App上，App中会有哪些场景使用到这些service，哪些service会有性能和样式的问题；其次，选择在App上直接使用可能会出现的那些Web service来实现独立的service。

18．2 没有Web版本的App也需要考虑App的依赖

App基本都是用来展示数据的，真实的操作系统都是由后台的服务器和数据库来实现的，而前台的App和后台的服务器是通过service的形式交换数据的。需要对service进行API和集成测试，以确保这些service的可用性和准确性。

可以使用soapUI和Apache JMeter来测试SOAP service；使用POSTMAN和soapUI来测试RESTful service。

示例：以SoapIU Pro为例，演示如何测试SOAP service

军规19 进行自动化和探索性测试

不能只是一味地添加基于界面的自动化测试，而是需要对App的自动化测试进行设计。

19．1 测试设计和测试金字塔

在不同的开发阶段都进行测试。单元测试、组件测试；功能测试、集成测试；UI测试、端到端测试；手动测试。

1、测试的成本；2、测试的效率；3、缺陷定位的难易；4、反映真实的业务需求；5、更加接近业务。

19．2 单元和组件测试以及TDD

测试人员只需要了解并评审开发人员在单元和组件测试中覆盖了哪些场景，并不需要完成其实现。

19．3 Mobile Service的API测试

通常是开发和测试人员一起讨论并实施的，因为开发人员更了解Mobile Service的API细节，而测试人员有更好地从用户角度排定Mobile Service的API测试的优先级和重点程度，从而优化对Mobile Service的API测试的投入产出比。

19．4 用户界面的自动化测试

尽可能地把可以被别的层级所覆盖的测试都推向更底层的测试层级。编写用户界面的自动化测试时，编写的原则是尽可能编写用户旅程级别的测试用例，而不是针对某一特定的小功能和模块进行测试，而且重点测试的是正向测试路径Happy Path；对于反射测试路径Sad Path，尽可能使用低层级的测试来进行覆盖。

一般来说，尽量保证用户界面的自动化测试能在最多45分钟内运行完成，不然由于效率原因，开发和测试人员都不会经常运行用户界面的自动化测试。

19．5 行为驱动开发BDD

行为驱动开发BDD的开发模式是基地非技术人员可读的测试场景，测试人员编写测试用例，开发人员依据测试用例实现相应功能的整个流程，来加深开发、测试、非技术人员与商业参与者的互动、沟通和协作。

行为驱动开发BDD的框架有Cucumber\Concordion\JBhave。

示例：如何使用Cucumber。

19．6 页面模式Page Object

通常与BDD的开发模式配套使用的测试技术还有页面模式。虽然最早页面模式是针对Web自动化测试设计的，但同样也可以使用在App的自动化测试中。

页面模式的目的就是把自动化测试中对于页面重复方法定义进行简化，减少自动化代码编写和维护的投入。

19．7 自动化测试中模拟器的使用

使用模拟器是比使用真实设备投入产出比更高。

对于iOS操作系统上的App的用户界面自动化测试，只能使用Xcode自带的iOS Simulator，但对于Android上App除了可以选择Android SDK自带的AVDs（android virtual devices），还可以选择第三方的模拟器。

对于Android的模拟器，强烈推荐使用Genymotion（http://www.genymotion.com）

19．8 用户界面自动化测试的常见工具

Appium是有一定优势的。

Appium可以直接使用iOS App 的.app文件和android app的.apk文件来测试，而不需要把自己的类库添加进App自己的代码库，再生成专门用于测试的App安装文件。这样不仅可以避免移动App自动化测试工具自己类库的问题影响到App的自动化测试，也减少了App自动化测试过程中准备App安装文件的复杂程度。

还可以使用Appium的Inspector来定位Ios和android App 中的元素Element。

使用inspector也可以帮助录制App的自动化脚本。

19．9 探索性测试

在测试金字塔的最高层，是对于App的“探索性测试”。

军规20 进行性能和安全性测试

20．1 测试App连接网络的速度

从无网到有网，不同网络间的切换，2G\3G\4G网络所使用的时间及切换所需要的时间。一般采用在模拟Mock的环境下进行测试，而测试的方法更多使用的是在App的log中添加时间戳的方式计算时间。

对于查看App的log，可以使用苹果公司提供的iphone configuration utility和android SDK中的DDMS或ADB来查看对应平台的设备log。

20．2 测试App在不同网络速度下操作的流畅程度

20．3 测试App对于前台页面渲染的性能

20．4 测试App操作数据库的性能

IOS使用的是coredata或sqlite

Android使用sqlite数据库。

大数据量的测试。

20．5 测试App用到的后台服务Mobile Service的性能

就apache JMeter进行简单的App后台服务性能测试演示。

除了关注功能和性能之外，还要对App的安全性问题关注。

测试人员可以使用类似于性能测试的分类方法进行测试。也就是说，App的安全性测试可以分为对App自身的安全性测试和对于App所用后台服务的安全性测试。

在App自身的安全性测试中，测试人员一方面可以从用户使用角度对App是否保存了临时数据或者已删除的数据，App对于会话session是否有过期设置进行测试；另一方面还可以从技术实现的角度对于App请求中是否包含了明文的用户信息，App的请求是否加密，SQlite数据库的存储是否安全，以及App使用WebView的安全性等方面进行测试。

20．6 测试App是否保存了临时数据或者已删除的数据

未保存的内容是否会清空；先清空，再打开是否还显示。

20．7 测试App的会话session是否有过期设置

输入密码：自动保存；过一定时间自动退出。合理的session过期时间不一样。

20．8 测试App请求中是否包含了明文的用户信息

使用UUID或者GUID等转码后的信息而不是电话号码或者账号信息等，测试人员可以使用Apple的iPhone Configuration Utility,android SDK自带的DDMS\Charles和Fiddler这些工具来监控App发送的请求。

20．9 测试App的请求是否加密

HTTPS

20．10 测试SQLite数据库的存储是否安全

测试App本地存储的SQlite数据库是否安全，测试人员可以通过ADB连接到root的android设备，并使用SQlite来查看具体的数据库保存的信息。

20．11 测试App使用WebView的安全性

可以采用和测试App所用的后台服务的安全性同样的方式进行测试，包括使用的各种工具。

20．12 测试App的后台服务Mobile Service

使用Zed Attacd Proxy来进行简单的App后台服务安全性测试演示。

军规21 使用log定位问题

选择Crashlytics来进行介绍。

军规22 充分使用持续集成和持续部署

22．1 第一种方式

通过TestFlight\Crashlytics\HockeyApp\installr

22．2 第二种方式

由于android支持从设备本地安装App，所以我们还可以通过Dropbox等文件分享工具进行分发。

App测试综合案例分析

23．1 首先需要确定测试微信App需要的设备和版本

23．2 “移动”测试微信App

23．3 测试微信App的多任务和意外情况处理

23．4 测试微信App的手势操作

23．5 测试微信App的用户体验

23．6 测试微信App的消息显示和通知展示

23．7 测试微信App对于操作系统特性的支持程度

23．8 测试微信App能否及时显示和同步消息

23．9 测试微信App能否适应不同设备的不同用户界面

23．10 测试微信App对于多种格式图片的支持

23．11 测试微信App对多语言和地区的支持

23．12 测试微信App中高内存使用的功能

23．13 测试微信App的流量和电量消耗

23．14 测试微信App的增量升级

23．15 测试微信App中集成和调用第三方App

23．16 测试微信App中非标准控件的使用情况

23．17 测试微信App对于最新操作系统特性的支持

23．18 测试微信App的依赖情况

23．19 对微信App进行自动化测试和探索性测试

23．20 对微信App进行性能测试和安全性测试

23．21 测试微信App的log提交

23．22 实现微信App的持续集成和持续部署