对于非关键任务而言，端到端和集成测试值得吗？

众所周知，端到端和集成测试成本很高。当然，如果我们开发应用程序，如果出现问题，人们可能会因此丧命，这是值得的投资。但是，在错误不是世界末日的应用程序中，完全跳过E2E测试和集成测试并在出现问题时制定备份计划会不会更便宜？像手动测试用户故事+单元测试+使用静态类型的语言是否足够？

例如，如果某个网上商店丢失了订单，他们可以改为免费发送该商品+道歉。最终用户可能会更开心，这样公司总体上可以节省金钱。

我想我的问题是，总体而言，集成测试和E2E测试的成本是多少？节省多少钱？有没有办法对此进行风险/成本计算？

是否实施E2E和集成测试都没有关系，无论哪种方式都需要备份计划。不要仅仅因为系统已经过测试就期望它没有错误。

因此，在成本估算中，您不会将实施E2E测试的成本与备份计划估算的成本（如果发生故障）进行比较，请比较：

• 手动进行端到端测试的成本（几次，每次发布新版本之前）

与

• 建立（和维护）自动化端到端测试的成本

如果您可以多次使用这些E2E测试，通常会进行许多次测试，而这些测试的成本会达到收支平衡点。这应该是您希望提前计划手动进行哪些E2E测试以及自动进行哪些测试时应采用的指标。

请注意，有些类型的E2E测试可以轻松实现，并且可以立即清楚地获得ROI，但是有些E2E测试的开发和维护成本可能会比几年内手动执行的成本更高。

也许直觉上与之相反，与没有测试相比，自动测试实际上可以减少开发时间。所以这是双赢。

想法是测试在多个层次上有所贡献

1. 强制执行严格的要求收集和规范

   这对发展速度产生了巨大影响。无需回头索取更多详细信息，没有误解，不需要的功能等

2. 开发人员知道功能何时完成

   大多数测试由开发人员在编写代码时完成，而不是由测试人员检查最终产品。自动执行此测试可减少此工作量

3. 立即发现由新功能引入的错误。

   这些可能很容易使您耗费冲刺，并且如果未被发现，则需要重写整个功能。

4. 更快的发布周期

   这意味着更少的代码在运行，这意味着更少的合并，这意味着更少的工作和更少的开发人员复杂性

尤其是如果您具有测试框架设置，则编写这些测试所花的时间要比节省这些效率所花的时间少。

另外，您可以节省手动测试时间，最后可以得到更好的产品。

我的答案？也许，也许不是。

当EOE测试非常简单时，它们是好的。如果您打算涵盖基本方案，则可以通过EOE测试获得一些优势。但是，如果您有一个非常复杂且庞大的应用程序（无论是否执行关键任务），那么此EOE测试的维护成本将很高，并且您需要了解您的方案以评估是否值得。

几年前，Google测试博客讨论了该主题。我只能同意作者的看法。好的测试需要快速，可靠并隔离故障，而EOE测试无法提供这些功能。

我在一个应用程序上进行了超过12个小时的端到端测试，涉及许多场景。最终，我们设法将测试分发到不同的计算机上，控制测试的开始，执行和结束，并收集和合并结果。被测试的应用程序是一个整体应用程序（安装和运行起来更容易进行测试），并且是维护测试的噩梦。

大多数时候，我们是在维护测试，而不是从测试结果中发现错误。在端到端测试中发现错误的根源需要花费大量时间。我们还处理了很多“假阴性”测试，并且花了很少的时间来理解该问题并进行纠正：Java Applet加载问题，页面上未找到预期元素（以及其他有关自动化速度的问题），维护查询代码仅用于数据库内存测试（因为原始查询使用数据库特定的代码），等等。

所有这些都需要人们维护和运行。最后，我们开始删除一些EOE测试并将其替换为许多单元/集成测试。

因此，我的保守建议是使用Google的测试金字塔：

作为一个很好的初步猜测，Google经常建议采用70/20/10的比例：70％的单元测试，20％的集成测试和10％的端到端测试。每个团队的确切组合会有所不同，但通常，它应保持金字塔形状。

以我的经验，无论应用程序有多重要，端到端测试始终是谨慎的。我一直认为，在最坏的情况下，如果事情变得一团糟，您是否愿意站在管理层面前并证明自己的做法合理？如果没有，那么您需要更改方法。许多组织将测试的重要性和资源分配降至最低，但是请放心，当出现问题时，每个人都在找人指责，如果您决定限制测试或提供建议，那您就是开火了线。

软件开发经常需要关注组织政治。

“众所周知，端到端和集成测试成本很高。”

我认为我不同意这个主张。

首先，端到端测试对于最终用户而言至关重要，并且可以成为测试复杂系统的最省时/最低成本的选择。例如，当某人购买汽车时，大多数人不会将其拉成碎片，而是开始隔离测试碳水化合物，变速箱和车轮。相反，他们将其用于试驾。

其次，就工具而言，E2E不会减慢产品的内部发展，并且持续时间更长。如果您考虑一下，大多数产品的实际功能面很少会发生太大变化，而在内部它可能会经历各种发展。结果，一旦测试工具启动并运行，它通常会持续非常好。例如，如果我们回到汽车类比。同样的“开车试驾”测试用例在福特T型车上的工作量与在特斯拉上的差不多。就像在道路，风洞，泄漏测试设置等方面的投资一样。有多少个内部组件测试在整个生命周期内都具有如此高的投资回报率？

虽然在初始设置中以及是否用于尝试对所有内容进行测试，但E2E测试的确往往更昂贵/不适当。务实地说，我认为避免此陷阱的最佳方法是优先执行对以下各项的自动化测试：

1. 易于自动化，不太可能需要大量维护才能保持运行。
2. 花费大量时间来应用一致，适当，手动的测试过程。
3. 如果产品破损发布，则冒着使您或您的老板看起来像白痴的风险。

使用您认为合适的任何形式的测试，包括E2E。虽然专注于那些。

您无法真正将集成测试的成本与错误仅影响单个订单的最佳情况的成本进行比较。逻辑错误可能会影响大量订单。说一个错误意味着没有捕获任何付款-这可能对任何企业造成灾难性影响。

您应该问什么是最糟糕的错误，由于缺乏端到端测试，实际上可能最终在生产中出现。并记住墨菲定律。

我假设这个问题与企业Web应用程序有关。

我对中等关键性内容的建议：

• 对您的后端API执行自动测试，确保后端按预期工作。这些测试应由开发人员在实现API时编写。
• 不要在乎自动化的UI测试，即手动进行前端测试。

我认为大多数测试应该在API级别或组件级别。我不在乎仅执行某些内部功能的单元测试。