Web applications are a lot more complicated these days than even a few years ago. We don’t hear a lot these days about Web services as a development technology, but virtually every Web application that uses commonly provided services will access those service via traditional Web services technology. If your Web application reports on the weather, or provides a stock market update, you are using a Web service. A Web service uses HTTP, but it runs the SOAP, REST, or similar protocol over that. And if your stock market updates are slow or accumulating timeout errors, chances are you are going to be losing traffic and eventually users.
In the 2013 R2 release, testers want to be able to easily capture and filter Web services traffic, so that you get exactly the traffic you’re looking for, without calls to extraneous servers or components. In the past, we’ve been able to capture traffic using the Fiddler tool. Starting with Test Studio 2013 R2, we can capture all Web services traffic from within Test Studio itself, and design and run a load test based on that traffic.
How about mobile? With web applications increasingly being used by mobile devices, it only makes sense to be able to load test with those types of devices as a part of your traffic. If teams want a truly representative load test with half their traffic coming from mobile devices and half coming from desktop web browsers, they would need to be able to capture, play, and execute profiles from those devices.
Now you can do that with Test Studio. If you have an a good idea, or even a reasonable guess, as to what kind of devices your traffic will be coming from, you can combine that into one load test, and run that test. It looks like the traffic could be coming from a desktop thick client, Web browser, or mobile device, and it aggregates that traffic into an overall picture of load. You can even do sensitivity or “what if” analysis, changing the mix of traffic to see how it affects your application’s performance. As mobile traffic grows, this will become a necessary part of testing in the not-to-distant future.
A last for Test Studio 2013 R2 provides more flexibility in working with cookies. Rather than dependent upon a cookie existing in the browser at a given time, you can insert that cookie, as a Web application may do when a user logs in. The cookie can be inserted into a load testing script, or the script can simply bind data to it.
I’m excited about this and other new capabilities that we’re building into Test Studio 2013 load testing. In our release earlier this fall, we included the ability to both schedule and remotely execute load tests. That meant that you weren’t dependent upon a single machine, running now. Instead, you could deploy execution agents to multiple machines across the network, to better simulate the actual location of your traffic. And you could do so at noon and at midnight, weekday or weekend, without having to actually be there.
Load testing is an important part of what we are doing with Test Studio, because we recognize the vital role it plays in making sure that your web applications are tested and will stand up to actual traffic under deployment. You can look forward to more load testing releases that will give you more flexibility and features in setting up, running, and analyzing load tests.
Peter Varhol is an Evangelist for Telerik’s TestStudio. He’s been a software developer and software product manager, technology journalist, and university professor among the many roles in his past, and believes that his best talent is explaining concepts and practices to others. He’s on Twitter at @pvarhol.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.