West Wind Web Surge Features
The following is an overview of features along with a number of screen shots to demonstrate WebSurge's features.
Effective URL and load testing testing starts with capturing or creating URL sessions that can be managed and saved easily. WebSurge makes this process as easy as possible to remove as much friction from the process as possible to encourage frequent creation of sessions to run tests on.
WebSurge lets you capture or enter full HTTP request data in a number of different ways:
- Built in HTTP Proxy Capture
- Manual entry of HTTP Request through the UI
- HTTP Request Traces in a Text File
Using the HTTP Proxy Capture Tool
The easiest ways to capture URLs that make up an HTTP session is by using
the built in URL capture tool. It uses an HTTP proxy to monitor your HTTP
requests on your machine and automatically captures the request data into
HTTP session files.
Using the capture tool (File | Capture Session or click the Capture Button on
the Session View) brings up the capture form which looks like this:
As you capture the capture window shows a live tally of captured requests. When done press Stop Capture to stop the capture. Once done you can then save the captured data to a file which becomes a new session file that is also automatically opened in the main WebSurge testing window.
Manually creating Tests
Of course you can also create request data manually using the WebSurge Request entry form. This form makes it easy to create requests by hand. You can add all HTTP specific information including URL, headers and content for each requests.
Note that you can easily add any kind of HTTP header or content. This allows you to create either plain GET requests, or more complex POST/PUT/DELETE requests that actually push data to the server. Since all of HTTP features are available here you can easily create any type of HTTP request.
Once you've entered a new request click the Save Button which automatically adds the entry to the current session displayed in the list on the left. Click the Save button on the Session window to save the Session to disk at any time.
You can also easily copy an existing request to a new request. Frequently when creating request urls by hand headers and content are very similar between requests and this option makes it easy to quickly modify an existing request to create a new one.
You can also easily test requests by clicking Test button or Alt-T on the Session window to run the selected request and display the results. This is great for quick individual URL testing, or even for testing REST APIs during development or adoption of an existing API from a vendor.
The Test form displays response headers and the raw response of a request. If an error occurrs the HTTP error message and status code is captured and displayed prominently on top of the entry. Notice the Show html button on the result form - it'll let you view rendered HTML which sometimes facilitates understanding the result rather than looking at a HTML text display. Likewise JSON and XML responses can be displayed as pretty formatted documents that are easier to read than the raw data.
Header Overrides for Authentication and Cookies
One important thing that happens when you create or capture requests is that headers get created with token from the current capture or manual entry. However, cookies and auth tokens expire, so existing captured sessions go stale and test that worked previously no longer work.
In order to get around this you can override various headers and request values via the options that are tied to a session as a whole. For example, you can force replacement of Cookie values or Authorization header, replace query string values or override the domain for each request.
The values set in this dialog are Session specific and are saved along with the Session HTTP data when you save a Session.
To use this feature when your cookies/auth headers have expired, you can capture a valid request that has the appropriate cookie and/or authentication header. You can use the WebSurge Capture tool, any Web Browser DevTools (f12 tools) or an HTTP proxy like Fiddler to get the updated header values. Simply copy the header values and paste them into the options form. Then re-run your tests - the options values override the originally captured values for each request tested.
HTTP Trace File
You can also enter requests into WebSurge on a lower level by directly manipulating the raw session trace file. Web Surge stores Session data as raw text files that are simply delimited HTTP headers. The format used is also shared by Telerik's Fiddler, and simply contains raw HTTP headers with a delimiter between requests.
You can manually create sessions simply by creating or editing these text files either by hand or under program control. From within WebSurge you can click the Edit button on the Session tab to bring up the raw session file. If WebSurge is running and you opened the file from within it any changes you make and save to disk are also immediately reflected and applied back in the Session list in the UI.
We believe that one of the biggest obstacles to Load Testing and URL testing in general is usually the process of creating sessions. By providing several different approaches we give you lots of options from automating capture from applications, to manually creating requests either in the UI or in the text files directly, or by allowing you to generate requests easily using any tool that can write out a text file.
There's no excuse, so "Get testing!"
Load TestingLoad Testing is Web Surge's main feature of course is load testing. Running tests is very straight forward: Fill in the number of seconds to run the test for and the number of simultaneous session you want to run. Then click start and off you go.
As you run the test you see a console view on the right that shows active requests being process along with a running total in the lower right hand corner. The console view can be turned off for high volume tests that generate 1000's of requests a second to minimize CPU load of the application but for request/sec of under a couple of thousand the display is fun to watch.
On the bottom is a summary display that shows the number of requests processed along with an average request per second calculation for the test run. The running total shows in green if there are no errors, but if error requests are hit changes to red.
Once the test is done you'll get to see a summary results view:
The results view summarizes the entire run at the top, and then also displays information for each individual requests show average request length and the number of requests that succeeded or failed.
To drill into individual requests click the Results tab on the left and click on any entry in the list which brings up a detailed raw HTTP view of that request and response.
You can review both the request and response headers and you can click on the original URL to directly access the request (realistic only for GET requests). You can also click on the Show html/json/xml link to display either the rendered HTML or pretty formatted JSON or XML. Note that only a subset of requests is displayed and editable in this fashion.
You can also click the Graph link to quickly view the a requests per second view over time of the test.
Other charts let you see request times charted either for the whole session or for individual requests.
Finally you can also export the result of a test to a raw HTTP trace, JSON or XML document. HTTP trace results can be re-imported so that you can re-examine previous test runs by using the Import WebSurge Results from the results tab's context menu.
Command Line Operation
WebSurge also supports command line operation, so you can automate load tests from other operations or development environments.
Command line operation allows running tests for individual URLs very quickly:
or you can run a full session file:
c:\> websurgecli c:\temp\MyDailyDosha_Session.txt -t20 -s10
There are a number of options available to control how long the test runs (-s) and how many instances are used (-t). You can also control how the output is handled, either continous, minimal or just the summary.
Commandline operation allows you to very quickly test a single URL or an existing session with just a single command. You can also easily integrate WebSurge into a build process by running short tests and checking for failures and or slow response times beyond expected values.