# devops测试流水线

从技术上讲，测试不应该分阶段进行。

在理想的情况下，软件测试的过程不会有离散的间隔。相反，测试将在整个编码过程中无缝地进行。然而，这并不是一个理想的世界，因此测试在整个开发生命周期中处于不均衡的集群中。在某些情况下，几乎不进行测试。在另一些情况下，开发过程中充斥着测试，但在bug到达生产环境之前，对它们进行补救可能为时已晚。

对于我们最新的信息图，我们决定代表一个理想的世界，一个测试在开发生命周期的每个阶段都平等地发生的世界。这是什么样子的


在软件开发过程中不应该有离散的测试阶段，同样，软件开发也不应该有离散的阶段(至少在DevOps下)。然而，为了帮助理解，我们已经尽我们所能把它分解了。

我们所说的代码阶段是指当你作为一个开发人员独自创建和更新产品代码的时候。这意味着您可能需要处理代码库的一个分支，该分支将包含一组提交。您正在进行的所有工作都反映在源代码的本地副本上。应该运行哪些测试

这是现实的检查，除非您真的致力于向左移动，否则您可能不会在软件开发阶段的早期测试和修复缺陷。即使在游戏的这个阶段测试没有技术障碍，许多公司还是不这么做。

在理想的环境中测试为什么要在编写代码的同时进行测试呢

让我们从结尾开始。与编写提交请求的测试相比，编写代码对测试有真正的好处。

重要的是，这可以防止您浪费精力。 如果您开始编码并创建错误或破坏现有测试，则很容易备份几行并重写它们-而如果仅在过程结束时进行测试，则可能会发现很多工作都取决于这些 几行错误代码。 这意味着您必须放慢速度并重写更多的工作，从而产生多米诺骨牌效果，最终可能会延迟整个项目。 这种延迟是DevOps哲学的厌恶。

此外，在SDLC的这一部分进行测试确实可以加强编码最佳实践。 如果错误一经发现就被识别出来，那么所学到的教训就会逐渐渗透到您的肌肉记忆中。 换句话说，早期测试可以使您成为更好的程序员。

在代码阶段创建测试工作流

您是开发人员，而不是专业测试人员，因此我们在代码阶段看不到测试的原因之一就是开发人员不想花时间在编码时间表上来创建和执行测试。 但是在mabl，我们专注于使测试变得容易，不干扰和自动化的方法。 例如，mabl用户可以创建工作流，在每次单击“ control + s”时，将使用CLI和本地运行程序在后台运行一系列端到端测试。 这使无头UI测试成为开发人员保存工作时的自动功能，从而易于将测试集成到代码阶段。

Mabl用户还可以根据自己的工作来构建一系列更具针对性的测试。 例如，如果它们在用户界面上工作，则现有的mabl测试将与该应用程序的特定功能相关联。 使用mabl，您可以在开始进行更改之前自动运行这些现有测试。 这些测试可以在开发生命周期的其他阶段中重复使用，从而减少了总体测试创建时间。

最后，在继续执行拉取请求之前，您应至少执行最后几个步骤。 这些不仅包括API和集成测试，还包括必要时添加新测试以及更新现有测试的步骤。 如果在应用程序中创建了新元素或工作流，则应编写一些新测试以反映这一点。 同时，您应该更新在编写新代码的过程中破坏的所有测试。

总而言之，在开发过程中尽早执行所有这些测试可以减轻以后的测试负担。 在开发的编码阶段进行路线校正要容易得多，这样做可以给您更多的时间来缓解以后出现的任何更严重的挑战。

# author

石头 磊哥 seven 随便叫

# company

thoughtworks（离职了。。。。）

大家好，本人不才，目前依旧混迹于thoughtworks，做着一名看起来像全栈的QA，兴趣爱好前端，目前是thoughtworks 西安QA社区的leader，如果有兴趣分享话题，或者想加入tw，可以找我

# roles

QA（营生） dev（front-end dev 兴趣爱好）

# 联系方式

如果想转载或者高薪挖我 请直接联系我 哈哈

# wechat:

qileiwangnan

# email:

qileilove@gmail.com