测试的真正价值
通常，测试人员的工作在测试失败后即告结束。提交了一个错误，然后是开发人员修复错误的工作。然而，为了确定端到端战略失败的地方，我们需要在这个框外思考并从第一原则出发解决问题。如果我们“专注于用户（以及其他所有人都会关注），”我们必须问自己，失败的测试如何使用户受益。答案如下：
失败的测试不会直接使用户受益。
虽然这个说法起初看起来很震撼，但事实确实如此。如果产品有效，它是否有效，无论测试是否有效。如果产品坏了，它会被破坏，无论测试是否破坏了。因此，如果测试失败不会使用户受益，那么用户有什么好处呢？
错误修复直接使用户受益。
只有当意外行为（错误）消失时，用户才会感到高兴。显然，要修复错误，您必须知道错误存在。要知道存在的错误，理想情况下，您有一个捕获错误的测试（因为如果测试没有，用户将找到错误）。但是在整个过程中，从失败的测试到错误修复，只在最后一步添加了值。
| 阶段 | 失败的测试 | 错误已打开 | 错误修复 |
| 增值 | 没有 | 没有 | 是 |
因此，要评估任何测试策略，您不能只评估它如何发现错误。您还必须评估它如何使开发人员能够修复（甚至防止）错误。
构建正确的反馈循环
测试创建一个反馈循环，通知开发人员产品是否正常工作。理想的反馈回路有几个属性：
- 它很快。没有开发人员想要等待数小时或数天才能确定他们的更改是否有效。有时候改变不起作用 - 没有人是完美的 - 反馈循环需要多次运行。更快的反馈循环可以加快修复速度。如果循环足够快，开发人员甚至可以在检查更改之前运行测试。
- 这很可靠。没有开发人员想花几个小时调试测试，只是发现这是一个不稳定的测试。片状测试降低了开发人员对测试的信任，因此即使在他们发现真正的产品问题时，也会忽略片状测试。
- 它隔离了故障。要修复错误，开发人员需要找到导致错误的特定代码行。当产品包含数百万行代码时，错误可能在任何地方，就像试图在大海捞针中找到一根针。
想想更小，而不是更大
那么我们如何创建理想的反馈循环呢？通过思考更小，而不是更大。
单元测试
单元测试只需要一小部分产品并单独测试该部件。他们倾向于创建理想的反馈循环：
- 单元测试很快。我们只需要构建一个小单元来测试它，测试也往往相当小。实际上，十分之一秒被认为是单元测试的缓慢。
- 单元测试是可靠的。简单的系统和小型单元通常倾向于从薄脆度中受到更少的影响。此外，单元测试的最佳实践 - 特别是与密封测试相关的实践 - 将完全消除薄脆。
- 单元测试隔离故障。即使产品包含数百万行代码，如果单元测试失败，您只需搜索被测试的小单元即可找到该错误。
编写有效的单元测试需要依赖管理，模拟和密封测试等领域的技能。我不会在这里介绍这些技能，但作为一个开始，为新Google员工（或Nooglers）提供的典型示例是Google如何构建和测试秒表。
单元测试与端到端测试
使用端到端测试，您必须等待：首先构建整个产品，然后部署，最后运行所有端到端测试。当测试运行时，片状测试往往是生活中的事实。即使测试发现了一个错误，该错误也可能出现在产品的任何地方。
虽然端到端测试在模拟真实用户场景方面做得更好，但端到端反馈循环的所有缺点很快就会超过这一优势：
| 单元 | 端到端 | |
| 快速 |
|
|
| 可靠 |
|
|
| 隔离失败 |
|
|
| 模拟真实用户 |
|
|
集成测试
单元测试确实有一个主要缺点：即使单元在隔离状态下工作良好，也不知道它们是否能很好地协同工作。但即便如此，您也不一定需要端到端测试。为此，您可以使用集成测试。集成测试需要一小组单元，通常是两个单元，并测试它们的整体行为，验证它们是否一致地协同工作。
如果两个单元没有正确集成，为什么要编写一个更小，更集中的集成测试来检测相同的bug时编写端到端测试？虽然您确实需要更大的思考，但您只需要考虑更大一点来验证单元是否协同工作。
测试金字塔
即使使用单元测试和集成测试，您仍可能需要少量的端到端测试来验证整个系统。要在所有三种测试类型之间找到适当的平衡点，最好的视觉辅助工具是测试金字塔。以下是2014年Google测试自动化大会开幕主题演讲中测试金字塔的简化版本：
大部分测试都是金字塔底部的单元测试。当您向上移动金字塔时，您的测试会变大，但同时测试次数（金字塔的宽度）会变小。
作为一个良好的初步猜测，谷歌经常建议70/20/10拆分：70％的单元测试，20％的集成测试和10％的端到端测试。每个团队的确切组合会有所不同，但总的来说，它应保留金字塔形状。尽量避免这些反模式：
- 倒金字塔/冰淇淋蛋筒。该团队主要依靠端到端测试，使用少量集成测试和更少的单元测试。
- 沙漏。团队从大量单元测试开始，然后使用端到端测试，其中应使用集成测试。沙漏底部有许多单元测试，顶部有许多端到端测试，但中间很少有集成测试。
就像常规金字塔往往是现实生活中最稳定的结构一样，测试金字塔也往往是最稳定的测试策略。
转自：https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html?m=1