在哪里能建免费的网站,免费个人博客注册,丹东有做公司网站的吗,怎么样做一个网站几代测试自动化框架 在开始自动化项目之前#xff0c;您需要了解需求#xff1b;您拥有哪些资源、需要自动化哪些内容、支持的平台等。但是#xff0c;框架有不同类型#xff0c;您需要仔细选择其中一种类型。您需要回答许多问题才能成功完成该过程。这里是其中的一些…几代测试自动化框架 在开始自动化项目之前您需要了解需求您拥有哪些资源、需要自动化哪些内容、支持的平台等。但是框架有不同类型您需要仔细选择其中一种类型。您需要回答许多问题才能成功完成该过程。这里是其中的一些
QA 工程师的技术水平如何 谁将负责维护和开发该框架 您的团队中是否有人在设计框架方面拥有丰富的经验 您有 DEV 团队的支持吗 您需要自动化的功能有多复杂 应用的需求是否稳定如果不是多久更换一次 这些只是您需要问的几个问题。我将撰写一篇关于它们的单独文章更详细地讨论所有内容。我在这里的观点是除了这些问题之外了解不同类型的测试自动化框架的历史和背景将有助于您进行选择。特别是对于新项目您不想生活在过去。几乎没有公司使用瀑布式开发软件而不使用敏捷方法或拥抱持续集成和持续部署。此外当我们要讨论新一代自动化时质量检查人员是/应该是非常好的程序员。抱歉写了“好”——测试自动化你应该是技术性的无论谁告诉你其他东西他都是在撒谎或者试图向你推销一些要花很多钱的东西。
第一代录制和回放 我什至不能将这种类型的自动化测试称为框架因为对我来说框架应该是几乎完全编码的东西。有些人将这种类型的自动化称为 线性脚本框架。
2023 年自动化测试将会发生什么
我们的 2023 年自动化测试报告探讨和评估了当前的测试趋势、测试架构和框架以及支持测试自动化的策略和工具例如人工智能和低代码。 测试人员不需要编写代码来创建函数并且步骤是按顺序编写的。在此过程中测试人员记录每个步骤例如导航、用户输入或检查点然后自动回放脚本以进行测试。
我能给出的最著名的例子是Selenium IDE。
硒集成开发环境
优点和缺点 您不需要编写自定义代码。您确实可以快速自动化一些简单的场景。
然而维持大量这些测试几乎是不可能的。自动化更复杂的场景是一个巨大的挑战。将这些测试集成到 CI 流程中、获得正确的报告并针对不同的工作环境进行配置是一件令人头疼的事情。
背景 — 质量保证和技术 当这些工具第一次出现时大多数公司刚刚开始从瀑布式到敏捷式的过渡。当时只有少数 QA 工程师如果这是正确的名字的话因此大多数测试都是手动的因为技术更简单。整个网络热潮才刚刚开始因此毫不奇怪大多数这些工具都支持网络录制和播放。后来出现了类似的桌面自动化工具例如Test Studio。然而由于新版本的发布并不经常发生因此雇用更多非技术人员并手动测试应用程序会更便宜。这就是为什么这些人的编码解决方案不起作用因为他们大多数人不知道如何编程。对于后代你会看到这种情况开始发生变化他们必须学习新技能才能保住工作。
第二代模块化和数据驱动的框架 基于模块化的测试框架 在记录和回放脚本中数据是硬编码的更复杂的场景几乎不可能编写。这就是为什么大多数供应商和开源工具开始支持导出到代码选项将录制的测试导出到流行的编程语言您可以在其中编辑和修改它。
同样最著名的例子是 Selenium IDE您可以将测试导出到 Selenium 后端代码然后导出到 WebDriver。
模块框架背后的整个想法是将应用程序分为不同的模块或导出的脚本然后将它们组合成更大的测试。例如您将有一个用于登录应用程序的模块另一个用于填写账单信息的模块还有一个用于提交票证的模块等等。在大多数情况下测试中的数据再次被硬编码。
数据驱动测试框架 由于对测试中的数据进行硬编码限制了不同步骤的组合并使创建新测试变得越来越困难因此出现了数据驱动框架。它们只是其他类型框架之上的一层例如基于模块或基于库的框架。
数据驱动测试框架帮助用户将测试脚本逻辑和测试数据相互分离。它允许用户将测试数据存储在外部数据库中。外部数据库可以是 XML 文件、Excel 文件、文本文件、CSV 文件、ODBC 存储库等。
优点和缺点 由于这些框架是经过编码的因此维护起来稍微容易一些因为您可以使用编程 IDE 的功能来修复测试。此外它们还显着增加了逻辑的重用。
但是由于大部分代码是自动生成的因此您必须重写它。由于抽象级别很低代码的可维护性仍然很低这导致了大量的复制粘贴。随着数据驱动框架的引入调试和故障排除变得更加困难。另外由于测试逻辑和测试数据是分开的测试的可读性较差。
背景 — 质量保证和技术 随着敏捷的采用项目开始变得更大、更复杂。人们开始觉得测试自动化可以帮助他们跟上步伐。但是正如我们所讨论的由于应用程序变得更加复杂因此需要一种更好的编写测试的方法。
QA 人员开始学习程序员的编程语言并开始导出测试希望通过最少的编辑实现自动化。数据驱动测试的引入有助于更快地实现自动化。但是就像完成一个新项目一样一开始每个人都试图无论如何都要完成它这意味着没有人知道跟上这个节奏并维持测试会有多困难。随着时间的推移维护测试的资源变得越来越大人们支持旧脚本比编写新脚本花费更多的时间。
第三代库和关键字驱动的框架 库架构测试框架 库架构测试框架从根本上是建立在基于模块的测试框架之上的并且具有一些额外的优点。我们不是将被测应用程序划分为测试脚本而是将应用程序划分为函数或者更确切地说划分为常用函数。该框架背后的基本原理是确定通用步骤将它们分组到库下的函数中并在需要时在测试脚本中调用这些函数。
例如在我担任 Telerik 的 QA 架构师期间我们拥有三个带有三个购物车的大型网站。正如您可以想象的那样开发人员实现两个额外购物车的最快方法是复制并粘贴代码并仅更改布局。基本上整个工作流程保持不变只有前端看起来不同并且网络元素有不同的定位器。当时我们有类似基于模块的测试框架。我们认为为两个额外网站维护相同的测试需要花费大量时间因此我们将基于模块的测试框架升级为库框架使用抽象外观来抽象整个工作流程。页面对象是此类框架的重要组成部分。
关键字驱动的测试框架 在关键字驱动的框架中被测应用程序的每个功能都布置在一个表中其中针对需要运行的每个测试按连续顺序排列了一系列指令。与数据驱动框架类似测试数据和脚本逻辑在关键字驱动框架中分离但这种方法更进一步。
在表中关键字以逐步方式与关联对象或正在执行操作的 UI 部分一起存储。为了使这种方法正常工作需要一个共享对象存储库来将对象映射到其关联的操作。
