Kusur Yoğunluğu Nedir? Örnekle Hesaplanacak Formül
Editoryal Takım
⚡ Akıllı Özet
Hata Yoğunluğu, bir yazılım modülündeki onaylanmış hata sayısının o modülün boyutuna bölünmesiyle ölçülür (genellikle bin satır kod başına ifade edilir) ve bir sürümün yayınlanmaya hazır olup olmadığını gösterir.
Kusur Yoğunluğu Nedir?
Kusur Yoğunluğu Bir yazılımda veya modülde belirli bir çalışma veya geliştirme döneminde doğrulanan hata sayısının, o yazılım veya modülün boyutuna bölünmesiyle elde edilen değerdir. Bu, bir ekibin bir yazılımın piyasaya sürülmeye hazır olup olmadığına karar vermesini sağlar.
Hata yoğunluğu, bin satır kod başına sayılır ve KLOC olarak da bilinir. Sayım boyuta göre normalize edildiğinden, çok sayıda hataya sahip büyük bir modül ile az sayıda hataya sahip küçük bir modül aynı ölçekte karşılaştırılabilir; bu, ham hata sayımının asla izin vermediği bir durumdur.
Bu ölçüm genellikle test döngüsünün sonunda raporlanır ve tracKed'in sürümü ardı ardına geliyor, bu yüzden diğerlerinin yanında yer alıyor. kusur yönetimi süreci içinde yazılım testi yaşam döngüsü.
Hata Yoğunluğu Nasıl Hesaplanır?
Kusur Yoğunluğunu ölçmek için bir formül:
Defect Density = Defect count/size of the release
Bir sürümün boyutu, kod satırı (LOC) cinsinden ölçülebilir.
Elde edilen sayının bir anlam ifade edip etmeyeceğine üç ayrıntı karar verir:
- Ölçü birimi. LOC ve KLOC en yaygın kullanılan birimlerdir. Fonksiyon puanları, ekiplerin programlama diline göre değişmeyen bir boyut ölçüsü istediği durumlarda kullanılır ve bazı ekipler bunun yerine modül veya bileşen bazında normalleştirme yapar.
- Neler kusur olarak kabul edilir? Pay kısmına yalnızca onaylanmış hatalar dahil edilmelidir. Yinelenen kayıtlar, reddedilen raporlar ve iyileştirme talepleri hariç tutulmalıdır, aksi takdirde kod kalitesinde herhangi bir değişiklik olmaksızın rakam şişer.
- Ölçüm penceresi. Sistem testleri sırasında bulunan kusurlar, gerileme testiVe yayınlandıktan sonra farklı şeyleri tanımlıyorlar, bu nedenle süre rakamla belirtilmelidir.
Kusur Yoğunluğu Örneği
Yazılım ürününüzde entegre edilmiş 3 modülünüz olduğunu varsayalım. Her modülde aşağıdaki sayıda hata tespit edilmiştir:
- Modül 1 = 10 hata
- Modül 2 = 20 hata
- Modül 3 = 10 hata
Toplam hata sayısı = 10+20+10 = 40
Her bir modülün toplam kod satırı sayısı şöyledir:
- Modül 1 = 1000 LOC
- Modül 2 = 1500 LOC
- Modül 3 = 500 LOC
Toplam Satır Code = 1000+1500+500 = 3000
Kusur Yoğunluğu şu şekilde hesaplanır:
Defect Density = 40/3000 = 0.013333 defects/loc = 13.333 defects/Kloc
Aşağıdaki grafikte de görüldüğü gibi, aynı hesaplamanın modül başına uygulanması, birleşik rakamdan daha kullanışlıdır: Modül 2, 1500 satır kodda 20 hata taşırken, Modül 3 yalnızca 500 satır kodda 10 hata taşımaktadır; bu nedenle, daha az hata bildirmesine rağmen, Modül 3 ikisi arasında daha yoğun ve daha riskli olanıdır.
Hata Yoğunluğu Standardı
Hata yoğunluğu için sabit bir standart yoktur. Çalışmalar, bir kusur Bin satır kod başına düşen değer, genellikle iyi bir proje kalitesinin göstergesi olarak kabul edilir ve bu rakam sektörde en yaygın olarak alıntılanan genel kuraldır.
Beklenti, alanla birlikte değişir. Havacılık elektroniği ve tıbbi cihazlar gibi güvenlik açısından kritik ve düzenlemeye tabi yazılımlar, KLOC başına bir hatanın çok altında bir hedefle sınırlandırılırken, sıradan iş uygulamaları genellikle bu hedefin üzerinde yer alır. Sayım kuralları, boyut birimleri ve test derinliği kuruluşlar arasında farklılık gösterdiğinden, yayınlanmış bir çalışmadan alınan bir kıyaslama, yalnızca aynı şekilde ölçüm yapan bir projeyle karşılaştırılabilir. Bu nedenle, metriğin pratik kullanımı dahili niteliktedir: bir sürümü, aynı şekilde ölçülen aynı ürünün önceki sürümüyle karşılaştırmak.
Hata Yoğunluğunu Etkileyen Faktörler
Aynı kod tabanı, aşağıdaki faktörlere bağlı olarak çok farklı Hata Yoğunluğu değerleri üretebilir:
- Code karmaşıklık. Derinlemesine iç içe geçmiş mantık ve yüksek siklomatik karmaşıklık Düz koda kıyasla satır başına daha fazla hata üretir.
- Dikkate alınan kusur türleri. Sadece işlevsel kusurları saymak veya kullanılabilirlik, dokümantasyon ve diğer unsurları da dahil etmek işlevsel olmayan Bulgular, pay kısmını önemli ölçüde değiştiriyor.
- Dikkate alınan süre. İki haftalık bir test döngüsü boyunca ölçülen bir rakam, altı aylık üretim kullanımı boyunca ölçülen bir rakamla karşılaştırılamaz.
- Geliştirici ve test uzmanı becerileri. Deneyimli geliştiriciler daha az hata eklerken, deneyimli test uzmanları mevcut hataların daha fazlasını bulur; bu nedenle iki etki, ölçütü zıt yönlerde etkiler.
- Test kapsamı. Araştırılmayan kusurlar asla hesaba katılmaz, bu yüzden test kapsamı Ölçülen yoğunluğun ulaşabileceği en yüksek seviyeyi sessizce sınırlandırır.
Hata Yoğunluğu ve Diğer Hata Ölçütleri Karşılaştırması
Hata Yoğunluğu tek bir soruyu yanıtlar: Bilinen hatalar ne kadar yoğunlaşmıştır? Üç tamamlayıcı ölçüt, yanıtlayamadığı soruları yanıtlar ve çoğu ekip bunları birlikte raporlar.
| metrik | Neyi ölçer | Soruyu cevaplıyor |
| Kusur Yoğunluğu | Boyutlarına göre ayrılmış onaylanmış kusurlar (KLOC veya fonksiyon puanları) | Boyutlarına göre en çok arıza gösteren modüller hangileridir? |
| Arıza Sızıntısı | Ürün piyasaya sürüldükten sonra tespit edilen kusurların tüm kusurlar içindeki oranı | Test sürecinden ne kadarı kaçarak kullanıcılara ulaştı? |
| Hata Giderme Verimliliği | Yayınlanmadan önce giderilen kusurların, tüm kusurlar içindeki payı | Testler, kusurları zamanında tespit etmede ne kadar etkiliydi? |
| Hata Şiddeti Endeksi | Kusurlar eşit olarak sayılmak yerine ciddiyetlerine göre ağırlıklandırılmıştır. | Kusurların sayısı değil, ne kadar zarar verici oldukları önemlidir. |
Dört madde birlikte okunduğunda daha kapsamlı bir tablo ortaya çıkıyor: düşük Hata Yoğunluğu ve yüksek Hata Sızıntısı, temiz koddan ziyade yüzeysel testlere işaret ediyor; bu da bir sonraki bölümde uyarılan yanlış yorumlamanın ta kendisi.
Hata Yoğunluğunun Avantajları
Hata yoğunluğunun avantajları şunlardır:
- Testlerin etkinliğini ölçmeye yardımcı olur.
- Bu, bileşenler ve yazılım modülleri arasındaki hata yoğunluğunu ayırt etmeye yardımcı olur.
- Bu, düzeltilmesi veya iyileştirilmesi gereken alanları belirlemede faydalıdır.
- Yüksek riskli bileşenleri belirlemede faydalıdır ve bu da doğrudan şuna katkıda bulunur: risk bazlı test.
- Çeşitli kaynakların eğitim ihtiyaçlarının belirlenmesine yardımcı olur.
- Bu, kusurların yol açacağı test ve yeniden işleme çabasını tahmin etmede faydalı olabilir.
- Yazılımda kalan hataları tahmin edebilir.
- Yayınlanmadan önce, şimdiye kadar yapılan testlerin yeterli olup olmadığını belirlemeye yardımcı olur.
- Bu, daha sonraki sürümlerin karşılaştırılabileceği tarihsel bir temel oluşturur.
Hata Yoğunluğunun Sınırlamaları
Bu ölçütün hesaplanması kolay, yanlış yorumlanması ise kolaydır. Aşağıdaki sınırlamalar, bir sürüm kararında ne kadar ağırlık taşıyacağına karar verir:
- Tespit edilemeyen kusurlar görünmezdir. Pay kısmında yalnızca testlerin gerçekten bulduğu kusurlar yer alır; bu nedenle, az test edilmiş bir modül, olduğundan daha iyi bir sonuç bildirir.
- Ciddiyet göz ardı ediliyor. Ödeme işlemini bozan tek bir kusur ve kozmetik bir hizalama sorunu aynı öneme sahiptir; bu nedenle, bunun yanında ciddiyet ağırlıklı bir bakış açısına da ihtiyaç duyulmaktadır.
- Hata tanımları farklılık gösterir. İki takımın farklı sayım yöntemleri kullanması, aynı kuruluş içinde bile karşılaştırılamayacak sonuçlar doğurabilir.
- Kod satırları, boyut konusunda zayıf bir göstergedir. Ayrıntılı kod, hiçbir şeyi iyileştirmeden yoğunluğu düşürür ve birim, programlama dilleri arasında karşılaştırılabilir değildir.
- Bu ölçüt manipüle edilebilir. Sınırda kalan raporları reddetmek veya satır sayısını şişirmek, ürünü iyileştirmeden rakamı yükseltir.
Bunların hiçbiri Hata Yoğunluğunu işe yaramaz hale getirmiyor. Aksine, onu takımları birbirleriyle karşılaştırmak için kullanılan bir puan olmaktan ziyade, tutarlı bir şekilde ölçülen tek bir ürün için bir trend göstergesi haline getiriyor.
Hata Yoğunluğunu Nasıl Azaltabiliriz?
Hata yoğunluğunu kağıt üzerinde değil, gerçekten düşürmek, hataları daha erken önlemek ve geri kalanını piyasaya sürülmeden önce bulmak anlamına gelir. Aşağıdaki uygulamalar, yayınlanmış kılavuzlarda tekrar eden uygulamalardır:
- Test işlemlerini daha erken bir tarihe alın. Test uzmanlarını gereksinim ve tasarım aşamasına dahil etmek, belirsizlikleri kod haline gelmeden önce yakalamayı sağlar; bu da hataların giderilmesinin en ucuz olduğu aşamadır.
- RevBirleştirmeden önce kodu inceleyin. Akran değerlendirmesi, mantık hatalarını, yanlış yorumlanan gereksinimleri ve kimsenin fark edemeyeceği tasarım kusurlarını ortaya çıkarır. ünite testi Aranacak şey buydu.
- Regresyon test paketini otomatikleştirin. Her commit işleminde kontroller çalıştırılıyor. sürekli entegrasyon Yeni kod yazılırken eski hataların tekrar ortaya çıkmasını engeller.
- Önce testleri yazın. Test odaklı geliştirme Her davranışın uygulanmadan önce belirtilmesini zorunlu kılar ve mutasyon testi Bu sayede elde edilen testlerin gerçekten bir şeyi iddia edip etmediği doğrulanabilir.
- Statik analiz kullanın. Otomatik kod taraması, tek bir test çalıştırılmadan önce boş referans hatalarını, kaynak sızıntılarını ve karmaşıklık noktalarını tespit eder.
- Yoğun modülleri yeniden düzenleyin. Hata Yoğunluğu en kötü bileşenleri belirledikten sonra, bunları bölmek ve basitleştirmek genellikle hem karmaşıklığı hem de hata sayısını azaltır.
- Hataları tekrar sürece dahil edin. Geriye dönük değerlendirmelerde yapılan kök neden analizi, tekil hataları geçici çözümler yerine süreç iyileştirmelerine dönüştürür.
Tracked sürümü, sürümün yanı sıra eş zamanlı olarak yayınlandı yazılım test teknikleri ve kapsama verileriyle birlikte, Hata Yoğunluğu bir karne olmaktan ziyade bir erken uyarı sistemi haline gelir.
