4.1 测试配置基本分类

不管具体的测试项目如何，对自动化测试系统来说，配置可以分为静态配置、动态配置和带有逻辑功能的配置。本节我们具体看一下这些配置的特点。

4.1.1 静态配置

静态配置是一种很基本的配置，也非常容易理解，就是将一些配置选项参数化，保存在一个外部资源（比如文本文件或数据库）中。测试执行者在测试执行前修改并保存这些配置项，让测试系统能够读取相应的值。

首先我们要明确，对于模块化的设计，其静态配置不能依赖于平台，而是每个模块自己管理自己的配置，最终汇总到配置管理模块进行统一管理。比如在一些实践中，测试报告模块需要如表4-1和表4-2所示的配置项。

而测试执行模块，则可包含如表4-2所示的配置项。

测试资源管理模块包含的配置项如表4-3所示。

也许有读者会问，如果我们的所有配置，包括测试资源、测试报告等都存放在数据库中，难道也要在每个模块中配置数据库的地址吗？答案当然是否定的。配置的归属问题应该属于设计的范畴，有些配置放在哪个模块都会显得合理或者不合理，对于数据库连接地址等信息，应该存放在数据库相关的模块中，而其他模块只需使用数据库模块提供的连接对象即可将数据输出到数据库。

同样，对于表4-1中的测试结果存放的目录，我们同样可以定义在测试执行模块而非测试报告模块中，测试报告模块只将其作为一个参数由测试执行模块来输入，所以笔者认为设计上并没有绝对的对和错。

这些配置和具体业务并没有联系，可以说是一些测试平台模块的通用配置项。但是除了这些常用配置，还有很多和业务相关的配置项，这些配置与具体的测试项目所测试的产品有关。比如，当我们测试某个网络产品的时候，会有如表4-4所示的一些配置项。

这些配置是测试执行模块中对具体产品相关的配置选项，只对特定的产品团队适用，所以静态配置应该能够被方便地扩展。

4.1.2 动态配置

相对于静态配置，动态配置的范围会比较广。动态配置的特点是，配置文件并不是固定不变的，它会随着业务变化（并非跨团队的业务变化）而增加或减少。这些配置并不是应用于整个平台或者某次执行中，而可能是作用于某个测试平台的对象，比如测试列表和测试用例。我们会在第6章介绍测试引擎的设计时具体介绍这两种配置，这里只举一些例子来简单介绍。

不同测试团队使用测试列表的方法不同，但基本是作为一组测试用例的合集，所以在执行的时候会有一些共同的配置项。假设一个团队用功能来对测试用例进行聚合，相同功能的测试用例放在一个测试列表中，那么在执行整个测试列表的时候，可能会有如表4-5所示的一些配置项。

这些配置项根据具体的测试列表来生成，在测试执行者调用该测试列表之前，执行者并不知道该配置的存在，也不知道去哪里配置。而当测试执行者加载了测试列表之后，该配置文件就应当被自动生成，并且这些字段会有默认值存在。这样，执行者可以根据生成的配置来修改需要的配置字段。

对于测试用例，有时候为了提供更高的灵活性，允许测试执行者进行一些配置项的更改，比如一个压力测试对一个操作重复N次，执行者就能通过配置这个N来决定要执行多少次重复操作。与测试列表一样，这个配置也不能在测试用例装载之前被定义，除非这个测试用例已经被装载过，或者人为地添加了配置文件。

进一步扩展，对于数据驱动的测试用例，测试数据本身就是一种配置文件，其形态都是通过向代码传递数据来改变具体的测试逻辑。对于一些极端情况，这种测试数据可能并不是用户手动去配置的，而是根据测试逻辑自动生成的。比如我们测试一个ACL（Access Control List）的配置API，设置的规则包含很多字段，每个字段可以有一些属性，如表4-6所示。

如果我们要对所有的字段进行全覆盖测试，手工去写这个测试用例，就需要花很长的时间。所以一般我们会使用算法自动生成测试数据，然后提供给测试用例。

对于动态配置，其特点是没有特定的定义对象，需要在某些逻辑操作之后才能生成。配置的时间点可能在测试执行之前，也可能在测试执行过程中。

4.1.3 带有逻辑功能的配置

我们在进行配置的时候，有时也希望能够进行一些逻辑功能的实现。怎么理解这个逻辑功能的实现呢？来看下面的例子。

在我们测试设备或某个软件的过程中，除用一些用户感知的反馈结果可以简单地判断验证点是否正确外，有时还需要对一些“隐藏”对象进行检查，比如在设备或系统的日志文件中，是否有异常的打印输出。因为可能在用户层面，所有的表现都极为正常，但是其实在系统内部已经产生了一些异常，此时即便这个测试用例通过了测试，也可能因为异常的累积，在将来某个时刻导致系统的崩溃。这种崩溃如果是随机性的，很有可能导致每次结果失败在不同的地方，给测试结果的排查造成一定困难。

这时，我们希望所有测试用例在执行的过程中，可以实时地对系统的日志进行监控，一旦发现诸如某些代表异常的字符串出现，立刻判定为异常。但是很显然，这种功能如果一个测试用例一个测试用例地去开发，工作量会很大。所以我们希望这个配置不仅能通过配置文件来告诉测试平台需要抓取测试用例的日志，同时，测试平台根据相应的配置规则能在测试用例执行过程中执行相应的逻辑，如图4-1所示。

这种带有逻辑配置的扩展性能够给测试团队提供更灵活的执行方式，在不修改测试用例的情况下，增加更多的测试选项。