Kiểm thử phần mềm là gì? 7 nguyên tắc, quy trình STLC và các loại kiểm thử
Kiểm thử phần mềm không phải là công đoạn "bấm thử cho chắc" trước khi phát hành. Nó là hoạt động thu thập thông tin để người ra quyết định biết sản phẩm đang ở đâu so với kỳ vọng — và rủi ro nào còn lại nếu phát hành ngay bây giờ.
Kiểm thử phần mềm là gì?
Kiểm thử phần mềm (software testing) là quá trình đánh giá một sản phẩm phần mềm nhằm xác định nó có đáp ứng các yêu cầu đã đặt ra hay không, và phát hiện những khiếm khuyết còn tồn tại. Kiểm thử bao gồm cả hoạt động động (chạy phần mềm và quan sát hành vi) lẫn hoạt động tĩnh (review tài liệu, phân tích mã nguồn mà không chạy).
Một cách hiểu thực dụng hơn: kiểm thử là hoạt động cung cấp thông tin để giảm sự không chắc chắn. Trước khi test, ta không biết sản phẩm tốt đến đâu. Sau khi test, ta biết rõ hơn — kèm danh sách những chỗ đã hỏng và những chỗ chưa kịp kiểm tra.
Phân biệt Error – Defect – Failure
| Thuật ngữ | Tiếng Việt | Bản chất | Ví dụ |
|---|---|---|---|
| Error (Mistake) | Sai sót của con người | Hành động sai của người viết | Lập trình viên hiểu nhầm quy tắc làm tròn |
| Defect (Bug, Fault) | Khiếm khuyết trong sản phẩm | Kết quả của sai sót, nằm trong mã nguồn hoặc tài liệu | Đoạn code làm tròn xuống thay vì làm tròn lên |
| Failure | Sự cố khi vận hành | Biểu hiện ra ngoài khi defect được thực thi | Hoá đơn hiển thị thiếu 1 đồng so với thực tế |
Vì sao cần kiểm thử phần mềm?
Lý do kinh tế quan trọng hơn lý do kỹ thuật: chi phí sửa một khiếm khuyết tăng theo cấp số nhân theo giai đoạn phát hiện. Một yêu cầu mơ hồ được phát hiện lúc review tài liệu chỉ tốn vài phút thảo luận. Cũng khiếm khuyết đó lọt ra production có thể tốn hàng trăm giờ xử lý, chưa kể thiệt hại uy tín.
- Phát hiện khiếm khuyết sớm, khi chi phí sửa còn thấp.
- Cung cấp thông tin để quyết định có phát hành hay không — kiểm thử không quyết định thay, nó cung cấp dữ liệu.
- Giảm rủi ro vận hành: mất dữ liệu, sai tiền, lộ thông tin, ngừng dịch vụ.
- Đáp ứng yêu cầu tuân thủ trong các lĩnh vực bị quản lý chặt như ngân hàng, y tế, bảo hiểm.
- Xây dựng niềm tin của đội ngũ vào việc thay đổi mã nguồn mà không làm hỏng thứ đang chạy.
7 nguyên tắc kiểm thử phần mềm
Bảy nguyên tắc này là nền tảng của syllabus ISTQB và cũng là bảy điều mà tester thực chiến vận dụng hằng ngày, dù có gọi tên chúng hay không.
- Kiểm thử cho thấy sự hiện diện của khiếm khuyết, không chứng minh sự vắng mặt. Không tìm thấy lỗi không có nghĩa là không còn lỗi.
- Kiểm thử toàn bộ là bất khả thi. Số tổ hợp đầu vào của một hệ thống thực tế là vô hạn về mặt thực hành — vì vậy phải ưu tiên theo rủi ro.
- Kiểm thử sớm tiết kiệm thời gian và chi phí. Bắt đầu từ lúc có tài liệu yêu cầu, không đợi có sản phẩm.
- Khiếm khuyết có xu hướng gom cụm. Một số ít module chứa phần lớn lỗi — hãy đào sâu ở nơi đã tìm ra lỗi.
- Nghịch lý thuốc trừ sâu: chạy mãi một bộ test case sẽ không còn tìm được lỗi mới. Bộ test phải được rà soát và làm mới định kỳ.
- Kiểm thử phụ thuộc ngữ cảnh. Cách test một ứng dụng ngân hàng khác hoàn toàn cách test một trò chơi di động.
- Sai lầm về việc không có lỗi: một phần mềm chạy đúng đặc tả nhưng không giải quyết nhu cầu người dùng thì vẫn là một sản phẩm thất bại.
Quy trình kiểm thử phần mềm (STLC) gồm 6 bước
STLC (Software Testing Life Cycle) mô tả các hoạt động kiểm thử theo thứ tự. Trong dự án Agile các bước này không diễn ra tuần tự một lần, mà lặp lại trong từng sprint với quy mô nhỏ hơn.
| Bước | Hoạt động | Đầu ra chính |
|---|---|---|
| 1 | Phân tích yêu cầu — đọc, phản biện, tìm chỗ mơ hồ và mâu thuẫn | Danh sách câu hỏi làm rõ, tiêu chí kiểm thử được |
| 2 | Lập kế hoạch — xác định phạm vi, rủi ro, nguồn lực, tiêu chí vào/ra | Test plan |
| 3 | Thiết kế test case — chuyển yêu cầu thành tình huống kiểm tra cụ thể | Bộ test case, ma trận truy vết |
| 4 | Chuẩn bị môi trường và dữ liệu test | Môi trường sẵn sàng, dữ liệu mẫu |
| 5 | Thực thi test — chạy, quan sát, ghi nhận, log bug, retest | Kết quả thực thi, danh sách bug |
| 6 | Kết thúc — tổng hợp, đánh giá tiêu chí ra, rút kinh nghiệm | Test summary report |
Các cấp độ kiểm thử
Cấp độ kiểm thử trả lời câu hỏi "test ở tầng nào", tương ứng với các giai đoạn phát triển khác nhau.
| Cấp độ | Đối tượng kiểm thử | Ai thường thực hiện | Ví dụ |
|---|---|---|---|
| Unit / Component | Từng hàm, từng lớp riêng lẻ | Lập trình viên | Hàm tính thuế trả về đúng với 10 bộ đầu vào |
| Integration | Sự phối hợp giữa các thành phần | Lập trình viên / Tester | Dịch vụ đơn hàng gọi đúng dịch vụ thanh toán |
| System | Toàn bộ hệ thống theo yêu cầu | Tester | Luồng đặt hàng từ tìm kiếm đến thanh toán |
| Acceptance | Hệ thống theo nhu cầu người dùng/nghiệp vụ | Khách hàng / Người dùng cuối | Nghiệm thu UAT trước khi go-live |
Nguyên tắc thực hành: đẩy càng nhiều kiểm tra xuống tầng thấp càng tốt. Kiểm tra ở tầng unit chạy trong mili-giây và chỉ ra chính xác chỗ hỏng; cùng kiểm tra đó ở tầng giao diện chạy mất vài chục giây và chỉ nói cho bạn biết "có gì đó sai".
Các loại kiểm thử phần mềm
Theo mục tiêu
- Kiểm thử chức năng (functional): hệ thống làm đúng những gì được yêu cầu không.
- Kiểm thử phi chức năng (non-functional): làm tốt đến mức nào — hiệu năng, bảo mật, khả dụng, tương thích.
- Kiểm thử cấu trúc (structural / white-box): dựa vào cấu trúc mã nguồn, đo độ phủ.
- Kiểm thử liên quan thay đổi: xác nhận bản sửa có hiệu quả và không phá vỡ thứ khác.
Các loại thường gặp trong công việc hằng ngày
| Loại | Mục đích | Khi nào dùng |
|---|---|---|
| Smoke test | Kiểm tra nhanh các chức năng sống còn | Ngay sau khi nhận bản build mới, trước khi test sâu |
| Sanity test | Kiểm tra hẹp một vùng vừa sửa | Sau một bản vá nhỏ, để quyết định có test tiếp không |
| Regression test | Đảm bảo thay đổi không phá vỡ chức năng cũ | Trước mỗi lần phát hành |
| Retest (Confirmation) | Xác nhận đúng con bug đã được sửa | Sau khi lập trình viên báo đã fix |
| Exploratory test | Khám phá tự do, tìm lỗi ngoài kịch bản | Khi yêu cầu thiếu, hoặc cần tìm lỗi bất ngờ |
| UAT | Nghiệm thu theo góc nhìn nghiệp vụ | Giai đoạn cuối, trước khi go-live |
Kiểm thử tĩnh và kiểm thử động
Kiểm thử động là chạy phần mềm và quan sát. Kiểm thử tĩnh là xem xét sản phẩm mà không chạy — review tài liệu yêu cầu, review mã nguồn, phân tích tĩnh tự động.
Kiểm thử tĩnh thường bị bỏ qua vì không tạo cảm giác "đang làm việc", nhưng đây là nơi tìm ra khiếm khuyết rẻ nhất. Một yêu cầu mâu thuẫn được phát hiện lúc review chỉ tốn một cuộc trao đổi; cũng mâu thuẫn đó phát hiện lúc UAT có thể kéo theo việc làm lại cả một luồng nghiệp vụ.
Câu hỏi thường gặp
Kiểm thử phần mềm và đảm bảo chất lượng khác nhau thế nào?
Kiểm thử là hoạt động đánh giá sản phẩm để tìm khiếm khuyết. Đảm bảo chất lượng rộng hơn, tập trung vào quy trình làm việc để ngăn khiếm khuyết phát sinh ngay từ đầu. Kiểm thử là một phần nằm trong đảm bảo chất lượng.
Vì sao không thể kiểm thử toàn bộ phần mềm?
Vì số tổ hợp đầu vào, trạng thái và đường đi trong một hệ thống thực tế lớn đến mức không thể duyệt hết trong thời gian hữu hạn. Chỉ riêng một ô nhập văn bản đã có vô số giá trị khả dĩ. Vì vậy kiểm thử phải dựa trên ưu tiên rủi ro và các kỹ thuật thiết kế test case để chọn tập đại diện.
Smoke test và regression test khác nhau ra sao?
Smoke test kiểm tra nhanh các chức năng sống còn ngay khi nhận bản build để quyết định bản build đó có đáng test sâu không. Regression test chạy rộng hơn nhiều, nhằm đảm bảo các thay đổi mới không làm hỏng chức năng đã hoạt động trước đó, và thường được chạy trước mỗi lần phát hành.
Tester có tham gia từ giai đoạn nào của dự án?
Từ giai đoạn phân tích yêu cầu, không phải đợi có sản phẩm. Đây chính là nguyên tắc kiểm thử sớm: đọc và phản biện tài liệu yêu cầu là hoạt động kiểm thử tĩnh, và là nơi phát hiện khiếm khuyết với chi phí thấp nhất.