Tỷ lệ lỗi nào tôi có thể mong đợi trong một codebase C++ được viết cho một bộ xử lý nhúng (DSP), vì không có kiểm thử đơn vị, không có đánh giá mã, không phân tích mã tĩnh và biên dịch dự án tạo ra khoảng 1500 cảnh báo. 5 lỗi/100 dòng mã có phải là ước tính hợp lý không?Tỷ lệ lỗi phần mềm nhúng
Mặc dù sự hoài nghi về tính hợp lệ của bất kỳ ước tính nào trong trường hợp này, tôi đã tìm thấy một số thống kê có thể có liên quan.
Trong this article, tác giả trích dẫn số liệu từ "một cơ thể lớn các nghiên cứu thực nghiệm", được xuất bản trong Software Assessments, Benchmarks, and Best Practices (Jones, 2000). Tại số SIE CMM Level 1, có vẻ như cấp độ của mã này, người ta có thể mong đợi tỷ lệ lỗi là 0,75 trên mỗi function point. Tôi sẽ để nó cho bạn để xác định các điểm chức năng và LOC có thể liên quan đến mã của bạn như thế nào - có thể bạn sẽ cần metrics tool để thực hiện phân tích đó.
Steve McConnell trong mã hoàn thành cites a study trong 11 dự án được phát triển bởi cùng một nhóm, 5 dự án không có đánh giá mã, 6 có đánh giá mã. Tỷ lệ lỗi cho mã không được xem xét là 4,5 trên 100 LOC và cho đánh giá là 0,82. Vì vậy, trên cơ sở đó, ước tính của bạn có vẻ công bằng khi không có bất kỳ thông tin nào khác. Tuy nhiên tôi phải giả định một mức độ chuyên nghiệp trong nhóm này (chỉ từ thực tế là họ cảm thấy cần phải thực hiện nghiên cứu), và rằng họ sẽ có ít nhất tham dự vào các cảnh báo; tỷ lệ lỗi của bạn có thể là cao hơn nhiều.
Điểm về cảnh báo là một số là lành tính, và một số là lỗi (tức là sẽ dẫn đến hành vi không mong muốn của phần mềm), nếu bạn bỏ qua chúng với giả định rằng chúng đều lành tính, bạn sẽ giới thiệu lỗi. Hơn nữa một số sẽ trở thành lỗi khi bảo trì khi các điều kiện khác thay đổi, nhưng nếu bạn đã chọn chấp nhận cảnh báo, bạn không được bảo vệ chống lại việc giới thiệu các lỗi như vậy.
Cảm ơn rất nhiều cho câu trả lời được nghiên cứu kỹ. Tôi phải thừa nhận hơn tôi chưa bao giờ nghe nói về các điểm chức năng trước đây. – geschema
Điều đó cũng tùy thuộc vào người đã viết mã (cấp độ kinh nghiệm) và cơ sở mã lớn như thế nào.
Tôi sẽ coi tất cả các cảnh báo là lỗi.
Bạn nhận được bao nhiêu lỗi khi chạy công cụ phân tích tĩnh trên mã?
EDIT
Chạy cccc và kiểm tra độ phức tạp chu kỳ của mccabe. Nó sẽ cho biết mã phức tạp như thế nào.
http://sourceforge.net/projects/cccc/
Chạy các công cụ phân tích tĩnh khác.
Tôi thậm chí không cố gắng chạy một công cụ phân tích tĩnh trên codebase. Tôi nghĩ trước tiên chúng ta nên cố gắng để có được những cảnh báo được tính bằng không. Điều này có vẻ hợp lý không? – geschema
@geschema Có, tất nhiên. Theo tôi, mã nên biên dịch mà không có cảnh báo, vì hầu hết các cảnh báo đều hợp lệ. –
Ngoài ra, hãy thêm càng nhiều bài kiểm tra đơn vị càng tốt. –
Hãy xem chất lượng mã. Nó sẽ nhanh chóng cung cấp cho bạn một dấu hiệu của số lượng các vấn đề ẩn trong nguồn. Nếu nguồn là xấu và mất một thời gian dài để hiểu sẽ có rất nhiều lỗi trong mã.
Mã có cấu trúc tốt với kiểu nhất quán và dễ hiểu sẽ chứa ít vấn đề hơn. Mã cho thấy bao nhiêu nỗ lực và suy nghĩ đi vào nó.
Tôi đoán là nếu nguồn chứa nhiều cảnh báo, sẽ có nhiều lỗi ẩn trong mã.
Chất lượng mã là điều tương đối và rất khó đo lường. Chỉ cần nhìn vào mã sẽ không cung cấp nhiều thông tin. –
Đúng, nhưng nó cung cấp cho bạn một ý tưởng về những gì đang xảy ra trong phần mềm. – Gerhard
Câu hỏi của bạn là "Có 5 lỗi/100 dòng mã là ước tính hợp lý không?" Câu hỏi đó cực kỳ khó trả lời, và nó phụ thuộc nhiều vào độ phức tạp của mã số &.
Bạn cũng đã đề cập trong nhận xét "để hiển thị quản lý rằng có thể có rất nhiều lỗi trong codebase" - điều đó thật tuyệt, kudo, ngay trên đó.
Để mở mắt tượng trưng quản lý, tôi muốn đề nghị ít nhất là một cách tiếp cận 3 mũi nhọn:
Một điểm khác: Tôi yêu cầu biên dịch sạch trong nhóm của tôi và cũng làm sạch đầu ra Lint. Thông thường điều này có thể hoàn thành chỉ bằng cách viết mã tốt, nhưng đôi khi các cảnh báo trình biên dịch/lint cần phải được tinh chỉnh để làm yên lặng công cụ cho những thứ không phải là vấn đề (sử dụng một cách khôn ngoan).
Nhưng điểm quan trọng tôi muốn thực hiện là: phải rất cẩn thận khi đi vào & trình biên dịch sửa lỗi & cảnh báo lint. Đó là một mục tiêu đáng ngưỡng mộ, nhưng bạn cũng có thể vô tình phá vỡ mã làm việc, và/hoặc phát hiện ra hành vi không xác định mà vô tình làm việc trong mã "bị hỏng". Vâng, điều này thực sự xảy ra. Vì vậy, hãy cẩn thận.
Cuối cùng, nếu bạn có một bộ thử nghiệm vững chắc đã có sẵn, điều đó sẽ giúp bạn xác định xem bạn có vô tình phá vỡ điều gì đó trong khi tái cấu trúc hay không.
Chúc may mắn!
+1 để được tư vấn cẩn thận. Xem thêm cuốn sách này để được trợ giúp chuyển từ mã không được kiểm tra sang mã thân thiện với quy tắc tái cấu trúc: http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 – Matthieu
@matthieu: đó là cuốn sách tuyệt vời. Nó cũng rất khuyến khích nó. – geschema
Cảm ơn lời khuyên tuyệt vời và chỉ ra nguy cơ giới thiệu các lỗi mới khi sửa các cảnh báo dường như vô hại, đặc biệt khi không có kiểm tra. – geschema
Nếu bạn muốn ước tính số lỗi, cách ước lượng thống kê thông thường là lấy mẫu dữ liệu. Tôi sẽ chọn ba chương trình con có kích thước trung bình một cách ngẫu nhiên và kiểm tra chúng một cách cẩn thận để tìm lỗi (loại bỏ cảnh báo trình biên dịch, chạy công cụ phân tích tĩnh, v.v.). Nếu bạn tìm thấy ba lỗi trong 100 dòng mã được chọn ngẫu nhiên, có vẻ như hợp lý rằng mật độ lỗi tương tự nằm trong phần còn lại của mã.
Vấn đề được đề cập ở đây là giới thiệu các lỗi mới là một vấn đề quan trọng, nhưng bạn không cần kiểm tra mã đã sửa đổi trở lại chi nhánh sản xuất để chạy thử nghiệm này. Tôi sẽ đề xuất một bộ kiểm tra đơn vị toàn diện trước khi sửa đổi bất kỳ chương trình con nào, và dọn sạch tất cả mã theo sau kiểm tra hệ thống rất kỹ lưỡng trước khi phát hành mã mới để sản xuất.
Nếu anh ta không may mắn, mẫu của anh ấy có thể rất tốt ... –
@VJo: * Phụ mẫu * không có nghĩa là * một mẫu *! Đó là số liệu thống kê cho bạn. – Clifford
@Clifford Thống kê là tốt, nhưng luật murfy là trên thống kê;) –
Nếu bạn muốn chứng minh lợi ích của các bài kiểm tra đơn vị, đánh giá mã, công cụ phân tích tĩnh, tôi đề xuất thực hiện một nghiên cứu thí điểm.
Thực hiện một số kiểm tra đơn vị, đánh giá mã và chạy các công cụ phân tích tĩnh trên một phần của mã. Hiển thị quản lý số lượng lỗi bạn tìm thấy bằng các phương pháp đó. Hy vọng rằng, kết quả nói cho chính họ.
Bài viết sau đây có một số con số dựa trên các dự án thực tế cuộc sống để mà phân tích tĩnh đã được áp dụng cho: http://www.stsc.hill.af.mil/crosstalk/2003/11/0311German.html
Tất nhiên các tiêu chuẩn mà một sự bất thường được tính có thể ảnh hưởng đến kết quả đáng kể, dẫn đến việc lớn sự thay đổi trong các số liệu được thể hiện trong Bảng 1. Trong bảng này, số lượng dị thường trên một nghìn dòng mã cho phạm vi C từ 500 (!) đến khoảng 10 (được tạo tự động).
Tại sao bạn muốn biết? – Jan
Thật khó để nói mức độ liên quan của số cảnh báo. Hầu hết các cảnh báo bắt nguồn từ tiêu đề sẽ được báo cáo trong tất cả các đơn vị dịch bao gồm tiêu đề đó. – MSalters
@Jan: để hiển thị quản lý rằng có thể có rất nhiều lỗi trong codebase và chúng ta nên bắt đầu làm điều gì đó về nó ngay bây giờ. – geschema