Here's a Quick Lesson in Cloud-Based Performance Testing
Here's a Quick Lesson in Cloud-Based Performance Testing
Performance testing is widely used. With wider adoption of cloud, it's important to ensure great performance. Here's a quick breakdown of cloud-based performance testing.
Join the DZone community and get the full member experience.Join For Free
xMatters delivers integration-driven collaboration that relays data between systems, while engaging the right people to proactively resolve issues. Read the Monitoring in a Connected Enterprise whitepaper and learn about 3 tools for resolving incidents quickly.
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.
“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.
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.
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.
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”.
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”.
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.
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.
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.
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 200+ channels on Sirius/XM radio. And kiss 1989 goodbye. You deserve it.
Published at DZone with permission of Dan Boutin , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.