本文转载自晨小菜订阅号，感谢大佬的分享

我们知道，在过去二十年UI端的自动化测试一直是我们项目上做自动化测试的重点。随着敏捷的发展，慢慢的越来越多人开始诟病UI自动化测试，觉得在UI端做自动化其稳定性和可靠性都比较差。

那么事实是否如此呢？UI自动化有没有提高的空间？刚好前两天我看到一篇文章，觉得这可能是对我们做UI自动化的一个借鉴，因此我把其核心内容翻译成中文，分享给读者。

作者：Yuri Bushnev

https://www.blazemeter.com/blog/top-15-ui-test-automation-best-practices-you-should-follow/

前言

在过去的几年里，我听到许多来自不同项目的工程师抱怨UI自动化测试的稳定性和可靠性。但它们真的如此不稳定和不可靠吗?相信我，他们不是！的确，UI自动化测试是一条艰难而危险的道路，可能会充满各种漏洞。然而，让UI自动化框架成为一条高速轨道，而不是一条陈旧且不稳定的乡村道路，这取决于您。

根据我的经验，我发现要创建一个设计良好且可维护的自动化框架，并使用非常稳定的测试，很难找到需要遵循的确切规则。这是因为每个规则都有很多例外。但尽管如此，有些原则是你应该遵守的，有些则是你不应该遵守的。

在本文中，我将总结并定义用于创建可靠且可维护的UI测试自动化框架的15个最佳实践。我们还将介绍这些原则的一些简单示例。此外，我还准备了一个完全工作的UI自动化框架，它是根据下面提到的这些原则创建的。您也可以将它作为您的框架的起点。

示例UI测试自动化框架和所有代码片段都基于Java编程语言。此外，我还使用了Serenity测试自动化框架作为我的解决方案的基础框架，这在我过去的几个项目中非常有效。但是，如果您计划在创建框架时使用的工具不是Java语言或Serenity，也不要担心。所有的原则都是相同的，一旦你理解了主要的概念，你就可以很容易地将相同的规则应用到你的情况中。

可以通过这个链接找到示例测试项目。请随意使用、使用、改进和分享您的想法!

https://github.com/BushnevYuri/web-ui-automation-best-practices

在我们深入探讨每个原则之前，为了方便您，我将简要介绍一下我将要讨论的最佳实践。因此，创建UI测试自动化框架的15个最佳实践如下:

• 不要仅依赖UI测试自动化

• 考虑使用BDD框架

• 始终始终始终使用测试设计模式和原则

• 除非有特定的测试需求，否则不要使用Thread.sleep()

• 不跨所有目标浏览器运行所有测试

• 将测试从测试自动化框架中分离出来

• 使您的测试自动化框架可移植

• 明智地为你的测试命名

• 如果需要在同一个web页面上创建相关检查的列表，请使用软断言

• 截屏进行故障调查

• 简化测试，而不是添加注释

• 遵循“绿色测试运行”策略

• 使用数据驱动而不是重复测试

• 所有的测试都应该是独立的

• 建立详细的自动化测试报告

01

不要仅依赖UI测试自动化

您首先应该考虑的一个主要的最佳实践是——不要仅仅依赖于UI测试自动化。理想情况下，您应该有信心，如果您从测试周期中删除整个UI自动化套件，您将能够在您的版本中捕获高达90%的现有bug。您需要始终记住，UI测试应该只是第三个防护盾，用于捕获在前两个级别上没有捕获的所有剩余问题。

我说的是哪个层次?

这是敏捷测试金字塔，最初由Mike Cohn设计，他是最成功、最聪明的敏捷和Scrum教练之一。它显示了在每个测试级别上实现的测试的推荐比例，如果您想要一个可靠的测试自动化流水线的话。

让我们来想想为什么金字塔是这样建造的。首先，低级测试本质上要快得多。单元测试比API测试快，而API测试比UI测试快得多。为什么这很重要?主要是因为更快的测试会给你更快的反馈。来自测试执行的更快的反馈使您能够尽早地捕获问题，从而节省了大量的成本。

其次，在QA自动化流水线中更早地执行低级测试。通常，在您的存储库中每次提交之前都会运行单元测试。如果您的项目是这样的，那么您甚至可以说，您不仅捕获了bug，而且还防止了bug，并且不让它们进入项目存储库。当然，这也为你节省了很多成本。

第三，低级测试比高级测试稳定得多。当有人问我为什么我更喜欢测试自动化框架中的低级测试时，我喜欢向他们展示这幅图。它很好地代表了低级测试(黑色)和高级测试(白色)的稳定性。这就是为什么，在自动化的过程中，我首先看到的是黑暗的一面……

这段开头提到的整个敏捷测试自动化金字塔在世界各地的许多著名公司中得到了成功的应用。这就是为什么我们选择将它包含在我们的最佳实践图表的顶部。

不要错误理解我的话。当然您应该总是运行所有这些测试类型！但是，如果您有一些可以完全被低级测试替代的高级测试，并且将它们放在UI套件中是多余的，那么您总是需要三思而后行。

02

考虑使用BDD框架

BDD是什么？BDD是一种软件开发方法，其中软件是按照描述其行为的方式实现的。如果您从未听说过这种方法，可以看公众号“晨小菜”里面的相关BDD的文章。BDD可以应用于任何类型的测试，包括单元测试、组件测试、集成测试以及许多其他类型的测试。UI测试是可以成功应用BDD的主要领域之一。出于许多原因，建议将BDD用于UI自动化。

首先，BDD是一种帮助团队相互理解、创建强大的团队内外协作的方法。通过使用BDD编写测试，您还可以创建能够帮助您的团队更好地理解测试和需求的规范。这意味着在编写测试的同时，还要创建一个清晰的测试文档。这确保了您不会浪费其他团队成员的时间(他们可能稍后会处理您的测试)以及您自己的时间，因为如果这些测试不清楚，您不需要解释和帮助。

其次，BDD帮助业务方面(例如，测试和项目经理)理解这些测试。这为测试带来了额外的价值，因为他们可以根据业务利益提出建议。

第三，BDD通常迫使您遵循严格的代码组织模式，这有助于避免代码重复。这是通过使用称为步骤或操作的独立组件来完成的，这些组件将成为测试的构建块。

现在让我们看一个简单的例子。假设我们想要编写一个非常小的测试来验证blazedemo.com网站上的基本工作流程。试着回顾一下测试场景，并理解它的作用:

这很简单，对吧?但是，让我们假设你是经理——你能轻松地阅读这些测试吗?或者假设您是一个新的团队成员，您必须检查现有的测试以了解它们的作用。你想复习一下这些测试吗?或者你更愿意看到同样的测试，像这样写:

第二个例子是在最著名的BDD框架之一Cucumber中使用Gherkin面向行的语言以BDD风格编写的相同测试。

即使您不喜欢用人类可读的文本文件编写测试，也有很多方法可以将BDD模型应用到您的测试中，不管它们是用哪种编程语言编写的。例如，你甚至可以在你的代码中加入BDD风格的注释:

03

始终始终始终使用测试设计模式和原则

设计模式是针对软件设计中常见问题的可重用解决方案。我们可以说，每个模式都是特定问题的特定解决方案的特定示例，而与编程语言或范例无关。补充设计模式，我们有设计原则。设计原则为您提供了构建良好且可维护的软件所需遵循的指导方针或规则。模式适用于特定的问题，而设计原则则不考虑上下文。

这与UI自动化测试有什么关系?正如前面所讨论的，UI测试是一条充满各种漏洞的艰难而危险的道路。但我有个好消息要告诉你。你不是这条路上的第一个司机。这就是为什么几乎没有人穿过的洞。您可以将设计模式和原则视为强大的导航器。一个告诉你通常如何安全驾驶(设计原则)，而另一个给出明确的指示如何处理每一个具体的洞，如果它在你的方式(设计模式)。

在本节中，我想讨论两种模式:Page Objects模式(它已经成为测试自动化工程师中最流行的web UI自动化模式)和Screenplay模式(它组织了Page Objects模式并对其进行了改进)。

Page Objects模式的概念是在大约10年前引入的。它的目的是使UI自动化测试保持一致，避免代码重复，提高可读性，并为web页面交互组织代码。在创建web测试时，您总是需要与web页面和在这些页面上显示的web元素(按钮、输入元素、图像等)进行交互。Page Objects模式接受这一需求，并在此基础上应用面向对象编程原则，强制您像与对象一样与所有页面和元素交互。

例如，如果您需要单击一个按钮，您不需要关心如何在测试中检索这个按钮，因为它已经在page objects中处理了。你应该有你正在寻找的页面的对象，它应该已经包含了你正在寻找的按钮的对象。你所需要的就是使用这个按钮对象的引用，并在其上应用“点击”操作。你可以像下图这样考虑所有的网页和网页元素:

对于您需要与之交互的每个页面和元素，您应该创建一个单独的对象，该对象将在您的测试中作为对这个web元素的引用。这是一个没有page objects模式的测试例子:

如果我们应用page objects模式并重构相同的测试，我们会看到完全不同的画面:

您可以在位置下找到这样一个测试的工作示例：

“/src/test/java/ui/pageobject/FindFlightsSimplePageObjectExampleTest.java”

综上所述，Page Objects给你带来了以下好处:

• 通过提供与页面和应用程序页面元素的交互，使您的测试更加清晰和易于阅读

• 组织代码结构

• 有助于避免重复(我们不应该两次指定相同的页面定位器)

• 节省了大量测试维护时间，并使UI自动化流水线更快=>降低成本

如果您想要使这个测试更清晰、更容易维护，那么您可以引入一个更高层次的抽象——步骤或关键字。在不同的框架中，您可能会看到这些模块的不同名称，但它们的原则是相同的。步骤(关键字)形成可以在任何测试中重用的操作模块。一旦编写了这些步骤(关键字)模块，您所需要做的就是在测试中引用该模块，并且可以使用这些特定模块提供的所有功能。

例如，如果我们创建一个模块，聚合所有与我们的网站上的航班搜索相关的功能，那么测试应该是这样的:

你可以在下面路径找到例子：

“/src/test/java/ui/pageobject/FindFlightsPageObjectWithStepsExampleTest.java”

但是，即使您使用Page Objects模式，您也可能迟早会遇到一个矛盾，这将使您陷入一个难以支持的框架中。为什么?因为除了设计模式之外，您还需要注意设计原则。

例如，当page objects模式成为一种称为“Large Class”的反模式的原因时，这是一种常见的情况。当某些页面上有太多的元素时，就会发生这种情况，因此表示页面的对象上的函数数量可能会变得非常大(这称为“Large Class”模式)。这违背了面向对象编程中最重要的设计原则之一，即SOLID:

• 单一职责原则（Single Responsibility Principle）

• 开闭原则（Open Closed Principle）

• Liskov替换原则（Liskov Substitution Principle）

• 接口替换原则（Interface Substitution Principle）

• 依赖性倒置原则（Dependency Inversion Principle）

它所违背的主要矛盾是单一职责原则，即每个类应该有一个单一的功能。Robert C. Martin(一位著名的软件工程师和SOLID的合作者)这样描述这个原则:“一个类应该只有一个改变的理由。”这就是为什么Page objects可能与这个原则相矛盾，因为Page类可以包含数百个执行许多不同操作的函数。

不用担心，我们不会详细介绍每个原则的含义。你可以在网上浏览许多文章来获得一个想法。但是您需要知道的是，为了遵循Page Objects模式的可靠原则，我们应该始终关注如何在页面和web元素之间分隔操作，并时不时地进行额外的代码重构，以保持框架的可维护性。

而Screenplay模式，这是设计从一开始就遵循SOLID原则。简单地说，screenplay是验收测试(包括UI测试)的设计模式，它允许您轻松地遵循可靠的原则。我建议您阅读这篇文章https://dzone.com/articles/page-objects-refactored-solid-steps-to-the-screenp，它将为您提供关于screenplay模式及其在UI自动化测试中的用法的出色解释。但即使不深入细节，你也可以复习一下我们之前用screenplay模式写的相同测试，然后自己感受一下不同之处:

这个测试看起来很棒，对吧?您可以在我们的测试项目中找到一个完整的工作示例，它是按照这些实践实现的。它位于:

“/src/test/java/ui/screenplay/ findflightsscreenplayexamtest .java”。

04

除非有特定的测试需求，否则不要使用Thread.sleep()

这是一条黄金法则，无论您的web应用程序有多复杂，您都需要遵循它。Sleep或确切的超时(更广为人知的名称是thread . Sleep()函数和类似函数)会在指定的确切秒数内阻塞测试线程。换句话说，它使您能够暂停测试。什么时候需要这样的功能?

web应用程序的行为取决于许多因素，如网络速度、您的计算机功能或应用服务器上的当前负载。由于所有这些因素，您不能总是预测加载特定页面或web元素所需的时间。这就是为什么有时您可能希望添加超时和暂停脚本检查执行至少一段时间的原因。

如果您不知道如何正确地处理这个问题，那么您将永远不会看到UI自动化的稳定性。

让我们假设在我们的测试中，我们将打开主页并验证主页的标题。非常简单。您只需要实现两个函数。一个用于打开页面，另一个用于验证是否提供了heading元素并具有正确的值。但是如果我们知道我们的应用程序可能需要7-8秒的时间来启动呢?

Selenium是一个web浏览器自动化工具，它的工作速度非常快，说实话，甚至比您还快。它可以在几毫秒内打开页面，并尝试在应用程序本身仍在启动时获取heading元素的文本。在这种情况下....请千万不要写这样的代码:

这是UI自动化测试稳定性的最大杀手。为什么?

• 我们会浪费时间，因为您知道在95%的情况下，应用程序应该在7-8秒内启动并运行。因此，每次我们都会损失2-3秒的执行时间。

你认为这算不了什么吗?我见过很多有3000个UI测试的项目。每次需要打开应用程序并等待它启动和运行时。也许你想在3个不同的浏览器上运行它?3000(测试)* 3(浏览器)* 2.5(平均损失秒数)= 22500(秒数)= 375(分钟数)= 6.25小时!总之，在这种情况下，我们失去了大约6个小时，只是因为我们不想正确地创造它。

• 如果应用程序加载一天需要10.5秒，会发生什么?只是因为网络慢了点。我们的考试会不及格。但当你第二天尝试在本地运行它时，它会运行得非常好。这是在测试中使用这种等待方式可能会遇到的麻烦的另一个例子。

我想你已经看出这很糟糕了，对吧?那么应该如何应对这种情况呢?您可以在主Selenium文档中找到答案——隐式和显式等待!完全按照这个顺序。隐式等待告诉浏览器为所有元素等待指定的时间。如果此时没有找到某个元素，则将此报告为失败。如果发现元素的速度快于指定的时间，则继续前进，不要一直等待。例如，如果隐式等待指定5秒，但是元素在2秒后出现，那么我们的脚本将不会等待其余的3秒。这为您的UI自动化测试节省了大量时间。

这是你可以通过使用Selenium在Java中指定隐含的等待:

那么显示等待是什么呢?显式等待是针对特定web元素或操作的加载时间比其他元素或操作长得多的情况而设计的。如果您的应用程序的启动时间很长(7-8秒)，但启动后运行非常快，该怎么办?仅仅因为应用程序加载缓慢而将隐含的等待指定为10秒甚至15秒是没有意义的。为此，您可以使用显式的wait，它在指定的时间内等待特定的条件。

下面是我们如何使用显式等待的思想重写我们之前的例子:

在这种情况下，我们也不浪费任何时间，脚本执行将在找到预期的元素后立即继续。

看起来清楚,对吧?不像你想的那么清楚…官方的Selenium网站显示了这样一个非常重要的提示:

不要混合使用隐式和显式等待。这样做会导致不可预测的等待时间。例如，将隐式等待设置为10秒，将显式等待设置为15秒，可能会导致在20秒后发生超时。”

您可以使用下面这两篇文章来了解为什么只使用显式等待更好，而且也足够了。

https://sqa.stackexchange.com/questions/12583/is-it-a-bad-practice-to-use-implicit-wait-in-selenium-webdriver-should-one-use

http://elementalselenium.com/tips/47-waiting

请大家继续留意“Python测试社区”公众号关注《您应该遵循的15个UI测试自动化最佳实践》（下），我们将继续分享剩下的11个最佳实践。

如果您还想了解更多测试的相关知识，请关注以下二维码：

备注：测试资料集合更新了，可在公众号后台回复989进行领取最新资料包，识别下方二维码关注，后台回复989 

识别下方公众号二维码关注，后台回复989 

并且推出福利测试技术进阶提升圈子点击原文链接或者戳链接查看详情：#测试提升圈#

觉得小编菜鸡点个赞