sonar jacoco_通过Sonar和JaCoCo桥接内部和外部软件质量

sonar jacoco

软件质量通常分为两个世界。 一方面，外部质量的世界，其主要目标是确保软件按照预期进行响应。 该组包括集成测试（IT），用户接受测试（UAT），非回归测试和性能测试。 此测试过程的主要步骤包括与软件进行交互，观察其行为并确保其按照功能规范运行，并且以后不会脱离这​​些规范。 这些交互可以手动进行，也可以通过市场上存在的众多工具之一进行。 通常将其描述为“黑匣子”方法，其目的是构建“正确的软件”。 外部质量投资的回报是立竿见影的。

另一方面，内部质量的世界旨在衡量软件的构建质量。 这意味着使用静态和动态代码分析工具以及单元测试（UT）对源代码进行内部检查，以便根据一组预定义的技术要求查看软件的性能。 这是一种“白盒”方法，旨在确保我们在构建“正确的软件”。 您可以使用Sonar之类的软件质量分析工具来衡量内部质量，即根据开发人员的七大罪过来衡量技术债务。 每次犯罪失败都会产生技术债务，这会给软件带来风险，并且/或者随着时间的推移，维护起来会更加困难。 评估内部质量的真正投资回报是中长期的。

持续交付是指将发布时间表交到企业手中，这意味着确保您的软件在其整个生命周期中始终处于生产就绪状态-可以通过全自动过程只需按一下按钮就可以将任何版本发布给用户。

为了完全接受持续交付方法，必须持续评估外部和内部质量，因此必须以全自动方式对其进行监控。 此方法还包括回答以下问题：

• 测试对我的应用程序的覆盖程度如何？
• 了解集成测试和单元测试的覆盖范围将有助于开发人员更加准确地评估与要进行的更改相关的风险：
  • 我可以睡个好觉。 集成和单元测试覆盖了该行。
  • 更改此代码行时应格外小心。 尽管我会立即知道是否违反了合同（UT），但是我不能确定应用程序中不会有任何回归（因为缺少IT），反之亦然。
  • 如果我更改此行代码，则我正在玩俄罗斯轮盘。

尽管这些类别中的每一个都有执行此监视的工具，但是目前没有一个能够监视这两种类型的软件质量的工具。 在内部质量世界和外部质量世界之间架起一座桥梁，将为解决上述问题的应用提供更多的见解。 让我们更详细地研究这些问题。

新开发的源代码是否包含相关的集成测试？

重要的是要知道在给定的时间点有多少覆盖率，但更重要的是要确保在更改或添加新的代码行时，用适当的测试覆盖它们。 这将确保您使用软件质量的长期策略。 因此，基本上，您希望在每个sprint末尾查看的是该代码是否具有适当的覆盖范围（包括单元测试和集成测试）。

部署到生产环境的代码是否真的使用过？

据统计 ，生产中64％的功能从未使用过或很少使用。 我的软件就是这种情况吗？ 另外，我是否有任何与任何要求都不相关的代码？

更改此代码行时，我真正影响的是什么？

在代码中进行某些更改时，通常很难知道还会影响哪些其他组件。 进行某种制图来显示更改将对整个软件产生的影响确实会有所帮助。

思考并回答这些问题将有助于：

• 减少未映射到任何需求或功能的现有源代码，并专注于生产中实际使用的源代码。
• 在评估与源代码更改相关的风险时具有全局性。
• 拥有全面的功能软件制图，以何种频率使用频率以及经过多好的测试以提供最高的业务价值和最少的技术债务。

进行此软件质量评估的一个非常有趣的第一步是最近发布的Sonar工具新扩展JaCoCo扩展 。 为了通过集成/功能/验收/用户界面（UI）测试（例如集成测试）评估代码覆盖率，您必须执行两个步骤：

1. 必须执行测试，并且您真的不想在此过程中受到干扰，因为可以通过许多工具之一来完成测试-即Maven插件（maven-surefire-plugin，maven-osgi-test-plugin，maven-failsafe-plugin ），Ant脚本，GreenPepper或Selenium。
2. 然后，您需要检测要测量的内容，并且取决于应用程序包格式（JAR，EAR，WAR），这确实很棘手，甚至对于使用源代码检测（ Clover ）或脱机的覆盖引擎来说，也是一场噩梦。字节码检测（ Cobertura或Emma ）。 一个典型的Java应用程序包括几个Java库，对每个Java库进行静态检测通常太复杂而无法自动化。

对于这种用例，更好的方法是像JaCoCo一样进行“即时”字节代码检测。 覆盖范围信息必须在运行时收集。 为此，JaCoCo创建原始类定义的检测版本。 使用所谓的Java代理在类加载期间即时进行检测。 此外，这种独特的方法使它成为当前市场上更好的代码覆盖引擎 。

实施此扩展需要两个步骤：

1. 配置JaCoCo代理与集成测试一起启动后，启动集成测试，并在执行结束时转储Jacoco结果文件。
2. 配置并启动Sonar以重用JaCoCo结果文件。 Sonar插件将仅提取所需的代码覆盖率信息。

这是一个包含三个模块A，B和C的Maven项目的示例。C模块仅用于通过Maven故障安全插件执行集成测试，我们希望通过包含的集成测试来获得模块A和B的代码覆盖率在模块C中。必须将命令行参数添加到C模块的pom.xml文件中的Maven Failsafe插件的配置中。 下面的清单1显示了此javaagent命令行参数。

清单1. JaCoCo的Java代理配置

<argLine>-javaagent:${jacoco.agent.path}=destfile=${jacoco.file.path}</argLine>

现在，必须使用清单2中所示的命令启动模块C中的集成测试。

清单2.使用JaCoCo代理运行集成测试的Maven命令

mvn -Djacoco.agent.path="PATH_TO_AGENT" -Djacoco.file.path="PATH_TO_DUMP" -Prun-its clean install

运行集成测试后，您可以对整个项目执行Sonar分析。 请注意，您仍然可以使用Clover，Cobertura或Emma之类的代码覆盖率工具来评估单元测试的代码覆盖率，并使用JaCoCo扩展来运行集成测试。 下面的清单3是用于运行Sonar分析的Maven命令。

清单3.运行Sonar代码分析的Maven命令

mvn -Dsonar.jacoco.itReportPath="PATH_TO_DUMP" sonar:sonar

下面的图1显示了Sonar中的集成测试代码覆盖率指标。

图1.集成测试的代码覆盖率

当然，也可以向下钻取源代码，以查看集成测试覆盖或不覆盖哪些代码行。 此功能如图2所示。

图2.源代码级别的集成测试代码覆盖率

为了通过所有Maven模块的单元测试获得代码覆盖率，配置步骤非常相似。 以下是启用单元测试代码覆盖率的步骤。

• 将argline属性添加到您的Maven Surefire插件配置中。

  <argLine>-javaagent:${jacoco.agent.path}=destfile=${jacoco.file.path}</argLine>

• 使用以下命令构建Maven项目：

  execute mvn clean install -Djacoco.agent.path=”PATH_TO_AGENT” -Djacoco.file.path=”PATH_TO_DUMP”

• 使用以下命令运行Sonar代码分析步骤：

  execute mvn -Dsonar.jacoco.itReportPath=”PATH_TO_DUMP” sonar:sonar”

什么是下一个步骤？

路线图的下一项是“手动代码审查”。 开发人员可以开始与Sonar GUI进行交互以开始讨论，手动创建新的违规，将违规分配给开发人员或将违规标记为“假阳性”。

结论

通过使用Sonar中的JaCoCO扩展，可以通过集成测试评估代码覆盖率。 尽管有人在努力确保各种技术文档之间的可追溯性，但Sonar团队已选择投资以确保可执行规范和源代码之间的连续且自动的可追溯性。

翻译自: https://www.infoq.com/articles/gaudin-sonar-jacoco/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

sonar jacoco