Android自动化测试解决方案

Android自动化测试解决方案 桌面应用程序与浏览器端的自动化测试都已经历了十年的发展，无论是从工具上还是项目管理方 法论上都已经趋于成熟。而移动设备端应用程序的自动化测试近两年才刚起步，似乎一切尚处于探讨与研究阶段。但我们似乎已经看到其爆炸性的需求增长势头。可 以从这两方面着眼分析：其一，移动应用从数量上和逻辑复杂程度上的增长，以及产品发布周期的紧缩，使得快速回归测试迫在眉睫；其二，安卓系统的开放性造成 硬件厂商百家争鸣的局面，设备款式之多，迫使移动应用的兼容性测试提上日程。纵观当前智能手机两 大主流阵营iPhone与Android，似乎安卓应用开发商与设备制造商更能体会兼容性测试的切肤之痛。鉴于此，并结合传统桌面系统上的自动化测试经 验，我们在此探讨基于Android平台应用程序的关键字驱动自动化测试的可能性，并摸索一条适合在移动应用开发过程日新月异的现实情况中切实有效的实现 和实施自动化测试的路子。 理论基础 在传统的桌面应用软件与浏览器端应用的自动化测试领域，已经有相当成熟的工具可供用户选择，例如商业工具HP QTP，IBM Robot/RFT，Borland SilkTest等；开源工具如Selenium，Watir等。剖析这些工具，它们似乎都有着相同的功能结构： ● 对被测应用界面对象/界面元素的捕获与识别，并对其进行管理与操作； ● 对于测试脚本的编辑功能与语法解析功能； ● 对于测试数据的组织与管理； ● 对于脚本执行结果的分析与输出； 如果细说，还可以牵扯到如脚本录制功能，插件管理功能，与测试管理工具、缺陷跟踪工具的整合等内容，涵盖面相当广泛。但所有这些都是为了一个目的：模拟测试人员行为，达到功能性回归测试的目的。本文尝试从以下最关键的几点来分析自动化测试工具的核心构成部分。 1、关键字驱动 关键字测试的主要思路是以面向对象的方式来管理被测应用的对象、对象的相关操作、测试数据以及这些测试数据之间的组合关系。关键字驱动是自动化测试中行之有效的方式，它可以帮助测试工程师更方便的维护测试脚本、构建复杂的业务逻辑测试用例、并节省手工测试的执行时间（尤其是在回归测试阶段）。关键字驱动主要由以下三种元素构成： 1）被测对象，即被测应用界面上的元素； 2）针对这些对象的操作，如点击（按钮）、填充（文字）、选择（单选框/多选框）； 3）以及基于这些操作的数值； 上述三种元素可以描述为以下表格： 对象操作数值文本框输入文本值按钮点击无选择框选择选项值或者以面向对象的文法表述为： 对象.操作（值） 该语句是关键字驱动脚本的构成基础。 2、对象库 对象库是用于储存被测应用程序界面对象（界面元素）的地方。它是关键字驱动测试工具的关键点。有了它，用户可以更容易的维护被测对象、更快速的构建测试脚本。它是如何做到这些的呢？让我们看看下面的结构：

实践探讨完上述关于不同测试工具的使用特点，更准确的说，是安卓应用自动化测试工具的特点，我们不妨来实践（其实是模拟）一个移动应用的测试过程。这里我们选用API Demo作为被测应用，选用DroidPilot作为测试工具。 分析被测应用 被测应用API Demo使用标准Android SDK作为开发控件，且被测应用未加扰码，因此，界面上所有元素可以被DroidPilot识别。 对于一些非标准Android SDK控件开发的应用，这里有两种情况：一种情况控件完全由自己开发，如果是这种情况，DroidPilot完全无法识别对象；另一种情况是在标准控件基 础上做了二次开发，这样的话DroidPilot只能识别到原生SDK那一层。对于这两种情况，都可以联系DroidPilot开发团队为非标准控件度身 定制专属插件，用于识别被测控件。 对于扰码问题，正如上述《前置条件》章节所描述的，DroidPilot本身是无能为力的，只能请开发团队去掉扰码，打包一个不加扰码的测试包给测试团队使用了。 设计测试用例 这里我们假设一个测试用例是进入\App\Activity\Animation\Fade in\界面，对界面的元素（按钮、文本框、多选框、单选框、下拉列表）进行操作，并验证文本框的文字是否符合我的预期结果。测试步骤如下： 测试用例1 -验证\App\Activity\Animation\Fade in\界面元素前置条件：API Demo已经启动，停留在起始页步骤动作期望结果1点击App项 点击Activity项 点击Animation项 点击Fade in项 在文本框输入”put your text here” 勾选Checkbox1 向下滑动一次屏幕 点击下拉框 勾选Venus 检查文本框文字=”textColorPrimary”开发测试脚本 先使用DroidPilot脚本编辑工具抓取各个屏幕的对象，然后把这些对象选入脚本设计器，按照测试用例的顺序来排列，如下图：

如下图，传统模式，测试工程师可能在第一轮测试才有一次Full Test,在后续的回归测试中，可能只能做到部分回归。

如果引入自动化测试工程师，同步开发测试脚本（理想情况，每个应用自动化比率达到70%~80%,整体自动化比率达到60%~70%），有可能使得回归测试比率有所提高。 从零做起 既然如此，何不从现在开始，从零开始，在项目中尝试引入自动化测试，哪怕只是抽调部分人力着手部分应用的自动化测试，至少可以达到Daily Build Smoke Test的效果。再者，移动应用自动化测试行业正处于起步阶段，此时介入也不失为一个好时机。 结论 回顾上述讨论的内容，我们设想能在移动应用自动化测试领域延续桌面系统自动化测试的成功经验，从理论基础、工具支持、以及后续项目管理方面都做了一番探讨。尽管主要还是局限于安卓应用的自动化方面，对于iOS提及较少。不难理解，iOS本身支持的机型有限，对于设备 兼容性测试并不是重点关注的内容。而在功能性回归测试方面，它本身也有相关工具支持。至于像Blackberry之类的平台，因为本身并没有呈现爆炸性的 应用增长，所以也没有列在讨论范围。所以，本文仍以安卓平台作为自动化测试的突破口，希望从中能结合市面上的一些商用工具，尝试实践以“关键字驱动”为基 础的自动化测试，而非原始的以“坐标点”为基础的屏幕点击测试。对于开源工具也没有提及，原因是考虑到像Robotium和MonkeyRunner之类 的流行工具可能更贴近于开发工程师使用，而非更贴近于测试工程师。所以，我们希望在上述的讨论中能带给读者在测试项目中新的启发。