The first step in performance or load testing a web application is to create a realistic test script. This script, representing a specific type of end user, contains steps that are fully automated transactions flows. Often, complex behaviors need to be emulated as part of these flows. To incorporate the needed behavior or to handle complex scenarios, testers need to customize these load scripts. The question is whether you utilize a tool that takes a GUI driven approach for script customization/manipulation, or whether you choose a tool which requires the use of a programming language.
As Performance testers, we typically evaluate several load testing tools before diving into a project. Some of us prefer the GUI driven approach to creating load scripts because, being results driven, we want to get the test up and running as quickly as possible. The GUI approach saves us time and there is no programming involved thus the learning curve is also extremely fast. These GUI scripts are typically easily modified by having their parameters and values organized in a visually obvious format. And just because a tool is easy to use, doesn’t mean that it’s only for beginners. Remember the good old days of MS-DOS? Eeek, thank goodness for GUI driven DOS (Windows).
Some testers (mistakenly) dismiss the GUI driven approach as being too limited for complicated behaviors. Old school testers insist on only utilizing program-based scripts because past experience has led them to think that this is the most flexible or the only choice for handling complicated behaviors. All too often, the perception is that GUI driven scripts limit the level of customizations possible to emulate a real user. This opinion is likely based on experiences with rudimentary GUI tools on the market that are too basic and limited in their capabilities such as handling dynamic content and varying the transactions flows.
However, there is a new breed in load testing solutions, designed and built to handle the most complex advanced scenarios. These are true enterprise-class solutions which provide a hybrid approach by containing both GUI and programming features. The power behind this hybrid approach enables the user to emulate even the most complex behavior but it also includes time saving features which can only be offered by a GUI solution.
Let’s get really technical for a minute to highlight an example: Some tools provide the common “programming” tools like loops and conditions. Recorded values of parameters are easily replaced by variables with a click of the mouse. NeoLoad, an example of a modern enterprise solution, goes further to provide even more advanced features. Some specific examples include: 1) “Wait Until” Action to the current execution thread until certain conditions have been verified 2) “Shared Queue” Action to use values from one VU’s response as input in an entirely different VU execution 3) a “While” Action allows various transactions, such as web pages, to be iterated while a condition remains false 4) “Try …Catch” Action to break out of the script based on Validation or Assertions and go to the End phase. The use of nested actions creates even more complex behaviors. All of these advanced scenarios are accomplished without programming! PUSH technology which is rapidly being deployed in today’s RIA’s adds even more complexity. With asynchronous updates pushed to/from the page independent of complete page refreshes…imagine this programming nightmare! NeoLoad has a way to solve this problem using cutting edge technology that can “listen” for PUSH behavior (all polling or streaming requests) and wrap all these asynchronous requests into a GUI fork Action, even calculating the average time interval between execution, then presents you with a newly modified script to emulate these load pattern characteristics. Again, all of these GUI centric features allow further manipulation without the need for programming.
As the script becomes more complicated, it’s nice to have this hierarchical GUI-type view.
New breed solutions not only allow for complex behaviors…the GUI approach has other time saving embedded assets. To handle dynamic parameters, NeoLoad is delivered with an ever evolving list of known architectural framework dynamic parameters which are automatically detected and handled by a wizard. The search and replace feature finds strings embedded in any request (body, header, URL’s, XML tree, partial matches, etc.) and replaces or concatenates to the string with any data or variable – choose to replace entire string or just part of the string. There’s an automatic extraction feature to take data from any response and use it to populate the value of a variable. You can enable/disable specific transactions at a page level or embedded request level which a click of the mouse to isolate transactions of interest. Target an entirely different QA/Performance/Production environment – change the Servers field from host where you initially made the recording to the new server name and port. Debug scripts easily using the side-by-side comparison feature with a tab isolating only the differences of recorded vs. replayed values.
From this perspective, the great debate over choosing a GUI driven or programming approach is over…eliminate the tradeoffs and choose a hybrid which has a powerful GUI and also extends the flexibility for programming. Skip most of the manual programming and only use coding where it’s required. Both experts and beginners can agree there is now a solution which meets all of the load & performance testing challenges of your own unique web application. Introducing the “GUI hybrid”.