Lý thuyết Kiểm thử phần mềm: Các thuật ngữ quan trọng
Tìm hiểu chi tiết cách phân biệt Error, Bug, Defect, Fault, Failure và các khái niệm Verification, Validation, Static Testing, Dynamic Testing và chỉ số RPN.
Kiểm thử phần mềmPhân biệt Bug và DefectVerification vs ValidationStatic vs Dynamic TestingChỉ số RPNFMEA trong testingRBT là gì
Các thuật ngữ cơ bản
1.1. Phân biệt Error, Bug, Defect, Fault và Failure
Trong kỹ nghệ phần mềm, sự nhầm lẫn giữa các thuật ngữ chỉ sự sai sót là vô cùng phổ biến. Việc làm rõ ranh giới giữa chúng giúp quy trình phát triển, báo cáo và sửa chữa trở nên chuyên nghiệp, minh bạch và chính xác hơn.
Mỗi thuật ngữ đại diện cho một giai đoạn cụ thể trong vòng đời của một vấn đề phần mềm, bắt nguồn từ tư duy của con người cho đến khi tác động trực tiếp đến trải nghiệm của khách hàng cuối cùng. Hãy cùng đi sâu vào chuỗi nguyên nhân - kết quả này.
Lập trình viên
Mệt mỏi, hiểu sai logic
Mã nguồn
Chứa dòng lệnh sai
Hệ thống
Trạng thái lỗi tiềm ẩn
Người dùng
Hệ thống sập, sai kết quả
Error (Lỗi / Nhầm lẫn)
- Bản chất: Là hành động sai lầm của con người. Con người luôn có thể mắc sai lầm.
- Chủ thể: Lập trình viên, nhà phân tích nghiệp vụ, hoặc người thiết kế hệ thống.
- Nguyên nhân cốt lõi: Do thiếu kinh nghiệm, mệt mỏi, áp lực thời gian, hiểu sai yêu cầu tài liệu, hoặc cấu hình sai môi trường.
- Kết quả: Tạo ra những đoạn mã sai logic, thiết kế sai luồng dữ liệu hoặc phân tích thiếu sót.
- Ví dụ thực tế: Lập trình viên sử dụng dấu
<thay vì dấu<=trong vòng lặp do sơ suất đánh máy.
Defect / Bug (Khuyết tật)
- Bản chất: Là biểu hiện vật lý của Error bên trong phần mềm. Sự sai lệch giữa kết quả thực tế và kết quả mong đợi.
- Hoàn cảnh phát hiện: Được tìm thấy bởi Tester (Kỹ sư kiểm thử) trong quá trình thực thi kiểm thử trước khi phần mềm được phát hành.
- Thuật ngữ: "Bug" là từ lóng phổ biến, không chính thức. "Defect" là thuật ngữ kỹ thuật, trang trọng hơn dùng trong các tài liệu báo cáo.
- Đặc điểm: Một phần mềm có thể chứa hàng ngàn Defect. Việc tìm ra chúng là trách nhiệm của đội ngũ QA/QC.
- Ví dụ thực tế: Chức năng đăng nhập cho phép người dùng nhập mật khẩu trống mà vẫn vào được hệ thống.
Fault (Lỗi hệ thống)
- Bản chất: Là một trạng thái không hợp lệ của phần mềm. Nó là hệ quả trực tiếp do Defect gây ra.
- Tính chất ẩn: Fault có thể nằm im lìm (dormant) trong mã nguồn mà không bao giờ gây hại nếu đoạn mã đó không bao giờ được thực thi.
- Sự kích hoạt: Một Fault chỉ trở nên nguy hiểm khi các điều kiện cụ thể được đáp ứng, kích hoạt đoạn code chứa khuyết tật.
- Phân loại: Có thể do Fault về thuật toán (tính toán sai), Fault về thời gian (timeout), Fault về tài nguyên (tràn bộ nhớ).
- Ví dụ thực tế: Hàm tính toán lãi suất chứa một Defect chia cho không. Chừng nào biến số chưa bằng không, Fault vẫn nằm im. Khi biến bằng 0, Fault được kích hoạt.
Failure (Thất bại / Sự cố)
- Bản chất: Là việc hệ thống không thể thực hiện chức năng yêu cầu của nó trong phạm vi hiệu suất đã chỉ định.
- Chủ thể phát hiện: Xảy ra khi phần mềm đã đến tay khách hàng (End-user) trong môi trường thực tế (Production).
- Hậu quả: Cực kỳ nghiêm trọng. Gây ảnh hưởng trực tiếp đến uy tín, tài chính, trải nghiệm của người dùng và doanh nghiệp.
- Nguyên nhân: Một Failure xuất hiện khi một đoạn mã chứa Fault được thực thi trong môi trường thực. Không phải Fault nào cũng dẫn đến Failure.
- Ví dụ thực tế: Ứng dụng ngân hàng sập hoàn toàn (Crash) khi khách hàng đang chuyển số tiền lớn vào ngày cuối tháng.
Chuỗi nguyên nhân - hệ quả cơ bản:
1.2. Xác minh (Verification) và Thẩm định (Validation)
Verification và Validation (thường được gọi tắt là V&V) là hai khái niệm nền tảng trong quy trình Đảm bảo Chất lượng Phần mềm (SQA). Mặc dù thường được nhắc đến cùng nhau, chúng đóng vai trò hoàn toàn khác biệt và được thực hiện ở những giai đoạn khác nhau trong vòng đời phát triển phần mềm (SDLC).
Nắm vững sự khác biệt giữa hai quá trình này giúp tổ chức xây dựng một phần mềm không chỉ đáp ứng đúng thiết kế kỹ thuật mà còn giải quyết đúng nỗi đau của khách hàng. Hãy coi Verification là việc làm mọi thứ đúng quy trình, còn Validation là việc đảm bảo quy trình đó hướng tới đúng mục tiêu.
Xác minh (Verification)
"Are we building the product right?"
(Chúng ta xây dựng sản phẩm đúng cách chứ?)
- Mục tiêu: Đảm bảo phần mềm được xây dựng tuân thủ chính xác các đặc tả yêu cầu, thiết kế kiến trúc và tiêu chuẩn đã đề ra từ đầu. Nó tập trung vào quy trình và tài liệu.
- Thực thi mã nguồn: KHÔNG thực thi (chạy) phần mềm. Quá trình này hoàn toàn tĩnh.
- Đối tượng kiểm tra: Tài liệu yêu cầu (BRD, SRS), bản vẽ thiết kế kiến trúc, mô hình dữ liệu, tài liệu thiết kế UI/UX, và mã nguồn thô (source code).
- Hoạt động chính: Review (Đánh giá), Walkthroughs (Rà soát), Inspection (Thanh tra code), Desk-checking (Kiểm tra tại bàn).
- Thời điểm: Thực hiện rất sớm, ngay từ giai đoạn đầu tiên của vòng đời phát triển phần mềm. Giúp tiết kiệm chi phí lớn vì phát hiện lỗi sớm.
- Lỗi phát hiện: Thiếu sót trong yêu cầu, logic sai lầm trên giấy tờ, vi phạm quy tắc lập trình chuẩn.
Thẩm định (Validation)
"Are we building the right product?"
(Chúng ta xây dựng đúng sản phẩm chứ?)
- Mục tiêu: Đảm bảo phần mềm được xây dựng cuối cùng giải quyết đúng nhu cầu thực tế của người dùng và hoạt động ổn định trong môi trường thực. Nó tập trung vào kết quả cuối cùng.
- Thực thi mã nguồn: CÓ thực thi phần mềm. Máy tính phải biên dịch và chạy ứng dụng.
- Đối tượng kiểm tra: Các module phần mềm đã hoàn thiện, hệ thống tích hợp nguyên vẹn, và sản phẩm cuối cùng.
- Hoạt động chính: Kiểm thử đơn vị (Unit Testing), Kiểm thử tích hợp (Integration), Kiểm thử hệ thống (System Testing), Kiểm thử chấp nhận (UAT).
- Thời điểm: Thực hiện muộn hơn, khi mã nguồn đã được viết và có thể chạy được. Sửa lỗi ở giai đoạn này thường tốn kém hơn nhiều.
- Lỗi phát hiện: Chức năng hoạt động sai bối cảnh, giao diện không hiển thị đúng, hiệu năng chậm chạp, hệ thống bị crash.
Kết luận quan trọng:
Một sản phẩm có thể vượt qua toàn bộ quá trình Verification (Làm đúng 100% theo tài liệu thiết kế ban đầu) nhưng vẫn thất bại ở bước Validation (Sản phẩm làm ra không giải quyết được vấn đề của khách hàng do ban đầu thu thập sai yêu cầu).
Đó là lý do bắt buộc phải thực hiện song song cả hai quá trình này.
1.3. Kiểm thử tĩnh (Static Testing) và Kiểm thử động (Dynamic Testing)
Hai kỹ thuật này song hành cùng Verification và Validation. Hiểu đơn giản, Static Testing là cách thức thực hiện Verification, còn Dynamic Testing là cách thức thực hiện Validation. Sự kết hợp giữa hai phương pháp này tạo ra một chiến lược kiểm thử toàn diện, đảm bảo chất lượng phần mềm từ những bản phác thảo đầu tiên cho đến khi sản phẩm sẵn sàng triển khai.
Nhiều tổ chức thường bỏ qua Kiểm thử tĩnh vì cho rằng nó tốn thời gian. Tuy nhiên, các nghiên cứu cho thấy việc sửa một lỗi phát hiện trong Kiểm thử tĩnh rẻ hơn gấp 10 lần đến 100 lần so với việc sửa chính lỗi đó khi bị phát hiện bởi Kiểm thử động ở giai đoạn cuối.
Kiểm thử tĩnh
(Static Testing)
- Định nghĩa: Quá trình đánh giá, phân tích phần mềm mà không cần biên dịch hay thực thi mã nguồn. Kiểm tra bằng mắt hoặc công cụ tự động phân tích cú pháp.
- Trọng tâm: Tìm kiếm nguyên nhân gây ra lỗi (Defects/Faults), ngăn chặn lỗi xảy ra trong tương lai. Kiểm tra xem mã có tuân thủ các chuẩn mực mã hóa không.
- Công cụ hỗ trợ: Các công cụ phân tích SonarQube, ESLint, Checkstyle... giúp quét mã nguồn để tìm các mẫu code xấu (code smells), biến chưa khai báo, vòng lặp vô hạn tiềm ẩn.
- Chi phí và Thời gian: Tốn kém thời gian ban đầu để rà soát, nhưng vô cùng tiết kiệm chi phí về lâu dài do phát hiện lỗi sớm trước khi hệ thống được xây dựng phức tạp.
- Ưu điểm nổi bật: Có thể bao phủ 100% dòng mã lệnh. Không cần môi trường kiểm thử phức tạp. Tăng cường kỹ năng cho toàn bộ team thông qua hoạt động Review code chéo nhau.
Kiểm thử động
(Dynamic Testing)
- Định nghĩa: Quá trình kiểm tra bằng cách cung cấp dữ liệu đầu vào, chạy phần mềm và so sánh kết quả đầu ra thực tế với kết quả mong đợi.
- Trọng tâm: Tìm kiếm sự thất bại của hệ thống (Failures/Bugs). Quan sát trực tiếp hành vi thực tế của phần mềm khi hoạt động.
- Công cụ hỗ trợ: Selenium, JMeter, Postman, JUnit, TestNG... Các công cụ này tương tác trực tiếp với giao diện người dùng hoặc API của hệ thống đang chạy.
- Chi phí và Thời gian: Thực hiện nhanh chóng nếu đã có kịch bản tốt, nhưng chi phí khắc phục lỗi (Fix cost) là rất cao vì phải quay lại sửa code, biên dịch, và deploy lại từ đầu.
- Đặc điểm môi trường: Đòi hỏi môi trường kiểm thử chuyên biệt (Test Environment) có cài đặt cơ sở dữ liệu, máy chủ, mạng lưới tương tự như môi trường thực tế của người dùng.
Mối quan hệ tương hỗ: Kiểm thử tĩnh tìm nguyên nhân để phòng ngừa. Kiểm thử động tìm triệu chứng để chữa trị. Bạn không thể chỉ dùng một phương pháp. Static Testing làm sạch mã nguồn, dọn đường cho Dynamic Testing chạy mượt mà và tập trung vào các lỗi logic phức tạp thay vì bị kẹt lại bởi các lỗi cú pháp cơ bản.
1.4. Kiểm thử dựa trên rủi ro (Risk-based Testing) và Phân tích FMEA
Không bao giờ có đủ thời gian và ngân sách để kiểm thử toàn diện mọi ngóc ngách của một hệ thống phần mềm (Nguyên lý Exhaustive testing is impossible). Do đó, chúng ta cần phải lựa chọn thông minh những gì nên ưu tiên kiểm thử trước. Đó là lúc Kiểm thử dựa trên rủi ro ra đời.
Kiểm thử dựa trên rủi ro sử dụng tư duy phòng ngừa, đánh giá tính chất nghiêm trọng của các thành phần phần mềm để phân bổ nguồn lực Tester một cách hợp lý. Để định lượng được rủi ro một cách khoa học, kỹ thuật FMEA (Failure Mode and Effects Analysis) là một công cụ phân tích đắc lực.
Khái niệm RBT (Risk-Based Testing)
Kiểm thử dựa trên rủi ro là một phương pháp tổ chức và quản lý quá trình kiểm thử phần mềm. Trong đó, các tính năng, module, hoặc khu vực của phần mềm được ưu tiên thiết kế kịch bản test và thực thi dựa trên mức độ rủi ro của chúng đối với hệ thống kinh doanh.
Các bước triển khai cơ bản:
Nhận diện
Liệt kê mọi rủi ro có thể xảy ra (Bảo mật, hiệu năng, logic chức năng, gián đoạn giao dịch).
Đánh giá
Phân loại từng rủi ro theo mức độ nghiêm trọng và xác suất xảy ra (Dùng ma trận rủi ro).
Lên kế hoạch
Dồn 80% thời gian test vào các module có rủi ro Cao. Các tính năng phụ có thể chỉ test lướt qua.
Kiểm soát
Theo dõi liên tục, theo dõi biến động rủi ro để điều chỉnh kế hoạch test cho phù hợp.
Phân tích FMEA (Failure Mode and Effects Analysis)
FMEA là một quy trình mang tính hệ thống, chủ động đánh giá một quá trình để xác định vị trí và cách thức mà nó có thể thất bại. Thuật ngữ này có vẻ học thuật, nhưng cốt lõi của nó là việc trả lời câu hỏi: "Điều tồi tệ nhất có thể xảy ra ở chức năng này là gì, và nó gây hại đến mức nào?"
Công thức chỉ số ưu tiên rủi ro (RPN)
Điểm RPN càng cao, rủi ro càng nghiêm trọng và cần ưu tiên kiểm thử ngay lập tức.
Severity (Mức độ nghiêm trọng)
Đánh giá mức độ tàn phá, hậu quả để lại nếu lỗi xảy ra đối với hệ thống, khách hàng hoặc kinh doanh. Chỉ số này thường do Business Analyst hoặc Khách hàng đánh giá.
- 1-3: Nhẹ, lỗi giao diện nhỏ, không ảnh hưởng vận hành.
- 4-6: Vừa, gây khó chịu cho người dùng, có cách làm thay thế (workaround).
- 7-9: Nặng, mất dữ liệu một phần, chức năng chính bị liệt.
- 10: Thảm họa, sập hệ thống toàn phần, vi phạm pháp luật, lộ dữ liệu nhạy cảm.
Occurrence (Tần suất xuất hiện)
Xác suất mà nguyên nhân gốc rễ (nguyên nhân gây ra khuyết tật) sẽ xảy ra trong thực tế môi trường vận hành. Thường do Lập trình viên và System Admin đánh giá.
- 1-3: Cực kỳ hiếm, gần như không thể xảy ra.
- 4-6: Thỉnh thoảng, xảy ra với một vài tình huống người dùng đặc biệt.
- 7-9: Thường xuyên, lỗi phổ biến, xảy ra hàng ngày.
- 10: Chắc chắn xảy ra mỗi khi người dùng gọi đến chức năng này.
Detection (Khả năng phát hiện)
Khả năng các quy trình kiểm thử hiện tại (tự động hoặc thủ công) có thể bắt được lỗi này TRƯỚC KHI sản phẩm đến tay khách hàng. Thường do QA/Tester đánh giá.
- 1-2: Chắc chắn phát hiện được (Có tool automation báo cáo ngay lập tức).
- 3-5: Khả năng cao phát hiện được thông qua Test hồi quy thủ công.
- 6-8: Khó phát hiện, lỗi ẩn sâu, chỉ lòi ra trong các luồng biên (edge cases).
- 9-10: Không thể phát hiện, hoàn toàn mù mờ, không có phương pháp test bắt lỗi này.
Ví dụ thực tiễn cách sử dụng RPN:
Giả sử bạn có 2 tính năng cần kiểm thử, nhưng chỉ còn 1 ngày trước thời hạn phát hành:
-
Tính năng A (Sai màu nút bấm): Mức độ nghiêm trọng thấp (S=2), tần suất xuất hiện mọi lúc (O=10), cực dễ phát hiện (D=1).
RPN = 2 x 10 x 1 = 20 -
Tính năng B (Thanh toán bị treo khi thẻ hết hạn): Mức độ nghiêm trọng rất cao (S=9), thỉnh thoảng thẻ mới hết hạn (O=5), khó phát hiện vì không có tài khoản ngân hàng thực tế để test giả lập (D=8).
RPN = 9 x 5 x 8 = 360
Kết luận hành động: RPN của B (360) cao vượt trội so với A (20). Toàn bộ đội ngũ Tester phải dồn lực lượng viết kịch bản test kỹ càng cho Tính năng B, tìm mọi cách mượn thẻ thực tế để xác minh. Tính năng A có thể chấp nhận bỏ qua hoặc test sơ lược.
2.371 xem 12 kiến thức 5 đề thi
21.150 lượt xem 11/04/2026
21.100 lượt xem 11/04/2026
20.921 lượt xem 11/04/2026
20.973 lượt xem 11/04/2026
21.038 lượt xem 11/04/2026
21.068 lượt xem 11/04/2026
20.990 lượt xem 11/04/2026
21.011 lượt xem 11/04/2026
21.091 lượt xem 11/04/2026
