移动应用的持续测试

用手点、用眼看。考虑到大批移动设备和应用进入软件生命周期，用手点、用眼看似乎是目前测试应用的唯一方式。这意味着手动测试将贯穿整个软件发布周期的前前后后。但是手动测试还存在问题，理由有几点：它大大减慢了开发过程，给错误的发生留下很多余地，最终会降低团队在短时间内发布高质量软件的信心。

现如今移动应用测试的解决方案必须提供 web 及原生应用的持续集成测试。这些解决方案应允许团队快速地创建、修改和执行测试。测试解决方案还应该提供与 Jenkins 集成的插件，或是以 ANT 任务的方式集成到任意持续集成服务器中，最终以标准的 JUnitXML 格式向持续集成服务器反馈测试结果。采用测试产品与持续集成服务器集成，企业每天能够发布多个构建，同时单元测试、功能测试以及性能测试全以自动化方式进行。

以下是 SOASTA 对于软件生命周期中移动应用持续测试的看法。

首先，解决方案的要求

• 以移动终端操作系统能够识别的相同速度、速率和精度，100% 准确地录制手势和交互。这个对于在移动应用中属于热门的游戏来说尤为重要。当一个手势，例如手指滑动，在移动设备上执行，它便由大量元数据组成。看似一个简单的手指滑动，移动终端操作系统看到的却是一个大型数组，它包含了手势的速度和轨迹，这些数据每秒钟采样多次。只简单地使用滑动起止点 X/Y 轴坐标，很多应用都无法完成精确测试，游戏领域几乎不太可能。
• 在真实设备上进行测试。这个要求再怎么强调也不为过。苹果公司甚至表示，不推荐应用交付前只在与 XCode 关联的 iOS 设备模拟器上测试。必须在真实设备上测试应用，以了解真实用户体验以及程序的性能和总体质量。基于模拟器或虚拟设备的解决方案总会和真实设备有差距，并会留下质量缺陷。
• 基于设备上呈现的真实对象和应用状态执行验证。早期的移动测试产品在测试创建以及回放方面使用视觉认知。这意味着，为验证测试在屏幕上识别到了某些东西，该产品将为设备屏幕截图，并试图定位图像的边界以验证某些东西是否出现了，比如一个登录框。这种方法很脆弱，误差范围大约是 4 个像素。因此，如果开发者修改了登陆框颜色，或是移动了它的位置，就需要重写或修改测试用例。能够在原生级别访问应用程序对象至关重要。在现如今的移动软件生命周期中，切实可行的测试解决方案必须能够在原生级别访问应用中的真实对象，以便执行测试用例并验证。

其次，移动应用自动化的蓝图

为完善移动测试解决方案，移动测试自动化领域存在诸多挑战。没有人工干涉的情况下，部署可测试版本应用到移动终端上就是其中之一。手动部署应用以启动自动化测试违背了持续集成测试的目的。

对于典型的 web 应用， Jenkins 持续集成工作流将会检出源码，构建，部署到测试环境，然后启动。目前 Jenkins 已具备部署 web 应用程序至测试环境这一特性。然而，如何在没有工程师人工干预的情况下，将应用程序部署到移动终端是目前业界还未解决的难题。

持续集成架构

在构建 iOS 应用程序时，你用作移动测试的持续集成 slave 端是一台 Mac 电脑。通过 XCode 构建代码并部署到移动终端。以 Jenkins 作为持续集成服务器为例，工作流程如下所示：

1. Jenkinss 持续集成服务器唤醒 slave，并命令它检出源代码。
2. Mac slave 使用 XCode 命令行工具构建源码。 这些都是构建 iOS 应用程序自动化的典型步骤。以下这几步在有些产品中是独有的：
3. 通过 USB 可将一个甚至多个 iOS 设备连接到 Mac slave。
4. 部署的 utility，作为 Jenkins 作业定义的步骤之一，将通过 XCode 自动部署应用程序到设备。
5. 一经部署，设备将自动连接到产品，并准备接收并执行测试。 应用程序通过 Jenkins 以自动化方式部署之后，就可开始执行测试用例、报告缺陷。
6. 执行测试。
7. 将代表通过或不通过的测试结果反馈给 Jenkins ，然后发送测试分析。

为便于查看，测试结果以行业标准 JUnitXML 格式反馈给 Jenkins 。一旦遇到错误， Jenkins 插件允许工程师查看异常的确切原因——在 Jenkins 范围之内无需另行登录到产品——搜索结果并定位到异常的确切原因：一个超链接会跳转到结果和异常以便快速分析。

SOASTA 云测试方法

我们的方法，发布于 2009 年，是一个最佳实践体系，该体系有关于生产环境中的应用测试，实验环境和生产环境的连续性测试，以及相互独立的两个环境中日常的例行测试。使用这个方法，我们已使众多企业在应用程序测试操作中达到了一流效果，这其中包括了美国在线零售商十强中的六个。

在云测试方法中，执行阶段内，云测试通过加快测试定义、设计、执行和评估来加速测试周期。可视化的开发环境允许团队以前所未有的速度创建测试用例，因为这个过程中只需编写少量的代码，甚至一行代码都没有。通过制定任务或持续集成服务器以自动化的方式执行测试。因为所有的数据都存在云测试上，测试结果将及时发布。这意味着工程师们可以通过创建、操作控制台获得实时的反馈。他们立即就能看到程序的性能和稳定性。

（点击图片，查看大图）

这个方法提出了两个队列，实验环境和生产环境各一个，队列维护实验室持续测试日程表，在每个关卡，可以对目标产品的测试用例做执行或者不执行的决定。

结论

要想在现今快速变化的网络世界里取得成功，企业需要正确的测试解决方案。创建糟糕的用户体验可能是灾难性的。性能低下可导致收入损失，客户流失，差的品牌口碑病毒式地传播。市场上传统玩家对在避免这些问题上表现出高度自信的解决方案反应迟缓。这种自信源于采用现代化的测试方法以及合适的工具。新技术提供了克服移动应用测试相关困难的方法和工具集。

关于作者

Dan Bartow是

SOASTA 负责产品管理的副总裁，SOASTA 是云测试行业领导者。你很难找到比 Dan 在这些问题上知道的还多的人，他曾就职于 Intuit、Turbo Tax、Neiman Marcus、ATG 以及几家创业公司。

查看英文原文： Continuous Mobile Application Testing

感谢李琼对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。