測試是傳統軟件開發的最后一步。整個軟件開發過程，需要收集要求、進行高層次的設計、詳細設計、創建代碼、進行部分單元測試，然后集成，最后才開始最終測試。
最佳的開發實踐應包含代碼檢查這個步驟。然而代碼檢查一般只能找出70%的系統錯誤，因此完美的測試環節絕對必不可少。測試就像個復式記帳系統，可以確保將缺陷扼殺在最終推出的產品之前。
在所有其它的工程實踐中，測試都被視為基本環節。比如，在美國，每一座聯邦政府出資修建的橋都必須經過大量的風洞測試。而在軟件領域，測試并沒有很受重視。盡管測試是所有工程實踐準則的關鍵部分，但編寫測試程序卻感覺是在浪費時間。好在嵌入式系統設計界內的許多領域已經將測試作為其工作的核心部分，他們認識到將這個關鍵步驟放在項目末期極不明智，因而主張同步地編寫測試程序和應用程序。
嵌入式系統軟件測試在諸多方面都與應用軟件測試一樣。不過，應用測試與嵌入式系統測試之間還是存在一些重要差異。嵌入式開發人員一般會用到基于硬件的測試工具，而這類工具通常不會用于應用開發過程中。此外，嵌入式系統一般都有些獨一無二的特性，這些特性應該在測試計劃中得以體現。本文將介紹測試和測試案例開發的基礎知識，并指出整個嵌入式系統測試工作的特有細節。
何時測試以及如何測試
從圖1可以看出，在可行的條件下，測試應盡早展開。一般來講，最早的測試是由最初的開發人員進行的模塊或單元測試。遺憾的是，開發人員大多對如何建構一整套測試例程以進行測試所知不足。由于精心設計的測試例程通常直到集成測試時才能使用，因此許多在單元測試過程中就能找出的缺陷直到集成測試時才會被發現。比如，硅谷的一家大型網絡設備廠商為找出其軟件集成問題的關鍵原因，進行了一項研究。這家廠商發現，在項目集成階段找出的缺陷中，有70%是由在集成之前從沒被執行過的程序所產生的。
2012-3-16 11:05:05 上傳
下載附件 (9.94 KB)
圖1：改正問題的成本。
單元測試：開發人員在單獨進行模塊級測試時一般是編寫存根代碼(stub code)取代余下的系統軟硬件。在開發周期的這個環節，測試主要側重于代碼的邏輯性能。
通常，開發人員會分別使用某些平均值、高值或低值、以及某些超出范圍的值(以測試代碼的異常處理功能)進行測試。但這些基于“黑匣子”的測試僅能對模塊中整個代碼的一部分進行測試。
回歸測試：測試不應是一勞永逸的。每次修改程序后都應該重新進行測試，以確保這些更改不會無意中“誤傷”某些不相關的行為。
稱為回歸測試的這類測試，一般是通過測試腳本自動進行的。比如，如果你設計了一組100個輸入/輸出(I/O)測試，回歸測試腳本會自動執行這100個測試，然后將輸出與一組“黃金標準”輸出進行對比。每次對代碼的任何部分進行修改時，都要對包含被修改代碼的整個程序運行整套回歸測試程序包，以確保修改過程中不會“誤傷”其余代碼。
測試什么
因為沒有一個實際的測試集可以證明一個程序是正確的，因此關鍵問題變成了哪個測試子集最有可能檢測到最多的錯誤。選擇合適的測試例程的問題被稱為測試例程設計。雖然存在數十種測試案例的設計方法，但它們通常可歸為兩種截然不同的方法：功能測試和覆蓋測試。
功能測試(也稱為黑匣子測試)選擇可評估實現與需求規格符合程度的測試。覆蓋測試(也稱為白匣子測試)選擇可執行代碼某些部分的測試例程。(過后，將詳細討論這兩種方法。)
這兩種測試都是對嵌入式設計進行嚴格測試所必需的。其中，覆蓋測試表示代碼的穩定性，所以這種測試是用于已經完成或將近完成的產品的。另一方面，可在編寫要求文檔時，同時編寫功能測試。
事實上，從功能測試開始入手，可以最大限度地降低重復勞動和重寫測試案例的工作。因此，在我看來，要先考慮功能測試。
每個人都同意先編寫功能測試這個觀點，有人認為，功能測試在系統集成階段(而不是在單元測試時)最有用。以下是整合功能測試和覆蓋測試方法的一個簡單處理流程：
1．找出哪些功能未被功能測試完全覆蓋。
2．找出每個功能的哪些部分沒被執行。
3．找出需要哪些額外的覆蓋測試。
4．運行新增的額外測試。
5．重復以上步驟。
何時停止測試？
最通用的停止標準(按可靠性排序)如下：
1．老板命令停止測試
2．新的測試周期找到的新缺陷少于X個
3．在沒有發現任何新缺陷的情況下已經滿足了某個覆蓋閥限
無論你多么徹底地測試了程序，都無法保證找出所有缺陷。這引發了另一個有趣的問題：你可容忍多少缺陷？假設在極端軟件壓力測試過程中，你發現系統每進行大約20小時的測試就會鎖定。你仔細地檢查程序，但是仍無法找出這個錯誤的根源。這個時候你應該交付產品嗎？
多少測試才“足夠好”？這個我說不好。但遵循一些久經時間考驗的規則總是好的：“如果方法Z預估Y行代碼中的缺陷少于X個，那么就可放心地發布程序了。”也許有一天會出現這種標準。編程行業仍然相對年輕，還達不到類似建筑業那樣的成熟度。
許多厚厚的建筑手冊和大本規范是多年經驗的結晶，它們可為建筑師、土木工程師和結構工程師提供按工期在預算內、建造一棟安全建筑所需的全部信息。偶爾雖仍會有建筑倒塌，但畢竟很少見。在編程行業制定出類似標準前，“多少測試才足夠？”就是個主觀判斷問題。
選擇測試案例
在理想情況下，你可能想要測試程序中每一個可能的行為。這意味著每一種可能的輸入組合或者每一種可能的判定路徑至少測試一次。
這是個崇高但完全不切實際的目標。比如，Glen Ford Myers在其《軟件測試的藝術》一書中就描述了一個只用五個判定條件就可有1014個不同執行路徑的小程序。他指出，如果你能夠每五分鐘就能編寫、執行并驗證一個測試例程的話，那么全面徹底地測試完這個小程序需要10億年時間。
顯然，理想的狀況是無法實現的，因此你必須采用接近這種理想狀況的標準。如你所見，功能測試與覆蓋測試相結合可以提供合理的次優選擇方案。基本方法是選擇最有可能發現錯誤的測試(一部分功能測試，一部分覆蓋測試)。
1．功能測試
功能測試一般稱為黑匣子測試，因為在編寫功能測試的測試例程時并沒有涉及實際的代碼。換句話說，沒有觸及到“匣子內”。嵌入式系統有輸入和輸出，并在輸入和輸出之間執行某些算法。黑匣子測試是根據對哪些輸入應該是可接受的以及這些輸入應與輸出有何種關系的了解來進行的。黑匣子測試完全不了解輸入與輸出之間的算法是如何實現的。黑匣子測試的示例包括：
壓力測試：有意使輸入通道、內存緩沖器、磁盤控制器、存儲器管理系統等過載的測試
邊界值測試：表示特定范圍內的“邊界”的輸入(例如，對于整數輸入而言，是最大和最小整數以及-1、0、+1)；以及應使輸出在輸出范圍的類似邊界出現跨變的輸入值。
異常測試：能觸發故障模式或異常模式的測試。
錯誤推測：根據以前的軟件測試經驗或者從測試類似程序獲得的經驗進行的測試。
隨機測試：通常，這是效率最低的一種測試方法，但卻仍然廣泛用于評估用戶界面代碼的魯棒性。
性能測試：由于性能預期是產品要求的一部分，因此性能分析屬于功能測試的范疇。
由于黑匣子測試僅取決于程序要求及其I/O行為，因此一旦完成功能要求的編寫，即可開發這類測試。這使得黑匣子測試例程的開發可以與余下的系統設計同步進行。
與所有測試一樣，功能測試應被設計得具有破壞性，也即，要試圖證明程序無法工作。這包括使輸入通道過載、隨意地敲打鍵盤，以及故意地做程序員認為會破壞其程序的所有事情。
作為研發產品經理，這是我的主要測試方法之一。如果產品在經過40個小時的極限測試(abuse testing)后，并沒發現任何嚴重或者致命的缺陷，那么就可以發布這個產品了。如果找到了一個重大的缺陷，那么修正這個缺陷后，還必須重復前面的測試步驟。
2．覆蓋測試
功能測試的缺點是其很少執行全部代碼。覆蓋測試則試圖規避這個缺點，它采用的方法是(理想地)確保每一條代碼語句、判定點或者判定路徑都至少被測試一次。覆蓋測試還可以顯示已經訪問的數據空間大小。
覆蓋測試也稱為白匣子測試或玻璃匣子測試，這類測試的設計需要全面了解軟件的實現方式，也就是說，它要“看到匣子里面”。白匣子測試利用了源代碼所能提供的方便。
白匣子測試充分借力了程序員對程序API、內部控制結構的知識，分享了程序員的異常處理能力。由于白匣子測試取決于具體的實現決策，因此要到應用代碼完成后，才能動手設計這類測試。
從嵌入式系統的角度來看，覆蓋測試是最重要的測試，這是因為只要你把握已在多大程度上對代碼進行了測試，你就可很好地預警出現未發現缺陷的風險。白匣子測試的示例包括：
語句覆蓋：選擇的測試案例可以至少將程序中的每一條語句執行一次。
判定或分支覆蓋：選擇的測試例程可以使每一個分支（條件為真和假的路徑）至少執行一次。
條件覆蓋：選擇的測試例程可以強制判定中的每一個條件(項)都包含所有可能的邏輯值。
理論上，白匣子測試可以利用或控制所需的任何對象來執行其測試。因此，白匣子測試可能使用JTAG接口強制設定特定的存儲器值作為測試的一部分。實踐上，白匣子測試可以分析邏輯分析儀報告的執行路徑。
3．灰匣子測試
由于白匣子測試可以深入代碼內部，因此與黑匣子測試相比，這類測試的維護成本更高。只要要求和I/O關系保持穩定，黑匣子測試就會一直有效；但每次修改代碼后，可能都需要重新進行白匣子測試。因此成本效益最高的白匣子測試一般是那些在不深入編程細節的情況下利用實現知識進行的測試。
較少涉及代碼細節的測試有時也稱為灰匣子測試。當與“錯誤推測”配合使用時，灰匣子測試非常有效。如果你知道(或者至少猜到)代碼中的弱點在哪里，那么你就可以設計出對這些弱點“施壓”的測試案例。
因為這些測試覆蓋了代碼的特定部分，因此這些測試是灰匣子測試；因為這些測試是根據可能會出現哪些錯誤的猜測而選擇的，因此這些測試是錯誤推測測試。
在整合新功能與穩定的舊代碼庫時，這種測試策略非常有用。由于代碼庫已經過全面的測試，因此將測試重點集中在新、舊代碼交集處可以起到事半功倍的效果。