（ThoughtWorks洞见网站 获人民邮电出版社和作者授权连载本书部分章节。任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。）

第一章

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

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

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

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）。

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

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

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

图1.2 － 2014年第四季度各操作系统市场占有率调查表（数据来源： www.netmarketshare.com ）

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

2. 移动app的生命周期

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

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

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

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

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

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

图1.5 Google Analytics

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

图1.6 Omniture SiteCatalyst

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

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

2. 设备的硬件参数

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

图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.13的表格。

图1.13 － 测试设备和操作系统版本对照表

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

可以看到，对于同一种设备（图1.13中的iPhone 5s），由于市场占有率大，而且支持多个操作系统版本，所以在iPhone 5s上需要测试iOS 7.1和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和4.4来说，因为Android 4.4比4.1新增了ART运行环境，所以针对这一点，测试人员需要准备设备安装Android 4.4，而不是仅仅在安装有Android 4.1的设备上测试。至于操作系统大的版本升级，就必须要进行测试覆盖了。

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

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

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

购买本书请点击链接：http://item.jd.com/11730286.html