LR Java Vuser2

Recently, the service-side protocol to be tested for the project was developed using the Java Netty Framework, while the transferred business data was serialized using Google Protobuf and then communicated to the client via TCP traffic. This time the pressure test script decided to use the Java script of LR write, has been used in LR in Java scripting is not much, but now the main use of the company project is the Java language, it is also intended to maintain the consistency of technology, testing related to use Java as much as possible.

Find some examples of the Java compression script written in LR, and then use the basic Java IO API to achieve the demo, it seems not complicated, but debugging with the server does not debug, the service side to resolve the client sent data failed, the client is not recognized data. It can be determined that the functionality of the server is normal and that the server and Android clients have been debugged, but the Andriod client has also used the Netty framework to handle protocol-related, repeatedly checking the use of basic Java IO implementation of the client demo code after the OK is no problem, then why does not make sense?

The first thought is to understand the Netty related principles, Netty Framework is probably how to achieve, using what is the underlying API? However, this will take a little time, direct code to the server developers to ask the question of the problem, although the developers do not immediately find the cause of the problem, but speculation may be the root of the TCP data transfer process in the sticky package/unpacking, the server Netty will be sticky packet processing ... Probably know the probable cause, took some time to read the next Netty related tutorials and blogs for sticky packet related, Netty server for PROTOBUF data using Protobufvarint32framedecoder way to decode, That is, through the head field to obtain the length of the entire transmission business data, and then receive the corresponding byte of the data stream to parse, and the head is a different type of int of Java type Varint, specific related data codec can consult the relevant blog tutorial. Because the relevant codec processing is done by the Netty framework, the business code only need to specify a codec, so the hidden codec in the beginning if unfamiliar with the Netty framework is unknown, resulting in the normal processing process caused by errors, Then it is obvious that the service-side parsing failure is due to the fact that the data sent by the client is not encoded, and the service side is correctly decoding the problem caused by the processing.

The problem that needs to be solved is to do the same processing according to the Protobufvarint32framedecoder encoding of the Netty, and the method of writing and decoding by the principle is possible, if the generality should be considered to be a little troublesome. There is a better way to develop colleagues, that is, the Google Protobuf jar package has provided a relative API to handle this codec, the use of debugging is successful.

Later, the protocol-related encapsulation in the Java jar, provided to the LR for invocation, also encountered some LR and Java package version related issues, because LR11 only support to JAVA6, the version is relatively low, it is recommended to write the LR call Java class, Java code uses the same version of Java to write debug packaging on the same machine as the LR , which avoids many version problems. Based on the problems encountered during the debugging of the script development, some points for attention are summarized:

1)When importing a jar package that is called in the Java script of LR: In addition to the jar package in which the custom class method resides, the jar package that it relies on also needs to be imported into LR , as the jar of this call is used by Google Protobuf. The Google Protobuf-java-2.4.1.jar package also needs to be imported into LR.

2) After the Java code written on the Mac machine is copied to Windows, there is a coding problem (resulting in a Java error: It needs to be class interface or enum) because of the BOM text encoding of the Windows miracle. Create a new text file on Windows and then copy the code in such a way that it can be resolved.

3) The use of Maven compiled when the machine turned on VPNFQ, there are a lot of need to download the relevant plug-in dependencies, such as the download process card does not always move, turn off the FQ VPN is normal.

4) A companion version of the LR Java Stress Test Scripting development environment:

Operating system: Windows8 X64
loadrunner:lr11.00.0.0
maven:3.0.5
Java:1.6.0_45
Google protobuf:2.4.1

After sense: LR Use the process of annoying problems really a lot, many times using LR to test slowly changed some of the consistent understanding, LR is not as good as previously imagined. Perhaps it is time to re-understand the Java-based JMeter this open-source tool framework ...

LR Java Vuser2