規(guī)范化嵌入式軟件自測(cè)試方法

王 泉

（中國(guó)航空西安軟件測(cè)評(píng)中心，陜西 西安710068）

0 引 言

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

1 嵌入式軟件特點(diǎn)及測(cè)試要求

本文從單位嵌入式軟件的開(kāi)發(fā)現(xiàn)行特點(diǎn)出發(fā)，建立一種滿足型號(hào)自測(cè)試要求、級(jí)別全面的自測(cè)試模型，盡可能在不同階段發(fā)現(xiàn)并消除軟件缺陷。某嵌入式軟件包含系統(tǒng)軟件、通信軟件等二十余個(gè)軟件配置項(xiàng)，軟件具有以下特點(diǎn)：

（1）軟件文檔編制種類不統(tǒng)一、文檔內(nèi)容不夠精準(zhǔn)：型號(hào)總體單位要求所有的軟件相關(guān)文檔均要遵循GJB438B文檔編寫(xiě)要求，但由于本單位軟件配置項(xiàng)眾多，不同的開(kāi)發(fā)人員對(duì)軍標(biāo)的理解、文檔編寫(xiě)的側(cè)重點(diǎn)、編寫(xiě)粒度均不同，同時(shí)部分軟件配置項(xiàng)還包含多個(gè)模塊，除軟件配置項(xiàng)應(yīng)出具的文檔外、各模塊出具的配套文檔種類繁多，類型和數(shù)量不統(tǒng)一。

（2）開(kāi)發(fā)環(huán)境多樣化：軟件配置項(xiàng)有二十余個(gè)，涉及的嵌入式開(kāi)發(fā)環(huán)境多樣化，如Tornado2.2、Tornado2.2.1、WorkBench2.6、Xilinx EDK9.1等。

其次，該嵌入式軟件自測(cè)試工作含以下測(cè)試要求：①軟件需滿足型號(hào)編碼規(guī)則要求：型號(hào)總體單位制訂了軟件編碼規(guī)范，要求各開(kāi)發(fā)單位的編碼均要符合該規(guī)范要求；②測(cè)試級(jí)別要求全面：某型號(hào)軟件二十余個(gè)配置項(xiàng)的關(guān)鍵性等級(jí)均為B級(jí)，必須開(kāi)展單元級(jí)、部件級(jí)、配置項(xiàng)級(jí)的測(cè)試，且單元測(cè)試需涵蓋靜態(tài)分析、代碼審查、動(dòng)態(tài)單元測(cè)試。

針對(duì)軟件特點(diǎn)及測(cè)試要求，為提高軟件自測(cè)試效率及質(zhì)量，本文提出了一種集軟件文檔審查、靜態(tài)分析和編碼規(guī)則檢查、代碼審查、動(dòng)態(tài)單元測(cè)試、部件測(cè)試、配置項(xiàng)測(cè)試在內(nèi)的規(guī)范化自測(cè)試模型，力求分階段發(fā)現(xiàn)軟件問(wèn)題，提高自測(cè)試質(zhì)量及效率。規(guī)范化自測(cè)試模型圖見(jiàn)圖1。

圖1 規(guī)范化自測(cè)試模型

該模型具有以下特點(diǎn)：

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

同時(shí)，測(cè)試人員對(duì)程序是否符合型號(hào)編碼規(guī)則和是否滿足型號(hào)軟件工程化大綱要求等方面進(jìn)行了靜態(tài)分析，最終生成靜態(tài)分析報(bào)告，詳細(xì)報(bào)告了軟件不符合編碼規(guī)則和圈復(fù)雜度、注釋率、行數(shù)、扇出數(shù)等不符合型號(hào)軟件工程化大綱要求的問(wèn)題，便于開(kāi)發(fā)人員及早對(duì)此類問(wèn)題進(jìn)行修改。

2 測(cè)試關(guān)鍵技術(shù)

2.1 可定制編碼規(guī)則的靜態(tài)分析

程序靜態(tài)分析是指在不運(yùn)行代碼的方式下，通過(guò)詞法分析、語(yǔ)法分析、控制流分析等技術(shù)對(duì)程序代碼進(jìn)行掃描，驗(yàn)證代碼是否滿足規(guī)范性、安全性、可靠性、可維護(hù)性等指標(biāo)的一種代碼分析，作為動(dòng)態(tài)測(cè)試的補(bǔ)充在程序運(yùn)行前盡可能多地發(fā)現(xiàn)其中隱含的錯(cuò)誤，提高程序的可靠性和健壯性。靜態(tài)分析作為軟件工程的一個(gè)熱點(diǎn)，已有眾多的研究和產(chǎn)品，如Parasoft、LDRA等。

某型號(hào)軟件自測(cè)試靜態(tài)分析需完成三方面工作：一是進(jìn)行軟件的基本靜態(tài)分析、復(fù)雜度分析、靜態(tài)數(shù)據(jù)流分析、交叉索引分析、信息流分析和數(shù)據(jù)對(duì)象分析等，消除軟件的大量低級(jí)錯(cuò)誤；二是驗(yàn)證軟件是否滿足型號(hào)工程化大綱中對(duì)軟件編碼的代碼行數(shù)、注釋率、圈復(fù)雜度、模塊扇出數(shù)等要求，三是驗(yàn)證軟件是否滿足型號(hào)編碼規(guī)范的要求。故本項(xiàng)目必須選擇具有檢查代碼規(guī)范性功能的靜態(tài)分析工具，同時(shí)工具支持對(duì)規(guī)范的定制和補(bǔ)充。

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

該靜態(tài)分析方法無(wú)需依賴程序的開(kāi)發(fā)編譯環(huán)境，結(jié)合了詞法分析、語(yǔ)法分析和語(yǔ)義分析，對(duì)軟件進(jìn)行了全代碼覆蓋的分析，驗(yàn)證了軟件與編碼規(guī)則的符合程度，消除了軟件的大量低級(jí)錯(cuò)誤，且大幅度降低了測(cè)試后續(xù)階段消除軟件瑕疵的成本。

圖3 最終編碼規(guī)則集組成

2.2 基于宿主機(jī)的動(dòng)態(tài)單元測(cè)試

單元測(cè)試主要檢查各程序單元是否正確實(shí)現(xiàn)了軟件詳細(xì)設(shè)計(jì)文檔規(guī)定的功能、性能、接口和其他設(shè)計(jì)約束要求，發(fā)現(xiàn)函數(shù)單元可能存在的錯(cuò)誤。針對(duì)嵌入式軟件的單元測(cè)試，各軟件開(kāi)發(fā)單位或測(cè)評(píng)機(jī)構(gòu)方法各異［6－8］。

動(dòng)態(tài)單元測(cè)試主要依據(jù)軟件的設(shè)計(jì)文檔，借助商用軟件測(cè)試工具，利用等價(jià)類劃分和邊界值分析技術(shù)，設(shè)計(jì)完全覆蓋軟件設(shè)計(jì)需求的單元測(cè)試用例，對(duì)軟件的每個(gè)單元進(jìn)行測(cè)試，根據(jù)測(cè)試用例執(zhí)行結(jié)果是否滿足預(yù)期及軟件結(jié)構(gòu)覆蓋率情況，發(fā)現(xiàn)類似設(shè)計(jì)遺漏、功能未實(shí)現(xiàn)、冗余代碼等軟件缺陷。

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

（1）實(shí)時(shí)顯示測(cè)試覆蓋率，提供調(diào)整測(cè)試方案和優(yōu)化軟件測(cè)試的必要信息；

（2）自動(dòng)生成單元／模塊測(cè)試驅(qū)動(dòng)、樁模塊，提高軟件測(cè)試效率與可靠性；

嵌入式軟件測(cè)試環(huán)境分為基于目標(biāo)機(jī)的測(cè)試環(huán)境和基于宿主機(jī)的測(cè)試環(huán)境。對(duì)于開(kāi)發(fā)環(huán)境多樣化的嵌入式軟件，需選擇基于宿主機(jī)的單元測(cè)試環(huán)境，重點(diǎn)對(duì)程序邏輯進(jìn)行測(cè)試、盡量消除與硬件的相關(guān)性。在宿主機(jī)環(huán)境中的測(cè)試消耗時(shí)間通常相對(duì)較少，用調(diào)試工具可以很快地完成調(diào)試和輔助完成測(cè)試任務(wù)，而與定時(shí)、時(shí)序、中斷、硬件接口等相關(guān)的測(cè)試重點(diǎn)在配置項(xiàng)測(cè)試驗(yàn)證。

使用TestBed／Tbrun的基于宿主機(jī)的動(dòng)態(tài)單元測(cè)試流程如圖4所示。

圖4 基于宿主機(jī)環(huán)境的動(dòng)態(tài)單元測(cè)試流程

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

2.3 部分增量的部件測(cè)試

部件測(cè)試的目的是把已通過(guò)單元測(cè)試的單元集合起來(lái)，構(gòu)造一個(gè)在概要設(shè)計(jì)中所描述的程序部件，通過(guò)測(cè)試發(fā)現(xiàn)與接口有關(guān)的程序結(jié)構(gòu)、模塊調(diào)用、模塊接口方面的問(wèn)題。部件測(cè)試策略一般分為增量式和非增量式兩種［11］，二者的優(yōu)缺點(diǎn)對(duì)比如表1所示。

表1 增量式與非增量式部件測(cè)試策略對(duì)比

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

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

使用部分增量的部件測(cè)試方法首先由于將底三層函數(shù)單元一次集成，因底層程序調(diào)用關(guān)系較簡(jiǎn)單、不易發(fā)生錯(cuò)誤，選用該方法可簡(jiǎn)化部件測(cè)試過(guò)程、減少部分測(cè)試時(shí)間；其次整體部件的第一、二層采用子部件增量遞加的方法，便于發(fā)現(xiàn)部件按順序依次調(diào)用時(shí)隱藏的影響程序結(jié)構(gòu)或接口的錯(cuò)誤。

2.4 基于故障注入的配置項(xiàng)測(cè)試

配置項(xiàng)測(cè)試依據(jù)軟件需求規(guī)格文檔進(jìn)行測(cè)試需求分析、測(cè)試設(shè)計(jì)、測(cè)試實(shí)現(xiàn)和測(cè)試執(zhí)行，完成軟件的功能、性能、接口、強(qiáng)度、余量等測(cè)試，并重點(diǎn)關(guān)注了軟件在異常狀態(tài)和邊界狀態(tài)下的響應(yīng)和處理，以及用于提高軟件可靠性和安全性的措施的有效性。針對(duì)嵌入式軟件特性，配置項(xiàng)測(cè)試主要采用了故障注入技術(shù)：

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

（2）程序插裝法模擬注入硬件故障：對(duì)于CPU、NVRAM等硬件設(shè)備的計(jì)算故障或設(shè)備故障，由于無(wú)法直接造成硬件故障，而相關(guān)的故障檢測(cè)及上報(bào)又為嵌入式軟件的重要功能，故采用程序插裝方法模擬注入此類故障，驗(yàn)證軟件的故障檢測(cè)及上報(bào)功能的正確性；

（3）數(shù)據(jù)故障：某型號(hào)軟件配置項(xiàng)數(shù)量大，涉及的外部接口種類和數(shù)量眾多，在接口測(cè)試中除正常接口通信驗(yàn)證外，重點(diǎn)通過(guò)模擬接口數(shù)據(jù)的包頭、校驗(yàn)位、數(shù)據(jù)長(zhǎng)度等數(shù)據(jù)故障來(lái)驗(yàn)證軟件的接口處理是否正確。

3 測(cè)試效果分析

由于測(cè)試前期文檔工程化審查、編碼規(guī)則符合性、靜態(tài)分析的有效開(kāi)展，提高了文檔編制的準(zhǔn)確性，細(xì)化了需求顆粒度，便于配置項(xiàng)測(cè)試的開(kāi)展，極大減少了后期測(cè)試工作時(shí)與開(kāi)發(fā)方的冗余溝通時(shí)間，大幅提高了測(cè)試效率。傳統(tǒng)自測(cè)試流程與本文自測(cè)試流程的測(cè)試各項(xiàng)工作比例對(duì)比見(jiàn)圖6。

由于測(cè)試過(guò)程涵蓋了靜態(tài)分析、代碼審查、動(dòng)態(tài)單元測(cè)試、部件測(cè)試、配置項(xiàng)測(cè)試等多個(gè)測(cè)試級(jí)別及其不同測(cè)試方法，便于在不同的級(jí)別測(cè)試中發(fā)現(xiàn)不同的軟件缺陷，不同階段發(fā)現(xiàn)軟件問(wèn)題數(shù)目的比例圖見(jiàn)圖7。

由圖7可看出，大量的不符合編程規(guī)范或程序低級(jí)錯(cuò)誤均在靜態(tài)分析或代碼審查中發(fā)現(xiàn)，動(dòng)態(tài)單元測(cè)試、部件測(cè)試及配置項(xiàng)測(cè)試的問(wèn)題缺陷比例已相對(duì)較小，符合測(cè)試盡可能早的發(fā)現(xiàn)問(wèn)題的初衷。

圖6 傳統(tǒng)自測(cè)試流程與本文自測(cè)試流程各項(xiàng)工作比例對(duì)比

圖7 不同測(cè)試階段發(fā)現(xiàn)軟件缺陷比例

4 結(jié)束語(yǔ)

某型號(hào)項(xiàng)目自測(cè)試工作采用規(guī)范化的流程與適當(dāng)?shù)姆椒?，有效發(fā)現(xiàn)了軟件缺陷，提高了軟件質(zhì)量。在測(cè)試過(guò)程中，本文作者針對(duì)測(cè)試工作中仍存在的可改進(jìn)部分及今后的型號(hào)軟件自測(cè)試工作如何更有效的開(kāi)展進(jìn)行了深入的思考和總結(jié)，主要包括以下幾方面內(nèi)容：

由于不同型號(hào)編碼規(guī)則不完全相同，目前任何成熟的軟件靜態(tài)分析工具都無(wú)法提供能夠包含全部編碼規(guī)則的編碼規(guī)則全集，如何進(jìn)一步擴(kuò)展靜態(tài)分析工具的功能使之能定制出可不斷添加新規(guī)則的通用編碼規(guī)則集，并獲得軍用軟件權(quán)威部門的認(rèn)可，仍是軟件靜態(tài)分析拭待解決的問(wèn)題。

本文中基于宿主機(jī)的動(dòng)態(tài)單元環(huán)境可對(duì)主流的嵌入式軟件開(kāi)發(fā)環(huán)境進(jìn)行相關(guān)測(cè)試配置，但隨著嵌入式軟件計(jì)算機(jī)語(yǔ)言的種類增多，如何開(kāi)發(fā)出適用各種開(kāi)發(fā)環(huán)境的通用單元測(cè)試宿主機(jī)環(huán)境，是單元測(cè)試研究的重要方向。

測(cè)試前期軟件文檔工程化審查工作的有效開(kāi)展，大幅提升了測(cè)試效率，后續(xù)的型號(hào)軟件開(kāi)發(fā)與研制過(guò)程中，一方面應(yīng)在項(xiàng)目開(kāi)展早期及時(shí)開(kāi)展需求評(píng)審，使測(cè)試人員真正有效的參與需求評(píng)審，減少文檔錯(cuò)誤造成開(kāi)發(fā)過(guò)程中錯(cuò)誤的不斷傳遞放大，另一方面應(yīng)切實(shí)有效的做好軟件文檔工程化審查工作，提高文檔編制的準(zhǔn)確性和一致性，提高測(cè)試效率。

［1］LV Quanhe.Embedded software measurement ［J］.Software Guide，2010 （9）：40－41 （in Chinese）.［呂全和.嵌入式軟件測(cè)試 ［J］.軟件導(dǎo)刊，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）.［秦春燕，姚竹.嵌入式系統(tǒng)軟件測(cè)試的研究 ［J］.機(jī)械管理開(kāi)發(fā)，2008，23（3）：183－184.］

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

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

［5］JI Peigang.Research of program static analysis ［D］.Lanzhou：Lanzhou University，2006 （in Chinese）.［冀佩剛.程序靜態(tài)分析研究 ［D］.蘭州：蘭州大學(xué)，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）.［胡丹，杜新華.基于目標(biāo)機(jī)的嵌入式軟件單元測(cè)試 ［J］.電子測(cè)量技術(shù)，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）.［曹曉勇，劉希.嵌入式軟件覆蓋測(cè)試的研究與應(yīng)用 ［J］.電子質(zhì)量，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）.［陳麗蓉，熊光澤.嵌入式軟件的覆蓋測(cè)試 ［J］.單片機(jī)與嵌入式系統(tǒng)應(yīng)用，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ìn)行嵌入式軟件測(cè)試 ［J］.電腦學(xué)習(xí)，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應(yīng)用于嵌入式軟件單元測(cè)試 ［J］.聲學(xué)與電子工程，2006 （4）：36－37.］

［11］The Art of software TESTING ［M］.2nd ed.Beijing：China Machine Press，2006 （in Chinese）.［機(jī)械工業(yè)出版社.軟件測(cè)試的藝術(shù) ［M］.北京：機(jī)械工業(yè)出版社，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）.［張艷梅，姜淑娟.一種基于動(dòng)態(tài)依賴關(guān)系的類集成測(cè)試方法 ［J］.計(jì)算機(jī)學(xué)報(bào)，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）.［高靜，蘭雨晴.基礎(chǔ)軟件平臺(tái)集成測(cè)試組合選擇方法 ［J］.北京航空航天大學(xué)學(xué)報(bào)，2010（3）：16－20.］