软件测试 | 常见的自动化测试架构

一个自动化测试架构就是一个集成体系，其中定义了一个特殊软件产品的自动化测试规则。这一体系中包含测试功能函数库、测试数据源、测试对象识别标准，以及各种可重用的模块。这些组件作为小的构建模块，被组合起来代表某种商业流程。自动化测试架构提供了自动化测试的基础，降低了自动化测试的难度。

常见的自动化架构包括如下。

1.数据驱动测试

数据驱动测试将测试脚本与测试数据放在同一测试架构中。该测试架构提供可重用的测试逻辑，目的是减少测试维护工作量和改善测试覆盖率。测试输入数据和测试结果数据都会被存储在一个或者多个数据源/数据库中，数据存储格式和数据组织方式依赖于具体实现。测试数据与测试逻辑分离，当测试数据发生改变时，不会影响测试逻辑。同一个测试逻辑可以针对不同数据来进行测试，提高了测试逻辑的使用效率和可维护性。

2.模块驱动测试

模块驱动测试使用独立的小脚本来对应待测系统的模块、零件和子功能。这些不同层级的小脚本按照一定规则，组合成更大级别的测试，如此就实现了一个特定功能的自动化测试案例。在所有自动化测试架构中，它应该是最容易领回和控制的一种。有这样一种编程策略，它的应用非常广泛，即屏蔽组件的内部实现，仅提供组件的对外抽象接口。如此下层的测试组件发生变动时，对上层自动化测试案例来说是透明的。“模块驱动测试”引入了抽象和封装的原则，目的是提升自动化测试的可维护性和可扩展性。

3.关键字驱动测试

关键字驱动测试也被成为“表格驱动测试”或者“操作名测试”，它是一种软件自动化测试的方法论。它将自动化测试的创建过程分为两个不同的阶段：设计阶段和实现阶段

（1）设计阶段的一个简单例子如下。

一个更复杂的例子如下。

（2）实现阶段依赖于具体使用的测试工具，通常自动化测试引擎会提供设计阶段定义的关键字，类似于“check”或者“enter”。测试人员基于这些关键字来编写测试案例。测试案例执行时，会有一个驱动程序来读取这些关键字，并执行响应的代码。

优点：

1.在一个较长的软件维护周期内，显著减少维护工作量，使得：

• 测试案例简介；

• 测试案例可读性高；

• 测试案例易于修改；

• 新的测试案例可以很方便地反复已经存在的关键字。

2.关键字可以跨越多个测试案例进行复用

3.不依赖于某种语言或者某个工具

4.让员工集中精力在自己所擅长的地方，比如：

• 测试案例的构建需要专业领域知识——不需要太多编程/测试工具知识；

• 关键字的实现要求丰富的测试工具/编程知识——不需要太多的专业领域知识。

5.可以对自动化测试划分抽象层级

缺点：

1.创建自动化测试需要更长的时间（相比于手工测试和录制/回放技术）。

2.需要更长的学习、掌握周期。

4.混合自动化测试

混合自动化测试是由其他自动化测试框架综合发展起来的。成功的自动化测试框架，通常都融合了“关键字驱动测试”和“数据驱动测试”。它们即拥有测试逻辑与测试数据相互分离的优点，又集成了关键字驱动的先进架构。这一架构会使得数据驱动脚本更加简洁，并减小运行时意外失败的可能性。另一方面，该架构可以实现一些纯粹的“关键字驱动测试”难以实现的自动化测试任务。该架构由核心数据驱动引擎、功能函数组件，以及支持库所构成。

5.基于模型测试

基于模型测试适用于采用“基于模型设计”的软件系统。在这种架构下，会有一个成熟的测试模型来描述测试数据的所有方面，以及测试案例和案例的执行环境。通常这一测试模型是全部或者从待测系统功能模型中提取出来的。测试模型描述了待测系统的抽象行为，因此从测试模型中可以派生出功能测试案例。这些测试案例构成了抽象测试案例集，不过抽象测试案例集不能直接在待测系统上执行。真正可以执行的测试案例集（可以与待测系统进行交互），是从抽象测试案例集派生出来的。有些基于模型测试的测试工具，支持从模型（包含足够信息）产生可执行测试案例集，如图 1-1 和图 1-2 所示。

从模型派生出案例，可以有很多种方式，因为测试很多时候是依靠经验去尝试，并没有固定的最佳方法。你需要事先收集“测试需求”、“测试目标”、“用户用例”，因为它们包含待测系统模型的信息。测试案例集是从模型二非代码派生出来的，因此基于模型测试可以被视为某种黑盒测试。事实上，基于模型测试目前只适合于功能不太复杂的软件系统，复杂商业软件系统的基于模型测试，还处在探索阶段。

注：IXIT—“implementation extra information”，其中包含将抽象测试案例集转换为可执行测试案例集需要的所有信息。通常其中包含数据映射、待测系统配置、测试装备等。

搜索微信公众号：霍格沃兹测试学院