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

Question

我在手工制作新代码。我想确保我不会掉以轻心。

除了指定代码契约以指导Pex之外，我还能做什么具体的事情，以便在数字密集的代码中产生良好的覆盖率？

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

将浮点数上的

算法约束近似为有理数，并在Z3之外使用启发式搜索技术寻找浮点约束的近似解。

...and也..。

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

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

Answer 1

你想要好的报道吗？仅仅有一个运行代码中每个分支的测试不太可能实际上意味着它是正确的--通常它更多的是关于角落案例，而您作为开发人员最适合知道这些角落案例是什么。这听起来也像是说‘这是一个有趣的输入组合’，而你更想要的是指定你想要看到的系统的行为--如果你一开始就把代码写错了，那么有趣的输入可能与正确的代码完全无关。

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

当开始填写API/编写代码时，您可能会获得额外的需要做的部分，并找出困难的部分是什么--如果您有条件等，您认为重构代码的人可能会出错，然后编写一个涵盖它们的测试用例。有时，我故意在这些地方编写错误的代码，得到一个失败的测试，然后更正它，以确保测试通过代码检查正确的路径。

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

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