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

嵌入式JavaPOS系统测试的设计与实现 摘要引言1JUnit分析与应用2POSDouble测试3通用接口测试4示例 UnifiedPOS和其衍生的JavaPOS标准 对收款机的硬件设备进行了规范 利用JUnit单元测试工具对嵌入式JavaPOS系统的设备接口进行了白盒测试 分析了市场主流收款机的不足 给出了嵌入式收款机的测试方法和测试用例POSDouble 测试结果表明 嵌入式JavaPOS系统成功地引入了JavaPOS规范 规范了各种外围设备的接口定义 由于采用Java语言 解决了移植性 动态加载 安全性等很多方面的问题 关键词 嵌入式系统 税控收款机 JavaPOS arm 摘要 随着嵌入式计算机应用技术的发展 嵌入式技术已经广泛应用到现代生活的方方面面 在零售系统方面 零售收款机是嵌入式应用的一个重要领域 目前 市场上的收款机大体上可分为三类 第一类是基于PC和DOS Windows体系的 这类产品目前占市场绝大多数 属于高端产品 价格太高 适合大的商场和销售系统 第二类是基于单片机 51系列居多 的 基本上没有操作系统的支持 功能也较弱 主要用于餐饮娱乐 占据中低档市场 第三类是正在快速发展的基于嵌入式芯片和嵌入式操作系统的 价格较低 功能较强 适用于中高档市场 这类产品将是未来市场的主体 以上三类收款机的开发平台形形色色 基本上是每一款就是一种开发平台 没有统一的规范 开发和调试平台 系统升级和移植困难 尤其对于一体机等需要第三方开发软件的应用 造成开发上更大的难度 虚拟机VM的改进 Java应用的速度已经不是太大的问题 引言 MUnit是JUnit的子集 使用方法类似JUnit 在这里只对JUnit做分析 JUnit是一个开源的Java测试框架 它是XUnit测试体系架构的一种实现 在JUnit单元测试框架的设计时 设定了三个总体目标 第一个是简化测试的编写 这种简化包括测试框架的学习和实际测试单元的编写 第二个是使测试单元保持持久性 第三个则是可以利用既有的测试编写相关的测试 所以这些目的也是为什么使用模式的根本原因 JUnit的设计使用以PatternsGenerateArchitectures的方式来架构系统 其设计思想是通过从零开始应用设计模式 然后一个接一个 直至获得最终合适的系统架构 JUnit是一个测试Framework 测试人员只需开发测试用例 然后把这些测试用例 TestCase 组成请求 可能是一个或者多个 发送到JUnit 然后由JUnit执行 最后报告详细测试结果 1JUnit分析与应用 其中 包括执行的时间 错误方法 错误位置等 这样测试用例的开发人员就不需知道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下没有反射机制 在实际测试中可以利用其优点来最大地发挥 由于MIDP1 0下不支持浮点数 float 运算 因此必须开发适合J2ME下的浮点数运算方法 这里主要实现了以下方法 这些方法的测试都是通过JUnit进行的白盒测试 测试数据的选择主要是根据市场的实际需求设定 保证了现阶段的实际需求 而在MIDP2 0下可以支持浮点数的运算 无须自己开发浮点数运算的方法 类名 POSDouble 主要是用于浮点数计算 主要测试以下方法 POSDouble 将字符串转换为POSDouble数 POSDouble Add 加法 POSDouble Sub 减法 POSDouble Mult 乘法 POSDouble Div 除法 POSDoubleisMax 比较浮点数大小 POSDoubletolong 将POSDouble数转化成长整数 POSDouble测试用例 以POSDouble Add 加法为例 2POSDouble测试 由于POSDouble是在J2SE下开发的 所以使用了JUnit工具 而其他接口函数是在J2ME下开发的 所以接口的测试采用了MUnit JUnit的子集 工具 MUnit工具的使用方法 规则请参考 MUnit测试集编写规范 1 测试框架目录结构的总原则是 源代码目录与测试代码目录分离 互不干扰 测试代码目录与源代码目录的分支结构一致 便于查找 维护 2 仿真环境测试执行流程首先编写测试代码 测试代码尽量放在与源代码相对应的测试目录中 修改测试程序入口 如使用ePos set FunctionFormFactory 3通用接口测试 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文件从步骤及时间上都高效得多 1 占用一个入口 加入键盘监听事件 如图2所示 4示例 2 在keyboardlistener中编写按键对应的测试用例或方法 如图3所示 3 编译构建Elf文件 先编译evm ejpos两个项目 编译ROMJava