如果对象都保存在对象库，它们可以被集中管理。与此同时，测试脚本（一个或多个）可以根据自身也许需求随意调用这些对象来使用。这使得多位测试工程师协同开发测试脚本成为可能。

　　对象库也可以分为两层，一层面向用户视角，另一层面向程序视角。这两层之间的对象是一一对应关系。这样做有助于测试脚本（测试用例）独立于被测应用程序。例如，应用程序的界面对象Obj 1改变了，但所有引用了该对象的测试脚本无需改动，因为它们是引用的对象Obj A，而非直接引用Obj 1。

　　3、测试数据组织结构

　　当我们提到测试用例的时候，通常指的是一系列操作步骤以及针对这些步骤所用到的测试数据。在之前的章节中，我们已经探讨了基于被测对象的操作步骤，现在我们来谈谈测试数据相关的内容。

　　测试数据，通常可以理解为填入被测表单各个字段中的数值。这些数值需要被很好的组织和保存，以防止数据冗余。可问题是，如何有效的组织和存放这些数据？

　　在前面关于对象库的文章中，我们可以看到，其实测试数据也可以像对象那样被保存于数据库。可以存于数据库的表中，也可以存在表格文件，如Excel或.csv文件。这些表中的字段（表结构）需要跟被测表单中的字段一一对应。

　　在每次测试迭代中，测试用例从数据表中挑选其中一条数据用以执行，所以，表格中的数据需要设计为可重复利用的。当然，期望结果也可以存放于表格中，例如，这次操作的期望结果或返回值。

　　至此，我们已经讨论了关键字驱动的测试脚本、对象库和测试数据的组织。这几样应该都是自动化测试的关键点。但是，这些关键点能否直接套用与安卓应用的自动化测试呢？这些我们将继续在接下来的章节中讨论。

　　前置条件

　　这一章我们要开始讨论基于安卓应用的自动化测试。在此之前，我们需要先关注两点安卓系统独有的两大特点：“Root机”与“扰码”。这两点是在上述桌面应用自动化测试中不曾碰到过的。为什么会提及这两点呢？原因很简单，就是关乎于安卓应用界面对象的识别。