Kỹ thuật thiết kế test là gì & vì sao cần

Kỹ thuật thiết kế test case là các phương pháp có hệ thống giúp tester chọn ra tập test case tối ưu từ vô số trường hợp có thể xảy ra — đủ để phát hiện lỗi mà không kiểm thử trùng lặp. Theo ISTQB CTFL v4.0, chúng được chia làm ba nhóm: black-box (hộp đen), white-box (hộp trắng) và experience-based (dựa trên kinh nghiệm).

Vì sao cần? Vì kiểm thử vét cạn (thử mọi giá trị đầu vào) gần như bất khả thi: chỉ riêng một ô nhập tuổi đã có hàng tỷ tổ hợp. Kỹ thuật thiết kế giúp bạn nhóm các đầu vào "tương đương" lại, chọn đại diện, và tập trung vào những điểm dễ sinh lỗi nhất. Nhờ đó bạn có test coverage hợp lý với chi phí thấp — đúng tinh thần nguyên lý "kiểm thử vét cạn là bất khả thi" của ISTQB.

Bài này tập trung vào nhóm black-box (thiết kế dựa trên đặc tả, không cần nhìn code) cùng kỹ thuật đoán lỗi thuộc nhóm experience-based — đây là phần chiếm nhiều câu hỏi nhất trong chương 4 của syllabus. Nếu bạn chưa rõ tổng quan chứng chỉ, hãy xem trước ISTQB là gì; còn muốn ôn lại định nghĩa thuật ngữ, thuật ngữ kiểm thử là cuốn từ điển nhanh tiện tra cứu.

Phân vùng tương đương (equivalence partitioning) + ví dụ

Phân vùng tương đương (Equivalence Partitioning – EP) là kỹ thuật chia miền dữ liệu đầu vào thành các nhóm (partition) mà mọi giá trị trong cùng nhóm được kỳ vọng hệ thống xử lý giống nhau. Bạn chỉ cần lấy một giá trị đại diện cho mỗi nhóm để kiểm thử, thay vì thử hết.

Mỗi miền dữ liệu thường có partition hợp lệ (valid) và partition không hợp lệ (invalid). Quy tắc của EP rất gọn: mỗi partition test ít nhất một giá trị; một test case nên phủ nhiều partition hợp lệ cùng lúc, nhưng mỗi partition không hợp lệ nên được test riêng để tránh "che" lỗi lẫn nhau.

Lấy ví dụ ô "Tuổi người đặt phòng" trong Hệ thống đặt phòng họp nội bộ, quy định chỉ nhân viên 18–60 tuổi mới được đặt:

Partition Khoảng giá trị Loại Giá trị đại diện
Dưới độ tuổi < 18 Không hợp lệ 15
Trong độ tuổi 18 – 60 Hợp lệ 35
Trên độ tuổi > 60 Không hợp lệ 70
Không phải số "abc", để trống Không hợp lệ "abc"

Thay vì thử 43 giá trị từ 18 đến 60, bạn chỉ cần một giá trị đại diện (ví dụ 35) cho cả nhóm hợp lệ. EP giúp giảm số test case kịch tính mà vẫn giữ độ phủ — nhưng nó có một điểm mù: lỗi thường ẩn ở rìa các partition. Đó là lý do ta cần kỹ thuật tiếp theo.

Phân tích giá trị biên (boundary value) + ví dụ

Phân tích giá trị biên (Boundary Value Analysis – BVA) là kỹ thuật tập trung kiểm thử ngay tại ranh giới giữa các partition, vì đó là nơi lỗi lập trình hay xuất hiện nhất (sai dấu < thành <=, lệch một đơn vị). BVA luôn đi kèm EP: bạn phân vùng trước, rồi "soi" vào các biên.

ISTQB CTFL v4.0 nêu hai dạng BVA: - 2-value boundary (BVA cơ bản): với mỗi biên, test giá trị tại biên và giá trị liền kề ở partition bên cạnh. - 3-value boundary (BVA mở rộng): test giá trị trước biên, tại biên và sau biên — chặt hơn, phát hiện thêm lỗi tinh vi.

Quay lại ô tuổi 18–60. Với biên dưới (18) và biên trên (60), các giá trị cần kiểm thử như sau:

Biên Dạng 2-value Dạng 3-value Kết quả mong đợi
Biên dưới = 18 17, 18 17, 18, 19 17 → từ chối; 18 trở lên → chấp nhận
Biên trên = 60 60, 61 59, 60, 61 tới 60 → chấp nhận; 61 → từ chối

Một ví dụ khác: ô "Số lượng phòng đặt" cho phép từ 1 đến 10 phòng/lượt. Biên cần test là 0–1 (dưới) và 10–11 (trên). Chỉ vài giá trị biên này thôi đã bắt được phần lớn lỗi "off-by-one" mà EP đơn thuần bỏ qua. Khi viết các ca này thành bảng test case chuẩn, bạn có thể tham khảo lại cách viết test case để trình bày input/expected gọn gàng.

Bảng quyết định (decision table) + ví dụ

Bảng quyết định (Decision Table) là kỹ thuật black-box dùng khi đầu ra phụ thuộc vào tổ hợp của nhiều điều kiện — giúp liệt kê đầy đủ các quy tắc nghiệp vụ (business rule) mà không bỏ sót tổ hợp nào. Mỗi cột là một "rule": tập điều kiện đầu vào và hành động đầu ra tương ứng.

Giả sử Hệ thống đặt phòng họp áp dụng quy tắc: được duyệt tự động khi (1) nhân viên còn quyền đặt phòng và (2) phòng còn trống trong khung giờ chọn; nếu phòng đã kín nhưng còn quyền thì đưa vào hàng chờ; nếu hết quyền thì từ chối.

Điều kiện / Hành động R1 R2 R3 R4
Còn quyền đặt phòng? Có Có Không Không
Phòng còn trống? Có Không Có Không
→ Duyệt tự động X – – –
→ Đưa vào hàng chờ – X – –
→ Từ chối – – X X

Mỗi rule (R1–R4) chính là một test case. Bảng quyết định buộc bạn nghĩ đủ 2² = 4 tổ hợp, nên rất hợp với các màn hình có logic điều kiện chồng chéo: tính phí, phân quyền, áp dụng khuyến mãi. Khi số điều kiện lớn, bạn có thể thu gọn (collapse) những cột cho cùng kết quả bất kể một điều kiện nào đó — như R3 và R4 ở trên đều "Từ chối" khi hết quyền, không cần quan tâm phòng trống hay không.

Chuyển trạng thái (state transition)

Kiểm thử chuyển trạng thái (State Transition Testing) là kỹ thuật black-box dùng cho hệ thống có hành vi thay đổi theo trạng thái hiện tại và sự kiện tác động — kiểm tra các chuyển tiếp hợp lệ và chặn các chuyển tiếp không hợp lệ. Nó phù hợp với quy trình có vòng đời rõ ràng.

Một yêu cầu đặt phòng trong hệ thống của chúng ta có vòng đời: Nháp → Chờ duyệt → Đã duyệt → Đã hủy / Hoàn tất. Mô hình chuyển trạng thái gồm 4 thành phần: trạng thái (state), sự kiện (event), chuyển tiếp (transition) và hành động/đầu ra. Từ đó bạn thiết kế hai loại test:

  • Chuyển tiếp hợp lệ: ví dụ từ "Chờ duyệt" + sự kiện quản lý duyệt → "Đã duyệt". Mỗi mũi tên hợp lệ là một ca cần phủ.
  • Chuyển tiếp không hợp lệ: ví dụ cố "Hủy" một yêu cầu đã ở trạng thái "Hoàn tất" — hệ thống phải từ chối, không được đổi trạng thái.

Kỹ thuật này lộ ra những lỗi mà EP/BVA không thấy: cho phép thao tác sai thời điểm, hoặc quên xử lý một sự kiện ở trạng thái nào đó. Ở mức CTFL, bạn chỉ cần nắm khái niệm và biết vẽ state transition diagram cùng bảng trạng thái đơn giản là đủ.

Đoán lỗi (error guessing)

Đoán lỗi (Error Guessing) là kỹ thuật thuộc nhóm experience-based — tester dựa vào kinh nghiệm, trực giác và hiểu biết về những chỗ lập trình viên hay sai để chủ động thiết kế test case "săn" các lỗi đó. Đây là điểm cần đính chính: nhiều tài liệu xếp đoán lỗi vào black-box, nhưng theo ISTQB CTFL v4.0 nó là kỹ thuật dựa trên kinh nghiệm, không phải black-box.

Khác với EP hay BVA có công thức rõ ràng, đoán lỗi mang tính phi cấu trúc — nhưng không phải đoán mò. Người làm lâu năm thường lập một danh sách lỗi hay gặp (defect/fault attack list) để hệ thống hóa kinh nghiệm. Với form đặt phòng, vài "điểm nóng" tôi luôn thử:

  • Nhập ký tự đặc biệt, emoji, hoặc khoảng trắng đầu/cuối vào tên cuộc họp.
  • Đặt phòng với giờ kết thúc trước giờ bắt đầu.
  • Bấm "Đặt" hai lần liên tiếp thật nhanh (double-submit) xem có tạo trùng không.
  • Đổi múi giờ máy rồi đặt phòng vắt qua nửa đêm.

Đoán lỗi bổ trợ rất tốt cho các kỹ thuật có cấu trúc: dùng EP/BVA/bảng quyết định để phủ nền tảng, rồi thêm đoán lỗi để bắt những ca "lạ" mà đặc tả không nói tới. Nó cũng là nền của kiểm thử thăm dò (exploratory testing) mà bạn sẽ gặp khi tìm hiểu các loại kiểm thử.

Bảng tổng hợp khi nào dùng kỹ thuật nào

Để bạn dễ chọn nhanh ngoài thực địa, đây là bảng đối chiếu các kỹ thuật thiết kế test case theo tình huống dùng:

Kỹ thuật Nhóm Dùng khi Ví dụ điển hình
Phân vùng tương đương (EP) Black-box Đầu vào chia thành các miền xử lý giống nhau Ô tuổi, hạng thành viên, loại tài khoản
Phân tích giá trị biên (BVA) Black-box Có ngưỡng/khoảng số, ngày tháng, độ dài Tuổi 18–60, số phòng 1–10, độ dài mật khẩu
Bảng quyết định Black-box Đầu ra phụ thuộc tổ hợp nhiều điều kiện Phân quyền, tính phí, duyệt/từ chối
Chuyển trạng thái Black-box Đối tượng có vòng đời/trạng thái rõ ràng Đơn hàng, yêu cầu đặt phòng, tài khoản
Đoán lỗi Experience-based Bổ sung sau khi đã phủ kỹ thuật có cấu trúc Input lạ, double-submit, biên thời gian

Một lưu ý nghề: các kỹ thuật không loại trừ nhau — trong một dự án thật bạn thường kết hợp. Ví dụ một form đăng ký dùng EP + BVA cho từng ô nhập, bảng quyết định cho logic hợp lệ tổng thể, rồi đoán lỗi để quét nốt. Phân biệt rõ nhóm black-box (thiết kế từ đặc tả) với white-box (thiết kế từ cấu trúc code) cũng là một câu hỏi rất hay ra trong kỳ thi Foundation.