<100%测试覆盖率 - 选择测试区域的最佳实践

Question

假设您正在处理项目,而时间/金钱预算不允许100%覆盖所有代码/路径.

然后,需要测试代码的一些关键子集.显然,可以使用"肠道检查"方法来测试系统,直觉和手动分析可以产生某种"确定"的测试覆盖范围.

但是,我假设有最佳实践/方法/流程可以识别关键元素达到某个阈值,并让您将测试元素集中在这些块上.

例如,一种用于识别制造中的故障的流行过程是故障模式和效果分析.我正在寻找一个过程来识别软件中的关键测试块.

Answer 1

100%的代码覆盖率不是理想的目标.出于某些原因,请参阅此博客.

我的最佳实践是从用例中派生测试用例.在系统应该实现的用例和证明它有效的测试用例之间创建具体的可跟踪性(我使用UML工具,但电子表也可以).

明确识别最关键的用例.现在看看他们追踪的测试用例.您是否有许多针对关键用例的测试用例？它们是否涵盖了用例的所有方面？它们是否涵盖了负面和例外情况？

我发现这是确保良好覆盖率的最佳公式(并最好地利用团队的时间).

编辑:

一个简单,人为的例子,说明为什么100%代码覆盖率不能保证您100%测试案例.假设CriticalProcess()应该调用AppendFile()来追加文本,而是调用WriteFile()来覆盖文本.

[UnitTest]
Cover100Percent()
{
    CriticalProcess(true, false);
    Assert(FileContents("TestFile.txt") == "A is true");

    CriticalProcess(false, true);
    Assert(FileContents("TestFile.txt") == "B is true");

    // You could leave out this test, have 100% code coverage, and not know
    // the app is broken.
    CriticalProcess(true, true);
    Assert(FileContents("TestFile.txt") == "A is trueB is true");
}

void CriticalProcess(bool a, bool b)
{
    if (a)
    {
        WriteFile("TestFile.txt", "A is true");
    }

    if (b)
    {
        WriteFile("TestFile.txt", "B is true");
    }
}

Answer 2

除非您使用TDD进行绿地开发,否则您不太可能获得(或想要)100%的测试覆盖率.代码覆盖范围更像是一个指导原则,可以问"我没有测试过什么？"

您可能希望查看其他指标,例如圈复杂度.找到代码的复杂区域并测试它们(然后重构以简化).