彩票走势图

连续运行自动化测试似乎很容易。CI系统是关键，可为敏捷开发团队提供对其应用程序运行状况的及时可见性。如果自动测试通过，则该应用程序运行状况良好。如果测试失败，则应用程序会以某种方式损坏。还是？不幸的现实是，自动化测试并不总是给我们这样的信心，特别是在运行Selenium测试时。Selenium测试可能由于多种原因而失败，无论应用程序是否以任何方式损坏或更改。这些问题在上一篇博客文章（UI测试自动化：轻松摆脱Selenium问题）中进行了详细介绍。在这里，我将说明如何修改CI/CD管道以自动解决这些问题，从而提高对CI系统测试结果的信心。

Selenium CI的悲哀

CI/CD放大了Selenium测试问题。让我们看看这是怎么发生的。首先，开发会进行一些代码更改。CI系统检测到更改并触发构建管道。编译模块，运行并通过单元测试（是！），然后打包应用程序以进行部署。接下来，部署管道将触发下一步，搭建测试环境，部署被测应用程序，然后启动集成测试，其中许多测试是使用Selenium编写的。并非所有Selenium测试都通过了这一点，CI系统会通过电子邮件将测试失败通知各个人。这些人会做出反应，有时会花费大量时间进行调查和故障排除。产品所有者、经理和其他相关方也可以在仪表板上看到故障，从而将注意力从其他方面转移到其他方面。知道Selenium测试本身是不稳定的，那么谁能相信CI/CD报告了真正的回归或缺陷？排查误报浪费了多少时间？

简单地改进Selenium测试可能并非易事，有时涉及反复试验，尤其是在问题断断续续或难以重现时。从一个构建到另一个构建，可能会四处走动的故障，没有任何可归咎的测试。它们可能是系统问题，也可能是环境问题。CI系统可以使用性能特性不一致的VM或基于云的执行程序。测试在开发人员工作站上运行并通过，但CI自动化失败。听起来有点耳熟？

Selenium CI如何解决

开发是为了帮助应对此类挑战。Selenic可以自动分析和纠正Selenium测试问题，提供对这些问题的修复或洞察力，并在CI系统通知人类时使这些发现可用。负担转移到CI系统，而不是对来自CI系统通知的人员做出反应。仅需两个简单的步骤，即可使用自动完成将Selenium测试作为CI/CD管道的一部分进行修复的过程。

注入Selenium代理

要集成，您可以对现有的测试执行脚本进行单行更改。假设我在管道中有一个Maven执行步骤正在驱动基于Java的Selenium测试。通常，我指定两个Maven目标：“清除”和“测试”，这两个目标作为命令行参数传递给Maven。在这里，您只是添加了一个额外的Maven命令行参数：

-DargLine=-javaagent:${SELENIC_HOME}/selenic_agent.jar=selfHealing=true,sessionId=${BUILD_TAG}

在Jenkins CI中，这可能看起来像这样：

现在，只要在“SELENIC_HOME”变量所引用的位置安装并许可了Selenic，就可以将Selenic代理注入到测试执行过程中。Selenic代理可以做各种事情，但是出于稳定测试的目的，我仅启用“自我修复”功能，该功能试图实时识别和修复Selenium测试问题。

要仔细考虑的一件事是您的Selenium测试是否全部存在于一个模块中，或者是否存在多个模块中的测试。通常出于组织目的将测试分为多个模块。为了让Selenic聚合来自多个测试模块的信息，必须配置“sessionId”参数。在上面的示例中，我使用的是“BUILD_TAG”，它是Jenkins CI系统中的一个预定义变量，可以很好地实现此目的。无论使用哪种CI系统，我的建议都是使用CI系统提供的变量来构造唯一的会话标识符。

进行了单行更改后，Selenic会自动识别并纠正测试稳定性问题，使每个人对CI系统发布的测试结果更有信心。但是，我建议再集成一个Selenic组件。

运行Selenic Analyzer

我们如何知道Selenic发现了什么问题或纠正了什么问题？我应该对Selenium测试进行一些更改，以避免Selenic发现的问题吗？要获取此信息，您可以将Selenic Analyzer运行为管道中的另一个执行步骤。这是第二个单行更改，但仍然微不足道：

java -jar $SELENIC_HOME/selenic_analyzer.jar -report target/selenic-reports -sessionId ${BUILD_TAG}

在Jenkins CI中，这可能看起来像这样：

Selenic Analyzer收集早期由Selenic Agent记录的信息，对数据执行一些附加分析，然后构建一些报告，然后由CI系统将其存档。默认情况下，分析器处理来自最新会话的信息，但出于鲁棒性的考虑，我建议使用配置Selenic Agent时使用的相同值显式配置“-sessionId”参数。

Selenic Analyzer默认情况下将报告写入当前工作目录中。但是，为了使报告的归档更加容易，您应该添加“-report”参数来指示Selenic将报告写入项目的构建输出目录中的“selenic-reports”文件夹中。完成此操作后，您将在管道中再添加一个步骤来存档“target/selenic-reports/**”：

现在，通过CI系统，每个人都可以使用该报告文件。对于Jenkins CI，可以通过稳定的URL方便地访问报告：

//{ci_server}/job/{test_job}/lastSuccessfulBuild/artifact/target/selenic-reports/report.html

 //{ci_server}/job/{test_job}/lastSuccessfulBuild/artifact/target/selenic-reports/report.json

第一个URL指向可以在Web浏览器中直接查看的Selenic HTML报告。第二个URL指向JSON报告，开发人员可以将其提供给Selenic IDE插件，以从上一次自动测试运行中导入建议。

其他注意事项

Selenic还有许多其他选项，您可以考虑根据测试环境和其他特定需求启用它们。

Selenic记录每个测试会话的数据。记录的数据可作为知识库，使Selenic能够随着时间的推移学习并做出更好的自我修复决策和建议。默认情况下，此数据存储在执行测试的计算机上。因此，如果您有一个执行程序池，那么您希望此数据位于所有执行程序都可以访问的共享文件夹中。可以通过将“data={path}”参数传递给Selenic Agent和将“-data {path}”参数传递给Selenic Analyzer来显式配置数据位置，其中“{path}”将是共享文件夹的文件系统路径。在Windows上，这可能是UNC路径，例如\\HostName\SharedFolder。除非受到约束，否则记录的数据还将无限期累积。最终可能导致高磁盘使用率。可以通过将“maxSessionDaysToKeep={num_days}”参数传递给Selenic代理来配置记录的测试会话数限制。“{num_days}”是记录数据的天数，而不是日历天。换句话说，Selenic不会计算没有记录测试会话数据的任何日子。如果不经常地、以不固定的间隔运行测试，或者由于服务器停机而导致您错过了几天的运行测试，这将很有帮助。

Selenic还可以配置为以各种粒度级别捕获其他诊断信息。例如，可以将Selenic配置为捕获每个Selenium操作或仅针对失败操作的屏幕截图。要启用有关测试失败的屏幕截图，您可以将“screenshot= failures”参数传递给Selenic Agent。 Selenic Analyzer生成的HTML报告中提供了失败的屏幕截图。

CI/CD + Selenic = ❤

的构建旨在使用Selenium作为CI/CD的一部分来加速敏捷开发。开发人员和测试人员可以提高生产效率，减少追寻Selenium“幽灵”的时间，而将更多的时间用于处理真实事物。使用Selenic增强对Selenium测试结果的信心。。