原创 进击！Helix QAC自动化静态测试

当一位有追求的测试(开发)工程师，每天面对枯燥且单调的静态测试工作时，他一定会有将静态代码测试变为自动化执行的冲动。然而当真正去实施自动化静态测试平台的构建时，我们往往因为无从下手或实施艰难而选择放弃。本文将以静态代码测试工具Helix QAC+版本管理工具SVN+持续集成工具Jenkins为例，向你介绍基于Helix QAC的自动化静态分析方案。通过本文，你将了解该方案的具体实施步骤，以及该方案可以实现的具体效果。如果你之前从未接触过Jenkins，看完本文后，你将对Jenkins的功能有一个大致的了解，同时你也可以根据自身的实际情况，构建自己的自动化静态测试流水线，让你彻底从枯燥且单调的静态测试工作中解脱。

自动化静态分析对静态分析工具有什么要求？

为了实现自动化静态分析，静态分析工具需要满足一下几点要求：

可以通过命令行实现静态分析工具的大部分功能；

可以脱离静态分析工具查看分析结果；

可以支持并行分析；

下面介绍一下本文自动化静态分析方案所使用的静态分析工具——Helix QAC。

Helix QAC是什么？

Helix QAC(以下简称QAC)是嵌入式静态分析领域公认的行业领导及先驱，是MISRA C&C++编码委员会的创始会员，是AUTOSAR工作组会员，是商业自动化分析解决方案的先驱，提供丰富的可选规范包：MISRA、AUTOSAR、CERT、CWE、HICPP等，

通过了不同行业的功能安全认证：ISO 26262、IEC 62304、IEC 60880、DO-178B等。

QAC提供丰富的command line 命令，几乎所有的功能都可以通过命令行实现，为自动化静态分析方案提供了无限的想象空间。

QAC软件还提供一个基于WEB的项目管理平台——Dashboard，我们可以将QAC工程的分析结果上传到该平台上，在Dashboard上可以查看工程详细的分析结果、同一个工程不同版本之间的质量变化趋势、不同版本之间代码的变更情况等。鉴于Dashboard强大的项目管理功能，本文将Dashboard集成到自动化静态分析方案。

QAC软件有完善的并行分析功能，QAC不仅支持对一个工程的多核并行分析，同时也支持在同一台电脑上，多个QAC工程的并行分析。这不仅大大提升了QAC的分析效率，也使得基于QAC的自动化静态分析平台可以满足更大规模的开发团队。

图1.Dashboard预览界面

为什么要做自动化静态分析？

首先看一下基于QAC的传统静态分析模式存在哪些问题：

开发人员无法快速查看分析结果。

如果项目规模很大，开发人员很多，没有QAClicense的人员需要将工程传递给指定的测试（开发）人员进行分析，无法快速地获取分析结果，以验证代码编写或修改是否满足要求。

测试人员工作量大。

由于需要固定的人员进行静态分析，测试人员需要对收到的源码建立QAC工程、分析、生成报告并将分析结果上传到服务器端的Dashboard，工作繁琐且单调。

难以在开发过程中实现持续测试。

由于开发工程往往进度催的很紧，而进行代码的静态测试又需要将代码提交给测试人员，等得到测试结果时，可能开发人员的进度已经进入到下一个阶段了，之前的测试结果已经过时了，这就会导致开发人员对静态测试不积极，将静态测试向开发的后期推。

难以实现Dashboard工程和开发人员的双向追溯。

当每个源码工程都经过多次迭代，且在迭代过程中需要将源码工程以不同的版本上传到Dashboard中时，测试人员精确上传分析结果的工作难度，无疑会随开发人员和开发工程数量的增加而呈指数倍增长。

当然，上述问题在自动化静态分析测试中都不是问题。

自动化静态分析该从何开始？

自动化静态分析平台的搭建，首先要有用于驱动测试工具进行测试的脚本。因此建议从脚本的编写开始入手，QAC的静态测试脚本应具备以下四个功能：

为源码建立QAC工程；

执行分析并生成分析报告；

获取SVN提交者用户名及源码当前SVN版本；

将分析结果上传到Dashboard（工程版本号由SVN用户名和SVN版本确定）。

上述功能中，3的难度相对而言最高。因此根据先实现后改进的原则，首先完成1、2、4脚本的编写。

幸运的是，QAC提供了丰富的command line命令，你可以轻松地实现上述三个功能：

QAC可以通过rebuild工程的方式，为QAC工程加载build过程中调用的源文件和头文件甚至宏定义，这使你无需编写脚本搜索文件里的源文件和头文件；

QAC工程的分析和报告的生成都有对应的命令，我们可以方便地实现这些功能；

将测试结果上传到Dashboard，同样有对应的命令，该命令需要指定将分析结果上传到哪个Dashboard工程，并指定上传版本号，如果不指定版本号，Dashboard会默认将上传的时间作为版本号，因此在测试脚本编写早期，可以先忽略Dashboard工程版本号的问题。

当完成上述功能的脚本编写后，可以先在本地运行调试，如果没有问题就可以添加第三步的功能了。

第三步的目的是为了实现Dashboard工程与开发工程师之间的双向可追溯。当一个源码工程由多个开发人员共同开发和维护时，这个功能就会变得十分重要。使用python语言强大的正则表达式库（re），可以很方便地将所需信息从SVN的输出的info信息中解析出来。将解析得到的SVN上传者用户名和当前SVN版本号进行组合，作为Dashboard工程的版本号，可以令团队人员方便地了解Dashboard工程不同版本的上传作者，使开发人员之间的沟通更有效率。

如何实现测试的自动化？

当我们完成了测试脚本的编写，我们的脚本只能运行在有QAC license的电脑上。为了让所有开发都能使用该脚本进行静态测试，我们需要实现，让本地的提交的自动化测试脚本运行在指定的主机端，比如，有QAC license的主机。此时我们就需要借助可持续集成工具Jenkins和版本管理工具SVN来实现此功能。

基于Jenkins和SVN的自动化QAC静态分析流程图如下：

图2. 基于Jenkins和SVN的自动化QAC静态分析流程图

由上图我们可以看出，开发或测试工程师只需要将检出并修改的源码提交到SVN，就能实现代码的静态分析，在分析完成之后会接收到由Jenkins发送的附有分析报告的邮件，并可以通过登录Dashboard查看具体的分析结果。

当然实现上述操作的前提是，已经在SVN中建立好了对应的库，并在Jenkins中建立好了相应的Jenkins工程，对于SVN库的建立和Jenkins工程的配置在此不做详细的叙述。