精华内容
下载资源
问答
  • 通过Shell命令调用api获取sonarQube中代码静态扫描结果中的bug数据 问题由来 公司质量管理部制定了一个临时的静态代码扫描通过标准,就是要求静态代码扫描结果中BLOCKER, CRITICAL, MAJOR级别的bug数为0即可。 ...

    通过Shell命令调用api获取sonarQube中代码静态扫描结果中的bug数据

    问题由来

    公司质量管理部制定了一个临时的静态代码扫描通过标准,就是要求静态代码扫描结果中BLOCKER, CRITICAL, MAJOR级别的bug数为0即可。 因为评价标准特殊,不能直接使用jenkins的插件sonar-quality-gates-plugin来直接判定job的失败,原因是SonarQube中质量标准无法配置出来上面三个bug类型。 所以只能通过api调用来获取上述数据。

    解决方案

    调用下面的api接口获取扫描结果中的BLOCKER,CRITICAL,MAJOR级别的bug数量。

    -u:参数后面跟的是sonarQube访问的token;

    curl -u 280f41fec8336367e189a79e9aeb077a1497130a "http://localhost:9000/api/issues/search?componentKeys=${projectKey}&types=BUG&severities=BLOCKER,CRITICAL,MAJOR&resolved=false" | tee report.json
    

    获取到数据后,将数据输入到report.json文件中,下面还需要写个简单的脚本解析这个report来获取我们希望的数据。方便起见,就用python了:

    cat parseScanReport.py
    #!/usr/bin/python
    import json
    
    with open('report.json', 'r') as f:
            data = json.load(f)
    
    print data['total']
    

    然后在shell中直接调用上面的脚本获取数据,并标记job的成功和失败:

    totalBugNo=`python parseScanReport.py`
    if [ $totalBugNo > 0 ]; then
        echo "BLOCKER&CRITICAL&MAJOR bug number is: $totalBugNo"
        exit -1
    fi
    

    记录之。

    展开全文
  • 无论您在开发组织中发挥的作用如何,静态代码扫描解决方案都具有附加价值,拥有软件开发中所需要的尖端功能,最大限度地提高质量并管理软件产品中的风险。 背景 微服务架构模式具有服务间独立,可独立开发部署等特点...
        
    静态代码扫描为整个发展组织增加价值。无论您在开发组织中发挥的作用如何,静态代码扫描解决方案都具有附加价值,拥有软件开发中所需要的尖端功能,最大限度地提高质量并管理软件产品中的风险。

    背景

    微服务架构模式具有服务间独立,可独立开发部署等特点,独立开发诱发了技术上的分离,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将分析的结果以可视化、可度量的方式展示给出来。逻辑结构如下图所示:

    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 更偏重于代码编写格式,及是否符合编码规范的检验, 对代码 bug 的发现功能较弱;而 FindBugs,PMD着重于发现代码缺陷。在对代码缺陷检查中,这三种工具在针对的代码缺陷类别也各有不同,且类别之间有重叠。

    规则定制

    考虑到Sonar Java规则已经包含了PMD和CheckStyle规则,因此我们选择了Sonar的默认规则,并对其进行了定制化。下图中SonarQube中展示了部分定制化规则内容。

    定制化后的规则覆盖的代码缺陷类型如下表所示(部分规则):

    代码缺陷分类 示例
    引用操作 空指针引用
    对象操作 对象比较(使用==而不是equals)
    表达式复杂化 对于的if语句
    数组使用 数组下标越界
    未使用变量或代码段 未使用变量
    资源回收 I/O未关闭
    方法调用 未使用方法返回值
    代码设计 空的try/catch/finally块
    展开全文
  • 无论您在开发组织中发挥的作用如何,静态代码扫描解决方案都具有附加价值,拥有软件开发中所需要的尖端功能,最大限度地提高质量并管理软件产品中的风险。 背景 微服务架构模式具有服务间独立,可独立开发部署等特点...

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

    背景

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

    微服务架构对测试的挑战

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

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

      1. 微服务系统模块层次化,需要保证模块内部代码的质量。这种场景下传统的端到端的测试无法满足测试要求;
      1. 需要保证各个微服务系统内部模块间的正确性。系统模块间以及前端和后端通常会同时开展开发工作,模块间或者前后端通过接口(通常是Restful http接口)进行连接,而模块和后端往往没有界面,为了保证各个系统单个依赖系统的正确性,因此需要借助Mock技术隔离依赖的前提下进行接口级的测试;
      1. 需要保证微服务系统中的接口一致性,即契约的一致性。需要通过契约测试手段保证契约的正确性,进而保证同步开发过程中的前后开发的正确性和一致性;
      1. 需要保障单个微服务系统的正确性。需要进行组件级的测试进行微服务系统的正确性;
      1. 需要保障整个系统的正确性。各个微服务系统串接之后通过端到端的测试保证整体系统的正确性;

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

    针对上面提到的微服务对测试的挑战,一方面为了保证在服务各个层级上对微服务进行全面的测试,特别是对于分布式系统;另一方面又要确保测试执行的效率,这样才能保证持续集成/持续交付(CI/CD)。因此,总体的测试策略采用如下解决方法:

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

      1. 采用流水线技术进行可视化快速反馈。由于微服务系统非常多,这样往往会增加了运维和沟通成本,为了提高沟通效率,需要借助流水线的技术,可视化查看每一个构建(Build)、测试(Test)、部署(Deploy)过程,快速做出质量反馈和处理决策。通过可视化流水线最终可以实现各个环节的监控,采用DevOps手段打通业务、开发、测试和运维的部门墙。

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

    静态代码扫描

    静态代码扫描背景

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

    静态代码扫描意义

    为开发者

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

    为DevOps

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

    为管理者

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

    静态代码扫描介绍

    静态代码扫描处在特性分支开发完成之后,具体的描述如下:

      1. 开发人员从Master分支拉取特性分支作为开发分支;
      1. 开发完特性分支后、代码构建、单元测试、静态代码扫描;
      1. 通过后合并到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. 微服务测试之单元测试
      1. 微服务测试之契约测试
      1. 微服务测试之接口测试
      1. 微服务测试之UI自动化测试
      1. 微服务测试之探索式测试

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

    展开全文
  • 无论您在开发组织中发挥的作用如何,静态代码扫描解决方案都具有附加价值,拥有软件开发中所需要的尖端功能,最大限度地提高质量并管理软件产品中的风险。背景微服务架构模式具有服务间独立,可独立开发部署等特点,...
    静态代码扫描为整个发展组织增加价值。无论您在开发组织中发挥的作用如何,静态代码扫描解决方案都具有附加价值,拥有软件开发中所需要的尖端功能,最大限度地提高质量并管理软件产品中的风险。

    背景

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

    “微服务架构对测试的挑战

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

    480a04a2ebb36b72378a949a29475889.png

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

    • 1. 微服务系统模块层次化,需要保证模块内部代码的质量。这种场景下传统的端到端的测试无法满足测试要求;
    • 2. 需要保证各个微服务系统内部模块间的正确性。系统模块间以及前端和后端通常会同时开展开发工作,模块间或者前后端通过接口(通常是Restful http接口)进行连接,而模块和后端往往没有界面,为了保证各个系统单个依赖系统的正确性,因此需要借助Mock技术隔离依赖的前提下进行接口级的测试;
    • 3. 需要保证微服务系统中的接口一致性,即契约的一致性。需要通过契约测试手段保证契约的正确性,进而保证同步开发过程中的前后开发的正确性和一致性;
    • 4. 需要保障单个微服务系统的正确性。需要进行组件级的测试进行微服务系统的正确性;
    • 5. 需要保障整个系统的正确性。各个微服务系统串接之后通过端到端的测试保证整体系统的正确性;

    8385e4e8b1d1b38ffdf020c114ab1c09.png

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

    针对上面提到的微服务对测试的挑战,一方面为了保证在服务各个层级上对微服务进行全面的测试,特别是对于分布式系统;另一方面又要确保测试执行的效率,这样才能保证持续集成/持续交付(CI/CD)。因此,总体的测试策略采用如下解决方法:

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

    f971934167aa86fb4e7c365ff9e3a901.png
    • 4. 采用流水线技术进行可视化快速反馈。由于微服务系统非常多,这样往往会增加了运维和沟通成本,为了提高沟通效率,需要借助流水线的技术,可视化查看每一个构建(Build)、测试(Test)、部署(Deploy)过程,快速做出质量反馈和处理决策。通过可视化流水线最终可以实现各个环节的监控,采用DevOps手段打通业务、开发、测试和运维的部门墙。

    43963beca61dbeb4a7bba98dc33075c0.png

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

    静态代码扫描

    “静态代码扫描背景

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

    “静态代码扫描意义

    为开发者

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

    为DevOps

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

    为管理者

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

    “静态代码扫描介绍

    静态代码扫描处在特性分支开发完成之后,具体的描述如下:

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

    62e27d0de5089ffc6b42ea64c221fb41.png

    “静态代码扫描流程

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

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

    15ff8dff7a8d33125267844cc5af3ab5.png

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

    6f7f7cd08187e0978a09c17e3c3448db.png
    • 3.SonarQube平台根据质量阀的要求,不满足质量阀要求则邮件通知开发人员。
    质量阀要求:
        1.新覆盖率大于等于80%;
        2.新增Bugs为0;
        3.新增漏洞为0;
        4.新增坏味道为0;

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

    5b1aecbc9e3e6f0d7d86699bde49dfab.png

    SonarQube与规则

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

    2bcb65a883bc404747e1fc18992ca22a.png

    “SonarQube的整合能力

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

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

    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对象的操作。

    三种工具对比

    ca99b3b43ad43722bcfd09e8b8e761f4.png

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

    “规则定制

    考虑到Sonar Java规则已经包含了PMD和CheckStyle规则,因此我们选择了Sonar的默认规则,并对其进行了定制化。下图中SonarQube中展示了部分定制化规则内容。

    fd320a4202400d3e314716bbcc35a125.png

    定制化后的规则覆盖的代码缺陷类型如下表所示(部分规则):

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

    总结

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

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

    作者简介

    王田,随行付架构部测试架构师。负责测试方法论布道、自动化测试工具研究与推广。

    展开全文
  • 芸墨(龚能)在2018云栖大会·南京峰会中做了题为《静态代码扫描体系在阿里移动研发的应用》的分享,就手机淘宝研发支撑体系的演进、手淘现状和挑战、阿里巴巴移动静态代码扫描体系、EMAS持续交付解决方案等方面的...
  • 少漏报和误报率低的工具是我们的首选,我最近试用了许多源代码扫描工具和方案,其中DMSCA(端玛科技企业级源代码安全和质量缺陷扫描分析服务平台),我发现扫描效果很不错,是一款最能解决软件安全问题的工具,下面...
  • infer静态代码扫描不能执行问题定位

    千次阅读 2016-01-26 13:16:18
    什么是inferfacebook推出的静态代码检测工具,可以检测android和IOS应用的内存泄露和空指针问题。...Failed to run InferAnalyze binary, exiting解决过程Google解决方案大部分反馈结果如下:About the
  • 摘要:本文由淘宝技术部高级无线开发工程师详细剖析了手机淘宝的现状及挑战。针对手淘问题发现被动、...阿里将其应用于EMAS持续交付解决方案中,用数据说明实力! 本次直播视频精彩回顾,戳这里! 演讲嘉宾简介:...
  • 构建高质量的C#代码 完整扫描

    热门讨论 2014-06-04 12:24:48
    18.2.2 解决方案 18.2.3 应用特点 第19章 工厂方法模式 19.1 虚拟战争游戏示例:控制作战单位的创建 19.1.1 收起自由创建单位的权力 19.1.2 控制作战单位类型 19.1.3 统一作战单位的创建方法 19.2 应用分析 19.2.1 ...
  • 前段时间因为工作原因需要对java源代码进行扫描,现结合使用经验对静态代码扫描工具Fortify SCA与FindBugs进行一个简单的对比。 一、Fortify SCA Fortify SCA是由全球领先的软件安全产品解决方案供应商Fortify ...
  • 在SAP中可以对主数据或者单据附加文档或网络地址以查询其对应详细信息。实现技术方式有如下几... GOS只能存放扫描图像和静态文件,对于版本管理的技术文档不适合。2. GOS安全性无法保证。3. GOS无分发文档功能。4. ...
  • Android平台阿里云安全解决方案总结

    万次阅读 2018-02-14 09:53:29
    Android平台阿里云安全解决方案总结 阿里聚安全目前提供了安全扫描、安全组件、应用加固、安全审计、安全测试工具五种方案。 一、安全扫描 将APP提交到阿里服务器上,然后由阿里服务器进行安全扫描发现恶意代码、...
  • 基于webpack搭建纯静态页面型前端工程解决方案模板 按需加载模块,按需进行懒加载,在实际用到某些模块的时候再增量更新 多入口文件,自动扫描入口。同时支持SPA和多页面型的项目 静态资源按需自动注入到html中,...
  • 1.一般我们用草料生成二维码,如果没有注册的话只能生成一个包含下载网址的静态码,没有统计功能,而且除了自己截图保存外,草料是不会保存你的二维码的。 如果注册草料后,可以选择生成活码。所谓活码,就是一个...
  • Parallel Helper是用于C#项目的静态代码分析器,支持并行和异步代码的开发。 该分析器是在的帮助下构建的,可以作为以及。 入门 成功安装Parallel Helper之后,它将自动扫描当前打开的文件。 Visual Studio扩展 ...
  • 背景 启动是App给用户的第一印象,对用户体验至关重要。抖音的业务迭代迅速,如果放任不管,启动速度会一点点劣...本文从原理出发,介绍了我们是如何通过静态扫描和运行时trace找到启动时候调用的函数,然后修改编...
  • 本文从原理出发,介绍了我们是如何通过静态扫描和运行时trace找到启动时候调用的函数,然后修改编译参数完成二进制文件的重新排布。 原理 Page Fault 进程如果能直接访问物理内存无疑是很不安.

空空如也

空空如也

1 2 3 4 5
收藏数 86
精华内容 34
关键字:

代码静态扫描解决方案