Để prompt thực sự hiệu quả, tester còn cần làm chủ các kỹ thuật prompting — và kỹ thuật cơ bản nhất, được dùng nhiều nhất chính là phân loại theo số lượng ví dụ cung cấp cho LLM: zero-shot, one-shot, few-shot.

Bài viết này sẽ giải thích chi tiết ba kỹ thuật này, kèm ví dụ thực tế cho công việc kiểm thử, hướng dẫn khi nào dùng kỹ thuật nào, và cách kết hợp chúng với framework RCIICO bạn đã học ở Phần 1.

Phần 1: Hiểu khái niệm "shot" trong Prompt Engineering

Thuật ngữ "shot" trong prompt engineering chỉ số lượng ví dụ mẫu mà bạn cung cấp cho LLM trong prompt để mô hình "học theo" pattern mong muốn. Đây là một dạng in-context learning — LLM không thật sự được huấn luyện lại, mà chỉ "hiểu nhanh" pattern từ các ví dụ trong prompt rồi áp dụng cho dữ liệu mới [1][2].

ISTQB CT-GenAI Section 2.1.2 phân loại ba mức [1]:

Kỹ thuật Số ví dụ Đặc điểm
Zero-shot 0 Chỉ có instruction, không có ví dụ
One-shot 1 Một ví dụ mẫu duy nhất
Few-shot 2-5 (đôi khi hơn) Nhiều ví dụ để LLM hiểu sâu pattern

Mỗi kỹ thuật có ưu điểm và bối cảnh sử dụng riêng — không có kỹ thuật nào "tốt hơn" tuyệt đối.

Phần 2: Zero-shot Prompting

2.1. Định nghĩa và đặc điểm

Zero-shot prompting là cách viết prompt không kèm bất kỳ ví dụ nào — bạn chỉ mô tả tác vụ và LLM tự "suy luận" cách thực hiện dựa trên kiến thức đã được huấn luyện [1].

Đây là kỹ thuật phổ biến nhất vì đơn giản và nhanh — gần như mọi câu hỏi bạn gõ vào ChatGPT/Claude lần đầu đều là zero-shot.

2.2. Ví dụ thực tế

Ví dụ zero-shot kết hợp RCIICO:

 
[Role] Bạn là senior tester có 8 năm kinh nghiệm kiểm thử ứng dụng e-commerce.

[Context] Tôi đang chuẩn bị test plan cho tính năng giỏ hàng của một trang TMĐT.

[Instruction] Hãy liệt kê 10 test condition quan trọng nhất cho chức năng 
"Thêm sản phẩm vào giỏ hàng", áp dụng kỹ thuật equivalence partitioning 
và boundary value analysis.

[Constraints] Mỗi condition gồm: tên ngắn gọn + lý do ưu tiên.

[Output format] Danh sách Markdown.

LLM sẽ tự sinh test condition mà không cần ví dụ mẫu nào.

2.3. Khi nào dùng zero-shot?

Phù hợp khi:

  • Tác vụ phổ biến, LLM đã được huấn luyện nhiều — sinh test case cơ bản, viết test report đơn giản, tra kiến thức kiểm thử.
  • Bạn cần kết quả nhanh, không có sẵn ví dụ mẫu.
  • Output không yêu cầu format quá đặc thù.
  • Đang ở giai đoạn brainstorm hoặc khám phá ý tưởng.

Không phù hợp khi:

  • Bạn cần output theo template/format đặc thù của team.
  • Tác vụ thuộc domain hẹp mà LLM ít được huấn luyện (ví dụ: ngôn ngữ tài liệu nội bộ, quy ước riêng).
  • Cần độ nhất quán cao qua nhiều lần chạy.

2.4. Anti-pattern thường gặp

Đừng nhầm "zero-shot" với "prompt cẩu thả".

Zero-shot không có nghĩa là viết mơ hồ. Một prompt zero-shot tốt vẫn cần đầy đủ thành phần RCIICO — chỉ thiếu phần ví dụ. Nhiều tester nghĩ "không có ví dụ thì viết gì cũng được" và viết prompt kiểu "viết test case cho login" — đây là prompt yếu, không phải zero-shot prompting đúng nghĩa.

Phần 3: One-shot Prompting

3.1. Định nghĩa và đặc điểm

One-shot prompting là cách thêm đúng một ví dụ mẫu vào prompt để LLM hiểu chính xác bạn muốn output trông như thế nào [1].

Một ví dụ duy nhất thường đủ để truyền đạt format đầu ra và mức độ chi tiết mong muốn, mà không cần đầu tư công sức như few-shot.

3.2. Ví dụ thực tế

Ví dụ one-shot — sinh test case theo template công ty:

 
[Role] Bạn là tester ngành tài chính.

[Context] Team tôi dùng template test case riêng. Tôi cần sinh test case 
cho chức năng chuyển khoản nội bộ giữa các tài khoản.

[Example - đây là format chuẩn của team:]
TC-PAY-001
- Tiêu đề: Chuyển khoản thành công với số tiền hợp lệ
- Pre-condition: User đã đăng nhập, có ít nhất 2 tài khoản, số dư > 0
- Steps:
  1. Chọn "Chuyển khoản nội bộ"
  2. Chọn tài khoản nguồn và đích
  3. Nhập số tiền 100.000 VND
  4. Xác nhận giao dịch
- Expected: Giao dịch thành công, số dư cập nhật chính xác ở cả 2 tài khoản
- Priority: High
- Tag: Functional

[Instruction] Dựa theo format trên, sinh thêm 8 test case cho cùng chức năng, 
bao gồm các kịch bản: số tiền vượt số dư, tài khoản đích bị khoá, 
giới hạn giao dịch hằng ngày, ký tự đặc biệt trong ghi chú.

[Output format] Cùng format với ví dụ.

Chỉ với một ví dụ, LLM hiểu chính xác mã định danh test case (TC-PAY-001), cấu trúc gạch đầu dòng, độ chi tiết của steps, ngôn ngữ của expected result.

3.3. Khi nào dùng one-shot?

Phù hợp khi:

  • Bạn có template chuẩn và muốn output đồng bộ format.
  • Tác vụ không quá phức tạp — một ví dụ đủ truyền đạt pattern.
  • Bạn muốn cân bằng giữa "ngắn gọn" và "có hướng dẫn".

Không phù hợp khi:

  • Pattern phức tạp, có nhiều biến thể (lúc này cần few-shot).
  • Tác vụ rất đơn giản, không cần ví dụ (zero-shot đủ rồi).

Phần 4: Few-shot Prompting

4.1. Định nghĩa và đặc điểm

Few-shot prompting là kỹ thuật cung cấp 2-5 ví dụ (đôi khi nhiều hơn) trong prompt để LLM hiểu sâu pattern và biến thể mong muốn [1][3].

Đây là kỹ thuật mạnh nhất trong ba kỹ thuật, đặc biệt hiệu quả khi tác vụ có độ phức tạp cao hoặc nhiều biến thể.

4.2. Ví dụ thực tế

Ví dụ few-shot — sinh test data đa dạng cho login:

 
[Role] Bạn là tester chuyên về test data design.

[Context] Tôi cần sinh test data đa dạng cho chức năng đăng nhập 
của ứng dụng banking, để chạy automation regression.

[Examples - đây là pattern test data team tôi dùng:]

Ví dụ 1 — Happy path:
{ "scenario": "Login thành công với tài khoản chuẩn",
  "username": "user_normal_01",
  "password": "Pass@123",
  "expected_result": "success",
  "tag": "happy_path" }

Ví dụ 2 — Negative case:
{ "scenario": "Login thất bại do tài khoản bị khoá",
  "username": "user_locked",
  "password": "Pass@123",
  "expected_result": "blocked",
  "tag": "account_state" }

Ví dụ 3 — Boundary case:
{ "scenario": "Username dài đúng giới hạn 50 ký tự",
  "username": "user_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx_50",
  "password": "Pass@123",
  "expected_result": "success",
  "tag": "boundary" }

[Instruction] Dựa theo 3 pattern trên, sinh thêm 12 test data đa dạng, 
phủ các nhóm: account_state (3 cases), boundary (3 cases), 
security (3 cases — SQL injection, XSS, brute force), edge_case (3 cases).

[Output format] JSON array đúng format ví dụ.

LLM "hiểu" sâu hơn rất nhiều so với one-shot: cấu trúc field, naming convention, cách gán tag, mức độ chi tiết của scenario description.

4.3. Cách viết ví dụ (examples) tốt cho few-shot

Đây là phần nhiều tester làm chưa tốt. Ba nguyên tắc quan trọng:

Đa dạng hoá ví dụ. Đừng đưa 3 ví dụ về cùng một loại (vd: cả 3 đều là happy path). Hãy chọn 3 ví dụ đại diện cho 3 nhóm khác nhau (happy, negative, boundary) — LLM sẽ hiểu được "phổ" của tác vụ.

Chất lượng > Số lượng. Hai ví dụ chuẩn còn tốt hơn năm ví dụ lộn xộn. Mỗi ví dụ nên là "kim chỉ nam" cho LLM, không phải "lấp chỗ trống".

Thứ tự có ý nghĩa. LLM thường bị ảnh hưởng nhiều hơn bởi ví dụ cuối cùng trong danh sách. Hãy đặt ví dụ "tiêu biểu nhất" ở cuối nếu muốn LLM bám theo style đó.

4.4. Khi nào dùng few-shot?

Phù hợp khi:

  • Output cần độ nhất quán cao (ví dụ: sinh hàng trăm test case theo cùng template).
  • Pattern phức tạp với nhiều biến thể (test data, bug report, test scenario phức tạp).
  • Tác vụ thuộc domain đặc thù mà LLM ít có "default behavior".
  • Bạn sẽ chạy prompt nhiều lần — đầu tư xây ví dụ một lần, dùng lại nhiều lần.

Không phù hợp khi:

  • Tác vụ rất đơn giản (over-engineering).
  • Bạn không có ví dụ chất lượng để cung cấp.
  • Context window của LLM hạn chế (hiếm gặp với LLM hiện đại nhưng vẫn cần lưu ý).

4.5. Lưu ý quan trọng — Bảo mật

ISTQB CT-GenAI Section 3.2 nhấn mạnh: không bao giờ dùng dữ liệu thật, code production, hay thông tin khách hàng làm ví dụ trong few-shot prompting [1]. Hãy "anonymize" hoặc tạo dữ liệu mô phỏng. Đây là rủi ro thường bị xem nhẹ — và là một trong những lỗ hổng data privacy phổ biến nhất khi tester dùng LLM công cộng.

Phần 5: So sánh nhanh — Chọn kỹ thuật nào?

Tình huống Kỹ thuật phù hợp
Tra kiến thức nhanh, brainstorm ý tưởng Zero-shot
Sinh output theo template công ty (đơn giản) One-shot
Sinh output đồng bộ qua nhiều lần chạy, format đặc thù Few-shot
Tác vụ trong domain hẹp, LLM dễ "đoán sai" Few-shot
Câu hỏi mang tính khám phá, sáng tạo Zero-shot
Tác vụ lặp lại nhiều lần với cùng pattern Few-shot (đầu tư một lần, dùng nhiều)

Một quy tắc thực dụng: bắt đầu bằng zero-shot, nếu output chưa tốt thì nâng lên one-shot, nếu vẫn chưa tốt thì few-shot. Đừng over-engineer ngay từ đầu.

Phần 6: Kết hợp với framework RCIICO

Một thắc mắc thường gặp: "Few-shot examples nên đặt ở đâu trong RCIICO?"

Câu trả lời: examples là phần bổ sung cho RCIICO, thường chèn vào sau phần Instruction hoặc trước phần Output format. Cấu trúc gợi ý:

 
[Role]
[Context]
[Instruction]
[Examples]  ← chèn examples vào đây
[Input data]
[Constraints]
[Output format]

Hoặc với prompt ngắn, bạn có thể tích hợp examples ngay trong phần Output format ("Output format theo các ví dụ sau:..."). Quan trọng là examples phải rõ ràng tách biệt với input data thật — dùng dấu phân cách như --- hoặc tiêu đề rõ ràng để LLM không nhầm lẫn.

Lời kết

Zero-shot, one-shot, few-shot là ba bậc thang quan trọng trong tay nghề prompt engineering của tester. Làm chủ chúng đồng nghĩa với việc bạn biết chọn đúng mức độ đầu tư cho từng tác vụ — không lười dùng zero-shot khi cần kết quả chất lượng cao, cũng không over-engineer few-shot cho những việc đơn giản.

Lời khuyên thực hành: tuần này, hãy chọn một tác vụ kiểm thử bạn làm thường xuyên nhất (ví dụ: sinh test case từ user story, viết bug report, sinh test data), thử lần lượt cả ba kỹ thuật zero/one/few-shot. So sánh chất lượng output, ghi nhận thời gian bạn đầu tư cho mỗi cách. Sau một tuần, bạn sẽ có "trực giác" rõ ràng về việc khi nào dùng kỹ thuật nào — và đây chính là kỹ năng quý giá khó học từ sách vở.

Trong Phần 3 của loạt bài, IT Learn sẽ hướng dẫn bạn các kỹ thuật prompting nâng cao hơn theo chuẩn ISTQB CT-GenAI: prompt chaining (chia nhỏ tác vụ phức tạp thành chuỗi prompt liên tiếp), meta prompting (dùng LLM để cải thiện chính prompt của bạn), và iterative refinement (vòng lặp đánh giá và tinh chỉnh prompt qua thực tế).

Theo dõi blog của IT Learn để không bỏ lỡ phần 3, hoặc liên hệ với chúng tôi qua hộp tin nhắn để được tư vấn lộ trình học tập phù hợp.

Tài liệu tham khảo

[1] ISTQB®. Certified Tester Specialist Level Syllabus – Testing with Generative AI (CT-GenAI) v1.0, July 2025. Tham chiếu cụ thể: Section 2.1.2 (Prompt Engineering Techniques — zero-shot, one-shot, few-shot prompting), Section 3.2 (Data Privacy and Security in GenAI Use). https://istqb.org/

[2] Brown, T. et al. "Language Models are Few-Shot Learners", arXiv preprint, 2020 — bài báo gốc giới thiệu khái niệm few-shot learning trong context của LLM (GPT-3 paper). https://arxiv.org/abs/2005.14165

[3] Anthropic. "Use Examples (Few-shot Prompting)", Claude Documentation — hướng dẫn chính thức của Anthropic về kỹ thuật few-shot. https://docs.claude.com/en/docs/build-with-claude/prompt-engineering/multishot-prompting

[4] OpenAI. "Best Practices for Prompt Engineering with the OpenAI API" — phần "Provide examples" tương ứng với one-shot/few-shot prompting. https://platform.openai.com/docs/guides/prompt-engineering