Coverity 相比于传统的测试方式,会更容易发现类似 空指针引用、资源泄漏和缓冲区溢出 的异常,在开发阶段使用 Coverity 一方面可以更加保证产品的质量,另一个方面也可以使测试人员把更多的精力放在业务逻辑的测试上而不是花大量精力去确认一些需要在特殊条件下才可能出现的 bug,进而提高测试的效率。本文并不介绍 Coverity 的具体安装和部署,专注于具体项目的代码扫描检测过程。
一、实践场景描述
纯净的设备环境下,去扫描 Android 工程,并将结果上传到 Coverity 后台,因此需要配置 Android 的编译环境和相关的 SDK。另外本篇实践过程是基于 Ubuntu 系统。
二、实施过程
2.1 Gradle 配置
方式一: 手动下载
1、在 Gradle官网 下载相应版本的 Gradle 二进制执行文件,之后操作如下:
$ mkdir /opt/gradle |
2、配置 shell 路径
在 /etc/profile 中追加如下内容:
export PATH=/home/zsk/opt/gradle/gradle-5.6.4/bin:$PATH |
3、验证配置结果
$ gradle -v |
方式二:gradlew自动配置
在项目根目录下直接执行 ./gradlew -v 就可以直接下载项目中配置的 Gradle 版本,这样在下面的分析脚本中就需要将 gradle 改换为 gradlew
2.2 SDK配置
SDK 可以通过 网站 下载需要的版本,当然也可以从其他已经下载好的设备中拷贝一份
2.3 项目修改
1、local.properties 中 SDK 的路径必须和 2.2 中的存放路径相同
2、最好修改 .gradle 文件中的仓库,改为对应的镜像地址,避免在编译过程中相关的库文件无法下载,这里我用的是阿里云的地址:
allprojects { |
2.4 执行命令
1、配置环境
cov-configure –java
用于配置 Coverity 扫描器的环境。它允许用户设置扫描器的配置选项,比如指定编译命令、定义预处理命令等
2、使用 Gradle 开始编译任务
cov-build –dir result gradle clean build
result:编译结果存放的文件夹名字
gradle:使用 gradle 来构建编译
clean:清除当前缓存任务
build:编译任务
运行结果如下:

3、扫描分析
cov-analyze –dir result –all
result:编译结果存放的文件夹名字,表示从这个文件中读取编译内容进行分析可以指定 分析的bug等级
可以筛选 bug 等级:
后跟 –aggressiveness-level high
例如:
cov-analyze –dir result –all –aggressiveness-level high
运行结果如下:

4、提交扫描结果
cov-commit-defects –stream tp_logger_v_1.0 –host 10.212.xxx.xxx –port 8081 –user zsk –password zskqq123 –dir result
stream:提交的流为 tp_logger_v_1.0,相当于分支
host:id 地址,例如 10.212.xxx.xxx
port:端口号,例如 8081
user:coverity 登录的用户名,例如 zsk
password:coverity 登录密码,例如zskqq123
result:分析结果存放的目录
运行成功之后即可在 Coverity 平台上看到此次提交内容
运行结果如下:

Coverity 平台上传结果:

5、注意事项
使用 Coverity 扫描其他类型的项目时比如 C 项目,需要使用 cov-configure 命令指定编译的工具,但是在扫描 Android 工程时,似乎并不需要,这点需要再做考究。
Linux example: |