移动APP测试

                  移动APP测试

1.测试设备和操作系统版本的选择。
    屏幕尺寸、分辨率、像素密度

2.移动测试。
    wifi、3g/4g/LTE、EDGE/GPRS（开发人员用MOCK技术模拟、获取信令的验证）、飞行模式。大量数据传输时，把3g/4g/LTE分开。错误提示信息需人性化；避免用户手
动刷新，后台自动刷新，避免在网络恢复过后APP依旧显示网络异常的提示信息。若多次刷新失败，放弃刷新尝试，以免浪费电量或者流量

3.关注多任务和意外情况处理。
    a.如填写某些（地址，登录）等信息时，切换至程序后再切换回来，看是否刚才填写的信息依然存在。
    b.APP使用过程中，接听来电后是否需要在后台运行？是否需要在状态栏和通知栏显示信息？
    c.不同APP间切换，打开APP的速度是否会变慢，切换时的动画是否会出现卡顿（Android）。关闭APP后，再重启，其响应速度是否会变慢（缓存数据是否被修改或者
被破坏，APP试图恢复关闭的状态时，可能会造成长时间的等待，甚至可能造成APP崩溃）
    d.硬件的影响。锁屏时，APP是否应该继续运行还是等待屏幕 恢复之后在运行？当解锁时，APP是停留在当前的子页面还是回到APP的主页面？前台运行APP，等待屏幕
进行休眠时，点击解锁键，观察APP的表现。
    e.home键，切换到后台时，1/5/10/30分钟之后，再次打开的时候是如何表现的，APP是停留在当前的子页面还是回到APP的主页面？页面的显示信息又是怎样的？
    f.不允许把APP存储到内存卡。不然拔出sd卡对APP来说是毁灭级的。

4.避免手势冲突。
    a.从屏幕左侧边缘向右滑动（返回上一页）。屏幕其他位置右滑则会呼出APP的导航菜单栏。（错误：向左滑动出现右侧导航菜单栏的APP）
    b.从顶部向下滑动，呼出操作系统的通知中心。
    c.底部向上滑动（iOS7-呼出控制中心，若关闭“应用程序内访问”功能，则无法打开）
    d.按住屏幕向下滑动（iOS7开始，主屏作此操作呼出搜索框），APP里面为刷新。
    e.通常图片上双击，APP放大此图片，再次双击，恢复之前的大小。
    f.两根手指分开和捏合，通常在APP中，此操作是平滑的放大和缩小当前页面、图片。
    g.图片编辑，两根手指按住屏幕旋转。
    h.3根手指操作（iOS关闭3个当前显示的3个APP）
    i.在iPad的APP中，使用4根手指手势操作，用4根手指向下滑动，就能关闭多任务处理界面；用4根手指向左滑动，可以切换到最近使用的APP，再向左，可以切换到上一个APP；向左和向右是对应的操作。
    j.在iPad上使用5根手指聚拢的捏合操作，能在任何一个APP中返回主界面。

5.关注用户体验。
    a.横竖屏幕测试（从启动到关闭每个页面）。若APP中嵌入了webview的页面的显示，当webview读取完成时，有可能横竖屏切换功能就被破坏了。
    b.若支持图表显示，则可能应为屏幕宽度和高度不同而改变显示内容和效果的页面。
    c.webview的测试（未做到响应式设计）。不同设备设备尺寸不一样，导致显示效果也不一样；若是具有特定格式的webview，在不同设备上差别可能更大。在手机上显示的webview和在web上显示的不一样。
    d.在不同颜色的背景下，状态栏的显示是否正常（与背景颜色一致）。ios7,Android4.4都开始支持沉浸式状态栏。

6.设计通知和消息展示。

    a.测试人员在测试APP的时候，需要注意这些权限是否申明明确，不然APP在提交到操作系统官方应用商店是会被拒绝，或者在用户安装APP的时候被拒绝。
    b.在用户使用APP的过程中，当APP需要使用到类似蓝牙、GPS、流量、照片、短信、通讯录等传感器或应用资源的时候，测试人员需要及时通知用户；当需要获得用户位置等隐私信息时，必须给用户提示。当不允许获得隐私信息即改变权限时，iOS会访问不到它想获得的资源和权限，而在Android上，操作系统会弹出安全性异常的提示框，并强制关闭APP。
    c.APP向用户申请访问权限的第一次很关键。方法如下：
    （1）用户第一次启动APP后，先向用户讲述授权后的便利，在用户有所了解后再次申请访问权限。
    （2）让用户更多机会了解APP之后再次申请权限。
    （3）让用户来出发什么时候对APP进行访问权限的授权。
    d.测试app在后台运行的时候是否有合适的通知和消息显示。用例设计：关闭通知中心时，是否仍然有提示信息？通知中心、状态栏、锁屏界面中、或显示为横幅或者提醒。
    （1）iOS的状态栏在通话、导航、录音、使用热点等情况下会变为双倍宽度，故需要测试从单倍宽度到双倍宽度，从双倍宽度到单倍宽度的情况。
    （2）iOS允许在其图标右上角显示未读信息的计数，而Android原生是不支持APP未读信息的计数显示的。计数显示有iOS提供，但计数的数字是由APP提供，故测试用例设计（若APP支持未读信息技术的显示时）：已经通过通知栏读取了的信息，并没有从APP计数中减去，导致计数显示与真实情况不一致。

    （3）若Android端APP没有采用百度的消息推送框架来完成消息的发送和展示，则会采用在后台开启单独的消息推送进程和后台服务器进行交互。而且如果APP及其服务器都被用户关闭之后，用户是收不到消息的。

           故可设计如下测试用例:

           对APP自己完成消息推送的情况，测试人员需要测试关闭APP自身服务或者APP后台服务器时，APP是否会崩溃，APP对于新消息的处理，以及APP消息推送的性能等。 对APP采用推送框架的情况，测试人员可以让推送通知框架的提供商关注后台服务器出错的场景，但是依然需要测试在APP接收到错误的推送通知，推送通知框架服务不可用时APP会如何处理。
    e.测试APP在出错是是否有合适的通知和消息显示。

7.支持操作系统特性。
    a.android的APP更容易被破解，采用反编译的工具来保护APP的安全（Android自带的Proguard工具就可以用来混淆代码），需要向开发人员确认在AndroidAPP代码中开启了Proguard。
    b.URL Schema就是iOS内的APP调用协议（APP进程间通信的一种方式）。使用iPhone configuration Utility可以用来查看log中有关URL schema的字段来测试APP之间的调用。
    c.在有widget的APP测试中，测试人员需要对以下情形进行测试：widget中进行的操作是否及时同步到APP中，APP中的数据及状态变化是否即时反映在widget里。
    d.由于Widget在用户界面长期显示，在widget显示和工作的时候，APP也不一定在工作，如果widget过于依赖APP的运行状态和数据，就可能发生widget无响应的情况。
    e.在iOS8中对于可以使用的内存，widget是远远低于APP的，所以当内存不足时，iOS更倾向于优先关闭widget,而不是杀死APP。因此可以考虑在高内存占用的时候来测试widget的性能。
    f.两个APP之间的widget可能会在通知中心栏内共存，如果这两个widget之间相互竞争从而阻塞了主线程的话，可能会引起整个通知中心失去响应，故需要测试共存时的兼容性。
    g.测试APP在特定设置下的行为。在操作系统的设置页面增加对于APP单独的设置。要测试其APP的功能、显示、性能是否正常。

8.及时显示和同步消息。
    测试缓存所占存储空间的大小；对于能够同时登陆多个设备的账号，要测试其是否能够被同步到所有的设备（Android和IOS）。
    对于支持同步消息的APP，用其不同版本对其进行测试。
    对于APP在安装和登陆后被关闭了的情况，测试在别的APP消息都被同步了之后，再次打开这个APP，观察是否会接受到在别的APP上被同步的消息。
    当APP同时支持缓存和同步信息显示是，测试人员需要在信息处于缓存的阶段改变该信息，再去测试在不同APP上这条信息是否能更新相应的内容。

9.适应特定用户界面对功能和显示的影响。
    a.三星的TouchWiz用户界面。（比原生安卓提供更多的手势操作，HTC sense/OPPO/LG的UX/也是如此，就有可能导致APP中的手势操作与用户界面的手势操作相冲突）。下面将特别的用户界面列出来。
    a1.米柚MIUI用户界面没有应用程序列表，而是类似iOS操作系统，把所有的程序都排列在桌面上。如果APP会自动在桌面上添加图标，就需要测试在桌面上是否生成了两个APP图标，或者导致桌面和系统异常。
    a2.由于MIUI界面高度模仿iOS的设计和操作理念，所以在MIUI6上也开始支持沉浸式状态栏，这也是测试人员需要确保App在miui上能支持的一个特性。
    a3.MIUI用户界面从MIUI6开始支持角标通知计数显示（故需要对角标计数进行测试）。
    a4.魅族的flyme用户界面也不具有应用程序列表，以及支持更多手势操作。
    a5.随着iOS8和iPhone6和iPhone6p的推出，其放大显示功能，会让APP在标准显示和放大显示的模式下，显示效果有所不同（测试点）。
    b.若某款手机的用户界面采用了不同于Android系统默认的字体，在测试时需要针对字体显示的不同，对于文本显示进行更仔细地验证。

10.支持多种文件格式。
    a.iOS的ibooks支持打开PDF文件，而Android不支持。在这种情况下，如果APP涉及到某些签协议的文件，其格式如果不被系统支持，则需要在APP中集成某种文件查看器（如PDF文件查看器），便于在APP中显示PDF文件，并且要让用户操作流程简单，下载下来可以自动打开查看，而不是要求用户自动打开，要保证能正常的放大和缩小，避免因看不清协议文件而让APP负不必要的法律责任。
    b.测试APP支持office文件，需要检查多种格式类型。
    c.APP需要支持通用的的图片文件格式：BMP、JPEG、PNG、GIF、TIFF
    d.常见的视频文件格式：MP4、3GP、AVI、RMVB、MKV、MOV
    f.常见的音频文件格式：MP3、WAV、AAC、OGG、APE
    g.常见的编码方式ＭＰＥＧ系列，视频编码MPEG1、MPEG2、MPEG3、MPEG4、MPEG4AVC;音频编码：MPEG AUDIO Layer1/2、MPEG AUDIO Layer3/MP3、MPEG-2AAC、MPEG-４AAC和Ｈ.26系列（H.262、H.263、H.263+、H.263++和H.264）。
    
11.支持多种语言和地区设置。
    a.如果APP不支持多语言和地区设置，若只支持一种语言，则切换到另外一种语言的输入法时，可能导致无法输入内容，甚至界面出错。
    b.若支持多语言显示，还需要注意不同语言文字对于显示的影响。比如中文单词和英文单词在换行时，中文是可以一个字单独拆开的，而英文单词不行，一个字母不能脱离整个单词，必须整个单词一起换行。
    c.在APP的输入框粘贴进多种语言的文字，看是否发生显示错误（复制粘贴可能发生改变，甚至崩溃）。不需要作正常处理，APP可以忽略或者提示用户错误信息，但是必须保证不能崩溃。

12.重点测试高内存占用的功能。
    a.ios中，如果内存占用不足时，操作系统内存不足时，会先对APP进行内存占用预警，如果APP持续消耗内存直到最大值，iOS会直接杀死掉APP进程。

    b.选择APP所支持的iOS设备中内存占用最小的设备，用XCODE->Open Developer Tool->Instruments->Activity Monitor->选择要监控的APP->筛选出需要显示信息的APP进程->红色按钮开始监控->选择显示监控APP进程的信息->实时内存量Real Memory Usage;

Hardware->Simulate Memory Warning测试APP在内存不足时会做出什么样的处理。进行大量使用内存的操作（问APP开发人员）。

    c.特别针对需要大量展示高分辨率图片，保存和处理长时间的语音、保存和播放大量视频的APP，测试人员需要进行多次和长时间的操作，以验证APP在进行这些操作时不会出现内存溢出或者APP崩溃等问题。因为APP在进行这些需要大数据量的操作时是应该启用单独的进程处理的，如果在开发和设计时没有这么做，就容易造成APP主进程的内存溢出和崩溃。

13.降低流量和电量消耗。
    a.下载安装测试，APP下载资源文件过程中，需要查看在熄屏（自动或者手动）再打开、关掉并重新连接、断网并重新连接情况下会不会续传。对于iOS，APP在锁屏10分钟之内就会被切换到后台，导致APP的下载操作也会停止。这时APP下载资源文件就会出错。    b.ios8中可以查看电量的消耗。

14.增量升级必不可少。
    a.在升级之前登陆的用户信息在APP升级后是否能正常显示。
    b.若APP具有内购的功能，需要保证用户在之前版本的APP购买的商品在新的APP版本上同样可用。
    c.当APP升级涉及到数据库结构变化时，需要确保在APP升级过后，保存在APP之前版本数据库中的数据在新的APP上显示正常，不会导致APP崩溃。
    d.在保证APP升级后功能和显示正常的同时，也需要保证APP升级之前的版本的功能和显示也正常。
    e.测试是否支持跨版本升级。
    f.测试APP的删除是否保留缓存个人信息缓存文件等，比如再次安装时发现仍能自动登录，会导致用户信息泄露，对APP的破解或者对APP服务器的攻击。
    h.Android操作系统中用户以两种方式清除APP的缓存，一是只清除那些缓存的图片等资源文件。并不应该清楚用户的登录的账号信息。二是清除数据，所有的信息都被清除。

15.确保成功集成和调用第三方APP。
    a.APP对第三方APP的直接集成。比如地图类的APP被集成在很多APP中，对于这些直接集成在APP中的第三方APP，如果功能或者内容有任何修改，测试人员就应该在对于第三方APP的集成和调用的测试过程中重点测试这些改动。
    b.测试APP分享、广告的功能。
    c.需要考虑到如果第三方的社交媒体账号登录暂时不可用，APP需要进行怎样的处理。
    d.推送功能的测试。
    e.如果APP具有可以打开某种文件的功能，则需要在文件管理器APP中或者别的APP中，打开这些文件时，是否可以使用本APP来打开。
    f.ios8及以上，APP和输入法等APP交互的功能。测试APP之间的交互性。

16.尽量不使用非标准控件。
    第三方类库的兼容性问题、性能问题、维护问题。

17.提前关注操作系统升级。
    a.iOS7支持系统字体调整。需要测试在不同系统字体大小下，APP都能正常显示和使用
    b.ios7支持后台更新数据。ios8引入了通知中心小工具widget。ios8允许APP调用指纹识别。
    c.Android4.1增加了通知栏，使得APP可以在通知栏显示更多的操作。测试人员需要覆盖到在通知栏进行操作的场景。
    d.新增的辅助功能方便残障人士使用，看APP是否支持这些功能。
    e.更好的支持h5,需要对使用webview的功能进行重点测试。
    f.Android4.4升级所引入的新特性。支持全屏模式（此模式下就不需要通知栏和虚拟按键）。
    g.Android4.4tigongde 存储访问框架Storage access framework，可以使APP从本地或者Dropbox和Box这样的第三方存储中提取文件，大大扩展了APP使用数据的范围。要针对能提取的不同的数据源做出测试。
    h.针对Android5.0，只保留了ART运行环境（安装时就解码），需要对ART运行环境进行适配和测试。针对新操作系统版本设计和开发新版本的APP时，也需要考虑这些特性对于测试APP的影响，比如在新操作系统初期版本上进行适应性测试，并同时在当前的操作系统上对当前版本的APP做回归性测试。

18.尽量减少依赖。
    a.如果已有的Web的service使用在APP上，APP中会有哪些场景使用到这些service，哪些service会有性能和样式的问题；其次，选择在APP上直接使用可能会出现问题的那些Web service 来实现独立的service。
    b.测试人员需要对service测试隔离后台服务器的变化对APP产生的影响。也需要对service进行API和集成测试，以确保这些service的可用性和准确性。可以使用SOAPUI和Apache JMter来测试SOAP service，使用POSTMAN 和SOAPUI来测试RESTful service。

19.进行自动化和探索性测试。
    a.我们不能只是一味的添加基于界面的自动化测试，而是需要对APP的自动化测试进行设计。在测试设计时最主要依据的就是测试金字塔的测试结构。 ->单元和组件测试（测试人员只需要了解并评审开发人员在单元和组件测试中覆盖了哪些场景，并不需要完成其实现->MobileService的API测试。通常需要自动化测试。这些测试能够及早的告诉APP所依赖的第三方服务或者系统是否可用，而且能够帮助实时监控这些APP之外的资源。（开发与测试一起讨论并实施）->用户界面的自动化测试（编写的原则尽可能编写用户旅程级别的测试用例，而不是针对某一特定的小功能和模块进行测试，而且重点测试的是正向测试路径）。

20.进行性能和安全性测试。
    a.在不同网络之间切换时，采用模拟Mock的环境下进行测试，而测试的方法更多的是在APP的log中添加时间戳的方式计算时间。（iPhone Configuration Utility和Android SDK中的DDMS或者ADB）
    b.若APP中嵌入了Webview，测试人员可以快速的刷新当前页面或者在使用Webview的页面间进行切换，因为webview里一般来说需要调用的不止一个线程。
    c.测试APP操作数据库的性能。
    d.测试APP用到的后台服务Mobile Service的性能。测试人员可以采用测试web性能通用的一些测试工具，比如Apache JMeter/LoadRunner/LoadUI/NewReic/Gating等。    
    e.安全性测试。测试APP是否保存了临时数据或者已删除的数据，先关闭，再打开APP，观察那些未保存的内容是否被清空即可。或者先清除APP对应的数据，通过文件管理APP来查看APP是否保存了不该保存的文件，例如APP的cookie文件等。
    f.测试APP的会话session是否有过期设置。切换到别的APP或者桌面一段时间，然后再次进入APP，看APP是否需要输入密码等验证信息。
    g.测试APP请求中是否包含了明文的用户信息。比如在APP中标识用户应该使用UUID或者ＧＵＩＤ等转码后的信息而不是电话号码或者账号信息等，当然更不应该用明码传送这些信息。（iPhone Configuration Utility和Android SDK中的DDMS、Charles和Fiddler这些工具来监控APP发出的请求）
    h.测试APP的请求是否加密。涉及到用户敏感信息要用https。
    i.测试sqlite数据库的存储是否安全。测试APP本地存储的SQlite数据库是否安全，测试人员可以通过ADB连接到root的Android设备，并使用SQlite来查看具体的数据库保存信息。如果存储了用户的账户信息，必须加密，但是尽量不要存储用户的账户信息。    
    j.测试APP使用webview的安全性，可以采用和测试APP所用的后台服务的安全性同样的方式进行测试，包括使用的各种工具。任何使用于webview的请求和在web端请求数据是一致的，所以任何使用于web端的攻击方式和漏洞对于webview来说都是通用的。
    k.测试APP的后台服务Mobile Service。测试人员可以采用与web安全性测试通用的一些测试工具，例如Zed Attack Proxy(ZAP)、Burp Suite、Websecurity、Wapiti和WebScarab等。
    l.使用Facebook的osquery、Netflix的Scunblr、Google的nogotofail等互联网公司的安全工具或者框架来协助进行安全测试。也可参考iOS开发安全指南，Android开发安全技巧，发放式web应用程序安全项目（open web application security project，OWASP）TOP10和OWASP安全性测试指南，以及乌云网的漏洞列表。

21.使用log定位问题。
    Crashlytics是Twitter旗下的一款产品，能够支持iOS、Android平台上手机APP崩溃的日志。

22.充分使用持续集成和持续部署（Jenkins ）。