# Kỹ Thuật Thiết Kế Test Case (Phân Vùng, Giá Trị Biên) > Bạn đã biết cách trình bày một test case gọn gàng, nhưng làm sao để chọn được đúng những trường hợp cần kiểm thử — không bỏ sót mà cũng không viết thừa hàng trăm ca trùng nhau? 🙂 Đó chính là lúc bạn cần tới kỹ thuật thiết kế test case. Trong bài này tôi sẽ đi qua các kỹ thuật chuẩn ISTQB CTFL — phân vùng tương đương, giá trị biên, bảng quyết định, chuyển trạng thái và đoán lỗi — kèm ví dụ xuyên suốt trên "Hệ thống đặt phòng họp nội bộ" để bạn áp dụng được ngay. - **URL canonical**: https://itlearn.edu.vn/blog/ky-thuat-thiet-ke-test - **Published**: 2026-07-03T11:00:00+07:00 - **Modified**: 2026-07-03T13:26:56+07:00 - **Author**: Anh Tuấn - **Category**: ISTQB Certificate (https://itlearn.edu.vn/blog/cat/istqb) - **Reading time**: 15 phút - **Source site**: IT LEARN — Học viện Software Testing tiếng Việt ---   ## 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ì](/blog/istqb-la-gi); còn muốn ôn lại định nghĩa thuật ngữ, [thuật ngữ kiểm thử](/blog/thuat-ngu-kiem-thu/) 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](/blog/cach-viet-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ử](/blog/cac-loai-kiem-thu). ## 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. ## Câu hỏi thường gặp ### Có mấy kỹ thuật thiết kế test? Theo ISTQB CTFL v4.0, kỹ thuật thiết kế test chia làm ba nhóm: black-box (phân vùng tương đương, giá trị biên, bảng quyết định, chuyển trạng thái), white-box (phủ câu lệnh, phủ nhánh) và experience-based (đoán lỗi, kiểm thử thăm dò, dựa trên checklist). Người mới nên nắm chắc nhóm black-box trước vì nó chiếm nhiều câu hỏi nhất. ### Phân vùng tương đương là gì? Phân vùng tương đương (Equivalence Partitioning) là kỹ thuật chia miền dữ liệu đầu vào thành các nhóm mà hệ thống được kỳ vọng xử lý giống nhau, rồi chỉ test một giá trị đại diện cho mỗi nhóm. Nó có cả partition hợp lệ và không hợp lệ, giúp giảm mạnh số test case mà vẫn giữ độ phủ. ### Giá trị biên test thế nào? Bạn xác định ranh giới giữa các partition rồi test ngay tại đó, vì lỗi hay nằm ở rìa. Dạng 2-value test giá trị tại biên và giá trị liền kề; dạng 3-value test thêm giá trị trước, tại và sau biên. Ví dụ ô tuổi 18–60 cần thử 17, 18 và 60, 61 để bắt lỗi off-by-one. ### Khi nào dùng bảng quyết định? Dùng bảng quyết định khi đầu ra phụ thuộc tổ hợp của nhiều điều kiện nghiệp vụ, như phân quyền, tính phí hay logic duyệt/từ chối. Mỗi cột (rule) trong bảng là một tổ hợp điều kiện và trở thành một test case, giúp bạn không bỏ sót tổ hợp nào và biến quy tắc nghiệp vụ thành test có hệ thống. ### Black-box và white-box technique khác gì? Black-box thiết kế test case dựa trên đặc tả/yêu cầu mà không cần biết code bên trong — như EP, BVA, bảng quyết định. White-box thiết kế dựa trên cấu trúc code (phủ câu lệnh, phủ nhánh), cần đọc được mã nguồn. Đoán lỗi không thuộc cả hai mà nằm ở nhóm experience-based, dựa vào kinh nghiệm tester. Bạn muốn luyện các kỹ thuật thiết kế test case này trên dự án thật và ôn thi CTFL bài bản? Tham khảo khóa [chứng chỉ ISTQB CTFL](/ctfl.html) của IT LEARN nhé.