嵌入式軟件測(cè)試與普通軟件測(cè)試的目的一樣，都是為了發(fā)現(xiàn)軟件缺陷，而后修正缺陷以提高軟件的可靠性。嵌入式系統(tǒng)安全性的失效可能會(huì)導(dǎo)致災(zāi)難性后果，即使非安全性失效，由于其應(yīng)用場(chǎng)合特殊也會(huì)導(dǎo)致重大經(jīng)濟(jì)損失。因此，往往嵌入式軟件對(duì)可靠性的要求比普通軟件高。這就要求對(duì)嵌入式軟件進(jìn)行嚴(yán)格的測(cè)試、確認(rèn)和驗(yàn)證，以提高產(chǎn)品的可靠性。 

不過(guò)由于嵌入式軟件的多樣性，基于的操作系統(tǒng)，使用的開(kāi)發(fā)環(huán)境，微控制器都是日益繁多，完整規(guī)范的測(cè)試實(shí)現(xiàn)起來(lái)比較困難，一般企業(yè)都是直接進(jìn)行系統(tǒng)測(cè)試。單元測(cè)試，集成測(cè)試由于測(cè)試執(zhí)行的運(yùn)行環(huán)境建立困難，執(zhí)行效率低下，或者維護(hù)困難就往往被忽略。 

實(shí)際上，只要時(shí)間上做好安排，確立測(cè)試方案，根據(jù)情況建立單元測(cè)試環(huán)境，還是可以順利實(shí)施單元測(cè)試，盡早發(fā)現(xiàn)軟件缺陷，整體上獲得時(shí)效，提高了系統(tǒng)可靠性。文中筆者就根據(jù)多年工作實(shí)踐，將嵌入式軟件單元測(cè)試相關(guān)的一些經(jīng)驗(yàn)與大家分享，同時(shí)拋磚引玉。 

測(cè)試環(huán)境

單元測(cè)試首先需要?jiǎng)討B(tài)運(yùn)行代碼的環(huán)境，嵌入式軟件開(kāi)發(fā)環(huán)境往往是交叉開(kāi)發(fā)環(huán)境，我們希望將代碼移植到開(kāi)發(fā)主機(jī)上運(yùn)行（比如Windows系統(tǒng)），這樣做有幾個(gè)好處：  

1 可以利用高速的主機(jī)提高代碼運(yùn)行效率； 

2 有利于測(cè)試管理，便于測(cè)試用例輸入和形成測(cè)試結(jié)果報(bào)表和維護(hù)； 

3 充分利用Windows系統(tǒng)的測(cè)試工具，實(shí)現(xiàn)自動(dòng)化測(cè)試。 

不過(guò)移植代碼至Windows系統(tǒng)需要將嵌入式軟件的API都移植到Windows，形成虛擬系統(tǒng)接口層，這種方法往往是長(zhǎng)期使用這一嵌入式系統(tǒng)，一勞永逸的長(zhǎng)遠(yuǎn)性方案。 

當(dāng)然還可以通過(guò)購(gòu)買(mǎi)使用一些商用的工具，比如CodeTest，VcTester，使用這些工具在嵌入式系統(tǒng)上直接開(kāi)展單元測(cè)試工作。 

這兩種方案對(duì)于一些中小企業(yè)來(lái)說(shuō)，由于不愿投入這么大人力物力，不能建立長(zhǎng)期有效的開(kāi)發(fā)方案而無(wú)法實(shí)施。對(duì)于這種條件還可以采用一種投入較小的短時(shí)方案，直接在程序中加入測(cè)試代碼，直接在目標(biāo)板上運(yùn)行查看結(jié)果，測(cè)試用例也可以直接在代碼中，或者通過(guò)接口從主機(jī)獲得測(cè)試輸入及輸出測(cè)試結(jié)果。這一方案對(duì)于測(cè)試硬件驅(qū)動(dòng)也是相當(dāng)適用的，比如測(cè)試某設(shè)備讀寫(xiě)做了以下c語(yǔ)言代碼(詳見(jiàn)本刊網(wǎng)站)： 

在實(shí)際平臺(tái)上運(yùn)行該代碼執(zhí)行測(cè)試，這種方法主要用于單元的功能測(cè)試。雖然需要在單元測(cè)試階段編寫(xiě)額外的代碼，但是由上面例子可見(jiàn)，被測(cè)單元接口定義清晰，測(cè)試代碼很容易完成，至于測(cè)試用例的編寫(xiě)是無(wú)法避免的。正式發(fā)布代碼時(shí)通過(guò)條件編譯將這些代碼屏蔽即可。  

測(cè)試策略 

從測(cè)試效果上看，當(dāng)然是花費(fèi)越多的時(shí)間、人力，發(fā)現(xiàn)的問(wèn)題越多，產(chǎn)品的質(zhì)量控制得更好。但實(shí)際上，徹底做好軟件單元測(cè)試幾乎是不可能的，我們需要綜合考慮成本和效率，這是實(shí)際產(chǎn)品開(kāi)發(fā)中經(jīng)常遇到的問(wèn)題，都面對(duì)這樣兩難的境地——上市時(shí)間延誤而沒(méi)有及時(shí)占領(lǐng)市場(chǎng)；或是時(shí)間上搶先，不過(guò)測(cè)試不充分導(dǎo)致出廠的產(chǎn)品質(zhì)量不高。如果測(cè)試時(shí)間不充足，如何在限定時(shí)間內(nèi)更好地完成測(cè)試工作呢？ 

1 我們需要強(qiáng)調(diào)對(duì)隱藏缺陷多的模塊進(jìn)行測(cè)試：?jiǎn)栴}是怎么在測(cè)試計(jì)劃之前確定哪些模塊缺陷多，容易出錯(cuò)呢？根據(jù)經(jīng)驗(yàn)，出錯(cuò)率大的地方往往是以下幾種情況： 

1）時(shí)間壓力大的情況下完成的模塊； 

2）經(jīng)驗(yàn)不足的員工編寫(xiě)的模塊；  

3）前期發(fā)現(xiàn)過(guò)大量bug的模塊；  

4）接口關(guān)系復(fù)雜的模塊；  

5）技術(shù)難度大，處于行業(yè)領(lǐng)先地位的模塊； 

6）從未做過(guò)測(cè)試或缺乏底層測(cè)試的模塊。 

2 對(duì)于重要的模塊加強(qiáng)測(cè)試：“重要”這個(gè)概念在這里往往也不是輕易評(píng)估的，實(shí)際實(shí)施中應(yīng)該需要測(cè)試評(píng)審小組商議決定。這里就根據(jù)經(jīng)驗(yàn)列出以下幾點(diǎn)作為參考： 

1）和安全相關(guān)的模塊，比如產(chǎn)生輻射，高溫，高壓等威脅人身安全的模塊，這是最為關(guān)鍵的一點(diǎn)； 

2）從經(jīng)濟(jì)利益角度考慮，出現(xiàn)故障將造成較大經(jīng)濟(jì)損失的模塊； 

3）從使用角度看，用戶(hù)操作的模塊優(yōu)先級(jí)要高于服務(wù)操作模塊，因?yàn)橛脩?hù)的優(yōu)先級(jí)高于客服人員；  

4）基本功能模塊優(yōu)先級(jí)高于擴(kuò)展功能模塊，試想基本功能都不能使用，那擴(kuò)展功能豈不是空中樓閣； 

5）執(zhí)行概率高的模塊，因?yàn)閳?zhí)行概率高的代碼在運(yùn)行中暴露缺陷的幾率也大。 

編碼注意事項(xiàng) 

以上是從測(cè)試角度討論如何建立單元測(cè)試執(zhí)行環(huán)境的幾種方案和測(cè)試策略的制定，不過(guò)，為單元測(cè)試的實(shí)施奠定堅(jiān)實(shí)的基礎(chǔ)的還是良好的程序設(shè)計(jì)。接下來(lái)從代碼編寫(xiě)角度列舉提高嵌入式軟件的可測(cè)性的幾點(diǎn)經(jīng)驗(yàn)教訓(xùn)： 

1 與硬件設(shè)備操作相關(guān)的需要與硬件操作無(wú)關(guān)的代碼分離，這樣與硬件操作相關(guān)的驅(qū)動(dòng)代碼可以獨(dú)立在目標(biāo)板上測(cè)試，當(dāng)然邏輯簡(jiǎn)單也可不作測(cè)試；大部分與硬件操作無(wú)關(guān)的代碼就容易實(shí)現(xiàn)跨平臺(tái)移植測(cè)試。 

2 中斷響應(yīng)函數(shù)功能盡量簡(jiǎn)單，這是因?yàn)橹袛囗憫?yīng)相對(duì)不好測(cè)試，如果代碼復(fù)雜，也不易定位錯(cuò)誤，因?yàn)楹芏嗟拈_(kāi)發(fā)環(huán)境或操作系統(tǒng)難以支持中斷響應(yīng)函數(shù)的斷點(diǎn)調(diào)試。 

3 系統(tǒng)調(diào)用及操作系統(tǒng)相關(guān)的操作做到與應(yīng)用層分離，可以通過(guò)中間函數(shù)實(shí)現(xiàn)，比如虛擬操作系統(tǒng)函數(shù)，這樣跨平臺(tái)移植測(cè)試的時(shí)候只需將這些中間層函數(shù)修改就可以實(shí)現(xiàn)。 

4對(duì)數(shù)據(jù)類(lèi)型的差異性也可通過(guò)宏定義來(lái)實(shí)現(xiàn)統(tǒng)一，對(duì)于庫(kù)文件的差異也通過(guò)宏定義來(lái)實(shí)現(xiàn)上層代碼的一致性。 

5 使用靜態(tài)代碼檢測(cè)工具，比如PC-Lint，以盡早發(fā)現(xiàn)代碼缺陷。PC-Lint是在代碼產(chǎn)生初期靜態(tài)查找代碼缺陷，更有利用錯(cuò)誤定位和修改，因?yàn)檐浖_(kāi)發(fā)階段越早發(fā)現(xiàn)問(wèn)題，解決問(wèn)題花費(fèi)的代價(jià)越小。因此，一般應(yīng)該是靜態(tài)檢查通過(guò)后再實(shí)施動(dòng)態(tài)測(cè)試。 

嵌入式軟件單元測(cè)試也是基于普通軟件單元測(cè)試的理論，仍需遵守，以上是對(duì)嵌入式軟件單元測(cè)試特別之處的經(jīng)驗(yàn)總結(jié)，希望能對(duì)初涉嵌入式軟件開(kāi)發(fā)的朋友有所幫助，重視軟件質(zhì)量，提高嵌入式系統(tǒng)的可靠性。 

{     
typedef struct _TEST_CASE // 測(cè)試用例結(jié)構(gòu)體     
{     
UINT8* pBuf; //讀寫(xiě)緩沖區(qū)指針     
int len; //讀寫(xiě)數(shù)據(jù)長(zhǎng)度     
STATUS result; // 測(cè)試結(jié)果，OK或ERROR     
} TESTCASE;     
#define TEST_NUM 4 // 測(cè)試用例數(shù)     
UINT8* rBuf;     
TESTCASE testCase[TEST_NUM]={     
{0,DATA_MAX_LEN+1,ERROR}, // DATA_MAX_LEN指允許讀寫(xiě)的***長(zhǎng)度     
{"a",1,OK},     
{"12",2,OK},     
{0,DATA_MAX_LEN,OK}     
};     
for (int i=0;i< TEST_NUM;i++)     
{     
if(write(testCase[i].pBuf,testCase[i].len) != testCase[i].result) // 寫(xiě)測(cè)試     
LOG ("test write failed!");     
if(read(rBuf,testCase[i].len) != testCase[i].result) // 讀測(cè)試     
LOG ("test read failed! ");     
if(bcmp(testCase[i].pBuf,rBuf,testCase[i].len) != 0) // 比較讀寫(xiě)數(shù)據(jù)     
LOG ("compare data failed! ");     
}     
}  

其實(shí)大多數(shù)軟件測(cè)試方法都可以直接或間接地用于嵌入式軟件的測(cè)試，但是由于操作系統(tǒng)的實(shí)時(shí)和嵌入式特性，嵌入式軟件測(cè)試也面臨一些特殊的問(wèn)題。雖然日前已經(jīng)有一些針對(duì)嵌入式軟件的測(cè)試和調(diào)試工具，但是在有些方面仍存在不足，包括許多任務(wù)操作系統(tǒng)的并發(fā)、非侵入式的測(cè)試和凋試、嵌入式系統(tǒng)的軟件抽象等。對(duì)于嵌入式軟件測(cè)試技術(shù)的研究人選測(cè)試工具有待開(kāi)發(fā)，仍須要做很多進(jìn)一步的工作。

【編輯推薦】

1. 嵌入式軟件測(cè)試的十大秘訣
2. 軟件測(cè)試中排錯(cuò)的基本方法
3. 軟件自動(dòng)化測(cè)試在功能測(cè)試中的應(yīng)用
4. 軟件評(píng)測(cè)師：軟件測(cè)試中白盒測(cè)試方面的總結(jié)