Global Sources
電子工程專輯
 
電子工程專輯 > 嵌入式技術
 
 
嵌入式技術  

嵌入式軟體測試基礎概述

上網時間: 2012年03月15日     打印版  Bookmark and Share  字型大小:  

關鍵字:嵌入式軟體  測試  功能測試  覆蓋測試  程式碼 

作者:Arnold Berger

華盛頓大學資深講師

測試是傳統軟體開發的最後一步。整個軟體開發過程,需要收集要求、進行高層次的設計、詳細設計、製作程式碼、進行部份單元測試,然後整合,最後才開始最終測試。

最佳的開發實踐應包含程式碼檢查這個步驟。然而程式碼檢查一般只能找出70%的系統錯誤,因此完美的測試環節絕對必不可少。測試就像個复式記帳系統,可以確保將缺陷扼殺在最終推出的產品之前。

在所有其它的工程實踐中,測試都被視為基本環節。比如,在美國,每一座聯邦政府出資修建的橋都必須經過大量的風洞測試。而在軟體領域,測試並沒有很受重視。儘管測試是所有工程實踐準則的關鍵部份,但編寫測試程式卻感覺是在浪費時間。好在嵌入式系統設計界內的許多領域已經將測試作為其工作的核心部份,他們認識到將這個關鍵步驟放在計畫末期極不明智,因而主張同步地編寫測試程式和應用程式。

嵌入式系統軟體測試在諸多方面都與應用軟體測試一樣。不過,應用測試與嵌入式系統測試之間還是存在一些重要差異。嵌入式開發人員一般會用到基於硬體的測試工具,而這類工具通常不會用於應用開發過程中。此外,嵌入式系統一般都有些獨一無二的特性,這些特性應該在測試計劃中得以體現。本文將介紹測試和測試案例開發的基礎知識,並指出整個嵌入式系統測試工作的特有細節。

何時測試以及如何測試

從圖1可以看出,在可行的條件下,測試應盡早展開。一般來講,最早的測試是由最初的開發人員進行的模組或單元測試。遺憾的是,開發人員大多對如何建構一整套測試例程以進行測試所知不足。由於精心設計測試例程通常直到整合測試時才能使用,因此許多在單元測試過程中就能找出的缺陷直到整合測試時才會被發現。比如,矽谷的一家大型網路設備廠商為找出其軟體整合問題的關鍵原因,進行了一項研究。這家廠商發現,在計畫整合階段找出的缺陷中,有70%是由在整合之前從沒被執行過的程式所產生的。


圖1:改正問題的成本。

單元測試:開發人員在單獨進行模組級測試時一般是編寫存根程式碼(stub code)取代餘下的系統軟硬體。在開發週期的這個環節,測試主要側重於程式碼的邏輯性能。

通常,開發人員會分別使用某些平均值、高值或低值、以及某些超出範圍的值(以測試程式碼的異常處理功能)進行測試。但這些基於‘黑盒子’的測試僅能對模組中整個程式碼的一部份進行測試。

回歸測試:測試不應是一勞永逸的。每次修改程式後都應該重新進行測試,以確保這些更改不會無意中‘誤傷’某些不相關的行為。

稱為回歸測試的這類測試,一般是透過測試腳本自動進行的。比如,如果你設計了一組100個輸入/輸出(I/O)測試,回歸測試腳本會自動執行這100個測試,然後將輸出與一組‘黃金標準’輸出進行對比。每次對程式碼的任何部份進行修改時,都要對包含被修改程式碼的整個程式執行整套回歸測試程式包,以確維修改過程中不會‘誤傷’其餘程式碼。


1 • 2 • 3 • 4 Next Page Last Page



投票數:   加入我的最愛
我來評論 - 嵌入式軟體測試基礎概述
評論:  
*  您還能輸入[0]個字
*驗證碼:
 
論壇熱門主題 熱門下載
 •   將邁入40歲的你...存款多少了  •  深入電容觸控技術就從這個問題開始
 •  我有一個數位電源的專利...  •  磷酸鋰鐵電池一問
 •   關於設備商公司的工程師(廠商)薪資前景  •  計算諧振轉換器的同步整流MOSFET功耗損失
 •   Touch sensor & MEMS controller  •  針對智慧電表PLC通訊應用的線路驅動器
 •   下週 深圳 llC 2012 關於PCB免費工具的研討會  •  邏輯閘的應用


EE人生人氣排行
 
返回頁首