一種基于C#的Cantata工具變更過程改進方法

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

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

　　關鍵詞: DO-178C; 嵌入式系統; 單元測試; C#

　　航空發動機控制軟件( 簡稱控制軟件) 是一種嵌入式軟件，根據《民航機載軟件適航標準 DO-178》的規定，屬于安全關鍵軟件[1]。為滿足適航認證，控制軟件必須要達成 DO-178C 提出的各項指標要求。其中，針對低層需求與高層需求的符合性這一目標，執行單元測試并建立追溯關系是一種常見的實現手段。

　　針對嵌入式軟件開發環境和運行環境不一致的現象，單元測試具有可在宿主機環境下執行、能提早測試介入時機且最大程度降低測試活動對目標環境依賴性等優點; 然而，單元測試也存在著的測試驅動難編寫、測試程序難管理、測試結果難界定等問題。對此，市場上出現了一批如 Cppunit、Jnuit 等開源測試框架[2]和 cantata、TestBed、Qt、TBrun 等單元測試軟件[3 - 5]。

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

　　然而，由于 cantata 工具在執行單元測試活動時所有過程均需基于服務器執行，而且工具對被測單元的隔離插樁過程與被測單元所屬文件有直接關聯。這就導致軟件升級時，若被測單元所屬文件發生變化，即使被測單元未發生更改，原有的單元測試用例也需要重新隔離插樁才能通過。由于隔離插樁過程需要人工操作，另外受到服務器響應和處理時間長的制約，在實際執行控制軟的 cantata 單元測試回歸時，需要耗費大量時間和人力來更新未變更函數的隔離插樁。

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

　　1 基于 C#的 cantata 變更過程改進方法

　　1. 1 整體方案分析

　　cantata 工具執行單元測試過程主要由源代碼隔離插樁、測試腳本生成、可執行文件構建和運行這 4 個活動組成，各活動均由服務器執行并將相應結果返回給用戶，具體如圖 1 所示。

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

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

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

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

　　1. 2 cantata 插樁規則提煉

　　通過分析 cantata 單元測試結果，對 cantata 插樁規格進行了提煉。圖 3 展示了某待測試文件 XX. c 的文件結構，包含有全局變量 GLB _ a、函數 FuncX( ) 和 FuncY( ) ，其中 FuncY( ) 調用了一個外部函數 UT_a ( ) 。

　　當 FuncX( ) 作為被測函數時，cantata 工具對 test_ FuncX. c、test. mk 和 ipg. cop 文件插樁規則如下。

　　test_FuncX. c 中，待隔離函數 FuncY( ) 的插樁規則如下函數隔離規則: / * 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 量的隔離規則: / * 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 中，待隔離函數 funcY( ) 和 UT_a( ) 的插樁規則: “- - sm: - - isolate: FunY( ) ” “- - sm: - - isolate: UT_a( ) #FunY( ) ” ④ ipg. cop 中，全局變量 GLB_a 的隔離規則: “- - sm: - - access_variable: ”XX. c”: GLB_a”

　　1. 3 二次開發方法設計

　　基于 C#進行 cantata 工具二次開發時，主要難點在于源代碼分析和變更差異比對。對此，以文件為單位，設計了文件信息的數據結構，具體的文件信息類圖如圖 4 所示。數據結構通過對頭文件引用、宏、數據結構、全局變量、函數聲明、函數等信息進行分類存儲，實現變更差異的快速識別和比對。

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

　　源碼規格化后，按照各數據結構類型特點設計相應的正則表達式，依次提取頭文件引用、宏定義、基本數據類型、特殊數據類型、函數聲明、全局變量、函數信息，完成源碼的文件數據結構提取。其中特殊數據類型特指枚舉、位域結構體和結構體類型，另外考慮到同義宏的存在，設計了遞歸方法執行同義宏的分類和存儲。

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

　　2 項目應用實踐與結果分析

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

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

　　此次變更前共計有 436 個單元測試腳本，變更前后共影響到 123 個測試腳本的關聯修改，修改量占比 28. 2% 。以其中一個關聯修改的測試腳本為例，進行分析:

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

　　完成 81 個變更函數對應的測試腳本修改后，在 Score 環境下批跑所有的 444 個測試腳本，導出結果如圖 8 所示。結果顯示所有自動隔離插樁的函數均通過，其中 11 個未通過的函數均為特殊實現原因導致覆蓋率無法滿足的函數，與自動隔離插樁過程無關。

　　基于 cantata 服務器進行人工手動隔離插樁時，平均每個測試腳本需花費大約 10 min。使用二次開發方法后，平均只需要不到 3 min 即可完成所有未變更函數測試腳本隔離插樁工作。以本次 123 個測試腳本的關聯修改為例，二次開發方法可有效節省約 20. 45 人時，測試工作效率有極大提升。

　　綜上結果證明，基于 C#的 cantata 工具二次開發方法可準確識別變更前后的源碼信息并完成差異比對，能正確并快速實現未變更函數的自動隔離插樁工作。

　　3 結束語

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

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