如何判断静态代码质量分析工具的性能？这五大因素必须考虑

静态代码质量分析工具能够查找常见的已知错误和漏洞，例如内存泄漏或缓冲区溢出，并检查代码是否符合各种编码标准。使用静态代码质量分析工具有助于在开发过程中分析代码，并在 SDLC 阶段的早期检测致命缺陷。

本文中，SonarSource 的社区经理 G. ANN CAMPBELL 将从环境、范围、语言、规则与问题修复五大因素入手，为您提供静态代码质量分析工具性能比较的参考。

作为 SonarQube 授权合作伙伴，创实持续关注代码安全领域，为中国用户带来全球范围内的优秀工具和解决方案，帮助企业实现开发运营安全一体化。

很多人可能都有过这样的经历：让孩子去做家务，结果孩子做家务做得飞快，一会儿的工夫就做完了。有时候我们自己做家务也是如此，也是很快就把家务做完了。虽然速度很快，但是质量如何我们心中是很清楚的：检查之后就会发现工作结果很难让人满意，之后就产生连锁反应，对一切都产生不良影响。

当人们开始谈论静态分析和/或 SAST 性能比较——或者实际上对任何类型的代码测试工具的性能进行比较时，记住上文的例子非常有意义。也许这种代码测试工具的速度很快，但它完成了什么？结果如何？质量如何？这就是为什么我今天想谈的话题——在比较性能时应该注意的问题。

假设您正在考虑更换代码测试工具，所以对静态代码质量分析工具 SonarQube 或 SonarCloud 进行测试。因为您在工作中已经使用了一些测试工具，所以对当前测试工具有了一定的了解。现在您只需要对新的代码测试工具进行测试即可。为了更好地进行代码测试工具的性能比较工作，您需要考虑性能对比中的以下几大因素。

分析环境

如果想比较两种代码测试工具的分析速度，您应该从分析环境着手。您是否在同一个平台上运行这两个工具（是否可比）？两个进程是否具有相同的可用资源（包括线程、内存等）？这些考虑看似普普通通，但却很容易被忽视。

分析范围

另一个决定分析速度的因素是分析范围。做对比的两种代码测试工具是否均配置为分析同一组文件？这会影响分析速度和分析质量。如果忽略重要文件，您将无法进行全面的代码分析。在要分析的文件集之中包括代码库和其他第三方内容，当结果出来时，您因需要费时费力地处理过多内容而使分析工作陷入困境。

除了文件，还有一个操作范围的问题。静态代码质量分析工具 SonarQube 和 SonarCloud 不仅仅在分析过程中提出问题。他们还计算复制百分比等指标，并收集软件配置管理（SCM）数据，用于问题属性和新代码的识别。

语言分析

SonarQube 和 SonarCloud 可提供多语言分析功能。通常情况下，无需要对该分析工具进行额外设置或配置，即可提供多语言分析功能。因此，使用 SonarCloud 和 SonarQube，您可能会获得比其他工具更广泛的分析范围。因为分析的文件数量比普通静态代码质量分析工具分析的要多，这种更广泛的分析可能会影响速度，可能也会对分析结果产生影响。

因此，如果 SonarCloud/SonarQube 分析与您基准测试中的特定工具相比，花费的时间稍长，您应该考虑的是，要获得与 SonarCloud/SonarQube 相同分析范围产生的分析结果，其他的工具需使用一整套。

规则

当我们谈论分析结果时，我们也应该谈论分析规则，因为分析规则对分析结果具有很大影响。SonarQube 和 SonarCloud 不仅仅提供多语言分析功能，它们还提供多领域分析功能。因此，这种代码分析不仅仅是安全性/SAST 分析，也不仅仅是代码质量分析。SonarCloud 和 SonarQube 能够发现代码漏洞、代码异味以及新代码的漏洞和安全热点。这意味着如果在每次分析中运行更多的分析规则，就能够发现更多的问题。完成所有这些工作可能需要更长的时间，但也许不会需要更长的时间，但 SonarCloud 和 SonarQube 提供了深度分析功能，这对于保持代码库的干净度和安全性非常重要。

修复问题

现在我们来谈谈分析结果。到目前为止，我们所做的分析都是与分析速度相关的性能对比：其实我们更应该做的是确保对分析速度的测试尽可能公平，以及在发现差异时应考虑的因素。现在我们来谈谈与分析质量相关的性能对比。

在对分析工具进行比较时，尤其是比较静态应用程序安全测试（SAST）工具时，很多人想要比较原始问题计数，并认为这样做才能体现出静态应用程序安全测试工具性能的优劣。但这就像相信一个孩子说他在 5 分钟内把房间打扫干净一样，你必须仔细观察才能找到真相。

让我们先假设您正在处理可比较的规则集，发现问题计数不匹配，并且存在一种情况：当前使用的代码测试工具报告未发现“缺失”问题但另一个代码测试工具却报告已发现“缺失”问题，这时您需要重点考虑的是：报告已发现“缺失”问题的报告是否为建设性意义的报告？举例来讲，有一次我们被问及另一个静态代码分析工具（不是 SonarQube 或 SonarCloud）提出的“缺失”CWE-117（日志输出中和不当）问题。是我们的静态代码测试工具功能有缺陷吗？答案是否定的，因为后续调查结果显示：

我们在 SonarQube 或 SonarCloud 特意禁用了在 HttpServletRequest 时引发问题这一功能选项。getHeader（）与日志记录相结合。“日志注入”的危险来自于可能引入换行符，然后这些换行符可以与虚假日志消息相结合，诱使某些用户进行不适当的操作。由于 HTTP 标头不能包含换行符，因此在这种情况下没有风险。

我们不是在刻意强调这个问题。事实上，我们已经做了很多工作来减少和避免误报，尽可能地让开发人员节约精力。我们还特意决定将漏洞报告（即存在需要修复的问题）与安全热点（即在某些情况下可能出错，需要人工审查）隔离开来。因此，原始问题计数很少可能说明整个情况。

不能用两件不同的事作比较，就像比较苹果与橘子

在任何时候进行比较时，都必须了解在同等环境中比较类似项目的程度。在前端，您可以做一些工作来公平竞争，减少我所说的外部差异——确保分析范围和资源相同。还有一些内在的差异是无法“平齐”的。

事实上，几乎不可能将 SonarQube 或 SonarCloud 与另一个静态代码分析工具进行一一比较。基于 SonarQube 或 SonarCloud 拥有的多语言、多领域分析的优势，我们有别于市场上的任何其他静态代码分析工具。如果您忽略这些差异，就忽略了我们的静态代码分析工具所创造的价值。

想要体验 SonarQube 或试用 SonarCloud，请联系 SonarQube 中国官方授权合作伙伴——创实 ，我们提供 SonarQube 产品的咨询、销售、 实施、培训及技术支持服务。

作者简介：

G. ANN CAMPBELL | 社区经理

文章来源：https://blog.sonarsource.com/5-things-to-consider-in-performance-comparisons/