移动App测试的22条军规

内容提要

本书全面讲解了移动App测试的技术、技巧、工具、案例和测试用例，全书共分23章，主要内容为：移动App的特性，关注多任务和意外情况处理，避免手势冲突，关注用户体验，设计通知和消息展示，支持操作系统特性，及时显示和同步消息，支持多种文件格式，支持多语言和地区设置，重点测试高内存占用的功能、降低流量和电量消耗，确保成功集成和调用第三方App，尽量不使用非标准控件，iOS 8升级所引入的新特性，Android 5.0升级所引入的新特性，自动化和探索性测试，自动化测试中模拟器的使用，用户界面自动化测试的常见工具，性能和安全性测试，使用Log定位问题，充分使用持续集成、持续部署，以及微信App测试综合案例分析等核心技术。

本书适合软件的测试初学者、测试从业人员及程序员阅读，也可以作为大专院校相关专业师生的学习用书，以及培训学校的教材。

前言

随着这几年智能设备的大规模普及，越来越多的人开始使用智能手机和平板电脑，因此，移动App的使用也越来越广泛。用户对于手机和平板电脑上App的要求渐渐地不局限于功能，更多地要求提升用户体验，且蜂拥进入移动App市场的各类公司也在加剧着这种趋势。因此，要想使自己的App脱颖而出，不仅需要使产品以更高品质，在更短的时间内投放到市场，还需要不断改进产品，以满足用户不断变化的需求和体验。

对整个App开发团队来说，这是很大的挑战，因为，不仅需要从开发方法和流程上适应各种变化，还需要更新技能以适应这些变化。对测试人员来说，了解移动App的测试和桌面应用测试的区别，设计专门针对移动App的测试场景和用例，高效地进行移动App的测试，成为了头等大事，为了帮助读者尽快适应这样的需求，特意撰写了本书。

本书是作者从项目实践中总结出来的22条移动App测试军规，帮助读者梳理测试思维，指导读者设计测试用例，以便更好地完成App的完整测试，本书的主要内容如下。

移动App的特性，关注多任务和意外情况处理，避免手势冲突，关注用户体验，其他需要关注的用户体验的细节，设计通知和消息展示，支持操作系统特性，及时显示和同步消息，支持多种文件格式，支持多语言和地区设置，重点测试高内存占用的功能，降低流量和电量消耗，确保成功集成和调用第三方App，测试App使用社交媒体等账号登录的功能，iOS 8升级所引入的新特性，Android 5.0升级所引入的新特性，尽量减少依赖，进行自动化和探索性测试，自动化测试中模拟器的使用，用户界面测试，性能和安全性测试，测试App用到的后台服务Mobile Service的性能，使用Log定位问题，充分使用持续集成和持续部署，微信App测试综合案例分析。

由于写作时间仓促，加之作者水平有限，书中难免有不当的地方，恳请广大读者给出修改建议，本书答疑联系方式为：http://weibo.com/hy1984427。

本书可以作为测试初学者阅读，可以帮助读者快速融入测试行业，并全面了解和掌握App测试所需要的技术和方法；本书适合测试从业人员阅读，通过本书讲述的技术、技巧、工具、案例和测试用例，可以帮助读者尽快进行自己项目的测试，因为本书所讲的技术适用于任何移动App测试项目；本书也适合从业于移动App开发的程序员，可以从本书了解App测试在整个产品开发中的位置和重要性，并在工作中与测试人员紧密配合，高效完成测试的全过程；同时本书也适合大专院校相关专业师生的学习用书，以及培训学校的教材。

自序

“移动App测试”，哦？虽然我们开发移动App，但我又不是测试人员，关心测试干什么？

先别急着打退堂鼓，试想一下在移动App开发团队中谁需要了解用户？谁需要知道技术实现？再想一下对这两方面都了解的有谁？难道不应该是测试人员吗？

现在你还不想了解测试人员是如何看待和关注移动App，以及在工作中是如何融合用户需求和技术实现的吗？

本书中这22条军规不仅针对测试人员，对于开发人员和项目经理同样适用。我们在开发移动App的时候，无论是从用户角度进行需求分析，还是从技术实现角度构建App，都可以遵循这22条军规的指导。

本书介绍的App测试军规绝没有枯燥的理论，都是实践案例的浓缩，在实例的介绍中没准就有你的项目的影子，为什么不按照军规实战一把呢？

希望通过笔者的经验分享能让你少走一些弯路。

军规1　确定设备和平台再动手

在测试设计之初，测试人员首先会考虑的是什么呢？没错，就是测试的环境，也就是确定App究竟需要运行在什么样的设备和平台上。

显然，在移动设备和平台碎片化的现实中，测试人员穷尽所有设备和操作系统的版本来实现全覆盖的测试是不可能的。那如何在有限的时间和精力投入下，从投入产出比的角度出发，达到尽可能多的测试覆盖呢？这里主要考虑以下几个方面。

1.1　移动App的特性

（1）如果App是针对心率监测、指纹识别、近场通信（NFC）、红外线操控这些需要特殊传感器设计的，那对测试设备和平台的选择就相对少一些，只需要考虑那些拥有这些传感器的设备。例如对于支持指纹识别的App，测试人员需要考虑的设备也就是iPhone 5s、iPhone 6、iPhone 6Plus、iPad Air2、iPad mini3、LG G3、三星Galaxy S5、三星Galaxy Note4、HTC One Max和华为Mate7这些设备（不考虑市场占有率比较低的vivo和OPPO的手机）；而如果App支持心率监测，测试人员就只能选择三星Galaxy S5和Galaxy Note4了。

这里推荐大家使用一个网站（http://www.phonearena.com）来做设备的查找工作。通过这个网站不仅可以查询到各种手机和平板设备的详细参数信息，还可以对它们进行横向对比，方便测试人员找到适合用来做测试的设备（如图1.1所示）。

（2）如果App是针对某种平台所独有的功能设计的，或者是某种平台独占的，测试人员就只需要考虑相应平台下的设备。比如App是类似Android设备上层出不穷的“xx清理大师”，那在确定测试设备和平台时就不需要考虑iOS平台了；又比如之前Instagram选择只支持iOS平台，那作为Instagram的测试人员只需要关注于iOS设备就足够了。

图1.1　http://www.phonearena.com设备对比

或者，如果App选择不支持某种平台，相应的，测试人员也就不需要测试运行这些平台的设备了。比如WindowsPhone、黑莓（BlackBerry）以及塞班（Symbian）平台在市场上的占有率已经很低了（根据2014年第四季度的调查，详见图1.2），如果在开发时选择不支持这些平台，那在测试时测试人员就完全可以忽略相关的设备。

图1.2　2014年第四季度各操作系统市场占有率调查表

（3）如果App是面向大众的通用型App，测试人员就需要结合移动App的生命周期和测试设备的硬件参数来确定测试设备和平台了。

1.2　移动App的生命周期

（1）对于还处于开发阶段但准备不久之后投入市场的一款新App，鉴于并没有已经实际使用App的用户，所以测试人员要“预测”真实的用户所使用的设备和平台。在这种情况下，首先需要了解使用App的主要用户是哪一类人群，比如说是发烧友，还是商务人士。发烧友极有可能使用的是最新的设备和平台；商务人士更多使用的是成熟的平台，高端一些的设备；而如果用户是普通大众，就需要通过Apple和Google官方发布的版本占有率数据来帮助测试人员进行有依据的“拍脑袋”了。

以下是Apple官方发布的iOS版本占有率数据(https://developer.apple.com/support/appstore/)，如图1.3所示；和Google官方发布的Android版本占有率数据（http://developer.android.com/
about/dashboards/index.html），如图1.4所示。

（2）对于已经发布并且有稳定用户群的App，测试人员可以使用在桌面应用开发时用到的工具，例如Google Analytics或Omniture SiteCatalyst（现在Omniture被Adobe收购了，工具也改名叫做Adobe Analytics）来统计用户的信息，从而确定App支持和需要测试的设备及平台。这里对于App有一点要求，就是App需要联网对后台的服务器发送请求，从而能获取到用户信息。

图1.3　截至2015年1月5日，iOS各版本所占比例

图1.4　截至2015年1月5日，Android各版本所占比例

Google Analytics（Google分析，网址为http://www.google.com/analytics）是Google的一款免费的网站分析服务，使用范围十分广泛。Google Analytics功能非常强大，只要在网站的页面上加入一段代码，就可以提供丰富详尽的图表式报告。Google Analytics的特点是简单易用，但是相应的缺点就是不可定制化。Google Analytics的页面如图1.5所示。

图1.5　Google Analytics

Omniture SiteCatalyst（Adobe Analytics，网址为http://www.adobe.com/solutions/digital-analytics.html）是一个进行网站基本指标的搜集、报告和分析的工具。通过这个软件可以得到网站和App的访问量、浏览量、跳出率、转化率、来源等诸多指标。只要在App中对不同事件以及发送请求都添加相应的Omniture追踪，然后再登录Omniture的网页就可以进行用户数据分析。Omniture SiteCatalyst不同于Google Analytics的一个特点是，它可以对数据进行高级细分，也就是说，可以对用户的各种操作打上不同的标签，在服务器端搜集到信息后进行统一的筛选和分析。Omniture SiteCatalyst的页面如图1.6所示。

（3）对于上面两种情况，有一种特例需要考虑，就是在有新的操作系统版本将要发布的时候，需要参考以前操作系统版本升级时用户更新的进度。正如图1.3和图1.4所示，在iOS 8发布3个月之内有68%的用户进行了升级，而使用iOS 7之前版本的用户只有4%；而Android 4.4 Kitkat发布一年后，市场占有率才刚刚达到39.1%，有超过52.7%的用户使用的还是4.0～4.3版本的Android，甚至还有8.2%左右的用户还在使用着Android 2.x的设备。

图1.6　Omniture SiteCatalyst

根据这些数据，测试人员在iOS操作系统版本升级时需要及早适配新的App版本；而对于Android发布新的操作系统时，测试人员主要还得关注当前市场占有率高的那些老版本。

1.3　设备的硬件参数

（1）屏幕尺寸。现在手机越出越大，连坚持自己风格的苹果公司也开始跟风发布大屏手机了。屏幕大小除了会影响显示效果外，还会影响到用户的使用习惯。一般用户手持6英寸屏幕的设备时，会采取双手操作的方式，所以App如果同时支持横纵屏显示会带来更好的用户体验（如图1.7所示）。

图1.7　双手持握设备的方式

而对于4～5英寸这种可以单手持握的设备，如果App无论横纵向显示，按钮都最好不要放在屏幕四个角，以免用户很难点击（如图1.8所示）。

图1.8　单手操作范围

49%的单手操作用户采用的是以上两种姿势（左手用户相反）。绿色代表容易点击区域，黄色为拇指伸展可点击区域，红色区域为超出单手可点击范围。

（2）分辨率。分辨率的大小会决定显示内容的多少，这对显示图片和视频时会有一定的影响（如图1.9所示）。

图1.9　不同分辨率下显示内容的大小以及显示比例

还需要注意的是，有些厂商（比如说魅族）虽然标注的屏幕尺寸和通用产品一致，但由于显示比例的不同，分辨率和通用产品也会有差别（图1.10所示为魅族MX4采用的15:9的屏幕比例，而非标准的16:9的屏幕比例）。

图1.10　魅族MX4的的屏幕比例（右）

（3）像素密度。屏幕大小和分辨率决定了像素密度。不同的像素密度对于显示也会有差别。在retina的屏幕上显示非retina的图片会很模糊，反之则会显得失真（如图1.11和图1.12所示）。如果需要同时支持retina和非retina的设备，那测试人员需要测试是否对图片，尤其是App的显示图片提供retina和非retina两个版本。

图1.11　非retina和retina的文字显示

图1.12　非retina和retina的图片显示

选取了操作系统版本和测试设备之后，就可以设计矩阵来配对操作系统版本和测试设备了。具体可以参考表1.1。

表1.1　测试设备和操作系统版本对照表

设计测试设备和操作系统版本对照表的原则是：让不同分辨率、不同屏幕尺寸大小的设备尽可能多地涵盖各个操作系统版本，另外，对于市场占有率很高的重点操作系统版本，可以使用多个设备来测试。

可以看到，对于同一种设备（如图1.13中的iPhone 5s所示），由于市场占有率大，而且支持多个操作系统版本，所以在iPhone 5s上需要测试iOS 7.1和iOS 8.1两个版本；由于iPhone 5s和iPhone 6Plus分辨率、性能等都不一样，所以同样对于iOS 8.1，两者都需要测试。

在设计Android设备和操作系统的覆盖时，可以看到对于类似的设备（比如HTC One XL和三星Galaxy S3硬件水平很接近），并没有要在它们上分别都测试覆盖Android 4.1和4.2，而是在HTC One XL测试Android 4.1，在三星Galaxy S3上测试Android 4.2。而Sony Xperia Z在CPU、内存、屏幕大小和分辨率上都和三星Galaxy S3不同，所以在这两部设备上都需要测试Android 4.2。

设计表格的过程中，测试人员还需要注意以下两点。

（1）操作系统的小版本升级一般只是修复缺陷，不会引入新的功能，例如iOS从8.0.1升级到8.0.2，以及Android从4.4.1升级到4.4.4。这时，如果不是App恰好被这些缺陷修复所影响，测试人员不需要考虑覆盖这些小版本。至于中间版本的升级，例如从iOS 8.0.2升级到8.1，以及Android从4.1升级到4.4，这时需要考察变动对App的影响，决定是否测试覆盖相应版本。就拿 Android 4.1 和 Android 4.4 来说，因为Android 4.4相比于4.1新增了ART运行环境，所以针对这一点，测试人员需要准备设备安装Android 4.4，而不是仅仅在安装有Android 4.1的设备上测试。至于操作系统大的版本升级，就必须要进行测试覆盖了。

（2）随着操作系统升级，既有的设备可能无法流畅地运行新的操作系统时，测试人员就需要考虑是不是还继续在新的操作系统上测试这些设备。比如，iPhone 4在升级为iOS 7之后运行速度变得很慢，各种操作的延迟都会很长，固然有一部分用户还是强忍着会继续使用，但是很多用户会放弃在新的操作系统上使用运行很慢的老旧设备。当新的操作系统升级时，甚至有些旧的设备就不会被支持了，例如iOS 8就不再支持iPhone 4。这时候如果确定这些旧的设备上的操作系统占比很小的话，测试人员就可以果断放弃这些设备。

所以测试人员需要从设备角度出发决定要测试的操作系统，以及从操作系统出发决定要测试的设备这两方面来考虑测试设备和操作系统版本对照表的制定。

明确了测试设备和操作系统版本，下面我们就来了解下在设计测试场景和用例中可以运用哪些具体的军规。

军规5　关注用户体验

在经历了移动App匮乏的时代之后，当今移动App呈现出大爆发式的增长趋势。同一类型的软件，虽然提供的功能都差不多，但是也会有多家公司竞争。例如即时通信类软件，大家常见的就有微信、来往、米聊、WhatsApp（如图5.1所示）、LINE（如图5.2所示）、Skype、KakaoTalk这些，而不常见的就更多了。

图5.1　常见的即时通信类软件WhatsApp

图5.2　常见的即时通信类软件LINE

当我们的App也是这众多App中一员的时候，如何才能脱颖而出呢？其实就是按照现在流行的说法——为用户设计，关注用户的体验。

就移动App测试来说，也需要关注用户体验吗？是的，测试人员不仅需要关注App的功能性需求，对于非功能性但关乎到用户体验的需求，更需要关注。这就要求大家在测试时思维更加开放一些，不只局限在功能性的需求上。

那在测试移动App的时候，怎样才能进行用户体验的测试呢？

在这里笔者列出了一些常见的用户体验所要关注的方面，不妨就从这些方面，让我们来看看自己手中测试的App是否达到了要求。

5.1　横竖屏幕测试

在移动设备上做用户体验测试，最容易想到的就是对App做横竖屏幕的测试，来观察App的显示效果。

首先需要被测试的App支持横竖屏。如果App不支持行不行呢？其实也是可以的，但是随着大屏幕手机的流行，连保守的iPhone都发布了5.5英寸屏幕的iPhone 6Plus，可见大屏幕手机是很有吸引力的。用户在操作大屏幕手机的时候，通常选用的都是横屏来使用App的。所以大家就尽量确保App支持横屏操作吧（如图5.3所示）。

图5.3　大量的App都已经支持了横竖屏的显示

其次，要解决横竖屏切换的问题。别看这是个很简单的功能，貌似只要在代码中设置支持横竖屏显示就可以避免横竖屏切换出现问题。但实际上，在某些情况下App代码有可能破坏了屏幕旋转的功能，比如说在App中的某些页面限制了屏幕显示的方向（如图5.4所示）。

图5.4　在图片上我们可以看见App展示内容的方向和设备横屏的方向不一致

除此之外，还需要注意在App中嵌入了WebView的页面的显示。在支持横竖屏切换的App中的页面嵌入了WebView，当WebView读取完成时，有可能横竖屏切换功能就被破坏了（如图5.5所示，游戏中这种弹出页面就破坏了横竖屏的切换）。

图5.5　当把移动设备向右横屏（设备底部在左手边），然后打开App，App本身显示正常。但是当有WebView弹出的时候，页面会反向；而当设备向左横屏的时候，却没有这个问题

值得一提的是，如果App支持显示图表，测试人员更需要关注图表在横竖屏之间的切换，因为横竖屏的显示宽度不一样，图表在不同屏幕状态下，显示的内容和样式很可能也是不一样的（如图5.6所示）。

在测试中，测试人员最好对每个页面都进行横竖屏显示的测试。当然，要更加关注于嵌入WebView和其他弹出式的控件的页面，以及图表这类可能因屏幕宽度和高度不同而改变显示内容和效果的页面。

图5.6　App中同一个图表在横竖屏下显示的内容和样式都有可能是不一样的

对于可以设置横竖屏显示的App，一旦设置了横屏或者竖屏，从启动App开始到关闭App为止，用户所有操作的页面都应该以设置的屏幕显示方向显示，不能出现有些页面横屏，有些页面竖屏这种混杂显示的问题。

5.2　WebView的测试

对于WebView的显示，除了需要关注它对于横竖屏的影响，还需要关注它在不同设备上的显示。因为不同设备会有不同的屏幕宽度和高度，所以WebView的显示效果通常也是千差万别的。比如显示宽度过宽（如图5.7所示），显示宽度过窄（如图5.8所示），或者显示位置太靠下从而导致页面出现很大的空白（如图5.9所示）等。

图5.7　WebView显示宽度过宽，造成有些文字被截断

图5.8　WebView显示宽度过窄，造成显示内容不全

图5.9　WebView显示位置太靠下从而导致页面出现很大的空白

如果是具有特定格式的WebView，在不同设备上的显示效果很可能差异更大，例如图5.10所示表格的显示差异。

图5.10　在手机App中嵌入的WebView显示样式和在Web上是不一样的

如果在嵌入WebView的页面输入文本，可能会出现更多的问题，如图5.11所示。

图5.11　在嵌入的WebView中点击Google搜索栏输入的时候，页面显示会出现问题

通常，开发移动App时想要在App里嵌入WebView，都是基于已经有了产品的Web版本。如果构建移动App的时候能使用已有的功能和资源，会节约开发的成本，降低开发难度。

是的，理论上是这样没错，但是如果在Web端没有做到响应式设计“Responsive Design”（如图5.12所示），在设计Web架构的时候没有考虑到Web端和移动App端功能以及特性的不同，就会造成在桌面端显示正常的Web页面被嵌入移动App之后会出现很多诸如前述的样式显示的问题。

图5.12　响应式设计“Responsive Design”的理念是集中创建页面的图片排版大小，可以智能地根据用户行为以及使用的设备环境（系统平台、屏幕尺寸、屏幕定向等）进行相对应的布局

所以最好不要在移动App中嵌入WebView，而是通过服务器返回信息，由原生代码控制显示的样式，这样可以更好地使用操作系统的特性来避免显示问题。

但是如果想使用WebView的优势，也就是在不改变客户端代码的情况下实现功能和样式的更新时，就要尽量保证在Web端和移动App端都能实现响应式设计（如图5.13所示为iPhone上的App Store从iOS 6升级到iOS 7时的变化）。

图5.13　App Store使用的就是WebView，所以即使设备没有从iOS 6升级到iOS 7，
也可以体验到新版的App Store

5.3　规范与习惯

对于支持多个操作系统平台的移动App，也需要在不同的操作系统上，遵循当前操作系统的设计规范和使用习惯，而不要一味地为了自己各个App的一致性而破坏操作系统的设计规范和使用习惯。

iOS的设计规范要求把菜单放置在设备底端，在记录上从右向左滑动会呼出“删除”和“更多”菜单等（如图5.14所示）。

图5.14　微信iPhone版本一直遵循iOS的操作规范

Android的设计规范则要求把多于3个的菜单放置在右上角3个点的按钮中，而长按记录则可以呼出更多的操作选项等（如图5.15所示）。

不同的操作系统有不同的特性，因此也有自己独特的设计和使用习惯，测试人员在开发和测试移动App的时候，都需要尽可能遵循这些规范，减少用户的学习成本，提高使用App的便利性。

图5.15　Android版本微信在5.2版本的时候从遵循iOS的风格改为Android的设计风格，
可惜在5.4版本的时候又改回到iOS的风格了

5.4　关注用户体验

测试人员不仅需要关注身体健全的用户，也需要关注残障人士。这不仅是人性的关怀，还是很多发达国家，比如美国、澳大利亚、新加坡等国家和地区在法律中有明文规定需要强制执行的。所以不仅为了移动App能顺利发布和避免引起诉讼，而且为了更多的用户能使用我们的App，稍微多花一些开发时间和精力关注用户体验也是非常值得的。

在当前主流的操作系统中，都带有“辅助功能”的选项（如图5.16、图5.17和图5.18所示）。

图5.16　iOS 8自带的“辅助功能”选项。更多iOS上的“辅助功能”可以参看
https://www.Apple.com/cn/accessibility/ios/

图5.17　Android 5.0自带的“辅助功能”选项。更多Android上的“辅助功能”可以参看
https://developer.android.com/guide/topics/ui/accessibility/index.html

图5.18　不少Android厂商也对“辅助功能”做了增强，例如图中所示的三星Galaxy上的TouchWiz

在这些辅助功能中，测试人员可以重点测试“放大字体”、“反色”、“放大”和“文字转语音”/“VoiceOver”这些功能。

比如，在测试视力不好的用户经常使用的放大字体的功能时，需要保证在更大字体的显示设置下，App不会出现界面显示不全，文字模糊等问题（如图5.19所示）。

图5.19　字体放大后文字可能显示不全，如图片中部的“Headphones and audio effects”

还有当测试人员在测试听力残障的用户常使用的“文字转语音”/“VoiceOver”功能时，需要检查App是否提供了完整的备用文本Alt Text，以便这些功能可以给用户读出页面信息，并且能够正常使用按钮等功能。当然还需要测试这些功能的朗读质量，比如有没有不连续的现象等（5.4版本的微信iOS版就存在朗读不流畅的问题）。

5.5　其他需要关注的用户体验的小细节

（1）在不同颜色的背景下，状态栏的显示是否正常。不仅iOS 7，而且Android 4.4都开始支持沉浸式状态栏，所以如果App支持这些平台，就需要注意测试在App不同颜色的页面上，状态栏的颜色显示是否正常，是否做到了沉浸式设计（如图5.20所示）。

图5.20　iOS从iOS 7开始支持沉浸式状态栏设计，我们可以通过和iOS 6的对比明显看出区别

（2）当用户快速点击App中的按钮等可操作控件时，会出现什么样的效果？相信很多经验丰富的测试人员看到这里都会会心一笑，因为这是在桌面软件测试和Web测试时的一个小技巧，现在在移动App测试中也是同样适用的。使用这个测试技巧的目的在于，当用户在App中进行不必要的多次操作时，应确保App避免对这些重复的多次操作作出响应。当然，有一种情况例外，如果App具有多次点击操作的特性时（比如说各类游戏中的点击操作），App当然需要允许这些操作。

（3）对于不支持多点触摸的App，也需要测试App对于多点触摸的支持。读者可能觉得疑惑，不是明明App不支持多点触摸吗，为什么还需要测试呢？答案是，我们不能限制真实用户是怎么使用App的，只能模仿真实用户对App多点触摸的支持进行测试，尤其是对于游戏类App的测试（如图5.21所示为iPad上的GarageBand）。

图5.21　iPad上的GarageBand支持多点触摸的特性

虽然这章介绍的知识都比较细碎，但是用户体验就是在细节上才能体现出App的质量和对用户的重视程度，而且界面也是用户最容易关注到的地方，所以测试人员在测试中一定不能忽视这些细节。