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

　　现如今移动应用测试的解决方案必须提供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范围之内无需另行登录到产品——搜索结果并定位到异常的确切原因：一个超链接会跳转到结果和异常以便快速分析。