Is there a way to perform Load or Stress testing of a Mobile application using Appium?
let me elaborate , very first thing,What do you mean by load or stress testing of mobile application? Is ur mobile allow to launch multiple instances of same application from one device? Obviously “No” right? You can do load testing on request and response, which does not matter you generate load from web browser or mobile application. so better to use Jmeter/Blazemeter/Gattling or any other open source load testing tools to generate load, you need to measure performance of your server, not your mobile application.
Second, for you performance testing is just measuring resources (CPU/Memory/Battery/Network Bandwidth) then i would say you need to baseline such parameters. Like my device (With specific hardware specifications) runs test application alone (Note: no other application running to your device), you can memory,CPU and Network, you can measure using DDMS. To measure battery you can install couple app available (Here, you should not attach your device with USB).
In above case, appium can not help actually because its functional testing tool.
Makes Sense. Thanks @Priyank_Shah
But we can find client memory issues with looping test for a long time and see that client will alive.
Or making scrolling large data in loop e.g. we have large list of objects on some screen.
Similar client perfomance tests are possible with Appium.
@Aleksei, you can do but again this is not performance testing, I would say this is benchmarking. To do this better approach is always do manual way where you can easily monitor memory footprint and also check crash occurred due to OOME.
i agree with you that it is not performance. but disagree that i need to make it manually we successfully managed to execute similar tests with iOS and Android in automatic way to monitor that application able to execute tests that fail before due to OOM issues.
10-15 min boring manual test - that is exactly what automation is needed for
Performance test is a rather vague term also. From mobile testing side, it could be explicitly defined further into these types of tests:
load test the server/cloud with many instances of mobile app running - which can be simplified as HTTP/REST/web socket traffic load against the server/cloud and abstracted away using JMeter/gatling and like tools, perhaps using proxy recording of mobile app traffic to then modify and replay at scale, if one doesn’t want to code the requests and validate responses from scratch
mobile app performance test, which could be broken down further into
- usability test - how well does the app perform/run when device is not stressed (e.g. just powered on, void of any other apps installed, much free memory and RAM) VS when stressed (low memory, cpu starved, low battery, etc.)
app stability test - say have app running (a long time, say indefinitely) in foreground (maybe alternatively background) mode, whether left idle or constantly performing activity on it, will it stay up (and responsive?) or will it slow, crash, leak memory, etc.?
device performance test - about the same as app performance on the software/driver side, but more focused on the device in general testing with various apps rather than focus on a particular app. This is likely not what most people test unless one works for a device manufacturer.
For mobile app usability/stability test, Appium could be useful, if used correctly. Because testing the usability aspect gets repetitive with the repeated workflow and all that stuff. And for usability in terms of response times, you can do the time calculations with code rather than a stopwatch. I am not sure, but assume mobile app timing evaluation in code may be easier than mobile web or web if mobile apps don’t quite have AJAX-y behavior where a page is loaded but not actually fully loaded (according to Appium), thus giving false positives (or rather incorrect calculations).
On the stability aspect, for the work that I’ve done, Appium could come in handy as a “monitor and controller” tool to ensure the mobile app is still running on (physical) device, and if not, to restart the app as needed. I did a proof of concept for that, but never got to really deploy, test, and use it due to our particular use case needs coupled with costs to deploy this for iOS - a lot easier for Android, but we’re focusing on iOS at the moment. For us the app crashed often (within a few hours of running in foreground) and sometimes less than an hour, so having a scripted solution that involved Appium to check if it’s still running and if not restart it is helpful. Manually going over to the device in the lab and restarting it is a pain. One could say why not deploy with cloud device services or something like https://github.com/openstf/stf? For us, we need to test device specific features with the app (e.g. BLE) and some other devices interacting with it, that you could not do shove into a contained device lab (whether internal or external), plus working at a cash strapped startup, can’t afford the luxury of a fancy lab setup. Dealing with iOS close ecosystem makes it worse in terms of $$$ for the lab setup.
Hello, is it possible for you to provide which tools and how did you actually achieve this?