这个层次的抽象能让自动化测试有着更长的生命周期。通过使用正确层次的抽象，无论是在应用程序上进行了改动，还是在当前使用的工具发生了变动，依然可以使得自动化测试继续进行下去。在本书提到的所有成功案例研究中都在一定程度上实现了这一层次的抽象。

　　0.2.1.2　将测试与测试件分离开来

　　顶层（高层）的抽象是将测试的基本想法（即对什么进行测试）与测试的实现（如何构建自动化测试）分离。测试人员使用对他们有意义的高级（领域相关的）关键字编写测试，以描述他们想要运行的测试。

　　这一级别的抽象对于那些没有编程技能的测试人员是最重要的。他们的专业技能可能是有关业务或者应用程序的。如果是程序员在开发测试，他们会更加理解这些测试技术是如何实现的，于是这层的抽象对他们来说就没有那么重要；这些对于开发人员最合适的高级关键字可能对那些业务用户来说过于技术性。但是不要忽略这一点，即对于那些编写和维护测试的人员来说，易于使用这些测试是很重要的，而不管他们是不是程序员。

　　测试人员的工作是测试（见0.1.5节中关于技能的部分）。在关注如何最好地对一些事物进行测试时，不应该考虑过多的实现细节。他们应该能够使用对他们来说有意义的语言来编写测试，而不是使用只对工具有意义的编程语言。他们关于测试的想法与他们的领域有关（即他们测试的应用程序），于是他们的测试也应该与这个领域有关。

　　例如，一个拥有保险业务知识的测试人员可能会关注保险索赔和续保。一名专注移动设备的测试人员可能会想对网络连接、会议电话等进行测试。对于不同行业部门的人来说，这些高层次关键字可能非常不同，即使一些低层次的关键词可能会相同。这就是为什么我们喜欢这个词目——“领域相关的测试语言”（Domain-Specific Test Language, DSTC），这点Martin Gijsen曾也提到（www.deanalist.nl）。

　　如果没有任何编程经验的测试人员既能编写也能运行自动化测试，那么自动化测试就能对业务领域有巨大的帮助，而且更有可能广泛地应用，进一步增加ROI。

　　专门地讨论这个层次抽象的案例研究包含在第2、11、12、14、15、20、21、27和29章。

　　0.2.2　自动化测试标准

　　如果人们仅仅关注自己的事情，他们将会以只对他们有意义的方式创建自动化测试和测试件，然而他们创建的东西彼此之间都不相同。如果想要很多人使用自动化测试，那么定义自动化的标准并去遵守这一标准是很重要的。标准的命名约定，存储测试件条目的统一的地方，创建测试的标准方式，归档测试的标准例子，对象、脚本和数据文件的标准名称；每个脚本的标准文件头——需要达成一致并且普遍使用的事情远比你能想到的还要多。之外，使用自动化测试的人越多，遵循标准就越重要，并能带来更大的收益。

　　对这些自动化测试标准的定义最好在试点项目中开始，在试点项目中可以尝试各种方法并且达成一致。之后必须将大家都同意的标准告知所有将要使用自动化测试的人员——无论使用领域相关的测试语言定义自动化测试的人员，还是开发可复用脚本的人员。我们还建议将一些标准构建到支持测试的工具中，以便更容易地创建更多的脚本，而且还能避免很多人为错误。

　　然而这些标准也不应该一成不变。随着自动化测试变得成熟，保证标准可以变更以及遵循新的（改进的）方法进行更新是个很好的主意。另外很重要的是，允许标准中出现例外情况，当然，要对这些例外进行验证。随着自动化测试规模变大，将标准进行集中管理并且就其与所有人员进行沟通就变得更加重要。关于标准的讨论参见第6、9、12、15、21和29章。

　　0.2.3　可复用性、文档和灵活性

　　虽然有时构建一些“可以丢弃的脚本”（disposable script，参见第19章）是很有用的，然而大部分自动化测试中，单个脚本都有很长的生命周期，并且需要以多种方式复用。如果脚本使用多次，那么就值得花费时间去保证它构建良好，如其中包含良好的错误处理方法，并且保证对其进行过测试和审阅。去找寻那些可以复用的模块，而不是一切都从头编写。

　　为了使得测试自动化人员能够找到并且使用可复用的模块，这些模块必须有良好的文档。应该可以很容易地访问这些测试件条目的信息，而且这些信息应该以标准的格式呈现出来。例如，在每个脚本头，写出这个脚本的目的、如何使用这个脚本（它期望接收的数据以及返回的数据），以及一些前置条件和后置条件。一些额外的信息也很有用，如在一些可能的错误条件下会发生什么。这些信息应该可以很容易地搜索到。事实上，将这些信息收集起来就可以作为测试件的文档，而且通常可以很直接地将这些信息收集起来，并将其分类到单独的文档或者集中进行管理。

　　在运行测试时，灵活性是很重要的。例如，如果一个脚本正在处理从电子表格中得到的数据，而且并不需要电子表格中所有项都填满，那么一个更加灵活的脚本应该允许跳过那些没有值的字段，这可使测试人员很容易创建各种不同的测试。

　　为每个测试标注上该测试属于哪一类也是很有用的，例如，可以标记其为冒烟测试、修复bug的测试或者对函数X进行的测试。使用这种“测试选择器”可以很快地选择在给定时间运行测试的不同子集。

　　这些主题在第3、5、11、14、21和29章中讨论。