Skip to content

Auto-Ignore & Equivalent Fields

ASM analyzes every field in your test case, but not every field needs configuration. Submit buttons, timestamps, and other static values work fine with recorded values. Configuring them wastes memory and clutters the Fields View.

Auto-ignore rules tell ASM to skip specific fields, saving memory and keeping configuration clean. Equivalent field names help ASM correlate fields when response and request use different names for the same thing (common in JSON/XML APIs).

This guide covers what ASM ignores by default, when to add custom ignore rules, and how to map equivalent field names across frameworks.

What ASM Ignores by Default

Built-In Auto-Ignore Behavior

ASM's rules-based engine automatically ignores certain field patterns without manual configuration:

Common auto-ignored patterns:

  • ✅ Submit button values: btnSubmit=Submit, action=continue
  • ✅ Static labels: Form field values that never change
  • ✅ Client-side only fields: JavaScript-managed values not sent to server
  • ✅ Known static patterns: Framework-specific constants

How it works: ASM's 300+ detection rules include ignore patterns that recognize common static field types. When a field matches an ignore pattern, ASM skips it. It doesn't appear in Fields View and doesn't consume memory during load tests.

Check what was ignored: After ASM runs, you won't see ignored fields in Fields View. If a field should have been ignored but wasn't, add it manually (see below).

Why Auto-Ignore Matters

Performance: More Virtual Users Per Engine

Every configured field consumes memory during load tests. Configure 1000 static fields unnecessarily and you're wasting memory that could support more virtual users.

Memory calculation:

1 configured field = ~100 bytes per virtual user
1000 unnecessary fields = 100 KB per VU
10,000 VUs = 1 GB wasted memory

Fewer VUs fit on each load engine, which means higher cloud costs. The fix is simple: only configure fields that actually need correlation. Ignoring static fields means more virtual users per dollar.

Cleaner Configuration: Easier Troubleshooting

Large test cases (100+ pages, 1000+ fields) become hard to navigate when Fields View is cluttered with static values.

Without auto-ignore:

  • Fields View shows 2000 fields (500 dynamic, 1500 static)
  • Finding the field causing replay failures requires scrolling through clutter
  • Hard to see which fields ASM actually configured

With auto-ignore:

  • Fields View shows 500 fields (only dynamic ones)
  • Easy to spot misconfigured fields (grey vs white background)
  • Faster troubleshooting

Show Ignored Fields

Can you show me which fields in my test case can be auto-ignored to
improve performance? Are there any static fields ASM is configuring
that should be ignored instead?

When to Use Custom Auto-Ignore Rules

Scenario 1: Application-Specific Static Fields

Problem: Your application has static fields ASM doesn't recognize.

Example: E-commerce site always posts currency=USD (never changes).

Without ignore rule: ASM configures currency field, extracts USD from every response, wastes memory.

With ignore rule: Add currency to ignore list → ASM skips it → uses recorded USD value → saves memory.

Scenario 2: Repeat Patterns Across Many Test Cases

Problem: You record 50 test cases, all have btnSubmit=Submit that doesn't need configuration.

Without ignore rule: Manually remove btnSubmit from Fields View in all 50 test cases (tedious).

With ignore rule: Add btnSubmit to global ignore list → ASM skips it in all test cases automatically.

Scenario 3: Timestamps You Control

Problem: Application posts timestamp=1234567890 from client-side JavaScript (not server-generated).

Typical behavior: ASM tries to correlate timestamp (finds it in responses, configures extraction).

Reality: Timestamp is client-generated, doesn't come from server, ASM correlation breaks.

Solution: Ignore timestamp → ASM skips correlation → client-side JavaScript generates fresh value during replay.

Scenario 4: Known Static Values

Problem: Form has hidden field version=2.0 that never changes.

Without ignore rule: ASM configures version, clutters Fields View.

With ignore rule: Add version to ignore list (by name or value) → ASM skips.

Configuring Auto-Ignore Rules

Accessing Ignore Preferences

  1. Window → Preferences (or Load Tester → Preferences on macOS)
  2. Web Performance → Configuration Wizards → Ignored Fields
  3. Two ignore lists appear:
  4. Ignored Names: Ignore fields by name (e.g., btnSubmit)
  5. Ignored Values: Ignore fields by value (e.g., Submit)

Ignore by Name

Use when: You know the field name that should always be ignored.

Example: Ignore all submit buttons named btnSubmit

How to configure:

  1. Click "Add" next to Ignored Names list
  2. Enter field name exactly: btnSubmit
  3. Click OK

Result: ASM skips any field named btnSubmit in all test cases.

Common field names to ignore:

btnSubmit
action
submit
continue
cancel
timestamp
clientTime
_ck         (client-side cookie tracking)
__utma      (Google Analytics)

Ignore by Value

Use when: You know the field value that indicates a static field.

Example: Ignore all fields with value Submit (regardless of name)

How to configure:

  1. Click "Add" next to Ignored Values list
  2. Enter field value exactly: Submit
  3. Click OK

Result: ASM skips any field with value Submit in all test cases.

Common field values to ignore:

Submit
Continue
Next
Back
Cancel

Ignore by Name OR Value

You can use both lists together:

Ignored Names OR Ignored Values
btnSubmit Submit

Result: ASM ignores fields that match either condition:

  • ✅ Field named btnSubmit (regardless of value)
  • ✅ Field with value Submit (regardless of name)

Why OR, not AND: More flexible, catching static fields using different naming conventions.

Testing Ignore Rules

After adding ignore rules:

  1. Right-click test case → Configure → Application State...
  2. ASM wizard runs with new ignore rules
  3. Open Fields View; ignored fields should be absent
  4. Run replay to verify static values still work

If replay fails after ignoring: Field wasn't actually static, remove from ignore list and let ASM configure it.

Best Practices for Auto-Ignore

1. Start Conservatively

Don't ignore fields you're not sure about. If a field might be dynamic, let ASM configure it.

Safe to ignore:

  • ✅ Submit button values you recognize (Submit, Continue, Next)
  • ✅ Known static hidden fields (version, appId)
  • ✅ Client-side timestamps (generated by JavaScript)

Risky to ignore:

  • ❌ Fields with numeric values (could be dynamic IDs)
  • ❌ Fields you've never seen before
  • ❌ Anything you're uncertain about

Rule: When in doubt, let ASM configure it. You can always add ignore rules later.

2. Test After Adding Ignore Rules

Always run replay after adding ignore rules to verify:

  • ✅ Ignored fields don't cause replay failures
  • ✅ Application accepts recorded static values
  • ✅ No unexpected behavior changes

If replay fails: Remove recently added ignore rule, re-run ASM, test again.

3. Use Name-Based Ignores for Consistency

Prefer "Ignored Names" over "Ignored Values" when possible.

Why: Field names are usually consistent across test cases. Field values can vary.

Example:

  • Good: Ignore by name btnSubmit → Catches all submit buttons
  • Risky: Ignore by value Submit → Might ignore legitimate dynamic fields that happen to have value "Submit"

4. Don't Ignore Blank Values

Blank Value Trap

If you add a blank entry to the Ignored Values list, ASM will ignore all fields with blank values. This is usually wrong. Many dynamic fields are blank in the recording but get values during replay.

Common mistake:

  1. Add empty string to Ignored Values (accidentally)
  2. ASM ignores all blank fields
  3. Replay fails because dynamic fields with blank recorded values weren't configured

Fix: Check ignore lists for blank entries, remove them.

5. Document Why Fields Are Ignored

Keep notes on why you added ignore rules, especially for application-specific patterns.

Example notes (external document or comments):

Ignored "currency" - always USD, never changes
Ignored "btnSubmit" - submit button value
Ignored timestamps - client-side generated, not from server

Why: You (or teammates) might wonder later why certain fields aren't configured.

Equivalent Field Names

The Problem: Name Mismatches in JSON/XML

Some applications use different field names in responses vs. requests:

Example: JSON API

Server sends (response): 

{
  "userId": "12345",
  "sessionToken": "abc123"
}

Client posts (request): 

user_id=12345
session_token=abc123

Name mismatch:

  • Response: userId (camelCase)
  • Request: user_id (snake_case)

Problem: ASM extracts userId from JSON, but test case posts field named user_id. ASM doesn't know they're the same field with different naming conventions, fails to correlate them.

Result: Replay uses hardcoded user_id=12345 instead of fresh extracted value.

The Solution: Equivalent Field Name Mappings

Equivalent field names tell ASM that two different names refer to the same field.

Mapping: userId (source name in response) ↔ user_id (destination name in request)

How it works:

  1. ASM extracts userId=67890 from JSON response
  2. Checks equivalency map: userId maps to user_id
  3. Assigns to field: Uses extracted value 67890 for user_id field
  4. Replay posts: user_id=67890 (fresh value)

Configuring Equivalent Field Names

Accessing Equivalent Field Names Preferences

  1. Window → Preferences
  2. Web Performance → Configuration Wizards → Application State → Equivalent Field Names
  3. Preferences page shows equivalency table

Adding an Equivalency Mapping

  1. Select Rule Family (JSON, XML, etc.)
  2. Click "Add"
  3. Enter mapping:
  4. Source Name: Name in response content (e.g., userId)
  5. Destination Field Name: Name in Fields View / POST data (e.g., user_id)
  6. Click OK

Result: ASM correlates userId from responses to user_id field in requests.

Rule Families

Rule family determines which detection rules use the equivalency mapping.

Common rule families:

  • JSON: For JSON API responses
  • XML: For XML/SOAP responses
  • HTML: For HTML form fields (rarely needed)

How to choose: Match the response content type where source name appears.

Example: If userId appears in JSON responses, use JSON rule family.

Exact Match vs. Regular Expression

Exact match (default):

  • Source Name: userId
  • Destination: user_id
  • Matches: Only exact userId → user_id

Regular expression (advanced):

  • Source Name: ([a-z]+)Id
  • Destination: $1_id
  • Matches: userId → user_id, sessionId → session_id, productId → product_id

When to use regex:

  • ✅ Many fields follow same naming pattern (camelCase → snake_case)
  • ✅ Want one mapping to handle multiple fields
  • ✅ Field names vary but pattern is consistent

Regex with capture groups: If regex has capture groups (...), they must match but can appear in any order.

Common Equivalent Field Name Scenarios

Scenario 1: camelCase (JSON) → snake_case (Form POST)

Problem: API sends camelCase, forms post snake_case.

Example:

  • Response: firstName, lastName, emailAddress
  • Request: first_name, last_name, email_address

Solution: Add three exact-match mappings (or one regex).

Exact mappings:

Source Name Destination Field Name
firstName first_name
lastName last_name
emailAddress email_address

Regex mapping (advanced):

Source Name (regex) Destination (regex)
([a-z]+)([A-Z][a-z]+) $1_$2 (lowercase)

Scenario 2: XML Namespaces

Problem: XML uses namespaced element names, form fields don't.

Example:

  • XML Response: <ns:userId>12345</ns:userId>
  • Form POST: userId=12345

Solution: Map ns:userId → userId

Configuration:

Source Name Destination Field Name
ns:userId userId

Rule Family: XML

Scenario 3: Abbreviated Names in Responses

Problem: Server abbreviates field names in responses, full names in forms.

Example:

  • Response: uId, sessToken
  • Request: userId, sessionToken

Solution: Map abbreviated to full names.

Configuration:

Source Name Destination Field Name
uId userId
sessToken sessionToken

Scenario 4: Different Casing

Problem: Response uses lowercase, form uses mixed case.

Example:

  • Response: userid
  • Request: userId

Solution: Map lowercase to mixed case.

Configuration:

Source Name Destination Field Name
userid userId

Note: ASM is case-sensitive. userId ≠ userid without equivalency mapping.

Troubleshooting Auto-Ignore & Equivalencies

Problem: Replay Fails After Adding Ignore Rule

Symptoms: Added field to ignore list, replay now fails with errors.

Possible cause: Field wasn't actually static, needs correlation.

Solution:

  1. Remove field from ignore list
  2. Re-run ASM to configure the field
  3. Check if field value changes between recording and replay
  4. If truly static, investigate why replay fails (may be unrelated)

Problem: Equivalency Mapping Not Working

Symptoms: Added equivalency mapping, ASM still doesn't correlate field.

Possible causes:

  1. Wrong rule family: Source name in XML but mapped under JSON family
  2. Spelling error: Source or destination name misspelled
  3. ASM not re-run: Equivalencies only apply when ASM wizard runs
  4. Case mismatch: userId ≠ UserID (case-sensitive)

Solutions:

Verify rule family:

  • Check response Content-Type: application/json → JSON family
  • Check response Content-Type: text/xml → XML family

Double-check spelling:

  • View response content, copy/paste exact source name
  • Check Fields View for exact destination field name

Re-run ASM:

  1. Right-click test case → Configure → Application State...
  2. Equivalency mappings only take effect during ASM run

Check case sensitivity:

  • Source name must match EXACTLY (case-sensitive)
  • Destination name must match EXACTLY

Problem: Too Many Fields Ignored

Symptoms: Fields View empty or very sparse after ASM, replay fails.

Possible cause: Ignore rules too broad, caught dynamic fields.

Example: Added blank value to Ignored Values, now all blank fields ignored.

Solution:

  1. Review ignore lists for overly broad patterns
  2. Remove problematic entries
  3. Re-run ASM

Problem: Regex Equivalency Matches Wrong Fields

Symptoms: Regex mapping correlates unintended fields.

Possible cause: Regex pattern too broad.

Example:

  • Pattern: .*Id (any field ending in "Id")
  • Matches: userId ✅, recordId ✅, gridId ❌ (not intended)

Solution: Make regex more specific.

Fixed pattern: ^(user|session)Id$ (only userId or sessionId)

Troubleshooting Help

I added an equivalency mapping for "userId" → "user_id" but ASM still
isn't correlating the field. The response is JSON with Content-Type
application/json. What could be wrong?

Auto-Ignore vs. Manual Removal

When to Use Auto-Ignore

Use auto-ignore preferences when:

  • ✅ Same field appears in multiple test cases (set it once, applies everywhere)
  • ✅ Field pattern is predictable (e.g., all submit buttons named btnSubmit)
  • ✅ You want consistent ignore behavior across all test cases

Benefits:

  • Set once, applies to all future test cases automatically
  • No need to manually remove field from each test case
  • Cleaner, more maintainable configuration

When to Manually Remove Fields

Manually remove from Fields View when:

  • ✅ Field is specific to one test case (not a general pattern)
  • ✅ You want fine-grained control (ignore in this test case, configure in others)
  • ✅ Temporary ignore (might need to correlate it later)

How to manually remove:

  1. Open Fields View
  2. Right-click field → Delete
  3. Field removed from this test case only (not global)

Difference:

  • Auto-ignore: Global rule, applies to all test cases
  • Manual removal: Per test case, doesn't affect others

Performance Impact: Measuring the Benefit

Before Auto-Ignore

Example test case:

  • 2000 total fields
  • 1500 static (submit buttons, timestamps, version numbers)
  • 500 dynamic (session cookies, CSRF tokens, user data)

Memory per VU:

2000 fields × 100 bytes = 200 KB per VU
10,000 VUs = 2 GB memory

After Auto-Ignore

Same test case:

  • 500 configured fields (only dynamic ones)
  • 1500 fields ignored

Memory per VU:

500 fields × 100 bytes = 50 KB per VU
10,000 VUs = 500 MB memory

Result: 75% memory reduction, allowing 4x more VUs on the same hardware.

Real-World Scenario

Cloud load test (AWS, 10,000 VUs):

  • Without auto-ignore: 2 GB/VU x 10,000 = 20 GB total, requires 4x c5.4xlarge instances (~$2.50/hour)
  • With auto-ignore: 500 MB/VU x 10,000 = 5 GB total, requires 1x c5.4xlarge instance (~$0.68/hour)

Over an 8-hour test, that's $14.56 saved per run.

Performance Win

Auto-ignore isn't just cleaner configuration. It's real money saved on cloud load tests.

Next Steps

Related Topics: