集成测试仍然是CI / CD生产周期的重要组成部分，包括容器化应用程序的开发。 通常，集成测试时间不会很长，但是会占用大量资源。 让我们看看如何将集成测试技术和工具与容器编排工具（尤其是
Red Hat OpenShift ）结合起来，以加快测试速度，提高其动态性并更有效地利用资源。
让我们使用
Cucumber ，
Protractor和
Selenium创建集成的BDD测试（
行为驱动的开发 ），并使用Zalenium在OpenShift平台上运行它们。
BDD测试
在开发集成测试时，BDD允许业务分析师（BA）创建集成测试的定义，而不仅仅是程序员。 借助BDD，可以组织开发过程，以便同时准备功能需求和集成测试的定义，并同时由业务分析师创建它们。
当您首先确定应用程序的业务功能，然后由质量控制部门（QA）创建集成测试时，这比传统方法要好得多，如下图所示：
这是使用BDD时的外观：
另外，在这种新方案中，每次迭代通常花费更少的时间。
业务分析师可以为集成测试创建定义，因为BDD用一种简单易懂的
Gherkin语言描述了这些测试，其主要关键字为Given，When和Then。 小黄瓜语言中的每个陈述都必须以以下单词之一开头。
例如：给定用户导航至登录页面（假设用户已访问登录页面）
用户输入用户名和密码时
用户名和密码正确时
然后系统将其登录（然后系统允许他登录）Cucumber是一种可以解释Gherkin测试的流行运行时。 要使用Cucumber，开发人员必须实现某些功能，以便可以执行任何Gherkin指令。 黄瓜具有与许多编程语言的绑定。 建议（但不是必需）以与被测应用程序相同的语言编写测试。
测试技术栈
让我们
看一下在
AngularJS实施中使用
TodoMVC网络应用程序示例的测试过程。 AngularJS是用于创建单页应用程序（SPA）的流行框架。
由于AngularJS是JavaScript，因此我们将使用
Cumcumber.js ，将Cucumber绑定到JavaScript。
为了模拟用户在浏览器中的工作，我们将使用
Selenium 。 Selenium是一个过程，可以启动浏览器并播放用户对通过API接收的命令的操作。
最后，我们将使用
Protractor来考虑模拟用AngularJS编写的SPA应用程序的细微差别。 量角器将照顾页面中的视图正确加载的期望。
因此，我们的测试堆栈如下：
该图中显示的过程描述如下：
- 当Cucumber测试运行时，Cucumber从Gherkin文件中读取测试定义。
- 然后，它开始调用测试代码实现代码。
- 测试脚本实现代码使用量角器在网页上执行操作
- 发生这种情况时，量角器将连接到量角器服务器，并通过API向Selenium发出命令。
- Selenium在浏览器实例中执行这些命令。
- 如果需要，浏览器将连接到Web服务器。 在我们的示例中，使用了SPA应用程序，因此不会发生这种连接，因为从首页的服务器加载时该应用程序已经加载。
在非容器化的基础架构中部署此类堆栈并不容易。 这不仅是因为使用了大量的过程和框架，而且还因为在没有监视器的服务器上启动浏览器一直很困难。 幸运的是，在容器化的世界中，所有这些都可以自动化。
集成测试场
企业Web应用程序需要针对客户端操作系统和浏览器的各种组合进行测试。 通常，这仅限于某些基本选项集，这些选项集反映了应用程序最终用户的计算机上的情况。 但是即使在这种情况下，每个应用程序的测试配置数量也很少会降到六打以下。
如果您为每个测试配置一致地部署一个堆栈并在其上运行相应的测试，那么这在时间和资源上都太昂贵了。
理想情况下，我想并行运行测试。
Selenium-Grid可以为我们提供帮助-一种解决方案，其中包括Selenium Hub请求代理和一个或多个在其上执行这些请求的节点。
每个通常在单独服务器上运行的Selenium节点，都可以针对客户端操作系统和浏览器的特定组合进行配置（在Selenium中，节点的这些和其他特征称为功能-属性）。 同时，Selenium Hub足够智能，可以将需要某些Selenium属性的请求发送到具有这些属性的节点。
Selenium-Grid集群很难安装和管理，以至于提供相关服务的公司甚至出现在市场上。 特别是，SauceLabs和BrowserStack是主要参与者。
基于容器的集成测试
很多时候，我希望能够创建一个Selenium-Grid集群，该集群将为我们的测试提供必要的Selenium属性，并以高度并行化的方式运行测试。 然后，在测试完成之后，我希望能够完全销毁该群集。 换句话说，要学习如何以集成测试场的提供者自己的方式工作。
该技术领域仍处于早期形成阶段，但是，一个有前途的开源项目
Zalenium可满足我们的一些需求。
Zalenium使用经过修改的集线器，该集线器可以按需创建节点，并在不再需要它们时销毁它们。 Zalenium当前仅在Linux平台上支持Chrome和Firefox浏览器。 但是随着Kubernetes的Windows节点的出现，可能会出现对Windows上的Explorer和Edge的支持。
如果将所有内容放在一起，那么技术堆栈如下：
图中的每个椭圆都是Kubernetes中的一个单独的pod。 测试播放器和仿真器的豆荚是短暂的，在测试结束时被破坏。
在CI / CD管道内执行集成测试
让我们在Jenkins中创建一个简单的管道，以展示如何将这种类型的集成测试集成到发布管理过程的其余部分中。 看起来像这样：
您的管道可能会有所不同，但是您仍然有机会重用集成测试阶段，而无需进行大量的代码重构。
由于大多数炉膛都是短暂的，管道的任务之一就是收集测试结果。 在Jenkins中，这可以使用archive和publishHTML原语来完成。
这是报告测试结果的示例（请注意，测试是在两个浏览器上运行的）：
结论
因此，尽管组织端到端集成测试基础架构很复杂，但“基础架构即代码”方法简化了过程。 在OS和浏览器的各种组合上执行集成测试需要大量时间和资源，但是容器编排工具和临时工作负载有助于解决此问题。
即使没有成熟的工具来组织面向容器的集成测试，基于容器平台的集成测试也已经可以在今天进行，并且可以利用容器方法。
如果要开发容器化的应用程序，请尝试在CI / CD管道中使用此方法，看看它是否有助于简化集成测试。
本文的示例代码可在GitHub网站上的redhat-cop / container-pipelinesh中找到。