Kiểm thử WebMCP cho AI agent: đừng dừng ở việc tool gọi được
Playwright 1.64 cho phép liệt kê và gọi các tool WebMCP do trang đăng ký. Với QA, test cần vượt qua happy path: kiểm tra phân quyền, dữ liệu đầu vào/đầu ra bất thường và cách agent phản hồi khi tool lỗi.
Tool WebMCP gọi thành công chỉ chứng minh một việc: đường kết nối đang hoạt động.
Nó chưa cho biết agent có dùng đúng quyền hay không, dữ liệu có bị vượt phạm vi hay không, hoặc agent sẽ phản hồi thế nào khi tool trả lỗi, rỗng hay thiếu trường. Với QA, đây mới là phần đáng kiểm thử trước khi đưa agent vào luồng có dữ liệu thật.
Playwright 1.64 bổ sung page.webmcp và frame.webmcp, cho phép test liệt kê và gọi các tool WebMCP mà trang đăng ký. Vì WebMCP là API trình duyệt thử nghiệm, bộ test nên đi xa hơn happy path ngay từ đầu.
WebMCP bổ sung một bề mặt cần test
Theo ghi chú phát hành Playwright 1.64, website có thể đăng ký các tool để AI agent gọi trực tiếp. Test có thể liệt kê tool, đọc tên và mô tả, rồi gọi tool như một phần của ứng dụng.
Ví dụ phát hành của Playwright bật WebMCP trên Chromium, sau đó gọi tool add:
js
const browser = await chromium.launch({
args: ['--enable-features=WebMCP']
});
const page = await browser.newPage();
await page.goto('https://example.com');
for (const tool of await page.webmcp.tools())
console.log(tool.name, tool.description);
const result = await page.webmcp.callTool('add', { a: 2, b: 40 });
console.log(result.content[0].text);
// "42"
Playwright MCP cũng hỗ trợ WebMCP mặc định: các tool do trang định nghĩa được cung cấp cho agent với tiền tố webmcp. Có thể tắt bằng tùy chọn --no-webmcp.
Playwright CLI cũng có các lệnh để khám phá và gọi tool:
bash
playwright-cli webmcp-list
bash
playwright-cli webmcp-call searchcatalog --params {"query":"cats"}
Với QA, một tool không chỉ là “hàm gọi được”. Nó có tên, mô tả, tham số, phản hồi, lỗi và quy tắc truy cập cần được xác nhận như mọi API hay tích hợp khác.
Ưu tiên nào trước: happy path, quyền hay dữ liệu lạ?
Nếu phải chọn điểm bắt đầu, phân quyền thường có rủi ro cao hơn happy path.
Luồng thành công vẫn cần thiết để xác nhận tool hoạt động. Nhưng lỗi nghiêm trọng hơn thường xuất hiện khi cùng một tool được gọi trong các phiên khác nhau: người dùng A không được nhận dữ liệu của người dùng B, và một lời gọi bị từ chối không được tạo thay đổi ngoài ý muốn.
Một cách chia bộ test thực dụng là theo ba lớp:
| Lớp test | Câu hỏi cần trả lời | Ví dụ cần phát hiện |
|---|---|---|
| Phân quyền | Ai được gọi tool? Ai được xem trường dữ liệu nào? | Phiên của A nhận bản ghi thuộc B |
| Dữ liệu bất thường | Input hoặc output không như kỳ vọng được xử lý ra sao? | Thiếu trường, sai kiểu dữ liệu, phản hồi rỗng |
| Luồng thành công | Tool có hoạt động với dữ liệu hợp lệ không? | Tool không được đăng ký hoặc không nhận đúng tham số |
Happy path là nền tảng. Nhưng phân quyền và xử lý lỗi mới quyết định agent có an toàn và đáng tin trong môi trường thực tế hay không.
1. Test phân quyền bằng ma trận vai trò × tool × dữ liệu
Đừng chỉ kiểm tra một tài khoản đăng nhập thành công. Hãy lập ma trận cho từng tool theo các chiều sau:
Vai trò hoặc trạng thái phiên: được phép, bị hạn chế, chưa đăng nhập.
Nhóm tool: đọc dữ liệu, thay đổi dữ liệu, tìm kiếm.
Phạm vi dữ liệu: dữ liệu của chính người dùng, dữ liệu ngoài phạm vi, bản ghi không tồn tại.
Kết quả kỳ vọng: được trả dữ liệu hợp lệ, bị từ chối theo contract, hoặc không được trả các trường không phù hợp.
Một test phân quyền tốt không chỉ kiểm tra “có lỗi hay không”. Nó cần xác nhận:
phản hồi không để lộ dữ liệu không thuộc phạm vi truy cập;
lời gọi bị từ chối không tạo thay đổi dữ liệu;
hành vi của agent sau phản hồi bị từ chối phù hợp với yêu cầu sản phẩm;
việc tool có xuất hiện trong danh sách tool hay không phù hợp với thiết kế của sản phẩm, nếu sản phẩm có yêu cầu này.
Nếu agent có transcript hoặc nhật ký, nên lưu cả lời gọi tool, phản hồi tool và câu trả lời cuối. Đây là bằng chứng rõ hơn ảnh chụp riêng một đoạn chat.
2. Test dữ liệu bất thường theo cả hai chiều
Input bất thường là phần quen thuộc trong kiểm thử: thiếu trường bắt buộc, giá trị rỗng, sai kiểu, giá trị biên, chuỗi dài hoặc ký tự đặc biệt.
Với WebMCP, còn có chiều ngược lại: tool trả dữ liệu bất thường về cho agent.
Một ý kiến trong thảo luận cộng đồng là nên thử cho tool trả về văn bản chứa chỉ dẫn không liên quan đến tác vụ để quan sát agent xử lý ra sao. Đây không phải cơ chế mà Playwright tự xử lý, nhưng là tình huống nên được đưa vào đánh giá rủi ro nếu output của tool có thể chứa nội dung không tin cậy.
Danh sách case tối thiểu cho mỗi tool có thể gồm:
Input thiếu trường mà agent hoặc tool cần.
Input đúng cấu trúc nhưng không có dữ liệu tương ứng.
Tool trả phản hồi rỗng.
Tool trả thiếu trường cần cho bước hiển thị hoặc kết luận.
Tool trả lỗi theo contract đã định nghĩa.
Tool trả văn bản không liên quan đến yêu cầu hiện tại.
Tool trả kết quả hợp lệ về mặt kỹ thuật nhưng không nằm trong phạm vi dữ liệu của phiên hiện tại.
Điểm quan trọng là tách riêng hai expected result:
Hành vi của tool: trả dữ liệu, phản hồi rỗng hay lỗi theo contract.
Hành vi của agent: diễn giải phản hồi đó cho người dùng theo yêu cầu UX và nghiệp vụ.
Ví dụ, tool trả rỗng có thể là hành vi đúng. Khi đó, tiêu chí kiểm thử của agent là không tự tạo ra danh sách kết quả không có trong phản hồi tool.
3. Khi tool lỗi hoặc thiếu trường, kiểm thử điều gì?
Ghi chú phát hành Playwright không định nghĩa một schema lỗi chung cho mọi WebMCP tool. Vì vậy, trước khi viết assertion chi tiết, QA cần lấy contract của từng tool từ đội phát triển hoặc tài liệu đặc tả.
Với mỗi lỗi đã được định nghĩa, hãy làm rõ:
Tool trả cấu trúc gì khi lỗi?
Trường nào có thể vắng mặt?
Agent được phép nói gì với người dùng?
Agent có được thử lại không? Nếu có, trong điều kiện nào?
Có hành động nào tuyệt đối không được thực hiện sau khi tool thất bại không?
Cần lưu bằng chứng nào để tái hiện lỗi?
Nếu đặc tả chưa trả lời các câu hỏi này, đó là một gap cần được xác nhận thay vì để automation tự suy đoán.
Dùng AI để phác thảo test case, không để AI tự quyết định contract
AI có thể giúp chuyển feature spec thành danh sách case ban đầu. Tuy nhiên, không nên đưa credentials, cookie, token hoặc dữ liệu production vào công cụ AI công khai.
Prompt mẫu:
text
Bạn là QA engineer. Hãy thiết kế test case cho WebMCP tool sau.
Tên tool: <toolname>
Mục đích: <mô tả nghiệp vụ>
Input schema: <schema>
Output schema thành công: <schema>
Các vai trò: <rolelist>
Quy tắc phân quyền: <authorizationrules>
Các lỗi đã định nghĩa: <errorcontract>
Yêu cầu:
Chia test case thành happy path, authorization, invalid input,
malformed output và tool error.
Mỗi case gồm: precondition, tool call, test data, expected tool response,
expected final agent behavior, evidence cần lưu.
Nêu rõ assumption nào chưa có trong spec.
Không tự bịa schema, mã lỗi hay cơ chế xác thực.
Sau khi có bản nháp, tester vẫn cần review ít nhất ba điểm:
Có thiếu vai trò hoặc trạng thái phiên không?
Hệ thống thực tế có thể nhiều trạng thái hơn cặp “admin/user”.
Expected result có được đặc tả hỗ trợ không?
Nếu spec chưa định nghĩa message hoặc mã lỗi, cần đánh dấu là câu hỏi mở.
Automation có phụ thuộc dữ liệu hoặc fixture mong manh không?
Với test WebMCP trực tiếp, assertion nên bám vào contract tool. Nếu agent đi qua UI, cần lưu thêm trace hoặc video khi cần tái hiện luồng.
Bằng chứng nào cần có trong bug report?
Một bug liên quan WebMCP nên đủ dữ liệu để dev và QA cùng tái hiện:
vai trò, trạng thái đăng nhập và dữ liệu test;
tên tool, tham số gọi và thời điểm gọi;
raw response từ tool, sau khi che dữ liệu nhạy cảm;
câu trả lời cuối của agent;
expected result và rule hoặc schema làm căn cứ;
trace hoặc video nếu lỗi xảy ra trong luồng trình duyệt.
Playwright 1.64 cũng bổ sung tùy chọn chỉnh frame rate video và cách hiển thị hành động trong video. Những tính năng này có thể hữu ích khi cần chứng minh các bước UI trước hoặc sau lời gọi tool.
Tuy vậy, video không thay thế payload. Với lỗi phân quyền hoặc lỗi dữ liệu, request và response đã được che thông tin nhạy cảm thường là bằng chứng quan trọng nhất.
Checklist trước khi đóng test WebMCP
[ ] Tool được liệt kê và gọi thành công trong luồng hợp lệ.
[ ] Cùng một tool đã được test với các quyền hoặc trạng thái phiên liên quan.
[ ] Đã kiểm tra dữ liệu không vượt phạm vi người dùng.
[ ] Có case input thiếu, sai hoặc rỗng.
[ ] Có case output rỗng, lỗi và thiếu trường.
[ ] Đã xác nhận hành vi kỳ vọng của agent khi tool không trả được kết quả.
[ ] Đã lưu lời gọi, phản hồi và câu trả lời agent sau khi che dữ liệu nhạy cảm.
[ ] Các điểm chưa được contract định nghĩa đã được ghi nhận để làm rõ.
Tool gọi thành công chứng minh tích hợp có thể chạy. Bộ test về phân quyền, dữ liệu bất thường và lỗi mới cho biết agent có hành xử đúng khi gặp dữ liệu và tình huống thật.