如何生成良好的浮点逻辑代码覆盖率？

Question

我正在手工制作新代码。我想确保我不遗余力。

除了指定代码合同来指导 Pex 以使其在数字密集型代码中产生良好的覆盖率之外，我还能做些什么具体的事情？

尝试在http://research.microsoft.com/en-us/projects/pex/pexconcepts.pdf 中搜索关键字“float”以获取一些背景信息。

浮点数的

算术约束通过转换为有理数来近似，启发式搜索技术在 Z3 之外用于寻找浮点约束的近似解。

...还有...

符号推理。 Pex 使用自动约束求解器来确定哪些值与测试和被测代码相关。然而，约束求解器的能力是有限的，而且永远是有限的。特别是，Z3 无法精确推理浮点运算。

或者，您是否知道 .NET 下更适合在 .NET 下查找数值异常的工具？我知道http://fscheck.codeplex.com/，但它不执行符号推理。

Answer 1

是你想要好的覆盖范围吗？仅仅在一段代码中运行每个分支的测试不太可能实际上意味着它是正确的——通常更多的是关于极端情况，作为开发人员的你最有可能知道这些极端情况是什么。听起来它也可以通过说“这是一个有趣的输入组合”来工作，而您想要的很可能是指定您想要查看的系统的行为 - 如果您首先编写错误的代码，那么有趣的输入可能与正确的代码完全无关。

也许这不是您正在寻找的答案，但我想说最好的方法是手动！在开始编码之前写下规范，并在您知道/正在为您的类/子系统编写 API 时将其转化为大量测试用例。

在开始填写 API/编写代码时，您可能会发现需要做的额外点点滴滴 + 找出难点是什么 - 如果您有条件等，您觉得有人会这样做重构代码可能会出错，然后编写一个涵盖它们的测试用例。我有时会故意在这些点上写错代码，在失败中进行测试，然后纠正它，以确保测试通过代码检查正确的路径。

然后试着想想你可能没有涵盖的任何奇怪的值——负输入、空值等。通常这些情况是无效的，你不想迎合/不得不考虑——在这些情况下，我通常会编写一些测试来说明它们应该抛出异常 - 这基本上可以防止人们在您没有正确考虑/使用无效数据的情况下滥用代码。

您在上面提到您正在使用数字密集型代码 - 可能值得测试更高级别，这样您就可以测试您正在寻找的系统中的行为，而不仅仅是数字运算 - 假设代码不是纯粹的数值 这将帮助您建立一些实际的执行条件，并确保无论数字运算位实际上在做什么都以您需要的方式与程序的其余部分交互 - 如果它是算法的东西，您可能会更好地编写一种验收测试语言，可帮助描述不同情况下所需的输出 - 这可以清楚地说明您要实现的目标，它还允许您通过系统抛出大量（真实）数据，这可能比计算机生成的输入。这样做的另一个好处是，如果您意识到算法需要彻底重写才能满足一些新要求，那么您所要做的就是添加新的测试用例，然后重写/重构；如果您的测试只是查看算法的细节并假设对外部世界的影响，那么您将非常头疼，试图弄清楚算法当前如何影响行为，哪些部分是正确的，哪些不是，然后试图将大量单元测试迁移到新的 API/算法。