1

我们在我们的代码库（FTR）上运行 gcovr，然后输入 SonarQube（cxx-plugin）。有很多地方报告的覆盖率低于 100%，即使没有明显的分支，所以应该肯定是 0 或 100%。举个例子：

std::string quote(const std::string& str, const std::string& quote_str) {
    return quote_str + str + quote_str;
}

在 SonarQube 上，第一行报告为“完全覆盖”。第二行报告为“部分被测试覆盖（2 个条件中的 1 个）”。没有提到第三行 - 正如预期的那样。问题是（我猜）gcovr 在返回线上看到的我不能看到的条件是什么。

我已经尝试过为什么 gcc 4.1 + gcov 报告 100% 分支覆盖率和更新的 (4.4, 4.6, 4.8) 报告 50% 为“p = new class;”的建议 线？（添加--exclude-throw-branches），甚至尝试添加--exclude-unreachable-branches。似乎没什么区别。

查看生成的 xml 输出，我注意到前几行都显示 57 次命中，分支 =“false”。我想知道“两个条件中的一个”来自哪里，也许是 SonarQube？

有没有其他人看到这个或有解决方案？

更新

我一开始没有提到这一点，因为它似乎无关紧要，但我们使用的是 clang v11（不是 gcc），因此在 gcovr 下使用“llvm-cov gcov”（不是 gcov 本身）。如下所示，这似乎很重要。

4

2 回答 2

1

也许是 SonarQube？

SonarQube 不计算代码覆盖率信息。它只显示由其他工具生成的报告。如果有任何不正确的地方，您必须分析使用的覆盖工具配置。

“2 个条件中的 1 个”来自哪里

他们为覆盖工具而来。表达式有更多分支，因为可以使用以下值执行该方法：

+---------------------+
|   str   | quote_str |
+---------------------+
|   NULL  |   NULL    |
|   NULL  |  string   |
|  string |   NULL    |
|  string |  string   |
+---------------------+

如您所见，可能会引发一些异常。我相信你只检查了happy path没有抛出异常的地方，所以这就是为什么只1 of 2 conditions被覆盖的原因。

As you mentioned in the comment, it is possible to disable conditions related to exceptions by adding --exclude-throw-branches. I have no big experience in C++ code (I'm a Java developer), but I would prefer to has lower code coverage and be aware of potential exceptions instead of seeing 100% coverage and hit unexpected issues in the runtime.

于 2020-09-24T19:38:47.570 回答
1

I did write an earlier comment that it is perhaps sonarqube but I've had another look:) I think your comments about the possible values is flawed because these are standard C++ strings (not C ones) so effectively can't be NULL as such. However there is a possible OOM exception on the add - you are probably right that the non-followed branch is this exception.

I did some experiments comparing the gcovr output using the --exclude-throw-branches and --exclude-unreachable-branches. Basically it made no difference on the gcovr report for this line, although it did make some difference on other lines.

I am not sure I mentioned that we are using clang rather than (say) gcc. I guess that might make a difference. Not sure. Whatever the reflection does seem to be that this is a gcov/gcovr issue and not sonarqube. I had originally assumed that made no difference. Seems it does. From what I can work out, "llvm-com gcov" (the subcommand of llvm-cov that simulates gcov) does not generate the tags to show that some branches reflect throws. I've looked at the output locally - I probably need to compare with gcc and gcov. However that seems to be the real problem.

于 2020-11-11T19:59:24.227 回答