longevity testing

  • perf-test.com need your contributions to build up a strong repository of performance engineering resources.

Hansraj

New Member
Aug 8, 2015
6
0
1
49
Hi All,

I've a doubt in longevity testing. Can somebody define what is longevity test and how do we configure that testing?

Hans
 
@Hansraj

I believe you are talking about soak test or endurance test or longevity test as you call it.

The test duration for all the above is defined by the application usage pattern.

As an example- consider a bank teller application which is going to be used by bank emplyees, who will login at 10 am and logout by 6 pm - so on an average 8 hour of continues usage. So the test design for such an application would be 8 hours.

There can be test designed for 8 hours, 12 hours , 24 hours or even days. hope this helps
 
  • Like
Reactions: Hansraj
Thank you very much Anmol. Information is very useful.

Let me share my understanding about endurance/longevity/soak testing.
For eg., I'm verifying a business scenario like "a user is taking a course". I want to test this scenario for 18 hrs soak test.
For this, does the user need to be logged in for 18 hrs without any gap in between? is my understanding correct?
 
@Hansraj Please clarify what is a course?
intention of longetivity tests are normally to test memory leaks - so at the end of test you need to verify all the system resources like memory are returned back to the pool.
 
@AnmolD Thanks for the reply.
Course means "attending for a online training class".

Let me give you the details about how are we doing soak test.
we scheduled soak test for a functionality with the following time slots:
6am-8am, 9am-11am, 12pm-2pm, 3pm-5pm.

My team says, longevity test we are running here is for 12 hrs with 1 hr cooling period.
My understanding is longevity test here is 120 mins only. there is no such concept of cooling period in performance testing.
Please clarify what is the actual soak test time here? What is this cooling period concept?
 
Normally a soak test would be a non-stop test. Running the system for a large number of hours with average to more than average load would constitute a soak test. This will bring out any memory leaks, memory fragmentation issues, connection leaks, garbage collection issues etc. in the system.

But there is nothing wrong in a cooling period during soak test, if it is emulating the real life scenario, one could create such a test case. E.g. of the students have a recess and during that if they are expected to logoff from the system and then are expected to relogin after an hour then this could be emulated in the soak test.
 
@Sundarraj,
Thank you very much for reply. I agree with your explanation.
We are doing soak test and burst test to test performance of some features. We are using Jenkin & Gatling tools to execute these tests.
We are getting 95th percentile, but looking for more information like at what request the performance is getting degraded.
Let me elaborate my question.
Lets say we are sending 100 requests per minute to the server and the response time is 3 secs. If send 200 requests per mimnute, the response time is 6 secs.
I want to find out exactly at what point of time, performance is degrading?
Is these any tool to find out this information?
Thank you.
 
After going through the discussion thread, these are my views:
We are talking about 2 different things. One is User Behavior and the other is Different types of Test.
In my opinion, the User Behavior will remain the same across Benchmark Test, Scalability Test and Soak / Endurance /Longevity test. It would depend on the User Behavior.

For eg: 1. For an internet banking website, a user would normally login to the system, do his transactions (like checking account balance, Fund Transfer etc..) and logout.
2. For a Data entry operator or Backend operator, the User would log into the system in morning and do data entry (like create / submit proposals, Submit transactions etc...) and will continue doing that throughout the day and will logout of the system at the eod.

The User behavior should remain same for Load Test and Soak Test. Only for some specific targeted tests like sync tests we would be altering the User Behavior, wherein we expect a very high concurrency on a specific screen. A good example would be Flash Sale screens for Mobiles on e-retailer sites.