Qtest测试之道 静态代码扫描在 360 无线项目中的实践

360Qtest团队 · November 09, 2018 · 1021 hits

前言

其实接到这个任务的时候,我内心是拒绝的,因为据我了解,各种静态代码扫描工具出来已经很长时间了,然而在各大公司推行的情况,相信各位略有耳闻,效果甚微。前阵子我看到google上有篇论文,叫《Why Don’t Software Developers Use Static Analysis Tools to Find Bugs?》,我深以为然!结合目前手头推进的经历,以及业务方的各种反馈来看,现实很残酷。但是既然决定做这事了,还是希望能改变这种现状,和testerhome的一些牛人讨论过这个话题,非常感谢给我建议的那几位大牛,给了我继续推进这件事的勇气😅 😅

-- 感谢何正老师为我们打下的基础

导读

  • 火线的诞生
  • 现有静态扫描工具有哪些?
  • 用户的真实需求和痛点
  • 火线如何与众不同?
  • 火线推广中遇到的困难
  • 火线存在哪些不足

火线的诞生

关注互联网的人也许看到过下面这段代码,当时引起了轩然大波。

事情原由我就不赘述了,我们最初的目的就是从根本上避免这种事在我们这里发生,于是在公司大老板和技术委员会的推动下,出现了一个叫安卓代码红线的工具,也就是火线的前身。

安卓代码红线出现的目的就是杜绝一些明显违反公司规定,或者违反安全类规范的代码内容,希望通过静态代码分析来解决这个问题。前期定下的规则已经大部分实现了(实际上也没几条规则),随着工作的推进,我们发现其实我们可以做更多的事情,于是在安卓代码红线的基础上做了不少扩展,演变成了如今的“火线”平台。

火线简介

  • 应用场景:静态代码扫描
  • 前 身:安卓代码红线
  • 扫描引擎:基于PMD开源
  • 扫描方式:命令行、GUI、在线扫描
  • 目 标:精确、聚焦、好用、极速

现有静态扫描工具有哪些?

我们针对市面上用的比较多的几个工具进行了分析,大概情况如下(不正确的地方还请指出,谢谢):
(原谅我用图片代替,markdown表格内换行实在是不会。。。)

上面几种工具的侧重点分别是不同的,从开发的反馈来看,他们用的比较多的是findbugs这个工具,这几款工具的比较相信表格里面已经写的很清楚了,在此不一一讲解。

用户的真实需求和痛点

经过一段时间的调研,我们总结了一些客户的痛点和需求反馈如下:

  • 痛点
    • 假设性问题远远多余实际问题
    • 大型项目扫描的问题数量令人发指
    • 规则无法自定义和扩展,或暂时忽略
    • 环境难安装、配置麻烦、需要上传源代码
    • 结果可读性太差,要么看不懂,要么不知道问题出在哪儿
    • 只能告诉我这里有问题,不能告诉我怎么修改
  • 需求
    • 快速梳理问题,区分优先级
    • 设置好的规则能够在团队内共享
    • 提供数据存储,历史问题跟踪,可评论
    • 提供修复指南,最好能自动修复问题
    • 容易集成到开发环境,比如持续集成,IDE等,结果实时展示
    • 有纠错和白名单功能,业务特殊需求

火线如何与众不同?

结合上面调研的几种工具,以及火线项目在扫描实际代码的时候总结的一些反馈,我们做了如下实验,新建一个安卓工程,在代码中预留了一些待检测问题,然后分别用不同的工具来扫描,查看结果的命中率,结果大概是这样的:

命中率比较

每个工具的检测结果是不一样的,实际上这个实验也不够严谨,因为findbugs和lint分别有各自的侧重点和优势,每个工具的特征也比较明显。其中Findbugs报了不少"*** doesn't start with an upper case letter"这样的错误,而PMD似乎对R.java很感兴趣,一下子报了7000多个问题(大部分是R.java报错),当然规则是可以删减的,我们扫描的时候为了确保完整性没有对规则进行精简。
现在比较流行的SonarQube平台就将几种工具集成到一个平台上统一管理和输出,但是在定制化方面较为复杂,规则扩展性和跨平台也不方便,有需求的同学可以去看看这个平台。

报告比较

  • Findbugs

  • Lint

  • PMD

  • 火线


相信通过上面的图片比较,各位应该能看出来我们大致做了哪些事情,我们结合前面提到的痛点和需求来具体看看:

火线在实际项目中的数据(截止4月1日数据,部分公司数据不做展示)

数据指标 本周数据
累计运行天数 115天
累计扫描次数 5158次
覆盖项目及任务 260个
扫描代码总行数 81,214,988行
扫描文件总数 215173个
平均项目扫描时间 38.95秒
千行扫描时间 0.469秒

此为4月1日为止的累计数据,覆盖项目及任务可能存在一个项目多个版本代码的情况

火线已经扫描的项目

常见的问题分布

火线推广中遇到的困难

相信大家在公司内部推广工具或者平台的时候,都会遇到各种困难和阻力,我们也不例外。下面是我们遇到的一部分问题(实际上与人打交道是很困难的)

火线之所以能够获取如此多的珍贵数据样本,其实还是取决于公司流程的保障,正如开头所提到的,有大老板和技术委员会引荐,推动起来会相对容易一些,但是好的产品上是真心能帮人解决问题的,而不是借助于“尚方宝剑”来强行推动,站在用户的角度上去帮他们解决问题,才是我们的动力。不过光靠自觉也是干不成事情的,还需要借助公司流程来推行。

公司大流程给我们提供了巨大的帮助:

  • 纳入安全审核流程
  • 接入代码审计流程
  • 提供在线自测平台(我们是没权限获取源代码的)
  • 火线的测试报告作为发布申请的依据
  • 针对业务进行加白和纠错
  • 审计人员做特批处理

目前流程还有待磨合及完善,相信会逐渐产生积极的影响。

火线存在哪些不足

虽然火线借助于公司的流程做了一些工作,但是还远远没有成熟,并且存在的问题也很多,互联网公司的快速迭代开发,让很多细节不再去追溯,很多问题都被忽略,还有一些特殊需求被加入,让代码检测不确定因素越积越多,代码可测性要低于可用性。但是本文并不是讨论如何编写优质的代码,或者如何推动编码规范的,因此在这里就不多吐槽了。

火线目前已经拿到了数百万的缺陷代码样本,能做的事情还很多,目前也存在比较显著的缺点,是我们后面想解决的:

  1. 满足更多业务痛点,空指针、多线程、定制规则实现
  2. 更多安全SDL规则的实现
  3. 持续优化,精减无效规则,降低误报率

由于产品现在还不成熟,等足够完善的时候,可以开源出来给各位同行使用,也能帮助产品加速完善和成型。所以目前暂时还不能开源,抱歉哈。。。

No Reply at the moment.
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up