一个通用的测试客户端框架设计

事情源于此：组内同事都是写Server出身的，linux下写代码，那是哗啦啦的。有些Server是需要跟客户端交互的，同事二话不说，写底层通信，写测试逻辑。有验证逻辑，有压力测试逻辑，还有模拟client的监控逻辑。

 

经过长期观察，还有本人自己的体会，每个人写的测试客户端功能相似，实现不同。这其实就是一个重复造轮子的过程。浪费了大量的人力和时间。并且，写出来的测试客户端基本只能在linux下使用。要是想在办公机器上测试一下，都是比较麻烦的。

 

于是为大家写了一个通用的跨平台的测试客户端框架。框架是基于ACE的，以此来做到跨平台。使用Reactor模式来处理并发逻辑（这个可以用在压力测试上面）。考虑组内很多人都不会用ACE，并且ACE的学习成本也是比较高的，因此每个人自己的测试逻辑部分，就能做到不用ACE也可以编译和运行。而且每个人的测试用例都不一样，测试框架需要能运行多种测试用例。没考虑多久，就选定了这样一个程序的架构。

 

 

 

 

测试客户端框架就是一个可执行程序，windows和linux下各有一个（没别的操作系统了，暂时只考虑这两个最有用的）。每一个测试用例都是一个动态链接库，windows下编译成dll，linux下编译成so 。

 

这样做的好处还有一点，无论测试用例写的多么烂，那都是测试用例自己的事情。很少有人能够理解这一点，在开发当中，几个人一起写代码，一粒老鼠屎坏了一锅粥的事情是常有的（架构、算法和需求的变动等导致整体逻辑变的难以维护，倒不是开发人员的水平问题。） 我们所能做的，就是将逻辑最大程度的分隔和解耦，动态链接库基本是单进程业务当中模块耦合度最低的了。当然，这么说的前提是，接口设计一定要好。

 

 

这里就说到接口设计了。怎样的接口设计才是比较好的呢？

 

首先要看我们的测试客户端框架需要提供何种功能。无论如何，设计都不能离开需求，我们鲜明的反对过度设计。

 

1. 提供统一的网络IO模型。

2. 提供一些基本功能的封装，比如帐号验证，tcp长连接。

3. 向上层屏蔽ACE。

 

这个测试客户端框架还是比较简单的。统一的网络IO模型，用Reactor模式就能实现了。实现注册、事件通知的接口。

 

TCP长连接，帐号验证等功能，写好类，封装成库，提供头文件给业务。

 

向上层屏蔽ACE，只要头文件里面不出现ace相关的数据结构就行了。

 

框架再次细化如下：

 

 

TestCase可以使用baselib封装的服务，并将自己注册到进程当中，很完美。

 

最后发现此模型有一个严重的问题：BaseLib使用了ACE，导致TestCase要把BaseLib编译进去，无论是在windows下还是linux下，都需要ACE的库。这违反了需求的第三点，向上屏蔽ACE。想了一下，如何解决这种问题呢？

 

那就把BaseLib编译到TestClientFrame当中嘛，通过TestClientFrame和TestCase的接口暴露服务给上层逻辑。由于TestClientFrame已经是一个编译好的进程了，使用这里面的接口，dll不会有任何问题。于是架构又回到了图1。（事物总是螺旋上升的）

 

最终接口总结如下：

 

 

 

测试框架通过IServiceFrame暴露功能给上层的TestCase应用，复杂的功能，如TCP连接，会有一个类来处理（CClientTCPHandler），而这个类是基于ACE的，因此只能暴露通用跟ACE无关的接口IClientHandler给TestCase，下层是否用ACE来实现，其实已经无所谓了。

 

IClientHandler定义了一个CallBack的接口回调来处理复杂的异步逻辑。如果MyTestCase需要用到这些异步逻辑，那么请实现此CallBack接口所规定的功能，如果不需要，那么就不用实现。

 

MyTestCase通过实现ITestCase的接口来为底层的Service调用，一般此类接口都是具有OnXXX的特性。

 

最后，最最重要的一点，是所有dll和so都必须要做的，就是要export一个函数给底层，这个函数会返回一个ITestCase的实例。最简单的做法，就是在实现这个函数的时候new一个CMyTestCase返回出去。。。

 

写太多了，很晚了，洗洗睡吧。。。