# Dùng AI Viết Test Case: Prompt Mẫu Cho Tester

> Cho AI viết test case đang là cách nhiều tester tiết kiệm hàng giờ mỗi tuần. 🤖 Nhưng dùng sao cho nhanh mà vẫn chất lượng, không bị AI "bịa" ra những bước không có thật? Bài này tôi chia sẻ quy trình thực tế, 5 prompt mẫu bạn copy dùng ngay, và những rủi ro cần kiểm soát — dựa trên cách tiếp cận chuẩn của chứng chỉ chuyên đề Testing with Generative AI (CT-GenAI) thuộc ISTQB.

- **URL canonical**: https://itlearn.edu.vn/blog/dung-ai-viet-test-case-prompt
- **Published**: 2026-06-19T17:45:00+07:00
- **Modified**: 2026-06-20T00:29:54+07:00
- **Author**: Anh Tuấn
- **Category**: AI for Tester (https://itlearn.edu.vn/blog/cat/ai-for-tester)
- **Reading time**: 15 phút
- **Source site**: IT LEARN — Học viện Software Testing tiếng Việt

---

## AI viết test case được tới đâu?

Trả lời thẳng: **AI viết test case rất tốt ở phần "nháp đầu tiên"** — từ một user story, nó sinh nhanh hàng loạt test case phủ nhiều tình huống, gợi ý cả những case bạn dễ bỏ sót. Nhưng AI **không thay thế tester**: nó có thể hiểu sai nghiệp vụ, bịa kết quả mong đợi, hoặc bỏ qua ràng buộc đặc thù. Vai trò kiểm chứng cuối vẫn là của con người.

Hiểu đúng kỳ vọng sẽ giúp bạn dùng AI hiệu quả: coi nó như một *trợ lý viết nháp cực nhanh*, còn bạn là *người biên tập có chuyên môn*. Nắm vững [cách viết test case](/blog/cach-viet-test-case) thủ công trước, rồi mới giao việc cho AI — vì bạn phải đủ giỏi để biết khi nào nó sai.

## Quy trình dùng AI sinh test case

Một quy trình gọn gàng, lặp lại được:

- **Chuẩn bị input rõ ràng.** Gom user story, acceptance criteria, mô tả màn hình/ràng buộc nghiệp vụ — AI chỉ tốt khi đầu vào đủ.

- **Viết prompt có cấu trúc.** Theo CT-GenAI, một [prompt tốt cho test gồm 6 thành phần](/blog/huong-dan-prompt-engineering-cho-tester-phan-1-lam-chu-framework-rciico-chuan-istqb-ct-genai): vai trò (role), bối cảnh (context), chỉ thị (instruction), dữ liệu đầu vào (input), ràng buộc (constraints) và định dạng đầu ra (output format).

- **Sinh bản nháp.** Yêu cầu AI xuất test case theo đúng định dạng cột bạn dùng (ID, Description, Pre-condition, Step, Expected output…).

- **Kiểm chứng & chỉnh sửa (human-in-the-loop).** Soát từng case: đúng nghiệp vụ chưa, expected output kiểm chứng được chưa, có bịa không.

- **Nhập vào template & bổ sung.** Dán vào template chuẩn, tự thêm các case AI còn thiếu.

Ví dụ một prompt có cấu trúc đầy đủ:

`Vai trò: Bạn là một tester có kinh nghiệm.
Bối cảnh: Màn hình đăng nhập của hệ thống đặt phòng họp nội bộ.
Chỉ thị: Sinh test case kiểm thử chức năng đăng nhập.
Dữ liệu đầu vào: [dán user story + acceptance criteria vào đây]
Ràng buộc: Phủ cả case hợp lệ, không hợp lệ và biên; viết tiếng Việt.
Định dạng đầu ra: Bảng gồm các cột ID | Description | Pre-condition | Step | Expected output.`

## 5 prompt mẫu cho tester

Năm prompt dưới đây áp dụng đầy đủ khung 6 thành phần của CT-GenAI (vai trò, bối cảnh, chỉ thị, dữ liệu đầu vào, ràng buộc, định dạng đầu ra) cùng các kỹ thuật thiết kế test ISTQB. Bạn chỉ cần thay phần trong ngoặc vuông bằng dữ liệu thật, và xuất kết quả theo đúng cột template ở [cách viết test case](/blog/cach-viet-test-case).

**Prompt 1 — Sinh bộ test case đầy đủ từ user story (structured + risk-based)**

 

`# Vai trò`
`Bạn là Senior Test Engineer 10 năm kinh nghiệm, thành thạo kỹ thuật thiết kế test ISTQB (phân vùng tương đương, giá trị biên, bảng quyết định, đoán lỗi).`

`# Bối cảnh`
`Chức năng cần test: [TÊN CHỨC NĂNG]`
`Loại ứng dụng: [web/mobile/API] — [mô tả ngắn hệ thống]`
`Đối tượng người dùng: [vai trò]`

`# Chỉ thị`
`Phân tích yêu cầu bên dưới và sinh bộ test case có hệ thống:`
`1. Liệt kê ngắn gọn các điều kiện test (test conditions) bạn xác định được.`
`2. Sinh test case chi tiết, phủ đủ 3 nhóm: hợp lệ, không hợp lệ, biên.`
`3. Áp dụng phân vùng tương đương + giá trị biên cho mọi trường có ràng buộc.`
`4. Gán mức ưu tiên (Cao/Trung bình/Thấp) theo rủi ro.`

`# Dữ liệu đầu vào`
`User story / Acceptance Criteria:`
`"""`
`[DÁN USER STORY + ACCEPTANCE CRITERIA]`
`"""`
`Quy tắc validate / ràng buộc nghiệp vụ (nếu có):`
`"""`
`[VÍ DỤ: email đúng định dạng; mật khẩu 8–20 ký tự, có hoa/số/ký tự đặc biệt]`
`"""`

`# Ràng buộc`
`- Mỗi Step chỉ MỘT hành động, đánh số 1, 2, 3...`
`- Expected output phải CỤ THỂ, kiểm chứng được (nêu rõ thông báo/điều hướng/trạng thái); cấm viết chung chung kiểu "chạy đúng".`
`- KHÔNG bịa ràng buộc không có trong input; nếu thiếu, ghi "GIẢ ĐỊNH:" và nêu rõ.`
`- Viết hoàn toàn bằng tiếng Việt. ID dạng TC_[MÃ CHỨC NĂNG]_001.`

`# Định dạng đầu ra`
`Bảng Markdown đúng cột: | ID | Test Case Description | Pre-condition | Step | Expected output | Priority |`
`Sau bảng, liệt kê riêng "Các giả định" và "Câu hỏi cần làm rõ với BA".`

 

**Prompt 2 — Rà soát Acceptance Criteria trước khi viết (bước 1 của chuỗi)**

`# Vai trò`
`Bạn là Test Analyst kỹ tính, chuyên soi yêu cầu trước khi thiết kế test.`

`# Chỉ thị`
`Đọc kỹ Acceptance Criteria dưới đây. KHÔNG viết test case vội. Hãy:`
`1. Chỉ ra điểm MƠ HỒ (chưa rõ hành vi mong đợi).`
`2. Chỉ ra điểm THIẾU (case lỗi, biên, ngoại lệ, phân quyền, bảo mật, hiệu năng chưa được mô tả).`
`3. Chỉ ra điểm MÂU THUẪN giữa các tiêu chí.`
`4. Đặt câu hỏi cụ thể cần hỏi BA/PO.`
`5. Đề xuất phiên bản AC đã làm rõ, sẵn sàng để viết test.`

`# Dữ liệu đầu vào`
`"""`
`[DÁN ACCEPTANCE CRITERIA]`
`"""`

`# Định dạng đầu ra`
`Năm mục: "Điểm mơ hồ" · "Điểm thiếu" · "Điểm mâu thuẫn" · "Câu hỏi cho BA" · "AC đề xuất (đã làm rõ)".`

**Prompt 3 — Sinh test case dạng Gherkin/BDD (kỹ thuật few-shot)**

`# Vai trò`
`Bạn là tester viết kịch bản BDD chuẩn Gherkin.`

`# Chỉ thị`
`Sinh scenario Gherkin (Given/When/Then) cho [TÊN CHỨC NĂNG], phủ case hợp lệ, không hợp lệ, biên. Dùng Scenario Outline + Examples cho các case tương tự.`

`# Ví dụ mẫu (hãy theo đúng phong cách này)`
`Feature: Đăng nhập`
`  Scenario: Đăng nhập thành công với tài khoản hợp lệ`
`    Given người dùng đang ở màn hình đăng nhập`
`    And đã có tài khoản hợp lệ "user@itlearn.edu.vn" / "Test@1234"`
`    When nhập đúng email và mật khẩu rồi bấm "Đăng nhập"`
`    Then hệ thống chuyển đến Dashboard`
`    And không hiển thị thông báo lỗi`

`  Scenario Outline: Đăng nhập thất bại`
`    Given người dùng đang ở màn hình đăng nhập`
`    When nhập "<email>" và "<mật khẩu>" rồi bấm "Đăng nhập"`
`    Then hệ thống hiển thị lỗi "<thông báo>"`
`    Examples:`
`      | email               | mật khẩu  | thông báo                     |`
`      | user@itlearn.edu.vn | sai0000   | Email hoặc mật khẩu không đúng |`
`      | (để trống)          | Test@1234 | Vui lòng nhập email           |`

`# Dữ liệu đầu vào`
`"""`
`[DÁN USER STORY / MÔ TẢ CHỨC NĂNG]`
`"""`

`# Ràng buộc`
`- Tiếng Việt; mỗi scenario một mục tiêu rõ ràng; Then phải đo lường được.`

`# Định dạng đầu ra`
`Một khối Gherkin hoàn chỉnh trong code block.`

**Prompt 4 — Thiết kế dữ liệu biên & bảng quyết định**

`# Vai trò`
`Bạn là chuyên gia thiết kế test dữ liệu (phân vùng tương đương, giá trị biên, bảng quyết định).`

`# Chỉ thị`
`Với (các) trường dưới đây:`
`1. Liệt kê các lớp tương đương (hợp lệ + không hợp lệ).`
`2. Xác định giá trị biên cần test (min-1, min, min+1, max-1, max, max+1).`
`3. Nếu có nhiều điều kiện kết hợp, lập bảng quyết định cho các tổ hợp quan trọng.`
`4. Đề xuất bộ dữ liệu test tối thiểu nhưng phủ tốt.`

`# Dữ liệu đầu vào`
`Trường & ràng buộc:`
`"""`
`[VÍ DỤ: Mật khẩu — bắt buộc, 8–20 ký tự, ≥1 hoa, ≥1 số, ≥1 ký tự đặc biệt]`
`"""`

`# Định dạng đầu ra`
`- Bảng "Lớp tương đương" (Loại | Mô tả | Ví dụ giá trị)`
`- Bảng "Giá trị biên" (Giá trị | Kỳ vọng hợp lệ?)`
`- Bảng quyết định (nếu áp dụng). Tất cả bằng tiếng Việt.`

**Prompt 5 — Review & gap analysis bộ test case (self-critique)**

`# Vai trò`
`Bạn là Test Lead review chất lượng test case, tư duy phản biện cao.`

`# Chỉ thị`
`Đánh giá nghiêm khắc bộ test case dưới đây:`
`1. Chỉ ra trường hợp CÒN THIẾU (negative, biên, phân quyền, bảo mật như chống user enumeration, đồng thời/định thời, accessibility...).`
`2. Phát hiện test case TRÙNG LẶP hoặc Expected output MƠ HỒ / không kiểm chứng được.`
`3. Cảnh báo bất kỳ kết quả mong đợi nào có dấu hiệu SUY ĐOÁN (để tôi xác minh).`
`4. Đề xuất danh sách bổ sung kèm mức ưu tiên.`

`# Dữ liệu đầu vào`
`"""`
`[DÁN BỘ TEST CASE HIỆN CÓ]`
`"""`

`# Ràng buộc`
`- KHÔNG khẳng định hành vi hệ thống nếu không có trong dữ liệu; đánh dấu "CẦN XÁC MINH".`
`- Tiếng Việt.`

`# Định dạng đầu ra`
`Bốn mục: "Trường hợp còn thiếu" · "Trùng lặp/mơ hồ" · "Điểm cần xác minh" · "Đề xuất bổ sung (kèm Priority)".`

 

**Mẹo dùng nâng cao:** chạy nối chuỗi (prompt chaining) theo thứ tự **2 → 1 → 4 → 3 → 5**, lấy output sạch của bước trước làm input bước sau. Và luôn nhớ: đừng dán dữ liệu production/nhạy cảm vào tool công cộng; mọi test case AI sinh ra đều phải tester xác minh (human-in-the-loop).

## Ưu/nhược & rủi ro khi để AI viết test case

Ưu điểm

Rủi ro cần kiểm soát

Sinh nháp rất nhanh, tiết kiệm thời gian

**Hallucination** — bịa bước hoặc kết quả mong đợi không có thật

Gợi ý case dễ bỏ sót (biên, ngoại lệ)

Không hiểu nghiệp vụ đặc thù → expected output sai

Chuẩn hoá định dạng, viết Gherkin nhanh

**Rò rỉ dữ liệu** nếu dán nhầm thông tin nhạy cảm vào tool công cộng

Cho người mới một điểm bắt đầu để học

Lạm dụng làm giảm tư duy test của chính mình

Rủi ro lớn nhất là hallucination: AI viết câu nghe rất "chuẩn" nhưng sai thực tế. Vì vậy đừng bao giờ copy thẳng kết quả AI vào bộ test case chính thức mà chưa đọc lại.

## Human-in-the-loop: vai trò của tester

CT-GenAI nhấn mạnh nguyên tắc **human verification** ở mỗi bước: AI sinh, con người kiểm chứng. Đây chính là mô hình [human in the loop](/blog/human-in-the-loop-hitl-trong-phat-trien-phan-mem-vai-tro-khong-the-thay-the-cua-qa-qc-tai-viet-nam) — và là lý do nghề tester không bị AI thay thế, mà *được nâng cấp*.

Cụ thể, sau khi AI sinh test case, tester cần: đối chiếu với yêu cầu thật, sửa expected output cho đúng nghiệp vụ, loại bỏ case trùng/bịa, và bổ sung những tình huống AI chưa nghĩ tới. Nói cách khác, AI lo phần *số lượng và tốc độ*, còn tester giữ phần *đúng và đủ*. Kỹ năng giá trị nhất bây giờ không phải gõ tay nhanh, mà là **phán đoán được khi nào AI sai**.

## Câu hỏi thường gặp

### AI có thay thế tester viết test case không?

Không. AI giúp sinh nháp nhanh và gợi ý case bỏ sót, nhưng không hiểu trọn vẹn nghiệp vụ và có thể bịa kết quả. Tester vẫn là người kiểm chứng, sửa và chịu trách nhiệm cuối. Vai trò dịch chuyển từ "viết tay" sang "biên tập và đánh giá" — đòi hỏi chuyên môn cao hơn, không phải biến mất. Xem sâu hơn: [AI có thay thế tester không](/blog/ai-co-thay-the-tester-khong).

### Prompt nào tốt để sinh test case?

Prompt tốt có cấu trúc rõ: nêu vai trò, bối cảnh, chỉ thị, dán đủ dữ liệu đầu vào (user story, acceptance criteria), nêu ràng buộc (phủ case hợp lệ/không hợp lệ/biên) và định dạng đầu ra mong muốn. Xem 5 prompt mẫu phía trên để áp dụng ngay cho công việc của bạn.

### AI viết test case có chính xác không?

Bản nháp thường khá tốt nhưng không đảm bảo chính xác: AI có thể hiểu sai nghiệp vụ, bỏ ràng buộc hoặc bịa bước. Độ chính xác phụ thuộc nhiều vào chất lượng input và prompt. Vì vậy mọi test case do AI tạo đều phải được tester review trước khi đưa vào sử dụng.

### Dùng ChatGPT hay Claude cho testing?

Cả hai đều là LLM mạnh và đều dùng tốt cho việc sinh test case. Lựa chọn nên dựa trên quy trình của đội, chính sách bảo mật dữ liệu và khả năng tích hợp công cụ, hơn là thương hiệu. Quan trọng nhất vẫn là kỹ năng viết prompt và kiểm chứng kết quả của chính bạn.

### Cần kiểm tra lại test case do AI tạo không?

Bắt buộc. Đây là nguyên tắc human-in-the-loop: AI sinh, con người kiểm chứng. Hãy soát từng case xem có đúng nghiệp vụ, expected output có kiểm chứng được, có bịa hay trùng lặp không, rồi bổ sung trường hợp còn thiếu. Bỏ qua bước này là rủi ro lớn nhất khi dùng AI. Muốn học bài bản cách dùng AI trong kiểm thử — từ prompt tới kiểm soát rủi ro — bạn có thể tham khảo [khóa AI cho Tester](/ai-tester.html) của IT LEARN.