第4章 模块化的测试配置

任何软件在运行的过程中都需要配置（Configuration），一般会利用配置文件或数据库甚至是储存在远端的服务器上，通过API进行请求。一个自动化测试平台本身也是一个软件系统，所以配置是肯定需要的。在一般的开发过程中，当遇到需要用户配置的变量时，最简单的处理方法就是定义一个文本的配置文件，从这个文件中获取相应的变量，使用者通过修改文本文件就能实现不同的配置。

这种方法在小规模项目中，只需要大家遵循相应的配置文件规则，就能很好地运行。但是随着项目规模变大，开发人员增加，以及模块数量增加，就会产生如下问题：

（1）配置文件越来越多

随着系统复杂性增加、模块增加，所需要的配置项会越来越多，由于我们并不希望所有的配置都一股脑地放在一个配置文件中，所以配置文件也会越来越多。

（2）资源文件读取或储存的风格不同

不同的开发人员可能将配置文件放在不同的目录下，并且为了方便，会使用自己熟悉的资源文件读写方法，比如有的开发者喜欢使用JSON，有的开发者喜欢使用XML。虽然有些团队会做一些代码书写的规定，但是团队成员并不一定会严格执行，特别是在项目野蛮发展的初期，怎么方便怎么来。

以上这些问题，都会为项目后期的维护带来很大的不便。测试的软件产品不同，需要的配置内容就不同，测试用例中需要用到一些配置项，如果脚本开发者不能够很好地规划这些配置，就会导致配置文件杂乱无章。

笔者经历过很多测试项目，除一些初期的项目外，很多历时几年的项目虽然代码上几近规范，但是有些配置文件依旧成为平台和具体测试业务的耦合点，导致测试框架代码和具体业务的测试用例无法完全分离。因为这些配置项过于具体，比如对于一些测试仪表的配置文件来说，并不是所有的团队都需要这些测试仪表，所以这些配置文件并不应该被强制加载。

本章，我们将分析常见的几种配置类型，并实现一个模块化的测试配置功能。分析的配置类型包括：

静态配置：在测试执行前进行的配置项，测试执行过程中不会改变。

动态配置：配置文件根据具体的业务生成，除了在测试执行前进行配置，还可以在测试过程中发生改变。这个范围会比较大，比如后面会讲到的数据驱动，其测试数据也可以看成一类动态配置。

带有逻辑功能的配置：这种配置比较特殊，除配置选项外，其本身会带有一些操作逻辑，可以让测试开发者在一些测试场景中，不修改测试用例，而进行配置层面的扩展。

通过本章，读者将会了解：

• 静态配置的设计及注册方法。

• 动态配置的设计。

• 带逻辑功能的配置设计。