嵌入式JavaPOS系統測試的設計與實現
發布時間：2010-11-17 15:50
發布者：designer
|
隨著嵌入式計算機應用技術的發展，嵌入式技術已經廣泛應用到現代生活的方方面面。在零售系統方面，零售收款機是嵌入式應用的一個重要領域。目前，市場上的收款機大體上可分為三類：第一類是基于PC和DOS／Windows體系的，這類產品目前占市場絕大多數，屬于高端產品，價格太高，適合大的商場和銷售系統；第二類是基于單片機(51系列居多)的，基本上沒有操作系統的支持，功能也較弱，主要用于餐飲娛樂，占據中低檔市場；第三類是正在快速發展的基于嵌入式芯片和嵌入式操作系統的，價格較低，功能較強，適用于中高檔市場，這類產品將是未來市場的主體。以上三類收款機的開發平臺形形色色，基本上是每一款就是一種開發平臺，沒有統一的規范、開發和調試平臺。系統升級和移植困難，尤其對于一體機等需要第三方開發軟件的應用，造成開發上更大的難度。虛擬機VM的改進，Java應用的速度已經不是太大的問題。 1 JUnit分析與應用 MUnit是JUnit的子集，使用方法類似JUnit，在這里只對JUnit做分析。JUnit是一個開源的Java測試框架，它是XUnit測試體系架構的一種實現。在JUnit單元測試框架的設計時，設定了三個總體目標，第一個是簡化測試的編寫，這種簡化包括測試框架的學習和實際測試單元的編寫；第二個是使測試單元保持持久性；第三個則是可以利用既有的測試編寫相關的測試。所以這些目的也是為什么使用模式的根本原因。JUnit的設計使用以Patterns Generate Architectures的方式來架構系統。其設計思想是通過從零開始應用設計模式，然后一個接一個，直至獲得最終合適的系統架構。JUnit是一個測試Framework，測試人員只需開發測試用例，然后把這些測試用例(TestCase)組成請求(可能是一個或者多個)，發送到JUnit，然后由JUnit執行，最后報告詳細測試結果。其中，包括執行的時間、錯誤方法、錯誤位置等。這樣測試用例的開發人員就不需知道JUnit內部的細節，只要符合它定義的請求格式即可。從JUnit的角度考慮，它并不需要知道請求TestCase的具體操作信息，僅把它當作一種命令來執行，然后把執行測試結果發給測試人員。這樣就使JUnit框架和TestCase的開發人員獨立開來，使得請求的一方不必知道接收請求一方的詳細信息，更不必知道是怎樣被接收，以及怎樣被執行的，實現系統的松耦合。 Junit．Framework包中包含了JUnit測試類所需要的所有基類，實際上這個包也是整個JUnit的基礎框架。TestCase類是這個包的核心類，測試人員對TestCase類進行繼承開發自己的類測試驅動程序。其余的類用來支援這個TestCase類，比如TestSuite用類聚合多個測試用例(Testcase)，Assert類實現期望值和實際值的驗證，TestResult收集所有測試用例執行后的結果。Test接口是這個包的關鍵所在，它建立了TestCase和TestSuite之間的關聯，同時為整個框架做了擴展預留。在J2SE下簡單應用舉例： 右擊項目名稱選擇新建→JUnit測試用例 (運行)調試方式→JUnit測試。圖1為運行結果。 JUnit在J2SE下可以很好地應用，但是在J2ME下應用存在比較大的困難，因為在J2ME下沒有反射機制。在實際測試中可以利用其優點來最大地發揮。 2 POSDouble測試 由于MIDP 1．0下不支持浮點數(float)運算，因此必須開發適合J2ME下的浮點數運算方法。這里主要實現了以下方法，這些方法的測試都是通過JUnit進行的白盒測試，測試數據的選擇主要是根據市場的實際需求設定，保證了現階段的實際需求；而在MIDP 2．0下可以支持浮點數的運算，無須自己開發浮點數運算的方法。 類名：POSDouble，主要是用于浮點數計算，主要測試以下方法：
POSDouble測試用例(以POSDouble．Add：加法為例)： 3 通用接口測試 由于POSDouble是在J2SE下開發的，所以使用了JUnit工具，而其他接口函數是在J2ME下開發的，所以接口的測試采用了MUnit(JUnit的子集)工具。MUnit工具的使用方法、規則請參考《MUnit測試集編寫規范》。 (1)測試框架 目錄結構的總原則是：源代碼目錄與測試代碼目錄分離，互不干擾；測試代碼目錄與源代碼目錄的分支結構一致，便于查找、維護。 (2)仿真環境測試執行流程 首先編寫測試代碼，測試代碼盡量放在與源代碼相對應的測試目錄中。修改測試程序入口，如使用ePos．set．FunctionFormFactory。 (3)目標環境測試執行流程 編寫測試代碼，修改測試程序入口，構建測試代碼的Jar文件，下載Jar文件到目標機運行。 (4)測試捷徑 通常情況下，在目標環境下測試，需要先編寫測試用例、再編譯、再下載、再運行，如果突然想到一個測試用例，又需重復上述操作步驟，就會非常耗時。為了增強測試的靈活性，可以加入鍵盤監聽事件。首先編寫鍵盤監聽類，將所有的測試單步對應到不同的按鍵上去，即按一個鍵執行一個操作步驟。如：“a”對應open操作，“b”對應claim操作，“c”對應setDeviceEnable(true)操作。要執行一個完整的測試過程，就分步驟按相應的按鍵。要想執行不同的測試用例就按不同的順序按相應的按鍵，這樣就不再需要編寫測試用例、編譯、構建、下載，可以節約很多時間，測試效率得到很大提升。同時可以結合原有測試用例，讓不同的按鍵對應到不同的(完整的)測試用例，這樣不占用程序入口，同樣可以實現并執行原來的測試用例。 (5)快速回歸測試 bug修正后需要做回歸測試，為了在目標環境上回歸測試，必須經過以下步驟： ①從CVS更新最新源碼； ②將Java源碼編譯成C文件； ③構建Elf文件； ④下載Elf文件； ⑤執行測試用例做回歸測試。 其中的步驟②～④將耗費很多時間。為了提升回歸測試效率，將設備的DeviceServices從Elf文件中剝離出來，單獨生成一個Jar文件，如果只有DeviceSer-Vices更新，只需要重新編譯DeviceServices的Jar文件，不需更改Elf文件。更新Jar文件比更新Elf文件從步驟及時間上都高效得多。 4 示例 (1)占用一個入口，加入鍵盤監聽事件，如圖2所示。 (2)在keyboardlistener中編寫按鍵對應的測試用例或方法，如圖3所示。 (3)編譯構建Elf文件。先編譯evm，ejpos兩個項目；編譯ROMJavaWin．c，NativeFunctionTable．c用于構建Elf(含evm，ejpos)；在LambdaIDE下構建Elf文件并優化；通過LBOOT下載到目標環境中。 (4)編譯測試用例的Jar文件。 (5)在目標機上根據按鍵執行不同的測試用例。 bug回歸測試時，更新DeviceService的內容，重復步驟(5)即可完成回歸測試。 |
網友評論