随着 Selenium 成为最受欢迎的选择，自动化测试已成为任何软件开发项目中不可避免的一部分。在持续测试、CI/CD 管道和 DevOps 的支持下，组织在设置自动触发测试方面进行了大量投资，希望从长远来看可以节省时间、成本和精力。
精心计划和编码的自动化测试将极大地帮助在开发的早期阶段发现错误。但是 Selenium 测试人员经常遇到的一个挑战可能会破坏整个生产力 -易碎测试!拥有 Flaky Selenium 测试套件到底意味着什么?在这篇关于 Flaky Selenium 测试套件的文章中，我们将讨论 Flaky 测试、Flaky Selenium 测试的常见原因、如何隔离、查找以及一些实用技巧以尽量减少它们。
让我们开始吧!
什么是片状测试?
确定性是有助于检测错误的自动化测试(或整个 Selenium 测试套件)的基本属性。如果测试始终提供相同的结果，则测试是确定性的，前提是代码没有引入任何更改。易碎测试是对相同代码随机通过或失败的测试，因此会给出不一致的结果。一次它会通过，另一次会失败，下一次又会通过，不会对构建进行任何更改。这种不确定的结果违背了自动化测试的主要目的。
例如，考虑在本地机器上的多个浏览器中运行测试套件的场景。然后，您的测试执行可能会受到在后台并行运行的其他进程、应用程序或浏览器会话的影响，竞争机器资源。在这种情况下，由于硬件限制，某些机器上的测试可能会失败，即使被测应用程序 (AUT) 本身没有错误。克服设备限制的流行解决方案是从本地测试切换到云测试平台。
片状测试有多常见?
幸的是，片状测试比您想象的更常见。最近对软件开发人员的一项调查发现，59% 的人声称每月、每周或每天都会处理不稳定的测试。在一个多月内收集了大量内部测试结果样本后，Google 发布了一份名为《持续集成测试状态@Google》的演示文稿，其中发现了一些有趣的见解。
从 Pass -> Fail 的 84% 的测试转换来自不稳定的测试
只有 1.23% 的测试曾发现破损
在他们的 420 万次测试中，近 16% 显示出某种程度的片状
片状故障经常阻塞和延迟发布
他们将 2-16% 的计算资源用于重新运行不稳定的测试。
谷歌得出的结论是：“测试系统必须能够处理一定程度的薄片”
为什么片状测试不好?
不稳定的测试会产生不一致的结果。它们没有明确指示软件错误的存在，因此限制了构建的可靠性。它们是不可取的。但是片状测试可能比你想象的更糟糕!
其中一些原因是：
不稳定的测试会削弱对测试的整体信任。它可以鼓励测试人员忽略测试失败并忽略实际缺陷，因为它们是测试不稳定的结果。这种情况称为测试结果疲劳。
它们会影响工程师的生产力，因为他们需要花时间重新编写、重新运行和重新检查测试。误报会消耗许多资源，这些资源可以用于更有价值的工作。
片状测试很昂贵。它们伴随着许多隐藏成本，例如创建、修复、执行、修复、业务和心理成本。
随着测试套件变得越来越广泛并且没有及时维护，片状商也随之增加。由于没有人愿意处理具有不可信结果的大型片状测试套件，因此测试人员可能会转向手动测试。现在，这减慢了开发过程。
不稳定的测试会减慢团队的进度和生产力，从而破坏开发体验。我们都同意浪费时间重新运行和调试可能没有错误的代码是令人沮丧的。在本文即将发布的关于 Flaky Selenium 测试套件的部分中，让我们深入探讨 Selenium 自动化测试中易碎的常见原因。
是什么导致了 Flaky Selenium 测试套件?
你可能想知道这种片状到底是从哪里来的?Selenium 是一种工具吗?答案是否定的。硒不是片状的。是你的测试不稳定。让我们稍微了解一下这个场景。
Selenium WebDriver语言绑定只是用于自动化浏览器的W3C WebDriver 协议的一个薄包装器。Selenium WebDriver 实现了一组由 W3C Webdriver 协议公开的 REST API，以按照规范执行相关的浏览器操作，例如启动浏览器、单击元素、在字段中输入输入等。
最新的Selenium 4通过 Webdriver API 的 W3C 标准化引入了重大的架构更新，并完全弃用了 JSON 有线协议。W3C 协议本身是确定性的，因此暗示 Selenium WebDriver 也是确定性的。Geckodriver 和 Chromedriver 等主流浏览器驱动也完全采用了 W3C 协议。简而言之，使用 Selenium 4，跨浏览器测试比以往任何时候都更加可靠和高效!
Selenium 测试套件中易碎的常见原因
以下是导致不稳定测试的关键问题以及获得构建稳定性的相应解决方案：
不稳定的测试环境
AUT 环境不稳定。
运行测试的机器的限制，如处理速度、内存等。
浏览器相关问题
用于运行测试的软件版本不正确。
网络连接不稳定，或连接速度慢，
第三方系统错误
第三方合同变更
不可靠的网络连接
缺乏同步
由于前端处理、加载繁重的组件、框架、内容等，页面加载需要时间。
来自 API 或数据库的延迟响应
异步处理
没有使用正确的“等待”策略。实际延迟时间取决于多种外部因素，测试脚本可能通过也可能不通过，这取决于代码中给出的延迟是否足够。
写得不好的测试
测试很大，包含很多逻辑。
该测试取决于之前的测试。
该测试使用固定的等待时间。
数据依赖
没有适当的测试数据准备
数据硬编码
在多个测试中使用相同的数据可能会导致数据损坏。
数据损坏是由正在使用和更改数据的其他同事造成的。
用户登录到门户
用户更改密码
定位器策略
没有有效地处理动态元素并使用根据 AUT 的渲染而变化的动态定位器
使用奇怪、冗长或硬连线的 XPath。
其他原因
框架中使用的模块配置不正确
使用不推荐使用的模块
使用不兼容的工具来测试应用程序。（例如：对于 Angular 应用程序，Protractor 将是比 Selenium 更好的选择）等。
您的测试环境是导致脆弱的 Selenium 测试套件的首要因素。这包括浏览器的主机、网络速度、网站的服务器、软件的性质等。常见的问题是：
不幸的是，这些基础设施挑战带来的随机性并不是我们可以完全控制的。项目可以使用基于云的测试环境，以获得稳定的环境。
2.与不可靠的第 3 方工具和应用程序集成
测试的不可预测性随着对测试环境的控制减少而增加。当您的测试用例依赖于不可靠的第三方 API 或由另一个团队维护的功能时，可能会出现不稳定的测试。
常见问题有：
Web 应用程序包含多个交互的层。这些层之间的交互方式直接影响应用程序的性能，包括 HTTP 处理、网络速度、源渲染、资源强度等方面。
因此，如果您正在测试一个对其他层或帧进行异步调用的应用程序，则可以预期操作可能需要不同的时间，并且您必须以等待调用成功完成的形式施加延迟。如果 AUT 和自动化测试之间没有同步，则测试结果可能会出现片状。
常见原因有：
另一个不足为奇且常见的原因是测试用例写得不好。一个糟糕的测试用例通常会导致结果的波动。
常见问题有：
测试数据问题也会导致测试失败。但是，它们很容易发现和修复。
常见原因有：
考虑以下两个测试用例共享相同的数据。
用户尝试通过输入其用户名和密码来登录门户。在另一个测试用例中，用户将密码更改为新密码。因此，在重新运行测试时，如果更改后的密码未重置为初始值，登录场景将失败。
导致片状测试的另一个关键原因是不可靠的定位器使用不当。
常见问题有：
例如，绝对 XPath 会带来不必要的僵化，并且冗长且容易出错。
1 | /html/body/div[3]/div/div[4]/div/div/div/section/div/div/article/div/form/div/div[4]/div/label |
6.无意调用负载测试
有时，您会在测试框架中引入不必要的复杂性，从而导致意外结果。一个这样的例子是启用并行执行。随着测试套件变得越来越大，通过并行测试减少整体测试执行时间是有意义的。但是太多的并行测试过程会放大测试的脆弱性。
并行测试的一个副作用是，它们可以通过对未准备好的软件施加大量负载来引入无意的负载测试。例如，考虑在测试开始期间所有测试都尝试使用相同的用户凭据登录到 AUT 的情况，这意味着同一用户同时发生了多个登录。另一方面，在这种情况下，测试可能在系列执行期间运行良好。
除了列出的原因之外，值得一提的还有几个不同的原因：
如何找到片状硒测试并修复它?
现在您知道了在您的测试套件中引入片状的常见原因，让我们探索如何找到片状硒测试并修复它。
由于 Flakiness 导致测试失败时出现的常见错误
首先让我们检查一下由于片状而导致测试失败时经常发现的一些错误或异常。
错误/异常
描述
ElementNotFoundException：即使 WebElement 存在于 UI 中，Webdriver 由于易碎而无法找到它。
ElementNotVisibleException：即使 WebElement 在 UI 中没有隐藏和可见，测试也会因片状而失败。
超时异常：当 Webdriver 等待 WebElement 可见时会引发此错误。尽管如此，该元素并没有出现在 Webdriver 的最大等待时间内，并且测试由于片状而失败。
无效元素状态异常：当您尝试与 WebElement 交互时可能会发生此错误，但它未处于执行所需操作的状态。
您可能无法完全消除 Selenium 测试套件中的脆弱性。但是，您可以按照以下步骤将片状测试的影响和不利影响降至最低。
修复 Flaky Selenium 测试套件的步骤
为您的项目采用正确的设计实践
编写小型且独立的自动化测试
每个测试都应该很小。
每个测试应该只有一个目的来测试一个特定的功能。
测试应该相互独立。
识别和隔离片状测试
记录片状测试
确定故障原因
一次修复一个不稳定的测试
将测试添加回稳定的测试套件
开始自动化测试的第一步也是最关键的一步是选择正确的测试框架。一个计划周密的框架不仅会相对减少脆弱的机会，而且易于维护和扩展。
考虑像页面对象模型(POM) 这样的方法来使您的框架健壮且可重用。POM 是 Selenium 中常用的设计模式，它创建一个对象存储库来存储所有 Web 元素。这种模式的主要目标是避免代码重复并增强代码的可重用性。
在编写自动化测试时，请坚持以下原则：
这有助于有效地分析测试失败的原因。您可以轻松地选择任何一组测试并以任何顺序运行它们。
修复不稳定测试的第一步是识别它们。定期多次运行测试套件并发现测试结果不稳定——最好每天或至少每周一次。一种有效的方法是使用任何 CI 服务。
与在本地机器上运行相比，实施 CI 服务将帮助您更频繁地运行整个测试套件。如果您想检测套件中的不稳定测试，您应该多次运行它们。使用 CI 测试，您可以安排您的构建在一天中的不同时间运行，并且您可能能够发现一些测试失败的模式。例如，A 测试在下午 4 点到 6 点之间失败。它非常适合在项目本身开始时实施 CI 服务。
分析后，您可以将测试分为两条不同的路径：稳定测试（绿色）和不稳定的易碎测试（红色）。您可以设置 CI 服务以定期为包含不稳定测试的分支安排构建，以识别和修复问题。这样，您可以轻松地将注意力分散在稳定和不稳定的构建之间。
目标是使最大的测试绿色化，以证明自动化增加了价值。
文档是优秀测试实践的一部分。一旦您确定了套件中的所有不稳定测试，请记录它们。一种流行的方法是创建票证。
将您获得的有关测试片状原因的信息添加到票证中。通过定期运行测试，您将能够收集平均测试运行时间、测试通过次数、正在测试的功能等数据。这将是跟踪和讨论修复测试的想法的好地方。此外，在片状原因很明显的情况下，请随时修复测试。
现在是时候调查为什么测试变得不稳定了。在某些情况下，测试失败的原因非常简单，例如错误的定位器、不正确的数据、错误的断言、页面加载时间等，并且可以快速关闭此类案例。但对于其他情况，您可能需要通过收集有关故障本身的更多信息来深入挖掘。
您可以实现在测试失败时触发的钩子。获取有关测试失败的数据，例如网页屏幕截图、错误日志、应用程序状态等，这有助于找出片状的罪魁祸首。分析为什么相同的测试会间歇性地通过和失败。
我建议您一次修复一个不稳定的测试。这将帮助您找到故障的根本原因，剖析问题并提供永久修复。尽可能多地进行测试并一次性修复它们可能很诱人。但实际上，从长远来看，这将花费更多时间，因为要找到故障的根本原因并创建永久性修复将具有挑战性。
您可以通过注释代码、监控日志、根据需要添加等待语句和断点等方式来调试问题。
测试确定后，通过多次运行测试来确保测试通过状态稳定。如果结果令人满意，即一致的成功运行，则将测试添加回稳定的测试套件。它并没有就此结束！多次重新运行稳定的测试套件以确保构建稳定。
在 Selenium 测试套件中减少 Flakiness 的技巧
消除片状和获得构建稳定性的几个基本策略是：
稳定您的测试环境
成本效益
高性能
更快的测试执行
可扩展性
定制
同步等待
使用可靠的定位器
始终寻找独特的定位器。
利用开发人员添加的静态 ID。
Web 开发框架生成的动态 ID 在每次页面加载时都会发生变化，从而使它们变得无用。因此，只针对动态 ID 的稳定部分。
如果您在 Selenium 中使用 XPath 或 CSS 选择器，请保持简短。
如前所述，不稳定的环境导致了不稳定的 selenium 测试套件。毫不奇怪，通常会忽略网络延迟、缓存问题、服务器错误、浏览器崩溃等方面。在修复不稳定的自动化 UI 测试的博客文章中，Emanuil Slavov 主张稳定他的测试环境有助于将通过率从 50% 提高到 100%。
稳定测试环境的一种流行解决方案是利用云测试平台。云测试的主要好处是：
另一种使测试结果不稳定的可靠方法是不正确地使用等待和睡眠。无法预测页面加载或异步请求完成的确切时间，这将触发不一致的结果。为了避免脚本中的不稳定，您需要区分隐式等待、显式等待和勤奋睡眠。
根据Alan Richardson的说法，同步问题是自动化失败的首要原因，并指出基于状态的同步是使其工作的解决方案。
另一个关键实践是使用可靠的定位器。选择独特的、描述性的且不太可能改变的定位器。任何不符合这些标准的都是错误的定位器，会导致测试失败。
几个最佳实践是：
结论
不稳定的测试对于自动化测试人员来说是一场噩梦。由于各种原因——不稳定的环境、不正确使用异步等待、错误的定位器等，将易碎性引入您的测试套件。每个测试人员都会不时地处理易碎的构建，这令人沮丧且调试耗时。
在这篇关于 Flaky Selenium 测试套件的文章中，我们讨论了 Flaky Selenium 测试套件、常见原因以及通过剖析测试失败的根本原因来查找和修复脆弱性以提高构建稳定性的最佳方法。即使您无法完全消除测试套件中的脆弱性，我们学到的措施也将帮助您将其最小化。此外，切换到符合 W3C 标准的 Selenium 4 将帮助您大大减少测试随机性。
希望这篇文章对您有所帮助，快乐测试!
常见问题 (FAQ)
你怎么知道你是否有一个片状测试?
在我们进行研究之前，发现不稳定测试的最有效技术是不断地重新运行失败的测试。如果一些重复通过，测试显然是不稳定的;但如果所有重新运行都失败，则状态不确定。
Selenium 测试是否不稳定?
不，您的测试是不稳定的，而不是硒。因为没有工具可以自动处理您的等待，所以最好正面面对问题并在某些页面对象中创建一些显式等待。
什么是自动化的脆弱性?
片状可以通过不可靠的测试运行系统引入。以下是常见原因的示例： 未能为被测系统分配足够的资源，导致无法启动。测试安排不正确，导致它们“碰撞”并失败。
卓码软件测评是一家[ 具备CMA、CNAS双重资质 ]的专业做软件测试的第三方软件测试服务机构, 可根据您的需求提供各类软件测试服务，并出具合格有效的软件测试报告。点击→→可了解测试报价
部分文字、图片来自网络，如涉及侵权，请及时与我们联系，我们会在第一时间删除或处理侵权内容。负责人：曾菲 电话：4006070568