1 背景
在我们的应用中的程序有很多是socket通信模块，对于socket通信相关的模块的测试存在如下的问题：
1. 驱动模块开发工作量大，形式各异，不易维护
随着自动化测试的开展，我们在进行功能测试时，普遍使用测试子系统的模式，对于socket通讯模块，我们普遍采取的是用驱动发送请求，接收结果的方式，针对每一个模块的驱动，我们都要写关于请求发送，连接管理，接受请求的代码，这些代码其实都差不多，这就有了很多的重复的工作量。而这些重复的也是可以避免的。虽然这些重复的代码实现的功能基本相同，但是对于不同的开发者而言，这些代码会写成不同的样子，这些驱动的使用方法也可能有很大的不同。这就给维护和使用造成了一些额外的学习成本。
2. 性能测试环境复杂，工具开发困难
很久以来，我们的性能测试和压力测试都采用的向最上端的webserver发送压力，然后通过一系列中间模块将压力请求发送到后端被测模块，采用这样的模式会有如下问题：（1） 进行后端模块的性能测试需要搭建一串的相当复杂的环境，占用相当多的机器。而且模块多，搭建环境的成本也会比较高。（2） 由于压力请求经历的模块很多，各个模块都有可能在配置或者环境上出现问题，当发生问题是定位原因也就是一个很复杂的过程。（3） 由于中间经历了多个模块的转发，对于下游模块的某些输入会在上游模块过滤掉。我们在压力测试中会忽略掉一些会影响性能的重要因素，导致性能测试不准确，可能会遗漏掉一些性能问题
因而，我们针对每个模块的压力工具，通过这个压力工具进行压力和性能测试，会是一种较好的解决方案。但是对于每个模块都写一个压力工具的开发量是比较大的。
3. 大数据对比效率低，定位问题困难
大数据对比是一种很好的保证程序回归功能点的方法，现阶段大数据对比的方法在我们测试中用的也越来越多了，在使用过程中出现了一些问题：现阶段的 socket通讯相关模块的大数据对比是通过用驱动分别向新老版本发送一条请求，然后将接收到的结果打印到文件中，通过对比两个输出文件的数据来判断结果数否相同。这种做法有如下一些弊端：现在的驱动都不支持压力功能，发送完一个请求驱动就退出，这样的话，大数据对比的效率很低速度很慢；输出的结果文件的大小可能很大，这就对进行结果diff造成了一些困难，定位问题也比较麻烦。
2 Aperlib的解决方案
通过对上面问题的分析，我们提供了aperlib来解决上述问题，提供驱动和压力工具框架lib，进行快速的driver和压力工具开发，解决了驱动程序开发的效率及维护和压力工具开发和性能环境复杂问题，提供大数据对比工具开发的框架库进行大数据对比工具的开发，解决了基于socket通信模块的大数据对比的效率低下和定位问题困难的问题。具体的解决方案说明如下：

我一只r认为socket通讯就是serversocket控件，，可是好像感觉不是这么回事呢

相当详细谢谢奉献

太好了，我正NEED

aperlib是open source的吗？

看不太懂 

支持楼主。。分享精神

顶分享精神

继续

具体的解决方案？

顶            
了

不错，顶

顶。。。

能否再具体一点儿？

这是个好东西，可以看一下。

学习了，可惜没学会……

怎么感觉是别人啊写的论文前面那一点！

看看什么好东西

不是很懂 还要多学学

zhichi

学习学习，

哦，介绍一个工具啊

为了得点节分！
 不得不支持！