周 毅, 王玉婷, 方 霞, 連紅森
(中國航發(fā)控制系統(tǒng)研究所,江蘇 無錫 214063)
航空發(fā)動機控制軟件(簡稱控制軟件)是一種嵌入式軟件,根據(jù)DO-178《民航機載軟件適航標準》的規(guī)定,屬于安全關(guān)鍵軟件[1]。為滿足適航認證,控制軟件必須要達成DO-178C提出的各項指標要求。其中,針對低層需求與高層需求的符合性這一目標,執(zhí)行單元測試并建立追溯關(guān)系是一種常見的實現(xiàn)手段。
針對嵌入式軟件開發(fā)環(huán)境和運行環(huán)境不一致的現(xiàn)象,單元測試具有可在宿主機環(huán)境下執(zhí)行、能提早測試介入時機且最大程度降低測試活動對目標環(huán)境依賴性等優(yōu)點;然而,單元測試也存在著的測試驅(qū)動難編寫、測試程序難管理、測試結(jié)果難界定等問題。對此,市場上出現(xiàn)了一批如CppUnit、JUnit等開源測試框架[2]和Cantata、TestBed、Qt、TBrun等單元測試軟件[3-5]。
其中QA Systems公司推出的Cantata單元測試工具,可提供基于DO-178B的覆蓋率分析,目前已在國內(nèi)外航空航天軟件的單元測試活動中得到廣泛應用[6-10]。該工具針對C/C++語言,通過使用EGT分析器提取源碼信息,結(jié)合插樁器和自動封裝技術(shù),實現(xiàn)測試腳本一鍵生成;通過提供測試用例管理器,實現(xiàn)測試用例便捷管理;通過運行結(jié)果自動比對、覆蓋結(jié)果樹形分析技術(shù),縮短測試驗證時間,確保驗證結(jié)論的正確性和完整性。
然而,由于Cantata工具在執(zhí)行單元測試活動時所有過程均需基于服務器執(zhí)行,而且工具對被測單元的隔離插樁過程與被測單元所屬文件有直接關(guān)聯(lián)。這就導致軟件升級時,若被測單元所屬文件發(fā)生變化,即使被測單元未發(fā)生更改,原有的單元測試用例也需要重新隔離插樁才能通過。由于隔離插樁過程需要人工操作,另外受到服務器響應和處理時間長的制約,在實際執(zhí)行Cantata單元測試回歸時,需要耗費大量時間和人力來更新未變更函數(shù)的隔離插樁。
目前,國內(nèi)外的相關(guān)文獻主要集中在對Cantata單元測試方法和工具使用的介紹說明[6-10]。針對本文提出的這一問題,尚未有具體解決方案。筆者提出了一種基于C#的Cantata工具變更過程改進方法。通過分析Cantata工具的單元測試插樁結(jié)果,提煉出工具的插樁規(guī)則,進而結(jié)合C#和正則表達式,完成源代碼變更前后差異分析,并依照提煉的插樁規(guī)則,自動修改測試用例管理器中的測試腳本和被插樁后的代碼,實現(xiàn)未變更函數(shù)的自動隔離插樁。從而解決人工操作煩瑣和隔離插樁過程對Cantata服務器強依賴的問題。
Cantata工具執(zhí)行單元測試過程主要由源代碼隔離插樁、測試腳本生成、可執(zhí)行文件構(gòu)建和運行這4個活動組成,各活動均由服務器執(zhí)行并將相應結(jié)果返回給用戶,具體如圖1所示。
圖1 Cantata單元測試原理圖
由于Cantata工具使用C文件作為自動封裝的最小單位(一個自動封裝可包含多個C文件),當被測單元所處自動封裝中的C文件出現(xiàn)全局變量、函數(shù)或外部函數(shù)調(diào)度變化時,即使被測函數(shù)沒有任何變更,也必須更新自動封裝,重新執(zhí)行隔離插樁,才能確保單元測試用例執(zhí)行通過。
Cantata測試用例管理器通過管理test_FuncX.c、test.mk和ipg.cop這3個文件來管控生成的測試腳本和被插樁代碼。
其中,test.mk是測試腳本的makefile信息,用于指導Build構(gòu)建器編譯生成可執(zhí)行文件;ipg.cop是測試級別配置文件,描述需要被隔離的全局變量和函數(shù),指導Cantata工具自動生成被測函數(shù)FuncX()的隔離插樁信息;test_FuncX.c是被測函數(shù)FuncX()的測試腳本,用于存儲被測函數(shù)的環(huán)境定義、覆蓋率分析方式、測試用例和隔離插樁接口等信息。
據(jù)此,在進行工具二次開發(fā)時,通過執(zhí)行代碼分析,識別出變更后代碼新增、刪除的全局變量、函數(shù)和函數(shù)調(diào)用信息,再將這些信息按照Cantata單元測試的格式要求,更新到test_FuncX.c、test.mk和ipg.cop中,實現(xiàn)對未變更單元的測試腳本和被插樁代碼的更新。二次開發(fā)后的Cantata單元測試原理如圖2所示。
圖2 二次開發(fā)后的Cantata單元測試原理圖
由圖2可以看出,基于C#的Cantata工具二次開發(fā)可以脫離對服務器的依賴,自動識別源碼的變更信息,完成測試腳本和被插樁代碼的修改。
通過分析Cantata單元測試結(jié)果,對Cantata插樁規(guī)格進行了提煉。圖3展示了某待測試文件XX.c的文件結(jié)構(gòu),包括全局變量GLB_a、函數(shù)FuncX()和FuncY(),其中FuncY()調(diào)用了一個外部函數(shù)UT_a()。
圖3 XX.c文件結(jié)構(gòu)示意圖
當FuncX()作為被測函數(shù)時,Cantata工具對test_FuncX.c、test.mk和ipg.cop文件的插樁規(guī)則如下。
① test_FuncX.c中,待隔離函數(shù)FuncY()的插樁規(guī)則如下:
/* Iaolate for function FuncY */
void ISOLATE_FuncY(void){
REGISTER_CALL(“FuncY”);
IF_INSTANCE(“default”){return;}
LOG_SCRIPIT_ERROR(“Call instance not defined.”);
Return;}
② test_FuncX.c中,全局變量GLB_a量的隔離規(guī)則如下:
/* Global data */
int GLB_a;
/* Expected variables for global data */
int expected_GLB_a;
static void initialse_global_data(){
TEST_SCRIPT_WARNING(“Verify initialse_global_data() ”);
INITIALISE(GLB_a);
}static void initialse_expected_global_data(){
TEST_SCRIPT_WARNING(“Verify initialse_expected_global_data() ”);
COPY_TO_EXPECTED(GLB_a, expected_GLB_a);}
static void check_global_data(){
TEST_SCRIPT_WARNING(“Verify check_global_data() ”);
CHECK_MEMORY(“GLB_a”, &GLB_a, &expected_GLB_a, sizeof(expected_GLB_a));}
③ ipg.cop中,待隔離函數(shù)funcY()和UT_a()的插樁規(guī)則如下:
“--sm:--isolate:FunY()”
“--sm:--isolate:UT_a()#FunY()”
④ ipg.cop中,全局變量GLB_a的隔離規(guī)則:
“--sm:--access_variable:”XX.c”:GLB_a”
基于C#進行Cantata工具二次開發(fā)時,主要難點在于源代碼分析和變更差異比對。對此,以文件為單位,設計了文件信息的數(shù)據(jù)結(jié)構(gòu),具體的文件信息類圖如圖4所示。數(shù)據(jù)結(jié)構(gòu)通過對頭文件引用、宏、數(shù)據(jù)結(jié)構(gòu)、全局變量、函數(shù)聲明、函數(shù)等信息進行分類存儲,實現(xiàn)變更差異的快速識別和比對。
圖4 FileInformation類圖
文件信息提取流程如圖5所示。為便于使用正則表達式提取源碼中的有效信息,首先需對源碼進行規(guī)格化處理,具體為剔除源碼中條件編譯忽略的代碼、注釋代碼、不規(guī)范和冗余的空格信息。由于條件編譯的判斷條件多使用宏信息,故需要先對源碼進行一次宏定義分析,再按照定制的形式進行規(guī)格化處理,導出規(guī)格化后的源碼。
圖5 文件信息提取流程圖
源碼規(guī)格化后,按照各數(shù)據(jù)結(jié)構(gòu)類型特點設計相應的正則表達式,依次提取頭文件引用、宏定義、基本數(shù)據(jù)類型、特殊數(shù)據(jù)類型、函數(shù)聲明、全局變量、函數(shù)信息,完成源碼的文件數(shù)據(jù)結(jié)構(gòu)提取。其中,特殊數(shù)據(jù)類型特指枚舉、位域結(jié)構(gòu)體和結(jié)構(gòu)體類型,另外考慮到同義宏的存在,設計了遞歸方法執(zhí)行同義宏的分類和存儲。
完成變更前后源碼的文件信息提取后,以文件為單位采用循環(huán)遍歷的方式,判斷并記錄對應文件中所有全局變量、函數(shù)及函數(shù)調(diào)用的變更狀態(tài)(共設計3種狀態(tài):增加、刪除、無變化)。依據(jù)記錄的變更狀態(tài),按照Cantata隔離插樁格式要求,更新用例管理器中未變化函數(shù)的單元測試用例腳本,實現(xiàn)未變更部分的自動隔離插樁。
在某項目升級過程中,應用基于C#的Cantata工具二次開發(fā)方法。通過選中變更前后源碼和Cantata測試用例管理器的位置,一鍵運行后,完成受升級影響的非變更測試用例隔離插樁的自動修改。具體運行界面如圖6所示。
圖6 運行界面
更改結(jié)果顯示,此次變更前后源碼共涉及17個文件、9個全局變量、81個函數(shù)的變更。使用Beyond Compare工具比對變更前后源碼并人工分析,結(jié)果顯示與C#的Cantata工具二次開發(fā)方法提取的結(jié)果一致,信息提取功能和變更比對功能正常。
此次變更前共計有436個單元測試腳本,變更前后共影響到123個測試腳本的關(guān)聯(lián)修改,修改量占28.2%。以其中一個關(guān)聯(lián)修改的測試腳本為例,進行分析:task.c文件共有5個函數(shù),比對變更前后的源碼,其中僅task_bigLoop()函數(shù)里新增了函數(shù)調(diào)度ISM_Excute25ms(),會同步影響該C文件中其他4個未變更函數(shù)測試腳本的隔離插樁。觀察分析對應未變更函數(shù)自動修改后的測試腳本可知,測試腳本中均按照格式要求完成了腳本修改,具體結(jié)果如圖7所示。
圖7 測試用例腳本修改結(jié)果
完成81個變更函數(shù)對應的測試腳本修改后,在Score環(huán)境下批跑所有的444個測試腳本,導出結(jié)果如圖8所示。結(jié)果顯示,所有自動隔離插樁的函數(shù)均通過,其中11個未通過的函數(shù)均為特殊實現(xiàn)原因?qū)е赂采w率無法滿足的函數(shù),與自動隔離插樁過程無關(guān)。
圖8 Cantata單元測試用例批跑結(jié)果
基于Cantata服務器進行人工手動隔離插樁時,平均每個測試腳本需花費大約10 min。使用二次開發(fā)方法后,平均只需要不到3 min即可完成所有未變更函數(shù)測試腳本隔離插樁工作。以本次123個測試腳本的關(guān)聯(lián)修改為例,二次開發(fā)方法可有效節(jié)省約20.45人時,測試工作效率有極大提升。
上述結(jié)果證明,基于C#的Cantata工具二次開發(fā)方法可準確識別變更前后的源碼信息并完成差異比對,能正確并快速實現(xiàn)未變更函數(shù)的自動隔離插樁工作。
通過分析航空發(fā)動機控制軟件升級過程,發(fā)現(xiàn)在依賴Cantata工具進行單元測試回歸時,存在未變更函數(shù)的測試腳本需重新人工手動隔離插樁,導致時間和人力耗費的問題,提出了一種基于C#的Cantata工具二次開發(fā)方法。項目實踐與分析結(jié)果表明,該方法能準確識別變更信息,正確并快速實現(xiàn)未變更函數(shù)的自動隔離插樁,極大提升了基于Cantata進行升級過程的單元測試效率,為達成DO-178C中低層需求與高層需求的符合性這一目標提供了有力支撐。
目前基于C#的Cantata工具二次開發(fā)方法已在3個項目的5次升級過程中得到應用,結(jié)果均正確可靠。但相較于市面上常見的源碼分析工具(如Eclipse CDT提供的API),本方法尚不支持函數(shù)內(nèi)部語法分析,也未與同類型代碼分析工具進行優(yōu)劣比對分析,這些可作為后續(xù)研究的一個方向。