前言
當一位有追求的測試(開發)工程師，每天面對枯燥且單調的靜態測試工作時，他一定會有將靜態代碼測試變為自動化執行的沖動。
然而當真正去實施自動化靜態測試平台的構建時，我們往往因為無從下手或實施艱難而選擇放棄。
本文將以靜態代碼測試工具Helix QAC+版本管理工具SVN+持續集成工具Jenkins為例，向你介紹基於Helix QAC的自動化靜態分析方案。
通過本文，你將了解該方案的具體實施步驟，以及該方案可以實現的具體效果。如果你之前從未接觸過Jenkins，看完本文后，你將對Jenkins的功能有一個大致的了解，同時你也可以根據自身的實際情況，構建自己的自動化靜態測試流水線，讓你徹底從枯燥且單調的靜態測試工作中解脫。
自動化靜態分析對靜態分析工具有什么要求？
為了實現自動化靜態分析，靜態分析工具需要滿足一下幾點要求：
- 可以通過命令行實現靜態分析工具的大部分功能；
- 可以脫離靜態分析工具查看分析結果；
- 可以支持並行分析；
下面介紹一下本文自動化靜態分析方案所使用的靜態分析工具——Helix QAC。
Helix QAC是什么？
Helix QAC(以下簡稱QAC)是嵌入式靜態分析領域公認的行業領導及先驅
- 其原廠PRQA是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的傳統靜態分析模式存在哪些問題：
- 開發人員無法快速查看分析結果。如果項目規模很大，開發人員很多，沒有QAC license的人員需要將工程傳遞給指定的測試（開發）人員進行分析，無法快速地獲取分析結果，以驗證代碼編寫或修改是否滿足要求。
- 測試人員工作量大。由於需要固定的人員進行靜態分析，測試人員需要對收到的源碼建立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工程的配置在此不做詳細的敘述。
下面我們就通過視頻展示一下該方案的具體實現效果：