如何生成浮点逻辑的良好代码覆盖率
本文关键字：代码覆盖率 何生成 | 更新日期: 2023-09-27 18:35:27
我正在手工制作新代码。 我想确保我不遗
余力。除了指定代码合约来指导 Pex 以便它在数值密集型代码中产生良好的覆盖率之外，我还能做些什么？
尝试 http://research.microsoft.com/en-us/projects/pex/pexconcepts.pdf 搜索关键字"float"以获取一些背景信息。
浮点数的算术约束通过向有理数的平移来近似，启发式搜索技术在 Z3 之外用于查找浮点约束的近似解。
。还有...
符号推理。Pex使用自动约束求解器来确定哪些值与测试和待测代码相关。但是，约束求解器的能力是有限的，而且将永远是有限的。特别是，Z3 无法精确地推理浮点运算。
或者，您是否知道 .NET 下更适合在 .NET 下查找数值异常任务的工具？ 我知道 http://fscheck.codeplex.com/但它不执行符号推理。
的报道好吗？ 仅仅有一个运行一段代码中每个分支的测试不太可能真正意味着它是正确的 - 通常它更多地是关于极端情况，而您作为开发人员最适合了解这些极端情况是什么。 听起来它也像只是说"这是一个有趣的输入组合"，而你很可能想要的是指定你想要看到的系统的行为 - 如果你一开始就写错了代码，那么有趣的输入可能与正确的代码完全无关。
也许这不是你要找的答案，但我想说最好的方法是手工！ 在开始编码之前写下规范，并在您知道/在为类/子系统编写 API 时将其转换为大量测试用例。
当开始填写 API/编写代码时，您可能会挑选您需要做的额外零碎 + 找出困难的部分 - 如果您有条件等，您觉得有人重构您的代码可能会出错，然后编写一个涵盖它们的测试用例。 我有时会故意在这些点上写错代码，让测试失败，然后纠正它，以确保测试检查代码的正确路径。
然后尝试考虑您可能没有涵盖的任何奇怪值 - 负输入，空值等。 通常这些情况是无效的，你不想迎合/必须考虑 - 在这些情况下，我通常会写一些测试说他们应该抛出异常 - 这基本上可以阻止人们滥用代码在你没有的情况下正确/使用无效数据。
您在上面提到您正在使用数字密集型代码 - 可能值得测试上面的级别，以便您可以测试您正在寻找的系统的行为，而不仅仅是数字处理 - 假设代码不是纯粹的数字运算，这将帮助您建立一些真实的执行条件，并确保数字处理位实际执行的任何操作都与程序中的其余部分交互你需要它的方式 - 如果它是算法的东西，你可能最好编写一种验收测试语言来帮助描述在不同情况下所需的输出是什么 - 这清楚地说明了你想要实现的目标，它还允许你抛出大量的（真实）数据通过一个可能比计算机生成的输入更好的系统。 这样做的另一个好处是，如果您意识到算法需要大幅重写以满足某些新需求，那么您所要做的就是添加新的测试用例，然后重写/重构;如果你的测试只是看算法的细节，并假设对外部世界的影响，那么你会非常头疼地试图弄清楚算法目前如何影响行为，哪些部分是正确的，哪些部分不正确，然后尝试将大量的单元测试迁移到新的API/算法上。