写在协议组件压力测试之前

想一想来TX已经差不多快两年了,回过头看看自己的走过的路,收获是不少,但仔细想想看,大部分做的东西都是些重复的,基本上写的所有代码都是围绕业务逻辑的,测试执行人员提点需求,我这边就改点代码或者再推翻了重新写个程序,again and again 不是说写业务逻辑代码的工具不好,毕竟可以解决自动化测试的问题,提高了同事的测试效率,减少了测试执行时间,但是一直没有个什么框架性的东西,即便有类似的想法,在提出的过程中也会因多种因素而夭折:比如工作时间的挤压,同事置疑是否已经有类似的东西以及必要性,其实自己清楚
五一节前,宠物1项目组又一次提出了新的领养服务器的压力测试需求,摆在我面前的有两条路：
一个是象往常一样，找到开发让他们提供几个CGI接口，用LR录脚本找几台机器跑完 给结果就行，平稳而高效的完成工作任务，但我知道那个得出的数据的参考意义到底有多大，与外网几十万的数据来比 内网测试受制于CGI单台apache服务器只能承受1000左右的并发量，好吧就算我能找到10台机同时跑 也就1万左右的并发量，也才相当于外网的几十分之一的请求量，明眼人一看也就明白，而且 大部分的压力都转移到了apahce服务器所在的机器上，有服务器顺序提交请求，那其实也不能叫真正意义上的请求，这种业务逻辑不是从WEB上发起的测试需求，借WEB之道行压力测试之名而已，而且还有个更重要的原因，我不想围着脚本转，说老实话，那是可耻的，写脚本一方面其枯燥性是对人的一种摧残，要是说写程序是一种智慧的凝结，那么写脚本就是个工人熟练度的问题。

另一条路心里想了很久，为什么呢，因为很多因素让我有些怯步，一个是，工作进度不会给你很多的时间，去研究新的方法，更多的时候 项目组的兄弟要的不是你方法，更多的时候要的是你的一个结论。另外的因素就是其技术难度和工程之大让人砸舌。可兄弟项目组都在做类似的东西了，ATP项目就是个很好的例子，剥离业务逻辑只实现业务接口，有测试执行人员负责2次开发直接调用，不过这是用于自动化功能测试的，对于性能测试就连业界内也大部分只是在使用LR的工具而已，自己要做到通用的压力测试平台的话，就要实现组件压力测试，业务逻辑均采用原来的项目组提供的方法，经过自己修改后封装成组件，呵呵，感觉自己是不是有点蚍蜉撼大树了。思考再三的情况下，还是向宠物1项目组要来了服务器相关协议及相关的CPP和头文件，
列了下自己要实现的功能以及技术难点，自己都有点傻眼了：

1.C#中对C++的DLL的调用-------------------------------------------------------------(难易度：★★★★)
2.封装的UDP/TCP发包器---------------------------------------------------------------(难易度：★★★)
3.原有业务逻辑struct的转换到byte的方法---------------------------------------------(难易度：★★)
4.并发请求控制(相当于LoadRunner的Controller)---------------------------------------(难易度：★★★★)
5.异步请求控制--------------------------------------------------------------------------(难易度：★★★)
6.线程数目根据负载机性能的动态调整------------------------------------------------(难易度：★★★★)
7.数据的统计和分析(单件模式的日志类/报表)-----------------------------------------(难易度：★★)
8.跨平台的支持(windows平台下多台负载机运行/MONO环境下Linux上的运行)-----(难易度：★★★★)

优点：
1.不受制于商业的压力测试工具及其license的限制
2.节省项目组开发人员的时间，不需要让他们找时间写CGI接口
3.可以验证边界值。
4.可以测试基与协议的非法数据的请求
5.基于组件实现了工具平台的通用性，避免了重复开发
6.跨平台让测试执行人员和服务器执行都有可能（当然需要看在MONO上的实现情况）

和以前一个自己创业的朋友谈了谈自己的想法，他说：你疯了？拿你的工资做你的事就好，还花这么大心思，不过这东西如果真的做出来了，我买一个。
这斯的最后半句说老实话还是极大程度上的鼓舞了我....呵呵 ，喝杯茶，去睡觉了。