作者：华婧彤 职位：QA工程师
●测试左移是要尽早的发现和预防问题，使用必要的测试手段在软件开发周期的早些阶段发现问题。
●测试左移的方式有静态代码扫描、CodeReview、代码提交行为分析等。
我们知道问题发现的越早，解决的成本就越小。统计证明，在整个软件开发生命周期中，30%至70%的代码逻辑设计和编码缺陷是可以通过静态代码分析来提早发现的。今天我们来了解一下测试左移里面的其中一种方式——静态代码扫描。不运行代码的方式下，通过词法分析、语法分析、控制流、数据分析等技术对程序代码进行扫描，验证代码是否满足规范性、安全性、可靠性、可维护性等指标的一种代码分析技术。
接下来我们来了解一下SonarQube～
●SonarQube是一款静态代码扫描工具，用于检测代码中的错误，漏洞和代码异味。
●支持Java、Python、PHP、JavaScript、CSS等25种以上的语言。
●多维度分析代码：代码量、安全隐患、编写规范隐患、重复度、复杂度、测试覆盖率、代码增量等。
●支持和CI/CD环境进行集成（如Gitlab,Github,Jenkins等）能够持续进行代码质量检测。
●支持集成pmd、findbugs、checkstyle等插件来扩展使用其他规则来检验代码质量。
1. SonarQube服务端：
webserver（配置和管理sonar）
searchserver（搜索结果返回给sonarUI）
ComplateEngineserver
（计算服务 将分析结果入库）
2. SonarScanner扫描工具，类似客户端
（可以有多个）
3. Sonarqube对应的数据库：数据库 存放配置
4. 针对于不同语言的扫描插件
1. 开发人员可在IDE工具中安装SonarLint插件并设置sonar服务地址，可在编辑器中接收即时反馈，及时修改问题。
2. 开发人员将他们的代码推送到对应的代码管理的平台。
3. 组织的持续集成 (CI) 工具检查、构建和运行单元测试，集成的 SonarQube 扫描仪分析结果（我们可以通过设置sonar质量门，扫描结果不符合阀值要求，当pipeline在运行的时扫描结果会失败）
4. 扫描器将结果发布到 SonarQube 服务器，该服务器通过 SonarQube 界面、电子邮件、IDE 内通知（通过 SonarLint）以及对拉取或合并请求的修饰向开发人员提供反馈。
5. 开发者对扫描出来的问题进行解决、评论、跟踪等。
4.1 扫描的规则
Sonar内嵌了Sonar way的扫描规则，不同语言（比如Java/Python/C#等）具有不同规则。
Sonar集成了pmd/findbugs/checkstyle插件，对规则集进行补充。
成功安装插件后，就可以在仓库中看到以下规则：
①使用不同规则集进行对比扫描
a.使用Sonar内置的规则（Sonar way）进行扫描
b.仅使用pmd+findbugs+checkstyle规则进行扫描
②问题对比
a.Sonar内置规则检查出的空指针报错
b.findbugs插件检查出的空指针报错（对比Sonar内置规则发现的问题，内置规则给出了更多的修改建议）
c.PMD规则检查出的代码规范以及注释问题（会新增很多Sonar内置规则扫不出的问题）
Sonar还支持自定义规则开发，开发适用于自己项目的检查规则：
①开发步骤见 Writing Custom Java Rules 101，这是官方提供的 sonar-java 下面的指导文档，简述了怎么开发一个 Java 自定义规则
②下载的模版项目完成自定义开发后
a.执行编译 mvn clean package
b.把生成的文件放在 $SONAR_HOME/extensions/plugins 目录，重启 SonarQube
③【代码规则】对应左边栏【仓库】中会展示新增了导入的规则
我们可以通过自定义扫描规则集以及异常的等级来定制检测问题，可以大大减少误报，更高效的查看结果报告并进行处理。
①新创建规则集：【质量配置】-》【创建】
也可以对已存在的规则配置进行扩展以及复制规则一份进行修改。
②创建成功后，可对该规则集添加规则、设置应用的项目。
③添加更多规则
点击其中一条规则的“激活按钮”，弹出确认对话框，在对话框中可以修改规则的异常等级。
（也可批量修改”按钮可以将当前页过滤出来的所有规则批量应用到当前质量配置中）
质量阈是对项目指标进行度量的条件，项目必须达到所有条件才能算整体上通过
可以自定义进行设置质量阈（重复率，可靠性，可维护性，安全率、覆盖率等）
①代码规范：sonar可以通过PMD,CheckStyle,Findbugs等代码规则检测工具规范代码编写。
②潜在的bug：sonar可以通过PMD,Findbugs等代码规则检测工具检测出潜在的缺陷。
③重复：显然程序中包含大量复制粘贴的代码是质量低下的，sonar可以展示源码中重复严重的地方。
④注释不足或者过多：没有注释将使代码可读性变差，特别是当不可避免地出现人员变动时，程序的可读性将大幅下降 而过多的注释又会使得开发人员将精力过多地花费在阅读注释上，亦违背初衷。
⑤复杂度分布：文件、类、方法等，如果复杂度过高将难以改变，这会使得开发人员难以理解它们且如果没有自动化的单元测试，对于程序中的任何组件的改变都将可能导致需要全面的回归测试。
⑥缺乏单元测试：sonar可以很方便地统计并展示单元测试覆盖率。
⑦糟糕的设计：通过sonar可以找出循环，展示包与包、类与类之间相互依赖关系，可以检测自定义的架构规则通过sonar可以管理第三方的jar包，可以利用LCOM4检测单个任务规则的应用情况，检测耦合。
点击对应问题可进入问题详情页面，会看到问题源码，sonarQube会根据代码提交信息这自动将任务分配给相关人员，若该用户设置了检查结果提示，在执行代码检查完成后，会自动收到邮件通知，当然你也可以将这个问题指派给其他人处理。