CYBERSOFT
Đăng nhập

Ngân hàng câu hỏi phỏng vấn: AI trong kiểm thử và kiểm thử AI agent

Chuyên phỏng vấnDịch vụ SaaSAI AgentPhỏng vấnKinh nghiệmNâng cao
🗓 1 tháng trước21 phút đọc·👁 1,002 lượt xem👤 95 người đọc

Bản đồ chủ đề, câu hỏi theo cấp độ Junior/Mid/Senior/Lead kèm câu trả lời mẫu và follow-up, một kịch bản phỏng vấn 1-1 giả lập, những lỗi khiến ứng viên rớt và checklist ôn tập.

1. Bản đồ chủ đề: phỏng vấn 'AI trong kiểm thử' hỏi gì

Phỏng vấn về AI trong kiểm thử không kiểm tra bạn có thuộc lòng tên công cụ, mà kiểm tra bạn có tư duy đúng về khi nào tin và không tin AI. Sáu cụm chủ đề thường gặp: kiến trúc một AI test agent, bộ ba planner/generator/healer của các công cụ hiện đại, giao thức MCP để mô hình điều khiển trình duyệt, hiện tượng ảo giác và grounding, guardrails cùng human-in-the-loop, và LLM-as-judge. Xuyên suốt mọi cụm là một câu hỏi lõi: khi nào bạn tin test do AI sinh ra và khi nào không. Bài này sắp xếp câu hỏi theo cấp độ để bạn tự định vị và luyện đúng chỗ.

Bản đồ chủ đề phỏng vấn "AI trong kiểm thử" AI Agent Testing Kiến trúc agent Planner/Gen/Healer MCP Hallucination/Ground Guardrail · HITL LLM-as-judge Khi nào TIN test do AI sinh?
Bản đồ chủ đề phỏng vấn: sáu cụm quanh 'AI Agent Testing', hội tụ về câu hỏi lõi 'khi nào tin test do AI sinh'.
Mẹo định hướng: mỗi câu trả lời tốt đều nên chạm tới một oracle (tiêu chí đúng-sai) và một ranh giới (điều AI không được tự quyết). Người phỏng vấn tìm tư duy đó, không tìm buzzword.
bash
# Bộ ba Playwright Agents (v1.56+) — hay bị hỏi ngay đầu buổi
npx playwright init-agents          # scaffold planner + generator + healer + seed.spec.ts
#  planner   → khám phá app, viết KẾ HOẠCH test dạng Markdown
#  generator → biến kế hoạch thành spec chạy được, TỰ kiểm locator trên app thật
#  healer    → chạy trong debug, đọc console/network/snapshot, sửa test hỏng hoặc mark skip
# Ranh giới cần nhớ: healer đề xuất, người review; KHÔNG merge thẳng bản 'tự chữa'.
  • Kiến trúc agent: planner–executor–critic, bounded action, termination.
  • Planner/Generator/Healer: bộ ba của Playwright Agents.
  • MCP: mô hình điều khiển trình duyệt qua accessibility tree.
  • Ảo giác & grounding: oracle chống báo cáo thành công giả.
  • Guardrails & HITL: fail-closed, người duyệt ca rủi ro.
  • LLM-as-judge: chấm không tất định mà không tự lừa mình.

2. Cấp độ Junior: định nghĩa nền tảng phải nói trôi chảy

Ở cấp Junior, người phỏng vấn muốn thấy bạn hiểu khái niệm nền và biết dùng công cụ ở mức cơ bản. Bạn cần nói rõ AI test agent là gì, khác gì script thường, và tại sao không thay được test hồi quy ổn định. Câu trả lời tốt tránh cường điệu: AI giúp khám phá và sinh nháp, còn test cố định vẫn nhanh, rẻ và đáng tin hơn cho việc bảo vệ. Đừng nói 'AI test mọi thứ tự động'; hãy nói 'AI đề xuất, con người và cổng eval quyết định'. Sự khiêm tốn có căn cứ này phân biệt ứng viên hiểu bản chất với ứng viên chỉ lặp lại quảng cáo.

AI test agent là gì? Nó khác script tự động thế nào?

AI test agent là chương trình dùng LLM để tự lập kế hoạch, gọi công cụ và tự đánh giá nhằm đạt một mục tiêu kiểm thử. Khác script tuyến tính chạy cố định từng bước, agent quyết định bước tiếp theo dựa trên quan sát vừa thu được, nên hợp cho khám phá luồng chưa có kịch bản. Nhưng vì không tất định, nó không thay test hồi quy ổn định.

Locator trong Playwright nên chọn kiểu nào và vì sao?

Ưu tiên locator theo vai trò và nhãn (getByRole, getByLabel) vì chúng bám vào ngữ nghĩa người dùng thấy, ổn định hơn CSS/XPath bám cấu trúc DOM. Locator ngữ nghĩa ít vỡ khi lập trình viên đổi class hay bố cục, và cũng là cách các AI agent 'nhìn' trang qua accessibility tree. Tránh selector giòn theo chỉ mục hay chuỗi class dài.

💡 Junior hay bị hỏi 'tại sao test này flaky'. Câu trả lời vàng: thiếu tự động chờ đúng điều kiện, phụ thuộc thứ tự/thời gian, hoặc dữ liệu dùng chung. Nêu được ba nguyên nhân này cho thấy bạn hiểu gốc rễ, không chỉ 'thêm sleep'.

3. Cấp độ Junior: câu hỏi công cụ & thực hành cơ bản

Vẫn ở cấp Junior nhưng nghiêng về thực hành: cách viết một assertion đúng, phân biệt kiểm chứng trạng thái với kiểm chứng giao diện, và biết công cụ hiện đại đã tự sinh assertion ra sao. Người phỏng vấn thường đưa một đoạn test và hỏi 'chỗ nào sai'. Điểm mấu chốt là bạn nhận ra assertion yếu (chỉ kiểm 'hiển thị' mà không kiểm giá trị nghiệp vụ) và biết đề xuất kiểm chứng bất biến. Đây cũng là lúc nói về Playwright codegen tự sinh toBeVisible và tại sao vẫn phải bổ sung assertion nghiệp vụ thủ công.

typescript
// Người phỏng vấn hỏi: "test này yếu ở đâu?"  (đáp án: assertion không kiểm bất biến)
// ❌ Yếu — chỉ kiểm nút hiển thị, không kiểm kết quả nghiệp vụ
await page.getByRole("button", { name: "Thanh toán" }).click();
await expect(page.getByText("Thành công")).toBeVisible();

// ✅ Mạnh — kiểm BẤT BIẾN: số dư trừ đúng, tồn kho giảm đúng, không âm
const before = await api.getBalance(userId);
await page.getByRole("button", { name: "Thanh toán" }).click();
await expect(page.getByRole("status")).toHaveText(/Đã thanh toán/);
const after = await api.getBalance(userId);
expect(before - after).toBe(orderTotal);      // tiền bảo toàn
expect(await api.getStock(sku)).toBeGreaterThanOrEqual(0); // tồn kho không âm

Playwright codegen tự sinh assertion, vậy còn cần viết tay không?

Vẫn cần. Codegen (từ v1.57) sinh được assertion hiển thị như toBeVisible, rất tiện để dựng khung. Nhưng nó không biết bất biến nghiệp vụ của bạn: tiền bảo toàn, tồn kho không âm, idempotency. Những assertion đó phải do người hiểu domain thêm vào. Codegen giúp nhanh phần vỏ, con người chịu trách nhiệm phần lõi oracle.

🔒

Nội dung bị khoá

Bạn đang xem bản xem trước. Đăng nhập để mở khoá toàn bộ bài viết và tất cả tài liệu Tester/QA.

Đã xem 24% nội dung
  • Đọc trọn vẹn mọi bài viết
  • Lưu bài & ghi chú cá nhân
  • Theo dõi tiến độ đã đọc
  • Luyện phỏng vấn, ISTQB, Mock
Đăng nhập để đọc tiếp

Chưa có mã? Lấy mã qua Fanpage / Zalo CyberSoft.

0

💬 Bình luận (0)

Bạn có thể đọc mọi bình luận. Đăng nhập để bình luận

Chưa có bình luận nào. Hãy là người đầu tiên!