Tóm tắt lý thuyết Software Testing - Các mức độ kiểm thử
Tóm tắt toàn diện về kiểm thử phần mềm: từ phân loại hộp đen, hộp trắng, các mức độ Unit, System, Integration đến mô hình TMM đánh giá quy trình kiểm thử phần mềm.
kiểm thử phần mềmkiểm thử hộp đenkiểm thử hộp trắngkiểm thử chức năngunit testintegration testmô hình TMMsystem test
1. Phân loại theo phương pháp tiếp cận
1.1. Kiểm thử hộp đen (Black Box Testing)
-
Định nghĩa: Đánh giá chức năng phần mềm mà không cần biết cấu trúc mã nguồn bên trong.
-
Trọng tâm: Chỉ quan tâm đến đầu vào (Input) và đầu ra (Output) mong đợi.
-
Người thực hiện: Chủ yếu là Tester (QA) và người dùng cuối.
Các kỹ thuật thiết kế test case:
- Phân vùng tương đương (Equivalence Partitioning): Chia dữ liệu đầu vào thành các tập hợp hợp lệ và không hợp lệ. Chỉ test một giá trị đại diện cho mỗi tập.
- Phân tích giá trị biên (Boundary Value Analysis): Tập trung kiểm tra các giá trị ở ranh giới (lớn nhất, nhỏ nhất, ngay sát biên) vì lỗi thường ẩn nấp tại đây.
- Bảng quyết định (Decision Table): Lập bảng các kết hợp điều kiện đầu vào và hành động tương ứng. Phù hợp cho logic phức tạp.
- Chuyển đổi trạng thái (State Transition): Áp dụng khi hệ thống thay đổi trạng thái dựa trên các sự kiện hoặc thời gian cụ thể.
- Kiểm thử Use Case (Use Case Testing): Dựa trên các kịch bản tương tác thực tế của người dùng với hệ thống.
1.2. Kiểm thử hộp trắng (White Box Testing)
-
Định nghĩa: Kỹ thuật kiểm thử dựa trên cấu trúc nội bộ, thiết kế và mã nguồn của phần mềm.
-
Yêu cầu: Đòi hỏi kiến thức sâu rộng về ngôn ngữ lập trình và kiến trúc hệ thống.
-
Người thực hiện: Chủ yếu do Lập trình viên (Developer) đảm nhiệm.
Các mức độ bao phủ (Coverage):
- Bao phủ câu lệnh (Statement Coverage): Đảm bảo mọi dòng code trong chương trình đều được thực thi ít nhất một lần.
- Bao phủ nhánh (Branch/Decision Coverage): Kiểm tra mọi nhánh của các cấu trúc điều khiển (ví dụ: cả nhánh TRUE và FALSE của lệnh IF).
- Bao phủ điều kiện (Condition Coverage): Đánh giá từng điều kiện logic (boolean) độc lập bên trong một biểu thức quyết định.
- Bao phủ đường dẫn (Path Coverage): Kiểm thử mọi luồng đường dẫn có thể xảy ra từ lúc bắt đầu đến khi kết thúc hàm/module.
1.3. Kiểm thử hộp xám (Grey Box Testing)
Định nghĩa: Là sự kết hợp ưu điểm của cả Hộp Đen và Hộp Trắng. Người kiểm thử có một phần kiến thức về cấu trúc nội bộ hoặc cơ sở dữ liệu để thiết kế test case, nhưng thực thi test ở cấp độ giao diện (Hộp đen).
Trọng tâm: Tìm kiếm các khiếm khuyết do cấu trúc hoặc ứng dụng sử dụng không đúng cách. Rất hiệu quả cho kiểm thử ứng dụng Web.
Đặc điểm nổi bật:
- Thiết kế test case dựa trên sơ đồ kiến trúc, sơ đồ dữ liệu.
- Kiểm tra dữ liệu trực tiếp trong hệ quản trị CSDL để đối chiếu giao diện.
- Không yêu cầu quyền truy cập toàn bộ mã nguồn (source code).
- Cân bằng giữa hiệu quả tìm lỗi và chi phí thời gian.
2. Phân loại theo mục tiêu thực thi
2.1. Kiểm thử chức năng (Functional Testing)
Mục tiêu: Xác minh phần mềm có hoạt động đúng theo các yêu cầu/đặc tả nghiệp vụ đã định nghĩa hay không. Trả lời câu hỏi: "Hệ thống CÓ LÀM ĐƯỢC những gì nó phải làm không?"
Smoke Testing
Kiểm tra nông và rộng. Đảm bảo các chức năng cốt lõi nhất, cơ bản nhất của bản build (bản dựng mới) hoạt động bình thường, không bị sập (crash). Nếu pass, mới tiến hành kiểm thử chi tiết.
Sanity Testing
Kiểm tra sâu và hẹp. Thực hiện sau khi nhận bản build có vá lỗi (bug fix). Chỉ tập trung xác minh các chức năng vừa được sửa hoặc module liên quan trực tiếp để đảm bảo lỗi đã biến mất.
Regression Testing (Kiểm thử hồi quy)
Thực hiện khi phần mềm có sự thay đổi lớn, thêm tính năng mới. Đảm bảo việc thêm mã nguồn mới không làm hỏng/ảnh hưởng đến các tính năng cũ đang hoạt động tốt.
Retesting (Kiểm thử lại)
Chỉ chạy lại đúng các test case đã từng bị Fail trước đó để xác nhận rằng Developer đã thực sự sửa xong lỗi (Fixed) cho các kịch bản cụ thể đó.
2.2. Kiểm thử phi chức năng (Non-Functional Testing)
Mục tiêu: Đánh giá các thuộc tính chất lượng của hệ thống như tốc độ, bảo mật, thân thiện. Trả lời câu hỏi: "Hệ thống LÀM ĐIỀU ĐÓ TỐT ĐẾN MỨC NÀO?"
Hiệu năng (Performance)
- Load Testing: Kiểm tra hệ thống dưới tải trọng bình thường và tối đa dự kiến.
- Stress Testing: Đẩy tải vượt mức giới hạn để xem hệ thống sập như thế nào và phục hồi ra sao.
- Spike Testing: Tăng đột ngột số lượng người dùng trong thời gian cực ngắn.
- Soak/Endurance Testing: Chạy hệ thống liên tục với tải trọng trung bình trong thời gian dài (vài ngày) để dò rò rỉ bộ nhớ.
Bảo mật (Security)
Bảo vệ dữ liệu và ngăn chặn các cuộc tấn công từ bên ngoài.
- Quét lỗ hổng (Vulnerability Scanning).
- Kiểm thử xâm nhập (Penetration Testing) - Đóng giả Hacker.
- Kiểm tra phân quyền và xác thực người dùng.
Trải nghiệm & Tương thích
- Usability Testing (Tính khả dụng): Giao diện có trực quan không? Người dùng có dễ thao tác không? Số bước để hoàn thành tác vụ có ít nhất chưa?
- Compatibility Testing (Tính tương thích): Hệ thống có chạy mượt trên nhiều Trình duyệt (Chrome, Safari), Hệ điều hành (Windows, iOS, Android), Thiết bị (Mobile, Tablet) khác nhau không?
2.3. So sánh Kiểm thử Thủ công và Kiểm thử Tự động
Thủ công (Manual Testing)
- Thực thi: Con người tự tay bấm click, nhập liệu từng bước theo kịch bản.
- Chi phí ban đầu: Thấp, triển khai ngay lập tức.
- Tốc độ: Chậm, dễ sai sót do yếu tố con người (nhàm chán).
- Ứng dụng tốt nhất: Kiểm thử thăm dò (Exploratory), Giao diện (UI/UX), Tính khả dụng (Usability), Dự án thay đổi yêu cầu liên tục.
- Đầu tư: Cần nhiều nhân sự khi số lượng test case tăng cao.
Tự động (Automated Testing)
- Thực thi: Dùng script/code và Tool (Selenium, Appium, Cypress) để máy tính tự chạy.
- Chi phí ban đầu: Rất cao (mua tool, thuê nhân sự viết code automation).
- Tốc độ: Cực nhanh, độ chính xác tuyệt đối, hoạt động 24/7.
- Ứng dụng tốt nhất: Kiểm thử hồi quy (Regression), Kiểm thử Hiệu năng (Load/Stress), Dự án dài hạn, Test case lặp đi lặp lại.
- Đầu tư: ROI (Tỷ suất hoàn vốn) cao về lâu dài.
3. Các mức độ kiểm thử phần mềm
Kiểm thử phần mềm không phải là một hành động đơn lẻ mà là một quá trình tuần tự gồm nhiều cấp độ. Mỗi cấp độ được thiết kế để tìm kiếm các loại khiếm khuyết khác nhau trong suốt vòng đời phát triển (SDLC).
1 3.1. Kiểm thử mức đơn vị (Unit Testing)
Định nghĩa: Là mức độ thấp nhất. Nhằm kiểm tra tính đúng đắn của các cấu phần nhỏ nhất, độc lập nhất trong mã nguồn (một hàm, một phương thức, một lớp).
Mục tiêu: Cô lập một phần mã nguồn và xác minh tính chính xác logic của phần đó.
Thực hiện: Do chính Lập trình viên (Developers) viết code thực hiện ngay trong quá trình code (Phương pháp Hộp trắng).
Kỹ thuật: Sử dụng Stubs (đoạn code giả lập hàm được gọi) và Mock objects để cô lập Unit khỏi các phụ thuộc bên ngoài như CSDL hay API.
Đặc điểm
- - Phát hiện lỗi sớm nhất
- - Chi phí sửa lỗi cực kỳ rẻ
- - Công cụ: JUnit, NUnit, xUnit, PHPUnit.
2 3.2. Kiểm thử tích hợp (Integration Testing)
Định nghĩa: Kết hợp các Unit (đã pass Unit Test) lại với nhau thành các cụm module và kiểm tra giao tiếp, luồng truyền dữ liệu giữa chúng.
Trọng tâm: Phát hiện lỗi phát sinh tại giao diện (Interface) kết nối giữa các module. Cấu trúc CSDL có khớp không? API truyền tham số có đúng định dạng không?
4 Phương pháp tiếp cận chính:
3 3.3. Kiểm thử hệ thống (System Testing)
Định nghĩa: Kiểm tra một hệ thống hoàn chỉnh và được tích hợp toàn bộ (End-to-End).
Mục tiêu: Đánh giá xem phần mềm có tuân thủ chặt chẽ tài liệu Đặc tả Yêu cầu Hệ thống (SRS - System Requirement Specification) hay không.
Phạm vi: Bao gồm cả Kiểm thử chức năng (nghiệp vụ toàn hệ thống) và Phi chức năng (hiệu năng, bảo mật, tương thích cấu hình).
Môi trường: Bắt buộc phải thiết lập môi trường kiểm thử (Staging) mô phỏng gần giống hoàn toàn 100% với môi trường thực tế (Production) của khách hàng.
Phương pháp sử dụng:
Kiểm thử hộp đen thuần túy
4 3.4. Kiểm thử chấp nhận (Acceptance Testing)
Định nghĩa: Mức độ cuối cùng trước khi đưa phần mềm ra thị trường. Nhằm lấy được sự đồng ý (ký nghiệm thu) từ phía Khách hàng hoặc Người dùng cuối.
Trọng tâm: Không phải tìm lỗi code (như các mức trước), mà là xác minh hệ thống có giải quyết được bài toán kinh doanh thực tế của khách hàng không.
User Acceptance (UAT)
Kiểm thử bởi đối tượng người dùng cuối thực tế. Xác minh sự dễ dùng và đáp ứng đúng quy trình tác nghiệp thường ngày.
Business Acceptance
Kiểm thử bởi các bên liên đới kinh doanh. Xác minh hệ thống có mang lại lợi nhuận, ROI và tuân thủ các quy định tài chính/pháp lý không.
Alpha Testing
Thực hiện tại văn phòng của công ty phát triển phần mềm, bởi người dùng nội bộ (nhưng không phải team Dev). Được kiểm soát chặt chẽ.
Beta Testing
Phát hành phiên bản thử nghiệm ra công chúng (môi trường người dùng thực). Nhận phản hồi để tối ưu trước khi Launch chính thức.
4. Mô hình đánh giá quy trình kiểm thử (TMM)
TMM (Test Maturity Model) được phát triển bởi Viện Công nghệ Illinois. Đây là khuôn khổ để đánh giá và cải tiến các quy trình kiểm thử phần mềm của một tổ chức, từ mức độ hỗn loạn nhất đến mức độ tối ưu, trưởng thành nhất.
4.5. Mức 5: Tối ưu hóa, Ngăn ngừa lỗi và Quản lý chất lượng
- Đây là mức độ cao nhất và lý tưởng nhất.
- Quy trình kiểm thử hoàn toàn nằm trong tầm kiểm soát bằng các công cụ kiểm soát chất lượng thống kê (Statistical Quality Control).
- Ngăn ngừa lỗi (Defect Prevention): Thay vì thụ động tìm lỗi, tổ chức phân tích nguyên nhân gốc rễ từ các dự án trước để ngăn lỗi xảy ra ở dự án mới.
- Liên tục cải tiến, đánh giá công cụ Test Automation và tối ưu hóa chi phí - hiệu năng.
4.4. Mức 4: Quản lý và Đo lường
- Giai đoạn Định lượng (Quantitative). Kiểm thử đã trở thành một ngành khoa học có thể đo đếm được.
- Các chỉ số (Metrics) đo lường chất lượng phần mềm được thiết lập chặt chẽ (ví dụ: Mật độ lỗi, Độ bao phủ code).
- Triển khai quy trình Đánh giá đồng cấp (Peer Reviews) chuyên nghiệp cho mọi tài liệu, source code, và test case.
- Thiết lập môi trường làm việc hợp tác mạnh mẽ, công cụ quản lý vòng đời lỗi (Defect Tracking) tinh vi.
4.3. Mức 3: Tích hợp
- Kiểm thử không còn là giai đoạn độc lập ở cuối dự án, mà được tích hợp hoàn toàn vào toàn bộ vòng đời phát triển phần mềm (SDLC), tiêu biểu là áp dụng V-Model.
- Kiểm thử bắt đầu diễn ra sớm nhất có thể (từ khâu thu thập yêu cầu).
- Hình thành một bộ phận Nhóm Kiểm Thử Độc Lập (Independent Test Group).
- Tổ chức các chương trình đào tạo kỹ năng chuyên sâu và chuẩn hóa nghiệp vụ cho đội ngũ tester.
4.2. Mức 2: Xác định giai đoạn (Phase Definition)
- Bắt đầu có sự phân biệt rõ ràng: Kiểm thử (Testing) là để chứng minh phần mềm chạy được, khác với Gỡ lỗi (Debugging) là sửa lỗi code.
- Quy trình cơ bản bắt đầu được áp dụng: Có lập Kế hoạch kiểm thử (Test Plan).
- Đã định nghĩa các kỹ thuật thiết kế test case căn bản.
- Tuy nhiên, kiểm thử vẫn chủ yếu diễn ra ở giai đoạn cuối của vòng đời dự án (sau khi dev code xong). Vẫn còn rủi ro cao về tiến độ.
4.1. Mức 1: Khởi tạo (Initial)
- Tình trạng hỗn loạn (Ad-hoc). Không có bất kỳ quy trình kiểm thử chuẩn mực nào được định nghĩa hay áp dụng.
- Kiểm thử và Gỡ lỗi (Debugging) bị đánh đồng là một. Chủ yếu là chạy ứng dụng lên, thấy lỗi ở đâu thì sửa ở đó.
- Hoàn toàn không có tài liệu hóa (không test plan, không test case).
- Thiếu tài nguyên, không có đội ngũ kiểm thử chuyên trách. Phụ thuộc hoàn toàn vào kỹ năng cá nhân của lập trình viên. Rủi ro chất lượng sản phẩm cực kỳ cao.
2.371 xem 12 kiến thức 5 đề thi
13.012 lượt xem 21/11/2025
14.896 lượt xem 05/12/2025
15.793 lượt xem 02/12/2025
15.006 lượt xem 05/12/2025
3.165 lượt xem 11/07/2025
2.767 lượt xem 11/07/2025
2.790 lượt xem 11/07/2025
13.190 lượt xem 21/11/2025
11.058 lượt xem 24/09/2025
