在你的生活中，你可能会回忆起一部你和朋友们都想看的电影，但看后你们都感到后悔。或者，你记得那次你的团队以为他们找到了产品的下一个“杀手级功能”，但该功能在发布后却失败了。

实践中，好主意常常会失败，在测试领域，围绕端到端测试构建的测试策略是一个广泛存在且常常失败的好主意。

测试人员可以投入时间编写多种自动化测试，包括单元测试、集成测试和端到端测试，但这种策略主要投资于验证整个产品或服务的端到端测试。通常，这些测试模拟真实用户场景。

端到端测试的理论

虽然主要依赖端到端测试不是一个好主意，但完全可以说服一个理智的人认为这个想法在理论上是合理的。

首先，谷歌“我们认为真理的十件事”中的第一条就是：“专注于用户，其他一切随之而来。”因此，专注于真实用户场景的端到端测试听起来是个不错的主意。此外，这种策略广泛吸引了许多利益相关者：

• 开发者喜欢它，因为它几乎卸载了所有的测试责任。
• 管理者和决策者喜欢它，因为模拟真实用户场景的测试可以帮助他们轻松判断一个失败的测试将如何影响用户。
• 测试人员喜欢它，因为他们经常担心遗漏错误或编写的测试无法验证现实世界的行为；从用户的角度编写测试通常可以避免这两个问题，并为测试人员带来更大的成就感。

端到端测试的实践

既然这种测试策略在理论上听起来很好，那么在实践中它为什么会出错呢？为了演示，我将根据我和其他测试人员熟悉的一系列真实经验，提出以下综合示例。在这个示例中，一个团队正在构建一个在线文档编辑服务（例如，谷歌文档）。假设该团队已经有了一些出色的测试基础设施。每晚：

1. 构建服务的最新版本。
2. 将此版本部署到团队的测试环境中。
3. 在该测试环境中运行所有端到端测试。
4. 向团队发送电子邮件报告，总结测试结果。

随着截止日期迅速逼近，我们的团队在为下一个版本编写新功能。为了保持产品质量的高标准，他们还要求至少90%的端到端测试通过，才认为功能完成。目前，截止日期还有一天：

分析

尽管出现了许多问题，测试最终还是发现了真正的错误。

哪些做得好

• 客户影响的错误在到达客户之前被识别并修复。

哪些做得不好

• 团队完成编码里程碑晚了一周（并且加班很多）。
• 找到导致端到端测试失败的根本原因非常痛苦，且可能需要很长时间。
• 合作伙伴原因和实验室故障破坏了测试结果。
• 许多较小的错误被较大的错误遮盖。
• 端到端测试有时不稳定。
• 开发人员必须等到第二天才能知道修复是否有效。

既然我们已经了解了端到端策略的问题所在，我们需要改变测试方法，以避免这些问题。但正确的方法是什么呢？

测试的真正价值

通常，测试人员的工作在他们有一个失败的测试后就结束了。随后，会提交一个错误报告，接下来修复错误就成了开发人员的任务。然而，要识别端到端策略的破绽，我们需要跳出这个框架，从基本原理出发来处理问题。如果我们“专注于用户（其他一切随之而来）”，我们必须问自己，一个失败的测试如何使用户受益。这里是答案：

失败的测试并不直接使用户受益。

虽然这个说法一开始听起来令人震惊，但它是真的。如果一个产品能用，那它就能用，无论测试说它能用与否。如果一个产品坏了，那它就是坏的，无论测试说它坏与否。因此，如果失败的测试对用户没有好处，那么什么对用户有好处呢？

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

用户只有在那个意外的行为——错误——消失后才会感到高兴。显然，要修复一个错误，你必须知道错误存在。理想情况下，你有一个可以捕捉到错误的测试（因为如果测试没有发现，用户会发现错误）。但在整个过程中，从失败的测试到错误修复，只有在最后一步才增加了价值。

构建正确的反馈循环

测试创建了一个反馈循环，告知开发人员产品是否正常工作。理想的反馈循环具有几个特性：

• 它很快。没有开发人员愿意等待几小时或几天来找出他们的更改是否有效。有时更改不起作用——没有人是完美的——反馈循环需要多次运行。更快的反馈循环导致更快的修复。如果循环足够快，开发人员甚至可能在提交更改之前运行测试。
• 它是可靠的。没有开发人员愿意花几个小时来调试一个测试，最后发现这是一个不稳定的测试。不稳定的测试减少了开发人员对测试的信任，结果经常忽略这些测试，即使它们发现了真正的产品问题。
• 它隔离失败。为了修复一个错误，开发人员需要找到导致错误的具体代码行。当一个产品包含数百万行代码，并且错误可能存在于任何地方时，这就像是在大海捞针。

考虑更小，而不是更大

那么我们如何创建那个理想的反馈循环呢？通过考虑更小的，而不是更大的。

单元测试

单元测试只测试产品的一小部分，并将该部分隔离测试。它们倾向于创建那个理想的反馈循环：

• 单元测试很快。我们只需要构建一个小单元来测试它，测试本身也往往很小。事实上，单元测试考虑0.1秒为慢。
• 单元测试是可靠的。简单的系统和一般的小单元往往不太会出现不稳定。此外，单元测试的最佳实践——特别是与密闭测试相关的实践——将完全消除不稳定。
• 单元测试隔离失败。即使产品包含数百万行代码，如果单元测试失败，你只需要搜索正在测试的那个小单元来找到错误。

编写有效的单元测试需要依赖管理、模拟和密闭测试等领域的技能。我在这里不会涵盖这些技能，但作为开始，通常提供给新Google员工（或Nooglers）的典型示例是Google如何构建和测试秒表。

单元测试与端到端测试

对于端到端测试，你必须等待：首先是整个产品的构建，然后是部署，最后是所有端到端测试的运行。当测试运行时，不稳定的测试往往是常态。

尽管端到端测试更好地模拟了真实用户场景，但这一优势很快就被端到端反馈循环的所有缺点所抵消：

集成测试

单元测试确实有一个主要缺点：即使单元在隔离中工作良好，你也不知道它们是否能够良好协同工作。但即便如此，你也不一定需要端到端测试。为此，你可以使用集成测试。集成测试将一小组单元（通常是两个单元）作为一个整体进行测试，验证它们是否能够协调工作。

如果两个单元不能正确集成，为什么要编写一个端到端测试，而不是编写一个更小、更专注的集成测试来检测相同的错误呢？虽然你确实需要考虑更大，但你只需要稍微考虑一下大一点，来验证单元是否能够协同工作。

测试金字塔

即使你有了单元测试和集成测试，你可能仍然会希望有少量的端到端测试来验证整个系统。为了找到三种测试类型之间的正确平衡，最好使用的视觉辅助工具是测试金字塔。这里是2014年Google测试自动化会议开幕主题演讲中的测试金字塔的简化版本：

金字塔的大部分是底部的单元测试。当你向上移动时，你的测试变得更大，但同时测试的数量（你的金字塔的宽度）变得更小。

作为一个好的初始猜测，Google经常建议70/20/10的分割：70%单元测试，20%集成测试，10%端到端测试。具体的混合将因团队而异，但总体上应保持金字塔的形状。尝试避免这些反模式：

• 倒金字塔/冰淇淋锥。团队主要依赖端到端测试，使用较少的集成测试甚至更少的单元测试。
• 沙漏。团队从许多单元测试开始，然后在应该使用集成测试的地方使用端到端测试。沙漏底部有许多单元测试，顶部有许多端到端测试，但中间几乎没有集成测试。

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