打造企业级移动测试云平台

背景

移动技术发展到现阶段,原生、混合式技术发展的足够成熟,可以无缝融合。而随着移动技术的发展和革新,移动领域的测试技术和实践也有了一定发展:工具不再像早期一样几家独大,选择性越来越多;从浅尝辄止的实验阶段到真实项目中的自动化测试落地。这些实践在一定程度上提升了测试反馈效率,在迭代交付的过程中出色的完成了质量保证的工作,但在相对漫长的实践过程中,我们依然可以总结一些痛点:

1、移动自动化测试的执行效率远不及Web应用

有过Web自动化测试经验的同学对于Selenium肯定不会陌生,Web端的并发测试使得测试在有限资源的情况下按照我们的期望并发执行。而且由于keychain等问题,很难在测试用例之间做到互不影响、对于测试环境的清理和准备也有很大难度。

2、很难全面覆盖繁杂的测试设备

Web自动化测试关注的测试环境相对单纯,针对不同项目、产品和市场,无非是对不同的浏览器和操作系统有不同程度的支持。而对于不同浏览器也有不同的driver来支持。而在移动测试中,很难做到对众多厂商和不同操作系统设备进行模拟。

3、移动自动化框架很难支持到回归测试颗粒度

在移动端(以iOS为例),受限于Apple的机制,大部分框架很难覆盖到与iOS系统/第三方App交互的场景,例如系统通知跳转、实时通讯应用信息发送等场景。而若无法覆盖核心功能,那么自动化测试的落地实则是在给自己和团队挖坑,得不偿失。

这些问题在随着WebDriverAgent的成熟以及XCode 9的新特性 —— Multiple concurrent simulators的出现,得到了极大程度的解决,我们可以像对Web应用一样,对移动端应用在不同的simulator上并发执行测试用例,极大提升了测试反馈效率。而且,测试人员不再受限从而可以编写覆盖率更高的测试用例。

除了普适性问题之外企业对移动测试方案潜在需求?

在项目的具体实施过程中,除了我们经常被这些普遍存在的细节问题困扰之外,企业或组织级客户已经对移动端自动化测试提出了更高的要求。在一次机会给客户讲解移动端自动化测试趋势时发现,新的框架的确会使客户眼前一亮,但是,在实践上的优势无非是你比其他人先研究了什么,这样的领先微乎其微,在交流过程中观察到客户更大的痛点是:

如何同时覆盖到更多物理设备?如何更好的构建和重用基础设施?如何跨地域高效使用测试资源?

带着这几个问题,我们对比了一些现有的可用方案,例如AWS device farm。Device farm是针对移动App提供的测试服务,用户可以对在AWS托管的基于iOS和Android物理设备测试原生和混合应用。用户既可以使用各种测试框架来做自动化测试,也可以远程访问设备进行应用程序的测试和调试。

但是该解决方案也是有一定局限性的,当测试运行期间同时执行测试的设备最大只有五个,而运行测试的时间也被限制到60分钟。当然上述的限制可以根据需要适当的放松,但是企业和用户不得不承担价值不菲成本。

与AWS device farm类似,SauceLabs和Xamarin也提供类似的平台,那SauceLabs的服务举例,如果想使用无限运行时间,支持24个并发运行设备,模拟器用户需要每月承担3576刀,而如果想使用真实设备进行测试,大概需要每月花费7200刀。这种昂贵的成本对于企业很难承受,而且重要的是这种资源是无法复制,企业不得不持续为云服务支付高昂的费用。

安全性也是企业需要考虑的问题,用户不得不在云测试平台上传自己的IPA或APK。我们当然可以信赖AWS的安全机制。一些对安全性要求较高的企业来说,更想规避这样的风险。

打造私有移动真机测试平台

通过分析,对于客户的需求大概涵盖几点:真实设备、并发、成本、安全、可重用。鉴于这些需求,我们把目标进行拆分:

1.设备管理——服务发现与注册

在该实例中我们使用WebDriverAgent作为测试框架,需要运行在每一个物理设备上,我们可以把这些物理设备当作Agent集群。这些集群设备就是我们运行WebDriverAgent的服务终端,我们可以通过很简单的程序让WebDriverAgent自动在设备上运行。通过服务发现与注册机制,把WebDriverAgent服务注册在通过Ansible管理的Proxy上。而服务发现与注册不单单解决了复杂的设备管理,而且可以解决分布式团队合作时设备跨地域有效利用的问题。

2.平台数据可视化

对于一个测试平台来说,如何把所有可用的服务(机器)、服务状态、自动重启和crash报告等数据可视化给企业终端用户,是极为重要的。那老牌Apache zookeeper来说,提供了友好的服务可视化管理功能并且可以根据用户需求进行二次开发。重要的是,这些底层基础设施服务可以在之后的任何一个移动测试项目中被重用。

3.自动化测试运行和报告生成

自动化测试平台虽然提供了强大的服务(设备)管理、服务可视化等功能。而自动化测试的核心需求依然是如何保障测试的独立性、稳定性、易维护性、重用性和覆盖率。通过WebDriverAgent跨语言测试框架,我们可以像架构Web自动化测试一样来开发针对移动端的测试工程。但需要注意的是移动测试不同的是真实物理设备,而不是计算机的某个进程。另外,如何接触测试场景的相互依赖、保证测试间的独立性,以及如何清理测试环境,需要大家在进行移动端架构的时候事先考虑。

这样一来,我们如果可以解决这三个问题,就可以不受昂贵的成本限制,为企业量身定做适合自己的业务规模的移动测试私有云了,不但为企业和组织机构构建了大型测试服务平台,同时也解决了之前提到的普适性问题。

总结

随着DevOps的发展,软件工程的开发、部署、上线、应急预案等都被自动化监控和处理。如果我们依然停留在“成熟”的解决方案而缺少思考,那么留给QA/测试人员的发展空间越来越少。

我们需要通过对测试技术细节的不断归纳、对比和练习,抓住领域发展趋势和真正的客户诉求,结合其他非测试技术,帮助自己在测试技能上有所突破,同时帮助自己提升构思和落地解决方案的能力。


更多精彩洞见,请关注微信公众号:思特沃克

Share

移动App测试的22条军规之“确定设备和平台再动手”

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

第一章

1军规:确定设备和平台再

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

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

  1. app的特性
    1. 如果app是针对心率监测,指纹识别,NFC(近场通信),红外线操控这些需要特殊传感器设计的,那对测试设备和平台的选择就相对少一些,只需要考虑那些拥有这些传感器的设备。 例如对于支持指纹识别的app,测试人员需要考虑的设备也就是iPhone 5siPhone 6iPhone 6PlusiPad Air2iPad mini3LG G3,三星Galaxy S5,三星Galaxy Note4HTC One Max,华为Mate7这些设备(不考虑市场占有率比较低的vivoOPPO的手机);而如果app支持心率监测, 测试人员就只能选择三星Galaxy S5Galaxy Note4了。

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

样章-1

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

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

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

样章-2

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

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

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

样章-3

1.3 - 截止201515日,iOS各版本所占比例

样章-4

1.4 - 截止201515日,Android各版本所占比例

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

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

样章-5

1.5 Google Analytics

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

样章-6

1.6 Omniture SiteCatalyst

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

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

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

1.7 - 双手持握设备的方式

而对于45寸这种可以单手持握的设备,如果app无论横纵向显示,按钮都最好不要放在屏幕四个角,以免用户很难点击(如图1.8所示)。

样章-8

1.8 单手操作范围。

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

    1. 分辨率:分辨率的大小会决定显示内容的多少,这对显示图片和视频时会有一定的影响(如图1.9所示)。样章-9

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

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

样章-10

1.10 魅族MX4的的屏幕比例

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

1.11 retinaretina的文字显示

样章-12

1.12 -非retinaretina的图片显示

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

样章-13

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

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

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

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

设计表格的过程中,测试人员还需要注意两点:

  1. 操作系的小版本升一般只是修复缺陷,不会引入新的功能,例如iOS8.0.1升级到8.0.2,以及Android4.4.1升级到4.4.4。这时,如果不是app恰好被这些缺陷修复所影响,测试人员不需要考虑覆盖这些小版本。至于中间版本的升级,例如从iOS 8.0.2升级到8.1,以及Android4.1升级到4.4,这时需要考察变动对app的影响,决定是否测试覆盖相应版本。就拿Android 4.14.4来说,因为Android 4.44.1新增了ART运行环境,所以针对这一点,测试人员需要准备设备安装Android 4.4,而不是仅仅在安装有Android 4.1的设备上测试。至于操作系统大的版本升级,就必须要进行测试覆盖了。
  1. 随着操作系统升级,既有的设备可能无法流畅地运行新的操作系统时,测试人员就需要考虑是不是还继续在新的操作系统上测试这些设备。比如,iPhone 4在升级iOS 7之后运行速度变得很慢,各种操作的延迟都会很长,固然有一部分用户还是强忍着会继续使用,但是很多用户会放弃在新的操作系统上使用运行很慢的老旧设备。当新的操作系统升级时,甚至有些旧的设备就不会被支持了,例如iOS 8就不再支持iPhone 4 。这时候如果确定这些旧的设备上的操作系统占比很小的话,测试人员就可以果断放弃这些设备。

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

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

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

Share