Phân Loại Lỗi Là Gì?
Phân loại lỗi – Defect Taxonomies là một hệ thống phân loại được sử dụng để phân loại và tổ chức các lỗi hoặc khuyết điểm trong quá trình kiểm thử phần mềm. Nó giúp tổ chức các lỗi theo các danh mục cụ thể, giúp kiểm thử viên và nhóm phát triển hiểu rõ hơn về các vấn đề có thể xảy ra trong phần mềm và cách xử lý chúng. Phân loại lỗi cũng có thể giúp ích trong việc báo cáo và phân tích các vấn đề trong quá trình phát triển và kiểm thử.
Cách Phân Loại Lỗi Phổ Biến
Phân loại lỗi có thể dựa trên IEEE 1044 Standard for Software Productivity Metrics, CMMI (Capability Maturity Model Integration) và các hệ thống tuỳ chỉnh được xây dựng dựa trên nhu cầu cụ thể của tổ chức phát triển phần mềm.
Dưới đây là cách phân loại phổ biến được đề cập đến trong cuốn sách “Managing the Testing Process” của Rex.
| No. | Categories | Subcategories | Description |
|---|---|---|---|
| Functional | Specification | Đặc tả chức năng trong tài liệu đặc tả hoặc trong những tài liệu khác bị sai. | |
| Function | Đặc tả đúng nhưng việc thực hiện nó sai. | ||
| Test | Sai sót trong dữ liệu kiểm thử, thiết kế kiểm thử, thông số kỹ thuật kiểm thử hoặc một nơi nào khác. | ||
| System | Internal Interface | Giao tiếp hệ thống nội bộ không thành công; nói cách khác, có một vấn đề tích hợp thuộc loại nào đó bên trong đối tượng kiểm thử. | |
| Hardware Devices | Phần cứng của hệ thống hoặc máy chủ lưu trữ hệ thống bị lỗi | ||
| Operating System | Hệ điều hành bên ngoài đối tượng kiểm thử bị lỗi | ||
| Software Architecture | Một số giả định thiết kế cơ bản tỏ ra không hợp lệ, chẳng hạn như giả định rằng dữ liệu có thể được di chuyển từ bảng này sang bảng khác hoặc qua một số mạng trong một khoảng thời gian không đổi. | ||
| Resource Management | Các giả định thiết kế là ổn, nhưng một số việc triển khai giả định là sai. Ví dụ, thiết kế của các bảng dữ liệu gây ra độ trễ. | ||
| Process | Arithmetic | Phần mềm tính toán sai. Điều này không có nghĩa là chỉ toán học cơ bản; nó cũng có thể bao gồm các chức năng phân tích số hoặc kế toán tinh vi, bao gồm các sự cố xảy ra do các vấn đề về làm tròn và độ chính xác. | |
| Initialization | Một thao tác không thành công trong lần sử dụng đầu tiên, khi không có dữ liệu trong danh sách, v.v.. | ||
| Control or Sequence | Một hành động xảy ra sai thời điểm hoặc sai lý do, chẳng hạn như nhìn màn hình hoặc fields theo thứ tự sai. | ||
| Static Logic | Các ranh giới được xác định sai, các lớp tương đương không bao gồm các phần tử đúng và loại trừ các phần tử sai, v.v. | ||
| Other | Đã xảy ra lỗi xử lý hoặc luồng điều khiển không phù hợp với các danh mục trước đó. | ||
| Data | Type | Loại dữ liệu sai, dù sử dụng loại dữ liệu tích hợp sẵn hay do người dùng xác định. | |
| Structure | Cấu trúc hoặc loại dữ liệu phức tạp không hợp lệ hoặc được sử dụng không phù hợp. | ||
| Initial Value | Giá trị khởi tạo của phần tử dữ liệu không chính xác. Chẳng hạn như danh sách số lượng cần mua mặc định là 0 thay vì 1. | ||
| Other | Xảy ra lỗi liên quan đến dữ liệu không khớp với các nhóm trước đó. | ||
| Code | Áp dụng cho một số lỗi đánh máy đơn giản, lỗi chính tả, lỗi văn phong hoặc lỗi mã hóa khác xảy ra và dẫn đến lỗi. | ||
| Documentation | Áp dụng cho các tình huống trong đó tài liệu cho biết hệ thống thực hiện X với điều kiện Y, nhưng thay vào đó, hệ thống thực hiện Z – một hành động không hợp lệ. | ||
| Standards | Áp dụng cho các tình huống trong đó hệ thống không đáp ứng các tiêu chuẩn hoặc quy định của ngành, chính phủ hoặc nhà cung cấp hoặc tuân theo các tiêu chuẩn mã hóa hoặc giao diện người dùng hoặc tuân thủ các quy ước đặt tên, v.v.. | ||
| Other | Đã biết nguyên nhân gốc rễ, nhưng không phù hợp với bất kỳ loại nào trước đó, điều này sẽ hiếm gặp nếu đây là một phân loại hữu ích. | ||
| Housekeeping | Duplicate | Hai báo cáo lỗi mô tả cùng một lỗi. | |
| Not a Problem | Hành vi được ghi nhận là đúng. Báo cáo phát sinh từ sự hiểu lầm của người thử nghiệm về hành vi đúng. Tình huống này khác với lỗi thử nghiệm vì điều này xảy ra trong quá trình thực hiện thử nghiệm và là vấn đề diễn giải kết quả thực tế. | ||
| Bad Unit | Lỗi này là một vấn đề thực sự, nhưng nó phát sinh từ một lỗi phần cứng ngẫu nhiên khó xảy ra trong môi trường sản xuất. | ||
| Root Cause Needed | Áp dụng khi lỗi được xác nhận là đã đóng bằng kiểm thử nhưng không có ai trong quá trình phát triển cung cấp nguyên nhân gốc rễ. | ||
| Unknown | Không ai biết cái gì bị hỏng. Lý tưởng nhất là điều này áp dụng cho một số ít báo cáo, thường là khi một lỗi không liên tục không xuất hiện trong một thời gian dài, dẫn đến kết luận rằng một số thay đổi khác đã sửa lỗi như một tác dụng phụ. |
Lưu ý rằng cách phân loại này tập trung vào nguyên nhân gốc rễ, ít nhất là theo nghĩa cuối cùng điều gì đã được chứng minh là sai trong mã gây ra lỗi. Bạn cũng có thể có một phân loại “nguyên nhân gốc của quy trình” để chỉ ra lỗi đã được đưa ra ở giai đoạn nào trong quá trình phát triển. Lưu ý rằng cách phân loại như vậy sẽ vô ích đối với chúng ta trong việc thiết kế các bài kiểm tra. Ngay cả việc phân loại tập trung vào nguyên nhân gốc rễ cũng có thể hơi khó sử dụng cho mục đích thiết kế thử nghiệm.
Mục Đích Của Việc Sử Dụng Phân Loại Lỗi
Việc sử dụng Defect Taxonomies giúp tăng cường quản lý chất lượng phần mềm bằng cách:
- Giúp xác định và phân loại các vấn đề phần mềm một cách rõ ràng.
- Tạo điều kiện thuận lợi để báo cáo và theo dõi lỗi.
- Cải thiện việc giao tiếp giữa các thành viên trong dự án phát triển và kiểm thử.
- Hỗ trợ việc tối ưu hóa quy trình kiểm thử và sửa lỗi.
- Cung cấp dữ liệu thống kê về lỗi để giúp quản lý ra quyết định.