随行付微服务测试之静态代码扫描

静态代码扫描为整个发展组织增长价值。不管您在开发组织中发挥的做用如何，静态代码扫描解决方案都具备附加价值，拥有软件开发中所须要的尖端功能，最大限度地提升质量并管理软件产品中的风险。

背景

微服务架构模式具备服务间独立，可独立开发部署等特色，独立开发诱发了技术上的分离，HTTP通讯增长了问题诊断的复杂度，对系统的功能、性能和安全方面的质量保障带来了很大的挑战。

微服务架构对测试的挑战

微服务架构模式下多个独立业务系统（服务）同时开展开发工做，每一个系统都有各自的业务范围和开发周期要求，这样一来，下图所示的传统流程中产品经理提供需求，需求人员进行需求分析、开发人员进行开发，最后交给测试人员进行测试的方法，就没法知足测试覆盖和测试效率的要求。

相对于传统的单体模式而言，微服务模式下对测试带来的挑战总结起来包括如下内容：

• 1. 微服务系统模块层次化，须要保证模块内部代码的质量。这种场景下传统的端到端的测试没法知足测试要求；
• 2. 须要保证各个微服务系统内部模块间的正确性。系统模块间以及前端和后端一般会同时开展开发工做，模块间或者先后端经过接口（一般是Restful http接口）进行链接，而模块和后端每每没有界面，为了保证各个系统单个依赖系统的正确性，所以须要借助Mock技术隔离依赖的前提下进行接口级的测试；
• 3. 须要保证微服务系统中的接口一致性，即契约的一致性。须要经过契约测试手段保证契约的正确性，进而保证同步开发过程当中的先后开发的正确性和一致性；
• 4. 须要保障单个微服务系统的正确性。须要进行组件级的测试进行微服务系统的正确性；
• 5. 须要保障整个系统的正确性。各个微服务系统串接以后经过端到端的测试保证总体系统的正确性；

微服务架构下如何开展测试

针对上面提到的微服务对测试的挑战，一方面为了保证在服务各个层级上对微服务进行全面的测试，特别是对于分布式系统；另外一方面又要确保测试执行的效率，这样才能保证持续集成/持续交付（CI/CD）。所以，整体的测试策略采用以下解决方法：

• 1. 开展「质量」文化。让开发人员创建起代码「质量」意识，用于保障模块内部的质量；
• 2. 采用自动化测试手段。在微服务架构中，开发分解为负责不一样服务的多个小组，测试人员每每天天要花费大量的时间，了解不一样团队的开发进度。若是还须要手动进行回归测试（Regression Test），最终将会不堪重负。因此自动化测试在微服务模式下是必须采起的手段。
• 3. 分层的自动化测试策略。自动化测试分层在Mike Cohn 提出的测试金字塔（Test Pyramid）原理中进行了详细的阐述。它提倡在代码级、接口级、应用级进行不一样粒度的测试来保证系统的质量。从自动化测试投入比例来看，单元测试和静态代码扫描的投入比例最大，其次是接口自动化测试，最后是UI自动化测试。同时为了提升测试效率和测试覆盖率，功能测试须要借助探索式测试手段开展测试。

• 4. 采用流水线技术进行可视化快速反馈。因为微服务系统很是多，这样每每会增长了运维和沟通成本，为了提升沟通效率，须要借助流水线的技术，可视化查看每个构建（Build）、测试（Test）、部署（Deploy）过程，快速作出质量反馈和处理决策。经过可视化流水线最终能够实现各个环节的监控，采用DevOps手段打通业务、开发、测试和运维的部门墙。

下面结合分层自动化测试的思想，首先对静态代码扫描进行介绍。

静态代码扫描

静态代码扫描背景

静态代码分析是指在不运行代码的方式下，经过词法分析、语法分析、控制流、数据流分析等技术对程序代码进行扫描的技术。它的目的是验证代码是否知足规范性、安全性、可靠性、可维护性的要求。静态代码扫描处于分层自动化测试的最底层，它和单元测试同级别。为了保证公司代码的规范性、安全性、可靠性的要求，经过定制公司级的静态代码扫描规范、扫描规则和扫描实施流程保证明施高效落地。

静态代码扫描意义

为开发者

软件开发人员最终负责代码质量。代码质量是非功能性需求的一部分，所以是开发人员的直接责任。代码质量不该该存在技术债务，在开发的过程当中每一步都提供反馈，从IDE到发布。这使得开发人员可以尽早作出有关代码质量的决策，使他们可以作得更好，并提供质量更好的软件产品。

为DevOps

DevOps须要确保软件的构建方式正确。DevOps中涉及的责任不少，其中包括支持开发流程，自动化测试，确保质量，提升生产力.....并最终实现持续部署。良好的代码质量是实现全部这些目标的必要条件，尽管不是充分条件。静态代码扫描可在任何构建/测试/部署步骤中添加的代码质量检验门槛，可以自动执行一组统一的质量标准，从而确保组织交付更好的软件。

为管理者

代码静态扫描可下降风险并提升团队生产力。管理人员须要可以安全地运行软件，而且须要花费合理的投资回报。咱们的解决方案一目了然地显示了他们面临的技术债务以及他们缓解的成本。它还具备开箱即用的功能，能够系统地提升开发团队的可维护性和长期生产力。这使管理人员可以以最佳成本使用风险控制方法确保其组织可以交付更好的软件。

静态代码扫描介绍

静态代码扫描处在特性分支开发完成以后，具体的描述以下：

• 1. 开发人员从Master分支拉取特性分支做为开发分支；
• 2. 开发完特性分支后、代码构建、单元测试、静态代码扫描；
• 3. 经过后合并到Master分支，用于投产；

随行付静态代码流程

随行付静态代码扫描平台的具体实现是经过集成SonarQube平台工具、Jenkins集成工具、IDE SonarLint插件和CheckStyle本地化规则模板等开源工具、插件集而成。实现本地化代码的实施检测，版本构建后的二次检测，以及邮件反馈等功能的流程闭环，保证投产前代码符合随行付代码规范的要求。具体的流程以下图所示：

• 1.本地化IDE中经过SonarLint插件实现和SonarQube平台规则、规范的同步、实现本地代码检查；随行付定制化了java规则、XML规则257条，javascript规则86条，用于检测代码的规范性、代码缺陷、漏洞、坏味道、重复率等信息。并将定制化的规则放到了SonarQube平台上，SonrLint插件的规则比较全面，包括全部的sonajava规则和javascript规则，为了保证本地使用定制的规则，且同sonarqube中的规则一致，须要远程链接SonarQube服务器,并绑定项目。以Eclipse为例，展现SonarQube链接和项目绑定过程：

  

• 2.代码提交到代码库GitLab中后，在Jenkins中测试环境构建时，自动触发Sonar扫描，并将扫描结果发布到SonarQube平台。下图为SonarQube展现的一个项目的结果：

  

• 3.SonarQube平台根据质量阀的要求，不知足质量阀要求则邮件通知开发人员。

质量阀要求：
 	1.新覆盖率大于等于80%；
  	2.新增Bugs为0；
	3.新增漏洞为0；
	4.新增坏味道为0；
复制代码

• 4.开发人员收到邮件后，进行代码处理，直到知足规范要求为止。
• 5.以周为单位统计SonarQube平台中静态代码扫描出来的Bugs\漏洞\坏味道的数量，定时自动发送周报给相关干系人，报告中会包含问题处理状况的趋势图。

  

SonarQube与规则

SonarQube是一个用于代码质量管理的开源平台，支持25+种编程语言的质量扫描。SonqrQube由远程机、Server端和数据库构成。远程客户机能够经过各类不一样的分析机制，从而将被分析的项目代码上传到SonarQube server 并进行代码质量的管理和分析，SonarQube 还会经过Web API将分析的结果以可视化、可度量的方式展现给出来。逻辑结构以下图所示： {% asset_img img11.png img11.png %}

SonarQube的整合能力

SonarQube平台中支持整合各类静态代码扫描检测工具。SonarQube中各类代码检测工具分析对象及应用技术对比：

Java静态分析工具	分析对象	应用技术
CheckStyle	Java源文件	缺陷模式匹配
FindBugs	字节码	缺陷模式匹配；数据流分析
PMD	Java源代码	缺陷模式匹配

CheckStyle

能够很方便的帮咱们检查Java代码中的格式错误，它可以自动化代码规范检查过程，从而使得开发人员从这项重要，可是枯燥的任务中解脱出来。基本上都是根据开发规则定制规则。主要涵盖如下内容：

• Javadoc 注释：检查类及方法的 Javadoc 注释
• 命名约定：检查命名是否符合命名规范
• 标题：检查文件是否以某些行开头
• Import 语句：检查 Import 语句是否符合定义规范
• 代码块大小，即检查类、方法等代码块的行数
• 空白：检查空白符，如 tab，回车符等
• 修饰符：修饰符号的检查，如修饰符的定义顺序
• 块：检查是否有空块或无效块
• 代码问题：检查重复代码，条件判断，魔数等问题
• 类设计：检查类的定义是否符合规范，如构造函数的定义等问题

FindBugs

Findbugs是一个静态分析工具，它检查类或者JAR文件，将字节码与一组缺陷模式进行对比以发现可能的问题。主要涵盖如下内容：

• Bad practice 坏的实践：常见代码错误，用于静态代码检查时进行缺陷模式匹配
• Correctness 可能致使错误的代码，如空指针引用等
• 国际化相关问题：如错误的字符串转换
• 可能受到的恶意攻击，如访问权限修饰符的定义等
• 多线程的正确性：如多线程编程时常见的同步，线程调度问题
• 运行时性能问题：如由变量定义，方法调用致使的代码低效问题

PMD

一种开源分析Java代码错误的工具，其原理为使用JavaCC生成解析器来解析源代码并生成AST(抽象语法树)。与其余分析工具不一样的是，PMD经过静态分析获知代码错误。也就是说，在不运行Java程序的状况下报告错误。PMD附带了许多能够直接使用的规则，利用这些规则能够找出Java源程序的许多问题，例如：

• 潜在的 Bugs：检查潜在代码错误，如空的 try/catch/finally/switch 语句
• 未使用代码（Dead code）：检查未使用的变量，参数，方法等
• 可选的代码：String/StringBuffer的滥用
• 复杂的表达式：检查没必要要的 if 语句，可被 while 替代的 for 循环
• 重复的代码：检查重复的代码
• 循环体建立新对象：检查在循环体内实例化新对象
• 资源关闭：检查 Connect，Result，Statement 等资源使用以后是否被关闭掉

此外，用户还能够本身定义规则，检查Java代码是否符合某些特定的编码规范。例如，你能够编写一个规则，要求PMD找出全部建立Thread和Socket对象的操做。

三种工具对比

代码缺陷分类	示例	Checkstyle	FindBugs	PMD
引用操做	空指针引用	√	√	√
对象操做	对象比较（使用 == 而不是 equals）		√	√
表达式复杂化	多余的 if 语句			√
未使用变量或代码段	未使用变量		√	√
资源回收	I/O 未关闭		√
方法调用	未使用方法返回值		√
代码设计	空的 try/catch/finally 块			√

由表中能够看出几种工具对于代码检查各有侧重。其中，Checkstyle 更偏重于代码编写格式，及是否符合编码规范的检验， 对代码 bug 的发现功能较弱；而 FindBugs，PMD着重于发现代码缺陷。在对代码缺陷检查中，这三种工具在针对的代码缺陷类别也各有不一样，且类别之间有重叠。

规则定制

考虑到Sonar Java规则已经包含了PMD和CheckStyle规则，所以咱们选择了Sonar的默认规则，并对其进行了定制化。下图中SonarQube中展现了部分定制化规则内容。

定制化后的规则覆盖的代码缺陷类型以下表所示：

代码缺陷分类	示例
引用操做	空指针引用
对象操做	对象比较（使用==而不是equals）
表达式复杂化	对于的if语句
数组使用	数组下标越界
未使用变量或代码段	未使用变量
资源回收	I/O未关闭
方法调用	未使用方法返回值
代码设计	空的try/catch/finally块

总结

本篇介绍了微服务架构架构对测试的挑战，在微服务架构下如何开展测试工做以及在微服务架构下的如何实现静态代码扫描。后续文章将介绍，敬请关注：

• 1. 微服务测试之单元测试
• 2. 微服务测试之契约测试
• 3. 微服务测试之接口测试
• 4. 微服务测试之UI自动化测试
• 5. 微服务测试之探索式测试

本分类文章，与「随行付研究院」微信号文章同步，第一时间接收公众号推送，请关注「随行付研究院」公众号。
复制代码