作者：黄勇
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
移动App测试的22条军规试读：
前言
随着这几年智能设备的大规模普及，越来越多的人开始使用智能手机和平板电脑，因此，移动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。编辑联系邮箱为：zhangtao@ptpress.com.cn。
本书可以作为测试初学者阅读，可以帮助读者快速融入测试行业，并全面了解和掌握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年第四季度各操作系统市场占有率调查表（数据来源：www.netmarketshare.com）（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 测试设备和操作系统版本对照表SOSOS VersionCategorModelManufacturNyer00AppleiOS7.1iPhone5s100AppleiOS8.1iPhone5s200AppleiOS8.0.2iPhone6300AppleiOS8.1iPhone6Plus400AppleiOS8.0.2iPadAiir2500AppleiOS8.1iPadmini600Android4.1PhoneOne XLHTC700Xperia ZSonyAndroid4.2Phone800Galaxy S3SamsungAndroid4.2Phone901Galaxy S5SamsungAndroid4.4.2Phone0onGoogleAndroid4.4.4PhoneNexus501Galaxy Tab3 10.1SamsungAndroid4.2.2Tablet201GoogleAndroid4.3TabletNexus7 II3
设计测试设备和操作系统版本对照表的原则是：让不同分辨率、不同屏幕尺寸大小的设备尽可能多地涵盖各个操作系统版本，另外，对于市场占有率很高的重点操作系统版本，可以使用多个设备来测试。
可以看到，对于同一种设备（如图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。这时候如果确定这些旧的设备上的操作系统占比很小的话，测试人员就可以果断放弃这些设备。
所以测试人员需要从设备角度出发决定要测试的操作系统，以及从操作系统出发决定要测试的设备这两方面来考虑测试设备和操作系统版本对照表的制定。
明确了测试设备和操作系统版本，下面我们就来了解下在设计测试场景和用例中可以运用哪些具体的军规。军规2“移动”测试
当App上线之后，我们可以通过各种途径得到用户的反馈。有些时候我们会很纳闷，用户说有问题的功能，明明是我们重点测试过的，怎么可能还会有问题呢？是不是用户打开的姿势不对？
这时候很可能我们已经陷入了一个误区，觉得我们是按照用户的使用习惯来测试的，用户在使用中不可能出现这样的问题。但是我们忽略了用户使用App时的场景，也就是环境对App的影响。
相对于桌面应用，移动App最大的特点就在于移动性。用户在任何时间任何地点都可以打开App使用，这意味着App对于不同网络，以及网络变化的情况都能进行处理。
图2.1展示了iPhone上支持的网络种类。测试人员并非对于每一种网络都需要测试，如何确定需要测试的网络，取决于App在网络上获取什么样的信息。图2.1 iOS上不同的网络状态图标（1）如果App只是通过网络访问服务器，那需要考虑的主要就是高速和低速网络之间的差别。因此只要测试Wi-Fi、3G/4G/LTE、EDGE/GPRS以及飞行模式就可以了。
为什么需要单独测试飞行模式呢？因为对于联网的App，不仅需要考虑到有网络环境中用户的使用，在无网络的情况下也要保证App不会出错，例如App崩溃等。
当App需要大数据量传输数据时，很可能需要把3G和4G/LTE的测试分开，充分模拟真实用户使用的场景。（2）如果App需要在不同的网络环境里得到认证信息，例如移动运营商的信令，那测试人员就需要对于不同的信令获取方式进行单独的测试分类了。比如说，如果App在4G/LTE的环境下进行的验证方式不同于3G环境，就不能把这两种网络状态当成一种情况来进行测试，而是要分别进行测试。
哇，这么多种网络环境，怎么进行测试啊？需要买这么多种SIM卡吗？不对啊，EDGE和GPRS可没有对应的SIM卡，现在什么SIM卡能支持这两种网络啊！是这两种网络环境一定要一起测试吗？或者需要专门的设备来测试？
其实，我们大可不必为网络环境而忧心忡忡，因为在程序开发和自动化测试中可以使用Mock技术。通过使用Mock可以从服务器端返回一般需要真实网络环境才能得到的response应答，这样App就可以直接处理信息，而不用非得连接到真实的网络环境或者是非得处于特定的状态下了。使用Mock这种方式减少了在开发和测试过程中由于需要真实环境而对于网络、设备和资源的投入。
那具体如何使用Mock技术呢？（1）对于不用在网络上获取信令Token的App，可以直接在代码里对App包进行标记，比如打上测试的标签，并且在向服务器发送请求的时候带上这个标签，这样服务器就可以根据这个测试的标签，判断出客户端是测试的App，从而对网络环境进行模拟并运行对应的Mock代码，延迟把产生的应答response发送回App，这样就可以模拟低网速下的网络环境了。另外，可以通过控制延迟时间的多少，模拟真实环境中不同网络速度的网络状况。（2）对于需要在网络上获取信令的App，基本过程和上述一致，只是需要在Mock代码中添加生成信令的代码，从而使服务器在返回应答时把信令告知客户端，从而绕过真实环境中的网络验证环节。
如果你还有疑问，猜想开发人员会不会因为增加了工作量而不同意做这些工作呢，那么大可放心，因为这些工作只是一次性的环境准备工作，对于整个团队来说都是必要的。开发人员也更希望在编码的时候就确保App能应对各种网络环境，而不用等出现了缺陷，花了很大力气之后才发现是网络环境的影响，而且还要得东奔西走，找不同的网络来验证修复；另外，业务分析人员也需要在不同的网络环境下设计用户的体验和交互方式。
目前也有不少工具可以帮我们快速搭建Mock环境，例如Mountebank、Charles、Apple Network Link Conditioner和moco。笔者比较常用的是moco，不仅是因为moco是2013年Oracle Duke’s Choice获奖作品，而且因为moco搭建简单，如果App不涉及获取信令的验证，以及与其他Service的集成，测试人员按照说明手册自己搭建一个Mock环境也是很快的。这样测试人员还可以参与后期Mock环境的维护，确保Mock的真实性和准确性（如图2.2所示）。
下面先简单介绍一下如何快速搭建moco环境（以Mac OS X为例）。（1）首先下载moco的独立运行的jar文件（地址如下）。http://repo1.maven.org/maven2/com/github/dreamhead/moco-runner/0.9.2/moco-runner-0.9.2-standalone.jar（2）打开任何一个文本编辑器，比如说Sublime Text。（3）输入以下的内容，这些内容将作为moco的配置文件，在moco运行时被读取；这些配置文件的作用，是用来向客户端返回被Mock过的服务器的response（如图2.3所示）。[ { "response" : { "text" : "Hi，移动App测试的22条军规的读者" } }]图2.2 配置文件中设置的response以及从页面中看到的结果图2.3 设置moco配置文件内容（4）保存成文件，并命名为“22rules”，并放置于moco jar文件所在的同一目录下（如图2.4所示）。图2.4 把保存的“22rules”和moco jar文件放在同一文件夹下（比如“workspace”）（5）在命令行工具，如“Terminal”下打开“workspace”这个文件夹。（6）输入命令“（java -jar moco-runner-0.9.2-standalone.jar start -p 12306 -c 22rules）”来启动moco，以下是moco的运行提示（如图2.5所示）。图2.5 moco运行后的提示信息（7）在浏览器中打开http://localhost:12306/就可以看到网页上显示之前在“22rules”里设置的信息：“Hi，移动App测试的22条军规的读者”（如图2.6所示）。图2.6 在浏览器中能看到之前在moco配置文件中输入的内容（8）当然，真实的场景不会这么简单，特定的请求request需要不同的response。这时就需要对moco配置文件改成如下内容（如图2.7所示）。[{ "response" : { "text" : "Hi，移动App测试的22条军规的读者" } }, { "request" : { "uri" : "/22" }, "response" : { "text" : "我是特定的response" } }]图2.7 对特定的请求request设置特定的应答response（9）打开http://localhost:12306/22查看结果，会发现针对不同的请求request，返回的response也是不一样的（如图2.8所示）。图2.8 特定的请求request返回特定的应答response（10）如果多个配置文件需要一起读取，那怎么办呢？这时就需要多个配置文件。下面来创建另外两个配置文件“another”和“combined”，它们的内容如下（如图2.9和图2.10所示）。“another”配置文件的内容如下。[ { "request" : { "uri" : "/another" }, "response" : { "text" : "我是另一个特定的response" } }]图2.9 “another”配置文件的内容图2.10 “combined”配置文件的内容“combined”配置文件的内容如下。[ { "include" : "22rules" }, { "include" : "another" }]（11）这两个配置文件也需要和之前的“22rules”以及moco jar文件在同一文件夹下（如图2.11所示）。图2.11 所有文件都需要放置在同一文件夹下（12）在命令行（“Terminal”）里运行“（java -jar moco-runner-0.9.2-standalone.jar start -p 12306 -g combined）”（如图2.12所示）。图2.12 moco读取多个配置文件运行后的提示信息（13）再次打开http://localhost:12306/，http://localhost:12306/22，以及http://localhost: 12306/another来查看同时支持多个不同配置文件的运行效果（如图2.13所示）。图2.13 moco同时支持多个配置文件的读取和运行（14）关于更多的moco的进阶使用和配置，请参考GitHub上moco的文档。
当然，有些特殊的网络环境我们是没有办法很容易地进行模拟的，例如前几年2G SIM卡的cmwap会抛弃一些http自定义头，现在的移动3G SIM卡丢包率很高等场景。对于这些场景的测试，我们还是需要使用真实的SIM卡，在手机等设备上进行测试。
现在让我们回到本章最开始的那个问题，你可能会说，我都按照你所说的在不同的网络状态下进行了测试了，可是用户还是会在执行过测试的那些场景发现我们没有发现的bug，这是为什么呢？
好，让我们再想一想测试人员所在的测试场景和用户的使用场景有什么不同呢？用户都是在什么样的环境中使用呢？咦，用户好像是不会像测试人员一样一直在办公桌前，在网络环境很好很稳定的区域使用App的！
没错，测试人员测试的仅仅是在特定的网络环境下App的表现，在网络切换的时候，App会如何处理测试人员是完全不清楚的。所以不要以为App在不同网络环境下表现正常，在网络切换的时候就不会有问题。下面还是拿需要在网络上验证信息取得信令的App来做例子（如图2.14所示）。
试想在App使用过程中需要在3G/4G网络上取得SIM卡注册后的信令，通过这个信令用户可以直接进行支付和延长合约等操作；在无线网络或者无网络的情况下，因为不验证SIM卡注册信息，所以无法进行相应的操作。但是当用户从一个有3G/4G信号的地点移动到一个没有信号（或者有无线网络连接）的地点，如果App处理不好，就会出现虽然App拿到了信令，相应的菜单显示可用，但是实际用户不仅无法成功操作，甚至还会出现异常的信息提示。
再试想一下，如果App具有支付功能，在网络不好的情况下，用户支付了订单，突然网络中断，用户的订单信息还是未完成，但钱已经从用户账户上支出了，这就不是一个小的问题了。相对而言，对于银行类的App，如果用户在网络不好的情况下支取了资金，但是用户账面金额并没有相应地扣除，银行损失的就不会是一笔小钱了。
对于网络异常的提示信息也需要人性化的设计，只告诉用户“HTTP 500 Internal Error”这样的消息对用户来说不仅没有任何帮助，反而会加剧用户的挫败感和不满情绪。图2.15就展示了这种不恰当的错误提示信息的真实场景。图2.14 获取移动网络信令App的结构示例图2.15 不恰当的错误提示信息
在网络出现异常，程序无法进一步处理的情况时，App应该明确告诉用户应该怎么操作，例如在网络连接不上的时候告知用户：“网络无连接，请稍后再试。”或者在网速很慢的时候提示用户：“当前网速很慢，可能会影响您的体验。”
而在后台，则需要定时刷新，避免在网络恢复的时候，App依旧显示网络异常时的提示信息，也避免用户需要不停手动刷新。当然，在多次尝试失败之后，可以放弃刷新尝试，改为让用户手动刷新来减少对于网络流量和电量的消耗。
对于视频播放类App，也需要验证在网络进行切换，比如Wi-Fi切换到4G或者3G网络时，对应播放的视频清晰度是否也会进行对应的切换。
当然，毕竟任何模拟都是替代方案，为了能模拟真实的网络环境和网络切换，走出去，“移动着”测试不失为一个选择。在真实环境的测试过程中，测试人员也会注意到更多之前忽略的用户使用的小细节。让我们在移动App测试的时候“动”起来吧！军规3关注多任务和意外情况处理
想必我们都有过这样的体验：在购物的App中填写信息，比如说收货地址的时候，忘记了具体地址，然后切换出该App到“印象笔记”之类的记录App中查找到地址，复制下来，再切换回购物App的时候发现，刚才填写的好多信息都没有了，还得手动输入一遍，这样就会觉得App的功能和体验很差。
这种情况其实就是没有处理好多任务时App的表现。
不同于功能机的时代，在使用智能手机的时候，经常会同时运行多个程序（如图3.1所示），这就要求测试人员在设计和测试App的时候考虑到App被别的程序或者用户切换到后台时，需要进行什么操作。图3.1 iOS的多任务处理3.1 第一个场景
一个典型的场景就是，App在使用过程中用户接听一个来电，App应该如何处理（如图3.2所示）。
试读结束[说明：试读内容隐藏了图片]