持续质量和云平台：如何进行移动应用测试

作为与客户互动的新策略，“移动先行”正在被越来越多的组织所采纳。与此同时，而随着移动应用市场的复杂度日益增加，移动应用开发 / 测试团队需要满足更快的版本发布速度，移动正在推动敏捷。最新的现状是移动应用需要一个完全不同的开发流程。为了能够赶上市场的步伐，在移动应用的整个生命周期中，开发人员需要应对不断增长的变化集合——从来自于新的移动平台和设备的终端用户到终端用户参与的数字体验的增长。举例来说，物联网（IoT）带来了更多新的具有传感功能的上下文感知设备，随之而来的就是与桌面电脑、手机、可穿戴设备、平板电脑以及非移动设备的集成需求。伴随着这些变化，我们必须接受移动的颠覆性将会是持续不断的；与此同时围绕移动设备的功能和性能，也将不断引入新的挑战。当移动应用推动创新、需求及功能发展的同时，测试这些应用的相关复杂性也与日俱增。如何确保开启车库门的应用不仅可以工作，而且可以持续保持良好的运转？此外又如何能够做到在不牺牲质量的前提下，达成更快的应用开发速度？能够支撑移动应用开发人员提升开发速度和质量的追求的唯一答案就是在移动软件开发生命周期（SDLC）的早期就引入测试，并将测试贯穿整个生命周期直至投产。这就是持续质量方法论。

持续质量

持续质量是一种将质量活动嵌入到 SDLC 过程的每一步中的方法论——从设计到构建再到投产——所有这些都基于过程、工具和用于支持组织特定需求的定制化测试实验室基础设施的支持。成功的持续质量过程可以优化上市时间，推动更加快速、频率更高的版本发布并且通过尽早地以自动化的手段管控风险，将逃逸到生产环境的缺陷减到最少。持续质量兴起背后的主要驱动力源于持续高频地发布高质量（原生的、混合的等）移动应用的需求。对于移动来说，必须要有敏捷的流程，但是在敏捷方法之上，在应用的功能、性能、可用性和安全方面，开发团队需要来自于真实设备的快速可操作的反馈。将与质量相关的所有内容嵌入到每一次的构建中，并持续为开发团队提供反馈，以便开发团队能够尽早洞察缺陷——这是持续质量的核心价值。目前，对于企业移动应用来说，平均需要执行数千次的测试。这些测试流程需要在各种安卓和 iOS 设备、智能手机和平板电脑以及两到三种最新版本的操作系统上执行。理想的持续质量过程依赖于可以针对测试设备矩阵执行自动化测试脚本的持续集成服务器，测试设备矩阵中包括安卓、iOS 设备，平板电脑，电话以及不同的操作系统版本。开发团队从持续集成服务器上获取报告，这类自动化测试执行的周期长度大概为几个小时（或一个晚上）。如果无法正常执行自动化过程，就几乎不可能将质量过程转化成一个可重复的循环，这一过程就会变的冗长低效。

成功——不可能完成的任务：未采用持续质量的后果

使用老旧、传统的开发方法的组织不可能在移动领域取得成功。未能实践持续质量工作流程的团队由于所用的工具与开发人员所用的完全不同，最终会以一种支离破碎的方式终结运转。如果一个团队仍然依赖于某个开发人员或质量保证人员桌上有限的几个移动设备完成测试，而没有将这些设备置于云端环境之中，在应用开发周期中他们将会面临更多的挑战，这其中就包括管理和安全的缺失。团队仍将严重依赖于手工测试和尝试性的基本的自动化测试——这与一夜之间就可以在多台设备上运行成千上万条测试的持续集成机器相比相差甚远。该团队还缺乏创建并测试真实的终端用户情景的能力。有许多工具可以模拟各种不同的网络情景、运营商网络、GPS 定位测试、载荷测试等，而且开发人员可以基于这些场景进行测试。这种“老旧”环境将导致对应用的质量和性能的可见性有限，这通常会导致缺陷在项目晚期才会被实施工程师或用户发现。

持续质量的实施

持续质量过程和其他过程的关键区别在于：在持续质量过程中，开发人员、测试人员和性能测试工程师之间没有严格的界限。其重点是凭借一组环境资产、工具和质量实验室在非常早期就引入质量保证工作，作为持续集成（CI）工作流的一部分，为开发人员提供一个自然的环境，并行完成开发、构建和测试移动应用的工作。为了实现目前为止可能比 Web 应用更加碎片化，更加复杂并且更加难以预测的移动应用的持续质量过程，移动应用开发人员或移动敏捷团队需要许多独特的工具能力，以保证强有力的持续质量过程。开发团队应该考虑可用于测试的真实设备的移动应用质量实验室；在许多技术方面，模拟器都无法满足要求，并且无法提供完整的设备能力，如传感器、网络条件、特殊的硬件限制等等。最理想的设置是在基于云的实验室中将设备连接到真实的移动网络中，该实验室可以提供用于控制移动设备的相关能力：

• 完整的移动设备系统控制
• 设备轮换
• 设备日志及关键信息，如 CPU 监控
• 真实的网络条件，开发人员可以进行应用测试的各种网络配置，如 2G，3G，不同的丢包率以及其他，并且可以在各种载荷条件下检查应用。
• 基于位置的测试能力（例如：利用谷歌地图 API 模拟设备位置）作为早期测试并贯穿持续集成工作流程的一部分
• 简单的 USB 设备接入能力，接入未被入侵，未被越狱的设备
• 模拟网络环境
• 环境转换能力，让在预生产环境和生产环境中同时进行同一应用的测试更加容易

借力混编云

面对如此多变的需求和持续变革的移动设备市场，团队可以从“混编云”环境获益良多。混编云是指由多种不同部署选项组成的云环境——组织机构可以在可用设备，共享设备和用于测试的远程托管移动设备的组合上开展工作，这可以补充对相关覆盖度的需求，并且可以支持全球团队间的相互合作。随着移动应用项目的扩张或转型，混编云的灵活性可以帮助团队随时增长或调整。混编云在满足本地开发案例方面也是相当有价值的，如测试需要通过 Wi-Fi 或蓝牙配对的可穿戴设备，或测试基于 NFC 的应用，如支付应用。混编云还可以满足全球化设备覆盖度的需求，例如当某个分布式团队需要与某个在特殊的网络中拥有独特设备的远程团队合作时。利用混编云环境，这些设备成为了联合云的一部分，所有团队都可以共享设备并使用这些设备开发或测试，无论所处位置如何。

端到端的软件开发生命周期支持

为了实现相当有挑战的发布周期目标，开发人员和测试人员相处融洽是相当重要的。测试自动化工作在持续质量过程中起到了至关重要的作用。这一自动化工作可以让开发和测试团队在他们所使用的任意框架和语言下编写高效的测试代码，并且可以在多个真实设备上无缝执行这些代码，作为整体持续集成和构建验收过程的一部分。这一自动化解决方案可以与任何持续集成过程、测试框架（Selenium，Appium，Calabash 等）以及集成开发环境（Eclipse，Visual Studio，Xcode 或其他 IDE）集成，成为持续质量过程的基础支柱。除了手工测试和功能测试以外，作为早期开发阶段和持续集成的一部分，测试环境还应该提供非功能性的性能和监控能力。意识到应用经常会与数个其他应用并行运行在各种不同的网络条件下，争夺有限的内存，CPU，电池延时和网络带宽是相当重要的。因此没有真实的载荷，复杂的场景和输入的事件以及其他影响，只在“干净的”机房环境中对应用进行测试的想法，的确有些天真。不重视上述情景，将其作为持续质量过程的一部分，会让你的应用暴露在后期的缺陷当中，而这类缺陷通常更加难以分析、修复和重新部署，特别是我们不得不通过应用商店冗长的重新部署流程。

持续质量过程中开发人员的角色

持续质量过程可以让开发人员获得授权并且将注意力转向高质量应用的构建。曾经习惯于非常基础的单元测试，并将二进制程序（IPA、APK 等）交给 QA 团队的开发人员现在拥有了可以让整个持续质量周期更加高效并具有更高测试覆盖度的能力和工具。开发人员可以在按需生成的应用构建（每日、每小时等）中注入大量的验证程序，并且可以在几个小时内得到一个全面的报告；这将完全改变原有的游戏规则。作为应用构建的一部分，开发人员可以在其中包含健壮、持久的测试自动化脚本，这些脚本可以是开发人员自己编写的或自动化工程师用同样的环境和语言编写的并且为开发人员所熟悉的脚本。开发团队应该用清晰的标准定义最重要的测试用例（发现缺陷最多的测试用例、关键功能测试用例、客户要求的缺陷修复等）并且应该将这些用例包含在每一次的持续集成回归周期中。一旦这些测试通过，就可以启动剩余的测试用例以保证更高的覆盖率、进一步降低风险。在基于真实设备和真实网络环境的功能性自动化测试完成的基础之上，开发人员可以包含更加重要、目的明确的“环境测试”能力以提升校验覆盖率并获得最大化的洞察力，以增加他们对这款即将上市的应用的信心。

不断变换的市场：下一代可穿戴设备

随着可穿戴设备对这个早已碎片化的市场的改变和加速，如今将持续质量过程作为 SDLC 一部分的需求比以往任何时候都更加强烈。可穿戴设备应用和移动应用将会持续地进行交互，并且相互依赖。在一个设备上实时发生的来自于用户的动作会触发另一台设备上的其他动作和事件。当用户使用 FitBit 完成一次跑步后，他 / 她就可以立刻在移动设备上查看最新的统计数据以及与前一天运动情况的对比。为了应对这一问题，开发人员需要能够拥有对设备（智能手机 / 平板电脑）系统以及可穿戴设备的完全控制权限。有了健壮的持续质量过程后，开发人员就拥有了对他们的移动环境以及用于开发和测试应用的工具的完全控制权限，以及对这些外附平台的支持。

实现向持续质量过程的飞跃：一个金融机构的旅程

我们应该如何做出改变，实现从冗长低效的移动应用开发过程向一流的持续质量过程的转化？一个顶尖的金融机构正面临这样的问题，每一个版本的 QA 周期都需要冗长的 8 周时间。这一周期不仅成本高昂，而且规模受限，这就导致相关风险随着每次构建不断增加。非常低的设备覆盖率和每次构建十分有限的洞察让开发人员的行动和对市场终端用户的反应迟缓。当时，该金融机构并未将反馈整合到过程当中，这就导致从用户现场报告的缺陷需要花费数天时间才能够被重现和调研。如今的最终用户不会有这样的时间、耐心或渴望来等待问题的修复，他们会直接转向竞争对手。该金融机构意识到基于应用商店中的公开用户的反馈对移动应用质量作出反应并非一个好的选择，他们需要与市场保持紧密联系才能留住客户。该机构设置了清晰的目标以保证可以有更频繁地版本发布，这就意味着需要在功能测试和性能测试阶段包含更高比例的测试自动化用例。为了实现向持续质量开发过程的转变，提升应用发布的速度，该组织在思维方式上做出了关键的调整。他们提出了一些尖锐的问题——从现在起，六个月以后他们希望他们的应用处于什么位置，一年以后以及更长时间以后呢？从质量的角度来说，他们的发布周期看起来应该是什么样子的？他们准备如何提升效率？最重要的是，如果没有这些变化，终端用户的体验该如何继续忍受？

• 经过调研和分析，最终确定如下目标：
• 提升应用质量，将应用商店中的评分提升至 4-5 星
• 用更细粒度的范围降低版本发布周期的长度——根据受影响的代码范围执行自动化测试。
• 提高效率，设置 80% 的自动化目标，从而缩短上市时间，加快缺陷的解决平均时间（MTTR）。
• 提高设备覆盖率，涵盖目标市场上市场占有率最高的设备。

结果

该金融机构意识到，要评估移动应用，确保其可以在桌面浏览器、移动设备及其他设备上正常运转，开发人员需要将测试贯穿整个移动应用开发的生命周期。这会提升应用的质量并加快开发的速度。从移动应用开发的初始阶段，他们就需要一个一直可用的测试实验室。这个实验室就可以根据需要提供对设备的访问，这些设备电量充裕、与真实的运营商网络保持无间断连接、拥有对设备系统的完全控制而且还提供日志。在这样的环境中进行测试，在开发周期中他们可以及早发现问题——显然，这对提升开发速度、提高移动应用质量非常关键。此外，拥有混编云测试环境后，团队就不再需要不断追赶设备或改变测试语言。他们可以将精力完全集中在版本质量和设备覆盖率之上。通过实现完成了测试自动化和基于云的实验室的持续质量过程，该金融机构可以将 80% 的手工测试自动化，并且可以将测试集成到持续集成工作流当中，并在多达 20 个真实的设备上执行，基于此，他们可以在安卓和 iOS 应用上增加真实网络条件下的性能测试——这些都要仰仗上文所提及的混编云模型。综上所述，下图是关于如何做出改变并转向持续质量过程的“详细计划书”：

Jenkins 这类自动化版本管理工具的普遍采用，与自动化的功能性回归测试的结合是移动应用速度和质量的关键，这一点已经十分明确，然而，特别是在移动环境中——性能测试也必须成为这一自动化版本管理过程的一部分。开发过程中很可能会无意中引入可能会导致性能下降的代码变更。实现自动化的性能评估作为自动构建的一部分可以消除这一风险，并且能够为开发人员和性能工程师提供早期的洞察。

总结

随着移动新时代的到来和对新平台的期望，移动应用开发者需要拥抱新的过程和方法论，以便他们在组织中可以处于更强势的位置，能够对市场变化更快地作出反应。对于组织来说，持续质量过程是能够快速处理市场变化并输出高质量、可预测成果的最有效的解决方案。开发人员应该持续不断地“聆听”市场发出的声音，以及这一声音会如何影响他们的开发——或者是会影响他们的设备矩阵的新平台发布、新的设备进入市场，或者是可能会影响移动应用质量的应用商店评审以及主要市场活动。持续质量为开发人员和测试人员所提供的桥梁让移动应用 SDLC 周期中的日常工作更加高效，因为整个团队都可以从每一个持续集成构建中及时获得来自于真实网络条件下的真实设备以及大规模的设备和操作系统中的详细信息，而且所有这些都会直接进入开发者的自然环境，这是在当今移动领域至关重要。

关于作者

Eran Kinsbruner是基于云的移动应用测试和自动化公司 Perfecto Mobile 的产品市场总监。在此之前曾经担任 Texas Instruments 的移动测试 CTO 和 Matrix 的项目经理，Eran 从 1999 年开始就从事测试相关的工作，还有在 Qulicke & Soffa，Sun Microsystems，General Electric 和 Neustar 的团队管理经验。作为在 Sun Microsystems 公司的移动 J2ME 测试的测试排除自动化机制的联合发明者，Eran 在移动测试领域拥有丰富的经验。可以在 ek121268@ Twitter ，LinkedIn 以及他的专业移动测试博客 ek121268.wordpress.com 找到他。Eran 还是 Perfecto Mobile 博客的定期撰稿人。

查看英文原文： Continuous Quality and the Cloud: How You Should Be Testing Mobile Apps