Are you getting an error that says ""Extractor could not locate content on page for variable xxxxx".? It may be due to a dynamic variable that hasn't been configured. The "ASM" feature automatically looks for dynamic variables and configures everything for you, but if your application uses a unique technique, then it will have to be configured by hand. You can react to test case errors and work backwards, but it is usually easier to proactively search for fields that haven't been configured and write dynamic variable detector rules that will work on all of your test cases. Why aren't some dynamic variables detected? The most common situation is a "creative" use of HTML that is not in common usage. The more clever the programming, the harder a web-based application is to test.
This is a big topic, and can take a lot of effort to master, but here is a quick overview of the process. If you are faced with something complex we are available on a consulting basis to configure everything for you.
1. Find Un-configured Fields
The first step is to click on the top level in the Test Case Editor to select all web pages, and then select the Fields Tab. (See attached screenshot) In the Datasource column, grayed out entries have been automatically configured, while blank entries are not configured at all. Look for entries that appear to be dynamically generated, i.e. long strings or UUIDs or numbers that will change with each session. Those are the ones you want to configure.
2. Search for Recorded Value
Double click on the un-configured field and copy the recorded value. Click on the search tab to find the page and transaction that field appears in. You can then select that page and transaction, and switch to the Content View. Use the search feature in the content view and the Text display mode to identify the HTML that isn't being detected automatically.
3. Design Extractor
You can use the page-specific validator dialog to configure a validator since its interactive. This value will be parsed and stuck into a variable for later use. Another option is to recreate the extractor later in the Detection Rules Dialog to apply to all pages and all test cases automatically.
Click on the Actors Tab, and then sector Extractors at the bottom of that window. Hit the green "+" symbol on the right-hand side to create a new extractor.
First, use the recorded value to locate the HTML again. A blue line will appear on the right-hand HTML display to indicate where the string occurs. Click on each blue marker until you find the source of the dynamic variable.
Regular expressions are preferred since they allow you to only accept values in the right format, ignoring all others. See the screenshot for a configuration example for the UUID "choiceId".
If you intend to create an extractor just for this test cause, write down the variable name for later use and click OK.
If you intend to create an automatic detection rule then copy the regular expression that works and click on Cancel.
4. Configure Fields
In this step, you configure fields to use the value from the extractor you just configured. This only applies if you are simply configuring an extractor for this particular test case. If you intend to create an automated rule skip to step #5.
Its as easy to configure multiple fields as just one so this example will show multiple fields. Click on the entire test case and then the Fields tab at the bottom. Make sure the table is sorted by field name. (The column on the far left.)
In this example you see that "access_token" is not configured. Select all of the rows for this field, right click, and select edit. For the datasource select "User variable", and type in the name of the user variable you created in step #3.
This brings up the field editor. For a datasource select User variable, and then type in the name of the variable you just created in step #3. Click OK, and then all of the selected fields are configured to change dynamically based on
5. Optionally Create a Detection Rule
This step is more trouble, and may not apply to every situation. If you are creating multiple test cases with the same application that have the same variables unconfigured each time, it may be worth the effort to create a detection rule that will work automatically.
Open the Detection Rule Dialog using shift-control-U.
Create a new dialog by copying a similar rule or creating one from scratch. Note that there are detailed instructions of detector rules in the manual, OR you can schedule a training session to learn everything you need at one go.
See the attached screen for a detector rule designed to pick up values in the HTML snippet: "choiceId="aaa-bbb-999-222". The regular expression is "choiceId="([0-9a-zA-Z-]++)", noting that it does not specifically look for UUIDs, which is beyond the scope of this document.
Click OK, and you have the option of applying the new rule to every test case. Many times that takes too long, so you should right-click on the test case you're working on and select Configuration->Application State.
6. Check the Fields View to Verify
Once the new detection rule has been applied, you should revisit the Fields View to make sure an extractor has been automatically applied. As you can see below the "choiceId" field has been configured:
