一種基于C#的Cantata工具變更過程改進(jìn)方法

　　摘要: 航空發(fā)動(dòng)機(jī)控制軟件在升級(jí)過程中使用 Cantata 工具開展單元測(cè)試活動(dòng)時(shí)，存在著未變更函數(shù)的 Cantata 測(cè)試腳本需重新人工隔離插樁，致使時(shí)間和人力耗費(fèi)的問題。通過研究 Cantata 自動(dòng)生成測(cè)試腳本的過程及插樁特點(diǎn)，提出了一種基于 C#的 Cantata 工具變更過程改進(jìn)方法。該方法通過 C#語言結(jié)合正則表達(dá)式進(jìn)行代碼分析，識(shí)別出升級(jí)過程中的變更函數(shù)和全局變量，并按照 Cantata 插樁格式，自動(dòng)完成測(cè)試腳本更新工作。詳細(xì)介紹了該方法的設(shè)計(jì)過程，并在某型航空發(fā)動(dòng)機(jī)控制軟件升級(jí)過程中進(jìn)行實(shí)踐應(yīng)用。實(shí)踐結(jié)果表明，該方法可準(zhǔn)確識(shí)別源碼信息并完成變更前后的差異比對(duì)，能正確快速實(shí)現(xiàn)未變更函數(shù)的自動(dòng)隔離插樁工作，有效解決了人力和時(shí)間消耗的問題，對(duì)回歸測(cè)試效率有極大提升。

　　本文源自測(cè)控技術(shù)2021-02-01《測(cè)控技術(shù)》雜志，月刊，于1982年經(jīng)國(guó)家新聞出版總署批準(zhǔn)正式創(chuàng)刊，由中國(guó)航空工業(yè)集團(tuán)有限公司主管，中國(guó)航空工業(yè)集團(tuán)北京長(zhǎng)城航空測(cè)控技術(shù)研究所主辦的學(xué)術(shù)性刊物，本刊在國(guó)內(nèi)外有廣泛的覆蓋面，題材新穎，信息量大、時(shí)效性強(qiáng)的特點(diǎn)，其中主要欄目有：綜述、航空裝備保障與維修技術(shù)專題、數(shù)據(jù)采集與處理等。

　　關(guān)鍵詞: DO-178C; 嵌入式系統(tǒng); 單元測(cè)試; C#

　　航空發(fā)動(dòng)機(jī)控制軟件( 簡(jiǎn)稱控制軟件) 是一種嵌入式軟件，根據(jù)《民航機(jī)載軟件適航標(biāo)準(zhǔn) DO-178》的規(guī)定，屬于安全關(guān)鍵軟件[1]。為滿足適航認(rèn)證，控制軟件必須要達(dá)成 DO-178C 提出的各項(xiàng)指標(biāo)要求。其中，針對(duì)低層需求與高層需求的符合性這一目標(biāo)，執(zhí)行單元測(cè)試并建立追溯關(guān)系是一種常見的實(shí)現(xiàn)手段。

　　針對(duì)嵌入式軟件開發(fā)環(huán)境和運(yùn)行環(huán)境不一致的現(xiàn)象，單元測(cè)試具有可在宿主機(jī)環(huán)境下執(zhí)行、能提早測(cè)試介入時(shí)機(jī)且最大程度降低測(cè)試活動(dòng)對(duì)目標(biāo)環(huán)境依賴性等優(yōu)點(diǎn); 然而，單元測(cè)試也存在著的測(cè)試驅(qū)動(dòng)難編寫、測(cè)試程序難管理、測(cè)試結(jié)果難界定等問題。對(duì)此，市場(chǎng)上出現(xiàn)了一批如 Cppunit、Jnuit 等開源測(cè)試框架[2]和 cantata、TestBed、Qt、TBrun 等單元測(cè)試軟件[3 - 5]。

　　其中 QA Systems 公司推出的 cantata 單元測(cè)試工具，可提供基于 DO-178B 的覆蓋率分析，目前已在國(guó)內(nèi)外航空航天軟件的單元測(cè)試活動(dòng)中得到廣泛應(yīng)用[6 - 10]。該工具針對(duì) C /C + + 語言，通過使用 EGT 分析器提取源碼信息，結(jié)合插樁器和自動(dòng)封裝技術(shù)，實(shí)現(xiàn)測(cè)試腳本一鍵生成; 通過提供測(cè)試用例管理器，實(shí)現(xiàn)測(cè)試用例便捷管理; 通過運(yùn)行結(jié)果自動(dòng)比對(duì)、覆蓋結(jié)果樹形分析技術(shù)，縮短測(cè)試驗(yàn)證時(shí)間，確保驗(yàn)證結(jié)論的正確性和完整性。

　　然而，由于 cantata 工具在執(zhí)行單元測(cè)試活動(dòng)時(shí)所有過程均需基于服務(wù)器執(zhí)行，而且工具對(duì)被測(cè)單元的隔離插樁過程與被測(cè)單元所屬文件有直接關(guān)聯(lián)。這就導(dǎo)致軟件升級(jí)時(shí)，若被測(cè)單元所屬文件發(fā)生變化，即使被測(cè)單元未發(fā)生更改，原有的單元測(cè)試用例也需要重新隔離插樁才能通過。由于隔離插樁過程需要人工操作，另外受到服務(wù)器響應(yīng)和處理時(shí)間長(zhǎng)的制約，在實(shí)際執(zhí)行控制軟的 cantata 單元測(cè)試回歸時(shí)，需要耗費(fèi)大量時(shí)間和人力來更新未變更函數(shù)的隔離插樁。

　　目前，國(guó)內(nèi)外的相關(guān)研究文獻(xiàn)，主要集中在對(duì) cantata 單元測(cè)試方法和工具使用的介紹說明[6 - 10]。針對(duì)本文提出的這一問題，尚未有具體解決方案。筆者提出了一種基于 C#的 cantata 工具變更過程改進(jìn)方法。通過分析 cantata 工具的單元測(cè)試插樁結(jié)果，提煉出工具的插樁規(guī)則，進(jìn)而結(jié)合 C#與正則表達(dá)式，完成源代碼變更前后差異分析，并依照提煉的插樁規(guī)則，自動(dòng)修改測(cè)試用例管理器中的測(cè)試腳本和被插樁后的代碼，實(shí)現(xiàn)未變更函數(shù)的自動(dòng)隔離插樁。從而解決人工操作繁瑣，解決隔離插樁過程對(duì) cantata 服務(wù)器強(qiáng)依賴的問題。

　　1 基于 C#的 cantata 變更過程改進(jìn)方法

　　1. 1 整體方案分析

　　cantata 工具執(zhí)行單元測(cè)試過程主要由源代碼隔離插樁、測(cè)試腳本生成、可執(zhí)行文件構(gòu)建和運(yùn)行這 4 個(gè)活動(dòng)組成，各活動(dòng)均由服務(wù)器執(zhí)行并將相應(yīng)結(jié)果返回給用戶，具體如圖 1 所示。

　　由于 cantata 工具使用 c 文件作為自動(dòng)封裝的最小單位( 一個(gè)自動(dòng)封裝可包含多個(gè) c 文件) ，當(dāng)被測(cè)單元所處自動(dòng)封裝中的 c 文件出現(xiàn)全局變量、函數(shù)或外部函數(shù)調(diào)度變化時(shí)，即使被測(cè)函數(shù)不存在任何變更，也必須更新自動(dòng)封裝，重新執(zhí)行隔離插樁，才能確保單元測(cè)試用例執(zhí)行通過。

　　cantata 測(cè)試用例管理器通過管理 test _FuncX. c、 test. mk 和 ipg. cop 這 3 個(gè)文件來管控生成的測(cè)試腳本和被插樁代碼。

　　其中 test. mk 是測(cè)試腳本的 makefile 信息，用來指導(dǎo) Build 構(gòu)建器編譯生成可執(zhí)行文件; ipg. cop 是測(cè)試級(jí)別配置文件，描述需要被隔離的全局變量和函數(shù)，指導(dǎo) cantata 工具自動(dòng)生成被測(cè)函數(shù) FuncX( ) 的隔離插樁信息; test_FuncX. c 是被測(cè)函數(shù) FuncX( ) 的測(cè)試腳本，用來存儲(chǔ)被測(cè)函數(shù)的環(huán)境定義、覆蓋率分析方式、測(cè)試用例和隔離插樁接口等信息。

　　據(jù)此，在進(jìn)行工具二次開發(fā)時(shí)，通過執(zhí)行代碼分析，識(shí)別出變更后代碼新增、刪除的全局變量、函數(shù)及函數(shù)調(diào)用信息，再將這些信息按照 cantata 單元測(cè)試的格式要求，更新到 test_FuncX. c、test. mk 和 ipg. cop 中去，實(shí)現(xiàn)對(duì)未變更單元的測(cè)試腳本和被插樁代碼的更新。二次開發(fā)后的 cantata 單元測(cè)試原理如圖 2 所示。由圖2 可以看出，基于 C#的 cantata 工具二次開發(fā)可以脫離對(duì)服務(wù)器的依賴，自動(dòng)識(shí)別源碼的變更信息，完成測(cè)試腳本和被插樁代碼的修改。

　　1. 2 cantata 插樁規(guī)則提煉

　　通過分析 cantata 單元測(cè)試結(jié)果，對(duì) cantata 插樁規(guī)格進(jìn)行了提煉。圖 3 展示了某待測(cè)試文件 XX. c 的文件結(jié)構(gòu)，包含有全局變量 GLB _ a、函數(shù) FuncX( ) 和 FuncY( ) ，其中 FuncY( ) 調(diào)用了一個(gè)外部函數(shù) UT_a ( ) 。

　　當(dāng) FuncX( ) 作為被測(cè)函數(shù)時(shí)，cantata 工具對(duì) test_ FuncX. c、test. mk 和 ipg. cop 文件插樁規(guī)則如下。

　　test_FuncX. c 中，待隔離函數(shù) FuncY( ) 的插樁規(guī)則如下函數(shù)隔離規(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 ( ) \ n”) ; INITIALISE( GLB_a) ; } static void initialse_expected_global_data( ) { TEST _ SCRIPT _ WARNING( “Verify initialse _ expected _ global_data( ) \ n”) ; COPY_TO_EXPECTED( GLB_a，expected_GLB_a) ; } static void check_global_data( ) {TEST_SCRIPT_WARNING( “Verify check_global_data( ) \ n”) ; 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”

　　1. 3 二次開發(fā)方法設(shè)計(jì)

　　基于 C#進(jìn)行 cantata 工具二次開發(fā)時(shí)，主要難點(diǎn)在于源代碼分析和變更差異比對(duì)。對(duì)此，以文件為單位，設(shè)計(jì)了文件信息的數(shù)據(jù)結(jié)構(gòu)，具體的文件信息類圖如圖 4 所示。數(shù)據(jù)結(jié)構(gòu)通過對(duì)頭文件引用、宏、數(shù)據(jù)結(jié)構(gòu)、全局變量、函數(shù)聲明、函數(shù)等信息進(jìn)行分類存儲(chǔ)，實(shí)現(xiàn)變更差異的快速識(shí)別和比對(duì)。

　　文件信息提取流程如圖 5 所示。為便于使用正則表達(dá)式提取源碼中的有效信息，首先需對(duì)源碼進(jìn)行規(guī)格化處理，具體為剔除源碼中由條件編譯忽略的代碼、注釋代碼、不規(guī)范和冗余的空格信息。由于條件編譯的判斷條件多使用宏信息，故需先對(duì)源碼進(jìn)行一次宏定義分析，再按照定制的形式進(jìn)行規(guī)格化處理，導(dǎo)出規(guī)格化后的源碼。

　　源碼規(guī)格化后，按照各數(shù)據(jù)結(jié)構(gòu)類型特點(diǎn)設(shè)計(jì)相應(yīng)的正則表達(dá)式，依次提取頭文件引用、宏定義、基本數(shù)據(jù)類型、特殊數(shù)據(jù)類型、函數(shù)聲明、全局變量、函數(shù)信息，完成源碼的文件數(shù)據(jù)結(jié)構(gòu)提取。其中特殊數(shù)據(jù)類型特指枚舉、位域結(jié)構(gòu)體和結(jié)構(gòu)體類型，另外考慮到同義宏的存在，設(shè)計(jì)了遞歸方法執(zhí)行同義宏的分類和存儲(chǔ)。

　　完成變更前后源碼的文件信息提取后，以文件為單位采用循環(huán)遍歷的方式，判斷并記錄對(duì)應(yīng)文件中所有全局變量、函數(shù)及函數(shù)調(diào)用的變更狀態(tài)( 共設(shè)計(jì) 3 種狀態(tài): 增加、刪除、無變化) 。依據(jù)記錄的變更狀態(tài)，按照 cantata 隔離插樁格式要求，更新用例管理器中未變化函數(shù)的單元測(cè)試用例腳本，實(shí)現(xiàn)未變更部分的自動(dòng)隔離插樁。

　　2 項(xiàng)目應(yīng)用實(shí)踐與結(jié)果分析

　　在某項(xiàng)目升級(jí)過程中，應(yīng)用基于 C #的 cantata 工具二次開發(fā)方法。通過選中變更前后源碼及 cantata 測(cè)試用例管理器的位置，一鍵運(yùn)行后，完成受升級(jí)影響的非變更測(cè)試用例隔離插樁的自動(dòng)修改。具體運(yùn)行界面如圖 6 所示。

　　更改結(jié)果顯示，此次變更前后源碼共涉及 17 個(gè)文件、9 個(gè) 全 局 變 量、81 個(gè) 函 數(shù) 的 變 更。使 用 Beyond Compare 工具比對(duì)變更前后源碼并人工分析，結(jié)果顯示與 C #的 cantata 工具二次開發(fā)方法提取的結(jié)果一致，信息提取功能和變更比對(duì)功能正常。

　　此次變更前共計(jì)有 436 個(gè)單元測(cè)試腳本，變更前后共影響到 123 個(gè)測(cè)試腳本的關(guān)聯(lián)修改，修改量占比 28. 2% 。以其中一個(gè)關(guān)聯(lián)修改的測(cè)試腳本為例，進(jìn)行分析:

　　task. c 文件共有 5 個(gè)函數(shù)，比對(duì)變更前后的源碼，其中僅 task_bigLoop( ) 函數(shù)里新增了函數(shù)調(diào)度 ISM _ Excute25ms( ) ，同步會(huì)影響該 c 文件中其他 4 個(gè)未變更函數(shù)測(cè)試腳本的隔離插樁。觀察分析對(duì)應(yīng)未變更函數(shù)自動(dòng)修改后的測(cè)試腳本可見，測(cè)試腳本中均按照格式要求完成了腳本修改，具體結(jié)果如圖 7 所示。

　　完成 81 個(gè)變更函數(shù)對(duì)應(yīng)的測(cè)試腳本修改后，在 Score 環(huán)境下批跑所有的 444 個(gè)測(cè)試腳本，導(dǎo)出結(jié)果如圖 8 所示。結(jié)果顯示所有自動(dòng)隔離插樁的函數(shù)均通過，其中 11 個(gè)未通過的函數(shù)均為特殊實(shí)現(xiàn)原因?qū)е赂采w率無法滿足的函數(shù)，與自動(dòng)隔離插樁過程無關(guān)。

　　基于 cantata 服務(wù)器進(jìn)行人工手動(dòng)隔離插樁時(shí)，平均每個(gè)測(cè)試腳本需花費(fèi)大約 10 min。使用二次開發(fā)方法后，平均只需要不到 3 min 即可完成所有未變更函數(shù)測(cè)試腳本隔離插樁工作。以本次 123 個(gè)測(cè)試腳本的關(guān)聯(lián)修改為例，二次開發(fā)方法可有效節(jié)省約 20. 45 人時(shí)，測(cè)試工作效率有極大提升。

　　綜上結(jié)果證明，基于 C#的 cantata 工具二次開發(fā)方法可準(zhǔn)確識(shí)別變更前后的源碼信息并完成差異比對(duì)，能正確并快速實(shí)現(xiàn)未變更函數(shù)的自動(dòng)隔離插樁工作。

　　3 結(jié)束語

　　通過分析航空發(fā)動(dòng)機(jī)控制軟件升級(jí)過程，在依賴 cantata 工具進(jìn)行單元測(cè)試回歸時(shí)，存在未變更函數(shù)的測(cè)試腳本需重新人工手動(dòng)隔離插樁，導(dǎo)致時(shí)間和人力耗費(fèi)的問題。提出了一種基于 C#的 cantata 工具二次開發(fā)方法，項(xiàng)目實(shí)踐與分析結(jié)果表明，該方法能準(zhǔn)確識(shí)別變更信息，正確并快速實(shí)現(xiàn)未變更函數(shù)的自動(dòng)隔離插樁。極大提升了基于 cantata 進(jìn)行升級(jí)過程的單元測(cè)試效率，為達(dá)成 DO-178C 中低層需求與高層需求的符合性這一目標(biāo)提供了有力支撐。

　　目前基于 C#的 cantata 工具二次開發(fā)方法已在 3 個(gè)項(xiàng)目的 5 次升級(jí)過程中得到應(yīng)用，結(jié)果均正確可靠。但相較于市面上常見的源碼分析工具( 如 Eclipse CDT 提供的 API) ，本方法尚不支持函數(shù)內(nèi)部語法分析，也未與同類型代碼分析工具進(jìn)行優(yōu)劣比對(duì)分析，可作為后續(xù)研究的一個(gè)方向。