unit-testing - 白盒测试用例，代码覆盖率100％

Question

我很抱歉，因为我是软件测试的新手。但是我有一个看起来很简单的代码来创建具有100％代码覆盖率的White-box测试用例：

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

我可以自由地在代码中添加行号，以便能够给出更好的解释。您在提到的评论中对语句覆盖范围感兴趣。您的代码示例中的语句位于07、09和11行以及18、20和22行中。而且，当然，if语句本身也是语句（因此具有名称），但是无论如何它们都将在以下位置执行各自功能的每次执行。

在函数oneParameter的一次执行中，将恰好执行以下条件语句之一：在第07行，在09行或在第11行。这是因为if-else if-else语句的排他性。类似地，在对函数twoParameter的一次调用中，将执行第18行，第20行或第22行中的语句。

因此，要覆盖所有语句，您必须调用每个函数3次。在两种情况下，控制实际分支采用的参数都是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"的计算被交换。
在 twoParameter的功能 "N"中， *错误地交换了 +操作。
在 twoParameter的函数 "N"中，表达式不是将 x1与 x2乘以，而是将 x1与 x1乘以。
在 twoParameter的功能 "M"中，常数设置为 0.05，而不是正确的 0.5。


这些只是可能的错误的示例。因此，认真对待可能发现的错误的目标需要思考的范围不仅仅限于覆盖范围。实际上，甚至有一些代码部分根本不适合通过单元测试进行测试-尽管在您的简单示例中并非如此。此类代码部分的示例是无法访问的代码（例如，为增强鲁棒性而添加的switch语句的默认分支），或仅由与其他组件的交互组成的代码，在这种情况下，集成测试是更合适的方法。因此，即使您真诚地追求高质量的单元测试套件，达到100％覆盖率的目标通常也没有意义。

但是，对于有兴趣确保开发人员已解决其代码中的所有相关方案的开发人员而言，覆盖率仍然是宝贵的信息。可悲的是，从管理的角度判断测试套件的质量时，覆盖率的价值远不如：在这种情况下，覆盖率通常只降低到很小的百分比，开发人员被迫创建测试，直到达到某个覆盖率为止-但是经常在没有给他们足够的培训，时间和鼓励的情况下进行适当的测试。结果，要达到例如80％的覆盖率，所有琐碎的代码（getter和setter等）可能会受到“测试”以增加覆盖率。但是，由于时间不足，推迟了对最复杂，最难测试的20％代码的测试（尽管这可能是隐藏了错误的代码）。而且，即使覆盖了80％的空间，也可能会像我上面显示的最小测试套件那样进行糟糕的测试。