Developing a web or mobile application takes a lot of effort, but all that effort can go down the drain quickly if you improperly load test the application or completely skip testing. Load testing applications is important and a necessary step in the pre-production stage. New applications, ones that have not yet made it to the production stage, likely don’t have a performance benchmark established. You don’t typically know what to expect with a new app, which is why before you do a larger load test on any application you first do some baseline testing. This will allow you to establish some benchmarks and pick out any performance issues before you place a larger load on the app. For example, if your app crashes with just five users, you have a problem. Look to the application architects to determine if any service level agreements have been set for the application during design. Once you have done some baseline testing you are ready to load test your application to determine its performance levels under heavier load. Here are 5 essential tips for starting load testing on an application.

1. 5ESSENTIAL TIPS
Load BeginnersTesting
FOR

2. We get it.

3. Software Development is no walk in the park...

4. It’s not as easy as pie.
Or a piece of cake...

5. Okay, we’re done with the clichés.Promise.

6. And adding load testing to the mix (which is highly
recommended to keep users happy with your application),
increases your difficulty level.

7. “Do I have to?”
Yes. You have to. Fight through the pain,
embrace the struggle...
and load test.

8. Load Testing:
The process of putting demand on a system or device and measuring
its response. Load Testing is performed to determine a system’s
behavior under both normal and anticipated peak load conditions.
You ready for those 5 essential tips?
Let’s Do It.

9. 1 CALCULATE THE
NUMBER OF USERS

10. When you load test, you have to determine
the number of users you wish to simulate.

11. Don’t worry, you don’t have to guess!
Math nerds rejoice!
That’s right...
We’ve got a formula for you.

12. Number of pages viewed per hour (PPH) –
this figure can be extracted from your Web server’s log file
Number of pages viewed per user (PPU) –
that is to say the number of pages in a representative test case
User duration in minutes (UD)
The calculation we use requires three variables:
*
*
*

13. # of Virtual Users Required
((PPH/PPU)/60)*UD
The formula looks like this:

14. Keep in mind, this basic calculation assumes a constant
load over an hour meaning it does not take into account
things like load ramping or traffic spikes, so you’ll need
more virtual users when testing with these conditions.

15. It’s probably quite obvious that if
application performance is...
bad for a small
number of users,
then it’s no bueno for a
large number of users.
Run a small test first. Once the application performs well with a small number of users, add more!

16. 2 GET OTHERS
INVOLVED

17. You’re going to need to collaborate and
communicate across three departments.
THE TESTING SIDE THE DEVELOPEMENT SIDE THE OPERATIONS SIDE

18. “WHAT,WHY?”
Testers may not know much about the application’s code, so a developer
will need to inform the testing team of any changes to the code before
the application undergoes testing. If a person from operations isn’t
involved from the beginning, then testers may not have the analytics of
the application from the production environment.

19. Involving all three of these groups will
create a stronger team dynamic that
will result in an accurate depiction of
the application performance.

20. 3 DETERMINE YOUR
TEST CASES

21. In order to
know what test
cases to implement,
you need to understand
the paths that users are
taking through your application.

22. Crack open your site analytics, your app analytics,
and the log files from your web server.
Study how users are traversing through the application –
as well as how many there are, where they are coming from
geographically, and the types of browsers and devices they use.

23. It’s important to put this data in the context of
your application architecture, so that you can
pinpoint bottlenecks and develop a
comprehensive set of tests to exercise them.

24. You will then be able
to see how your
application performs
under a somewhat
realistic load.
Once you
assemble this
information
together...
You can create a test plan that
simulates observed behavior using virtual
users on emulated and/or physical
devices and across geographic regions.

25. 4 YOU CAN’T MAKE
ASSUMPTIONS WITH
AN INEXACT TESTING
ENVIRONMENT

26. Can I extrapolate results based on smaller number of users?
Can I extrapolate the results in the testing environment with a
smaller proportional number of servers to the production environment?
Can I assume the performance results from an inexact testing environment apply to my production environment?

28. There is a nonlinear relationship between the testing
environment and the production environment if the
testing environment is not an exact mirror of production.
However, mirroring production exactly with the same
infrastructure and configuration can be quite expensive.

29. So, what’s the solution?

30. The truth is that you want to make your tests as
realistic as possible, but no test will ever be perfect.

31. You can still find and fix
performance issues in an inexact
testing environment, and for those
who can get permission to do so,
testing in production on off hours
may provide even more accurate
results than a mirrored testing
environment.
Remember
that the goal of testing
is to minimize risks.

32. 5 TAKE TIME
TO ANALYZE
YOUR RESULTS

33. Load and performance testing is typically one of the last steps
in most development cycles and is often rushed as a result.
This means that testers may
gather a heap of performance
metrics that may be overlooked
because of a looming deadline.

34. Results analysis is critical.
It allows you to pinpoint
smaller issues in your app
or the infrastructure itself.
Don’t cut out the analytics; take the time
get to the root cause of issues from build to
build before they snowball out of control.

35. But seriously...

36. Load test for the sake of your users.

37. If you have any questions,
contact out performance experts.
HAPPY TESTING!
Load testing is a necessary step to ensure
the performance of your application for end users.
Take the time to find the best tool for you.

38. HORROR STORIES:
PERFORMANCE TESTING
TALES FROM THE SCRIPT
You often hear horror stories about testers who get blamed for an application’s
crashing despite having to use poor testing conditions, or a performance
engineer who tested inside a firewall then saw an app fail in production. This all
happens with the spectre of time and resource pressures looming overhead.
As the former manager of a load and performance team, Brad Stoner has a
number of haunting stories from his days in the field that carry insightful lessons
learned about load and performance testing. Watch this webinar to learn:
- The first performance test you should run on your app
- How to use the results of a test run in a non-production environment
- How testing inside the firewall can come back to haunt you
- The most critical test to run
SEE THE FULL WEBINAR
__________________________________________________________
Performance Testing Horror Stories
Tales from the Script
Brad Stoner
Senior Performance Engineer
Neotys

39. ABOUT NEOTYS | www.neotys.com
Neotys is a leading innovator in load testing and performance monitoring solutions for Web and Mobile applications.
Neotys’ products NeoLoad and NeoSense enable Development, QA and IT Operations to quickly and efficiently test and monitor the
quality, reliability and performance of their applications. More than 1500 organizations globally have selected our solutions because
they are Agile, easy to use and support all RIA and Mobile technologies.
For more information about Neotys and NeoLoad visit: www.neotys.com or contact sales@neotys.com.
CONTACT US
US: Tel: +1.781.899.7200 | EMEA: Tel: +33.442.180.830
EMAIL: sales@neotys.com | LEARN MORE: www.neotys.com