作者：陈市明/Slipper Feng 摘自：http://www.blogjava.net/JPeanut

       现在越来越多的系统不是独立运行的，会和其他系统进行交互。交互的方式又很多，从传统的页面 post 到现在的 jms ， ws 等。这个就给测试带来比较大的难度，特别是互相通讯的系统不属于同一个公司。测试人员很难在一个办公室里面进行对项目完整的测试，更何况对方系统有的时候是没有测试小组的，只有开发人员兼职做测试。

       我这里主要是解决 jms 通讯的单元测试。在我们公司， jms 的传输的数据密文传输（因为历史原因被称为电文）。很多情况下我们都是通过 mock 来模拟队列和电文的，我这里是通过重新写 jms 的 mq 和 jms 的 message 来实现的，所有的数据不是通过模拟的东西，而是进入真实的队列中。

   设计思想：

模拟 MQ 和 JMS 的工作原理，编写一个本地的 MQ 和消息发送接收系统

在内存中直接将替换 aop 容器中的 MQ 、 JMS 替换为本地的 MQ 和我们的消息处理

       具体设计：

       1 ）电文接收

图表 1 新电文系统接收电文原理

新电文接收系统：其他系统如果要发送信息给我们的系统，是先讲电文发送给我们的 uecp 平台，然后 uecp 讲电文存放倒 MQ 中，我们项目对从 MQ 中读出电文，然后根据配据配置调用响应的 Service ，最后，一般情况， service 都是来操作数据库进行增删改动作。

新电文平台的几大特点：

Ø         电文是异步传输

Ø         电文的是有时序的

Ø         一般来说，一个应用只有一个电文接收队列

图表 2 新电文接收的单元测试原理

针对新电文系统接收的原理和特点，可以分析出：

Ø         电文必须改成本地的的，单元测试做不到异步电文的自动化回归

Ø         应用只有一个队列，我们只需要封装下 ArrayList 就可以作为队列了

Ø         为了修改最小话， IBMMQProxy 的实现改成 JunitMessagingServerProxy ，然后，再通过 ioc 注入 junit 的 MQ 和 Junit 的 JMS

Ø         因为在 uecp 中可以看到电文的明文的，所以， Test***Action 发送电文也是明码，可以直接把 uecp 中的电文 copy 到程序中

图表3新电文系统发送电文原理

读取这些队列将数据准确发送到各个系统中。

图表4新电文发送的单元测试原理

作者：陈市明/Slipper Feng 摘自：http://www.blogjava.net/JPeanut

Junit 目前是 java 种最为流行的单元测试的框架，开发人员是编写设计模式的三大牛人之一。 junit 灵活的使用了多种模式，使得扩展非常之容易。他的扩展是所有单元测试框架是最多的，但是很多扩展都是直接继承自 TestCase ，这个就导致用了这个扩展就没法使用其他的扩展了，比如，用了 dbunit 就不能再用 easy struts 了（除非，我们对扩展进行重写）。

  为了解决这个问题，我在Junit之上还封装了一层TestFrame，使得junit能够很容易的同时使用多个扩展。我们这里的设计思想是：

1．  把扩展写成插件式，我只要通过写一个 plugin 接口让他集成进我们的框架中

2．  后期对架构的功能扩展完全可以通过插件实现。目前，已经写了 dbunit ， struts-easy,imon fk ， JMS 电文的 plugin 。通过插件的方式，我们就可以很容易的解决 junit 的硬伤：测试数据硬代码。

3．  插件的添加，无需修改架构及其原有的测试脚本，只需要在“项目的 TC ”中在注册中心对插件注册就可以获得插件的所有的功能

4．  架构是面向对项目的，所有不同架构的项目可以使用同一套底层架构，不一样的只是“项目 Tc ”

5．  Test Frame Work 、所有的 plugin 和项目 TC 都可以各自独立打成 jar ，这样框架可以很方便的进行局部升级

（呵呵，有了电文插件后，就很容易的对我们的项目进行自动化的单元测试。在次之前，我们一直没有对电文进行有效的自动化的单元测试， mock 技术可以实现，但是，对于需求变化 mock 没有很好的解决办法）

作者：陈市明/Slipper Feng 摘自：http://www.blogjava.net/JPeanut

J2EE 是目前公认的比较慢的一种开发，相比 .net ， php ， asp 等而言。其实， j2ee 的开发者都深有体会的， java 代码编写的速度其实并不慢，在 eclipse 和 jbuilder 等可视化界面的帮助下，编写代码变的越来越简单；但是在调试的时候，每改完一个 java 或者 xml 代码要预览改的效果的话，必须要重新构建，部署，重启服务器 , 这些动作反反复复，消耗的时间不少。

近期为公司写了个单元测试的框架，基本上解决了反反复复构建，部署，重启服务器的问题。我们的项目的都是运用了类似 struts － spring － hibernate 的 MVC 架构（下面简称 ssh ），不同的就是中间的 aop 是自己开发实现的，而没有运用 spring 的。不过，我们的单元测试框架对标准的 struts － spring － hibernate 支持也挺好。

上面的是在 ssh 的一次交互的原理图，做过 struts 开发者都会很熟悉。首先，是 jsp 通过 submit 的 url 将表单数据提交给后台 action 的 servlet ，后台通过在 struts-config.xml 中的配置找到相关的××× Action ，然后通过××× Service ，××× Dao 操作数据库，再将数据返回给另外一个 jsp ，让他显示结果。

上面的图是我们单元测试框架实现构建，部署，重启服务器的原理图。我们很容易从图上看的出来，我们写了个 Test ××× Action 来模拟 2 个 jsp 的动作，该类分成 2 部分上面一部分是模拟了 jsp 页面 submit 的动作（包括模拟提交给 url ，模拟提交数据），下面一部分是接收××× Action 返回的数据，然后，进行校验（此处的校验，我们用了 junit 的断言功能）。通过用 java 类来模拟 jsp 的好处在于，我们可以完全把这个一个交互作为一个 application 来运行起来，非常容易的做到单步调试，而不用到真实的平台上，启动服务器上运行。（注：此处有 2 个 db ：开发 db 和测试 db ，这个再以后的介绍中会讲到）

我们还为在这个架构上开发制定了流程：

1 把当天需要开发的模块的 java 代码全部些好

2 通过这种模式调试 java 代码

3 在确保这些 java 代码无误后，构建，部署，启动服务器

4 然后编写所有的 jsp （因为修改 jsp 无需启动服务器）

这样，在开发一天的所有代码，几乎都不用怎么重启服务器，可以为开发人员省下很多时间，也使得开发人员喜欢的单步调试变的异常简单，提高代码的质量。

我们已经在真实的项目中实施了该流程的开发，得到的效果和预期的一样。当然还是比不过其他语言的开发，不过我们的架构还在不断改进（通过改进流程、编写 eclipse 等开发工具的插件等方法），使我们的开发人员可以更加快的进行 j2ee 的开发。

作者：陈市明/Slipper Feng 摘自：http://www.blogjava.net/JPeanut

进入测似小组也有不少时间了，很多时间都泡在 51testing 论坛里，混在“测试时代组”的 qq 群里，和做测试的朋友聊，聊久了就产生了很多想法。呵呵，想法变成现实嘛，改不了开发的老本行，结合我们公司的开发流程现状，自己动手写了一套关于测试架构，方便我们测试和开发。

该架构主要有实现了一下几点功能：

1 调试无需启动中间件

2 数据和测试代码部分隔离

3 自动生成测试文档

4 单元测试实现功能测试

5 实现回归测试自动化

6 。。。。。

在后面的一些时间，我会陆续详细的从各个角度来介绍这个架构，架构也还在陆续开发和改进中。