通过我们针对以上的问题进行了分析：我们的不同程序的压力工具，不同之处在与和下游被测模块的接口，包括发送的请求、接收结果的接口和从词表文件中获取请求数据，其他的对于连接的管理，压力发送数据的管理，压力大小的控制，压力结果数据的管理都是一致的，而且压力工具的功能和逻辑是相同的，只是一些功能的具体的实现方式有所差异，因而，我们可以将程序的基本框架和相同的功能在一个类中实现，而将可能有差别的地方用虚函数接口暴露在程序外面，通过针对不同的被测程序模块的特点，继承这个类的子类来，重写这些函数来实现各个模块的压力和大数据对比工具。下图黑色部分为压力工具中的相同的不需重写的功能，红色为实现不相同的功能，对应的蓝色为对应的aperlib的函数接口。
图1. Aperlib压力的功能及重用接口说明图示
我们有了测试压力工具，那么我们的性能和压力测试就不需要搭建被测模块上游的一系列的模块，而且对于输入的信息我们可以不怕上游模块的过滤*构造了，以下图为例说明一下性能环境的精简。
图2 性能测试环境精简图示
2. 驱动和压力工具共用，降低开发成本
我们再来分析一下压力工具和功能测试所用的驱动模块的区别：压力工具是发送大量的请求给被测模块，有发送请求接受结果和将结果打印出来的功能，而我们功能测试所用的驱动模块是发送少量的请求，也有发送请求接受结果和将结果打印出来的功能，实际上他们的区别只在于发送请求的数量上了，那么我们将压力工具的压力词表的数据变少，实际上就是一个驱动程序了，也就是说我们程序的驱动和压力工具可以用一个程序来实现。我们在写压力工具的时候我们的驱动程序也就随之产生了
5 个解决方案
#1
主席说过，凡是分享的都顶。而且我还不会，更应该顶了!
#2
学习、。。。。。
#3
我也学习、。。。。。
#4
该回复于2010-12-02 13:05:03被版主删除
#5
学习学习..
#1
主席说过，凡是分享的都顶。而且我还不会，更应该顶了!
#2
学习、。。。。。
#3
我也学习、。。。。。
#4
该回复于2010-12-02 13:05:03被版主删除
#5
学习学习..