# Các Loại Kiểm Thử Phần Mềm Phổ Biến (Có Ví Dụ) > Mới học testing, bạn sẽ choáng vì có quá nhiều cái tên: functional, regression, smoke, black-box, UAT… 😅 Nhưng đừng lo — hầu hết các loại kiểm thử phần mềm đều quy về vài nhóm dễ nhớ. Bài này tôi vẽ cho bạn tấm bản đồ phân loại, kèm bảng so sánh và ví dụ thực tế để lần sau gặp thuật ngữ nào bạn cũng biết nó nằm ở đâu. - **URL canonical**: https://itlearn.edu.vn/blog/cac-loai-kiem-thu - **Published**: 2026-06-22T19:42:00+07:00 - **Modified**: 2026-08-06T06:03:49+07:00 - **Author**: Anh Tuấn - **Category**: Manual Testing (https://itlearn.edu.vn/blog/cat/manual-testing) - **Reading time**: 10 phút - **Source site**: IT LEARN — Học viện Software Testing tiếng Việt --- ## Phân loại kiểm thử theo nhóm **Các loại kiểm thử phần mềm thường được phân theo ba nhóm chính: theo cấp độ (unit, integration, system, acceptance/UAT), theo mục đích (functional và non-functional), và theo góc nhìn kỹ thuật (black-box và white-box).** Ngoài ra còn một nhóm liên quan đến thay đổi: smoke, sanity, retest (confirmation) và regression. Mấu chốt khiến người mới rối là: **một bài test có thể mang nhiều tên cùng lúc**, vì nó được gọi theo các trục phân loại khác nhau. Ví dụ "test đăng nhập trên toàn hệ thống bằng cách nhập liệu mà không cần biết code" đồng thời là *system test* (theo cấp độ), *functional* (theo mục đích) và *black-box* (theo góc nhìn). Khi bạn hình dung mỗi loại test như một điểm trên ba trục tọa độ này, mọi thuật ngữ đều có chỗ đứng rõ ràng (theo cách phân loại của chuẩn quốc tế ISTQB). Trong phần còn lại của bài, ta sẽ đi lần lượt từng nhóm — kèm bảng và ví dụ với "Hệ thống đặt phòng họp nội bộ" để bạn dễ liên hệ. ## Functional vs Non-functional testing Đây là cách phân loại theo **mục đích**: kiểm thử *cái gì* hay *tốt tới đâu*. Tiêu chí Functional Testing Non-functional Testing Trả lời câu hỏi Hệ thống làm ĐÚNG chức năng không Hệ thống chạy TỐT tới đâu Dựa trên Yêu cầu chức năng Đặc tính chất lượng (ISO/IEC 25010) Ví dụ Đăng nhập, đặt phòng, thanh toán đúng Hiệu năng, bảo mật, khả dụng, tương thích, độ tin cậy Người mới làm Phần lớn bắt đầu ở đây Thường cần công cụ/chuyên môn riêng Ví dụ với hệ thống đặt phòng họp: *functional* là kiểm tra đặt phòng có thành công không, có chống đặt trùng giờ không. Còn *non-functional* trả lời những câu hỏi "chất lượng" đi kèm, ví dụ: - **Hiệu năng (performance):** hệ thống chịu được 500 người đặt phòng cùng lúc không? - **Bảo mật (security):** có chặn được truy cập trái phép vào lịch phòng của người khác không? - **Khả dụng (usability):** người dùng mới có đặt phòng được mà không cần hướng dẫn không? - **Tương thích (compatibility):** chạy ổn trên Chrome, Safari, điện thoại không? Người mới thường bắt đầu từ functional vì gần với nghiệp vụ và không cần công cụ chuyên sâu; non-functional thường cần kỹ năng và công cụ riêng (ví dụ JMeter cho performance). ## Regression, Smoke, Sanity, Retest Nhóm này phân loại theo **mối liên hệ với thay đổi** — rất hay dùng mỗi khi có build mới hoặc bug được sửa: Loại Mục đích Smoke test Kiểm tra rộng–nông xem build có đủ ổn để test tiếp không Sanity test Kiểm tra hẹp–sâu một chức năng/bản sửa cụ thể Retest (Confirmation) Chạy lại đúng test đã fail để xác nhận bug đã được sửa Regression Kiểm tra thay đổi có làm hỏng phần đang chạy tốt không Hình dung qua một tình huống quen thuộc: dev gửi build mới → tester chạy **smoke** xem app có "sống" không; build ổn, dev báo đã sửa bug đăng nhập → tester chạy **sanity** quanh vùng đó; xác nhận đúng cái bug cũ đã hết bằng **retest** (xem [vòng đời của bug](/blog/bug-life-cycle-bug-report)); cuối cùng, trước khi release, chạy **regression** để chắc thay đổi không kéo theo lỗi mới ở nơi khác. Phân biệt dễ nhầm nhất: **retest** xác nhận *lỗi cũ đã hết*, còn **regression** đảm bảo *không phát sinh lỗi mới*. Smoke và sanity là hai "cánh cổng" trước khi test sâu — chi tiết ở bài [smoke test vs sanity test](/blog/smoke-test-vs-sanity-test). Vì regression phải lặp lại nhiều, nó là ứng viên hàng đầu để tự động hóa. ## Black-box vs White-box Đây là cách phân loại theo **góc nhìn vào hệ thống** khi thiết kế test: Tiêu chí Black-box (hộp đen) White-box (hộp trắng) Góc nhìn Không cần biết code, dựa trên đặc tả Dựa trên cấu trúc code bên trong Kỹ thuật Phân vùng tương đương, giá trị biên, decision table Statement coverage, branch coverage Ai thường làm Tester (manual rất phổ biến) Dev hoặc tester biết code Ví dụ Nhập email sai định dạng xem báo lỗi không Kiểm tra mọi nhánh if/else đã được chạy Ngoài hai nhóm trên, ISTQB còn nhắc tới **kỹ thuật dựa trên kinh nghiệm (experience-based)** như *exploratory testing* (kiểm thử khám phá), *error guessing* (đoán lỗi dựa kinh nghiệm) và *checklist-based testing*. Đây là vũ khí lợi hại của tester lâu năm: dùng trực giác và kinh nghiệm để "đánh hơi" những chỗ phần mềm hay hỏng mà test case viết sẵn dễ bỏ sót. Người mới thường bắt đầu với black-box vì không yêu cầu lập trình; white-box đòi hỏi đọc hiểu code và thường gắn với cấp độ unit/integration. ## Unit / Integration / System / UAT Đây là cách phân loại theo **cấp độ kiểm thử** (test level) — đi từ nhỏ đến lớn trong vòng đời phát triển: Cấp độ Test cái gì Ai thường thực hiện Unit (Component) Từng đơn vị code nhỏ nhất (hàm, class) Dev Integration Tương tác giữa các thành phần/module Dev / Tester System Toàn bộ hệ thống đã tích hợp Tester Acceptance (UAT) Hệ thống đáp ứng đúng nhu cầu nghiệp vụ Khách hàng / end user Diễn giải nhanh từng cấp độ: - **Unit:** kiểm tra một hàm tính tiền phòng theo giờ trả về đúng kết quả chưa — do dev viết, chạy rất sớm. - **Integration:** kiểm tra module đặt phòng gọi đúng sang module lịch và gửi thông báo chưa. - **System:** chạy thử cả luồng nghiệp vụ trên hệ thống đã ghép — đây là nơi manual tester làm việc nhiều nhất. - **Acceptance (UAT):** khách hàng/end user nghiệm thu xem phần mềm có giải quyết đúng nhu cầu thực tế trước khi go-live. Manual tester thường tham gia nhiều nhất ở cấp System và hỗ trợ chuẩn bị cho UAT. ## Bảng tổng hợp khi nào dùng loại nào Để bạn tra nhanh, đây là bảng "tình huống → loại test phù hợp": Tình huống Loại test nên dùng Vừa nhận một build mới từ dev Smoke test Vừa sửa xong một bug nhỏ Sanity test / Retest Trước release, sau nhiều thay đổi Regression test Kiểm tra chức năng đúng yêu cầu Functional test Kiểm tra tốc độ, tải, bảo mật Non-functional test Kiểm tra một hàm/đơn vị code riêng lẻ Unit test Nghiệm thu cùng khách hàng trước go-live Acceptance test (UAT) Gặp thuật ngữ chưa rõ, bạn tra nhanh ở [thuật ngữ kiểm thử](/blog/thuat-ngu-kiem-thu/). ## Câu hỏi thường gặp ### Có bao nhiêu loại kiểm thử? Không có con số cố định, vì cùng một bài test có thể được gọi tên theo nhiều trục phân loại. Cách gọn nhất là nhớ ba nhóm: theo cấp độ (unit, integration, system, acceptance), theo mục đích (functional, non-functional), và theo góc nhìn kỹ thuật (black-box, white-box), cộng nhóm liên quan thay đổi (smoke, sanity, retest, regression). ### Functional và non-functional khác gì? Functional testing kiểm tra hệ thống có làm đúng chức năng theo yêu cầu không (ví dụ đăng nhập, thanh toán). Non-functional testing kiểm tra hệ thống chạy tốt tới đâu — về hiệu năng, bảo mật, khả dụng, tương thích, độ tin cậy. Một bên trả lời "làm gì", bên kia trả lời "làm tốt tới đâu". ### Regression testing là gì? Regression testing là kiểm thử để chắc rằng một thay đổi (sửa lỗi, thêm tính năng) không vô tình làm hỏng các phần đang hoạt động tốt. Nó thường chạy sau khi có thay đổi và trước khi release, phạm vi rộng, và là ứng viên hàng đầu để tự động hóa vì phải lặp lại nhiều lần. ### Black-box và white-box khác nhau? Black-box thiết kế test dựa trên đặc tả, không cần biết code bên trong — phù hợp tester và manual testing. White-box dựa trên cấu trúc code, kiểm tra các nhánh và câu lệnh đã được chạy chưa — thường do dev hoặc tester biết lập trình thực hiện, hay gắn với cấp độ unit/integration. ### UAT là gì? UAT (User Acceptance Testing) là kiểm thử chấp nhận do khách hàng hoặc người dùng thực hiện ở giai đoạn cuối, nhằm xác nhận phần mềm đáp ứng đúng nhu cầu nghiệp vụ trước khi đưa vào sử dụng. Đây là cửa nghiệm thu cuối cùng, tập trung vào giá trị thực tế cho người dùng hơn là chi tiết kỹ thuật. Muốn nắm vững và thực hành các loại kiểm thử trên dự án thật, bạn có thể tham khảo [khóa Manual Testing](/newtester.html) của IT LEARN.