Controlling Android network state with jMeter

Note: this blog is also published at SAP Community Network: http://scn.sap.com/community/mobile/blog/2014/10/13/controlling-android-network-state-with-jmeter

Testing a mobile web scenario includes testing the app end to end for different usage scenarios. This includes testing the state of the mobile device: online and offline. Consider the following scenarios: a HTTP POST request is send to SMP 3 which in turn will send out a push notification, or the UI5 app opens a HTTP request while the device is offline. Will the test pass as expected?

The Android emulator allows controlling the state of network connectivity by pressing F8. This turns gsm data on or off. Manually turning the data network on or off is possible while executing a test, but does not really reflect a real scenario where this happens randomly (entering elevator, subway, bad connection, etc) and is out of your control. To simulate a suddenly not available data connection means to be able to randomly deactivate and activate a data connection on the emulator.

First thing of course is to know how to turn off network in an automated way. To control the network state of the Android emulator, the command: gsm data off/on needs to be issued. To execute the command it is necessary to connect via telnet to the emulator.

Command: telnet localhost 5554

Note: 5554 is the number of the emulator. Connecting via adb shell won’t work.

Telnet opens the command shell and allows executing gsm command to turn off or on the network.

    

    

In case you followed some of my other blogs about testing, you`ll have noticed that I use jMeter. JMeter comes with an impressive list of functionality allowing you to cover almost everything in your test scenario. Therefore, my first thought was to use jMeter to control the network state of the Android emulator. This way, I can include this behavior in other test cases executed by jMeter.

While the commands and execution order is now known, a problem last: Windows telnet client cannot read a list of commands form command line and there is no jMeter telnet client plugin. There is no easy way to send the commands from jMeter to Android. These are two problems to solve:

  1. Send scripted telnet commands
  2. Execute these from jMeter

Send scripted telnet commands

Let’s solve problem 1: One possibility is to use a VB script to send the commands by emulating keyboard strikes. This implies that you should not use the keyboard at the same time – and writing a VBscript. And it does not solve the problem that depending on your Windows version you first will have to install telnet or even won`t be allowed doing so. The solution is a tool known in the Linux world, a tool created in a time WWW was only in its infancy and known only to a few: nc. The last released stable version of nc was released 10 years ago. Fortunately, there is a newer (better) implementation available from nmap: ncat. Ncat is included in the nmap download and available therefore for Windows. No compilation needed, just download and run ncat.exe. To open a telnet session to Android with ncat, the command is: ncat -4 –t localhost 5554

The commands to deactivate gsm data are:

gsm data off

quit

 

Save these to a input file (e.g. gms_off.txt) and let ncat read the file. Command: ncat -4 –t localhost 5554 < gsm_off.txt

This solves issue #1. Now telnet can be used to send a list of commands to Android. Next is to solve issue #2 so jMeter can execute the ncat command.

Execute ncat from jMeter

jMeter offers a OS Process sampler that allows executing a command line program. I wasn`t able to start ncat.exe directly; starting CMD and pass ncat as a parameter however works.

The command to be run is CMD and the input parameters are:

/C <path to nmap>\ncat.exe -4 –t localhost 5554 < <path>\gms_off.txt

Including another sampler for turning data connectivity on again lets jMeter control the network state. Adding a timer element adds the random part to the test. Of course the procedure outlined here is not not applicable to network data, but to all commands available by the Android command shell.

Let the world know

Load test your web applications part 2 – with Apache jMeter

Note: 1st published at SCN on 19.8.2013

This blog is laying around on my hard drive for too much time. The previous version of this blog series was published over a year ago!. Originally named “Load test Web Dynpro Java with jMeter” this was actually the 1st blog of the 3 part series. During the last year, a few blogs about jMeter were published, but as I do not want to leave the series unfinished, I am publishing now (finally) the last part of my load test your web application blog.

To make it easier a jMeter test plan is attached to this blog. This plan can be used in conjunction with a
WDJ application
. Both were used for the creation of this blog.

With jMeter

JMeter is a great tool for testing your web applications. And you can even use it to test Web Dynpro Java applications. To facilitate the work of creating the tests, jMeter comes with a proxy to intercept browser requests and add them to the test. This allows for easy and fast recording of tests.

jMeter test for sample WDJ application:


As by default a WDJ application is accessible as anonymous – or Guest – user, authentication is not needed and a test can be executed several times against the WDJ application. Pretty easy but in real life you’ll hit real soon a hard limit. By default ,the HTTP Cookie Manager controller does not delete cookies with each iteration, or: JSESSIONID is not deleted.

Simulating users

Running the test and checking the user sessions in NWA shows that the same Guest session is used.


With that you may be tempted to run the test and to see the load generated by just 1 user. But try to run the test 50 times. After some calls, jMeter shows an error when executing the open WDJ app step.


The error message returned from the server is:


HTTP 403? Yes, 403. Re-using the same session will ensure that you`ll hit a well known limitation. You can now opt to implement SAP note 1012065, but it is better to end the session after each iteration. While only one Guest session is open, the maximum number of application sessions is exceeded: 23


Now let jMeter create a new session with each iteration.

The new sessions are created because the HTTP Cookie Manager deletes the JSESSIONID cookie with each iteration. Run the test 5 times, the open sessions in NWA will show

To access the report, go to: Availability & Performance -> Resource Monitoring -> Session Monitoring

If now a test with 500 iterations is run, 500 Guest sessions will be created. This may not a problem, but won’t reflect your reality where sessions are ended after the user navigates away. Logging in and off creates additional load, something worth to test too. Besides this, each session occupies some memory. Depending on your test case, this amount of memory can consume quite some substantial part of the free memory, compromising your test results. 

The correct way to test WDJ applications is to end the user session after the test is executed, independently if Guest or named users are used. To end the session, all it takes is to delete the cookies each iteration and trigger a logout action: /irj/portal?logout_submit=1 [you have the portal installed in the same instance, right? If not, you’ll have to add your own logoff functionality to the application]


Add this step at the end of the test.


With a HTTP sampler as the last step, each iteration can be started with a new session without overloading the NetWeaver Java server with Guest or user sessions.

Let the world know