paint-brush
建立一个完全隔离的端到端环境经过@marcinwosinek
511 讀數
511 讀數

建立一个完全隔离的端到端环境

经过 Marcin Wosinek5m2023/04/12
Read on Terminal Reader

太長; 讀書

片状测试是由于与您的代码无关的原因而失败的测试。在极端情况下,不稳定的测试会让您的团队忽略 E2E 结果。这可能会扼杀自动化质量控制 (QA) 的工作 这里介绍的方法解决了测试运行中潜在问题的两大来源。
featured image - 建立一个完全隔离的端到端环境
Marcin Wosinek HackerNoon profile picture

对于稳定的端到端(E2E)测试,我们需要一个尽可能与外界隔离的环境。

减少片状

片状测试是由于与您的代码无关的原因而失败的测试。它们使使用 E2E 作为应用程序正确性的可靠检查变得困难。在极端情况下,不稳定的测试会让您的团队忽略 E2E 结果。这可能会扼杀自动化质量控制 (QA) 的工作。


此处介绍的方法解决了测试运行中潜在问题的两大来源:


  • 由不同测试作业共享的后端存储的状态,以及


  • 您无法控制的外部服务。


还有其他不受此方法影响的片状来源:


  • 真正的问题出在随机出现的应用程序中,或者


  • 应用程序中的问题是由 E2E 与其交互的不自然速度引起的。

选择

在我和我的团队针对专用后端容器运行测试之前,我们使用了一个非生产服务器。这种方法在我们的 E2E 解决方案的实验阶段很好。


当只有几个测试时,我们无论如何都无法根据测试结果做出决定。


然而,随着我们继续添加更多测试并生成更长的执行时间,这种方法开始分崩离析。主要问题如下:


  • 即使我们试图恢复测试中的数据更改,一些测试失败也会留下意想不到的变化。


  • 并行工作正在发生冲突。不同的测试作业正在改变相同的状态,这通常会导致其中一项作业失败。

Docker化一切

这个问题的解决方案是为每个测试作业提供一个单独的后端服务器和数据库。如果不是 Docker,这种方法将非常具有挑战性。


Docker 容器是创建包含应用程序运行所需一切的封闭环境的完美工具:


  • 正确的操作系统(或者更确切地说,正确的 Linux 发行版),


  • 系统依赖项,例如图像处理库等,以及


  • 语言解释器(Python、Node 等)或数据库服务器的正确版本。

数据库

对于您的测试,您可以准备一个专用的数据库容器,其中包含可预测的测试数据。通过这种方式,您将能够准确地重现每次 E2E 执行中的起点,从而使您的测试更加稳定。


您可以为 Docker 镜像使用不同的标签,以对测试数据库进行版本控制。同样的测试数据库也可以用在开发环境中。对于开发中的手动测试,您需要与自动化测试类似的示例实体。

后端

如果您已经使用 Docker 来部署后端,那么重用相同的图像来运行 E2E 将非常容易。在我的团队中,我们将后端部署为容器,并提供数据库 URL 和凭证作为环境变量。


完全相同的容器版本可以部署在生产中或用于持续集成 (CI) 以运行测试——每个环境都提供正确的值来连接到数据库。

前端

根据您的部署策略,您可以执行以下操作之一:


  1. 使用您构建的容器作为前端构建的一部分。


  2. 获取编译后的文件并确保它们可通过 HTTP 用于测试。


在我们的例子中,我们使用选项 2:我们将应用程序部署为静态文件,因此我们只创建了一个专用容器来在 E2E 作业运行期间为构建的文件提供服务。

GitLab 中的工作服务

我们使用 GitLab 作为运行 CI 的平台。 GitLab 中的每个作业都在带有您选择的图像的容器中运行。除了主容器,您还可以定义服务:与测试一起运行的附加容器。配置非常简单:

 <job-name>: services: - name: <image> alias: <container-url>


可用选项类似于您在 Docker Compose 中的选项,但它们更受限制。

GitLab 配置中的一个“陷阱”是,如果您希望允许服务在测试运行期间相互访问,则将变量FF_NETWORK_PER_BUILD设置为 1。

考虑用于在职隔离的临时数据

在某些时候,我们在一个作业中并行运行所有测试。当时,有必要实施更强大的隔离——每个测试都使用相同的后端和数据库。


为了解决这个问题,我们升级了我们的测试,主要依赖于我们在测试的before一部分注入的随机数据。这允许测试运行不受其他线程中发生的其他更改的影响。


这种方法一开始可能有点棘手,但根据您的情况,它可能很有意义。

每次测试后清理

即使我们为每个测试作业启动一个新的数据库,我们仍然试图让我们的测试让应用程序保持与它们发现它时相同的状态。也许这有点像我们在共享环境中运行测试时遗留下来的东西。


它不再重要,但在以下情况下它仍然可以在测试开发过程中提供帮助:


  • 当你只运行一个测试时——所以测试遇到的状态与你运行文件中的所有测试时没有什么不同。


  • 当您一遍又一遍地在本地重新运行相同的测试时——这样数据库就不会受到之前运行的影响

模拟外部服务

在某些情况下,将服务移动到容器不是一种选择。例如:


  • 如果应用程序直接或通过某些后端代理使用外部服务器,或者


  • 由于技术问题,您拥有的服务器无法在容器内运行。


在这两种情况下,为了隔离测试运行,您可以模拟发送到这些服务的请求。这将使不可预测的外部服务不会影响您的测试结果。这种方法的缺点是您的测试将与您的应用程序运行的上下文断开连接。


有了模拟,当这些服务的变化影响您的应用程序时,您的测试将不会捕获案例。

继续学习

如果你有兴趣了解更多关于测试或其他编程相关的话题,你可以在这里注册,以便在我发布相关内容时获得更新。