對嵌入式系統(tǒng)自動化測試的方法研究

1、<p>　　對嵌入式系統(tǒng)自動化測試的方法研究</p><p>　　[摘 要]該文結合筆者的實踐，闡述了嵌入式系統(tǒng)自動化測試的優(yōu)點，介紹了自動化測試框架，最后分析了自動化測試的策略與實現(xiàn)，以給嵌入式系統(tǒng)的自動化測試問題提供參考與借鑒。 </p><p>　　[關鍵詞]嵌入式系統(tǒng) 自動化測試 策略 方法 </p><p>　　中圖分類號：P804 文獻標識碼：

2、A 文章編號：1009-914X（2015）13-0086-01 </p><p>　　一、嵌入式系統(tǒng)自動化測試的優(yōu)點 </p><p>　　嵌入式系統(tǒng)的測試往往類似于其它測試，主要種類包括：單元測試、系統(tǒng)測試、集成測試以及驗收測試。對于系統(tǒng)測試來說，其面向的對象不僅包括開發(fā)的軟件系統(tǒng)，主要有嵌入式操作系統(tǒng)以及嵌入式應用軟件，也包括硬件系統(tǒng)以及另外的有關因素，主要有人員的操作以及數(shù)據(jù)的獲取

3、，所以就整個產品實施的全面性系統(tǒng)測試來說需要兩個環(huán)節(jié)：第一個環(huán)節(jié)是功能性測試環(huán)節(jié)；第二個環(huán)節(jié)是真正意義上的系統(tǒng)測試。 </p><p>　　自動化測試對軟件質量具有重要意義，尤其對于Agile廣泛運用的目前，執(zhí)行自動化測試已經屬于一種準則。自動化測試具備的優(yōu)越性往往如下： </p><p><b>　　1.提升測試效率 </b></p><p>

4、;　　若干測試如果都通過手工測試則屬于較為復雜的工作，人工進行檢查不但非常枯燥乏味，還浪費時間、容易出錯。若運用自動化測試，便顯得簡單、輕松起來。 </p><p>　　2.給予了回歸測試 </p><p>　　針對產品型的軟件或者具備較長生命周期的項目而言，往往存在新功能開發(fā)或需求更改。對于新發(fā)布的軟件來說，會有許多功能均類似于上一個版本，這些功能要是在上一個版本中已經進行了自動化測試，

5、則在新發(fā)布的版本中，這些功能便能實現(xiàn)自動回歸測試，不僅減少了重復測試的成本，也保證了軟件本身的質量。 </p><p><b>　　3.支持性能測試 </b></p><p>　　在進行性能測試時，利用自動化測試，能簡單地模擬并發(fā)，讓性能測試具備更優(yōu)越的方法。然而自動化測試也存在一定的瓶頸，特別針對嵌入式系統(tǒng)，具體實施存在難處，若運用一些仿真設備，使用起來則會相當昂貴

6、，增加成本。另外進行自動化測試用例的開發(fā)及其維護需要很多的投入，往往比軟件自身的投入還多，而最大的問題在于測試用例的開發(fā)往往落后于軟件自身的開發(fā)，所以不能立即覺察到軟件缺陷，從而越積越多。 </p><p>　　二、自動化測試框架 </p><p>　　自動化測試框架是由一些假設、概念及為自動化軟件測試提供支持的實踐構成的。它在被測應用程序的基礎上研制一套方法，以控制或管理測試自動化過程的

7、變化，從而最大程度地在不同條件下進行自動化測試。當今主要使用的自動化測試框架不僅包括模塊化測試腳本框架、測試庫構建框架、關鍵字驅動測試框架，還包括了數(shù)據(jù)驅動測試框架以及混合的測試框架。 </p><p>　　對于測試庫構建框架而言，其將待測應用程序實施分解，使之成為過程及函數(shù)，而不是成為腳本。此項框架應創(chuàng)建代表待測應用程序模塊、片段還有如SQABasic libraries、APIs以及DLLs功能的庫文件，這些

8、庫文件經由測試用例腳本進行直接調用。 </p><p>　　對于數(shù)據(jù)驅動測試框架而言，是測試從數(shù)據(jù)文件中讀取輸入和輸出數(shù)值并載入到捕獲的或手工編碼的腳本變量里的一種框架。此類框架里面，輸入數(shù)值以及輸出驗證數(shù)值均運用到變量，這些變量應用于測試腳本里面編寫貫穿程序的導航、數(shù)據(jù)文件的讀取以及記錄測試狀態(tài)和信息的日志代碼。 </p><p>　　近年來，自動化測試的要求日益提高，怎樣把自動化測試的

9、效率提高到需要的水平，已經成為所有的測試部門重點考慮的問題。所以一個先進的測試管理流程與一流的自動化測試工具包對于實施自動化測試非常關鍵。 </p><p>　　三、自動化測試的策略 </p><p>　　嵌入式系統(tǒng)經常通過利用C語言來實現(xiàn)，若干任務一起完成不同功能，通常而言都為事件驅動程序。嵌入式系統(tǒng)的重點之處為所有任務狀態(tài)是否正確，有沒有就事件進行準確、快速的響應，這些也都屬于測試重點

10、。對于別的方面如：人機界面能夠經過其它方式的測試得以完成，但自動化測試卻往往不太有效。各項任務均存在一個唯一的入口，要是提供全部可能的輸入，經由此項入口便能覆蓋到全部的代碼，所以應該基于所有任務處在各類輸入的狀況下，檢查狀態(tài)變換有沒有合理，重點數(shù)據(jù)結構能否保持正確，就事件進行的處理能否確保正確?；诖丝梢园l(fā)現(xiàn)對嵌入式系統(tǒng)的測試變?yōu)榱藢θ蝿盏娜肟诤瘮?shù)進行的測試。 </p><p>　　此項策略運用到與單元測試相近的

11、方法，然而也依然存在著本質上的不同。單元測試需將所有函數(shù)接口里面所有被調用了的函數(shù)當成樁進行實現(xiàn)，關鍵目的即為進行函數(shù)內部的邏輯測試，并且文中給出的自動化測試只針對任務的入口函數(shù)進行，僅要求那些和設備主要包括網絡設備、顯示設備、存儲設備及其有關的接口能夠當成樁得以實現(xiàn)。而與任務自身邏輯有關的接口還是要經過直接調用，進而察覺到任務邏輯的問題，如此進行便于更加良好地察覺代碼集成間的問題。另外的區(qū)別在于單元測試屬于白盒測試，應該相當熟悉代碼，

12、也要考慮邊界值，項目開發(fā)的過程中，代碼若出現(xiàn)變化，測試用例也會出現(xiàn)對應的變化，如此進行需要很大投入；而此項策略雖然應該熟悉掌握代碼，但是僅僅依靠需求，代碼發(fā)生變化不能造成用例的變化，除非是接口發(fā)生了變化，所以把其稱為灰盒測試。 </p><p>　　此方案依靠于Rational Test Real Time，其為IBM發(fā)布的在Window 上的一個有名的測試工具，里面最關鍵的功能即為“Component Test

13、ing”。策略實現(xiàn)主要包括：建立工程、配置工程、實現(xiàn)測試用例、構建及其運行。其通過相當簡單的腳本語言進而實現(xiàn)測試用例，淡化了測試用例的開發(fā)，測試用例被測代碼與樁共同進行編譯產生可執(zhí)行文件，對此項執(zhí)行文件進行直接運行，對應的測試結果因此產生。所以此項方案無需另外的硬件、開發(fā)測試用例的投入不多、編譯及其運行花費很少的時間，代碼的邏輯問題能很快被察覺，促使自動化測試對嵌入式系統(tǒng)方面的問題得以很好處理。 </p><p>

14、;<b>　　四、總結 </b></p><p>　　基于項目實施與評測結果而言，此類自動化測試方案具有非常好的應用效果，其可以很好地察覺缺陷，節(jié)約了很多資源，能保證與開發(fā)齊頭并進，盡可能早地發(fā)現(xiàn)問題。同時其在追蹤待實現(xiàn)的功能上也具有很多作用，是現(xiàn)代化軟件進行開發(fā)時非常關鍵的一環(huán)，同時也確保了軟件質量。這樣的測試省去了許多重復的工作，所以我們可以利用更多的時間去思考怎樣提升軟件的質量，制定詳

15、細的測試計劃，精心設計測試用例，構建功能更為強大的測試系統(tǒng)。 </p><p>　　總的來說，此方案在自動化測試的投入與產出上保持了比較好的平衡，滿足了軟件開發(fā)的需要。將此項方案用于一些科研項目里，也證明了其屬于一個成功的實踐，給其它嵌入式系統(tǒng)的自動化測試帶來一些參考借鑒與思路。 </p><p><b>　　參考文獻 </b></p><p>

16、;　　[1]趙婧，手機半自動化測試工具的設計與開發(fā)[D]，北京交通大學.2008 </p><p>　　[2]章亮，劉斌，陸名燕，嵌入式軟件測試開發(fā)中的框架設計，北京航空航天大學學報，2005，（03） </p><p>　　[3]高秋，GMTAF 測試自動化框架的設計與實現(xiàn)[D]，杭州，浙江大學， 2007. </p><p>　　[4]陸璐，王柏勇，軟件自動化測