首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

嵌入式JavaPOS系统测试的设计与实现

嵌入式JavaPOS系统测试的设计与实现

摘要:UnifiedPOS和其衍生的JavaPOS标准,对收款机的硬件设备进行了规范。利用JUnit单元测试工具对嵌入式JavaPOS系统的设备接口进行了白盒测试,分析了市场主流收款机的不足,给出了嵌入式收款机的测试方法和测试用例POSDouble。测试结果表明,嵌入式JavaPOS系统成功地引入了JavaPOS规范,规范了各种外围设备的接口定义,由于采用Java语言,解决了移植性、动态加载、安全性等很多方面的问题。
关键词:嵌入式系统;税控收款机;JavaPOS;ARM


0 引 言
    随着嵌入式计算机应用技术的发展,嵌入式技术已经广泛应用到现代生活的方方面面。在零售系统方面,零售收款机是嵌入式应用的一个重要领域。目前,市场上的收款机大体上可分为三类:第一类是基于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数。
    POSDouble.Add:加法。
    POSDouble.Sub:减法。
    POSDouble.Mult:乘法。
    POSDouble.Div:除法。
    POSDouble isMax:比较浮点数大小。
    POSDouble tolong:将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)即可完成回归测试。
返回列表