Answers:
您什么时候有足够的自动测试来对您的持续集成流程充满信心？
如果您考虑要自信的话，答案可能会很清楚。最终，它映射了1-1。每项测试都会使您对所测试的一件事充满信心：
从您提出问题的方式来看，您现在可能正在从大角度思考商业问题，例如：
我想确信我的应用程序可以做X。
因此，您编写了一个尝试执行X并检查它是否正确执行的端到端测试。
这都是非常自指的，但这是因为这就是问题所在。根本没有更多。
例如，假设您编写了一个用于创建烹饪食谱的应用程序。一个功能是，如果您添加不同数量的几种不同类型的奶酪，它会为您提供正确的温度和时间，以便它们都融化。
因此，您可以为自己编写一个单元测试CheeseMeltCalculator，在其中进行100g豪达奶酪和200g Emmental奶酪的测试，然后检查温度和时间是否正确。这意味着您现在可以放心，该产品CheeseMeltCalculator适用于100克荷兰扁豆和200克奶酪。现在，如果您用300克荷兰扁豆而不是200克重复此测试，则可以确信它可以正确地用于不同的值。您可以添加Gouda的和的测试0，以确保代码不会因奇怪的输入而跳闸（或按预期正确跳闸）。-1int.MaxValue
您可以编写一个集成测试，以检查CheeseMeltCalculator是否已正确集成到整个食品温度和时间计算过程中。如果这是错误的，但是CheeseMeltCalculator上面的测试很好，您可以确信该错误存在于其他计算器中，或者是来自不同计算器的数据组合在一起的方式。
最后，您可以编写一个用于创建整个配方的端到端测试，您要检查的内容之一是结果温度和时间。如果前面的两个测试水平都很好，但是这样做有误，那么您可以再次确信那些部分是正确的，而错误之处在于温度计算如何集成到应用程序中。例如，可能用户输入未正确传输。
而最后，如果所有这些测试都很好，那么你可以相信，“ 如果你添加不同量的几种不同类型的奶酪，它给你适当的温度和时间，让他们都融化 ”
关键是您无法进行“正常工作”测试。您只能测试“如果我执行X，则发生Y”。
但是，这正是项目技术规格中应包含的内容。诸如“ 如果您添加不同数量的几种不同种类的奶酪，它会为您提供正确的温度和时间，以便它们都融化 ” 这样的陈述，不仅使客户对成品的用途有明确的期望，而且可以转换成成品进入自动化测试。
用户Richard在编辑中添加了以下信息：
马丁·福勒（Martin Fowler）在他的网站上有一个关于最常见策略的非常不错的摘要：https : //martinfowler.com/articles/microservice-testing/
我不想删除它，但我想说的是：与这个答案相比，它不是一个“摘要”，而是一个更深入的解释，其中包含漂亮的图形和所有内容。
我的建议是：如果阅读完我的回答后一切对您都有意义，那么您就完成了。如果情况仍然不清楚，请拨出一点时间仔细阅读链接的文章。
您没有可以计算的指标可以给您所需的信心。做某事，然后成功或失败，并从中学到一些东西，就会建立信心。
我发现使我对测试覆盖面充满信心的唯一“指标”是：
自动化测试不是万灵丹。您需要跟踪在每个发布周期中发现了多少生产缺陷。当这个数字下降时，您将交付更好的软件。自动化测试和持续集成只是您用来提供更好软件的工具。
您唯一可以衡量的指标是“您是否提供了更好的软件？”
即使这样，它也是主观的。
您什么时候有足够的自动测试来对您的持续集成流程充满信心？
在大多数经济环境中，您将没有预算来实现足够的置信度（> 99％），但是您必须管理有限的预算：这全都与成本/收益比有关。
因此，实际上，将执行简单/便宜/风险较高的测试，而不会执行昂贵/不太可能的测试。
软件开发的一个子目标是创建易于/廉价测试的体系结构（通过应用Test-driven_development设计可测试性），以保持自动测试的可负担性。
我假设Pareto_principle也可以在此处用于可维护/可测试的软件：它表示，多花20％的钱，您将获得80％的额外收益。为了获得剩余的20％的收益，您需要花费额外的80％的钱。
您可以应用诸如代码覆盖率和变异覆盖率之类的测试指标 来向您展示潜在的未经测试的源代码。
但是，即使覆盖率达到100％，您也不能保证代码中没有错误。
管理喜欢编码度量。如果开发人员不支持/不喜欢自动测试，而管理人员强制执行“代码覆盖率> = 80％”，则存在编写具有高覆盖率的测试代码的方法，该方法不会证明有任何假象给人以安全感。
这里的诀窍不是担心完整的覆盖范围，而在于管理更改的风险。
假设您正在使用管道来部署与生产中已经使用的版本完全相同的版本-回归错误的风险是什么？零（因为没有变化）。
现在，假设我要在其中一个屏幕上更改一段文本。我已经添加了测试，以验证文本现在是否可以正确显示（为方便起见，假设它是一条非常重要的文本）。我还需要其他哪些测试来验证没有回归错误？实际上没有...
因此，每个发行版都需要进行的自动化测试的数量不是您的应用程序大小的函数，而是更改大小的函数。如果您要进行小的，低风险的更改，那么您将需要更少的测试来减轻风险。
但是，请稍等...这对CI和CD的要求不是很好吗？
是的 通过将所有更改和增量保持为很小，您可以通过流程而不是测试来减轻许多回归风险。而且，问题实际上并没有变成自动化的问题（这只是我们将使用的工具），而仅仅是测试和风险承受能力的问题。完全忘记自动化，您将针对变更进行哪些测试，以确保变更没有引入问题？从手动测试过程到CI系统，这个问题的答案不会改变-唯一的优点是，许多回归测试以前可能是在以前的功能中开发的，CI鼓励您进行更小，更安全的更改。
TLDR
您的测试是为了减轻更改的风险。增量为零的部署没有风险，因此没有风险。通过将更改保持在很小的范围内，可以轻松地确定验证它们所需的测试-自动化的可重用性是一个好处。