淺談嵌入式軟件測試

1.功能測試

功能測試一般稱為黑匣子測試，因為在編寫功能測試的測試?yán)虝r并沒有涉及實際的代碼。換句話說，沒有觸及到“匣子內(nèi)”。嵌入式系統(tǒng)有輸入和輸出，并在輸入和輸出之間執(zhí)行某些算法。黑匣子測試是根據(jù)對哪些輸入應(yīng)該是可接受的以及這些輸入應(yīng)與輸出有何種關(guān)系的了解來進(jìn)行的。黑匣子測試完全不了解輸入與輸出之間的算法是如何實現(xiàn)的。黑匣子測試的示例包括：

壓力測試：有意使輸入通道、內(nèi)存緩沖器、磁盤控制器、存儲器管理系統(tǒng)等過載的測試

邊界值測試：表示特定范圍內(nèi)的“邊界”的輸入(例如，對于整數(shù)輸入而言，是最大和最小整數(shù)以及-1、0、+1);以及應(yīng)使輸出在輸出范圍的類似邊界出現(xiàn)跨變的輸入值。

異常測試：能觸發(fā)故障模式或異常模式的測試。

錯誤推測：根據(jù)以前的軟件測試經(jīng)驗或者從測試類似程序獲得的經(jīng)驗進(jìn)行的測試。

隨機(jī)測試：通常，這是效率最低的一種測試方法，但卻仍然廣泛用于評估用戶界面代碼的魯棒性。

性能測試：由于性能預(yù)期是產(chǎn)品要求的一部分，因此性能分析屬于功能測試的范疇。

由于黑匣子測試僅取決于程序要求及其I/O行為，因此一旦完成功能要求的編寫，即可開發(fā)這類測試。這使得黑匣子測試?yán)痰拈_發(fā)可以與余下的系統(tǒng)設(shè)計同步進(jìn)行。

與所有測試一樣，功能測試應(yīng)被設(shè)計得具有破壞性，也即，要試圖證明程序無法工作。這包括使輸入通道過載、隨意地敲打鍵盤，以及故意地做程序員認(rèn)為會破壞其程序的所有事情。

作為研發(fā)產(chǎn)品經(jīng)理，這是我的主要測試方法之一。如果產(chǎn)品在經(jīng)過40個小時的極限測試(abuse testing)后，并沒發(fā)現(xiàn)任何嚴(yán)重或者致命的缺陷，那么就可以發(fā)布這個產(chǎn)品了。如果找到了一個重大的缺陷，那么修正這個缺陷后，還必須重復(fù)前面的測試步驟。

2.覆蓋測試

功能測試的缺點是其很少執(zhí)行全部代碼。覆蓋測試則試圖規(guī)避這個缺點，它采用的方法是(理想地)確保每一條代碼語句、判定點或者判定路徑都至少被測試一次。覆蓋測試還可以顯示已經(jīng)訪問的數(shù)據(jù)空間大小。

覆蓋測試也稱為白匣子測試或玻璃匣子測試，這類測試的設(shè)計需要全面了解軟件的實現(xiàn)方式，也就是說，它要“看到匣子里面”。白匣子測試?yán)昧嗽创a所能提供的方便。

白匣子測試充分借力了程序員對程序API、內(nèi)部控制結(jié)構(gòu)的知識，分享了程序員的異常處理能力。由于白匣子測試取決于具體的實現(xiàn)決策，因此要到應(yīng)用代碼完成后，才能動手設(shè)計這類測試。

從嵌入式系統(tǒng)的角度來看，覆蓋測試是最重要的測試，這是因為只要你把握已在多大程度上對代碼進(jìn)行了測試，你就可很好地預(yù)警出現(xiàn)未發(fā)現(xiàn)缺陷的風(fēng)險。白匣子測試的示例包括：

語句覆蓋：選擇的測試案例可以至少將程序中的每一條語句執(zhí)行一次。

判定或分支覆蓋：選擇的測試?yán)炭梢允姑恳粋€分支(條件為真和假的路徑)至少執(zhí)行一次。

條件覆蓋：選擇的測試?yán)炭梢詮?qiáng)制判定中的每一個條件(項)都包含所有可能的邏輯值。

理論上，白匣子測試可以利用或控制所需的任何對象來執(zhí)行其測試。因此，白匣子測試可能使用JTAG接口強(qiáng)制設(shè)定特定的存儲器值作為測試的一部分。實踐上，白匣子測試可以分析邏輯分析儀報告的執(zhí)行路徑。

3.灰匣子測試

由于白匣子測試可以深入代碼內(nèi)部，因此與黑匣子測試相比，這類測試的維護(hù)成本更高。只要要求和I/O關(guān)系保持穩(wěn)定，黑匣子測試就會一直有效;但每次修改代碼后，可能都需要重新進(jìn)行白匣子測試。因此成本效益最高的白匣子測試一般是那些在不深入編程細(xì)節(jié)的情況下利用實現(xiàn)知識進(jìn)行的測試。

較少涉及代碼細(xì)節(jié)的測試有時也稱為灰匣子測試。當(dāng)與“錯誤推測”配合使用時，灰匣子測試非常有效。如果你知道(或者至少猜到)代碼中的弱點在哪里，那么你就可以設(shè)計出對這些弱點“施壓”的測試案例。

因為這些測試覆蓋了代碼的特定部分，因此這些測試是灰匣子測試;因為這些測試是根據(jù)可能會出現(xiàn)哪些錯誤的猜測而選擇的，因此這些測試是錯誤推測測試。

在整合新功能與穩(wěn)定的舊代碼庫時，這種測試策略非常有用。由于代碼庫已經(jīng)過全面的測試，因此將測試重點集中在新、舊代碼交集處可以起到事半功倍的效果。