RTRT代碼覆蓋率及在Linux測試環(huán)境中的應(yīng)用

1、使用 Rational Test RealTime 分析 C/C+ 代碼覆蓋率及在 Linux 測試環(huán)境中的應(yīng)用代碼覆蓋率是在產(chǎn)品開發(fā)，測試過程中，衡量產(chǎn)品質(zhì)量的一項非常重要的技術(shù)指標(biāo)。它可以幫助工程師準確的判斷哪些源代碼經(jīng)過了測試，是否還需要補充測試代碼，從而在產(chǎn)品的開發(fā)、測試階段幫助工程師及時發(fā)現(xiàn)潛在問題，更好的提升產(chǎn)品質(zhì)量。Rational Test RealTime 是專門進行自動化測試、實時分析的工具集，它包括 Coverage、SystemTest、 Trace 等多項功能。其中 Coverage 用于分析代碼覆蓋率，改善代碼的可靠性和性能，它不但支持 C、C+、Java 等主流語

2、言，而且在 Linux、Unix 和 Windows 上都可以集成使用。本文主要介紹了在 Linux 環(huán)境下，如何利用 Rational Test RealTime 的命令模式進行 C/C+ 的代碼覆蓋率分析，針對不同的覆蓋率需求如何部署和配置 Rational Test RealTime，以及在真實的測試環(huán)境中如何收集、整合程序覆蓋率的測試結(jié)果，最終達到自動化分析和測試的目的。0 評論李 小燕, 軟件工程師, IBM曾 凡鋼, 軟件工程師, IBM2009 年 11 月 26 日· 內(nèi)容在 IBM Bluemix 云平臺上開發(fā)并部署您的下一個應(yīng)用。開始您的試用概述當(dāng)代信息

3、社會中，軟件的功能日趨強大，而項目卻日趨復(fù)雜，如何保證軟件項目在發(fā)布之前進行充分的測試，找出潛在問題，成為了一項重要課題。代碼覆蓋率是在產(chǎn)品開發(fā)，測試過程中，衡量產(chǎn)品質(zhì)量的一項非常重要的技術(shù)指標(biāo)。它可以幫助工程師準確的判斷哪些源代碼經(jīng)過了測試，是否還需要補充測試代碼，從而在產(chǎn)品的開發(fā)、測試階段幫助工程師及時發(fā)現(xiàn)潛在問題，更好的提升產(chǎn)品質(zhì)量。Rational Test RealTime 是 IBM 公司開發(fā)的一套強大的、適用于嵌入式系統(tǒng)，實時系統(tǒng)以及網(wǎng)絡(luò)系統(tǒng)的、跨平臺的自動化實時測試分析工具集。它擁有代碼覆蓋率分析，內(nèi)存泄露檢查，以及性能檢測等功能；能夠進行單元測試，集成測試，系統(tǒng)測試，實時的嵌

4、入式系統(tǒng)測試，分布式應(yīng)用測試等各種自動化測試；支持 AIX、HP Unix、Linux、Sun Solaris、Windows 等多種操作平臺。Rational Test RealTime 幾乎可以滿足開發(fā)團隊建立復(fù)雜交互系統(tǒng)測試平臺的所有需求。本文主要介紹在 Linux 環(huán)境下如何利用 Rational Test RealTime 的命令模式進行 C/C+ 的代碼覆蓋率分析，針對不同的覆蓋率需求如何部署和配置 Rational Test RealTime，以及在真實的測試環(huán)境中如何收集、整合程序覆蓋率的測試結(jié)果，最終達到自動化分析和測試的目的。目前針對代碼覆蓋率有很多測試的角度。Ration

5、al Test RealTime 主要提供下列 4 種：· 功能測試覆蓋：檢測程序中的每個函數(shù)是否被調(diào)用。特別是在開始的測試中，可以用來檢測軟件的哪些地方被覆蓋。這種測試往往可以迅速有效的找出測試漏洞。· 調(diào)用代碼覆蓋：這個標(biāo)準檢測是否執(zhí)行了每次函數(shù)調(diào)用。這是基于缺陷通常產(chǎn)生于模塊間的調(diào)用而提出的一個方法。· 塊代碼覆蓋：檢測是否每一行可執(zhí)行的代碼都被執(zhí)行過。· 條件代碼覆蓋：檢測是否有足夠的測試用例測試過每一條可能導(dǎo)致不同結(jié)果的條件語句?；?Rational Test RealTime 提供的上述代碼分析方法，接下來本文將會介紹如何使用 Ration

6、al Test RealTime 來做代碼覆蓋分析。其中，所有的實例都是基于本文供下載的例子代碼，在 Linux 環(huán)境中運行所得。回頁首搭建配置環(huán)境環(huán)境參數(shù)配置Rational Test RealTime 的下載，安裝方法可以在它的幫助手冊中找到。在使用 Rational Test RealTime 開始編譯項目之前，首先需要正確配置環(huán)境變量。下面給出了一些比較重要且常見的環(huán)境變量的配置方法：· TESTRTDIR: 強制賦值的變量。該變量指出 Rational Test RealTime 安裝的路徑。只有當(dāng)此變量被分配之后，所有的 Rational Test RealTime 可執(zhí)

7、行文件和庫才能被找到。比如，當(dāng) Rational Test RealTime 被安裝在 /build/RTRT/releases/TestRealTime.7.5.0.0下，運行命令echo $TESTRTDIR應(yīng)該打印出上面的路徑信息。· ATLTGT: 同樣是一個強制賦值的變量。它表示當(dāng)用戶使用該工具的命令行時的目標(biāo)部署端口（Target Deployment Port）的路徑。· ATTOLOBJ: 可選擇的賦值變量。該變量指向 project.h 文件和目標(biāo)部署端口文件 TP.o 或 TDP.obj

8、0;生成的路徑。缺省條件下，這些文件生成在當(dāng)前路徑下。如果需要在項目中生成多次 project.h 或 TP.o 文件，可以使用該變量指定生成位置，只生成一次，以后用的時候，系統(tǒng)會自動在該變量指定的路徑下去尋找這些文件。TDP 設(shè)置Rational Test RealTime 的目標(biāo)部署技術(shù)（Target Deployment Port，TDP）是一種靈活的，高效率的技術(shù)，它可以使測試基于目標(biāo)或者實時分析獨立地進行分析，與編譯器、鏈接器、調(diào)試器及目標(biāo)結(jié)構(gòu)無關(guān)，從而實現(xiàn)跨多開發(fā)環(huán)境，多目標(biāo)結(jié)構(gòu)。作為 Rational Test RealTime 的一個關(guān)鍵

9、組件，目標(biāo)部署技術(shù)允許用戶的測試用例和實時分析可以直接運用到目標(biāo)系統(tǒng)上。構(gòu)建 TDP 以使它可以和用戶的編譯器，鏈接器，調(diào)試器和目標(biāo)結(jié)構(gòu)相協(xié)調(diào)，使得測試可以獨立于 TDP。當(dāng)環(huán)境改變的時候不需要另外去更新 TDP。測試腳本的配置，執(zhí)行和報告仍然可以使用。在每個 TDP 配置中包含四個部分。· 基本設(shè)置：這個部分制定了缺省的文件擴展名，編譯鏈接標(biāo)志，環(huán)境變量和用戶自定義變量，允許用戶設(shè)置所有 Rational Test RealTime 常見的設(shè)置和變量以及 TDP 的部分。比如說，用戶可以設(shè)置在編譯，預(yù)處理和鏈接過程中使用的編譯器的名字和位置。如果稍后要改變編譯器，只需要更新這個部分

10、就可以了。· 構(gòu)建（Build）設(shè)置：這個部分主要配置 Rational Test RealTime 圖形接口集成 build 過程所需要的一些功能。它定義了編譯，鏈接，執(zhí)行 perl 腳本以及用戶所需的自定義的腳本。該部分是 TDP 的核心部分，所有的需要編譯和執(zhí)行的部分都是靠它來驅(qū)動的。所有和 build 設(shè)置相關(guān)的文件都被存儲在 TDP cmd 這個下級目錄下。· 庫設(shè)置：這個部分描述了在目標(biāo)平臺下使用 TDP 的一系列源碼文件和用戶定制文件。它定義了特定平臺下的 TDP 的最常用的部分定制設(shè)置。這些文件被存儲在 TDP .lib

11、0;目錄下。· 解析設(shè)置：這個部分可以為了強調(diào)非標(biāo)準的編譯后綴名而改變解析器的行為。例如，non-ANSI 后綴。該部分使得用戶可以使用 Rational Test RealTime 正確適當(dāng)?shù)慕馕鲎约旱脑创a，插入標(biāo)志或者生成代碼。對應(yīng)的配置文件放在 TDP ana 這個下級目錄下。安裝完 Rational Test RealTime 在 $TESTRTDIR/targets 這個目錄下發(fā)現(xiàn)已經(jīng)有一些常用的 TDP 被安裝了。在筆者的機器上，安裝了下列 TDP（清單 1）.清單 1. 已安裝 TDP#lsadagnat adaunxa

12、pex clinuxgnu cunxdiabsgstep gcc_act jdk1.4.0 stAgent xml用戶可以通過設(shè)置 ATLTGT 這個環(huán)境變量來決定使用哪一個 TDP。例如，在本例中使用了 clinuxgnu。目錄 ana 下的文件 atl.opp 包括了解析設(shè)置的一部分，也是比較常用的一部分。清單 2 是它的一個實例。清單 2. 文件 atl.opp 示例-dollar-no_restrict-special_subscript_cost-no_alternative_tokens-variadic_macros-extend

13、ed_variadic_macros-void_star_null_pointer-guiding_decls-old_specialization-gnu_mode-microsoft_union_with_array-treat_template_classes_as_static-simulate_virtual_methods-simulate_called_routines-diag_suppress 14,34,46,47,161,174,177,305,375,427,549,550,737,795,830,837,940,997-diag_suppress 1,30,114,2

14、89,330,349,397-diag_suppress 100,137,280,350,381,416,541,815-diag_suppress 175,186,307,321,347,485,603,756-diag_suppress 191,265,603,691,802,1053,1205-diag_suppress 68,847,1097-diag_suppress 83, 94, 111, 180, 513-old_style_template_instantiation-vla-sys_include=/usr/X11R6-gnu_version=40300-gen_new_s

15、pecialization-sys_include=/usr/lib/gcc/i386-redhat-linux/4.3.0/././././include/c+/4.3.0-sys_include=/usr/include/c+/4.3.0-sys_include=/usr/lib/gcc/i386-redhat-linux/4.3.0/././././include/c+/4.3.0/i386-redhat-linux-sys_include=/usr/include/c+/4.3.0/i386-redhat-linux-sys_include=/usr/lib/gcc/i386-redh

16、at-linux/4.3.0/././././include/c+/4.3.0/backward-sys_include=/usr/include/c+/4.3.0/backward-sys_include=/usr/local/include-sys_include=/usr/lib/gcc/i386-redhat-linux/4.3.0/include-sys_include=/usr/include-sys_include=project path/CodeCoverage/include在該文件中，有幾個參數(shù)常常會用到，需要引起注意。其中之一是 Diag_suppress。當(dāng)

17、用戶在使用 RT 來編譯工程時如果想忽略某些警告甚至錯誤時，可以通過設(shè)置這個參數(shù)來實現(xiàn)。例如，如果想忽略錯誤或者警告 83，94，111，180，153，可以把這樣一行 -diag_suppress 83, 94, 111, 180, 513 加入該文件。另一個需要注意的參數(shù)是 sys_include。通常情況下，RT 會對所有的原文件來做代碼覆蓋分析，包括 .c, .cpp 和 .h 文件。如果用戶不想對位于某些特定位置的文件作覆蓋分析，可以把對應(yīng)的目錄路徑賦值給該變量。例如，該實例中不想對 include 目錄下的文件做代碼分析，

18、可以加入這樣一行 -sys_include=the examples folder/include?；仨撌准?Rational Test RealTime 生成 Build安裝完 Rational Test RealTime，配置好所需的環(huán)境參數(shù)后，需要檢查 Rational Test RealTime 所需要的環(huán)境配置是否都已經(jīng)在當(dāng)前系統(tǒng)中運行成功。方法如下：1. 運行命令行 $TESTRTDIR/license_check 來確認所需的 Rational Server 已經(jīng)運行，并已經(jīng)具備有效的注冊碼。2. 運行命令 $TESTRTDIR/test

19、rtinit.sh 設(shè)置 Rational Test RealTime 的環(huán)境變量，包括 PATH 等等。Rational Test RealTime 還提供了命令 attolcc 來編譯以 C/C+ 為源代碼的程序。它的使用方法如下所示。#attolcc <-options> <-settings> - <compilation_command>以上參數(shù)分別代表：· <options> 指一系列可選擇的參數(shù)項。· <settings> 是一系列可選擇項的對應(yīng)值。&

20、#183; <compilation_command> 是指在沒有使用 Rational Test RealTime 情況下，用戶所用的編譯項目的標(biāo)準命令行。所有上面描述的參數(shù)細節(jié)都可以在 Rational Test RealTime 幫助文檔中查到。完成環(huán)境配置后，就可以開始利用 Rational Test RealTime 來生成項目的新 Build。生成方法只需在命令行中加入 Rational Test RealTime 的相應(yīng)指令。接下來將從全代碼覆蓋率和指定模塊代碼覆蓋率兩種不同覆蓋方法，舉例說明如何利用 Rational Test RealTime 生成新 b

21、uild，以及如何進行覆蓋率分析。全代碼覆蓋率分析全代碼覆蓋率分析，就是對整個項目的所有文件進行覆蓋率分析。這種方法適用于用戶關(guān)心整體項目的測試質(zhì)量，而非某個模塊。使用 Rational Test RealTime 進行全代碼覆蓋率分析十分方便，只需在整個項目頂層的編譯參數(shù)前加上 Rational Test RealTime 的參數(shù)。以上面的例子為例，進行全代碼覆蓋率分析。我們在項目文件夾 CodeCoverage 下面運行命令 make，并且在其前面加上 Rational Test RealTime 的參數(shù) attolcc，還可以在編譯指令（如 gcc）前面加上

22、適當(dāng)?shù)倪x擇參數(shù)。比如我們有一個包括 3 個模塊的項目，每個模塊都有他們自己的 .c 文件和 makefiles（如清單 3 所示）。在最頂層的文件夾中，另外有一個總的 main.c 文件，它會鏈接所有的模塊中的目標(biāo)文件，然后生成一個可執(zhí)行文件。清單 3. 用例文件夾結(jié)構(gòu)#lscomponent1 component2 component3 include main.c makefile進行全代碼覆蓋率分析我們只需要在頂層文件夾編譯時，將編譯命令改為：# make CC="attolcc gcc”在這里，我們?yōu)轫攲泳幾g的“gcc”加了一個前綴“attolcc - ”。在打印出

23、的日志信息里面，我們可以看到所有的模塊在編譯時都會自動加上測試代碼覆蓋率的前綴“attolcc - ”，如列表 4 所示清單 4. 日志示例attolcc -proc - gcc -g -I"<project-dir>/include" -o main.o -c main.c#>#Perl Script Command Line (9 args): # attolcc -proc - gcc -g -I<project-dir>/include -o main.o -c main.c # ATLTGT = /RTRT/Execute/

24、releases/TestRealTime.7.5.0.0/targets/clinuxgnu# TESTRTDIR = /RTRT/Execute/releases/TestRealTime.7.5.0.0TestRT-I-STARTEXEC, Rational(R) Test RealTime instrumentation driver 7.5.0.0TestRT-I-COPYRIGHT, Copyright(C) 1996-2008 Rational Software Corporation. >preprocessing of main.c to main.i>instr

25、umentation of main.i to main_aug.c>compilation of main_aug.c to main.omake1: Entering directory <project-dir>/component1'attolcc -proc - gcc -I"<project-dir>/include" -c file1.c>preprocessing of file1.c to file1.i>instrumentation of file1.i to file1_aug.c>compil

26、ation of file1_aug.c to file1.oattolcc -proc - gcc -I"<project-dir>/include" -c file2.cattolcc -proc - gcc -I"<project-dir>/include" -c file3.cattolcc -proc - gcc -g -I"<project-dir>/include" -o calculator main.o <project-dir>/component1/file1.o

27、<project-dir>/component2/file2.o <project-dir>/component3/file3.oTestRT-I-STARTEXEC, Rational(R) Test RealTime instrumentation driver 7.5.0.0TestRT-I-COPYRIGHT, Copyright(C) 1996-2008 Rational Software Corporation. >TDP generation. >Link with ./TP.o在編譯成功后，在對應(yīng)的文件夾下面會產(chǎn)生一些新的文件，比如 prod

28、ucts.h, TP.o 等等，如列表 5 所示。清單 5. 生成文件#lsattolccReport.xtp component1 component2 component3 main.c main.o products.hcalculator include main.c.fdc makefile TP.o其中，.fdc 文件就是代碼覆蓋率的報告文件。在每個模塊中對每個 .c 文件都會生成一個這樣對應(yīng)的文件。在有些情況下，我們加入“attolcc - ”進行編譯，會增加出錯的概率，這可能是因為 Rational Test RealTime 會進行二次編譯的原因造成的。這時我們可以

29、加入?yún)⒘?#160;verbose 來增加打印錯誤信息，來判斷是何種原因造成的出錯以及如何解決。根據(jù)經(jīng)驗，如果遇到“unlink ./products.h failed”的錯誤，往往是因為系統(tǒng)在鏈接過程中會因在眾多模塊中產(chǎn)生多個 TP.o 文件而產(chǎn)生鏈接錯誤，可以通過以下方式解決：1. 通過以下命令在某個目錄下手動的生成 TP.o 文件#gcc TP.c2. 定義參數(shù) ATTOLOBJ。將其值設(shè)定為步驟 1 中 TP.o 文件的路徑。#export ATTOLOBJ=the path in step 13. 在編譯命令中加入?yún)?shù) - noTDP。這會使得系統(tǒng)在鏈接

30、過程中使用步驟 1 中生成的 TP.o，而不是由系統(tǒng)自己生成的 TP.o。#make CC=” attolcc noTDP - gcc”指定模塊覆蓋率分析在很多測試情況下，不需要對整個項目進行代碼覆蓋率分析，而只是對項目中某些特定的模塊感興趣，只需要對這些部分模塊進行代碼修改或者測試。Rational Test RealTime 不僅支持整個項目的全代碼覆蓋率分析，而且還支持只分析某些特定的項目模塊，為程序員提供了更大的靈活性。同樣以上例為例，在示例中我們有三個模塊，分別是：component1, component2 和 component3。假如僅僅需要分析 component1 的代碼覆

31、蓋率，也就是指定模塊的覆蓋率分析。可以按以下步驟進行：1. 僅在編譯 component1 時使用 Rational Test RealTime。# make CC="attolcc -atl_runtime_format=NONE - gcc"2. 而在其他模塊的編譯中不使用 Rational Test RealTime。# make3. 在頂層的項目文件夾下，先編譯出目標(biāo)文件。# gcc c main.c o main.o4. 利用 Rational Test RealTime 鏈接所有的目標(biāo)文件，最后生成可執(zhí)行文件。# attolcc - gcc -o main.ex

32、e main.o component1/file1.a component2/file2.o component3/file3.o這個可以通過修改頂層文件夾下的 makefile 來實現(xiàn)（清單 6）。清單 6. Makefile 示例CC = gccCFLAGS = -g $(OPTION64) -I$(PDIR) RT = attolcc - $(CC) calculator l: main.o $(DIRCOMP1)/file1.o $( DIRCOMP2)/file2.o $( DIRCOMP3)/file3.o$(RT) $(CFLAGS) -o $ $? main.o: ./main

33、.c$(CC) $(CFLAGS) -o $ -c $?$(DIRCOMP1)/file1.o: cd $(DIRCOMP1); make CC="attolcc -atl_runtime_format=NONE - gcc"cd .; $(DIRCOMP2)/file2.o: cd $(DIRCOMP2); make; cd .; $(DIRCOMP3)/file3.o: cd $(DIRCOMP3); make; cd .;通過這種方法，代碼覆蓋率的報告文件（.fdc 文件）就只會在 component1 下面生成，而不是整個項目下都有。在使用 Rational Tes

34、t RealTime 進行指定模塊覆蓋率分析的時候，有兩點我們特別要注意：1. 如果編譯過程中遇到以下錯誤：/build/RTRT/releases/TestRealTime.7.5.0.0/targets/clinuxgnu/lib/priv.c:119: multiple definition of priv_exit'，這可能是由于 Rational Test RealTime 在鏈接庫文件時重復(fù)鏈接造成的，可以嘗試加入?yún)?shù) -atl_runtime_format=NONE 來避免重復(fù)鏈接。當(dāng)鏈接時生成的文件是目標(biāo)文件（obj）或者庫文件時必須使用該參數(shù)設(shè)置。

35、2. 在第 1 步和第 4 步使用的參數(shù)除了 -atl_runtime_format=NONE 以外必須相同。回頁首收集覆蓋率數(shù)據(jù)在利用 Rational Test RealTime 對項目編譯鏈接完成以后，下一步就需要對代碼進行覆蓋率數(shù)據(jù)收集。我們通過運行生產(chǎn)的目標(biāo)程序來獲取源代碼插入分析信息文件（Source Code Insertion -SCI），這個文件的默認名字是 atlout.spt（如清單 7 所示）。清單 7. 生成 spt 文件#lsatlout.spt calculator component1 component2 component3 m

36、ain.c.fdc makefile TP.cattolccReport.xtp main.c main.o products.h在這之后，利用 dump file splitter 工具atlsplit 來分離源代碼插入分析信息文件。這里假設(shè) .spt 文件使用的就是默認名字，我們可以運行清單 8 中的命令。在其結(jié)果中，會新產(chǎn)生一個以 tio 為后綴的文件，默認名為 attolcov.tio，這個就是代碼覆蓋分析所需的動態(tài)追蹤文件 (Dynamic Trace File)。清單 8. Split 結(jié)果#atlsplit atlout.sptSplitting a

37、tlout.spt traces fileTraces file successfully split.現(xiàn)在，所有檢查代碼覆蓋率所需的文件都準備好了。回頁首查看覆蓋率信息收集完代碼覆蓋率數(shù)據(jù)以后，可以通過 Rational Test RealTime 中的圖形界面（GUI）來查看覆蓋率分析結(jié)果。Rational Test RealTime 的圖形查看工具支持 Windows、Linux、AIX 等多種操作系統(tǒng)，能夠?qū)Υa覆蓋率進行柱狀圖分析，源文件覆蓋分析和統(tǒng)計結(jié)果分析。這里仍以 Linux 環(huán)境下進行結(jié)果查看為例。在 Rational Test RealTime 的安裝目錄下運行以下代碼：#studio <file>.c.fdc attolcov.tio圖形界面將會自動打開。其中 <file>.c.fdc 是我們所想要查看的代碼覆蓋率報告文件。我可以指定一個或者同時指定多個 fdc 文