以 Playwright 自動化 Salesforce Lightning：為何通用定位器會構成挑戰

Salesforce Lightning applications can be challenging to automate, particularly when dealing with complex page structures, dynamically rendered components and repeated UI elements.

One challenge that becomes increasingly noticeable when working with browser automation is locator identification.

Consider a Salesforce page where similar search controls appear in multiple locations, or where several records contain buttons labelled "Edit", "Approve", "Reject" or "View".

For a human, identifying the correct element is relatively straightforward because we understand the visual and business context in which it appears. We know which record, section or component we are interacting with.

For an automation script, however, identifying the intended element reliably requires more than just knowing its accessible name.

This becomes even more interesting when introducing AI into test automation.

The challenge with generic locator generation

Playwright provides several powerful ways to identify elements, including accessible roles, names, text and other locator strategies.

For example:

const editButton = page.getByRole('button', {
  name: 'Edit'
});

await editButton.click();

This works when the target button is unique.

But what happens when the same button appears in multiple sections of the page?

Playwright uses strictness checks for operations that require a single element. If the locator matches multiple elements, it throws a strict mode violation rather than arbitrarily selecting one.

One possible workaround is positional selection using nth():

const editButton = page.getByRole('button', {
  name: 'Edit'
}).nth(1);

await editButton.click();

Although this can work, it introduces a dependency on element ordering. If the page structure changes or another matching element is introduced, the locator may target the wrong element.

The problem is not necessarily the locator strategy itself. It is the lack of sufficient context to distinguish between elements.

Finding an element is one thing. Identifying the correct element within its intended context is another.

A practical challenge in Salesforce Lightning

This problem becomes more noticeable in real Salesforce workflows.

For example, search functionality may be available in multiple areas of the interface. Depending on the page and application state, similar search controls can appear with identical or similar accessible names.

A human user can usually distinguish between them using their position and surrounding interface.

An AI-driven automation framework, however, may receive multiple elements with similar descriptions. Without sufficient context, it may select the wrong search control or fail to identify which one is relevant to the requested operation.

The same challenge appears in workflows involving parent and child cases.

Consider a workflow where an automation script needs to change the owner of a particular case, update its status to In Progress, or perform an approval or rejection action.

When parent and child cases contain similar fields and actions, identifying an element by its name alone may not be enough.

The automation needs to understand which case it is interacting with and which controls belong to that specific record.

This is not simply an element-identification problem. It is a context-identification problem.

Why AI-driven automation introduces another challenge

AI-assisted automation adds another dimension to this problem.

An LLM can inspect page information and attempt to identify the target element based on the context it receives.

However, when that information contains numerous similar elements, the model must distinguish between them and understand their relationships.

For complex enterprise applications, providing an entire page representation can introduce a significant amount of information that may not be relevant to the requested interaction.

The model needs to determine:

1. Which section contains the intended element?
2. What is the relationship between the parent and child elements?
3. Are there multiple elements with identical accessible names?
4. Which element belongs to the requested business context?

For example, asking an AI agent to locate a search bar or an Edit button may not be sufficient when multiple matching elements exist.

The agent needs to understand which section or record it should interact with before identifying the element.

This makes context an important part of AI-driven locator generation.

What if we changed the way we provide context?

Instead of asking AI to identify an element across the entire page, what if we first helped it understand the relevant section?

Imagine a page containing multiple customer records, each with its own Edit button.

Rather than identifying an Edit button globally, we can first identify the relevant customer container and then locate the button within that container.

This is the principle behind scoped locator strategies.

Playwright supports this through locator chaining and filtering:

const customerSection = page
  .getByTestId('customer-card')
  .filter({
    has: page.getByRole('heading', {
      name: 'Customer A',
      exact: true
    })
  });

const editButton = customerSection.getByRole('button', {
  name: 'Edit',
  exact: true
});

await editButton.click();

Here, the first locator identifies the relevant customer container. The second locator searches for the Edit button within that container.

This establishes a parent-child relationship between the locators rather than searching for the button across the entire page.

The example uses illustrative test IDs and headings; the actual selectors depend on the application's markup and accessibility structure.

We should still validate that the parent and child locators resolve to exactly one intended