Help

JBlitz Professional works with test configuration files. These files are XML based user-editable files which specify all the details of a particular test environment. These comprise:

• The target website / IP address. The server to test.
• The test cases - the sequence of URLs that will be targeted.
• Error detection settings. Detecting error pages and specifying error return codes.
• State maintenance options. For example, enabling cookie support.
• Request headers. These can be tailored to suit your server.
• Logging settings. What to log and where to log to.
• Authentication details. Basic authentication only currently.
• Run control information. Whether to run indefinitely or stop after some time limit or hit count.

Work with these files just like you would work with a spreadsheet or text document. Open them, edit them, save them etc. You can maintain a directory of configurations for different test scenarios.

Typically, you would start with a new test configuration (one is created for you on startup), use the UI to enter all your test settings (including target website, target web pages etc), save the configuration to disk and then run it using the green arrow toolbar icon or pressing the F8 key.

You can open a new configuration file (as long as a test run is not ongoing) by selecting File->Open menu option or by clicking the toolbar open icon. If necessary, JBlitz will prompt you to save your current configuration. Your new configuration will be loaded into the tool and you should be ready to go with these new settings.

On startup, JBlitz will reopen the previously opened configuration by default. You can change this behavior to open a specific configuration file by using the <config file> command line option.

You can save the test configuration that you're working on by selecting the File->Save menu option or clicking the toolbar save icon. JBlitz tracks your configuration to see whether anything requires saving, so this option will only be enabled if your test configuration has changed since it was last saved.

The following connection properties are configurable within JBlitz:

1. Host name or IP address. Specified under the 'Main Setup' tab at the top of the screen. An optional page-level override can also be specified if required via the page settings dialog.
2. Optional port number. Specified alongside the host name or IP address by appending after a colon. For example, www.mytestwebsite.com:8080. An optional page-level override can also be specified if required via the page settings dialog.
3. Optional proxy server host name or IP address. Specified in the proxy server settings accessible from the main menu Options->Proxy Server Settings...

See below for more details about how to configure each of these properties.

To specify this property, simply type the host name or IP address into the combo-box at the top of the 'Main Setup' tab on the main screen. The website is entered as, say, www.mytestwebsite.com (or the IP address will do) (important note - do not type in the protocol - e.g. 'http' - at the start - the protocol will be automatically assigned by JBlitz as 'http' for regular pages and 'https' for secure pages).

You'll need to ensure that a test run is not ongoing (press F9) and that the 'Main Setup' tab is selected. If you click the little down arrow to the right of the combo, you'll see the set of websites already typed into the box. You can, alternatively, select any of these as your website target.

When JBlitz is run for the very first time, the website combo contains the initial text <type your website here>. This is informational only. Please overwrite this text by typing in a valid website name e.g. www.an-interesting-website.com.

An optional page-level override can be supplied for the host. This allows you, for example, to make connections to different servers for different web pages within your test cases. It also allows for the use of sub-domains on some pages. See specifying page-level settings for more information.

You can specify an explicit port to use either globally or at the page level by typing it after the host name following a colon.

For example, to connect all pages to port 8080, select the 'Main Setup' tab of the main screen and type in :8080 after the host name so that it takes the form www.mytestwebsite.com:8080. To connect only a subset of pages to an specific port, you'll need to specify the port number in the page settings dialog. See specifying page-level settings for more information.

The following defaults apply if no explicit port number has been specified:

• 80 (http protocol)

• 443 (https protocol)

If you connect to the internet through a proxy server, you can configure the proxy settings using the main menu Options->Proxy Server Settings...

In this dialog, first click on the top check-box Enable Proxy Server to enable its use. Type into the HTTP Proxy field below to specify the host name or IP address of the proxy for regular requests. You should also specify the proxy port to the right.

The two SSL Proxy fields below are optional and only used for any secure (https) web pages that you may configure. If they are left blank and you do make a web page secure, the SSL Proxy settings will default to using the HTTP Proxy settings.

If authentication is required against the proxy, click the 'Authorization...' button and specify the user-name / password in the dialog.

Proxy server connection properties are stored in the jblitz.ini file and hence apply across all test configurations.

JBlitz tests distinct functional areas within your website or web application using what's known as a 'test case'. Test cases are no more than a sequence of target web pages to be downloaded and settings specifying how each download should occur and how each response should be checked. Once all pages in the sequence have been downloaded (in order), the sequence is started again.

A configurable number of virtual users are assigned to run through each test case. Each virtual user goes through the download sequence independently from every other.

Each test case has its own set of settings available via the test case settings dialog. These settings are distinct from the global settings shown in the tabs on the main screen. Global settings, such as HTTP response code checking or authentication settings, apply across all test cases.

Add a test case by clicking on the 'Create' button on the right hand side of the 'Main Setup' tab. Alternatively, the main menu item Test Cases->Create can be selected. To delete a test case, select the test case to delete and press the 'Delete' key or click the right mouse button and select the 'Delete' menu item. You can also delete the selected test case using the main menu item Test Cases->Delete. You can vary the number of test cases from 0 to 500 (NOTE evaluation restricted to 3).

You can cut, copy and paste whole test cases by selecting the appropriate option from the right mouse menu on a given test case, or choosing the cut, copy or paste icon on the main application toolbar. Test cases are represented as XML format text on the system clipboard.

If testing with a large number of test cases, you may want to ensure that you have a fast machine / processor and sufficient bandwidth on the connection to your site.

The evaluation version of JBlitz is limited to at most 3 test cases.

The test case settings are accessed by either double clicking on a test case within the 'Main Setup' tab, using the right mouse button and selecting the 'Settings' menu item or hitting Ctrl+G. You'll need to ensure that a test run is not ongoing (press F9) and that the 'Main Setup' tab is selected.

The dialog shows a list of the web pages that make up the test case. The pages are downloaded in order from top to bottom. To add a new page, click on the 'Add' button. To remove the selected page, click on the 'Remove' button. Modify the download order by using the 'Move Up' and 'Move Down' buttons.

The test case name, virtual user count, connection timeout and, of course, the web page itself are specified directly within this dialog.

The test case name

A descriptive name that JBlitz can use to refer to the test case. It can be any name of your choice.

 

The virtual user count

Specifies how many concurrent virtual users (modeled as threads), should be used for this test case. All virtual users compete for CPU time / bandwidth equally. The number of virtual users can vary from at least one to at most five hundred. If testing with a large number of virtual users, you may want to ensure that you have a fast machine / processor and sufficient bandwidth on the connection to your site.

 

The connection timeout

Specifies how long JBlitz should wait before abandoning a request for a web page. A timeout is treated as an error. Specifying a lower connection timeout can help make JBlitz more responsive when stopping a run. The timeout is specified in seconds.

 

The web page

Identifies the resource to download for this page. Type this into the combo-box or select it from the combo drop-down. Alternatively, clicking on the '...' button to the right brings up the Web Page Catalog which can be used to select a page that has been imported or used before. Further, clicking on the 'pencil' icon to the right of the combo brings up the Web Page Editor that gives you a broken down view of your web page where name value pairs in the query string are listed and separately editable.

The web page is appended to the host as specified in the 'Main Setup' tab of the main screen (or the page-level host override if specified) to create the URL to use. Normally, your web page will contain the relative path from the document root and should also contain any query string or entity data.

For GET requests, any applicable query string should be written after a question mark in the normal fashion. For POST and PUT requests, the entity (form) data should also be written following a question mark as if it were a query string. JBlitz knows to repackage the entity data appropriately for the request being made (this is just a convenient shorthand notation for specifying entity data).

The exact URL used to query any given page within a test case depends also on the navigation mode in force for that web page. The navigation mode allows you to either specify a URL to be used as-is, or to have JBlitz forge a URL by following a hyperlink or filling out a form contained in the previous page. See below for more information on how to specify the navigation mode for a web page.

To the right of each web page shown in the web page list, a series of 'dash' icons shows the presence if any of the following:

1. Page level error text detection
2. URL assistant
3. Response checker
4. Response informer

Double-clicking on any of these icons for a web page allows you to edit the corresponding setting. All of these settings are also available through the page settings dialog described below.

Edit the settings for an individual web page by double clicking on it, using the right mouse button and selecting the 'Page Settings' menu item or by selecting the page and clicking the 'Page Settings...' button toward the bottom right of the dialog.

The page settings comprise: Request method: Specify one of GET, POST, PUT, DELETE or HEAD. These methods represent different ways of invoking your server side script and are outlined further below. See the w3c site for more information. Download type: You can choose, for any page, to download it repeatedly each cycle. This is effectively the same as adding the page again and again to the test case, but is a neater way of doing it. Additionally, you can specify that the page is 'One-time only' where it will be downloaded on the first cycle through the pages, but not thereafter. This may typically be used for a logon page or suchlike that should only occur once for any given virtual user. Secure: Choose either a regular request (http) or a secure request (https) using SSL 3.0. Pause: Specify how long to pause after the page is downloaded. This setting can be used in conjunction with the throttle control to control the overall server load. Alternate host: Specify an alternate host to connect to for this web page only. Overrides the global default as specified in the 'Main Setup' tab of the main screen. Alternate port: Specify an alternate port to connect to for this web page only. Overrides the global default specified as part of the host in the 'Main Setup' tab of the main screen. Alternate request headers: Specify alternate request headers to use for this web page only. Overrides the global default as specified in the 'Request Headers' tab of the main screen. Navigation and state maintenance: Specify various settings controlling how JBlitz should navigate from the previous page to this one and for how any state data sent back in the previous page should be transferred on into this request: If you want your web pages as specified in each test case to be used 'as is', select Plain navigation mode. If your website or web application uses 'hidden' input tags or encodes a jsessionid into its URLs, select Name-value transfer navigation mode. To have JBlitz follow hyperlinks as if a user were clicking on them, or fill out forms as if the user were, select Follow hyperlink / form action navigation mode. More information is provided under Navigation and state maintenance. Errors: Specify search text that can signal that the response page contains an error. Further information Java: Specify URL assistant, response checker or response informer plug-in modules for your web page. These Java classes allow you to customize various aspects of the download quickly and easily. See the customization help for more.

Page settings

The page settings dialog can also be invoked directly from the main screen by selecting a web page icon and double clicking with the Shift key pressed down, or using the right mouse popup menu.

HTTP GET and POST requests can be used to transfer data, typically a series of name / value pairs, to the server and make it available to the server side script / program which forms the target of the request. For GET requests, this information transferred is called the query string. For POST requests it is called the entity or POST data. In additional to this, PUT requests can also be used to transfer entity data across to the server.

To simplify the JBlitz user interface, the entity data for POST and PUT requests is shown and entered as if it were a query string, i.e. it appears following the web page after a '?'. When requests are issued, JBlitz knows for each POST or PUT request to repackage the text following a '?' into the entity data.

As an example, if you had a logon script called logon.jsp that expected a user to be passed in using the name 'userid', the web page as entered into JBlitz would be:

/logon.jsp?userid=jim

even when the request method is POST instead of GET. JBlitz will handle the formatting of the correct HTTP request message in either circumstance.

You can get extra help editing the name value pairs appearing in query strings or entity data by choosing the web page editor. Go to the test case settings dialog (right mouse and select 'Settings' on the test case) and click the 'pencil' icon to the right of the web page combo.

Remember, specifying query strings and entity data becomes easier, more powerful and more flexible when dynamic substitutions are used to help generate the test data to be sent. For example, with POST and PUT requests, if the entity data to be sent is contained within a file, you can use the file content substitution %x and simplify your URLs so that they take the form /mypage?%x00 or similar.

Note: one drawback of using the GET request method is that the query string size is limited to relatively small number of characters. Watch out for this if your server side script seems to be missing some data sent on the request. In such cases, you may want to consider using the POST request method as this has no size limitations.

JBlitz carries support for editing the name value pairs in a URL with the web page editor which is available by clicking on the button displayed just to the right of the web page in the test case settings dialog.

The editor display the URL at the top of the dialog and a table of name value pairs below. Use this editor in one of two ways:

• Edit the web page directly in the text field at the top of the dialog. Type name value pairs after an initial question mark (separating each with the '=' and '&' symbols. As you type in each pair, you will see the table update dynamically to list the names and values.
• Click on the 'Add' button to the right of the table and then double click on either the name or the value displayed. Type into the table cell to change the name or value. Click away to see the new table cell value reflected in the web page text field at the top of the dialog.

Via the web page editor, you can also choose and embed a dynamic substitution element into your web page, URL encode or decode any given name value pair and rearrange the name value pairs to your hearts content.

Remember that you input name value pairs for both GET and POST requests in the same way in JBlitz. Specify them after the web page followed by a question mark. For POST requests, JBlitz will repackage the name values into the form data for the HTTP request message.

You can customize the request headers JBlitz uses for any of the supported request methods. Select the 'Request Headers' tab and choose the request method whose headers you wish to modify. The modifications will be used for every web page download that uses the given request method. Note, however, that you are also able to specify individualized request headers for any given web page via the page settings dialog. Note also, that you may define dynamic substitutions within the headers if you want to.

All the headers may be modified except for:

• The first line of the request which specifies the request method itself and the HTTP version.
• The Content-Length request header which needs to be set by JBlitz in accordance with any POST data.
• Any cookie request headers which are added by JBlitz in accordance with any cookie state maintenance set up.
• Any basic authentication request headers which are added by JBlitz when basic authentication is demanded.

Be careful as incorrect or incomplete request headers will prevent your requests from succeeding. At any time you may revert to 'safe' headers as used by JBlitz by default by selecting the 'Restore defaults' option.

We recommend not to use the header Connection: Keep-Alive as this is not generally appropriate. JBlitz does not attempt to keep connections alive between requests for any of the virtual users, so such a header can result in connections 'running out' and connection errors subsequently occurring. We recommend that this header (as with the defaults) be omitted or replaced with a Connection: Close header instead.

JBlitz will format the headers you enter to remove any leading or trailing white-space and to insert the correct line separator characters between the header lines.

A powerful and simple feature of JBlitz is the use of dynamic substitutions. These are replacement portions for your test URLs generated according to the rules laid out below. Use these as a tool for simulating real world server load by allowing you to vary the web page, query string or POST data values specified in your test URLs. Amongst other things, dynamic substitutions give you the power to embed arbitrary XML documents into your query strings and POST data, and to have those documents include randomly generated test data within.

There are four categories or types of substitution available:

• Value substitutions: generate integers, floating point numbers and strings etc.
• User defined substitutions: generate of test data using your own Java code.
• File content, item and file item substitutions: generate file derived test data and items of data chosen from a list of items.
• Prior substitutions: re-generate previously generated test data for repeating data used in previous queries.

The following sections describe these substitution types, how each of them can be used and how they help simulate real world loading.

Note: Remember to URL encode any data appearing inside a query string or a form field! Failure to encode the test data may result in unexpected errors occurring when the request is made.

The simplest form of substitutions are the value substitutions. These substitutions are replaced at test time with randomly generated values.

Symbol used in URL	Name	Generates
%i00 -> %i99	Integer Range Substitution	a random integer within a user specified range (100 separate ranges definable)
%j or %J	Integer Substitution	a random single digit from 0 through 9
%k or %K	Integer Substitution	a random integer between 0 and 99 inclusive
%l or %L	Integer Substitution	a random integer between 0 and 999 inclusive
%m or %M	Integer Substitution	a random integer between 0 and 99999 inclusive
%n or %N	Integer Substitution	a random integer between 0 and 9999999 inclusive
%r00 -> %r99	Floating Point Range Substitution	a random floating point number within a user specified range (100 separate ranges definable)
%s	String Substitution	a random lower case string, average length 6 chars
%S	String Substitution	a random upper case string, average length 6 chars
%t	Boolean Substitution	true or false chosen at random with a 50 / 50 chance of each
%T	Boolean Substitution	TRUE or FALSE chosen at random with a 50 / 50 chance of each

As an example, consider a URL like this:

/product?id=4&user=jim&product_detail=57

Instead of hard-coding test data values, it would be far better to have them generated dynamically:

/product?id=%j&user=%s&product_detail=%k

where the %j, %s and %k are replaced for each web page request.

The integer range substitutions and floating point range substitutions need special mention. They give you the flexibility to map 100 different integer and floating point ranges whose bound are configured by you within JBlitz. As an example, say you had a URL for a scientific web application that recorded timing measurements and you knew that valid timings ranged from 4.00 to 7.00. To generate test data for this URL, you can define one of the %r00 -> %r99 substitutions (any one, lets use %r00 here) to map to the range 4.00 to 7.00 with 2 decimal places of precision. Your test URL might be of the form:

/addTiming?value=%r00

Further test URLs that carry invalid timings could be generated using %r01 to map to the range 0.00 to 3.99 (say) and %r02 to map to the range 7.01 to 10.00.

Range settings for integer and floating point range substitutions can be configured by going to the 'Dynamic Substitutions' tab and selecting the %i or %r substitution type. Use the right hand panel to select the substitution number to use (from 00 to 99). Click 'Edit...' to specify the range.

Using these substitutions makes your web server and associated server side technology work much harder. In conjunction with the other substitution types outlined below, this strategy can really test your site.

This substitution type gives you the freedom to say what replacement value should be substituted into your URLs. This substitution allows 100 separately definable values.

Symbol used in URL	Name	Generates
%u00 -> %u99	User Defined Substitution	a value specified by your own Java code

User defined substitutions work by calling out to your Java code. All you need to do is write a Dynamic Substitution Generator which is not as complicated as it sounds - just a single static method that is passed the URL to substitute into and returns the value to be substituted.

This substitution is ideal for generating test data that, for whatever reason, cannot be predefined. A simple example might be the time that the query takes place. To accomplish this with a user defined substitution, a URL of the form:

/readings/addReading?data=%z00&time=%u00

could be used where a reading (here we're using a file item substitution to pick the value for the reading from a file) could be sent to the server marked with the time of the reading, the current time.

You can configure your %u substitution by going to the 'Dynamic Substitutions' tab and selecting the %u substitution type. On the right hand side of the panel, click 'Set...' and then type in the fully qualified class name for your substitution generator when prompted. Click 'OK'. You don't need to specify anything else - JBlitz will now call out to your Java code whenever it meets any of the 100 allowed %u substitution elements in any URL. It will pass in the associated substitution number (from 00 to 99) to your code so that you can work out which substitution you're trying to perform.

There's more information on how to write a Dynamic Substitution Generator plug-in.

Dynamic substitutions also encompass file content, item and file item substitutions. File content substitutions allow you to embed the contents of an arbitrary file into the URL. Options are provided for URL encoding the file contents before embedding. Item and file item substitutions allow you to specify test data items to be substituted by selection from a free format list of items. You have the option to make the selection work sequentially through the list or to pick at random.

All these substitution types all allow 100 separately definable values.

Symbol used in URL	Name	Generates
%x00 -> %x99	File Content Substitution	the contents of a user specified file
%y00 -> %y99	Item Substitution	a test data item chosen from a user specified list of test data items
%z00 -> %z99	File Item Substitution	a test data item chosen from a list of test data items contained in a user specified file

File content substitutions allow you to avoid trying to embed file contents (e.g. XML message documents) into your test URLs by specifying them indirectly instead. For instance, consider the following web page

/petshopEnquiry?msg=%x00

where '%x00' is a file content substitution that points to a given XML message file on your local disk. You can define the file content substitutions used by JBlitz in the 'Dynamic Substitutions' tab. Select the %x substitution type and use the right hand side of the panel to define the value for that substitution.

Item substitutions allow you, for example, to embed an XML based message that is one of a set of XML messages you want to test, by specifying the web page along the lines of

/petshopEnquiry?msg=%y00

where you have setup the item substitution %y00 to substitute from a list of candidate XML messages. You could further make the list use %x substitutions so that your XML messages can be read from file (see below on how to use substitutions recursively). You can define the %y substitutions used by JBlitz in the 'Dynamic Substitutions' tab. Select the %y substitution type and then use the right hand side of the panel to define the value for that substitution.

File item substitutions work very similarly to item substitutions except that the list of test data items reside in a file on your local disk rather than being entered into JBlitz. You can use them in exactly the same way. They work best for situations where your test data naturally resides in a file and the flexibility of being able to edit it outside of JBlitz is beneficial.

Remember, for these three substitution types, you can configure up to 100 different substitutions, that is the for values 00 -> 99 inclusive.

This substitution type allows you to re-generate a value previously generated for one of the other dynamic substitution types.

Symbol used in URL	Name	Generates
%p1 -> %p9	Prior Substitution	the value generated for the previously made substitution

Prior substitutions are especially useful in all sorts of situations where you want to write URLs that query using the same test data that a previous URL used. As an example, consider a couple of URLs that might be used to add and remove stock items from an inventory system.

/stockInventory/addStockItem?id=supergizmo1

/stockInventory/removeStockItem?id=supergizmo1

and then a query on the given item should reveal that it is no longer listed:

/stockInventory/queryStockItem?id=supergizmo1

To test such a hypothetical set of URLs you can make use of prior substitutions to re-generate the item id that was initially added for both the removal and the subsequent checking query:

/stockInventory/addStockItem?id=%z00

/stockInventory/removeStockItem?id=%p1

/stockInventory/queryStockItem?id=%p1

Where %z00 is setup to point to a file containing some test stock items including supergizmo1 and supergizmo2 etc. The return page from the last query should always reveal that no such stock item is listed.

Some further points of note:

1. Prior substitutions are 9 deep - that is only the last 9 values are 'remembered' for each virtual user. To work out the number to use, just count backwards through the web pages configured for your test case until you reach the substitution that you would like to replicate. %p1 generates the most recent value (the %z00 in our example), %p2 the second most recent and so on to %p9 which will return the value for the ninth most recently substitution made by the virtual user.
2. Prior substitutions can work with any of the other substitution types - they literally re-create the data substituted.
3. Prior substitutions do not themselves affect the substitution history. For example %p1%p1%p1 in a URL will insert the same piece of re-generated test data 3 times.
4. Before you can use prior substitutions in your URLs, you must make sure they are enabled in the GUI - go to the 'Dynamic Substitutions' tab and select the %p substitution type, then click on the Enable use of %p substitutions check-box. This is an optimization as enabling their use when they are not required would incur an unnecessary memory and runtime processing overhead.

A significant feature of dynamic substitutions within JBlitz lies in their recursive use. You can nest substitution elements within other substitution values.

For example, the values configured in the GUI for a %y00 item substitution could be %x00, %x01, %x02 etc. This allows your URLs to substitute the contents of a file that has been selected from a suite of files. Further, each file can itself reference other substitution types e.g. test data within the file may use %i, %j, %s substitutions etc.

A more detailed example of the recursive use of dynamic substitutions is presented in the FAQ here.

Note: when using substitution elements within external files that make up file content substitutions, make sure the substitution element does not set up closed cycles of recursive substitutions. For example, if the substitution element %x00 references your document 'invoice.xml', make sure that 'invoice.xml' does not itself contain the element '%x00' either directly or indirectly.

One of the principal features of JBlitz is exercising your website or web application and detecting any errors or malfunctions. Most malfunctions will be caused by the same reasons that any software malfunctions: bugs, poor design or overloading (i.e. running out of system resources such as CPU time or memory). When an error occurs, JBlitz can be configured to take various actions such as stopping the test run or displaying a dialog. JBlitz will also record the error in the Error Inspector. This window keeps a log of the last 'n' errors that have occurred and allows you to review them at your leisure.

JBlitz can detect errors and malfunctions in your website or web application in one of the following seven ways:

1. Checking for bad HTTP response codes. As part of the world wide web standard, the HTTP protocol defines the set of allowed return codes when any resource is requested from a web server. For instance, 200 defines an 'OK' and 401 defines 'Unauthorized'. Sometimes, your website will respond with an 'error' code when a problem has occurred. JBlitz allows you to specify on an individual response code level those codes which signal errors. Normally these will be the default standard set of codes of the form '4XX'. However, you can redefine this set to exclude some or include others. More info...
2. Searching for standard error text that signals a standard error page has been returned. Often, your website will signal a problem by returning a standard error page to the user saying, for instance, 'Sorry, but your request cannot be processed at this time'. Some websites and web applications also signal an error by returning a specific HTTP header to the requester. When this occurs, it could mean your server side scripts / programs have crashed, too many requests are incoming or even that the web server has run out of memory! Whatever has caused the problem, you want to know about it! JBlitz will search for a given piece of text or run a regular expression pattern match on either the web page body or the headers. More info...
3. Checking for slow connection or response times. JBlitz be configured to raise an error is a connection or response time is longer than a maximum acceptable time. More info...
4. Invoking a global response checker. This is your own custom Java code that is installed globally and is used to signal success or failure at a global level. More info...
5. Invoking a page-level response checker. This is your own custom Java code that is installed for a particular response page and can signal success or failure for that particular page. More info...
6. Searching for page-specific text that may signal an error has occurred. You can configure text searches against individual web pages to see if the page contains / does not contain the expected response. More info...
7. Invoking a customization module. This is your own Java code that is installed as part of the JBlitz query engine. Customization modules have the power to raise an error on any given web page download More info...

Under the 'Error Handling' tab, the first tab below that is titled 'HTTP Response Errors'. Click on this tab to show the configurable settings for checking HTTP codes against a list of 'error' codes.

Click the Test HTTP response codes check-box in the top left hand corner to make JBlitz check for error codes. Once checked, two list-boxes should be enabled to the right (make sure that a test run is not ongoing). The first list-box defines the response codes that JBlitz will interpret as meaning that 'an error has occurred on the web server'. The second list-box simply holds all the possible HTTP codes that exist.

Select a code from the left hand list and you should be able to remove it by clicking the Remove button. Click a code in the right hand list and you should be able to add it by clicking the Add button. If in doubt, click the Restore Defaults button to restore a 'normal' set of codes (ie all 4XX codes except for 401 - Unauthorized).

In any case, the left hand list defines the codes that JBlitz will look out for. If you're not interested in checking for HTTP responses from your website, uncheck the Test HTTP response codes check-box in the top left hand corner.

Under the 'Error Handling' tab, the second tab below that is titled 'Standard Error Pages'. Click on this tab to show the configurable settings for checking for error or success text within the returned web pages or HTTP headers. Click the Check response bodies check-box in the top left hand corner to make JBlitz check for errors. Once checked, you can specify a search pattern to be applied to each response page downloaded. Search patterns can be either plain text searches or more advanced searches using regular expressions.

In a similar fashion, you can specify that JBlitz should search for some given error or success text within the HTTP response headers returned from the server. Again, click the Check response headers check-box to left of the screen and specify a search pattern to be applied.

More information about how to use text searches and regular expressions within JBlitz is available.

Once enabled, JBlitz will apply your search text or regular expression to each and every response received from the web server. In this sense, these searches are 'global' and are only appropriate for identifying 'standard' error scenarios. However, page-level errors can also be detected through text searching and regular expression matching. This is a more powerful tool that can be used to determine if the content of any given response contains the expected data for the request made. See below under 'Searching for page specific error text'.

Click on the main 'Error Handling' tab and select the sub-tab 'Wait Time Errors'. Click on the check-box at the top left to make JBlitz check for slow connection and response times for every download.

The first two fields 'Maximum allowable connection time' and 'Maximum allowable response time' hold the limits to be enforced. Enter figures in seconds.

The field below 'Do not enforce wait time limits for the first 'n' seconds' is intended to give your website or web application a startup 'grace period'. Enter a figure in seconds, enough time for it to come up to speed, before the performance checking begins. Enter zero to have no grace period.

A custom global response checker can be configured under the 'Custom Errors' tab below the main 'Error Handling' tab. The checker is a Java class that can be used to check web page responses for errors. All responses are submitted to the installed checker if there is one.

The checker is written using the JBlitz customization API. More information about using the API to write and install a response checker is available.

To configure a page-level response checker, double click on a given test case to bring up the test case settings dialog and select the web page of interest. Double click on the third 'dash' icon to the right. Alternatively, bring up the page settings dialog and select the 'Java' tab.

A page level checker applies only to the web page(s) it is configured against and will only be invoked to check the responses for those pages. Aside from that, it is an identical beast to the global response checker. More information about response checkers is given in the customization help.

Configure page-level searching by bringing up the test case settings dialog for the relevant test case and selecting the target web page. Double click on the first 'dash' icon to the right. Alternatively, bring up the page settings dialog and select the 'Errors' tab. The Error Text Detection dialog allows you to raise errors on any given web page download by searching for a given piece of text or by running a regular expression pattern match on the returned web page or its headers. Plain text searches are a good tool for identifying either unexpected (error) text or expected (success) text within each response. Regular expressions offer a more powerful and flexible means of identifying errors, but require some skill to configure correctly. More information about how to use the text searching facilities within JBlitz are given below. Within this dialog, you can reference the nth prior substitution made for the virtual user using the special values $p1$ through $p9$. These portions of the search text are replaced at search time with the nth prior substitution made when requesting this page (or indeed a previous page). Also available are the URL decoded versions using $p1d$ through $p9d$.

Page-level error text detection

As an example of how to use prior substitutions within text searches, if the URL used to query this page was, say:

/stockInventory/addStockItem?id=%y00

and you expect the response page to list the stock item as having been added, you could set up an error text search with search text like:

The stock item $p1$ was successfully added

The %p dynamic substitution help has more information on how prior substitutions work.

To identify errors in the responses from the server, you can perform text searches and regular expression matches against the returned web pages or their headers.

• at the global level, you can specify a text search or regular expression match that will be applied for every response downloaded. This is configured in the 'Standard Error Pages' sub-tab of the main tab.

• at the page level, you can specify a text search or regular expression match that will be applied only to the page or pages it is configured against. Bring up the test case settings dialog for the relevant test case and select the target web page. Double click on the first 'dash' icon to the right. Alternatively, bring up the page settings dialog and select the 'Errors' tab.

The search of the response can be one of three types:

• Plain Text Search. JBlitz looks for some user specified search text within the response headers or body. This can be performed either case-sensitive or case-insensitive.

• Regular Expression - pattern find. Configure a regular expression that is matched against the response headers or body. Regular expressions within JBlitz are described more below. This type of search attempts to find a piece of the returned headers or body that matches the given regular expression. Not all the data need match, just some part of it. Hence, an expression such as 'r.d' will return success if the response contains (anywhere) 'rad', 'rbd', 'rcd', 'rdd', 'red' etc. The matching is performed using the java.util.regex.Matcher.find() method. More details about how this works are available from the Java online documentation for the Matcher and Pattern classes.

• Regular Expression - pattern match. Configure a regular expression that is matched against the response headers or body. Regular expressions within JBlitz are described more below. This type of search attempts to match the entire returned headers or body against the given regular expression. Success is only returned if all the data matches. Hence, the expression '[a-zA-Z0-9]*' will match if and only if all the data is exclusively alpha-numeric. The matching is performed using the java.util.regex.Matcher.match() method. More details about how this works are available from the Java online documentation for the Matcher and Pattern classes.

Note: the case-sensitive option is only available for plain text searches as regular expression pattern matches are always implicitly case-sensitive.

In addition to specifying the search type, you can also specify whether finding a 'match' constitutes an error condition or a success condition. This allows you to specify your search text or regular expression in either a positive or negative sense - i.e. it can be used to search out error conditions or to identify the 'success' conditions in each response.

Select the appropriate entry from the combo next to the third field 'Raise an error if':

• Matching text is found - select this option when specifying 'error text' - i.e. when you want an error to be raised when your search text is found or your regular expression matches.
• No matching text is found - select this option when specifying 'success text' - i.e. when you want an error to be raised when your search text cannot be found anywhere or your regular expression does not produce a match

The regular expression support in JBlitz is centered on classes within the java.util.regex package that comes distributed with the standard Java VM. Notably, java.util.regex.Pattern and java.util.regex.Matcher.

For Java version 1.4.2, these classes are documented here.

The syntax of the regular expressions acceptable to these classes is similar to that used within Perl. Some detailed explanation of the syntax is given in the javadoc for these classes and also in this tutorial and overview Mastering Regular Expressions.

Regular expressions are compiled into java.util.regex.Pattern objects using the Pattern.compile() method. The Pattern.DOTALL flag is passed into the compile() method to enable matching of the '.' character class to include line feeds and newlines. (Note: flags like these can be enabled and disabled inside the pattern using the (?) syntax). If the expression has bad syntax, a PatternSyntaxException is thrown which will result in a resource error being raised at test run time.

Once a pattern has been created, it is matched against each response using Pattern.matcher(<response>).find() for pattern finds or Pattern.matcher(<response>).match() for matches. The difference here being that a find() attempts to find some (any) part of the response data that matches the expression whereas a match() requires that all the response data matches it.

Customization modules can signal errors in any web page response received. The relevant methods that need to be implemented are in the com.clan.jblitz.custom.engine.QueryExtension interface as follows:

public CustomError responseHeadersReceived() public CustomError responseBodyReceived()

Install a customization module by going to the main menu Customize->Load Customization Module... . A complete description of how to write and install a customization module is given here.

JBlitz determines that an error has occurred when:

• One of the seven detection mechanisms described has signaled an error.
• A connection has timed out (connection timeouts can be specified in the test case settings dialog.
• A connection to the server could not be made.
• An underlying error has occurred on the network - i.e. the web server became disconnected or a network fault occurred

When any of these events occur, JBlitz takes the actions as specified in the tab titled 'Detection Action' under the 'Error Handling' tab.

This panel contains settings in the box at the top titled 'Virtual User Action'. These settings specify what JBlitz should do with the virtual users that are running when an error occurs:

• Do nothing. All virtual users keep running unaffected
• Restart the download sequence. for the virtual user that detected the error. Begin a new transaction by abandoning this one and starting again on the first web page for the test case.
• Stop the virtual user that detected the error. Results in the offending virtual user stopping but leaves every other unaffected.
• Stop all virtual users for the affected test case. The test case is 'stopped' i.e. all virtual users assigned to it finish, but other test cases are unaffected.
• Stop all virtual users. This will cause your test run to end immediately.

Any of these actions may be appropriate given different scenarios of testing your website (you may, for example, be expecting some errors to occur and simply want to keep track of what percentage errors you get - in this case you'd simply tell JBlitz to do nothing).

At the bottom the box titled 'Additional Options' contains a couple of extra settings:

• Display a message box - configure JBlitz to display a message box when an error occurs so that it is obvious that it has happened. This cannot be done unless JBlitz stops the virtual user that detected the error (otherwise, its likely you'll get inundated with a stack of message boxes as the virtual user keeps encountering the same error).
• Break to debugger - when a debug test run is ongoing, if an error occurs, control is passed to the debugger which is paused at the offending virtual user within the offending test case. If the test run is a normal one (i.e. not debug mode), this flag will have no effect.

JBlitz supports stateful navigation between the web pages that make up your test cases. To enable the navigation and state maintenance functions within JBlitz, first go to the 'State Maintenance' tab of the main screen. Tick Enable state maintenance to globally allow JBlitz to maintain state between web pages. There are two support mechanisms, cookies and response parsing. These are described below. Tick each option if it applies to your website or web application.

Cookies are used principally for ASP and JSP session support. Cookies are described further in the next section.

Response parsing enables each virtual user within JBlitz to navigate statefully between web pages. This can be done in one of two ways. 

1. By simply following hyperlinks or filling out forms. JBlitz emulates a browser to follow hyperlinks and form actions.
2. By transferring name-value pairs and, optionally, session IDs returned by the server onto the next request.

Additional Options allows you to reset state after each cycle. When ticked, this means that each virtual user's state information will be reset once that virtual user has gone through all the web pages for a test case and is ready to begin again at the first page.

Cookie support underpins state maintenance on the web server when you are using Active Server Pages and Java Server Pages / J2EE technologies (amongst others). These technologies require the client (i.e. JBlitz) to return any cookies sent by the server. The server uses these to maintain information about that client. In terms of JBlitz, each virtual user in each test case is a 'client'.

To configure cookie support in JBlitz, click on the 'State Maintenance' tab in the main screen and ensure that both the Enable state maintenance and Mechanisms: cookies check-boxes are ticked. No further action is required. All cookie headers received by a virtual user will be sent back with each subsequent request.

The follow hyperlink / form action navigation mode makes JBlitz work like a user clicking on links in a browser - URLs are computed by following hyperlinks or form actions. You do not need to configure the exact URLs to use within your test cases because JBlitz extracts them dynamically from each response.

The following points will help explain how this navigation mode works:

Because the URL for the web page is sent back by the server, the web page URL as shown in the test case is only a nominal one. It may, however, still affect which hyperlink / form action is followed if the Only count occurrences where the target page matches this page check-box is selected in the response parsing settings. JBlitz basically uses the hyperlink or form action 'as is', however: Test data can be added or modified within the computed URL by using Data Injection. This allows you to specify the user-entered form data to be sent to the server. Dynamic substitutions can be used here to allow for dynamic test data. The computed URL is available for modification by a registered URL assistant or loaded customization module. The request method used will be GET for hyperlinks and normally either GET or POST for forms, whichever is specified (default is GET).

To configure JBlitz to follow a hyperlink / form action:

1. Open the page settings dialog for the web page that is the target of the hyperlink or the action of the form (Shift double-click on the web page icon from the main screen or go to the test case settings dialog and double-click on the desired page).
2. Select the 'Navigation and State Maintenance' tab. In the Navigation Mode combo, select Follow hyperlink / form action. Click the configure button below right to specify which hyperlink or form to look for. This is the link that will be used to determine the URL for querying this page. Various parsing options are available. These are described in detail in the Response parsing section below.

Name-value pairs normally appear either as part of the query string of an anchor tag or as form fields inside a form tag. For example, the following hyperlink and web form will send the values for option1 and option2 back to the server when the user either clicks on the hyperlink or submits the form:

 

<a href="mypage?option1=this&option2=that"> <form action="mypage"> <input type="hidden" name="option1" value="this"> <input type="hidden" name="option2" value="that"> </form>

A couple of dialogs are used to configure the response parsing that occurs when either the Follow hyperlink or Name-value transfer navigation modes are used. These dialogs are shown when you click the 'Configure...' button on the Navigation and State Maintenance tab of the page settings dialog.

They are principally used by JBlitz to determine which anchor or form tag to look for when parsing the previous response page which in turn determines the URL that will be used for this page.

If the URL for this page is shown as a hyperlink in the response, you'll want to enable parsing for ANCHOR tags. Otherwise, if the URL for this page represents the action of a form in the response, you should enable parsing for FORM tags.

Below this, you can then specify where in the response page JBlitz should start from. Choose a line number or a search string that JBlitz should look for before parsing begins.

If the response page contains many candidate forms or hyperlinks, you can have JBlitz select which Occurrence to look for - the first found, second, last etc. This may be helpful, for instance, if the response page is a catalog index page with many links and each hyperlink links to a catalog entry. You could then configure JBlitz to follow the link to first, second, last or a random entry.

The check-box Only count occurrences where the target page matches this page is intended to allow some 'leeway' when working out what hyperlinks or forms match.

When using the Follow hyperlink / form action navigation mode, you can additionally configure:

• Data Injection: Specify replacement or additional name-values to be sent in the request. Typically, this is used to allow you to specify user-entered form data when filling out a form. JBlitz will transfer hidden form data for you, so you don't have to specify that. Within the Data Injection field, type in name-value pairs separating each with an '&' character. Note that you are free to make use of any of the dynamic substitution elements to generate realistic test data for the hyperlink or form action. Remember, also, to URL encode your data!

When using the Name-value transfer navigation mode, there are several extra options:

• Excluded names: You can choose to exclude some name-values when parsing so that they're not transferred onto the next request.
• Hidden only: For name-values within FORMs, you can also specify that only ones of TYPE=HIDDEN should be transferred.
• Merge mode: The last option under 'Additional Options' governs how the name-value pairs extracted from the response page are to be merged with any that you may have defined for this page. Various options are available:
  • Use the Value Defined in the URL For This Page: The value for any name-value name that appears in the web page typed into JBlitz will override any value that may have been parsed from the response for the same name.
  • Use the Value Sent Back in the Previous Response: The value for any name-value name that is parsed from the previous response will override any value that has been typed into JBlitz for the same name.
  • Use Both: Neither overrides the other, both are sent back in the query for this page.
• Session ID: You can optionally choose to have a path parameter transferred. The parameter must occur following a semicolon in the past path component of the hyperlink or form action. See above.