几代测试自动化框架
在开始自动化项目之前，您需要了解需求；您拥有哪些资源、需要自动化哪些内容、支持的平台等。但是，框架有不同类型，您需要仔细选择其中一种类型。您需要回答许多问题才能成功完成该过程。这里是其中的一些：

QA 工程师的技术水平如何？
谁将负责维护和开发该框架？
您的团队中是否有人在设计框架方面拥有丰富的经验？
您有 DEV 团队的支持吗？
您需要自动化的功能有多复杂？
应用的需求是否稳定？如果不是，多久更换一次？
这些只是您需要问的几个问题。我将撰写一篇关于它们的单独文章，更详细地讨论所有内容。我在这里的观点是，除了这些问题之外，了解不同类型的测试自动化框架的历史和背景将有助于您进行选择。特别是对于新项目，您不想生活在过去。几乎没有公司使用瀑布式开发软件而不使用敏捷方法或拥抱持续集成和持续部署。此外，当我们要讨论新一代自动化时，质量检查人员是/应该是非常好的程序员。抱歉写了“好”——测试自动化，你应该是技术性的，无论谁告诉你其他东西，他都是在撒谎，或者试图向你推销一些要花很多钱的东西。

第一代：录制和回放
我什至不能将这种类型的自动化测试称为框架，因为对我来说，框架应该是几乎完全编码的东西。有些人将这种类型的自动化称为 线性脚本框架。

2023 年自动化测试将会发生什么

我们的 2023 年自动化测试报告探讨和评估了当前的测试趋势、测试架构和框架，以及支持测试自动化的策略和工具，例如人工智能和低代码。

测试人员不需要编写代码来创建函数，并且步骤是按顺序编写的。在此过程中，测试人员记录每个步骤，例如导航、用户输入或检查点，然后自动回放脚本以进行测试。

我能给出的最著名的例子是Selenium IDE。

硒集成开发环境

优点和缺点
您不需要编写自定义代码。您确实可以快速自动化一些简单的场景。

然而，维持大量这些测试几乎是不可能的。自动化更复杂的场景是一个巨大的挑战。将这些测试集成到 CI 流程中、获得正确的报告并针对不同的工作环境进行配置是一件令人头疼的事情。

背景 — 质量保证和技术
当这些工具第一次出现时，大多数公司刚刚开始从瀑布式到敏捷式的过渡。当时，只有少数 QA 工程师（如果这是正确的名字的话），因此大多数测试都是手动的，因为技术更简单。整个网络热潮才刚刚开始，因此，毫不奇怪，大多数这些工具都支持网络录制和播放。后来出现了类似的桌面自动化工具，例如Test Studio。然而，由于新版本的发布并不经常发生，因此雇用更多非技术人员并手动测试应用程序会更便宜。这就是为什么这些人的编码解决方案不起作用，因为他们大多数人不知道如何编程。对于后代，你会看到这种情况开始发生变化，他们必须学习新技能才能保住工作。

第二代：模块化和数据驱动的框架
基于模块化的测试框架
在记录和回放脚本中，数据是硬编码的，更复杂的场景几乎不可能编写。这就是为什么大多数供应商和开源工具开始支持导出到代码选项，将录制的测试导出到流行的编程语言，您可以在其中编辑和修改它。

同样，最著名的例子是 Selenium IDE，您可以将测试导出到 Selenium 后端代码，然后导出到 WebDriver。

模块框架背后的整个想法是将应用程序分为不同的模块或导出的脚本，然后将它们组合成更大的测试。例如，您将有一个用于登录应用程序的模块，另一个用于填写账单信息的模块，还有一个用于提交票证的模块，等等。在大多数情况下，测试中的数据再次被硬编码。

数据驱动测试框架
由于对测试中的数据进行硬编码限制了不同步骤的组合，并使创建新测试变得越来越困难，因此出现了数据驱动框架。它们只是其他类型框架之上的一层，例如基于模块或基于库的框架。

数据驱动测试框架帮助用户将测试脚本逻辑和测试数据相互分离。它允许用户将测试数据存储在外部数据库中。外部数据库可以是 XML 文件、Excel 文件、文本文件、CSV 文件、ODBC 存储库等。

优点和缺点
由于这些框架是经过编码的，因此维护起来稍微容易一些，因为您可以使用编程 IDE 的功能来修复测试。此外，它们还显着增加了逻辑的重用。

但是，由于大部分代码是自动生成的，因此您必须重写它。由于抽象级别很低，代码的可维护性仍然很低，这导致了大量的复制粘贴。随着数据驱动框架的引入，调试和故障排除变得更加困难。另外，由于测试逻辑和测试数据是分开的，测试的可读性较差。

背景 — 质量保证和技术
随着敏捷的采用，项目开始变得更大、更复杂。人们开始觉得测试自动化可以帮助他们跟上步伐。但是，正如我们所讨论的，由于应用程序变得更加复杂，因此需要一种更好的编写测试的方法。

QA 人员开始学习程序员的编程语言，并开始导出测试，希望通过最少的编辑实现自动化。数据驱动测试的引入有助于更快地实现自动化。但是，就像完成一个新项目一样，一开始，每个人都试图无论如何都要完成它，这意味着没有人知道跟上这个节奏并维持测试会有多困难。随着时间的推移，维护测试的资源变得越来越大，人们支持旧脚本比编写新脚本花费更多的时间。

第三代：库和关键字驱动的框架
库架构测试框架
库架构测试框架从根本上是建立在基于模块的测试框架之上的，并且具有一些额外的优点。我们不是将被测应用程序划分为测试脚本，而是将应用程序划分为函数，或者更确切地说，划分为常用函数。该框架背后的基本原理是确定通用步骤，将它们分组到库下的函数中，并在需要时在测试脚本中调用这些函数。

例如，在我担任 Telerik 的 QA 架构师期间，我们拥有三个带有三个购物车的大型网站。正如您可以想象的那样，开发人员实现两个额外购物车的最快方法是复制并粘贴代码并仅更改布局。基本上，整个工作流程保持不变；只有前端看起来不同，并且网络元素有不同的定位器。当时，我们有类似基于模块的测试框架。我们认为，为两个额外网站维护相同的测试需要花费大量时间，因此我们将基于模块的测试框架升级为库框架，使用抽象外观来抽象整个工作流程。页面对象是此类框架的重要组成部分。

关键字驱动的测试框架
在关键字驱动的框架中，被测应用程序的每个功能都布置在一个表中，其中针对需要运行的每个测试按连续顺序排列了一系列指令。与数据驱动框架类似，测试数据和脚本逻辑在关键字驱动框架中分离，但这种方法更进一步。

在表中，关键字以逐步方式与关联对象或正在执行操作的 UI 部分一起存储。为了使这种方法正常工作，需要一个共享对象存储库来将对象映射到其关联的操作。