在查看算法时,选择特定类型的覆盖标准背后的理由是什么？

Question

因此,我不确定du-path覆盖范围(或者例如,任何数据流覆盖标准)与谓词标准或分支/节点标准的优缺点.

我可以看到,在某些情况下,一种覆盖对另一种有明显的优势.例如,如果我的很多算法都包含在下一个例子中

void m();
void n();

void method(boolean b) {
    if (b) {
        m();
    } else {
        n();
    }
}

很明显,使用任何类型的数据流覆盖标准都会让很多逻辑未经测试(这是我们想要避免的).对于给定的情况,使用谓词/子句标准会更好.

现在,我想知道的是一般情况,在决定你将遵循哪种覆盖标准时,你在算法中寻找的是什么

• 图形
• 数据流
• 逻辑
• 输入
• 句法

各种覆盖标准(基本上,在软件测试简介中找到的标准).也就是说,对于一般情况,我基本上都在寻找一般的启发式方法.

谢谢

Answer 1

诚然，我在这个领域没有做太多研究，也不一定完全跟随你（主要是因为我在这个领域缺乏经验）。但希望这不是太离谱。

我对代码覆盖率的理解一直是你想要覆盖每一个可能的执行路径。现在我知道有些路径比其他路径重要得多（例如：“快乐路径”比设置某些属性的一些模糊路径重要得多），但无论天气如何，你至少“覆盖”每条路径希望了解它们的存在，并有意识地选择要覆盖什么和不覆盖什么（通过单元测试或手动）。

您可以从观察方法和编写测试用例开始，但这很快就会变得不可靠，因为无论算法类型如何，您都保证不会看到每个可能的执行路径。即使非常小的程序也会产生无法解释的错误，因为测试人员没有想到以这种方式“尝试”。

您真正需要的是一个代码覆盖率工具来告诉您单元测试覆盖了哪些执行路径，哪些没有覆盖。那时，您可以根据天气做出合理的决定，或者不覆盖那些丢失的案例（因为并非所有案例都不值得您花时间）。如果没有这样的工具，我认为您将花费无数的工时逐行跟踪哪些测试用例涵盖了什么...即使该工具花费数百美元（甚至数千美元），我认为您很快就能及时收回节省下来的资金。

因此，我对您的一般启发是使用这样的工具来跟踪您的测试覆盖率，并根据其结果决定覆盖或不覆盖。

一些代码覆盖率工具（不全面）：

• .NET- NCover
• PHP - PHP覆盖率
• JAVA-艾玛
• 红宝石-CoverMe
• JavaScript - JSCoverage