大家觀點

既然單元測試是如此重要，那為什么不是每一個項目都做了呢？可能是因為即使是簡單的測試案例也需要一定的工作量。

回想一下前文講到的簡單的例子。首先，函數(shù)的自變量不一定是簡單類型。它們也可能是復(fù)雜的，所以需要初始化以便于測試。第二，被測功能不一定返回簡單類型，也可能是外部變量。最后，“foo”函數(shù)可能調(diào)用另外一個“goo”。這就好比，硬件傳感器/文件/數(shù)據(jù)庫/網(wǎng)絡(luò)接口/ USB端口接收GUI的用戶輸入，這會因為分離而不能正常運作。

要為這個特別的“foo”準(zhǔn)備一個有用的單元測試用例需要大量的工作。要使所測試功能的所有變量初始化正確，存根/驅(qū)動器不可以調(diào)用函數(shù)（例如“goo”），也不能只能后置條件校驗，等等。最后是準(zhǔn)備一個美觀的報告展示測試執(zhí)行結(jié)果，還有執(zhí)行過程中涉及的線/陳述或分支。這些資料需要一直保存。

你會覺得這些工作量很大，而且事實上也是。這就是有些軟件項目沒有進(jìn)行單元測試的最主要的原因。

嵌入式單元測試實踐

在嵌入式軟件開發(fā)的背景下，單元測試是一個更大的挑戰(zhàn)。一方面，它很簡單，因為只使用C語言——當(dāng)使用C ++時，它僅是其中一個簡化的子集。另一方面，單元測試用例需要部署在目標(biāo)板上，或在模擬器上。代碼要和所有的測試用例、測試數(shù)據(jù)一起轉(zhuǎn)移到目標(biāo)板上，然后執(zhí)行。最后，試驗結(jié)果必須收集并傳送回主機，以方便進(jìn)行分析。這些準(zhǔn)備工作增加了嵌入式軟件進(jìn)行單元測試的花費。本文我們不使用這樣的方法，而是探討一種更實用的方法。

被測系統(tǒng)

讓我們考慮簡化的ASR (Acceleration Slip Regulation) 系統(tǒng)，它運行在Keil評估板MVBSTM32E上。必須強調(diào)的是，我們提出這樣的系統(tǒng)是為了說明一個概念：ASR不是真實存在的軟件。

在示例系統(tǒng)中，前輪有兩個速度探測監(jiān)視器。如果一個輪子開始旋轉(zhuǎn)而另一個減慢，則系統(tǒng)假定車輪打滑。接著，系統(tǒng)啟動前輪剎車，以便扭矩直接通過前輪軸降低速度。ASR系統(tǒng)工作的真實詳情，請參考維基百科en.。

簡化的ASR由MDK-ARM建成并通過ULINK Pro部署。它附著在一個汽車模型上運行。該汽車模型裝有速度傳感器板，并可以模擬滑移條件。如下圖。

想了解這些系統(tǒng)是如何工作的，請點擊視屏觀看。

你們注意到視屏中，當(dāng)一個車輪上升時，它就失去了抓地力并獲得整個扭矩。你可以看到系統(tǒng)如何啟動車輪的剎車，使扭矩傳遞到另一個輪子上。

為了準(zhǔn)備ASR的單元測試，我們需要：

• 將uVision項目導(dǎo)入C++test
• 配置里面的C++test項目
• 配置結(jié)果傳輸
• 處理目標(biāo)邊界
• 準(zhǔn)備測試套件和示范性測試用例
• 部署并收集結(jié)果

完成了這些步驟，我們就可以開始測試的具體工作了。