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

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

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

1.数据驱动测试

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

2.模块驱动测试

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

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036【暗号：csdn999】

3.关键字驱动测试

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

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

一个更复杂的例子如下。

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

优点：

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

测试案例简介；
测试案例可读性高；
测试案例易于修改；
新的测试案例可以很方便地反复已经存在的关键字。

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

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

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

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

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

缺点：

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

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

4.混合自动化测试

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

5.基于模型测试

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

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