因此，我不确定du-path覆盖（或者例如，任何数据流覆盖标准）与谓词标准或分支/节点标准的优缺点。
我可以看到，在某些情况下，对另一种情况有一种明显的优势。例如，如果我的很多算法都包含在下一个例子中的相似内容
void m();
void n();
void method(boolean b) {
if (b) {
m();
} else {
n();
}
}
现在，我想知道的是一般情况，在决定你将遵循哪种覆盖标准时，你在算法中寻找的是什么，
各种覆盖标准（基本上是Introduction to Software Testing中找到的标准）。也就是说，对于一般情况，我基本上都在寻找一般的启发式方法。
由于
答案 0 :(得分：3)
不可否认，我在这方面做了很多研究，并不一定完全跟着你（主要是因为我缺乏这方面的经验）。但希望这离基地不太远。
我对代码覆盖率的理解一直是您希望涵盖所有可能的执行路径。现在我知道一些路径比其他路径重要得多（例如：“快乐路径”比设置某些属性的一些模糊路径重要得多），但无论天气与否，你都“覆盖”每条路径，至少你我们想要了解它们的存在，并在某些方面做出有意识的选择（通过单元测试或手动）。
您可以从眼球方法和编写测试用例开始，但这很快变得不可靠，因为无论算法类型如何，都保证不会看到每个可能的执行路径。即使非常小的程序也会产生下落不明的错误，因为测试人员没有想到以这种方式“尝试”。
您真正需要的是一个代码覆盖率工具，用于告诉您单元测试涵盖哪些执行路径，哪些不是。此时，您可以对天气作出合理的决定，以便涵盖那些遗失的案例（因为并非所有案例都值得您花时间）。如果没有这样的工具，我会认为你会花费无数的工作时间一行一行地跟踪哪些测试包涵盖了什么...即使该工具花费数百美元（甚至几千美元），我想你及时快速收回这些资金。
因此，我的一般启发式方法是使用这样的工具来跟踪您的测试覆盖率，并根据其结果做出决定覆盖或不覆盖。
一些代码覆盖工具（不全面）：