Menu

How-To: Dynamic Field Names and Multi-Variable Extractors

Overview

You’re recording test cases, configuring them, replaying them, and running load tests.  One day, you attempt to test a new web application.  However, every time you attempt to run a replay, the replay throws an extractor error; it is unable to find a field in the page content of the replay to extract.  ASM configured this field automatically, so why isn’t it working?  You look at the replay content … and the field name isn’t there.

The usual culprit that causes this problem is a dynamic field name: a variable in a dynamic web page that not only changes in value, but also varies in name.  For example, on one page the first row of data includes a field named “Item45”, while in the replay with a different user and a different search term, that field is named “Item56”.  This name and the value are then resubmitted to the webserver as a JSON field or a query parameter in the next request, so it must be extracted – but ASM doesn’t do it, because it can’t find the original field name.  Dynamic field names are very common in applications that handle lists of data that are generated on the fly from a database query.

In such a case, Load Tester must be configured to deal with the situation by extracting the name of the field and the value of the field into user-created variables.  Before tackling this tutorial, you should already be familiar with Load Tester’s recording process and test case customization, and you should be familiar with regular expressions. There are a series of steps involved in the process of configuring Load Tester to handle dynamic field names.

Step 1: Stop ASM from handling these fields

First, you need to identify and disable the ASM automated processing of the problem fields.  So … how do you tell which of these fields are problems?  One way is to simply replay the test case until you get an extractor error.  If you compare the content from the recording with the content from the replay and the field names change, then you have a strong candidate on your hands.  For example, if in the recording the field name is “Item45”, and in the replay the field name is “Item56”, then there is a good chance the field name is dynamic, and you’ll need to stop ASM from trying to extract it.

This is accomplished by selecting the “Expert Options” checkbox when configuring a test case for replay, and then choosing the “Guided Configuration” radio button under Application State Management.  (You can also reach this screen by running ASM by itself.)  The analysis will complete, and then a list of fields will be displayed.  Select one or more fields, and then select the “Never Extract” radio button on the right.  The icon next to the field will change and indicate that the field will not be handled automatically.  ASM will not retain this information unless you completely configure the fields using an extractor and setting the field name and value; you will get a warning in the next run of ASM that there are pre-configured fields that it thinks it should ignore.  If you configure fields to be ignored, but you don’t finish the configuration, you will have to reset the “Never Extract” flag the next time you run ASM on the test case.

Configuring ASM to ignore fields

Configuring ASM to ignore fields

Step 2: Set up an extractor to get the field name and the field value

Next, set up an extractor to get the field name and the value.  You can do this with two extractors; however, it is quicker and easier to use a multi-variable extractor to get them both at the same time.

A multi-variable extractor must use regular expressions, as we will need to specify two or more selection groups.  Here’s an example of a configured multi-variable extractor:

Configuring a a multi-variable extractor

Configuring a a multi-variable extractor

This can initially be confusing, so lets go over it piece by piece.  First, you select Regular Expressions as your extractor type (highlight 1).  Then, you enter in the regular expression to identify your field name and value (highlight 2).  A full discussion of regular expressions is beyond the scope of this post, but I want to point out two important things:  first,  notice the escape codes for DOS line termination in the regular expression (\r\n).  Which ones you might have to use will depend on what software created the document, and it may not be immediately obvious.  Second, when you set up a regular expression like this, note in highlight 3 that there is an instance number.  If your regular expression has more than one match in the page content, the instance number is how you control which values are extracted.  This is an important time-saver: if you build the regular expression correctly, you can cut and paste extractors (using the Edit menu) and simply change the instance number and variable names to get the next set of values that match.  Conversely, don’t try to be too general – if you have two significantly different instances to extract, simply create another extractor.

Details of extractor configuration

Details of extractor configuration

In highlight 4, you can see that two variables names are entered with a space between them.  These variables will be matched up to the regular expression selection groups; the first selection group goes to the first variable, the second selection group goes to the second variable, etc.  What values are actually selected by the combination of instance number and selection group is shown in highlights 5, 6, and 7, with 5 and 6 identifying the match inside the content and highlight 7 giving you a summary list of everything being extracted.

Step 3: Inserting extracted data back into the test case

Next, you need to insert the extracted data into the fields that we told ASM not to automate.  This is done by double clicking the M? cell in the Fields view, and then setting both the field name and the variable name in the dialog.  The highlight below shows the example fields.  The M? cell would be blank for a field that has not been configured; the green arrow icon indicates that the field has been automated.  Fields that have been automated by ASM have a “#” character at the beginning of the variable name.

Inserting extracted data into fields

Inserting extracted data into fields

Once you double-click the M? cell, you will get a dialog that looks like this:

Configuring a field value variable

Configuring a field value variable

Change the Value of the field to User Variable, and enter the name of the value variable you chose.  Once that is done click on the Name tab and do the same thing with the name variable you chose:

Configuring a field name variable

Configuring a field name variable

In this way, both the name of the field and the value of the field are extracted and substituted – each replay and each virtual test case run will be different based on the page content returned from the site.  Unfortunately, there is currently no way to get a list of your user variables, so in a complex test case you will need to utilize a naming convention like I’ve done here, or keep track of your variables by hand.  Also, when you are cutting and pasting extractors, make sure you change both the instance number and the target variable names, so that each extracted set of variables has a set of unique names.

If you have questions or comments about this blog entry, please post a comment, contact us directly, or submit a support request via the Support Request tool inside Load Tester.  Happy testing!

Add Your Comment

You must be logged in to post a comment.

Resources

Copyright © 2019 Web Performance, Inc.

A Durham web design company

×

(1) 919-845-7601 9AM-5PM EST

Just complete this form and we will get back to you as soon as possible with a quote. Please note: Technical support questions should be posted to our online support system.

About You
What you Need