![]() In the example above, we’ll use an online public demo e-commerce application called “JPetstore,” in which you can shop for animals to purchase. For now, let’s focus on how to handle a parameter, once you recognize it is dynamic. ![]() When it comes to request comparison to identify dynamic parameters, NeoLoad delivers a side-by-side view. If a session ID that is assigned is invalid, you will likely generate a 403 or 500 status code. Pay attention to any errors in responses that might give clues to what was sent improperly. There are some fundamental ways (which this article will not go into), to help with identification - one common practice is to compare a recording to a playback of the same script, looking for value similarities. Being able to determine what parameters are dynamic is equally as important as how you’re handling them. ![]() Using static values from a recording will result in script and load test failure. Dynamic parameter identificationĪs you can see, it’s important to identify and handle parameters with dynamic values. This is why it is essential to ensure that you’re using dynamic parameters. No matter how it is dealt with, when a user (or virtual user) visits a website, it is given unique session info that is either valid for as long as the browser is open or for a specified amount of time. While NeoLoad typically handles session IDs very well, it can just as easily handle complex methods and correlation. The value can sometimes incorporate a timestamp (see above) or other more complex factors, which may be in the likeness of “jsessionID” or UUID. This particular parameter will contain an alphanumeric value that is stored in a cookie, form field, or URL. Session identificationĪlmost all web applications use some form of session identification to designate an individual user’s application access time, thus making it unique. With NeoLoad, you can replace this value with a variable based on current date using the current time in milliseconds pattern (Epoch time). If you try to replay the script using this value after a day or more, the server is likely to reject your request, yielding a script error. ![]() It uses a value of “1519246164376” for the “random” parameter, which is the equivalent to Wednesday, February 21, 2018, 3:49:24.376 PM GMT-05:00 (Eastern US time zone). Take this screenshot below, for example, using a Google Ad Services request. Most web applications use Epoch timestamp values, or current milliseconds from January 1, 1970. Since time is something specific to when an application and user is accessing the application, the value will eventually become invalid and need to be replaced with a variable that makes it dynamic. Some examples of unique dynamic values that web applications use are in the form of timestamps. The time saved can be significant, which makes your job easier and less stressful. This allows NeoLoad to search for dynamic values throughout your script and automatically handle the correlation. Once you identify what is dynamic in your script and create correlation for it (extraction using a regular expression and replacement), you promote it to a Framework. This can save hours and days designing and maintaining a script in preparation for load testing. Some tools, like Tricentis NeoLoad, can automate handling the many occurrences of dynamic parameters through a feature called Frameworks. The handling of these static values so that they appear dynamically distinctive each time a load test runs is called correlation, or what many refer to as-as the bread and butter of “design.” Many of the best load testing tools aid in the identification and handling of dynamic parameters. Some of these parameters include session IDs, tokens, timestamp values, and universally unique identifiers (UUIDs), and must be different every time the script runs. The initial static values are no longer valid and were usually specific to the original recording, but not suitable for any playback of the script. Why is this important? If left unmodified, these parameters with recorded values will play back to the server in their original value(s). With any typical user session accessing an application server, there are parameters (and values) that give this specific session its unique fingerprint. The “script,” in its raw form, is usually a recording of an emulated user interacting with the application. Designing a load test involves the creation of a script - a set of calls, requests, and actions to an application server.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |