具有100%代码覆盖率的白盒测试用例

Question

我很抱歉，因为我对软件测试非常陌生。但我有一个简单的代码，可以创建一个白盒测试用例，代码覆盖率为100%：

01 public class ShapeAreas {
02
03 public double oneParameter(String shape, float x1)
04 {
05     float area;
06     if (shape.equals("A"))
07         return x1 * x1 * Math.XI;
08     else if (shape.equals("B"))
09         return x1 * x1;
10     else 
11         return -1.0;
12 }
13 
14 public double twoParameter(String shape, float x1, float x2)
15 {
16     float area;
17     if (shape.equals("N"))
18         return x1 * x2;
19     else if (shape.equals("M"))
20         return 0.5 * x1 * x2;
21     else
22         return -1.0;
23 }
24 }

我需要关于我的输入数据在这段代码中应该是什么样子的帮助，以便用最少的测试用例实现100%的代码覆盖率。

我很感激能帮上忙，谢谢！

Answer 1

你必须在每种方法中寻找分支，以获得100%的覆盖率。对于oneParameter方法，它是A，B，X作为shape参数，对于two parameter方法，它是N，M，X。

每种方法的3个测试用例将为您提供100%的覆盖率。

然而，它不会告诉你你的代码是100%正确的。

例如，尝试将null作为形状。（这将导致NullpointerExc0019）

您还需要定义计算所需的精度。（双返回类型与浮点计算。）

public void testOneParameterWithShapeB() {
  double result = sut.oneParameter("B", 1.0);
  //TODO check the result
}

Answer 2

为了能给出更好的解释，我自由地在代码中添加行号。你在评论中提到你对声明的报道感兴趣。代码示例中的语句见第07、09和11行，以及第18、20和22行。当然，if语句本身也是语句（因此得名），但它们将在每次执行相应函数时执行。

在函数oneParameter的一次执行中，将只执行一个条件语句：第07行、第09行或第11行。这是因为if-else-if-else语句的排他性。类似地，在一次调用functiontwoParameter时，将执行第18行、第20行或第22行中的语句。

因此，要覆盖所有语句，必须对每个函数调用三次。在这两种情况下，控制实际分支的参数都是shape参数。这意味着，其他参数的值与要执行的语句无关。一组微不足道的调用可能是：

oneParameter("A", 0.0);
oneParameter("B", 0.0);
oneParameter("any other", 0.0);
twoParameter("N", 0.0, 0.0);
twoParameter("M", 0.0, 0.0);
twoParameter("any other", 0.0, 0.0);

这是一个实现100%语句覆盖率的最小调用集的示例。令人惊讶的是，这些只是调用——甚至没有对结果的任何评估。当我们谈论测试覆盖率时，隐含的假设是，相应的代码行不仅仅是执行的，而且相应的结果是作为测试的一部分进行评估的。这可能看起来像下面这样：

assertEquals(0.0, oneParameter("A", 0.0));
assertEquals(0.0, oneParameter("B", 0.0));
assertEquals(-1.0, oneParameter("any other", 0.0));
assertEquals(0.0, twoParameter("N", 0.0, 0.0));
assertEquals(0.0, twoParameter("M", 0.0, 0.0));
assertEquals(-1.0, twoParameter("any other", 0.0, 0.0));

尽管它现在有100%的语句覆盖率，并且还对结果进行评估，但它仍然远远不是一个高质量的测试套件。原因如下：单元测试通常以发现代码中的错误为主要目标。然而，上面的测试集不太适合找到任何有趣的错误。给你一些这个测试套件找不到的可能错误的例子：

• 由于错误，在函数oneParameter中对“A”和“B”的计算被交换

这些只是可能的错误的例子。因此，认真对待寻找可能的错误的目标需要不仅仅考虑覆盖面。事实上，甚至可能有部分代码根本不适合用单元测试来测试——尽管在你的简单例子中情况并非如此。这种代码部分的示例是不可访问的代码（例如，为了健壮性而添加的开关语句的默认分支），或者只包含与其他组件交互的代码，在这种情况下，集成测试是更合适的方法。因此，达到100%覆盖率的目标通常是没有意义的，即使你真诚地努力争取一个高质量的单元测试套件。

然而，对于有兴趣确保在代码中解决了所有相关场景的开发人员来说，覆盖率是一个有价值的信息。可悲的是，从管理的角度来判断测试套件的质量时，覆盖率远没有那么重要：在这种情况下，覆盖率往往会降低到一个简单的百分比，开发人员被迫创建测试，直到达到某个覆盖率百分比——但在没有给他们足够的培训的情况下，覆盖率往往已经足够了，时间和鼓励来正确地进行测试。因此，为了达到（比如）80%的覆盖率，所有琐碎的代码（getter和setter等）都可能会经过“测试”，以增加覆盖率。然而，对最复杂、最难测试的20%代码的测试由于时间不足而推迟（尽管这可能是隐藏bug的代码）。而且，即使是已经涵盖的80%的测试，也可能会像我在上面展示的最小测试套件一样，进行糟糕的测试。