<Parasoft C / C ++test產品詳情>

大家觀點

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

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

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

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

嵌入式單元測試實踐

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

被測系統

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

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

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

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

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

為了準備ASR的單元測試，我們需要：

• 將uVision項目導入C++test
• 配置里面的C++test項目
• 配置結果傳輸
• 處理目標邊界
• 準備測試套件和示范性測試用例
• 部署并收集結果

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

購買最新正版授權Parasoft贈送Macbook！""

慧都年終盛典火爆開啟，一年僅一次的最強促銷，破冰鉅惠不容錯過(12.01~12.31)！！優惠詳情點擊查看>>