问是否有可能编写一个涵盖所有内容的单元测试？

EN

这在一定程度上是一种评论，部分是因为你表达问题的方式。

评论

是否有可能编写一个涵盖所有内容的单元测试？

No. --即使在您的示例中，您将测试用例限制在2^32上，但是如果代码被移动到64位系统，然后有人使用2^34或其他什么工具添加一行，怎么办？

另外，您的问题向我表明，您正在考虑动态代码的静态测试用例，例如，代码是动态的，因为它是由程序员随时间而更改的，这并不意味着被代码动态修改。您应该使用动态代码来考虑动态测试用例。

最后，您没有注意到是白色、灰色还是黑匣子测试。

答案

让工具分析代码并生成测试数据。

请参阅：自动测试数据生成技术综述

你还问过关于搜索关键字的问题。

下面是我在谷歌上找到的有价值的搜索：

代码分析自动测试生成调查

相关

我自己从未使用过这些测试用例工具，因为我使用Prolog DCG来生成我的测试用例。目前，我正在用一个项目在大约两分钟内生成数百万个测试用例，并在几分钟内对它们进行测试。一些失败的测试用例，我永远不会自己想出来，所以这可能被一些人认为是过火了，但它起作用了。

由于许多人不知道Prolog，这里有一个类似的方法，使用C# with LINQ，由Eric，每棵二叉树都有解释

不，目前还没有一种通用的算法不涉及某种非常密集的计算(例如，测试很多种情况)，但您可以编写单元测试，这样在方法发生更改时，它们失败的可能性更高。例如，在给出的答案中，为x= 10编写一个测试。对于其他两种情况，首先在11和int.Max之间选择几个随机数，然后对它们进行测试。然后在int.Min和9之间测试几个随机数。在您描述的修改之后，测试不一定会失败，但是它失败的可能性更大，而不是仅仅硬编码这个值。

此外，正如@GuyCoder在他出色的回答中所指出的，即使你确实尝试过这样做，也很难(或者不可能)证明没有可能改变一种方法来破坏您的测试。

此外，请记住，任何类型的测试自动化(包括单元测试)都不是一种万无一失的测试方法；即使在理想的条件下，您也无法100%地证明您的程序是正确的。请记住，几乎所有的软件测试方法基本上都是经验方法，而经验方法并不能真正实现100%的确定性。(不过，它们可以获得很大的确定性；事实上，许多科学论文的确定性达到95%或更高-有时甚至更高-因此，在这种情况下，差别可能并不那么重要)。例如，即使你有100%的代码覆盖率，你怎么知道测试中没有错误呢？你要为考试写测试吗？(这可能导致出现海龟一直往下走类型的情况)。

如果你真的想了解这件事，并且相信大卫·休谟，你就不可能100%地肯定基于经验检验的东西；每次你运行测试都通过了测试，但这并不意味着它在将来会继续通过。不过，我离题了。

如果您感兴趣，形式验证研究的方法是演绎地证明软件(或者至少是软件的某些方面)是正确的。注意，这方面的主要问题是，要对一个复杂的完整系统的程序进行正式验证往往是非常困难或不可能的，特别是在使用未经正式验证的第三方库的情况下。(这些，以及首先学习这些技术的困难，是正式验证没有真正脱离学术界和某些非常狭窄的行业应用的一些主要原因)。

最后一点:软件附带了错误。您将很难找到任何复杂的系统，是100%无缺陷时，它是发布的。正如我前面提到的，目前还没有一种技术可以保证您的测试发现了所有的bug(如果您能够找到一个bug，那么您将成为一个非常富有的个体)，所以在很大程度上，您将不得不依靠统计方法来了解您是否已经进行了充分的测试。

TL；博士不，你不能，即使你可以，你仍然不能百分之百地确定你的软件是正确的(例如，在你的测试中可能有一个错误)。在可预见的将来，您的单元测试用例也需要维护。不过，您可以编写测试以更好地抵御更改。