移动 app 云测试平台的对比与分析

文章作者/配图来自ThoughtWorks:黄勇,未经允许,谢绝转载。

我们都知道在测试移动app时最耗时的是在各种测试设备进行测试, 因为不论是安卓还是iOS都已经碎片化了。而云测试看似是解决这一问题的有效途径。因此选择哪种云测试平台来协助测试人员进行各种测试就成为首要问题。

我们先来看看云测试平台通常都提供哪些功能和服务。

主流的云测试平台都支持对原生native,混合hybrid和Web app的测试,这些测试包括:

  1. 兼容测试。通过在多种测试设备上安装/卸载和运行被测app,遍历app的每个界面,主要检查app是否会报错或者崩溃。有些云测试平台还会对每个页面进行截图并进行对比。
  2. 脚本测试通过运行云测试平台工具进行录制的或者使用自动化测试框架编写的自动化脚本,实现模拟用户操作的目的,并且减少手动测试时间。
  3. 性能监控和分析利用Android SDK提供的借口,云测试平台可以检测移动app的耗电量,CPU等资源占用率,使用的流量等信息。有些云测试平台还提供自己的SDK,整合在app中可以提供更为准确的性能指标和信息,包括线上app的性能信息以及崩溃信息等。
  4. 手动测试和人工测试云测试平台的手动测试是指租用云测试平台的特定设备,测试人员手动登录设备进行测试。

    而人工测试则是将测试需求告知云测试平台的专业测试人员,雇佣他们临时作为自己的测试人员进行测试。

  5. 持续集成不少提供脚本测试的云测试平台都同时提供对持续集成(Continuous Integration)环境的支持。

此外不少国内云测试平台还提供以下功能:

  • 安全测试
  • 内测托管分发
  • 众包测试

我们再来看看各种云测试平台对于上述功能和服务的支持情况。

由于国内外的云测试平台使用环境等因素的不同,我们分别对国内外主流的几个云测试平台进行对比。

国外主流的云测试平台:
  • Xamarin Test Cloud (https://xamarin.com/test-cloud/)
  • TestDroid (http://testdroid.com/)
  • Sauce Labs (https://saucelabs.com/mobile/)
  • Google Cloud Test Cloud (https://developers.google.com/cloud-test-lab/)
  • AWS Device Farm (https://aws.amazon.com/device-farm/)

TestCloud-Foreign图1 - 国外主流的云测试平台对比

从上图我们可以看到一些特点:

  1. 在测试设备的数量上,Xamarin Test Cloud和Sauce Labs都是非常有优势的,虽然Xamarin Test Cloud统计的是测试设备的数量,而Sauce Labs是平台的数量;
  2. 亚马逊自己的FireOS只被自己的云测试平台支持,在国内我们也能看到类似的例子;
  3. 所有的云测试平台都支持app测试,但是只有TestDroid支持游戏测试;
  4. 对于国内云测试平台提供的人工测试,安全测试,内测分发和众包测试,国外这些云测试平台都是不支持的,需要结合别的工具和框架进行使用。不过对于手动测试,Sauce Labs和Perfecto这两个云测试平台支持租用测试设备进行手动测试;
  5. 对于云测试基础功能的兼容测试,以及脚本测试,崩溃分析和持续集成,这些云测试平台都是支持的;
  6. 只有Xamarin Test Cloud,TestDroid和AWS Device Farm支持性能监控;
  7. 对于脚本测试所使用的移动app自动化测试框架,每个平台都不甚相同:
    • Xamarin Test Cloud支持Calabash(iOS和Android)和自己的Xamarin.UITest;
    • TestDroid支持很多框架,包括支持iOS的Calabash,appium,UI Automation和 Jasmine,以及支持Android的Calabash,appium,Espresso,Robotium和uiautomator;
    • Sauce Labs支持自己的开源框架appium;
    • Google Cloud Test Lab则支持Espresso,Robotium和Robo test;
    • AWS Device Farm也支持很多框架,包括支持iOS的Calabash,appium,UIAutomation和XCTest,以及支持Android的Calabash,appium,JUnit,Espresso,Robotium和uiautomator。
  8. Xamarin Test Cloud,TestDroid和Sauce Labs都有自己的移动app测试脚本录制工具,分别是:Xamarin Test Recorder,TestDroid Recorder和appium inspector。

综合来看,对于国外的云测试平台,如果侧重的是测试设备的覆盖程度,选择Xamarin Test Cloud和Sauce Labs会更合适;如果需要测试FireOS设备,那就选择AWS Device Farm;如果侧重的是脚本测试中支持的语言和框架,那就可以选择TestDroid和AWS Device Farm;如果是进行游戏测试,只能选择TestDroid;如果要远程连接测试设备进行手动测试,那就需要选择Sauce Labs和Perfecto;如果在测试过程中需要同步监测性能,就不能选择Sauce Labs和Google Cloud Test Lab。

国内主流的云测试平台:
  • Testin云测 (http://www.testin.cn/)
  • 百度MTC (http://mtc.baidu.com/)
  • 腾讯优测 (http://utest.qq.com/)
  • 阿里MQC (http://mqc.aliyun.com/)

TestCloud-Domastic图2 - 国内主流的云测试平台对比

从上图我们也可以看到一些特点:

  1. Testin云测支持的测试设备数量最多,达到了600部Android和70部iOS终端的数量;但是和Xamarin Test Cloud以及Sauce Labs支持的设备数量还是有不少差距的;
  2. 和亚马逊类似,阿里的YunOS也只有阿里MQC才能支持;
  3. 和国外的云测试平台很类似,这四个国内云测试平台也都支持app的云测试,而不支持游戏测试;只有Testin云测支持游戏测试;
  4. 对于云测试基础功能的兼容测试,国内主流云测试平台都是支持的;
  5. 这四个国内云测试平台也都支持崩溃分析,不过对于性能监控,却只有百度MTC支持,而且百度MTC的深度性能测试中还可以做竞品app的性能对比;
  6. Testin云测和百度MTC不支持手动测试;
  7. 只有阿里MQC不支持人工测试;
  8. 只有Testin云测不支持安全测试;对于支持安全测试的云测试平台,也没有公布是如何进行安全测试的;
  9. Testin云测支持内测分发和众包测试,阿里MQC支持众包测试,其它两个云测试平台对于内测分发和众包测试都不支持;
  10. 对于脚本测试,只有腾讯优测不支持;而对于测试工具和框架,各个平台的支持也不相同:
    • Testin云测支持Robotium,JUnit,淘宝的Athrun和Testin SDK,其中只有Testin SDK支持iOS和Android,其他框架都只支持Android;
    • 百度MTC只支持通过自己的测试脚本录制工具录制的脚本;
    • 阿里MQC支持Robotium和增强后的appium,其中appium可以支持iOS和Android;
  11. Testin云测,百度MTC和阿里MQC都提供了自己的测试脚本录制工具,分别是itestin录制回放工具,百度MTC录制回放工具和易测;
  12. 国内云测试平台都没有提及持续集成,不过从笔者的了解看来,Testin云测和阿里MQC应该是都支持的。

对于国内云测试平台,如果需要覆盖更多的测试设备或者需要测试游戏亦或需要内测分发,只能选择Testin云测;如果需要测试YunOS设备,那就需要选择阿里MQC;如果需要进行性能监控和竞品对比,那就选择百度MTC;如果要远程连接测试设备进行手动测试,那就需要选择腾讯优测和阿里MQC;如果需要雇佣云测试平台的专业测试人员,就不能选择阿里MQC;如果需要进行安全测试,就不能选择Testin云测;如果需要进行众包测试,那就选择Testin云测和阿里MQC;如果要进行脚本测试,就不能选择腾讯优测,对于百度MTC也不推荐。

相信通过对比这些云测试平台提供的功能和服务,以及它们各自的特点,读者在选用云测试平台时有了更多的依据。希望大家在使用这些信息作为依据时,综合考虑这些云测试平台的特点,同时可以使用它们提供的免费试用进行尝试,以便验证是否真的适合自己的app。

P.S.以上云测试平台提供的功能及服务,截止于2016年3月20日。

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