Locator tự chữa lành bằng AI: tăng tốc mà không che lỗi thật

1. Bối cảnh: vì sao locator gãy khi giao diện thay đổi

Trên một sàn thương mại điện tử, đội QA duy trì hàng trăm kịch bản end-to-end phủ luồng tìm kiếm, thêm giỏ hàng, áp mã giảm giá và thanh toán. Mỗi lần đội frontend đổi cấu trúc DOM — thêm một thẻ bọc, đổi lớp CSS sinh tự động, hay chuyển nút sang component mới — hàng loạt locator dựa trên XPath hoặc lớp CSS gãy đồng loạt. Kết quả là pipeline đỏ rực dù nghiệp vụ không hề thay đổi. Đây chính là bài toán mà locator tự chữa lành (self-healing) hướng tới: giữ cho bộ kiểm thử bám vào ý nghĩa của phần tử thay vì bám vào chi tiết cấu trúc dễ vỡ.

Locator gãy có hai loại hoàn toàn khác nhau, và phân biệt chúng là cốt lõi của toàn bài. Loại thứ nhất là gãy do tái cấu trúc: phần tử vẫn tồn tại, vẫn cùng vai trò và nhãn, chỉ khác đường đi tới nó — đây là lúc self-healing thực sự có ích. Loại thứ hai là gãy do lỗi thật: nút 'Đặt hàng' biến mất vì một bug logic, hoặc bị disable sai. Nếu AI 'chữa lành' bằng cách nhảy sang một nút khác gần giống, nó sẽ che mất chính lỗi mà bài kiểm thử sinh ra để bắt. Vì vậy oracle phải đặt lên trên: bài test khẳng định bất biến nghiệp vụ, còn cơ chế heal chỉ được phép thay đổi cách tìm phần tử, tuyệt đối không thay đổi điều được khẳng định.

2. Neo locator vào ý nghĩa, không vào cấu trúc

Trước khi bàn tới AI, phải thừa nhận rằng phần lớn locator gãy đến từ lựa chọn tồi ngay từ đầu. Một XPath tuyệt đối kiểu /html/body/div[3]/div/button[2] gãy chỉ vì thêm một div bọc. Ngược lại, getByRole('button', { name: 'Đặt hàng' }) bám vào accessibility tree — thứ phản ánh ý nghĩa mà người dùng và trình đọc màn hình cảm nhận. Khi bạn neo vào vai trò và tên có thể truy cập (accessible name), locator sống sót qua hầu hết đợt tái cấu trúc thuần túy trình bày. Self-healing bằng AI nên được xem là lưới an toàn cho phần còn lại, chứ không phải cái cớ để tiếp tục viết selector giòn.

Trên sàn thương mại điện tử của chúng ta, một quy ước tốt là gắn data-testid cho các phần tử nghiệp vụ then chốt: nút thanh toán, ô nhập mã giảm giá, tổng tiền giỏ hàng. data-testid tách rời khỏi lớp trình bày, không đổi khi thiết kế thay đổi, và cho AI một mỏ neo rõ ràng để suy luận. Kết hợp getByRole cho phần tử tương tác chuẩn và data-testid cho phần tử nghiệp vụ đặc thù, bạn giảm mạnh số lần cần tới heal ngay từ đầu — và mỗi lần heal thật sự xảy ra sẽ đáng chú ý hơn, dễ điều tra hơn.

// locators.ts — neo vào ý nghĩa: role / label / testid, KHÔNG dùng XPath tuyệt đối
import { Page, Locator } from '@playwright/test';

export class CheckoutPage {
  constructor(private page: Page) {}

  // Ổn định: bám accessibility tree (role + accessible name)
  placeOrder(): Locator {
    return this.page.getByRole('button', { name: /đặt hàng|place order/i });
  }
  // Ổn định: business testid tách khỏi lớp trình bày
  couponInput(): Locator {
    return this.page.getByTestId('checkout-coupon-input');
  }
  cartTotal(): Locator {
    return this.page.getByTestId('cart-total');
  }
}

// ❌ Đừng làm: XPath tuyệt đối gãy khi thêm 1 div bọc
// page.locator('xpath=/html/body/div[3]/div/button[2]')

3. AI đề xuất locator thay thế từ accessibility tree và DOM snapshot

Khi một locator không tìm thấy phần tử, cơ chế self-healing bắt đầu bằng việc chụp một snapshot của trạng thái trang: accessibility tree (role, tên, trạng thái) kèm DOM rút gọn. Từ v1.60, ARIA snapshot của Playwright còn kèm bounding box — toạ độ layout — nên AI có cả ngữ nghĩa lẫn vị trí không gian để suy luận. AI sẽ so khớp mô tả gốc của phần tử (ví dụ 'nút submit tên Đặt hàng, gần ô tổng tiền') với các ứng viên trong snapshot, rồi đề xuất một hoặc vài locator thay thế xếp theo độ phù hợp. Điểm quan trọng: đầu vào là cây ngữ nghĩa, không phải ảnh pixel — nên đề xuất bám vào ý nghĩa phần tử.

Có nhiều tín hiệu để chấm điểm ứng viên: khớp vai trò (một button không thể chữa thành một link), khớp tên có thể truy cập, khoảng cách chuỗi giữa nhãn cũ và mới, độ gần về vị trí layout, và ngữ cảnh cha (cùng nằm trong form thanh toán). Một hệ thống nghiêm túc kết hợp các tín hiệu này thành một điểm tin cậy duy nhất, thay vì mù quáng lấy phần tử đầu tiên trông giống. Nếu vai trò không khớp, điểm phải bằng không — vì chữa một button thành link gần như luôn là dấu hiệu của lỗi thật, không phải tái cấu trúc.

4. Chấm điểm tin cậy và ngưỡng quyết định

Điểm tin cậy chỉ hữu ích nếu gắn với một chính sách quyết định rõ ràng. Một mô hình ba mức thực dụng: trên ngưỡng cao (ví dụ 0.9) và trùng vai trò thì cho phép heal nhưng vẫn ghi log; trong vùng xám (0.6–0.9) thì đánh dấu để con người xem lại, không tự chữa trong nhánh chính; dưới ngưỡng thấp thì để test fail như bình thường vì nhiều khả năng là lỗi thật. Ngưỡng không phải hằng số vũ trụ — bạn hiệu chỉnh nó dựa trên dữ liệu lịch sử: bao nhiêu lần heal về sau bị xác nhận là đúng, bao nhiêu lần là che lỗi.