移动测试策略

‍

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

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

‍