Cho AI điều khiển trình duyệt để kiểm thử thăm dò với Playwright MCP
Playwright MCP cho phép LLM tương tác với trang web qua accessibility snapshot thay vì ảnh chụp màn hình. Dưới đây là cách QA dùng nó cho kiểm thử thăm dò, ghi nhận phát hiện và chuẩn bị regression test.
Một ticket ghi: “Người dùng có thể áp mã giảm giá ở trang thanh toán”. Happy path thường không khó. Phần tốn thời gian là các nhánh còn lại: để trống mã, nhập mã không hợp lệ, bấm Apply nhiều lần, tải lại trang, hoặc kiểm tra tổng tiền có thực sự đổi đúng lúc hay không.
Playwright MCP gợi ý một cách làm khác cho QA: giao cho AI một mục tiêu kiểm thử rõ ràng, để AI thao tác trình duyệt và quan sát cấu trúc trang; sau đó QA kiểm tra lại phát hiện, viết bug report và chuẩn hóa những trường hợp quan trọng thành regression test.
Điểm cần nhớ: đây không phải “để AI test thay người”. AI có thể hỗ trợ khám phá và ghi nhận; QA vẫn là người xác định phạm vi, expected result và mức độ tin cậy của kết quả.
Playwright MCP là gì?
Playwright MCP là một MCP server cung cấp khả năng tự động hóa trình duyệt bằng Playwright cho các mô hình ngôn ngữ lớn (LLM).
Thay vì dựa vào ảnh chụp màn hình và tọa độ pixel, Playwright MCP sử dụng accessibility tree của trang. Đây là dữ liệu có cấu trúc thể hiện các thành phần như heading, link, button và textbox, cùng tên hoặc trạng thái liên quan.
Theo README của dự án, cách tiếp cận này có một số đặc điểm:
Làm việc với dữ liệu cấu trúc thay vì thao tác theo pixel.
Không yêu cầu mô hình thị giác.
Giảm sự mơ hồ thường gặp khi chỉ dựa vào ảnh chụp màn hình.
Phù hợp với các vòng lặp tác tử cần quan sát cấu trúc trang và suy luận lặp lại.
Với QA, điều này hữu ích khi cần cho AI đi qua một luồng, quan sát trạng thái trước và sau thao tác, rồi tóm tắt những gì đã thấy.
> Playwright MCP là giao diện MCP cho Playwright, không thay thế trực tiếp bộ test regression hiện có. Những ca kiểm thử quan trọng vẫn nên được chuẩn hóa thành mã test và review trước khi đưa vào pipeline.
Khi nào nên dùng MCP, khi nào nên dùng Playwright CLI?
README của Playwright MCP phân biệt hai hướng sử dụng:
Playwright CLI với SKILLs có thể phù hợp hơn cho coding agent xử lý codebase lớn hoặc cần throughput cao. README nêu rằng CLI có thể tiết kiệm token hơn vì tránh nạp schema công cụ lớn và accessibility tree dài vào context.
Playwright MCP vẫn phù hợp cho các vòng lặp cần trạng thái liên tục, quan sát cấu trúc phong phú và suy luận lặp lại, chẳng hạn exploratory automation hoặc workflow tự động kéo dài.
Với kiểm thử thăm dò, MCP đáng cân nhắc khi bạn muốn AI quan sát trang, thực hiện một chuỗi thao tác theo charter và báo lại những điểm cần QA xác minh.
Thiết lập Playwright MCP
Theo README, bạn cần:
Node.js phiên bản 18 trở lên.
Một MCP client tương thích, chẳng hạn VS Code, Cursor, Windsurf, Claude Desktop, Goose, Grok hoặc Junie.
Cấu hình chuẩn được cung cấp như sau:
js
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}
Một số client có lệnh cấu hình riêng. Ví dụ, với Claude Code:
bash
claude mcp add playwright npx @playwright/mcp@latest
Với Codex CLI:
bash
codex mcp add playwright npx "@playwright/mcp@latest"
Sau khi cấu hình, hãy kiểm tra trong client đang dùng rằng Playwright MCP server đã được nhận trước khi giao nhiệm vụ cho agent.
Giao việc bằng test charter, không phải câu lệnh mơ hồ
Prompt kiểu “test trang này xem có lỗi không” thường khó tạo ra đầu ra hữu ích. AI cần biết mục tiêu, phạm vi, dữ liệu được phép dùng và cách báo cáo kết quả.
Bạn có thể dùng mẫu charter sau:
text
Bạn là QA thực hiện exploratory testing trên <URL hoặc môi trường test>.
Mục tiêu nghiệp vụ:
<chức năng cần kiểm thử>
Phạm vi:
Chỉ kiểm thử các luồng: <danh sách luồng>
Dùng tài khoản test: <tài khoản test được cấp>
Không thực hiện thao tác không thể hoàn tác.
Không truy cập dữ liệu ngoài phạm vi.
Rủi ro cần ưu tiên:
<validation>
<phân quyền>
<trạng thái sau reload>
<xử lý lỗi>
Cách làm:
Quan sát cấu trúc trang trước mỗi thao tác quan trọng.
Thử happy path và các biến thể biên phù hợp.
Với mỗi phát hiện, ghi lại: bước tái hiện, dữ liệu đầu vào,
hành vi thực tế, hành vi kỳ vọng theo đặc tả và bằng chứng quan sát được.
Nếu kỳ vọng không có trong đặc tả, đánh dấu “cần QA xác nhận”,
không tự kết luận là bug.
Kết thúc bằng:
Các luồng đã đi qua
Các rủi ro chưa kiểm tra được
Danh sách đề xuất regression test
Charter giúp QA kiểm soát phiên khám phá ngay từ đầu: AI được giao việc gì, không được chạm vào đâu và phải trả về bằng chứng theo cấu trúc nào.
Ví dụ: khám phá luồng áp mã giảm giá
Giả sử đặc tả ghi:
> Người dùng nhập mã giảm giá rồi chọn Apply. Mã hợp lệ cập nhật tổng tiền; mã không hợp lệ hiển thị lỗi và tổng tiền không đổi.
Bạn có thể giao nhiệm vụ:
text
Kiểm thử thăm dò khu vực áp mã giảm giá tại <URL>.
Kiểm tra:
Mã hợp lệ
Mã không hợp lệ
Ô mã để trống
Thao tác Apply lặp lại
Trạng thái tổng tiền và thông báo sau mỗi thao tác
Không suy đoán giá trị giảm giá nếu trang không hiển thị rõ.
Ghi lại tên control, trạng thái enabled/disabled và nội dung thông báo
theo accessibility snapshot.
Sau khi khám phá, đề xuất các test regression Playwright ở mức hành vi.
Một đầu ra có ích không chỉ là “đã test xong”. Nó nên có:
Luồng đã thực hiện và dữ liệu test tương ứng.
Các bước tái hiện theo thứ tự thao tác.
Trạng thái UI trước và sau khi chọn Apply.
Nội dung thông báo mà AI quan sát được.
Những điểm chưa thể kết luận vì đặc tả chưa nói rõ.
Đề xuất trường hợp nên đưa vào regression.
Ví dụ, nếu đặc tả đã nêu mã không hợp lệ không được thay đổi tổng tiền, đó là một assertion hành vi phù hợp để cân nhắc đưa vào regression test.
Từ phát hiện sang test regression
Sau khi QA xác nhận quan sát và expected result, có thể yêu cầu AI phác thảo test tự động:
text
Dựa trên các quan sát đã xác nhận, hãy soạn một test regression Playwright
cho trường hợp <tên trường hợp>.
Yêu cầu:
Dùng locator dựa trên role, label hoặc tên control có ý nghĩa.
Assertion kiểm tra hành vi nghiệp vụ đã được xác nhận.
Liệt kê giả định về test data và trạng thái ban đầu.
Đừng đưa mã AI tạo ra vào bộ regression ngay lập tức. Hãy review ít nhất các điểm sau:
Test có phản ánh đúng đặc tả đã được xác nhận không?
Test data có ổn định và phù hợp với môi trường test không?
Locator có bám vào đặc điểm có ý nghĩa của control không?
Assertion có kiểm tra kết quả nghiệp vụ, thay vì chỉ kiểm tra một phần tử xuất hiện không?
Test có chạy lại được từ trạng thái ban đầu rõ ràng không?
Những điểm QA vẫn phải cầm lái
Playwright MCP có thể giúp AI thao tác qua dữ liệu cấu trúc của trang, nhưng không tự biết hành vi nghiệp vụ nào là đúng.
Trước khi tạo bug hoặc thêm test, QA cần kiểm tra:
Coverage: AI đã đi qua các chuyển trạng thái quan trọng hay mới chỉ chạy happy path?
Expected result: Kỳ vọng có nằm trong đặc tả, acceptance criteria hoặc quyết định đã thống nhất không?
Bằng chứng: Quan sát được có đủ bước tái hiện và trạng thái trước/sau thao tác không?
Khả năng tái hiện: Có thể chạy lại từ một phiên hoặc dữ liệu test phù hợp không?
Mức độ kết luận: Nếu thiếu thông tin, hãy ghi là câu hỏi cần làm rõ thay vì gọi đó là bug.
Checklist trước khi chạy exploratory session
[ ] Có test charter nêu rõ mục tiêu và phạm vi.
[ ] Có môi trường và tài khoản test phù hợp.
[ ] Có expected result, hoặc đã đánh dấu những điểm cần xác nhận.
[ ] Có yêu cầu AI ghi lại bước tái hiện và bằng chứng quan sát.
[ ] Có bước QA review trước khi tạo bug hoặc thêm regression test.
Playwright MCP phù hợp để tăng tốc vòng lặp khám phá → ghi nhận → chuẩn hóa thành regression. Hãy để AI hỗ trợ thao tác và tóm tắt quan sát; còn QA vẫn cần cầm lái ở phần quan trọng nhất: đặt câu hỏi đúng, xác thực kỳ vọng và bảo vệ chất lượng bộ test.