产品迭代速度越来越快，每个分支都有各自的业务范围和开发周期需求，QA 无法触及到代码本身的质量,导致暴露的问题越来越多.同时代码微服务架构模式具有服务间独立,可独立开发部署的特点,开发过程中无法对代码本身的质量情况得到反馈,集中测试时才去关注质量，这样一来当出现问题时，大大增加了问题诊断和原因定位的复杂度.
这个背景其实是大多数互联网公司的通用型问题,大家都是为了赶进度往往忽略了代码的质量,有的时候不是开发不想改,是时间成本不允许.往往到了项目后期,改代码的风险是非常的高.
产品迭代节奏的提升，导致功能实现为主时，容易忽视掉代码底层模块间的互相影响，且开发代码改动信息沟通有遗漏时，会出现测试验证覆盖率的缺失，导致没有测试验证改动，直接发布上线的问题，造成不可预估的影响。目前质量验收集中在集成测试阶段，对开发过程质量没有监控，以至于发现问题集中在后期，使发版质量风险越来越大.
在我司技术团队上述这种问题还是发生过的,通常都是开发改了一些底层逻辑,没有评估好影响范围,导致上线后出现线上 bug.
1、现在我们测试团队的测试结构是,业务 + 接口自动化脚本结合测试,但是发现的问题基本上黑盒的,无法从代码层面找出问题,或者说不能深入发现问题.
2、随着业务迭代越来越多,代码行数越来越多.可能会引入重复代码、代码复杂度高、不符合编程规范以及、安全漏洞等问题.
1、应该引入一套代码扫描机制,在测试阶段或者上线前扫描出严重问题并且必须修复严重问题.
2、构建一条自动化流水线,从提交代码 => 扫描代码 => 发送报告.
静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。代码检查代码检查包括代码走查、桌面检查、代码审查等，主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面；可以发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容
上边提到的重点部分是 “可以发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容”,
需要一个能持续集成的、可视化展示数据、能扫描的能力强、扫描规则可定制化.
通过一番的技术调研后,我们选择了 SonarQube
可以参考这个帖子
https://testerhome.com/topics/17117
上面讲了那么多都是纯理论,当然不能靠嘴皮子就能把活干了.
静态代码扫描不算是一种新的测试手段了,但是比如我们这种量级的小公司其实很多没有开展,所以需要一个给技术同学的推展过程和接受的过程.
如何让大家了解和接受?
一个新的 “相当新的测试技术” 如果想搞的话,必须有一个技术调研,而不是拍脑子就去做了.
我认为好的技术调研应该是如下几方面:
这个简单来说就是解决了什么问题,或者基于什么问题背景.这个往往是最关键的,如果没有很强的背景去支撑很难落地.
这块有点考察对事物分析的能力,比如解决问题应该去拆解问题、有一个流程图、并且这个思路经得起推敲.
往往理想的丰满的现实是残酷的,解决问题都是有昂贵的人员和时间成本.
所有要做任务拆解,比如第一期花了多长时间、能做什么、解决了什么问题.
一般在调研阶段,必须要去本地搭建一套调研产品,最起码了解清楚可行性有多大
真正的落地就是要立项了,时间、人员、排期等
过程可能对于大佬们往往不关心,成果或者成绩才是大家关心的.
可以定一些指标,例如第一期能发现 xx 个严重问题.
以下是我花了一周左右做的 “静态代码扫描可行性调研”
有了调研文档就可以约着相关人员开会讨论了,如果第一次推广最好别越所有人.最好找一些项目负责人或者项目小组.
在开会的时候让大家给出一些问题,综合大家意见看看是不是能落地、达成目标一致性.
找一个比较容易的项目去做,比如项目结构简单、服务架构简单.刚开始做的时候,仅是为了验证这个事 “靠不靠谱”.
当时我们找了一个后端相对比较新的服务、代码都是新写的.我们是在项目提测以后就开始去定期扫描.
使用了 jenkins + gitlab 这种比较简单的方式:
最好别直接给开发扔 SonarQube 的地址,把 bug 提到 bug 管理平台上.
原因有几点:
相对来说就是能不能发现一些问题,千万别没有一个结论.
当时我们定的小目标就是,证明静态代码扫描是有可行性的、发现扫描项目不少于 5 个严重问题
另外一个就是项目结束的时候,有一个 bug 统计报告.
下面聊一下技术方面的小细节和使用工具的方法.
理想状态下能够覆盖到目前产品技术团队研发的 S1、S2 级服务，扫描的编程语言包括：java(后端)/Android/iOS/Python。从成本考虑，优先选择一到两门编程语言走通流程（Java、OC),后续会推广到整个技术部
SonarQube 针对 java 的语言支持比较好,推荐先去弄后端服务.iOS 在调研的时候发现 SonarQube 的一些 OC 插件,扫描出来的结果偏差很大,所以放到了最后面去搞.
因为 SonarQube 对每一个语言有很多中规则,在每个规则中又有很多种类型.
当时发现如果使用了默认的 java 规则,一个项目项目最起码能扫描出几百的问题,如果把这些问题都提 bug 开发会炸了.
需要精简规则,仅打开 Bugs 等级的规则,每次扫描出来的 “有效” 问题少多了.
大致总结了一下发现 bug 的高频问题:
可能一个项目会被扫描多个分支,需要在 SonarQube 区分代码分支.
以 maven 项目为例子:
mvn sonar:sonar -Dsonar.branch=xxxx
SonarQube 对应的项目名字后缀的分支名字
SonarQube 每次会把最新的数据存在数据库,但是最新的数据会覆盖老数据,不能查看历史数据.
因为不能查看历史数据,所以需要每次扫描完成后,把扫描结果存一份到测试管理平台上,需要有如下几步:
这里会用到 SonarQube 的一些 api 接口
因为我们公司用的是企业微信沟通,所以每次静态代码扫描完成后都会把结果发到企业微信群中.
扫描的策略大概有几种,目前我们是定时构建触发.
首先要和开发确认定义清楚哪些问题是必须改的.
例如 Bugs 中的阻断和严重的必须上线前修改
静态代码扫描是相当长的测试周期、并且覆盖项目的范围比较广.
如果一个公司像尝试去做这方面,最好有一个架构涉及或者清晰的调研结果.
和自动化构建工具结合的时候,尽量使用开源的、或者公司内部的自动部署平台.
在人员投入上,最好能有一个专职的人去做,并且有一定的代码基础.
2、让所有代码都经过检查
https://cloud.tencent.com/developer/article/1371896
