Các cấp độ testing: Unit, Integration, System và Acceptance tests
6 tháng trước · 12 phút đọc
Testing không chỉ có một cấp độ
Nhiều bạn mới học testing hay hỏi mình: "Tester thì test cái gì? Dev đã tự test rồi còn mình làm gì thêm?"
Câu hỏi đó hợp lý. Nhưng đây là điều thú vị: dev và tester test ở các cấp độ khác nhau, với mục tiêu khác nhau, bắt lỗi ở những chỗ khác nhau.
Phần mềm được kiểm thử theo 4 cấp độ, từ nhỏ nhất đến lớn nhất: unit test, integration test, system test và acceptance test. Mỗi cấp độ trả lời một câu hỏi riêng - và bỏ sót bất kỳ cấp nào cũng có thể để lọt bug lên production.
4 tầng testing: mỗi tầng bắt một loại lỗi riêng biệt
Mình sẽ giải thích từng cấp theo thứ tự, kèm ví dụ cụ thể để bạn hình dung tester tham gia ở đâu trong từng giai đoạn dự án.
Unit test: kiểm tra từng mảnh nhỏ nhất
Unit test là cấp độ thấp nhất. Dev viết code cho một function nhỏ - function đó được test riêng lẻ, tách biệt khỏi phần còn lại của hệ thống.
Hình dung như nhà máy lắp ráp xe máy: trước khi ráp động cơ vào xe, người ta test từng chi tiết - bu lông, piston, vòng bi - riêng từng cái. Nếu piston lỗi mà cứ ráp vào rồi mới test xe, việc tháo ra sửa tốn gấp 10 lần.
Ai viết unit test? Chủ yếu là dev. Tester ít khi viết unit test, trừ khi bạn là automation tester có kỹ năng code.
Ví dụ thực tế: Function tính giá sau khi áp mã giảm giá trên sàn thương mại điện tử.
Input: giá gốc 500.000đ, mã giảm 20%
Expected output: 400.000đ
Unit test sẽ check:
- Giảm đúng 20% chưa? → 400.000đ ✓
- Nếu mã giảm 100%? → 0đ hay vẫn tính phí ship?
- Nếu giá âm? → Báo lỗi hay crash?
- Mã giảm đã hết hạn? → Xử lý thế nào?
Unit test bắt lỗi ngay từ function nhỏ - chi phí fix thấp nhất
Tester cần biết unit test để đọc kết quả và hiểu dev test gì rồi - từ đó không test lại những gì dev đã cover, mà tập trung vào integration và system level.
Một điều mình thường thấy fresher bỏ qua: hỏi dev "unit test cover gì rồi?" trước khi viết test case. Tiết kiệm rất nhiều thời gian.
Integration test: các module có "nói chuyện" được với nhau không?
Dev viết từng module riêng lẻ. Mỗi module unit test đều pass. Nhưng khi ghép lại... bug nổ.
Tại sao? Vì interface giữa các module sai. Module A trả về số dạng string "100", module B nhận đầu vào là số integer 100 - kết quả tính toán ra sai hoàn toàn dù cả hai module riêng lẻ đều đúng.
Integration test kiểm tra đúng điểm này: các component phối hợp với nhau có đúng không?
Lỗi tích hợp thường ẩn ở "ranh giới" giữa hai module
Ví dụ thực tế trong dự án app đặt đồ ăn:
- Module giỏ hàng tính tổng tiền → integration với module thanh toán nhận đúng số tiền?
- Module đặt hàng tạo đơn → integration với module thông báo gửi SMS xác nhận?
- Module đăng nhập xác thực user → integration với module phân quyền cấp đúng quyền?
Tester tham gia nhiều ở cấp này. Bạn không cần hiểu code bên trong từng module - chỉ cần biết module A nhận gì, trả gì, và module B nhận đầu vào đó xử lý đúng không.
Một lần mình từng bỏ qua test tích hợp giữa module giảm giá và module tính ship. Kết quả: đơn hàng được giảm giá nhưng phí ship vẫn tính trên giá gốc. Bug tồn tại 3 ngày trên production trước khi bị khách hàng báo. Từ đó mình không bao giờ bỏ qua integration test nữa.
Người trái ngành đừng lo: bạn không cần biết code để test integration. Chỉ cần hiểu luồng dữ liệu đi từ đâu đến đâu - kỹ năng này học được sau 1-2 tuần làm quen với hệ thống.
System test: test toàn bộ ứng dụng như người dùng thật
System test là cấp độ mà tester làm nhiều nhất. Đây là lúc bạn test toàn bộ hệ thống đã tích hợp hoàn chỉnh - từ giao diện đến database, từ luồng người dùng đến xử lý lỗi.
Nếu unit test là "từng chi tiết máy móc hoạt động không", integration test là "các bộ phận lắp vào nhau khớp không", thì system test là "chiếc xe này chạy được không?".
System test bao gồm nhiều loại kiểm thử:
- Functional testing (kiểm thử chức năng): tính năng hoạt động đúng như yêu cầu?
- Regression testing (kiểm thử hồi quy): sau khi fix bug, tính năng cũ có bị ảnh hưởng?
- Performance testing (kiểm thử hiệu năng): hệ thống chịu được bao nhiêu người dùng cùng lúc?
- Security testing (kiểm thử bảo mật): có lỗ hổng bảo mật nào không?
System test bao gồm nhiều loại - tester cần lên kế hoạch trước khi test
Ví dụ với app ngân hàng online:
Scenario system test: Chuyển tiền liên ngân hàng
1. Đăng nhập → xác thực OTP
2. Chọn chuyển tiền → nhập số tài khoản ngân hàng khác
3. Nhập số tiền → xem phí giao dịch
4. Xác nhận → nhập PIN
5. Kiểm tra số dư bị trừ
6. Kiểm tra lịch sử giao dịch
7. Kiểm tra thông báo SMS nhận được
System test không chỉ test "happy path" (luồng thành công). Tester phải test negative cases: nhập số tài khoản sai định dạng, chuyển số tiền vượt hạn mức, mất kết nối giữa chừng khi đang giao dịch.
Mình khuyên bạn dành ít nhất 30-40% thời gian cho negative test cases - đây là nơi ẩn nhiều bug nhất nhưng fresher hay bỏ qua vì chỉ nghĩ đến "test bình thường".
Acceptance test: người dùng cuối quyết định "đạt" hay "không đạt"
Acceptance test - hay kiểm thử chấp nhận (UAT - User Acceptance Testing) - là cấp độ cuối cùng trước khi phần mềm được release. Và đây là cấp độ đặc biệt: người thực hiện không phải tester hay dev, mà là khách hàng hoặc người dùng cuối.
Tại sao lại thế? Vì tester kiểm tra xem phần mềm có đúng với spec (tài liệu yêu cầu) không. Còn khách hàng kiểm tra xem phần mềm có đúng với nhu cầu thực tế của họ không. Hai thứ này đôi khi... khác nhau.
Tester làm gì trong UAT?
Bạn không phải ngồi chơi. Tester hỗ trợ UAT bằng cách:
- Chuẩn bị test scenario (kịch bản kiểm thử) cho người dùng thực hiện
- Ghi chép bug và feedback trong quá trình UAT
- Hướng dẫn người dùng khi họ bị stuck với nghiệp vụ kỹ thuật
- Tổng hợp kết quả, phân loại lỗi nào cần fix trước release
Tester đóng vai "cầu nối" giữa người dùng cuối và team dev trong UAT
Ví dụ UAT thực tế - phần mềm quản lý kho cho chuỗi bán lẻ:
Team dev và tester đã test xong system test, mọi test case đều pass. Đến UAT, quản lý kho của khách hàng dùng thử và phát hiện: màn hình nhập hàng yêu cầu nhập từng sản phẩm một. Nhưng thực tế họ nhận hàng theo lô 50-100 mặt hàng cùng lúc - phải nhập từng cái thì mất cả ngày.
Bug không? Không. Phần mềm chạy đúng spec. Nhưng spec thiếu - và UAT mới phát hiện được điều này.
Nhiều bạn hỏi mình có cần tham gia UAT không. Câu trả lời: có, và đây là cơ hội học hỏi rất tốt. Bạn được tiếp xúc trực tiếp với nghiệp vụ thực tế của khách hàng - thứ mà không sách nào dạy được.
Tester tham gia ở cấp độ nào trong dự án thực tế?
Một câu hỏi thực chiến hơn: trong dự án thật ở công ty Việt Nam, tester xuất hiện lúc nào?
Thực tế không phải lúc nào cũng sách vở. Nhiều startup nhỏ không có quy trình rõ ràng. Nhưng nhìn chung, đây là phân công phổ biến:
| Cấp độ | Người thực hiện | Tester làm gì? |
|---|---|---|
| Unit Test | Dev | Đọc kết quả, hỏi coverage |
| Integration Test | Dev + Tester | Viết test case API, test luồng module |
| System Test | Tester chính | Viết và thực thi toàn bộ test case |
| Acceptance Test | Khách hàng + Tester hỗ trợ | Chuẩn bị kịch bản, ghi chép bug |
Tester tập trung nhiều nhất ở system test - nhưng cần hiểu cả 4 cấp
Với fresher mới vào nghề, bạn sẽ bắt đầu từ system test: viết test case, thực hiện test, báo cáo bug. Đây là nơi bạn xây dựng kỹ năng nền tảng.
Sau khoảng 6-12 tháng kinh nghiệm, bạn dần tham gia integration test - đặc biệt nếu dự án có API. Nhiều tester sau 1-2 năm học automation để cover unit test và integration test tự động.
Nếu bạn muốn có nền tảng vững chắc ngay từ đầu, khóa Kiểm thử phần mềm đi từ kiến thức cơ bản nhất, có bài thực hành từng cấp độ - phù hợp cho người trái ngành không có background IT.
Trấn an thêm một chút: bạn không cần nắm hết cả 4 cấp trong ngày đầu. Hiểu khái niệm đủ để không bị lost khi nghe dev hoặc PM nói chuyện - thế là ổn rồi. Kỹ năng thực chiến sẽ đến khi bạn làm thật.
Bức tranh toàn cảnh: 4 cấp độ trong vòng đời dự án
Để không bị rối, hãy nhớ một nguyên tắc đơn giản: bug phát hiện càng muộn, chi phí fix càng cao.
Theo nhiều nghiên cứu về chi phí phát triển phần mềm, sửa bug ở production tốn gấp 6-10 lần so với sửa ở giai đoạn phát triển - con số này giải thích tại sao các công ty đầu tư nhiều vào testing từ sớm. Bug ở unit test: dev tự sửa trong 30 phút. Bug ở production sau release: tốn vài ngày phân tích, hotfix khẩn, thông báo khách hàng, có thể mất uy tín.
4 cấp độ không phải "test lại từ đầu mỗi lần" - mà là lưới lọc nhiều tầng. Mỗi tầng bắt một loại lỗi riêng:
- Unit test: lỗi logic trong function nhỏ
- Integration test: lỗi giao tiếp giữa các module
- System test: lỗi nghiệp vụ từ góc nhìn người dùng
- Acceptance test: lỗi "đúng spec nhưng sai nhu cầu"
Lưới lọc 4 tầng: bug qua được tầng này sẽ bị bắt ở tầng sau
Tải checklist bên dưới để có danh sách câu hỏi cho từng cấp độ - mình tổng hợp từ kinh nghiệm thực tế để bạn dùng khi bắt đầu làm dự án đầu tiên:
Tải checklist 4 cấp độ testing
Testing không khó. Khó là nhớ rằng mỗi cấp độ có mục tiêu riêng - và làm đúng mục tiêu đó, không nhầm lẫn giữa các cấp.
Bạn đang ở cấp nào trong hành trình học testing? Comment bên dưới, mình đọc và trả lời từng bạn nhé.