規范化嵌入式軟件自測試方法

王 泉

（中國航空西安軟件測評中心，陜西 西安710068）

0 引 言

隨著嵌入式軟件工程化要求的日趨嚴格，嵌入式軟件測試工作日益受到重視，引發了眾多測評機構對其進行研究［1－4］。但在嵌入式軟件自測試方面，由于各單位本身對測試級別和測試類型的要求差異，尚未形成一種完全規范的覆蓋全部測試級別的自測試流程和方法，尤其是在靜態分析和部件測試方面要求和方法各異。限于多數嵌入式型號軟件測試周期較緊的情況，大多采用相對簡單的靜態分析和一次集成的部件測試方法。本文作者旨在提出一種包括文檔審查、靜態分析、代碼審查、動態單元測試、部件測試和配置項測試的規范化自測試方法，使嵌入式軟件自測試階段能及早并盡可能多的發現并消除軟件問題，提高嵌入式軟件質量。

1 嵌入式軟件特點及測試要求

本文從單位嵌入式軟件的開發現行特點出發，建立一種滿足型號自測試要求、級別全面的自測試模型，盡可能在不同階段發現并消除軟件缺陷。某嵌入式軟件包含系統軟件、通信軟件等二十余個軟件配置項，軟件具有以下特點：

（1）軟件文檔編制種類不統一、文檔內容不夠精準：型號總體單位要求所有的軟件相關文檔均要遵循GJB438B文檔編寫要求，但由于本單位軟件配置項眾多，不同的開發人員對軍標的理解、文檔編寫的側重點、編寫粒度均不同，同時部分軟件配置項還包含多個模塊，除軟件配置項應出具的文檔外、各模塊出具的配套文檔種類繁多，類型和數量不統一。

（2）開發環境多樣化：軟件配置項有二十余個，涉及的嵌入式開發環境多樣化，如Tornado2.2、Tornado2.2.1、WorkBench2.6、Xilinx EDK9.1等。

其次，該嵌入式軟件自測試工作含以下測試要求：①軟件需滿足型號編碼規則要求：型號總體單位制訂了軟件編碼規范，要求各開發單位的編碼均要符合該規范要求；②測試級別要求全面：某型號軟件二十余個配置項的關鍵性等級均為B級，必須開展單元級、部件級、配置項級的測試，且單元測試需涵蓋靜態分析、代碼審查、動態單元測試。

針對軟件特點及測試要求，為提高軟件自測試效率及質量，本文提出了一種集軟件文檔審查、靜態分析和編碼規則檢查、代碼審查、動態單元測試、部件測試、配置項測試在內的規范化自測試模型，力求分階段發現軟件問題，提高自測試質量及效率。規范化自測試模型圖見圖1。

圖1 規范化自測試模型

該模型具有以下特點：

測試前期審查嚴格：為提高自測試準確性和高效性，測試方嚴把入口關，首先對軟件文檔進行工程化審查，為滿足定型測評要求，明確了審查范圍為型號總體規定的全套文檔。對于部分配置項存在多個模塊且模塊級需提交的文檔未規定的問題，考慮到軟件研制任務書、軟件需求規格說明、軟件概要設計說明和軟件詳細設計說明文檔的質量與軟件開發及測試質量息息相關，上層文檔存在的錯誤會導致錯誤的不斷傳遞與放大，造成測試過程的代價大幅提升，如圖2所示。故文檔工程化審查人員統一了模塊級別的提交文檔為軟件測試的最小集，即軟件研制任務書、軟件需求規格說明、軟件概要設計、軟件詳細設計；針對文檔編制不夠細致精準、對軍標理解不一致、文檔編寫側重點不一致的特性，給出了上述四類文檔的通用模板；針對這四類文檔進行了多輪重點審查，以保證軟件自測試必需的文檔描述和依據全面、準確、無誤，盡量減少因文檔的不完善造成測試無法正常進行或增加測試迭代的次數。

同時，測試人員對程序是否符合型號編碼規則和是否滿足型號軟件工程化大綱要求等方面進行了靜態分析，最終生成靜態分析報告，詳細報告了軟件不符合編碼規則和圈復雜度、注釋率、行數、扇出數等不符合型號軟件工程化大綱要求的問題，便于開發人員及早對此類問題進行修改。

2 測試關鍵技術

2.1 可定制編碼規則的靜態分析

程序靜態分析是指在不運行代碼的方式下，通過詞法分析、語法分析、控制流分析等技術對程序代碼進行掃描，驗證代碼是否滿足規范性、安全性、可靠性、可維護性等指標的一種代碼分析，作為動態測試的補充在程序運行前盡可能多地發現其中隱含的錯誤，提高程序的可靠性和健壯性。靜態分析作為軟件工程的一個熱點，已有眾多的研究和產品，如Parasoft、LDRA等。

某型號軟件自測試靜態分析需完成三方面工作：一是進行軟件的基本靜態分析、復雜度分析、靜態數據流分析、交叉索引分析、信息流分析和數據對象分析等，消除軟件的大量低級錯誤；二是驗證軟件是否滿足型號工程化大綱中對軟件編碼的代碼行數、注釋率、圈復雜度、模塊扇出數等要求，三是驗證軟件是否滿足型號編碼規范的要求。故本項目必須選擇具有檢查代碼規范性功能的靜態分析工具，同時工具支持對規范的定制和補充。

LDRA TestBed作為常用靜態分析工具之一，滿足上述要求［5］，尤其是其在編碼規則的修改和定制功能恰好能最優滿足本項目要求。測試者使用LDRA TestBed測試工具，對成熟的軟件GJB5369編程規則進行裁減、定制和補充，建立最終編碼規則集，其組成關系如圖3所示 （首先定制92條型號強制規則與TestBed支持GJB5369的所有138條規則中完全相同的規則，然后加入TestBed測試工具根據型號編碼標準定制的若干補充規則，形成最終編碼規則集），通過自動化逐行掃描程序代碼，從中查找是否存在與事先構建好的規則模式相匹配的代碼，如果發現相匹配的代碼，則報告相應錯誤并判斷代碼是否違反所制定的編碼規則，最終以文本報告的方式詳細報告編碼規則，定位代碼中違反編碼規范的地方。

該靜態分析方法無需依賴程序的開發編譯環境，結合了詞法分析、語法分析和語義分析，對軟件進行了全代碼覆蓋的分析，驗證了軟件與編碼規則的符合程度，消除了軟件的大量低級錯誤，且大幅度降低了測試后續階段消除軟件瑕疵的成本。

圖3 最終編碼規則集組成

2.2 基于宿主機的動態單元測試

單元測試主要檢查各程序單元是否正確實現了軟件詳細設計文檔規定的功能、性能、接口和其他設計約束要求，發現函數單元可能存在的錯誤。針對嵌入式軟件的單元測試，各軟件開發單位或測評機構方法各異［6－8］。

動態單元測試主要依據軟件的設計文檔，借助商用軟件測試工具，利用等價類劃分和邊界值分析技術，設計完全覆蓋軟件設計需求的單元測試用例，對軟件的每個單元進行測試，根據測試用例執行結果是否滿足預期及軟件結構覆蓋率情況，發現類似設計遺漏、功能未實現、冗余代碼等軟件缺陷。

目前專業的測試工具很多，如Compuware公司的Dev－Partner、Rational公司的Purify、C＋＋ Test、CuttleITE和 Attol、IBM Rational Test RealTime［9］等。本文仍使用TestBed／Tbrun專業測試工具。該工具具有以下兩大優勢［10］：

（1）實時顯示測試覆蓋率，提供調整測試方案和優化軟件測試的必要信息；

（2）自動生成單元／模塊測試驅動、樁模塊，提高軟件測試效率與可靠性；

嵌入式軟件測試環境分為基于目標機的測試環境和基于宿主機的測試環境。對于開發環境多樣化的嵌入式軟件，需選擇基于宿主機的單元測試環境，重點對程序邏輯進行測試、盡量消除與硬件的相關性。在宿主機環境中的測試消耗時間通常相對較少，用調試工具可以很快地完成調試和輔助完成測試任務，而與定時、時序、中斷、硬件接口等相關的測試重點在配置項測試驗證。

使用TestBed／Tbrun的基于宿主機的動態單元測試流程如圖4所示。

圖4 基于宿主機環境的動態單元測試流程

測試人員設計好測試用例，完成代碼的靜態分析、代碼插裝和動態分析后，使用宿主機環境對測試用例及插裝后的代碼進行編譯鏈接和執行，生成測試結果文件和代碼覆蓋率文件，最終再經過TestBed形成單元級別的測試報告文件。宿主機環境應盡可能與開發環境相同，主流的開發環境如Tornado2.0、Tornado2.2、WorkBench均可通過TestBed自帶的測試配置工具Tbconfig完成不同開發環境的配置，某些特殊的開發環境在不影響單元邏輯測試要求和測試結果的前提下，將其移植到可配置的開發環境下完成單元測試。借助TestBed測試工具，測試人員可著重設計測試用例、提高測試用例質量，從而更有效的發現軟件缺陷。

2.3 部分增量的部件測試

部件測試的目的是把已通過單元測試的單元集合起來，構造一個在概要設計中所描述的程序部件，通過測試發現與接口有關的程序結構、模塊調用、模塊接口方面的問題。部件測試策略一般分為增量式和非增量式兩種［11］，二者的優缺點對比如表1所示。

表1 增量式與非增量式部件測試策略對比

對比表明，增量式部件具有較好的測試效果，但相對測試過程較復雜，耗時較長。以往的針對嵌入式軟件的集成測試雖有一定的研究［12，13］，但尚未形成統一規范的測試方法。針對嵌入式軟件最底層調用的大量函數為硬件讀寫、訪問、打印語句等系統函數的特點，本文采取了一種部分增量的部件測試方法，其具體策略為：首先分析每個部件的入口函數與所有調用函數之間的調用層次關系；然后將調用層次關系樹中從最底層葉子節點開始向上延伸三層（含最底層葉子節點）的所有函數單元一次組裝進行子部件測試，然后采用自底向上的方法逐層向上組裝直至到達整個部件的根結點的下一層，若從最底層葉子節點到根結點的下一層少于3層，則按實際層數一次組裝進行測試；對整個模塊進行部件測試時，如果各子部件之間有數據依賴關系，則按照部件真實調用子部件的順序，采用子部件增量遞加的方法逐個集成各子部件。圖5給出了根據某部件層次調用關系劃分的子部件和增量遞加部件的示例圖，其中A調用B、C、D的先后順序為調用B→調用C→調用D。

圖5 基于部分增量方法的部件劃分

使用部分增量的部件測試方法首先由于將底三層函數單元一次集成，因底層程序調用關系較簡單、不易發生錯誤，選用該方法可簡化部件測試過程、減少部分測試時間；其次整體部件的第一、二層采用子部件增量遞加的方法，便于發現部件按順序依次調用時隱藏的影響程序結構或接口的錯誤。

2.4 基于故障注入的配置項測試

配置項測試依據軟件需求規格文檔進行測試需求分析、測試設計、測試實現和測試執行，完成軟件的功能、性能、接口、強度、余量等測試，并重點關注了軟件在異常狀態和邊界狀態下的響應和處理，以及用于提高軟件可靠性和安全性的措施的有效性。針對嵌入式軟件特性，配置項測試主要采用了故障注入技術：

（1）硬件故障：通過下電、拔除等方式注入部分硬件模塊故障，驗證軟件的相關自檢及處理是否正確；

（2）程序插裝法模擬注入硬件故障：對于CPU、NVRAM等硬件設備的計算故障或設備故障，由于無法直接造成硬件故障，而相關的故障檢測及上報又為嵌入式軟件的重要功能，故采用程序插裝方法模擬注入此類故障，驗證軟件的故障檢測及上報功能的正確性；

（3）數據故障：某型號軟件配置項數量大，涉及的外部接口種類和數量眾多，在接口測試中除正常接口通信驗證外，重點通過模擬接口數據的包頭、校驗位、數據長度等數據故障來驗證軟件的接口處理是否正確。

3 測試效果分析

由于測試前期文檔工程化審查、編碼規則符合性、靜態分析的有效開展，提高了文檔編制的準確性，細化了需求顆粒度，便于配置項測試的開展，極大減少了后期測試工作時與開發方的冗余溝通時間，大幅提高了測試效率。傳統自測試流程與本文自測試流程的測試各項工作比例對比見圖6。

由于測試過程涵蓋了靜態分析、代碼審查、動態單元測試、部件測試、配置項測試等多個測試級別及其不同測試方法，便于在不同的級別測試中發現不同的軟件缺陷，不同階段發現軟件問題數目的比例圖見圖7。

由圖7可看出，大量的不符合編程規范或程序低級錯誤均在靜態分析或代碼審查中發現，動態單元測試、部件測試及配置項測試的問題缺陷比例已相對較小，符合測試盡可能早的發現問題的初衷。

圖6 傳統自測試流程與本文自測試流程各項工作比例對比

圖7 不同測試階段發現軟件缺陷比例

4 結束語

某型號項目自測試工作采用規范化的流程與適當的方法，有效發現了軟件缺陷，提高了軟件質量。在測試過程中，本文作者針對測試工作中仍存在的可改進部分及今后的型號軟件自測試工作如何更有效的開展進行了深入的思考和總結，主要包括以下幾方面內容：

由于不同型號編碼規則不完全相同，目前任何成熟的軟件靜態分析工具都無法提供能夠包含全部編碼規則的編碼規則全集，如何進一步擴展靜態分析工具的功能使之能定制出可不斷添加新規則的通用編碼規則集，并獲得軍用軟件權威部門的認可，仍是軟件靜態分析拭待解決的問題。

本文中基于宿主機的動態單元環境可對主流的嵌入式軟件開發環境進行相關測試配置，但隨著嵌入式軟件計算機語言的種類增多，如何開發出適用各種開發環境的通用單元測試宿主機環境，是單元測試研究的重要方向。

測試前期軟件文檔工程化審查工作的有效開展，大幅提升了測試效率，后續的型號軟件開發與研制過程中，一方面應在項目開展早期及時開展需求評審，使測試人員真正有效的參與需求評審，減少文檔錯誤造成開發過程中錯誤的不斷傳遞放大，另一方面應切實有效的做好軟件文檔工程化審查工作，提高文檔編制的準確性和一致性，提高測試效率。

［1］LV Quanhe.Embedded software measurement ［J］.Software Guide，2010 （9）：40－41 （in Chinese）.［呂全和.嵌入式軟件測試 ［J］.軟件導刊，2010 （9）：40－41.］

［2］QIN Chunyan，YAO Zhuting.Study on embedded system software measurement ［J］.Mechanical Management and Development，2008，23 （3）：183－184 （in Chinese）.［秦春燕，姚竹.嵌入式系統軟件測試的研究 ［J］.機械管理開發，2008，23（3）：183－184.］

［3］ZHAO Xiaolan.Analysis of standard software test process ［J］.Aerospace Control，2010 （1）：98－100［趙曉嵐.規范化軟件測試過程淺析 ［J］.航天控制，2010 （1）：98－100.］

［4］HU Rongxiang.Embedded software testing ［J］.CHINA Computer＆Communicaton，2010 （7）：79 （in Chinese）.［胡 榮祥.試論嵌入式軟件測試 ［J］.信息與電腦，2010（7）：79.］

［5］JI Peigang.Research of program static analysis ［D］.Lanzhou：Lanzhou University，2006 （in Chinese）.［冀佩剛.程序靜態分析研究 ［D］.蘭州：蘭州大學，2006.］

［6］HU Dan，DU Xinhua.Methods and practice of embedded software unit testing on a target machine ［J］.Electronic Measurement Technology，2006 （2）：33－35 （in Chinese）.［胡丹，杜新華.基于目標機的嵌入式軟件單元測試 ［J］.電子測量技術，2006 （2）：33－35.］

［7］CAO Xiaoyong，LIU Xi.Application of coverage testing tool in embedded software testing ［J］.Electronics Quality，2009（12）：21－23 （in Chinese）.［曹曉勇，劉希.嵌入式軟件覆蓋測試的研究與應用 ［J］.電子質量，2009 （12）：21－23.］

［8］CHEN Lirong，XIONG Guangze.The covering test of embedded software ［J］.Microcontroller ＆ Embedded System，2007（7）：8－11 （in Chinese）.［陳麗蓉，熊光澤.嵌入式軟件的覆蓋測試 ［J］.單片機與嵌入式系統應用，2007 （7）：8－11.］

［9］JIANG Long，WANG Dongxing.Using IBM rational test Real－Time to realize embedded software test ［J］.Computer Study，2010 （3）：139－140 （in Chinese）.［姜龍，王冬星.使用IBM Rational Test Realtime進行嵌入式軟件測試 ［J］.電腦學習，2010 （3）：139－140.］

［10］WANG Yu，HE Yongjun，Testbed／Tbrun used in embedded software unit testing ［J］.Acoustics and Electronics Engineering，2006 （4）：36－37 （in Chinese）.［王煜，何永軍.Testbed／Tbrun應用于嵌入式軟件單元測試 ［J］.聲學與電子工程，2006 （4）：36－37.］

［11］The Art of software TESTING ［M］.2nd ed.Beijing：China Machine Press，2006 （in Chinese）.［機械工業出版社.軟件測試的藝術 ［M］.北京：機械工業出版社，2006.］

［12］ZHANG Yanmei，JIANG Shujuan.An approach for class integration testing based on dynamic dependency relations ［J］.Chinese Journal of Computers，2011，34 （6）：1075－1089 （in Chinese）.［張艷梅，姜淑娟.一種基于動態依賴關系的類集成測試方法 ［J］.計算機學報，2011，34 （6）：1075－1089.］

［13］GAO Jing，LAN Yuqing.Approach to choose integration testing combination for foundational software platform ［J］.Journal of Beijing University of Aeronautics and Astronautics，2010（3）：16－20 （in Chinese）.［高靜，蘭雨晴.基礎軟件平臺集成測試組合選擇方法 ［J］.北京航空航天大學學報，2010（3）：16－20.］