OK, go ahead... admit it. You listen to Sirius/XM Radio channels 8 and 9 only. You haven't noticed who the president is since Bill Clinton left office. If you haven't had your mid-life crisis, you're thinking about having it soon. And you may still call your test tool Mercury LoadRunner, refusing to acknowledge HP's purchase of Mercury since it happened eight years ago.

You want to get with the times, but you can't. Why? Because you don't speak the new language. And that language barrier is stopping you from entering the new world order in performance testing: cloud-based performance testing.

So, I'm here to help you feel young again with a language lesson. Today, we're going to translate your circa-1989 client/server tool terminology to today's web and mobile cloud-based performance testing language.

(To paraphrase a former University of Florida coach, Urban Meyer, who refused to ever mention Florida State University (FSU) during his entire tenure at the University of Florida -- instead calling them "that school out west" -- I'll do the same in this blog post. I will henceforth refer to that tool that had the lion's share of the marketplace and was named after a planet as "that tool out west".)

This blog post is a translator for anyone using "that tool out west". The goal of this post is to map familiar concepts within, say, a client/server test tool developed in 1989 to corresponding similar concepts in SOASTA CloudTest.

Cloud testing terminology and concepts

Both CloudTest and "that tool out west" require planning before creating performance test cases. The performance engineer needs to understand the system, user experience, and business drivers for load testing the system under test. The load test plan needs to identify test cases, Entry and Exit criteria, metrics to be collected, timelines, and include a final report.

Terminology Differences

1. An environment in CloudTest is very similar to an environment in "that tool out west": they are both web applications. Both of them perform the job of controlling virtual users for a test scenario, and both require a username and password to access and Performance Center manages and maintains scenarios. "That tool out west's" controller, the stand-alone solution, also does this. It is done by SOASTA’s repository in CloudTest. One important difference is that the SOASTA CloudTest environment incorporates load test creation, browser-based functional test creation, and can serve as a Load Generator, all in one platform.

1. A maestro in CloudTest is the same as a load generator in "that tool out west". In the case of SOASTA CloudTest, a load server can be local machine or it can be in the cloud. Deploying load generators in the cloud is cost effective and can simulate traffic from different geographic locations on the Internet. With "that tool out west", load generators are usually deployed locally. A recently announced version of "that tool out west" provides the ability to deploy both controller and load generator in the cloud, but this storm is still evolving and does not yet qualify for a name from the National Hurricane Center.

1. Analytics dashboards in CloudTest are similar to performance analysis in "that tool out west".

1. Virtual users in CloudTest are similar to Vusers in "that tool out west".

1. Clips in CloudTest are similar to Vuser scripts in "that tool out west".

1. A composition in CloudTest is similar to a scenario in "that tool out west". Both composition and scenario determine what should happen in a testing session with details about what test cases should be

Building scripts

"That tool out west" uses VuGen. VuGen captures all the recorded traffic based upon the type of protocol selected for the test.

With SOASTA CloudTest, recording is integrated in the product and uses an agent called the SOASTA Conductor on the machine from which recording is being done. The Conductor acts as a web proxy for capturing all the HTTP/HTTPS traffic when recording.

SOASTA CloudTest has the option of viewing recording in list and icon views.

Correlation

SOASTA CloudTest has a "Session Template Package Wizard" which is somewhat similar to "that tool out west's" "Scan Script for Correlations". However, SOASTA CloudTest scans for name/value pairs and not for differences between recording and playback. The Session Template Package Wizard identifies all dynamic values in the clip and required values can be selected from the UI.

Seed data

SOASTA CloudTest has a seed data repository, which is similar to "that tool out west's" parameterization functionality, but covering only the parameter type File. Test data can be stored within CloudTest or it can be hosted anywhere accessible by the load generators and used within a clip. Once test data is available, it can be used in a random fashion, as single shot data or unique data for each virtual user. This functionality can be achieved either from the UI or by using JavaScript.

Validation

CloudTest has validation functionality similar to "that tool out west's" "Content Check". The validations can be done within a clip/script and added for text, HTML, JSON, XML and SOAP. Validations can be done for data within the header or body. The validations can be added for each and every message within a clip. Similar to the content check functionality in "that tool out west", success and failure messages can be added as part of validations.

Collections

CloudTest can group multiple messages or pages as transactions (also known as collections) and metrics can be tracked in the analytics dashboard for a particular transaction. This is similar to the concept of transaction in "that tool out west".

Test compositions

For creating a test in CloudTest, one or more clips are added to a composition. This is similar to adding vu scripts in a scenario. The composition specifies load servers, number of virtual users, number of iterations, ramp time and duration of the test. This is like adding load generators, building a schedule, specifying duration and ramp up and ramp down for the test in "that tool out west".

Analytics

SOASTA CloudTest has extensive metrics in the analytic dashboards. These dashboards show real-time data, independent of the scale of the test. They are similar to "that tool out west" performance analysis. SOASTA CloudTest results can be viewed during and after the test execution and results can be exported in .csv, .xml and .doc formats.

Repository

The SOASTA repository stores results from the test. This is similar to the result directory in "that tool out west". The SOASTA repository can be maintained on premise or in the cloud and can accessed over the internet. In both cases, the client is an Ajax- based browser.

Monitoring

Just like "that tool out west", SOASTA CloudTest has integrated monitors for monitoring system utilization of systems under load. These monitors can be created as web monitors, database monitors, application server monitors, etc.

CloudTest can also integrate monitored data from third-party monitoring tools, such as those from New Relic, CA, Amazon, AppDynamics, Correlsense and more, displaying the results in the same real-time dashboards.

Takeaways

Now that you're up to speed on the terminology, let's keep the momentum going. Go ahead and download our free version of CloudTest, the performance testing solution used by every one of the top twenty online retailers.

And now that you speak the language, take the extra mile by getting trained and certified. Find out how here.

Once you are done with that, feel free to check out the other 220+ channels on Sirius/XM radio. And kiss 1989 goodbye. You deserve it.