0.2　技术因素

　　在我们看来，最重要的技术因素是测试件架构以及多个层次上的抽象。测试件（testware）是所有创建的用于测试的事物，包括脚本、数据、文档、文件、环境信息等。测试件架构就是这些事物是如何组织的，以及它们彼此之间是如何依赖的——例如，高层次的脚本使用了低层次的脚本用来与被测软件进行交互。

　　0.2.1　抽象、抽象、再抽象：测试件架构

　　在最初得到了一个测试执行工具后，通常会期望测试人员开始使用这个工具。当这名测试人员不是开发人员时会发生什么？现在突然需要他们成为程序员，去学习工具的脚本语言。如果他们没有编程背景，他们就不知道如何构建坚固的（自动化）代码，于是当对被测软件进行改动，同时这项改动也需要在自动化代码中进行时，维护他所写的代码可能就要付出很大的代价。通常，公司放弃一个测试执行工具是因为测试脚本维护费用很高！

　　对于成功的自动化测试执行来说，（至少）有两个主要的抽象层次：将工具和工具特定细节与结构化的测试件分离开来；将测试（即测试人员所从事的工作）与结构化的测试件分离开来。这些内容会在0.2.1.1节和0.2.1.2节中进行更详细的描述。

　　自动化测试人员负责实现这些层次的抽象；如果这些层次实现得不好，那么自动化维护起来就会很昂贵而且很难使用。图0-1展示的是我们认为好的测试件架构，其中还包含了为了达到这些层次的抽象自动化测试人员所扮演的角色。

图0-1　抽象的层次

　　0.2.1.1　将测试执行工具与测试件分离开来

　　一个好的测试件架构能够让测试自动化发挥真正的力量。自动化测试架构师负责设计测试件的架构：脚本、数据文件和实用工具等，这些都是自动化测试所需要的。其他的自动化测试人员在之后必须对其进行补充和完善。这里需要好的编程实践：良好的结构，遵守一些合理标准的模块化代码，这些标准鼓励代码的简易性和复用性。当软件的一些方面有所改变时，也许测试件需要进行改动，但是一个好的架构会让这些变动最小。

　　可以通过框架来实现测试件架构，框架可能是测试执行工具的一部分，也可能和测试执行工具分开；或者也可以通过分开的测试控制程序或者测试解释器来实现测试件架构。

　　有时人们在用户界面（UI）对象（如按钮和编辑框）周围使用包装器（wrapper）。包装器是个好的开始而且对于好的自动化测式来说也很有必要（但是并不足够）。为GUI对象的名字使用对象映射（object map）也是另一个用来实现合适层次抽象的例子。

　　另外一个重要的方面是较高级的测试件不应该直接与任何特定的工具或者工具语言绑定在一起。当然，在工具接口上，脚本必须是以选择的工具语言所编写，但是这仅仅是对于最底层而言；结构化的脚本应该以与工具无关的方式编写。你也许会认为，当前使用的工具很完美，为什么还要这么做？但是随着时间的推移工具会发生变化，应用程序也已意料之外的方式发生改变，系统可能要迁移到其他环境或者平台上，于是3年前看起来完美的工具现在看起来并不那么合适。如果测试件和工具紧紧地绑定到一起，那么很有可能你最终会不得不抛弃测试件的很多部分。如果达到了这个层次的抽象，那么就可以保留结构化的测试件的大部分，仅仅需要改动最底层的那些与工具相关的脚本。