介紹

單元測試已經(jīng)存在了許多年。 “Test early, test often” 是一個涉及單元測試的口頭禪，但不是每一個軟件項目都有合適的和先進的單元測試套件。當面對嵌入式系統(tǒng)的時候，這個想法需要改變了，因為對軟件質量的要求在持續(xù)增長。國際標準，如IEC-61508-3, ISO/DIS-26262或DO-178B/C，需要模塊測試以達到要求的功能安全級別。模塊級的單元測試有助于達到這一要求。然而，功能安全不僅僅是一個成本回收的問題，還會損失信用。我們需要多花一些時間和精力，以確保我們發(fā)布的軟件不會造成任何不愉快的意外。

在這篇文章中，我們將介紹如何編寫，維護，建立關于ASR的簡化模擬模塊的單元測試并從中受益。我們將使用Keil評估板MCBSTM32E與Cortex-M3 MCU，帶有新的ULINK Pro debug和trace adapter的MDK-ARM，Parasoft C / C ++test。您將看到如何最大化利用IDE/測試框架的整合，并通過測試工具專用主機的通信通道ULINK Pro簡化了初始設置。您還將看到對于擴大測試能力而言，這安裝工作如何起到重要的作用。

單元測試的基礎知識

單元測試是一個眾所周知的概念。本質上，它包括單個功能或一類方法，并用一組給定的參數(shù)調用它。當執(zhí)行完畢時，最好的結果是達到了預期要求。這樣一個代碼的完成成為一個測試用例。檢查結果通常是使用斷言的形式完成的。例如，假設您有以下功能“foo”：

int foo (int a, int b) {
return b – a -1;
}

一個測試用例可能是這樣的：

void test_foo ()
{
int Ret = foo(1,2);
assertTrue(ret = 0, “Wrong value returned!”);
}

優(yōu)點

單元測試有許多好處。當創(chuàng)建了一個單元測試案例，即使開發(fā)測試人員的水平有些低也能夠執(zhí)行，甚至包括高級別功能測試的代碼部分。這樣一來，測試人員可以測試“角落示例（corner cases）”，處理異常情況。

第二個重要的優(yōu)點，可以促使開發(fā)人員編寫“可測試”的代碼。這樣使得代碼不過與復雜，容易分解，更好的全面設計。

另一個好處是，單元測試用例套件為您的應用程序建立一個巨大的安全網(wǎng)。無論您是重構代碼還是處理舊的代碼，這一點都是非常重要的。通常這種情況下，開發(fā)人員都害怕引入新的錯誤。有了這個安全網(wǎng)，您可以放心的修改代碼。如果您出現(xiàn)了什么錯誤，安全網(wǎng)會立即發(fā)出警報。這可以提高您的工作效率并寫出質量更高的代碼。

最后一點同樣很重要，單元測試用例可以將錯誤在開發(fā)周期的早期暴露。眾所周知，在集成測試階段修復錯誤比在系統(tǒng)測試階段后期的成本要少很多。

上述原因導致測試驅動開發(fā)（TDD）的發(fā)明。TDD促使開發(fā)人員為每個功能創(chuàng)建一個單元測試案例，并實現(xiàn)它。