我有一个检查64位字的奇偶校验的函数。可悲的是，输入值确实可以是任何东西，所以我不能将我的测试偏向于覆盖已知的一组值，我显然无法测试每一个可能的64位值......
我考虑过使用随机数，这样每次运行测试时，函数都会获得更多的覆盖率，但单元测试应该是一致的。
忽略我的具体应用，是否有一种明智的方法来确保合理的覆盖水平，这很可能会暴露未来引入的错误，而不会花费十亿年的最佳时间来运行？
答案 0 :(得分：1)
以下论点假定您已编写/有权访问源代码并进行白盒测试。
根据所需的置信度，您可以考虑使用自动证明来证明算法正确。但是，假设您的代码不是需要这种置信度的应用程序的一部分，那么您可能会获得相当少的一组单元测试来获得足够的置信度。
让我们假设您的算法以某种方式在64位循环（或者这样做是因为您仍然需要对其进行测试）。这意味着将以非常规则的方式处理64位。现在，您的代码中可能存在一个错误，例如，在循环的主体中，错误地使用了值0，而不是使用64位输入中的相应位。该错误将意味着您始终得到的奇偶校验为0。可以通过导致期望奇偶校验为1的任何输入值来找到此特定的错误。
从这个例子中，我们可以得出结论，对于实际上可能发生的每个错误，您都需要一个相应的测试用例才能找到该错误。因此，如果您查看算法并考虑可能存在的错误，则可能会提出 x 错误。然后，您只需不超过 x 个测试用例即可发现这些错误。 （您的一些测试用例可能会发现多个错误之一。）
这个主要考虑因素导致了许多得出测试用例的策略，例如等效划分或边界测试。例如，在边界测试中，您将特别关注位于循环索引边界的位0和63。这样，您就可以捕获许多经典的一次性错误。
现在，将来算法会发生变化的情况如何（正如您询问的将来引入的错误）？无需遍历64位，可以使用xor-ing以各种方式计算奇偶校验。例如，要提高速度，您可以先xor高32位与低32位，然后取结果，xor高16位与低16位，依此类推。
此替代算法将具有不同的可能错误集。为了对测试用例进行未来的证明，您可能还必须考虑这种替代算法和相应的错误。但是，最有可能的是，第一种算法的测试用例也将发现这些错误的很大一部分-因此，测试的数量可能不会增加太多。但是，分析变得更加复杂。
在实践中，我将专注于当前选择的算法，而不是采用从根本上改变算法的情况重新设计测试套件的方法。
很抱歉，如果这个答案太笼统。但是，应该已经很清楚了，一个更具体的答案将需要有关您选择的算法的更多细节。