作者 ｜ vivo 互聯(lián)網(wǎng)服務(wù)器團(tuán)隊 - Li Qingxin

C/C++ 開發(fā)效率一直被業(yè)內(nèi)開發(fā)人員詬病，單元測試開發(fā)效率也是如此，以至于開發(fā)人員不愿花時間來寫單元測試。那么我們是不是可以通過改善編寫單元測試的效率來提升項目的測試用例覆蓋率?

本文主要介紹如何利用GCC插件來實現(xiàn)提升C/C++開發(fā)者的單元效率工具解決方案，希望對大家在提升單元測試效率上有所啟發(fā)。

一、動機(jī)

上圖展示了C/C++單元測試的基本流程，在日常開發(fā)過程中寫單元測試是一項比較大工程量的事情，C/C++ 目前單元測試代碼都需要自己手動寫，而且對于一些私有方法打樁就更加麻煩。

目前業(yè)內(nèi)無開源的自動化測試框架或者工具，倒是有一些商業(yè)的自動測試工具，下圖展示了我們自動化測試工具及單元測試庫：

即使開源界有g(shù)test等測試庫的支持，我們?nèi)匀恍枰帉懘罅康膯卧獪y試用例代碼。對于一些private、protected的類方法，編寫單元測試用例的效率就更低，需要手動打樁(mock)。同時我們分析測試用例發(fā)現(xiàn)，存在很多邊界的用例，它們基本上都是很固定或者有一定模式，比如int 最大最小值等。

如何改善編寫單元測試的效率，提升C/C++同學(xué)開發(fā)效率以及程序質(zhì)量?我們可以通過提取源文件中的函數(shù)、類等信息，然后生成對應(yīng)的單元測試用例。自動生成用例時需要依賴函數(shù)的聲明、類的聲明等信息，那么我們應(yīng)該如何獲取這些信息呢?

例如：如下的函數(shù)定義：

void test(int arg) {}

我們希望能夠從上面的函數(shù)定義中得到函數(shù)的返回值類型、函數(shù)名稱、函數(shù)參數(shù)類型、函數(shù)作用域。通常我們可以通過以下幾種方式得到：

1.1 方法1：使用正則表達(dá)式

無奈C/C++ 格式比較復(fù)雜能夠雖然能夠使用多種組合來獲取對應(yīng)的函數(shù)聲明等信息：

 void test(int arg){}
 void test1(template<template<string>> arg,...){}
 void test2(int(*func)(int ,float,...),template<template<string>> arg2){}

那么就需要寫一系列的正則表達(dá)式：

• 提取函數(shù)名稱、參數(shù)名：[z-aA-Z_][0-9]+
• 提取函數(shù)返回值：^[a-zA-Z_]

關(guān)鍵詞提取出來了，但是他有一個很大的問題：怎么判斷文件中書寫的代碼是符合C/C++語法描述呢?

1.2 方法2：使用flex/bison 分析c/c++源碼文件

這當(dāng)然是一種很好的方式，但是工作量巨大，相當(dāng)于實現(xiàn)一個具備詞法、語法分析器簡易版本的編譯器，而且要適配不同的語法格式，雖然bison可以解決上述的如何判斷語法是否正確問題，但是仍然很復(fù)雜。

1.3 方法3：利用編譯已經(jīng)生成的AST 來生成代碼

通常我們了解到的GCC編譯的過程是以下四個階段：

源文件->預(yù)處理->編譯->匯編→鏈接

但實際上GCC為了支持更多的編程語言、不同的CPU架構(gòu)做了很多的優(yōu)化，如下圖所示：

上圖展示了GCC處理源碼及其他優(yōu)化過程，在前端部分生成的Generic 語言是gcc編譯過程中為源碼生成的一種與源碼語言無關(guān)的抽象語法表現(xiàn)形式(AST)。既然GCC編譯過程中生成了AST樹，那么我們可以通過GCC插件來提取GCC 前端生成的抽象語法樹關(guān)鍵信息比如函數(shù)返回值、函數(shù)名稱、參數(shù)類型等?？傮w難度也很高，一方面業(yè)內(nèi)可參考資料很少，只能通過分析GCC的源碼來分析AST語法樹上的各個節(jié)點描述。

本文所描述的自動化生成單元測試用例的解決方案(我們稱之為TU：Translate Unit，后文統(tǒng)稱為TU)就是基于方法3來實現(xiàn)的，下面我們先來看看我們的自動化測試用例解決方案的效果展示。

二、效果展示

2.1 業(yè)務(wù)代碼零修改， 直接使用TU生成邊界用例

在該用例中我們不需要修改任何業(yè)務(wù)代碼就能夠為業(yè)務(wù)代碼生成邊界測試用例，而且函數(shù)參數(shù)可邊界值實現(xiàn)全排列，大大降低用例遺漏風(fēng)險。大家可能發(fā)現(xiàn)這種沒有做任何修改生成的用例是沒有斷言的，雖然沒有斷言，它仍然能夠幫助發(fā)現(xiàn)單元是否會存在邊界值引起coredump。

那么如果想要給他加上斷言、mock函數(shù)，是否沒有辦法呢?通過C++11 [[]] 新的屬性語法，只需要在方法聲明或者定義時添加下根據(jù)TU的格式添加斷言即可，對業(yè)務(wù)邏輯無侵入。

2.2 使用注解tu::case生成用戶自定義用例

很多情況下默認(rèn)生成的邊界測試用例還不能覆蓋到核心邏輯，所以我們也提供tu::case 來給用戶自定義自己的測試用例及斷言。比如有一個int foo (int x,long y) 方法，現(xiàn)在想新增一個測試用例返回值123，函數(shù)實參1,1000，那么只要在函數(shù)聲明前加入，以下代碼即可：

[[tu::case("NE","123","1","1000")]]

2.3 使用注解tu::mock 自動生成mock方法

開發(fā)過程中我們也常需要對某個方法進(jìn)行mock(即對原有方法設(shè)置一個臨時代替方法并且調(diào)用方式保持一致)，比如某個函數(shù)訪問Redis、DB這種情況下進(jìn)行單元測試往往需要對這些方法進(jìn)行mock，方便其他函數(shù)調(diào)用進(jìn)行單元測試，為了方便進(jìn)行單元測試我們往往會對其進(jìn)行mock，所以為了方便開發(fā)人員進(jìn)行快速的mock，所以我們提供了tu::mock 的注解幫助開發(fā)同學(xué)快速的定義注解，然后TU會自動生成對應(yīng)的mock函數(shù)。例如：現(xiàn)在給foo_read 方法mock一個函數(shù)，讓mock的函數(shù)返回10：

三、TU實現(xiàn)方案

3.1 AST 是什么?

GENERIC、GIMPLE和RTL三者構(gòu)成了gcc中間語言的全部，它們以GIMPLE為核心，由GENERIC承上，由RTL啟下，在源文件和目標(biāo)指令之間的鴻溝之上構(gòu)建了一個三層的過渡。

GCC在語法分析過程中，所有識別出來的語言部件都用一個叫TREE的變量保存著。這個TREE就是GCC語法樹(AST)，這個過程叫做GENERIC。實際上它也是GCC的符號表，因為變量名、類型等等這些信息都由TREE關(guān)聯(lián)起來。

下面我們通過gcc編譯選項來看下gcc的ast表現(xiàn)形式：

3.2 AST(Abstract syntax tree)

GCC 可以通過添加編譯選項-fdump-tree-all 來生成ast 樹，ast樹文件內(nèi)容如下：

AST 各個類型描述可以參考：https://gcc.gnu.org/onlinedocs/gccint/Types.html

雖然上圖中簡單看下一下可以發(fā)現(xiàn)，gcc這種表現(xiàn)形式節(jié)點與節(jié)點之間還存在依賴，比較難于理解，沒有clang生成的直觀更容易閱讀。雖然不利于閱讀，但是不影響通過編碼來提取AST信息。

3.3 方案

如上圖所示，我們通過使用不同的插件收集被測試源文件的AST信息、頭文件信息、函數(shù)注解(屬性)，將這些重要信息保存起來。GCC將用戶注冊插件事件保存到數(shù)組中：

然后在編譯構(gòu)建過程中到就會去查找對應(yīng)的事件有沒有設(shè)置回調(diào)方法如果設(shè)置則進(jìn)行調(diào)用,TU主要使用以下幾種插件：

• PLUGIN_INCLUDE_FILE 用于獲取當(dāng)前文件的所包含的頭文件
• PLUGIN_OVERRIDE_GATE 用戶獲取普通函數(shù)、類
• PLUGIN_PRE_GENERICIZE 用于獲取模板函數(shù)的具現(xiàn)化
• PLUGIN_ATTRIBUTES 用于實現(xiàn)自定義屬性或者注解(tu::case\tu::mock ....)

GCC 支持的所有插件類型如下圖所示：(摘自gcc 6.3.0 源碼)

四、TU 插件使用的簡易程度對比

如果僅僅只是做邊界測試那么僅需要修改構(gòu)建的腳本比如cmake 添加對應(yīng)的插件參數(shù)即可。

五、使用TU的優(yōu)點

• 接入簡單、邊界單元測試可以做到業(yè)務(wù)代碼0修改
• 函數(shù)參數(shù)可邊界值實現(xiàn)全排列，大大降低用例遺漏風(fēng)險、減少大量重復(fù)性的工作
• 快速生成用戶自定義用例、mock方法等

六、TU支持的功能

七、總結(jié)與展望

1、文章中對比了三種方法自動生成測試用例的方法，下面對這幾種方法進(jìn)行對比：

2、文章中還主要介紹了TU的功能特點以及基于GCC-AST的實現(xiàn)自動生成測試用例的解決方案。

TU解決方案目前在構(gòu)建時能夠自動生成測試用例已經(jīng)極大降低了單元測試門檻提升單元測試覆蓋率，未來我們也希望能夠把TU與IDE相結(jié)合，探索更高效便捷的使用方式，通過更加便捷的方式生成指定方法的測試用例。比如通過在函數(shù)、方法上，通過快捷鍵生成當(dāng)前方法的測試用例等。