Thursday, May 2, 2013

Why we have to parameterize the values in LR scripts?

As already mentioned in the previous article () we have the below four situation, where we need to parameterize the values.
1.    Unique constraint
2.    Date constraint
3.    Data dependency
4.    Data caching
Click here to know more

1.    Unique constraint: This is the first reason to parameterize is to accommodate any field that requires a unique value. Suppose we take banking application while a virtual user is logged in with the username ‘Sam’, any other user who tries to log in with the same username will get an error, causing a failure in the execution of the test script. Since each login attempt needs unique value we have to provide a unique username, a static value in a script will not work.

2.    Date constraint: A date recorded into a script yesterday may be invalid today. This is a problem that can be remedied through the use of parameterization. For example take an example of gym application for setting up meeting with physical trainer in this case it is quite possible that a script generated a week prior to the test run worked fine on that day, but is now causing errors in the test execution. This can be fixed with a parameter that will always select a current date +1 for the meeting schedule.

3.    Data Dependency: In this case the parameterized value for an object on the application determines what values are valid for another object on the application. As we take the example above, the login Password is dependent on the User Name. If the username does not change, then the password will always match. If the User Name field is parameterized, however, then the value will change during test iterations. Since there will only be one valid password for each given User Name, the Password field is data-dependent on the User Name field. Hence, the Password field must also be parameterized with passwords that match the usernames.

4.    Data caching: Parameterization reduces or eliminates the effects of data caching. Data caching problems will not cause your script to fail, but they may cause load test result to be misleading. For example, an application is being tested to ensure that data requests return results within an average of 2 seconds. First, we run an unparameterized search, then a parameterized one. When the first virtual user makes a request, the information is retrieved from the database and is returned in 3 seconds. Since the data was just retrieved, a copy is now available in the data cache. When the second and third users request the same data, they retrieve the data from the cache at a much faster rate. The average seek time for these three users is 1.5 seconds, which would appear to be under the benchmark. But since real users will not always request the same data, the average seek time is unrealistically low. With a parameterized script, each virtual user is searching for a different string of data, so requests are processed by the database instead of the cache.

Stay tuned for more funJ.  Yes, of course Load running is always a fun ;)

No comments:

Post a Comment