Mật độ khuyết tật là gì? Công thức tính toán với Ví dụ

Mật độ khuyết tật là gì?

Mật độ khuyết tật Chỉ số này là số lỗi được xác nhận trong một phần mềm hoặc một mô-đun trong một khoảng thời gian hoạt động hoặc phát triển cụ thể, chia cho kích thước của phần mềm hoặc mô-đun đó. Nó cho phép nhóm quyết định xem một phần mềm đã sẵn sàng để phát hành hay chưa.

Mật độ lỗi được tính trên mỗi nghìn dòng mã, hay còn gọi là KLOC. Vì số lượng được chuẩn hóa theo kích thước, nên một mô-đun lớn với nhiều lỗi và một mô-đun nhỏ với ít lỗi có thể được so sánh trên cùng một thang đo, điều mà việc chỉ đếm lỗi thô không bao giờ cho phép.

Thông số này thường được báo cáo vào cuối chu kỳ thử nghiệm và tracđược phát hành qua từng đợt, vì vậy nó nằm cùng với phần còn lại của... quy trình quản lý khuyết tật trong vòng đời kiểm thử phần mềm.

Cách tính mật độ khuyết tật

Công thức đo mật độ khuyết tật:

Defect Density = Defect count/size of the release

Kích thước của bản phát hành có thể được đo bằng số dòng mã (LOC).

Ba yếu tố quyết định xem con số thu được có ý nghĩa gì hay không:

• Đơn vị kích thước. LOC và KLOC là những đơn vị phổ biến nhất. Điểm chức năng được sử dụng khi các nhóm muốn có một thước đo kích thước không thay đổi theo ngôn ngữ lập trình, và một số nhóm chuẩn hóa theo mô-đun hoặc theo thành phần.
• Những gì được coi là lỗi? Chỉ những lỗi đã được xác nhận mới được đưa vào tử số. Các lỗi trùng lặp, báo cáo bị từ chối và yêu cầu cải tiến phải được loại trừ, nếu không con số sẽ tăng lên mà chất lượng mã không hề thay đổi.
• Cửa sổ đo lường. Các lỗi được phát hiện trong quá trình kiểm thử hệ thống, trong quá trình kiểm tra hồi quyVà sau khi phát hành, nó mô tả những điều khác nhau, vì vậy khoảng thời gian phải được nêu rõ bằng con số.

Ví dụ về mật độ khuyết tật

Giả sử bạn có 3 mô-đun được tích hợp vào sản phẩm phần mềm của mình. Mỗi mô-đun có số lượng lỗi được phát hiện như sau:

• Mô-đun 1 = 10 lỗi
• Mô-đun 2 = 20 lỗi
• Mô-đun 3 = 10 lỗi

Tổng số lỗi = 10 + 20 + 10 = 40

Tổng số dòng mã cho mỗi mô-đun là:

• Mô-đun 1 = 1000 LỘC
• Mô-đun 2 = 1500 LỘC
• Mô-đun 3 = 500 LỘC

Tổng dòng Code = 1000+1500+500 = 3000

Mật độ khuyết tật được tính như sau:

Defect Density = 40/3000 = 0.013333 defects/loc = 13.333 defects/Kloc

Việc áp dụng cùng một phép tính cho từng mô-đun sẽ hữu ích hơn so với con số tổng hợp, như biểu đồ bên dưới cho thấy: Mô-đun 2 có 20 lỗi trong 1500 dòng mã và Mô-đun 3 có 10 lỗi trong chỉ 500 dòng mã, do đó Mô-đun 3 có mật độ lỗi cao hơn và rủi ro hơn mặc dù báo cáo ít lỗi hơn.

Tiêu chuẩn về mật độ khuyết tật

Không có tiêu chuẩn cố định nào cho Mật độ Khuyết tật. Các nghiên cứu cho thấy rằng một khuyết tật Tỷ lệ lỗi trên 1000 dòng mã thường được coi là dấu hiệu của chất lượng dự án tốt, và con số đó là quy tắc kinh nghiệm được trích dẫn rộng rãi nhất trong ngành.

Kỳ vọng thay đổi tùy thuộc vào lĩnh vực. Phần mềm quan trọng về an toàn và được quản lý chặt chẽ, chẳng hạn như phần mềm hàng không và thiết bị y tế, phải đáp ứng mục tiêu có tỷ lệ lỗi thấp hơn một lỗi trên mỗi KLOC, trong khi các ứng dụng kinh doanh thông thường thường xuyên đạt tỷ lệ cao hơn. Vì các quy tắc đếm, đơn vị kích thước và độ sâu kiểm thử đều khác nhau giữa các tổ chức, nên một tiêu chuẩn được lấy từ một nghiên cứu đã công bố chỉ có thể so sánh với một dự án đo lường theo cùng một cách. Do đó, việc sử dụng thực tiễn của chỉ số này là nội bộ: so sánh một phiên bản phát hành với phiên bản trước đó của cùng một sản phẩm, được đo lường theo cùng một cách.

Các yếu tố ảnh hưởng đến mật độ lỗi

Cùng một cơ sở mã có thể tạo ra các số liệu về mật độ lỗi rất khác nhau tùy thuộc vào các yếu tố sau:

• Code sự phức tạp. Logic lồng nhau sâu và cao độ phức tạp chu trình Tạo ra nhiều lỗi hơn trên mỗi dòng so với mã lệnh thông thường.
• Loại khuyết tật được xem xét. Chỉ tính các lỗi về chức năng, hoặc bao gồm cả khả năng sử dụng, tài liệu và... phi chức năng Những phát hiện này làm thay đổi đáng kể tử số.
• Khoảng thời gian được xem xét. Con số đo được trong chu kỳ thử nghiệm hai tuần không thể so sánh với con số đo được trong sáu tháng sử dụng thực tế.
• Kỹ năng lập trình viên và kiểm thử viên. Các nhà phát triển giàu kinh nghiệm thường ít gây ra lỗi hơn, trong khi những người kiểm thử giàu kinh nghiệm lại tìm ra nhiều lỗi hơn, do đó hai yếu tố này kéo chỉ số theo hướng ngược nhau.
• Kiểm thử phạm vi phủ sóng. Những khuyết điểm không được tìm kiếm sẽ không bao giờ được tính đến, vì vậy Kiểm tra vùng phủ sóng Âm thầm giới hạn mức độ cao tối đa mà mật độ đo được có thể đạt tới.

Mật độ lỗi so với các chỉ số lỗi khác

Mật độ lỗi trả lời một câu hỏi: các lỗi đã biết tập trung ở mức độ nào. Ba chỉ số bổ trợ trả lời những câu hỏi mà chỉ số mật độ lỗi không thể trả lời, và hầu hết các nhóm đều báo cáo chúng cùng nhau.

Khi đọc cả bốn yếu tố cùng nhau, ta sẽ có một bức tranh toàn diện hơn: Mật độ lỗi thấp đi kèm với Tỷ lệ rò rỉ lỗi cao cho thấy việc kiểm thử còn sơ sài chứ không phải là mã nguồn sạch, và đó chính xác là sự hiểu sai mà phần tiếp theo cảnh báo.

Ưu điểm của mật độ khuyết tật

Sau đây là những ưu điểm của Mật độ khuyết tật:

• Nó giúp đo lường hiệu quả của việc kiểm tra.
• Nó giúp phân biệt sự tập trung lỗi giữa các thành phần và các mô-đun phần mềm.
• Nó rất hữu ích trong việc xác định những lĩnh vực cần sửa chữa hoặc cải thiện.
• Nó hữu ích trong việc chỉ ra các thành phần có rủi ro cao, điều này ảnh hưởng trực tiếp đến... thử nghiệm dựa trên rủi ro.
• Nó giúp xác định nhu cầu đào tạo của các nguồn lực khác nhau.
• Điều này có thể hữu ích trong việc ước tính nỗ lực kiểm thử và sửa chữa do các lỗi gây ra.
• Nó có thể ước tính các lỗi còn lại trong phần mềm.
• Trước khi phát hành, việc này giúp xác định xem các thử nghiệm đã thực hiện cho đến nay có đủ hay không.
• Nó tạo ra một cơ sở dữ liệu lịch sử để so sánh với các phiên bản phát hành sau này.

Những hạn chế của mật độ khuyết tật

Chỉ số này dễ tính toán nhưng cũng dễ bị hiểu sai. Những hạn chế sau đây sẽ quyết định mức độ quan trọng của nó trong quyết định phát hành:

• Những khuyết điểm không được phát hiện sẽ không thể nhìn thấy. Tử số chỉ chứa các lỗi mà quá trình kiểm tra thực sự phát hiện ra, vì vậy một mô-đun được kiểm tra sơ sài sẽ cho ra con số có vẻ khả quan.
• Mức độ nghiêm trọng bị bỏ qua. Một lỗi làm ảnh hưởng đến quá trình thanh toán và một lỗi nhỏ về căn chỉnh hình thức đều được tính như nhau, đó là lý do tại sao cần có một đánh giá dựa trên mức độ nghiêm trọng.
• Định nghĩa về khuyết điểm có thể khác nhau. Hai nhóm có cách tính toán khác nhau sẽ cho ra những con số không thể so sánh được, ngay cả trong cùng một tổ chức.
• Số dòng mã là một thước đo kích thước không chính xác. Mã lệnh rườm rà làm giảm mật độ mà không cải thiện được gì, và đơn vị này không thể so sánh được giữa các ngôn ngữ lập trình khác nhau.
• Chỉ số này có thể bị thao túng. Việc loại bỏ các báo cáo ở mức ranh giới hoặc thổi phồng số lượng dòng đều giúp cải thiện con số mà không cải thiện chất lượng sản phẩm.

Điều này không có nghĩa là Mật độ Lỗi trở nên vô dụng. Nó chỉ đơn giản là một chỉ báo xu hướng cho một sản phẩm được đo lường một cách nhất quán, chứ không phải là một điểm số để so sánh các nhóm với nhau.

Cách giảm mật độ lỗi

Việc giảm mật độ lỗi thực sự, chứ không chỉ trên lý thuyết, có nghĩa là ngăn ngừa lỗi từ sớm và tìm ra những lỗi còn lại trước khi phát hành. Các phương pháp dưới đây là những phương pháp thường xuyên được nhắc đến trong các hướng dẫn đã được công bố:

• Tiến hành thử nghiệm sớm hơn. Việc đưa người kiểm thử vào giai đoạn xác định yêu cầu và thiết kế giúp phát hiện sự mơ hồ trước khi nó trở thành mã lập trình, đây cũng là giai đoạn mà việc loại bỏ lỗi có chi phí thấp nhất.
• RevXem mã trước khi hợp nhất. Đánh giá ngang hàng giúp phát hiện các lỗi logic, hiểu sai yêu cầu và các khiếm khuyết thiết kế mà không ai khác có thể nhận ra. kiểm tra đơn vị đã được viết ra để tìm kiếm.
• Tự động hóa bộ kiểm thử hồi quy. Thực hiện kiểm tra trên mọi commit. tích hợp liên tục Ngăn chặn các lỗi cũ tái xuất hiện trong khi đang viết mã mới.
• Hãy viết các bài kiểm tra trước. Hướng phát triển thử nghiệm buộc mỗi hành vi phải được xác định rõ trước khi được thực hiện, và kiểm tra đột biến Từ đó có thể xác nhận xem các kết quả kiểm tra có thực sự khẳng định điều gì đó hay không.
• Sử dụng phương pháp phân tích tĩnh. Quét mã tự động sẽ phát hiện các lỗi truy cập con trỏ null, rò rỉ tài nguyên và các điểm nóng về độ phức tạp trước khi bất kỳ bài kiểm tra nào được thực thi.
• Tái cấu trúc các mô-đun phức tạp. Khi Defect Density đã xác định được các thành phần gây lỗi nghiêm trọng nhất, việc chia nhỏ và đơn giản hóa chúng thường giúp giảm cả độ phức tạp và số lượng lỗi.
• Đưa các sản phẩm lỗi trở lại quy trình. Phân tích nguyên nhân gốc rễ trong các buổi đánh giá sau sự kiện giúp biến các lỗi riêng lẻ thành các giải pháp khắc phục quy trình thay vì chỉ là các bản vá lỗi đơn lẻ.

Tracphát hành ked kèm theo phát hành song song các kỹ thuật kiểm thử phần mềm Với dữ liệu về phạm vi bao phủ, Mật độ Lỗi trở thành một hệ thống cảnh báo sớm thay vì một bảng điểm.

Câu Hỏi Thường Gặp