This post (going forward all my posts!!) is/will be my best
shot at explaining what I have learnt in my past experiences, how I learned,
and what I think would be the right thing to do for a performance test.
Performance testing is a category of testing that often
considered to be a high profile testing that evokes strong feelings in people:
feelings of confusion (What really should I concentrate in a performance
test?), feelings of fear (There are so many metrics in the world, what should I
really care!), feelings of inadequacy (What tool should I use, Will the tool
help me to find the bottlenecks!!), feelings of confusion (When should I stop
my performance test?)
May be my blog could answer some of your questions. Please
feel free to write to me in-case if your questions are unanswered or you feel
the contents could have been much better.
My target audience would be the newbies to performance
testing and who has least experience in performance testing.
So what is a performance test in simple terms!!
It’s a process of validating an application in terms of
responsiveness and stability. Say, you have a shopping cart which is going live
next month. Definitely you would have done many rounds of development and
functional testing to ensure the product is bug free. But there is another
dimension to the quality attribute which is called PERFORMANCE.
What happens if the customers’ lands up the home page after 5 sec? Don’t
we lose the business? I am pretty sure, we will!!! So this puts the performance
testing a mandatory one. By end of your performance test, you can guarantee
that your system doesn’t break under heavy load and renders its response within
the expected time. So a performance tester will be able to answer the following
questions:
· Speed
- Does the system
respond quickly enough?
· Capacity
- Is the infrastructure adequate?
· Scalability
- Can the system grow to handle the future volumes?
· Stability
- Does the system behave correctly
under load?
How is
a performance test classified?
When the primary objective of your testing differs, the
performance testing is evolved to different flavors and is called by or
categorized under specific names. So now let’s take a look
what are the different flavors of a performance test.
1. Load Test: This is one usual name that
everyone has heard of. Also, this is a common type of testing that all
performance testers do. This testing primarily assess if an application can
handle a certain load level without degrading the performance. So typical measure
is to ensure if the product/system renders the response within specific time
under specified amount of load.
Simple example: You have
email application which expects traffic of 1000 users at a time. If you need to
assess if this application can take up this load, then might want a load test
to carry out.
Parameters to look:
Response time, Transactions/sec
2. Stress Test: This
testing pushes an application beyond the expected load conditions and evaluates
the system in terms of performance under the stressed condition. And some
people go beyond and test the crashing point of your application.
Simple example: With the
same analogy(email application), if you keep increasing the load(say 1500
users) and test, then you are carrying out a stress test. Say your application
behaves well under the stress; you can certify that application behaves well
under the stress. But if you want to know the crashing point of your
application, you can keep increasing the load and break your system. If your
system breaks down at 1600 users, then this is your crashing point beyond you
cannot expect your application to withstand further load.
Parameters to look:
Response time, Transactions/sec, Hits/sec
3. Capacity Test: This
test is primarily carried out to determine at how many users your application
can handle before the performance or stability becomes unacceptable. By
knowing the number of users your application can handle “successfully”, you
will have better visibility into events that might push your site beyond its
limitations. This is a way to avoid potential problems in the future.
Parameters to look:
Response time, Transactions/sec
4. Endurance/Soak/long
duration test: This determines if the application’s performance is stable
over time (say 8-10 hours). Sometimes, an application may work well for an hour
or two, but then start to experience issues. This type of testing primarily
reveals if your application has any memory leaks, file descriptor leaks (lets
discuss what these leaks are in other posts).
Parameters to look:
RT distribution over time, Memory usage, TPS trend over time
5. Volume testing – This testing is primarily done
to identify if server can handle specific volume under a given time. The system
is run with maximum amounts of data or databases, files, disks etc. are loaded
with a maximum of data.
Parameters to look:
Response time of DB queries, no loss of data.
No comments:
Post a Comment