Android application performance tests need to follow an end-to-end application delivery model that tests for all the varying scenarios on each component involved. That way, android app developers can gain a true understanding of how their Android apps will perform on a given device as the end users would perceive them.
In a recent DevX article, we proposed such an end-to-end approach for mobile application performance testing. In this article we validate that approach for Android developers by will walking through an Android application performance test using a sample banking app.
Android App Performance Test Components
The Android app performance test involves the following components and tools.
Android Application
The sample Android app is a hybrid application for processing banking transactions. Hybrid mobile applications are installed on mobile devices just like native mobile apps but users can access them via either an installed app or the device browser. The aim is to test this application for performance and find different performance viewpoints.
Server Component
The server component (see details below) handles the business logic for the banking transactions initiated from either a mobile thick/thin client or a desktop Web browser.
- Operating System: Windows Server 2000
- JDK: 1.6
- Web Server: Apache Tomcat
- Database Server: MySQL
Network Emulator
A network emulator recreates a wide variety of network conditions such as latency, jitter, packet loss/error/reordering, and bandwidth restrictions, so that developers can simulate environments such as Wide Area Networks (WANs), Wireless LANs, GPRS, 3G, 2G, IP over Radio / Radio over IP (RoIP), Satellite or MPLS networks. The network emulator determines the traffic load generated by the application under different network conditions. We used Infosys WindTunnel, an in-house tool developed by Infosys Labs, for this performance test.
Load Generator
A load generator tool generates load on the application under test, and it will measure the load times. It allows configuration changes to ramp up the load, increase concurrent users, increase transactions per second, enable parameterization of the URLs, and name each URL. We used JMeter to recreate the load from different delivery modes for the sample application.
Android Device
We used both a high-end and a low-end device for testing to because performance can vary and we wanted to prove the importance of variability in device configurations on the same platform.
Performance Monitor
Thick and Thin Client Performance Comparison
The graph below shows the difference between thick client and thin client. This allows us to understand how the rendering of responses affects performance from the end user’s point of view.
Network Performance Comparison
The graph below presents the network speed for 3G and 2G networks. Load is generated via the load runner tool. We observed that the 2G response time rose higher than that of the 3G as we increased the load.
As you can see, extensive analysis can be performed with the end-to-end data available for the different components involved in mobile application delivery. Such analysis would not be possible if the device were tested in isolation with no control over server/network conditions.
Conclusion
This article presented a proof of concept for end-to-end mobile application performance testing using a sample Android app. It detailed every component to be tested, the method for testing as well as the challenges involved.
When adopting this approach, be sure your Android application performance tests are under these conditions:
- On multiple devices
- With native applications as well as browser-based applications
- Under production like delivery mode-based workload mix on server
- Under production like geography-based workload mix on server
- Under varying network profiles
- Under varying device states
