移动测试策略

  Kiran Rayachoti是Sapient公司的一名高级管理程序经理。他有10多年 QA规章、流程、方法、测试自动化性能测试及商业验收测试方面的丰富经验。起初他是干开发的,后来转入了不同领域,如:售前,程序管理和QA。他要定下测试系统的架构,获取后融合系统,管理人,改善流程并改变管理,项目管理,数据驱动的决策,并为TCoE制定最佳做法。为了主要顾客,Kiran成功与各地大型团队一起执行了QA功能,为运输、电子商务、CMS和ERP顾客进行QA流程/自动化测试端到端工作。他在TCoE以前还是一家小型初创公司时就是其中的一员,更早的时候甚至是他创建了TCoE。Kiran最近在为一个大型的数百万的零售项目(该项目涵盖了移动web和apps)管理整个QA程序功能。他是QA论坛中积极的一员,并在QA策略和自动化方法方面提出了白皮书,发起了研讨会。

?

  我在IT这一行干了10多年了,大部分时间都放在质量保证上了,其中包括的测试类型有:手动、自动化、性能、移动测试,当然在创建TCoE上也费了我不少精力。也因此,我可以看到移动测试所呈现的一堆完全不同的挑战,以及一个人必须采用的成功实施移动测试的策略。下面就是我的完整的测试移动app的经验,包括用各种工具进行的各种测试。
   用于移动设备的企业app涵盖了前所未有的工作领域。许多电脑桌面app现在被用在移动设备上了。移动app正被开发成和PC端app一样灵敏可靠。为了应对这一挑战,移动app测试已演变为一种独立的测试。
   本文中,我列出了移动业务app测试中所特有的挑战,并简要阐释了重要的成功要素,移动工具,以及移动app的手工、功能、自动化性能测试的方法。

  移动环境的发展
   如果说移动app的使用在蓬勃发展,或许太过轻描淡写了。2010年,移动app商店记录:大概总销售有62亿,其中45亿来自app下载。到2013年,一些分析师预计移动app盈利将超过210亿。如图1所示,相较于15亿电视,14亿信用卡,13亿固定电话,9亿PC和8亿汽车,移动app已是世界上最常用的技术设备了。

图1. 移动设备拥有量(较于其他技术设备的拥有量)

  现今,全世界有37.5亿移动设备购买者,14.5亿移动设备用户会买两至三只手机。所以全世界总共有52亿次移动设备购买。2010年,移动语音通话大约增长了2%(有6250亿),而移动数据账户大约增长了17%(有2950亿)。

 移动app现状
   移动app包括:移动web和移动app。移动web是一个典型的常用网页,适用于小屏移动设备。其功能往往比移动app的更有限。而移动app则是在移动设备上下载并运行的app。移动app比起移动web有更快的速度和更高的性能;也能提供更广泛的功能和容量。例如,用亚马逊移动web,你可以在你的移动设备上进行在线购物,用Facebook,你可以用你的移动设备在别人的空间墙上留言。图2左下角展示了移动web一个例子(亚马逊),右边是移动app快捷方式的一些例子(Facebook,美国银行,Skype等)。

图2. 一个移动web和一些移动app快捷方式

  移动测试中的巨大挑战
   不像PC环境,移动环境里各种硬件和软件配置的设备过多且通信很复杂。这就使得移动web测试和移动app测试比PC的web测试和app测试更复杂;在许多不同的设备和模型上测试相当耗时耗钱。移动测试中的其他挑战如下所示:
   ??因为移动设备和模型的显示屏尺寸和分辨率种类太多,图像的绘制和定位范围也很广。 
   ??当app在网络边界上通信时,网络延迟将不可预测。 
   ??真机测试允许测试员验证设备LCD上所显示的“看起来正确”的事物,但却几乎无法获取任何不同于真机LCD上所显示的诊断信息。 
   ??对于多数性能问题(比如页面加载慢),用真机测试无法提供解决问题所需的具体的根本原因分析 
   ??用真实设备,测试员就不可能知道URL重定向/网页内部文本上下文。 
   ??在真实设备上无缝地进行测试自动化是不可行的。

  移动测试的方法和工具
   为了有效测试移动web和app,就需要仿真器、模拟器和真机。必须组合使用仿真器、模拟器、工具和真机。让我们看看需要关注的移动web和app的测试种类。
   ??可用性测试 
   ??功能测试——手动 
   ??用户体验测试 
   ??回归测试——自动 
   ??可达性和安全性测试 
   ??性能测试 
   所有移动测试都围绕着仿真器、工具和设备。因此,让我们深入了解一下什么是仿真器和模拟器吧!

 仿真器(Emulators)
   仿真器是有真实移动设备的硬件复制。仿真器模拟移动设备并确保测试员可以在PC上测试移动app而无需在真实移动设备上测试。
   下面有三种仿真器:
   ??设备仿真器一般由设备制造商提供。设备仿真器是针对特定设备模式的。
   ??操作系统(OS)仿真器是微软和谷歌为其各自的操作系统所提供的。OS仿真器在PC上为设备模拟特定操作系统并运行。OS仿真器通常依赖于用来模拟移动环境的构建工具;比如,Xcode是一个iPhone构建工具,Eclipse Emulator是Android构建工具。
   ??浏览器仿真器一般相应的设备网站上都有;它们在浏览器上运行,并不一定要是移动设备(也就是说,它们可以在PC浏览器上运行)。网上有大量开源仿真器,如iPhone的MobiOne以及Android 的Android Emulator 1.5 PC。
   用仿真器测试的一大优势是:仿真器会让你准确了解设备LCD“后”究竟在发生什么,这可以让测试员调试并真正地打开屏幕看看里面在发生什么,让测试员可以深入洞察问题且让开发员更轻松地修复缺陷。测试员也可以为开发员提供快捷方式,高级信息和数据报文。这就减少了部分开发团队花在解决问题上的精力。以  下使用仿真器的其他益处:
   ??仿真器往往很划算,因为它们多数是免费的。
   ??因为虚拟设备(仿真器)是在其软件堆控制之下的,测试员可以收集关于内容页面的“每个要素”的重要信息,包括内部文本和网页直接链接。
   ??可以精准迅速地进行多种内容的相容性测试——如验证图片尺寸或确定损坏的链接。

  模拟器(Simulators)
   设备模拟器是特定设备的硬件复件,模拟器为了测试而模拟设备的软件。测试员通常使用PC的本地浏览器来进行移动浏览器模拟。(注意:模拟器是用于测试移动web的,不是移动app。)为了获得一个本地浏览器进行模拟,测试员要在本地浏览器里更改“用户代理”设置。该方法通常用于自动化功能测试。
   有了模拟器,无需使用仿真器就能快速轻松地完成测试。 另外,模拟器很划算使用它们都不要购买任何的新软件。 
   对于火狐浏览器模拟iPhone 和Android,有了QuickTest Professional 一类的工具,要实现自动化也是有可能的。但是这主要是从功能而不是外观和感受角度出发,且主要用于功能自动化测试。为减少手动的精力/成本,一种通常的做法是功能自动化 
   对于移动web,这是一种成功完成自动化并大大减少精力的方法。

  测试自动化
   因为移动测试必须在许多不同设备,浏览器和操作系统上进行,因此手动做完所有测试会很贵很耗时。测试自动化可以减少测试相关的时间与成本。此外,测试自动化可以提高测试团队的生产力。但要强调一点:自动化测试并不是要取代手动测试,它是为了减少产品上市所费精力/时间。自动化移动web测试工具会与移动app的不同。对于移动web,我用过HP QTP,它有利于功能回归测试的最佳使用。QTP测试工具支持测试自动化框架(关键词/数据驱动/混合)。通过将本地PC浏览器模拟为移动浏览器,我们可以在移动web上运行QTP脚本。这很好地覆盖了必须不断重复的移动web回归测试用例的功能。
   对于移动app测试,测试工具要根据设备平台挑选。我曾经做过POCs ,还进行过移动app自动化,用过QTP ,FoneMonkey(开源),DeviceAnywhere等工具。市场上还有一些移动app测试工具。但是在深入进行移动app测试前必须要定下一个明确的目标。因为它也有自己的挑战,像是工具支持,个人学习曲线和架构支持。如果项目团队很看重自动化的益处,他们可以为app自动化看看究竟要选哪个可用的工具。这通常对电子商务/零售app有用,因为app稳定性对于为公司创造收入来说很关键。

  负载和性能测试
   移动web或移动app的性能是影响移动设备用户转化率的最重要因素。(如果性能太慢,用户便会离开网站。)负载和性能测试在找到负载和性能问题上很关键,要知道负载和性能问题不利于用户转化。
   对于移动web,可以用HP Load Runner/Performance Center进行负载和性能测试。该产品通过用本地浏览器模拟移动浏览器来测试移动web浏览器。 
   对于移动app,它依赖于移动app的平台和架构。绝大多数移动app通过服务层获取数据。进行性能测试的一个方法是手动用户访问app时加载服务层。比如,如果数据层是通过web服务或REST 服务调用的话,那么手动测试员访问移动app时就已经在测试这些服务的性能了。用这个方法就可以获得接近实际的结果了。

  使用“优先平台矩阵”测试真实设备
   测试真实设备时,就必须在每个可能的设备平台上测试app。比如,如果你在测试一个安卓app,你可能最终不得不在20甚至更多的设备(例三星,摩托罗拉等)上测试。为了避免这种情况,你可以在你的测试中使用优先平台矩阵。这个方法可以确实减少你要测试的设备。这种测试方法包含两步:
   1.明确主要参数。主要参数是特定硬件和软件组合重要性的影响因素。我们可以根据项目范围安排优先级。比如,如果只限iPhone 和Android,那么就不会评价黑莓和Windows了;如果我们正在建一个移动web app,就用不到Windows了。你要从业务需求里获取信息。以下是影响这种组合重要性的几点因素:
   ??制造商
   ??分辨率
   ??长宽比
   ??企业对特定设备或OS进行测试或获取数据的推荐
   2.准备一个矩阵以应对所有可能的组合。要准备可以代表每种组合评分的矩阵。按组合相关评分来计算得分。更高的分数表明组合的更高临界值。?

图3. 优先平台矩阵实例

  用户体验测试(UE测试)
   在测试周期早些时候就开始用户体验测试很明智。多数人往往会把UE测试放在最后,但UE测试可以揭示很多问题,如外观、字体、文本颜色、背景颜色、内容、布局等,还可以在测试周期尽可能早地找到缺陷并将之修复。UE测试是基于业务需求的风格设定,复制文档和内容的。对于移动app,UE测试起着重要作用,因为即使是一个小差异,对于最终用户也是显而易见的。
   因此UE测试必须排到项目初始,而不是等到最后。

 可达性和安全性测试
   对于可达性测试,根据组织标准,W3C理事会准则“A”,“AA”和“AAA”适用于移动设备(即组织标准可以优先于任何标准,但不包括选择的内容)。一些可以用于可达性测试的web工具有WAT, WAVE, JAWS和Outspoken。对于移动app,一些设备也有可用在可达性测试中的内嵌工具。比如,iPhone app可以用它的内嵌工具来测试。
   对于安全性测试,10条OWASP 规定适用,需要进行常规安全检查——比如认证检查,输入验证检查,对话管理检查,加密检查,app检查以及注入测试。一些可用于安全性测试的web工具有:HP WebInspect和Web Proxy Editor,很少有其他可以用来进行安全性测试的工具。对于有效移动测试,下面或许就是重要的测试要素:
   ?? 仿真器和模拟器的使用。
   ?? 在所选的真实设备上测试,至少一轮测试是关于外观和感觉的。
   ?? 测试自动化的有效实施。
   ?? 彻底的用户体验测试:风格,字体,内容,图片,布局。
   ?? 性能测试
   ?? 使用各种工具支持不同测试。
   ??(根据范围)在多个网络上测试。有一些公司在SaaS模式上支持该服务,比如DeviceAnyWhere。
   ??使用“优先平台矩阵”选择正确的OS,浏览器和设备版本以便可以很好地覆盖大部分设备。

  移动app测试的准则
   做移动测试时要注意一下准则:
   ??开始实际测试前,了解网络与设备的情况。 
   ??最大可能地模拟真实移动web和移动app环境。 
   ??选择正确的自动化工具 
   以下是自动化工具中你应该要查看的: 
   1.它要支持多平台。 
   2.它要支持多种测试。 
   3.它要支持端到端测试,即使有必要连接到第三方app。 
   4.工具要容易学。 
   5.测试脚本维护要简单。 
   ??在真实设备上使用优先平台矩阵来测试 
   ??UE测试——以及一些要优先考虑的性能测试的测试脚本——应该在真实设备上完成。 
   ??敏捷项目一般的员工比例1:3(测试员:开发员)也许并不适用于移动测试项目,因为设备组合会更多,还有一些自动化挑战,所以其比例应该是1:2(努力的结果实际上取决于项目/测试范围,且可能不是1:2)。但是对于大型移动测试项目,我们无法在没有使用工具的情况下用更少的测试员管理整个测试。

版权声明:本文出自 SPASVO泽众软件测试网:http://www.spasvo.com/news/html/20141125155150.html

原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。