一文彻底吃透自动化测试框架所有知识，看完就可以直接独立搭建自动化测试框架

自动化测试虽然目前很受欢迎，但并不意味着所有企业和项目可以适用，对于定制型、周期短、简单测试类型的项目并不适合做自动化测试。不可否认的是，如果可以执行自动化测试框架，确实可以为开发和测试带来很多的好处：

自动化测试框架和自动化脚本都可以最大程度地减少编写和运行测试所花费的时间，从而可以在短时间内获得最大的输出，提高测试效率。

当我们使用现有组件库中的代码时，它仍然是可重复使用的，并且其他所有相关的任务（如报告、同步和故障排除）都可以更方便访问。

定义测试自动化
在任何行业中，自动化通常被解释为自动处理流程，而这些流程几乎不需要人工干预。在软件行业，测试自动化意味着使用许可版本或开源的自动化工具对软件应用程序执行各种测试。用技术术语来说，测试自动化框架是一组定制的交互式组件，它们有助于执行脚本化测试和全面报告测试的结果。

不同类型的框架
团队根据团队规模、经验水平、用户需求等因素来选择测试框架，可以分成不同的测试框架类型。

1、线性框架
这是最基本的框架类型。它通常被称为“记录和回放(record and playback)”框架。

在这个过程中，测试代码的创建和执行是按线性或顺序编写的——测试人员手动记录每一个步骤，并自动回放记录的脚本。这些步骤包括导航、用户输入和检查点。它最适合小型应用程序或团队。

在此过程中，测试代码的创建和执行以线性或顺序方式编写-测试人员手动记录每个步骤并自动播放记录的脚本。这些步骤包括导航，用户输入和检查点。最适合小型应用程序或小团队。

优点：线性框架最大的好处是生成测试用例的速度快，直接录制；无须代码基础，无须手动编写测试代码，因此门槛较低、易于上手。

缺点：然而线性框架的不足之处也很明显：录制的脚本是固定的(hardcode)，不可重用。这意味着，当应用发生微小变化时，上一次录制的脚本可能就无法使用了，需要重新录制(rework)，从而产生大量的后期维护成本。

2、基于模块化的框架
顾名思义，此框架允许将被测应用程序划分为单独的模块，单元或部分。每个模块都会为它们创建独立的测试脚本。因此，每个模块及其测试脚本的组合可以构建代表各种测试案例的更大的测试。

优点：该框架在创建模块时使用抽象。因此，应用程序更改将只影响与它们相关联的测试脚本所涉及的模块，而不影响其他部分。

高度的模块化，这使得维护更加容易且具有成本效益

创建测试用例所需的精力最少，因为可以重复使用不同模块的测试脚本。

缺点：如果没有语言开发基础，则建立框架可能会很困难。

由于将数据硬编码到测试脚本中，因此无法重复使用数据集——因为测试是单独执行的。

3、库结构框架
该库体系结构框架建立在模块化框架的基础上，但具有其他好处。这样做的好处是，它不仅可以将被测应用程序划分为测试脚本，还可以将测试脚本中的相似任务划分为通用功能。

然后创建一个库，该库构成了AUT的常用功能，可以在需要时由测试脚本调用。

优点：高度的模块化，这使得测试维护简单且预算友好。

它具有高度的可重用性，因为它的公共函数库可以被几个测试脚本使用。

缺点：框架中引入的库使其更加复杂。

测试数据也被硬编码到测试脚本中。因此，数据中的更改必须适用于测试脚本。

测试脚本的开发需要更多的时间和技术。

4、数据驱动框架
在数据驱动框架中，测试数据和测试脚本是分离的。在许多测试场景中，需要使用不同的测试数据多次测试同一功能或特性。如果测试数据是hardcode进测试脚本的，那么每更换一次测试数据都需要修改测试脚本。这是很大的工作量。此时，可以使用数据驱动框架。具体来说，测试脚本是固定的，而测试数据可以从外部的数据文件，以Excel、CSV、SQL等形式作为参数传入测试脚本。这样，我们只需要维护一份脚本和一份数据文件即可。

优点：总体来说，这种框架最大的好处就是易于维护。

测试脚本中的任何更改都不会影响测试数据。因此，可以避免对数据进行硬编码。

可以使用多组数据进行测试。

可以通过更改外部数据库中的测试数据来测试各种测试方案，从而减少所需的测试脚本数量。

缺点：准备和计划框架的通用测试脚本，识别与格式化测试数据需要花费时间。

框架设计的使用需要经验丰富的测试人员，因为它的复杂性，需要具备多种编程语言知识。

5、关键字驱动框架
该框架是数据驱动框架的扩展。测试数据和测试脚本也被分离，不同的是，该框架要更进一步地将测试脚本中的通用功能剥离出来，形成关键词(keyword)。测试脚本本质上就是对一系列通用的或者自定义的关键词的调用。这样做的好处是关键词可以在多个测试中复用，并且测试脚本更加易于维护。不过，实现这样一个框架并非易事。

优点：与数据驱动不同，运行此框架不需要脚本知识。

可以独立于被测应用程序构建测试脚本。

一个关键字可以在多个测试脚本中使用。因此该代码是可重用的。

缺点：设计框架和维护关键字对自动化的专业知识要求比较高。

实现该框架的成本相对较高，而且设置起来也比较耗时和复杂。

综上所述，实现用于自动化测试的框架需要选择一种灵活的工具。该工具应支持广泛的应用程序，并满足测试要求。另外，应该有正确的策略来定义应该自动化哪些部分。

自动化框架的主要组件
大多数功能强大且性能卓越的测试自动化框架（无论是开源还是商业的），则必须考虑包括构成其核心的某些组件。

基于各种测试的理想测试自动化框架的主要组成部分是：
测试库
单元测试
单元测试库可用于塑造任何测试自动化框架的重要组成部分。需要它用于：
通过特定的形式注释定义使用的测试方法
执行影响自动化测试最终结果的断言
运行简单明了的测试
集成和端到端测试
在执行集成和端到端测试自动化时，通常建议保证现有测试库提供的功能是稳定的。由应用程序的UI驱动的API级别的测试需要使与被测应用程序进行交互变得更加容易的组件，因为它不可避免的需要用到编码的工作。因此可以花更多精力专注于其他方面的工作。

行为驱动开发
专用于BDD的库以行为规范为目标，以可执行代码的形式创建可执行规范。在这里，可以将不同的功能和预期行为场景转换为代码，尽管它们不能像测试工具直接与被测应用程序进行交互那样工作。它们可作为BDD流程的支持，以创建与自动化测试的范围和意图一致的实时文档。

测试数据管理

在软件测试自动化和测试创建过程中，最大的挑战是利用测试数据管理系统。随着自动化测试数量的增加，始终存在确保执行特定测试所需的某些测试数据可用或创建的问题。面临的挑战是，没有针对此问题的万无一失的解决方案，这需要一种可靠的测试数据管理方法来使自动化工作取得成功。

解决此问题的一种方法是使用moco工具，以使数据更加简化，清晰和易于消化。

软件测试中的虚拟化
在探索和研究自动化测试的许多想法时，可能会遇到以下情况：

想将模块与通常在单元测试中经历过的连接组件隔离开

需要处理应用程序的集成或端到端测试中常见的繁琐和关键的依赖关系

在这种情况下，测试人员会觉得创建反映所连接组件行为模式的mock和Stubs以及虚拟化至关重要。处理这些内容是一项艰巨的任务，在开发自动化测试框架的过程中选择有用的虚拟化工具至关重要。

测试结果报告
在选择用于将测试结果报告到自动化框架中的库或机制时，应该主要关注将要阅读或查看所生成报告的目标受众。在这方面，我们可以提出几个注意事项：

诸如JUnit和TestNG之类的单元测试框架生成的报告主要针对诸如CI（持续集成）服务器之类的接收系统，这些系统最终会对其进行解释并以其他软件可使用的XML格式进行呈现。

当我们寻求具有人类最易理解的语言的报告功能的工具时，需要考虑使用与单元测试框架兼容的商业工具，例如用于Junit的UFT Pro、NUnit和TestNG。

另一种选择是利用第三方库，该库以人类易于理解的格式创建测试结果报告，包括通过饼图，图形或图像进行的视觉解释。

源代码管理
与手动测试一样，自动化测试也涉及编写和存储源代码和测试用例版本。每个开发公司都有一个源代码和版本控制系统来保存和保护源代码。自动化测试需要完善的源代码管理系统，该系统在处理生产代码时会派上用场。

创建依赖关系管理器
依赖关系管理器的主要目的是协助收集和管理在自动化软件解决方案的功能中使用的现有依赖关系和库的过程。某些工具（例如Maven和Gradle）同时充当依赖项管理器并帮助构建工具。构建工具旨在帮助您从源代码和支持库开发自动化软件，并运行测试。

建立和实施框架的过程
有几种方法可以计划实现自动化测试解决方案的方法。

从用户的角度探讨自动化的实际适用性。从各个角度检查它是否如PPT中所讲（避免PPT自动化的最佳实践），在使用中的技术上对其进行测试。

密切关注被测系统的技术，以找到能够完美模拟用户行为的最合适的测试自动化工具，这一点至关重要。

建议采用基于阶段的实现方法，其中每个阶段都具有交付自动化测试脚本的优先级，同时添加框架功能以实现预期的脚本执行。

在启动软件测试自动化之前，为确保正确执行自动化决策，必须首先计算和估算实施后的投资回报率，运行手动回归或冒烟测试的时间以及每个版本的运行周期。

加油吧，如果你需要提升技术储备，那就行动，在路上总比在起点观望的要好。一切的迷茫都是因为想得太多而做的太少！

以上就是今天的分享，如果觉得有用，欢迎分享转发给更多朋友。

欢迎在留言区跟我们互动噢~