Mobile Device Applications Testing Tips - Stress Testing

Although mobile device’s memory and power have improved over the past few years, mobile applications still have much more memory and CPU constraints than desktop applications. With users expecting applications to hold up even under high traffic conditions with many applications running, stress testing is a must to find exceptions, hangs, and deadlocks that may go unnoticed during functional and user interface testing.

Techniques

The following are some stress testing techniques to try:

1. Load your application with as much data as possible to try to reach its breaking point. For instance,

Windows Mobile devices can accomplish this with either ActiveSync (Windows XP) or Windows Mobile Device Center (Windows Vista and newer). This will give the user full access to the Windows file system on the device to add needed testing files where they are required.

2. Perform the same operations over and over again, particularly those that load large amounts of data repeatedly.

3. Perform the repeated operations at varying speeds – very quickly or very slowly.

4. Leave your application running for a long period of time, both interacting with the device and just letting it sit idle, or performing some automatic task that takes a long time (like displaying a 200-photo slideshow).

5. Randomly send screen taps and keystrokes to your application.

6. Have multiple applications running on your device so you can switch between your application and other device applications often, and at different states within your application:

a. On Android or Blackberry you can press and hold the hard Home or Menu key, respectively, to quickly switch between running applications.

b. Use all means to launch your application, for example on Windows Mobile use the Touch Flo, the file explorer, and if the application is already launched, maximize and minimize the application.

Non-reproducible issues

Another general tip related to stress testing – do not be afraid to report bugs that you haven’t yet found a way to reproduce 100% of the time. If you can at least provide crash logs and a best guess as to how to trigger the problem, that is usually enough to give the developer some ideas on narrowing down the root cause.