背景

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

这个背景其实是大多数互联网公司的通用型问题,大家都是为了赶进度往往忽略了代码的质量,有的时候不是开发不想改,是时间成本不允许.往往到了项目后期,改代码的风险是非常的高.

现状

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

在我司技术团队上述这种问题还是发生过的,通常都是开发改了一些底层逻辑,没有评估好影响范围,导致上线后出现线上 bug.

应该怎么改善?

为什么做 (痛点)?

1、现在我们测试团队的测试结构是,业务 + 接口自动化脚本结合测试,但是发现的问题基本上黑盒的,无法从代码层面找出问题,或者说不能深入发现问题.

2、随着业务迭代越来越多,代码行数越来越多.可能会引入重复代码、代码复杂度高、不符合编程规范以及、安全漏洞等问题.

怎么做?

1、应该引入一套代码扫描机制,在测试阶段或者上线前扫描出严重问题并且必须修复严重问题.

2、构建一条自动化流水线,从提交代码 => 扫描代码 => 发送报告.

静态代码扫描初探

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

上边提到的重点部分是 “可以发现违背程序编写标准的问题,程序中不安全、不明确和模糊的部分,找出程序中不可移植部分、违背程序编程风格的问题,包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容”,

优点:

缺点

工具选型

工具对比

工具很多应该怎么选?

需要一个能持续集成的、可视化展示数据、能扫描的能力强、扫描规则可定制化.

选择 SonarQube 工具

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

SonarQube 的环境搭建

可以参考这个帖子

https://testerhome.com/topics/17117

如何落地?

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

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

面临的挑战

如何让大家了解和接受?

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

技术调研

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

问题背景

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

解决思路

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

解决成本

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

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

Demo 的可行性

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

如何落地

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

如何验证成果

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

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

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

image

image

image

如何推展到业务中?

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

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

如何能和迭代挂钩?

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

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

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

image

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

image

原因有几点:

image

如何能做结果验证?

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

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

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

image

image

技术细节

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

范围

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

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

扫描规则

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

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

image

image

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

image

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

扫描分支

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

以 maven 项目为例子:

mvn sonar:sonar -Dsonar.branch=xxxx

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

image

报告展示

自带的报告

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

image

自定义报告

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

image

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

image

image

测试通知

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

image

扫描策略

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

如何修改扫描问题

首先要和开发确认定义清楚哪些问题是必须改的.
例如 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/1371896


↙↙↙阅读原文可查看相关链接,并与作者交流