# Các Cấp Độ Kiểm Thử: Unit, Integration, System, UAT > Hồi mới vào nghề, mình từng tưởng "kiểm thử" chỉ là ngồi bấm thử app xem có lỗi không. 🙂 Đến khi đọc syllabus ISTQB mình mới vỡ lẽ: kiểm thử được chia thành nhiều tầng rất rõ ràng, mỗi tầng có người l… - **URL canonical**: https://itlearn.edu.vn/blog/cac-cap-do-kiem-thu - **Published**: 2026-07-05T11:00:00+07:00 - **Modified**: 2026-07-05T12:42:00+07:00 - **Author**: Anh Tuấn - **Category**: ISTQB Certificate (https://itlearn.edu.vn/blog/cat/istqb) - **Reading time**: 12 phút - **Source site**: IT LEARN — Học viện Software Testing tiếng Việt --- Hồi mới vào nghề, mình từng tưởng "kiểm thử" chỉ là ngồi bấm thử app xem có lỗi không. 🙂 Đến khi đọc syllabus ISTQB mình mới vỡ lẽ: kiểm thử được chia thành nhiều tầng rất rõ ràng, mỗi tầng có người làm và mục tiêu riêng. Bài này mình kể cho bạn nghe gọn gàng về **các cấp độ kiểm thử** — từ unit tới UAT — để bạn nắm được bức tranh tổng thể, biết mình đang đứng ở đâu trong quy trình. ![Các cấp độ kiểm thử theo ISTQB: unit, integration, system, acceptance UAT](/uploads/2026/07/cac-cap-do-kiem-thu.jpg) ## Cấp độ kiểm thử (test levels) là gì? **Các cấp độ kiểm thử (test levels) theo ISTQB gồm 4 tầng: Unit (component), Integration, System và Acceptance (UAT).** Mỗi cấp độ kiểm tra phần mềm ở một mức độ "lắp ráp" khác nhau — từ một hàm code nhỏ, tới các module ghép lại, tới cả hệ thống hoàn chỉnh, và cuối cùng là nghiệm thu theo nhu cầu người dùng. Đây là 4 nhóm hoạt động kiểm thử được tổ chức và quản lý cùng nhau. Hiểu nôm na: bạn không kiểm thử "tất tần tật một lúc". Bạn đi từ chi tiết nhỏ nhất rồi nới rộng dần. Càng lên cấp cao, bạn càng nhìn phần mềm giống mắt người dùng cuối. Cách phân tầng này khớp với **mô hình chữ V (V-model)**: mỗi cấp độ kiểm thử "soi gương" với một giai đoạn phát triển — unit ứng với thiết kế chi tiết, integration ứng với thiết kế kiến trúc, system ứng với đặc tả yêu cầu, và acceptance ứng với nhu cầu nghiệp vụ ban đầu. Để dễ hình dung, suốt bài mình lấy ví dụ một **Hệ thống đặt phòng họp nội bộ** của công ty — kiểu app cho nhân viên chọn phòng, chọn khung giờ, gửi lời mời. Ta sẽ đi qua từng cấp độ với chính hệ thống này. ## Unit testing **Unit test là gì? Đó là cấp độ kiểm thử nhỏ nhất — kiểm tra từng đơn vị code riêng lẻ (một hàm, một method, một class) một cách độc lập.** Mục tiêu là xác nhận từng "viên gạch" hoạt động đúng trước khi ghép chúng lại. Unit testing còn được ISTQB gọi là **component testing**. Trong Hệ thống đặt phòng họp, một unit có thể là hàm `kiemTraTrungLich(phong, gioBatDau, gioKetThuc)` — chỉ làm đúng một việc: trả về true nếu khung giờ bị trùng. Bạn viết test cho riêng hàm này, không cần database hay giao diện, thường dùng **mock/stub** để giả lập phần phụ thuộc. - **Ai làm:** lập trình viên (developer) là người viết và chạy unit test, thường ngay trong lúc code. - **Khi nào:** sớm nhất, ngay khi một đơn vị code vừa hoàn thành. - **Mục tiêu:** bắt lỗi logic ở mức nhỏ nhất, nơi sửa rẻ nhất. Unit test thường gắn với **TDD** (Test-Driven Development) và được tự động hóa cao bằng các framework như JUnit, NUnit, pytest. Đây là cấp độ tester thủ công ít đụng tới nhất, nhưng hiểu nó giúp bạn phối hợp với dev tốt hơn. ## Integration testing **Integration test (kiểm thử tích hợp) kiểm tra cách các đơn vị/module đã qua unit test giao tiếp và hoạt động cùng nhau.** Một hàm chạy đúng khi đứng riêng chưa chắc đã đúng khi ghép với hàm khác — lỗi thường nằm ở "đường nối" giữa chúng: sai định dạng dữ liệu truyền qua, gọi API sai thứ tự, hiểu nhầm giá trị trả về. Ở Hệ thống đặt phòng họp, integration testing kiểm tra ví dụ: module "Đặt phòng" gọi sang module "Gửi thông báo" — khi đặt thành công thì email mời họp có được kích hoạt với đúng dữ liệu phòng và giờ không? Hay module đặt phòng có ghi đúng vào database lịch không? ISTQB phân biệt hai loại tích hợp: **component integration** (ghép các module trong cùng một hệ thống) và **system integration** (ghép hệ thống của bạn với hệ thống ngoài, ví dụ tích hợp với Google Calendar). Về cách tiếp cận, có ba lối quen thuộc: Cách tích hợp Ý tưởng **Top-down** Ghép từ module cấp cao xuống thấp, dùng *stub* thay phần chưa có **Bottom-up** Ghép từ module cấp thấp lên cao, dùng *driver* để gọi **Big-bang** Ghép tất cả một lúc rồi test — nhanh nhưng khó tìm nguyên nhân lỗi - **Ai làm:** developer và/hoặc tester, tùy mức tích hợp. - **Khi nào:** sau khi các unit liên quan đã pass. - **Mục tiêu:** phát hiện lỗi ở giao diện và tương tác giữa các thành phần. ## System testing **System testing kiểm thử toàn bộ hệ thống đã được tích hợp hoàn chỉnh, đối chiếu với đặc tả yêu cầu (requirements).** Đây là lần đầu phần mềm được nhìn như một khối thống nhất, trong môi trường gần giống thật. Tester là nhân vật chính ở cấp độ này. Với Hệ thống đặt phòng họp, system testing kiểm tra trọn vẹn luồng nghiệp vụ end-to-end: nhân viên đăng nhập → tìm phòng trống → đặt phòng → nhận xác nhận → người được mời thấy lịch. Đồng thời, đây là nơi kiểm tra cả **yêu cầu phi chức năng**: tốc độ tải trang (performance), bảo mật phân quyền (security), khả năng dùng được (usability). - **Ai làm:** đội kiểm thử độc lập (independent test team). - **Khi nào:** sau khi integration xong, hệ thống đã hoàn chỉnh. - **Mục tiêu:** xác nhận hệ thống đáp ứng cả yêu cầu chức năng lẫn phi chức năng theo đặc tả. System testing nên chạy trong môi trường test riêng, cấu hình càng giống production càng tốt, để kết quả phản ánh đúng thực tế khi go-live. ## Acceptance testing (UAT) **UAT là gì? Acceptance testing (kiểm thử chấp nhận) là cấp độ cuối, xác nhận hệ thống đáp ứng nhu cầu nghiệp vụ và sẵn sàng bàn giao — do người dùng/khách hàng thực hiện, không phải đội kỹ thuật.** UAT (User Acceptance Testing) là dạng phổ biến nhất, nhưng acceptance testing rộng hơn UAT. Khác biệt cốt lõi với system testing: system testing hỏi "phần mềm có đúng đặc tả không?", còn acceptance testing hỏi "phần mềm có **giải quyết được công việc thật** của người dùng không?". Ở Hệ thống đặt phòng họp, chính nhân viên hành chính — người dùng thật — sẽ tự đặt thử vài cuộc họp theo kịch bản công việc hằng ngày để xác nhận app dùng được, trước khi công ty triển khai rộng. ISTQB liệt kê vài dạng acceptance testing đáng nhớ: - **UAT (User Acceptance Testing):** người dùng cuối kiểm tra hệ thống có phục vụ đúng nhu cầu nghiệp vụ. - **OAT (Operational Acceptance Testing):** đội vận hành kiểm tra backup, phục hồi, bảo trì, cài đặt. - **Contractual & regulatory acceptance:** nghiệm thu theo điều khoản hợp đồng hoặc quy định pháp lý. - **Alpha & beta testing:** alpha do người dùng test tại nơi nhà phát triển; beta do người dùng test tại môi trường của họ. - **Ai làm:** khách hàng, người dùng cuối, đội vận hành. - **Khi nào:** sau system testing, ngay trước khi go-live. - **Mục tiêu:** tạo niềm tin để bàn giao; phát hiện vấn đề về sự phù hợp với nhu cầu thực. ## Bảng so sánh 4 cấp độ (ai làm · khi nào · mục tiêu) Đây là bảng mình hay vẽ lại cho học viên để nhớ nhanh **các cấp độ kiểm thử**: Cấp độ Test gì Ai làm Khi nào Ví dụ (Hệ thống đặt phòng họp) **Unit (component)** Một đơn vị code riêng lẻ Developer Vừa code xong Hàm kiểm tra trùng lịch phòng **Integration** Tương tác giữa các module Dev / Tester Sau khi unit pass Module đặt phòng gọi module gửi email **System** Toàn hệ thống vs đặc tả Đội test độc lập Sau integration Luồng đặt phòng end-to-end + hiệu năng, bảo mật **Acceptance (UAT)** Hệ thống vs nhu cầu thật Người dùng / khách hàng Trước go-live Nhân viên hành chính đặt thử cuộc họp thật Mẹo nhớ: đi từ trên xuống là đi từ **nhỏ → lớn**, từ **góc nhìn dev → góc nhìn người dùng**, và lỗi bắt được càng muộn thì sửa càng đắt. Đó là lý do ai cũng khuyên "test sớm, test thường xuyên". ## Phân biệt test levels vs test types Đây là chỗ rất nhiều bạn mới nhầm, nên mình tách riêng. **Test levels (cấp độ kiểm thử) trả lời câu hỏi "kiểm thử ở giai đoạn nào / mức lắp ráp nào" (unit, integration, system, acceptance). Còn test types (loại kiểm thử) trả lời "kiểm thử khía cạnh gì" (functional, performance, security, usability...).** Hai khái niệm này **trực giao** — tức là độc lập và kết hợp được với nhau. Bạn có thể chạy *functional test* (một test type) ở *system level* (một test level); cũng có thể chạy *performance test* ở cấp system. Một cái nói về **khi nào / lắp ráp tới đâu**, cái kia nói về **soi khía cạnh nào**. Để nắm trọn bức tranh, bạn nên đọc thêm bài [các loại kiểm thử](/blog/cac-loai-kiem-thu) (phần test types) song song với bài này. Hai cấp độ và loại kiểm thử này đều nằm trong [quy trình kiểm thử STLC](/blog/quy-trinh-kiem-thu-stlc) tổng thể, và đều là kiến thức cốt lõi trong [ISTQB là gì](/blog/istqb-la-gi). Nếu gặp thuật ngữ lạ trong lúc đọc, tra nhanh ở [thuật ngữ kiểm thử](/blog/thuat-ngu-kiem-thu/) cho chắc. Muốn học bài bản các cấp độ kiểm thử cùng toàn bộ syllabus và luyện thi CTFL có người hướng dẫn, bạn có thể tham khảo khóa [chứng chỉ ISTQB CTFL](/ctfl.html) của IT LEARN. ## Câu hỏi thường gặp ### Có mấy cấp độ kiểm thử? Theo ISTQB có 4 cấp độ kiểm thử: Unit (component), Integration, System và Acceptance (UAT). Chúng đi từ nhỏ tới lớn — từ kiểm tra một đơn vị code riêng lẻ, tới ghép các module, tới toàn hệ thống, và cuối cùng là nghiệm thu theo nhu cầu người dùng trước khi bàn giao. ### UAT là gì? UAT (User Acceptance Testing) là kiểm thử chấp nhận do chính người dùng cuối hoặc khách hàng thực hiện, ở cấp độ cuối cùng. Mục tiêu là xác nhận phần mềm giải quyết được công việc thật của họ, không chỉ đúng đặc tả kỹ thuật. UAT diễn ra ngay trước khi hệ thống go-live, tạo niềm tin để bàn giao. ### Unit test do ai làm? Unit test do lập trình viên (developer) viết và chạy, thường ngay trong lúc code từng hàm hay class. Đây là cấp độ kiểm thử nhỏ nhất và được tự động hóa cao bằng các framework như JUnit, pytest. Tester thủ công ít trực tiếp làm unit test, nhưng hiểu nó giúp phối hợp với dev tốt hơn. ### Test level khác test type thế nào? Test level nói về kiểm thử ở giai đoạn hay mức lắp ráp nào (unit, integration, system, acceptance). Test type nói về kiểm thử khía cạnh gì (functional, performance, security, usability). Hai khái niệm độc lập và kết hợp được: ví dụ bạn có thể chạy performance test ngay tại cấp system testing. ### Integration testing là gì? Integration testing (kiểm thử tích hợp) kiểm tra cách các module đã qua unit test giao tiếp với nhau, vì lỗi thường nằm ở "đường nối" giữa chúng — sai dữ liệu truyền qua hay gọi API sai. Có ba cách tiếp cận phổ biến: top-down, bottom-up và big-bang, mỗi cách hợp với một bối cảnh dự án khác nhau. Bạn muốn học chắc các cấp độ kiểm thử và luyện thi CTFL bài bản trên dự án thật? Tham khảo khóa [chứng chỉ ISTQB CTFL](/ctfl.html) của IT LEARN nhé.