测试背景
使用工具：
- 源伞科技Pinpoint
- Sonarqube
测试项目：
- 开源国产CMS软件iBase4J(6000行代码)
测试结果汇总
数据统计：
- SonarQube结果：
| 代码错误 | 安全隐患 | 风格质量 | 总量 | |
|---|---|---|---|---|
| 有效/总量 | 2/6 | 4/4 | 0/93 | 6/103 |
- 源伞科技Pinpoint结果：
| 代码错误 | 安全隐患 | 风格质量 | 总量 | |
|---|---|---|---|---|
| 有效/总量 | 2/2 | 19/19 | 6/7 | 27/28 |
我们将所有bug归为以下3类：
| 分类 | Sonarqube对应分类 | Pinpoint对应分类 |
|---|---|---|
| 代码错误 | bug类 | 代码崩溃、数值处理不当类 |
| 安全隐患 | Vulnerability类 | 代码安全类 |
| 风格质量 | Code Smell类 | 代码风格、性能问题类 |
有效报告：我们定义有效报告为真实影响程序执行并值得进一步检查修复的问题报告。
测试细节：
- 数量：
从数量看，Pinpoint结果确实明显少于SonarQube。但是有效报告明显少于Pinpoint.
- 安全隐患：
从质量看，首先Pinpoint可以找到很多SonarQube无法发现的Vulnerability,也就是安全隐患（19比4），其中SonarQube找到的4个有效报告Pinpoint也能找到，Pinpoint找到15个SonarQube没有找到的问题。
SonarQube的3个报告属于同一类别，是在exception.printStackTrace()调用的时候，最好打log，不要直接打到屏幕上（这个被SonarQube归类为安全问题）, Pinpoint会提示这里会有stack trace信息泄露问题。如下图所示：
Pinpoint：
SonarQube:
除了这些，Pinpoint还找到了如下所示的安全隐患
这些问题SonarQube都没有报告。
- 代码错误：
对于代码错误，SonarQube找到了6个,而Pinpoint只找到2个问题，这两个问题SonarQube也找到了，是有效报告。SonarQube归类为bug的另外4个Pinpoint没有报告的问题可以归为两类：
第一个是参数修改，这个是JAVA中很常见的应用方式，不太会引起程序错误，也会带来大量误报，所以Pinpoint没有列为bug，如下图：
![]()
在这里插入图片描述
第二个是常量的，隐式类型转换，也是正确的用法，如下图：
![]()
在这里插入图片描述
- 风格质量：
对于风格质量类问题，SonarQube共报了93个问题，而Pinpoint只报了7个，两个工具的报告完全没有交集。
SonarQube共报了93个问题，所有这些问题并不会产生实际代码错误的问题，比如 if(a) {if(b){}} 要写成 if(a&&b){} 这样的问题，举例如下：
这些中的很多问题实际上可以修改一下，但是无论改与不改并不会实际影响程序的执行。
Pinpoint报告的7个问题SonarQube都没有报，这里包括几类问题：
可能缺失的异常处理（这里mkdir可能失败），如下图：
![]()
在这里插入图片描述
可能引起反序列化安全隐患的问题：
![]()
在这里插入图片描述
无意义的包装+拆装组合，切实影响程序的执行效率
![]()
在这里插入图片描述
无意义的null-check:
![]()
在这里插入图片描述
除了最后一个影响不大（Severity=Low）其他每一个都是要仔细检查的，SonarQube虽然报了93个，但是这7个重要的都没有报。
主要结论：
- 从报告总量上SonarQube比Pinpoint多报了很多（103/28），但是有效报告Pinpoint要明显多于SonarQube（27/6）。
- 6个有效报告SonarQube和Pinpoint同时报出。Pinpoint有21个有效报告SonarQube无法检出。
- SonarQube绝大多数是可有可无的修复，并不影响程序执行，Pinpoint虽然只有28个报告，但是每个报告都是值得一看的（除了标记为low的那个无意义的null-check，那个虽然可以改一下，但是对程序执行几乎没有影响）。
- Pinpoint和SonarQube关注点有区别，有3个有效报告SonarQube报printStackTrace应该打到log里而不是屏幕上，这个Pinpoint没有归类为bug, 同样的位置Pinpoint报告的是stack trace信息泄露隐患。
为国产工具源伞科技Pinpoint打Call !!
为国产静态检测工具源伞科技Pinpoint打Call!
