最近项目待压测的服务端协议使用的是java的Netty框架开发，而传输的业务数据使用了google protobuf进行序列化，然后通过tcp数据流与客户端通讯。这一次的压测脚本决定使用LR的java脚本来写，一直以来LR中使用java写脚本使用的并不多，但现在公司项目主要使用的是java语言，所以也打算保持技术的一致性，测试相关的也尽量使用java了。
找了些LR下写的java压测脚本的例子，然后自己使用基本的java io API实现了Demo，看起来貌似并不复杂，然而与服务端进行调试时并没有调试通，服务端解析客户端发送过的数据时失败，未识别客户端的数据。可以确定的是服务端的功能是正常的，并且服务端与android客户端是已经调试通过的，不过andriod客户端也使用了Netty框架来处理协议相关的，反复检查了使用基本的java io实现的客户端demo代码后确定是没有问题的，那么为啥就不通呢？
首先想到的是了解下netty相关的原理，netty框架大概是如何实现的，使用的是什么底层API等？不过这都需要一点时间的，直接发代码给服务端开发人员询问下遇到的问题，开发人员虽然没有马上找出问题的原因，不过猜测可能是根tcp数据传输过程中的粘包/拆包有关，服务端netty会进行粘包处理。。。 大概知道了可能的原因后，花了些时间看了下netty相关的教程及博客对于粘包相关的，netty服务端对于protobuf数据使用了ProtobufVarint32FrameDecoder方式进行解码，也即是通过头部字段来获得整个传输业务数据的长度，然后接收对应字节的数据流进行解析，而且头部使用的是一种不同于java的int类型的一种特殊类型varint，具体相关的数据编解码可以查阅相关博客教程。因为相关的编解码处理都是有netty框架来完成的，业务代码只需要指定一种编解码方式即可，所以这里隐藏的编解码处理在一开始如果不熟悉netty框架的话是未知的，导致按常规的处理流程就导致错误了， 那么很显然遇到服务端解析失败的原因是因为客户端发送的数据没有进行相关的编码处理，而服务端正常进行了解码处理导致的问题。
需要解决的问题即是按netty的ProtobufVarint32FrameDecoder编码方式对发送的数据做同样的处理，通过原理自己写编解码的方法固然是可以的，如果考虑其通用性应该也是稍有点麻烦的，有开发同事提供了更好的办法，那就是google protobuf的jar包中已经提供了相对的API来处理这种编解码，使用之调试便成功了。
之后将协议相关的封装在java的jar中，提供给LR进行调用，其间还遇到一些LR和java包版本相关的问题，由于LR11只支持到java6，版本已经比较低了，建议以后写LR调用的java类时，java代码在LR相同的机器上使用相同版本的java进行编写调试打包，这样可以避免很多版本方面的问题。基于本次脚本开发调试过程中遇到的问题，总结一些注意事项：
1）LR的java脚本中调用的jar包导入时：除了自定义类方法所在的jar包外，该jar包依赖的jar包也同样需要导入到LR中，如本次调用的jar用到了google protobuf，那google的protobuf-java-2.4.1.jar包也同样需要导入到LR中
2）mac机器上写的java代码拷贝到windows上后编译时会有编码问题 （导致java错误：需要为class interface或enum），原因是windows奇葩的BOM文本编码导致的。在windows上新建文本文件然后拷贝代码的方式可以解决。
3）使用maven编译时竟然遇到由于机器开启了VPNFQ，有很多的需要下载的相关插件依赖包等下载过程中卡不一直不动了，关掉FQ的VPN才正常的。
4）本次LR java压力测试脚本开发环境的配套版本：
操作系统： windows8 X64
loadrunner： LR11.00.0.0
maven： 3.0.5
java：1.6.0_45
google protobuf: 2.4.1
后感：LR使用过程中烦人的问题还真不少，多次使用LR进行测试中慢慢的改变了一些一贯以来的认识，LR并没有之前想象中的那么好用了。或许是该要重新去认识下基于java的jmeter这个开源的工具框架了。。。