Performance testing on mobile devices, applications, and Web content is by no means a new phenomenon. Even so, the truth is that we still need to know how well our apps and sites perform in production environments before that inevitable slow down or downtime occurs.
One key characteristic of mobile device traffic is that it's often thinner and less complex than traffic originating from desktop environments. However, a key commonality is the shift to use open Web standards in both websites and native applications, desktop and mobile alike. The result is that more and more of the traffic originating from mobile devices revolves around open Web standards, regardless of whether the content is a website or a native app.
Traffic Is as Traffic Does
The biggest hurdle in performance testing for mobile devices is not simulating loads of traffic, it's recording the traffic accurately in the first place.
When we talk about Web “traffic,” we're really referring to the HTTP requests and responses between devices and servers. From the perspective of your website, your desktop browser and your mobile phone are not all that different. They both need content, often over different network connections, but the protocols are typically just Web standards such as HTTP/SSL and the content formats follow suit.
Some traffic varies based on things like the end-user's profile, the locale, and the device type. For mobile devices, the traffic pattern is often also affected by form factor and capabilities of the device.
Anything that affects the traffic pattern matters when testing the performance of your Web content; different devices produce different traffic patterns. Still, it's important to remember that the pattern of traffic is the important aspect, not the device that the traffic originates from.
Recording the Simulation
There are two methods of recording mobile traffic:
- Record the traffic from your device while you interact with your mobile content
- Simulate the experience of interacting with your mobile content via an emulator
If you have access to physical devices for testing, the former approach will often get you the most accurate recording of the traffic that devices in the field will produce. If you don’t have access to actual hardware, you may want to consider the latter option, using emulators.
It is important to record traffic that is as close to actual anticipated traffic as possible. Your test results will be pretty useless if you simulate the connection speed but fail to consider the volume of traffic. Using the same data each time may also skew your test results, leading you to miss important issues in the production situations.
The most accurate and widely supported option is to use a proxy server. In this model, you intercept traffic between your device and your Web content, allowing LoadUIWeb to record that traffic. You simply need to follow these three steps:
1. Connect Device and Workstation to the Same Network
First, make sure your mobile device and workstation are connected to the same network. In most cases, this is as simple as connecting to the same Wi-Fi network from your mobile device and your workstation or laptop. If your device and workstation don’t have similar IP addresses, you may want to consult your IT administrator for help getting this to work.
You can find a number of tutorials on how to do this for iOS, Android, and Windows Phone online, though after doing it once, you’ll get really good at it.
2. Set up a Proxy
Secondly, make your workstation act as a proxy server. An easy way to do this (in Windows, anyway) is to install Fiddler, a tool that acts as a proxy service when running. Launch the tool, then under the Tools > Options dialog, on the “Connections” tab, enable the “Allow remote computers to connect” and disable the “Act as system proxy on startup” features (see image).
If your Web application or site uses HTTPS/SSL to secure traffic from clients, you’ll want to enable the “Capture HTTPS CONNECTs”, “Decrypt HTTPS traffic”, and “Ignore server certificate errors” over on the “HTTPS” tab.
3. Connect Device to Proxy
Finally, tell your device to use your workstation as a proxy by going back to your mobile device’s Wi-Fi connection settings and entering your workstation’s network IP address in the proxy server field, including the port number you saw in the Fiddler settings.
Now all traffic from your device to the Internet will be relayed through your workstation, allowing LoadUIWeb to record it as a test. All you have to do is go into LoadUIWeb, click the "Record New Scenario" button, and use your app on the device.
We recommend that, as you use your mobile app or site, you annotate what actions you’re performing using the recording toolbar; do this by selecting “Manual Only” in the Pagination section of the New Scenario dialog. This ensures that you can organize the recorded traffic to your liking. You also don’t need to launch a browser, so uncheck that option before recording.
Once you record and annotate your actions, you’ll end up with a scenario definition that is equivalent to how your mobile device interacted with your Web app or site. Here’s an example of using Google on a Galaxy tablet (Android):
Now that you have an accurate recording of traffic from your mobile device, you can data-drive and parameterize your traffic as you would with any LoadUIWeb Pro test.
You may also want to change the connection speed on the load test, depending on the anticipated network infrastructure your mobile users might connect with. If people are using phones to connect to our app/site over cellular 3G/4G/LTE networks, you may want to select the “T1 (1.5M)”, “T2 (6.3M)”, or “LAN (10M)” accordingly.
See also:
[dfads params='groups=937&limit=1&orderby=random']