28

我有这个开关系统，我正在使用 eclemma 来测试分支覆盖率。我们需要对所有内容至少有 80% 的分支覆盖率，所以我正在尝试尽可能多地进行测试。但是，eclemma 告诉我这个交换机系统在分支覆盖方面没有经过全面测试。

pos = p.getCurrentPosition().substring(0, 1);
switch (pos) {
            case "G":
                goalkeepers++;
                break;
            case "D":
                defense++;
                break;
            case "M":
                midfield++;
                break;
            case "F":
                offense++;
                break;
            case "S":
                substitutes++;
                break;
            case "R":
                reserves++;
                break;
        }

我使用简单的 JUnit 测试来处理每种情况。仍然 eclemma 将此标记为黄色，并表示“19 个分支中有 7 个丢失”。我想说只有 7 种方法可以通过这个开关系统（6 个单独的案例 + 全部未定义）。

我尝试搜索有关堆栈溢出的类似问题。其中一些具有使用 if/else 进行全面覆盖的解决方案。我不确定这是否是获得此覆盖的唯一方法。

任何人都可以解释所有这 19 个分支的来源以及我如何测试剩余的 7 个分支以在此 switch 案例上获得 100% 的分支覆盖率？

4

2 回答 2

36

Java 编译器将 switch-case 代码转换为 atableswitch或 a lookupswitch。当tableswitch不同情况之间只有几个间隙时使用。否则，lookupswitch使用 。

在您的情况下tableswitch使用 a 是因为您的情况的哈希码间隔很近（与 owaism 引用的代码不同）：

  16: tableswitch   { // 68 to 83
                68: 111 // 'D'
                69: 183
                70: 141 // 'F'
                71: 96  // 'G'
                72: 183
                73: 183
                74: 183
                75: 183
                76: 183
                77: 126 // 'M'
                78: 183
                79: 183
                80: 183
                81: 183
                82: 171 // 'R'
                83: 156 // 'S'
           default: 183
      }

冒号左边的数字是有序的哈希码和它们之间的填充间隙，右边的数字是跳转目的地。（在 Java 中，字符的哈希码是它的 ASCII 值。）

68是“D”（最低位）83的哈希码，是“S”（最高位）的哈希码。 69是真实案例之间差距之一的值，将跳转到默认案例。

但是，我假设 EclEmma 从 a 的覆盖率计算中排除了这些分支tableswitch（由于存在差距，它会进一步降低覆盖率）。所以我们还有0 个（计数的）分支。

接下来，在每个跳转目的地执行字符串值的相等比较（默认情况除外）。由于您的 switch-case 由 6 个 case 组成，因此我们有 6 个 6 个跳转目的地并进行相等比较。

案例“G”的比较字节码如下：

  96: aload_3
  97: ldc           #10
  99: invokevirtual #11  java/lang/Object;)Z
 102: ifeq          183
 105: iconst_0
 106: istore        4
 108: goto          183
 111: aload_3

EclEmma 计算两个分支：输入字符串和案例字符串相等或不相等。因此，我们有6 * 2 个分支用于比较。（默认情况不分支。）

接下来，如果两个字符串相等，则将存储案例的索引（105-106案例“G”的字节代码行）。tableswitch然后将执行到第二个的跳转。否则直接跳转。

 185: tableswitch   { // 0 to 5
                 0: 224
                 1: 237
                 2: 250
                 3: 263
                 4: 276
                 5: 289
           default: 299
      }

此开关对先前存储的案例索引进行操作并跳转到案例中的代码（案例“G”具有索引0，默认案例具有-1）。EclEmma 计算了 7 个分支（6 个案例加上默认案例）。

因此，在第一个中我们有 0 个计数分支，tableswitch在比较中有 12 个分支，equals在第二个中还有 7 个分支tableswitch。总而言之，这会产生 19 个分支。

您的测试不涵盖 6 个不等于分支中的任何一个。 为了涵盖这些，您需要为每个案例找到一个不等于案例条件但具有相同哈希码的字符串。这是可能的，但绝对不明智......

很可能，EclEmma 的分支计数将来会调整。

此外，我猜您没有与任何案例都不匹配的测试案例（因此不包括（隐式）默认案例。）

于 2015-01-18T21:50:47.097 回答
0

查看以下链接：http: //sourceforge.net/p/eclemma/discussion/614869/thread/80e770df/

以下是上述链接的片段：

这是一个具有 3 个案例的开关的示例：

这是一个非常有趣的观察。通过查看字节码，可以看出 Java 编译器如何处理字符串切换。实际上这是一个 3 步过程：

  1. 打开哈希码（3 个分支，1 个默认）
  2. 对每个哈希码做一个等于（3 * 2 个分支）
  3. 为案例的实际执行进行最终切换（3 个分支，1 个默认）

所以我们总共有 14 个分支，从源代码的角度来看，这看起来很奇怪。看起来更奇怪的是你错过了其中三个。解释是步骤 2，其中在哈希码之后额外应用了 equals 方法。要覆盖这些分支，您还需要找到具有相同哈希码的其他字符串。这绝对是可以从 JaCoCo 未来版本的覆盖报告中过滤掉的东西：
https ://sourceforge.net/apps/trac/eclemma/wiki/FilteringOptions

于 2015-01-18T20:04:38.457 回答