记一次静态代码扫描实践

背景

产品迭代速度越来越快，每个分支都有各自的业务范围和开发周期需求，QA 无法触及到代码本身的质量,导致暴露的问题越来越多.同时代码微服务架构模式具有服务间独立,可独立开发部署的特点,开发过程中无法对代码本身的质量情况得到反馈,集中测试时才去关注质量，这样一来当出现问题时，大大增加了问题诊断和原因定位的复杂度.

这个背景其实是大多数互联网公司的通用型问题,大家都是为了赶进度往往忽略了代码的质量,有的时候不是开发不想改,是时间成本不允许.往往到了项目后期,改代码的风险是非常的高.文章源自玩技e族-https://www.playezu.com/190840.html

现状

产品迭代节奏的提升，导致功能实现为主时，容易忽视掉代码底层模块间的互相影响，且开发代码改动信息沟通有遗漏时，会出现测试验证覆盖率的缺失，导致没有测试验证改动，直接发布上线的问题，造成不可预估的影响。目前质量验收集中在集成测试阶段，对开发过程质量没有监控，以至于发现问题集中在后期，使发版质量风险越来越大.文章源自玩技e族-https://www.playezu.com/190840.html

在我司技术团队上述这种问题还是发生过的,通常都是开发改了一些底层逻辑,没有评估好影响范围,导致上线后出现线上 bug.文章源自玩技e族-https://www.playezu.com/190840.html

应该怎么改善?

为什么做 (痛点)?

1、现在我们测试团队的测试结构是,业务 + 接口自动化脚本结合测试,但是发现的问题基本上黑盒的,无法从代码层面找出问题,或者说不能深入发现问题.文章源自玩技e族-https://www.playezu.com/190840.html

2、随着业务迭代越来越多,代码行数越来越多.可能会引入重复代码、代码复杂度高、不符合编程规范以及、安全漏洞等问题.文章源自玩技e族-https://www.playezu.com/190840.html

怎么做?

1、应该引入一套代码扫描机制,在测试阶段或者上线前扫描出严重问题并且必须修复严重问题.文章源自玩技e族-https://www.playezu.com/190840.html

2、构建一条自动化流水线,从提交代码 => 扫描代码 => 发送报告.文章源自玩技e族-https://www.playezu.com/190840.html

静态代码扫描初探

静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。代码检查代码检查包括代码走查、桌面检查、代码审查等，主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面；可以发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容文章源自玩技e族-https://www.playezu.com/190840.html

上边提到的重点部分是 “可以发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容”,文章源自玩技e族-https://www.playezu.com/190840.html

优点:

• 1、不需要启动服务,就能扫描代码.
• 2、通过规则自动化扫描代码,坐等报告.
• 3、支持多语言
• 4、人力成本低

缺点

• 1、不能发现代码业务逻辑问题 (需要人工做 codereviews 机制)
• 2、可能会扫描出很多问题,但是后期可以屏蔽一些基本比较低的规则.

工具选型

工具对比

• FindBugs -一个开源的静态分析字节码的 Java (工具比较老,只能输出静态页面)
• IntelliJ IDEA -跨平台的 Java IDE，具有自己的一套几百代码检查可在即时在整个项目的编辑和批量分析分析代码 (还是在 IDE 工具层面)
• SonarQube -对代码质量的持续检查的开源平台。 https://www.sonarqube.org
  

工具很多应该怎么选?

需要一个能持续集成的、可视化展示数据、能扫描的能力强、扫描规则可定制化.文章源自玩技e族-https://www.playezu.com/190840.html

选择 SonarQube 工具

通过一番的技术调研后,我们选择了 SonarQube

• 开源
• 平台化
• 扫描规则较多
• 可持续集成,gitlab + jenkins + SonarQube 结合三个工具做持续集成.

SonarQube 的环境搭建

可以参考这个帖子

https://玩技博客.com/topics/17117

如何落地?

上面讲了那么多都是纯理论,当然不能靠嘴皮子就能把活干了.

静态代码扫描不算是一种新的测试手段了,但是比如我们这种量级的小公司其实很多没有开展,所以需要一个给技术同学的推展过程和接受的过程.

面临的挑战

如何让大家了解和接受?

一个新的 “相当新的测试技术” 如果想搞的话,必须有一个技术调研,而不是拍脑子就去做了.

技术调研

我认为好的技术调研应该是如下几方面:

问题背景

这个简单来说就是解决了什么问题,或者基于什么问题背景.这个往往是最关键的,如果没有很强的背景去支撑很难落地.

解决思路

这块有点考察对事物分析的能力,比如解决问题应该去拆解问题、有一个流程图、并且这个思路经得起推敲.

解决成本

往往理想的丰满的现实是残酷的,解决问题都是有昂贵的人员和时间成本.

所有要做任务拆解,比如第一期花了多长时间、能做什么、解决了什么问题.

Demo 的可行性

一般在调研阶段,必须要去本地搭建一套调研产品,最起码了解清楚可行性有多大

如何落地

真正的落地就是要立项了,时间、人员、排期等

如何验证成果

过程可能对于大佬们往往不关心,成果或者成绩才是大家关心的.

可以定一些指标,例如第一期能发现 xx 个严重问题.

以下是我花了一周左右做的 “静态代码扫描可行性调研”

如何推展到业务中?

有了调研文档就可以约着相关人员开会讨论了,如果第一次推广最好别越所有人.最好找一些项目负责人或者项目小组.

在开会的时候让大家给出一些问题,综合大家意见看看是不是能落地、达成目标一致性.

如何能和迭代挂钩?

找一个比较容易的项目去做,比如项目结构简单、服务架构简单.刚开始做的时候,仅是为了验证这个事 “靠不靠谱”.

当时我们找了一个后端相对比较新的服务、代码都是新写的.我们是在项目提测以后就开始去定期扫描.

使用了 jenkins + gitlab 这种比较简单的方式:

最好别直接给开发扔 SonarQube 的地址,把 bug 提到 bug 管理平台上.

原因有几点:

• 需要手工做一些 bug 筛选
• bug 的统计
• bug 流程监管

如何能做结果验证?

相对来说就是能不能发现一些问题,千万别没有一个结论.

当时我们定的小目标就是,证明静态代码扫描是有可行性的、发现扫描项目不少于 5 个严重问题

另外一个就是项目结束的时候,有一个 bug 统计报告.

技术细节

下面聊一下技术方面的小细节和使用工具的方法.

范围

理想状态下能够覆盖到目前产品技术团队研发的 S1、S2 级服务，扫描的编程语言包括：java(后端)/Android/iOS/Python。从成本考虑，优先选择一到两门编程语言走通流程（Java、OC),后续会推广到整个技术部

SonarQube 针对 java 的语言支持比较好,推荐先去弄后端服务.iOS 在调研的时候发现 SonarQube 的一些 OC 插件,扫描出来的结果偏差很大,所以放到了最后面去搞.

扫描规则

因为 SonarQube 对每一个语言有很多中规则,在每个规则中又有很多种类型.

当时发现如果使用了默认的 java 规则,一个项目项目最起码能扫描出几百的问题,如果把这些问题都提 bug 开发会炸了.

需要精简规则,仅打开 Bugs 等级的规则,每次扫描出来的 “有效” 问题少多了.

大致总结了一下发现 bug 的高频问题:

• 数据库未关闭
• 空指针应该被捕获
• 资源应该被关闭
• 变量命名不规范
• 变量应该用 final 声明
• 代码重复度

扫描分支

可能一个项目会被扫描多个分支,需要在 SonarQube 区分代码分支.

以 maven 项目为例子:

mvn sonar:sonar -Dsonar.branch=xxxx

SonarQube 对应的项目名字后缀的分支名字

报告展示

自带的报告

SonarQube 每次会把最新的数据存在数据库,但是最新的数据会覆盖老数据,不能查看历史数据.

自定义报告

因为不能查看历史数据,所以需要每次扫描完成后,把扫描结果存一份到测试管理平台上,需要有如下几步:

• SonarQube 中添加 webhook

• 保存报告后端接口

这里会用到 SonarQube 的一些 api 接口

• 前端展示报告

测试通知

因为我们公司用的是企业微信沟通,所以每次静态代码扫描完成后都会把结果发到企业微信群中.

扫描策略

扫描的策略大概有几种,目前我们是定时构建触发.

• 监控活跃或者 master 分支,当提交代码的时候出发自动化代码扫.
• 部署服务后出发自动化代码扫描.
• 每天晚上定时自动化代码扫描.
• 上线打包构建自动化代码扫描.

如何修改扫描问题

首先要和开发确认定义清楚哪些问题是必须改的.
例如 Bugs 中的阻断和严重的必须上线前修改

小结

静态代码扫描是相当长的测试周期、并且覆盖项目的范围比较广.

如果一个公司像尝试去做这方面,最好有一个架构涉及或者清晰的调研结果.

和自动化构建工具结合的时候,尽量使用开源的、或者公司内部的自动部署平台.

在人员投入上,最好能有一个专职的人去做,并且有一定的代码基础.

参考

1、阿里巴巴 java 编程规范
https://alitech-private.oss-cn-beijing.aliyuncs.com/1528269849853/Java_manual.pdf?Expires=1584004146&OSSAccessKeyId=LTAIqKGWQyF6Vd3W&Signature=xZ0QYCJoTpGutc7xMYmYIK4S/HE%3D

2、让所有代码都经过检查
https://cloud.tencent.com/developer/article/1371896ssd测试软件