Answers:
格伦福德·迈尔斯（Glenford Myers）的书《软件测试的艺术》对此有一个简单但原则性的规则：当您停止发现错误时，测试即告完成。或者，实际上，当您发现新错误的速度大大降低时。
错误往往会“聚集”在某些模块和某些功能中：一旦发现一个错误，就知道应该进一步检查以发现更多错误。要查找错误，可以使用黑盒测试，白盒测试和变异测试的技术。只要发现错误，就知道您的测试过程正在运行！
为了可视化您的进度，请绘制图表，记录您的团队每天发现的错误数量。如果图表向下倾斜，则说明您的团队正在使用的技术始终无法找到它们。当然，如果您认为自己的技术无法达到标准，那么请阅读Myers的书中的应用原理。
现在，您可能会缺少新的错误补丁，而如果您继续进行更多测试，发现错误的比率将会大大提高。但是，如果您相信自己的技术是合理的，那是不可能的。
简单的答案是它取决于系统。如果您正在编写用于心脏监护仪的嵌入式软件或用于核反应堆的安全监视工具，那么该标准将远远高于编写博客平台的标准。
对于一个好的系统测试人员（我不是一个），这确实是一个问题，但是我会给它一个机会。
您的基本度量将是测试覆盖率：实际已经测试了多少应用程序（通过单元测试和功能测试）。
您需要评估每个潜在用例（以及该用例的参数），以了解其实际使用的可能性（因此您可能会丢弃边缘用例），复杂性（较简单的事物不太可能包含错误，或者不太可能包含硬错误）查找错误），测试成本（时间）以及缺陷的潜在影响（如果在该区域发现）（这是核反应堆与博客平台的结合之处）。
基于该评估，您需要确定哪些将要测试以及需要多少细节。一旦有了类似的列表，团队（包括产品经理/项目经理/用户代表）便可以浏览该列表，并根据您的约束进行优先级排序。
考虑的一种有用技术是，您还可以更改每个发行版中测试的用例。例如，您可能有一个非关键测试用例的列表，并用一个发行版测试其中的一半，然后用下一个发行版测试另一个（然后是替代）。这样，您就可以增加努力的总测试覆盖率（尽管存在引入回归错误的风险）。
这也可以扩展到平台测试-如果您支持两个数据库后端（或多个浏览器），则在一个应用程序上测试一半应用程序，在另一应用程序上测试另一半，然后交换下一个版本。
（我认为这被称为条带化，但请不要在此引用我的意思。）
然后要考虑的最后一件事不是测试内容，而是发现问题时实际解决的问题。通常说“修复所有错误”，但现实是存在时间压力，并非所有错误都是平等的。同样，与所有相关方面进行定期漏洞修复是最好的方法。这在漏洞修复可能特别具有侵入性的情况下尤其重要，因为它所产生的重新测试和回归测试中的额外工作可能会超过该修复的好处。
“程序测试可用于显示错误的存在，但从不显示错误的存在！” 埃德格·迪克斯特拉（Edsger Dijkstra）
进行任何测试（自动化或其他方式）时，请记住一些好事情。您只能证明您没有发现更多错误，也不能证明没有其他错误。
但是，您对一段代码的关注越多，对它的正确操作的信心就越大。在这方面，这很像Knuth关于优化的报价：您可以很容易地测试错误的东西，并且可以在开发的错误时间进行测试。
从本质上讲，您想在两个大方面都涉及到：
该软件是否通过BDD测试以证明其满足指定要求。如果事实并非如此，则该软件甚至都无法完成。
最关键，最复杂和不确定的细分市场是否有足够的测试来提供信心？如果这是一个核心循环，或者您必须对其进行优化或修改，请对其进行测试。如果它很复杂并且有很多逻辑上的分歧：请对其进行大量测试。如果您无法对其进行单元测试，或者其嵌入的深度太深而无法直接进行实际测试：请确保已对代码进行了检查，并且手动进行了间接测试。
如果等到项目完成，您的确会有大量的测试用例。如果您连续交付，并且专注于小批量交付，则每次迭代的测试用例将更少，并且您将能够测试所有内容。如果您无法进行小批量交付，则优先处理并从最高优先级开始进行测试，然后进行测试，直到必须停止为止。
如果您正在谈论单元测试并且正在执行TDD（首先编写测试），那么这不是问题：只要完成功能，就停止测试。
在增量式TDD中，您编写了一个失败的测试，然后实施可以使其通过的最少代码，然后进行重构。继续以这种方式添加测试，直到方法完成为止。
这是一个很好的例子。
统计人员也一直在研究这个问题-实际上早在1970-80年代。给定关于如何发现错误的适当假设，他们将尝试从测试数据中估计错误的数量。然后根据优化损失函数将其用于确定何时停止。参见例如https://rpubs.com/hoehle/17920 ...，以简短了解有关此问题的论文之一，包括有关如何在实践中使用R代码的文章。
当然，一个问题总是关于错误发现过程的假设。例如，在以上处理中，假设错误是彼此独立发现的。在实践中，修复一个大的bug可能会导致新的bug等。但是，这为您提供了一个开端并补充了直觉。
发货日期到了。软件测试无止境。但是，这又有一个时间表。您将必须在计划的时间内测试大多数功能，并修复遇到的错误。您无法保证该软件是完美的。
一切归结为信心问题。您是否对系统进行了足够的测试充满信心？
显然，“置信度”是非常主观的，因为您永远无法完全确定但足够确定，这就是我们所要寻找的。为此，您需要创建一个指标列表，通常称为完成定义，并且应该是整个团队都同意的指标。
以下是一些与测试相关的“完成指标”：
如果您可以检查这些点，那么您可能会说您已经进行了足够的测试。