🤭 🤸🏼 🐪 对End-2-End测试只说不 💬 👇🏻 🦁

当您和您的朋友们真的想看电影时，您可能会遇到这种情况，然后后悔您花了很多时间在电影上。也许您还记得当您的团队认为仅在产品发布后才发现“杀手功能”并发现其“陷阱”的那一刻。

好的想法通常在实践中会失败，在测试领域，基于端到端测试自动化的测试策略就是一个很好的例子。

测试人员可以将时间花在编写许多类型的自动化测试上，包括单元测试，集成测试和2端测试，但是该策略主要针对对2个产品或服务进行整体测试的2端测试。通常，这些测试模仿真实的用户方案。

资源

理论上的2端测试

尽管主要依靠端到端测试不是一个好主意，但从理论上讲，您可以提出一些支持该声明的论点。

因此，众所周知，在Google列出的十件事中，第一名是“用户的利益高于一切”。因此，使用针对实际用户场景的端到端测试似乎是个好主意。另外，该策略通常对该过程中的许多参与者具有吸引力。

开发人员喜欢这种策略，因为您可以将大多数（如果不是全部）测试转移给其他人。
, , , , , , .
, , ; .

End-2-end

那么，如果这种测试策略在理论上看起来如此出色，那么实践中有什么问题呢？为了证明这一点，我将在下面给出一个虚拟的场景，但这是基于我和其他测试人员所熟悉的真实情况。

假设一个团队创建了一项用于在线编辑文档的服务（例如Google Docs）。让我们假设团队已经有了一些出色的测试基础架构。每天晚上：

构建最新版本的服务，
然后将此版本部署在团队测试环境中，
然后在此测试环境中运行所有端到端测试，
该团队会收到一封电子邮件报告，其中总结了测试结果。

截止日期快到了。假设要保持较高的产品质量，我们决定至少需要90％的成功的2－2端测试，以便我们认为该版本已准备就绪。假设最后期限是一天之内。

尽管存在许多问题，这些测试最终还是显示出真正的错误。

进行得很好

识别影响用户的错误，然后将其发现并纠正。

出问题了

团队在一周后完成了编程阶段（并加班了很多）。
查找失败的端到端2端测试的根本原因很耗时，可能会花费很多时间。
并行团队的故障和设备故障将测试结果推迟了几天。
许多小错误隐藏在大错误之后。
2端测试结果有时是不可靠的。
开发人员必须等到第二天才能确定修复程序是否有效。

因此，既然我们知道端到端策略中出了什么问题，我们就需要更改测试方法来避免上述许多问题。但是正确的方法是什么？

测试的真正价值

通常，测试失败时，测试人员的工作便会结束。错误被记录下来，然后开发人员的任务是修复错误。但是，要确定端到端策略在哪些地方行不通，我们需要超越这一思维，并使用我们的基本原理来解决问题。如果我们“关注用户（其他所有内容都在其中）”，则必须问自己：失败的测试是否对用户有利？

答案是：“失败的测试不会直接使用户受益。”

尽管乍看之下这句话令人震惊，但这是事实。如果产品有效，则不管测试是否表明有效，该产品都有效。如果产品损坏，则无论测试是否表明它已损坏，产品都将损坏。那么，如果失败的测试对用户没有好处，那么对他有什么好处呢？

错误修复直接使用户受益。

仅当这种不可预测的行为（错误）消失时，用户才会感到高兴。显然，为了纠正错误，您必须知道它存在。要发现错误，理想情况下，您应该有一个检测到该错误的测试（因为如果该测试未检测到该错误，则用户会找到它）。但是在整个过程中，从测试失败到错误纠正，增值出现在最后一步。

因此，要评估任何测试策略，您不能仅仅评估它如何发现错误。您还应该评估这如何允许开发人员纠正（甚至阻止）它们。

建立正确的反馈

测试会创建一个反馈循环，以告知开发人员该产品是否正常工作。理想的反馈回路具有多个属性。

. , , . ( ), . . , .
. , , , . , , .
它应该可以让您快速找到错误。要修复该错误，开发人员需要找到导致该错误的特定代码行。当产品包含数百万行代码，并且错误可能出现在任何地方时，这就像试图在大海捞针中寻找针头一样。

小而不大

那么，我们如何创建一个完美的反馈回路？考虑的是小而不是大。

单元测试

单元测试占用一小部分产品，并与其他所有产品隔离进行测试。它们几乎创建了相同的完美反馈回路：

单元测试很快。我们需要编写一小段代码，我们已经可以对其进行测试。单元测试通常很小。实际上，十分之一秒对于单元测试来说太长了。
. , , . , — , , — .
. , , , , .

编写有效的单元测试需要诸如依赖性管理，编写存根/模拟和严格测试等领域的技能。我不会在这里描述这些技能，但首先，提供给新Googler（或在Google中称为Noogler）的典型示例就是Google如何创建和测试秒表。

针对端2端测试的单元测试

对于端2端测试，您需要等待：首先创建整个产品，然后进行部署，最后完成所有端2端测试。当测试仍然有效时，它们很可能会定期失败。即使测试检测到错误，它也可以在产品中的任何位置。

尽管端到端测试更适合于对真实用户场景进行建模，但是端到端反馈循环的所有缺点很快就抵消了这一优势：

集成测试

单元测试有一个主要缺点：即使模块单独工作良好，您也不知道它们能否一起正常工作。但是即使那样，您也不必运行端到端测试。您可以为此使用集成测试。集成测试需要一小组模块（通常是两个），并整体测试其行为。

如果两个模块不能正确集成，那么为什么可以编写一个端到端测试，而您可以编写一个更小，更集中的集成测试来检测相同的错误呢？当然，您在测试时必须了解整个上下文，但是为了一起测试两个模块的工作，您只需要稍微扩展一下视野即可。

测试金字塔

即使进行单元测试和集成测试，您也可能需要进行少量的端到端2测试以测试整个系统。要在所有三种类型的测试之间找到适当的平衡，最好使用视觉测试金字塔。这是2014年Google测试自动化会议开幕致辞中测试金字塔的简化版本。

您的大部分测试都是金字塔底部的单元测试。随着您在金字塔上的移动，测试会变得更加全面，但是同时，测试的数量（金字塔的宽度）会减少。

Google很好地提供了70/20/10的分离度：70％的单元测试，20％的集成测试和10％的端到端测试。每个团队的确切比例会有所不同，但通常应保持金字塔的形状。尽量避免以下“形式”：

倒金字塔/蛋卷冰淇淋。该团队主要依靠端到端测试，使用多个集成测试和很少的单元测试。
滴漏。该团队从大量的单元测试开始，然后在应该使用集成测试的地方使用端到端测试。沙漏在底部有很多单元测试，在顶部有很多端到端测试，但在中间没有集成测试。

就像普通金字塔往往是现实生活中最稳定的结构一样，测试金字塔也往往是最稳定的测试策略。

职位

如果您喜欢并且知道如何编写单元测试，那么欢迎您！LANIT公司的DevOps团队中有一个Java开发人员的空缺，在那里您会发现志趣相投的人。

对End-2-End测试只说不