Yazılım Test Metrikleri: Nedir, Türleri ve Örnek
⚡ Akıllı Özet
Yazılım test metrikleri, bir test sürecinin ilerlemesini, kalitesini ve verimliliğini ölçen nicel göstergelerdir. Bu kılavuz, üç metrik türünü, temel ve hesaplanmış ayrımını, metrik yaşam döngüsünü ve doğrudan uygulayabileceğiniz bir formül sözlüğünü kapsamaktadır.

Yazılım Testi Metrikleri Nelerdir?
Yazılım Test Metrikleri yazılım test sürecinin ilerlemesini, kalitesini, üretkenliğini ve sağlığını tahmin etmek için kullanılan niceliksel önlemlerdir. Yazılım test metriklerinin amacı, yazılım test sürecinin verimliliğini ve etkinliğini artırmak ve test süreci hakkında güvenilir veriler sağlayarak daha sonraki test süreci için daha iyi kararlar alınmasına yardımcı olmaktır.
Bir ölçüt, bir sistemin, bir bileşenin veya bir sürecin belirli bir özelliğe ne ölçüde sahip olduğunu nicel terimlerle ifade eder. Basit bir benzetme olarak, bir otomobilin gerçek haftalık yakıt tüketimi ile üreticinin belirttiği rakam arasındaki farkı gösterebiliriz.
Yazılım test ölçümleri – Bir yazılım test sürecinin verimliliğini ve etkinliğini artırır.
Yazılım test metrikleri veya yazılım test ölçümü, bir süreç veya ürünün bazı özelliklerinin kapsamının, kapasitesinin, boyutunun, miktarının veya boyutunun niceliksel göstergesidir.
Yazılım testi ölçümü örneği: Toplam kusur sayısı
Test Ölçütleri Neden Önemli?
“Ölçemediğimiz şeyi geliştiremeyiz.” Test ölçütleri, test sürecini ölçülebilir hale getirmek için vardır.
- Sonraki faaliyet aşamasının ne olması gerektiğine karar verin.
- Kaliteyle ilgili bir iddia veya tahmine dair kanıt sunun.
- Hangi tür iyileştirmenin gerekli olduğunu belirleyin.
- Bir süreç veya teknoloji değişikliğini gerekçelendirin.
Onun hakkında daha fazlasını okuyun Test Metriklerinin Önemi
Test Metrik Türleri
- Süreç Metrikleri: SDLC'nin işlem verimliliğini artırmak için kullanılabilir (Yazılım geliştirme Yaşam Döngüsü)
- Ürün Metrikleri: Yazılım ürününün kalitesiyle ilgilenir
-
Proje Metrikleri: Bir proje ekibinin veya herhangi bir ekibin verimliliğini ölçmek için kullanılabilir. test araçları ekip üyeleri tarafından kullanılıyor
Doğru ölçütleri seçmek, çok sayıda ölçüt toplamaktan daha önemlidir. Bir ölçüt kümesine karar vermeden önce aşağıdakileri göz önünde bulundurun:
- Metrik hazırlığı için hedef kitleyi sabitleyin
- Metrikler için hedefi tanımlayın
- Proje ihtiyaçlarına göre ilgili tüm ölçümleri tanıtın
- Her bir ölçütün maliyet ve faydasını ve projenin yaşam döngüsünün hangi aşamasında en fazla değeri sağladığını değerlendirin.
Manuel Test Metrikleri
In Yazılım Mühendisliği, Manuel test metrikleri iki sınıfa ayrılır
- Temel Metrikler
- Hesaplanmış Metrikler
Temel ölçümler, test senaryosunun geliştirilmesi ve yürütülmesi sırasında Test Analisti tarafından toplanan ham verilerdir (Gerçekleştirilen test senaryolarının sayısı, test senaryolarının sayısı). Hesaplanan metrikler, temel metriklerde toplanan verilerden türetilir. Hesaplanan metrikler genellikle test raporlama amacıyla test yöneticisi tarafından takip edilir (Tamamlanma Yüzdesi, Test Kapsamı Yüzdesi).
Proje veya iş modeline bağlı olarak, en önemli ölçütler genellikle şunlardır:
- Test senaryosu yürütme üretkenlik ölçümleri
- Test senaryosu hazırlama üretkenlik ölçümleri
- Kusur metrikleri
- Önceliğe göre kusurlar
- Ciddiyete göre kusurlar
- Kusur kayma oranı
Manuel ve Otomasyon Test Metrikleri
Yukarıda açıklanan ölçümler, manuel olarak yürütülen bir test paketini varsaymaktadır. Otomatikleştirilmiş bir test paketi farklı şekilde ölçülür, çünkü artık kısıtlama yürütme çabası değildir.
| Kriterler | Manuel Test Metrikleri | Otomasyon Testi Metrikleri |
|---|---|---|
| Birincil odak | Çaba ve uygulama ilerlemesi | Kapsama alanı, kararlılık ve çalışma süresi |
| Tipik ölçü | Günlük olarak yürütülen test senaryoları | Otomasyon kapsama yüzdesi |
| Kalite sinyali | Test saati başına bulunan arıza sayısı | Kararsız test oranı, yani istikrarsız testlerin payı. |
| Maliyet ölçüsü | Test görevlisinin çalışma saatleri | Sürüm başına komut dosyası bakım saatleri |
| Hız ölçümü | Döngü süresi (gün) | Paket yürütme süresi (dakika) |
Automation Coverage = (Test cases automated / Total test cases) x 100 Flaky Test Rate = (Tests with inconsistent results / Total automated tests) x 100
Düşük test oranı özellikle dikkat gerektiriyor. Yaklaşık yüzde 5'i geçtikten sonra, ekipler kırmızı renkteki yapıları görmezden gelmeye başlıyor ve bu noktada, kapsama alanı ne kadar yüksek olursa olsun, test paketi bilgi sağlamayı durduruyor.
Yazılım Mühendisliğinde Test Metrikleri Yaşam Döngüsü
| Metrics yaşam döngüsünün farklı aşamaları | Her aşamadaki adımlar |
|---|---|
| Makaleler |
|
| İletişim kurmak |
|
| Değerlendirme |
|
| Report |
|
Bir Test Ölçütü Nasıl Hesaplanır?
| Bay # | Metrikleri test etme adımları | Örnek E-posta |
|---|---|---|
| 1 | Anahtarı tanımlayın yazılım testi ölçülecek süreçler | Test ilerlemesi trackral süreci |
| 2 | Bu Adımda test uzmanı, metrikleri tanımlamak için verileri temel olarak kullanır. | Günde yürütülmesi planlanan test senaryosu sayısı |
| 3 | Takip edilecek bilgilerin belirlenmesi, bir sıklık trackral ve sorumlu kişi | Günlük gerçek test yürütme işlemi, günün sonunda test yöneticisi tarafından yakalanacaktır. |
| 4 | Tanımlanan metriklerin etkin hesaplanması, yönetimi ve yorumlanması | Günlük olarak yürütülen gerçek test senaryoları |
| 5 | Tanımlanan metriklerin yorumlanmasına bağlı olarak iyileştirme alanlarını belirleyin | If test durumu Uygulama, kararlaştırılan hedefin altında kalırsa, nedenini araştırın ve düzeltici önlemler önerin. |
Test Ölçütü Hesaplamasına Örnek
Çalıştırılan test senaryolarının yüzdesini örnek olarak ele alalım. Çalıştırma durumunu yüzde olarak ifade etmek için şu formülü kullanın:
Percentage test cases executed= (No of test cases executed/ Total no of test cases written) X 100
250 test senaryosu yazılmış ve 175'i çalıştırılmışsa, sonuç (175 / 250) x 100 = olur. Yüzde 70 artış. .
Aynı model diğer tüm yürütme parametreleri için de geçerlidir: yürütülmeyen, başarılı, başarısız ve engellenen test durumları. Her biri aynı payda üzerinde farklı bir paydan ibarettir.
En Önemli Test Ölçütleri Track
Bu eğitimin sonundaki sözlükte yaygın olarak kullanılan tüm formüller listelenmiştir. Uygulamada, bir raporlama paketi nadiren sekizden fazla formüle ihtiyaç duyar. Bunlar, bir kararı sürekli olarak yönlendiren formüllerdir.
| metrik | Ne tür bir cevap veriyor? | Dikkat et |
|---|---|---|
| Test senaryosu yürütme yüzdesi | Planlanan koşunun ne kadarını tamamladık? | Kaliteden hiç bahsetmiyor, sadece ilerlemeden bahsediyor. |
| Hata yoğunluğu | Boyut birimi başına kusurlar, peki hangi modül en zayıf? | Tutarlı bir boyut ölçüsüne bağlıdır. |
| Hata giderme verimliliği | Ürün piyasaya sürülmeden önce hataların ne kadarını tespit ettik? | Üretim verileri geldikten sonra ancak kesinleştirilebilir. |
| Arıza sızıntısı | Müşteriye kaç adet kusurlu ürün ulaştı? | En önemli kalite sinyali |
| Test kapsamı | Belirlenen gereksinimlerin ne kadarı yerine getiriliyor? | Zayıf iddialarla desteklenen yüksek kapsama oranı hiçbir şeyi kanıtlamaz. |
| Hata şiddeti endeksi | Açıkta kalan kusurlar ciddi mi yoksa kozmetik mi? | Ağırlıklandırma yapılmadan kusurların sayılması yanıltıcıdır. |
| Onarım için geçen ortalama süre | Ekip sorunu ne kadar hızlı çözüyor? | Uzun süredir devam eden birkaç kusur nedeniyle çarpıtılmış |
| Test yürütme verimliliği | Bir test uzmanı günde kaç vaka tamamlar? | Hedef olarak kullanıldığında yüzeysel testleri teşvik eder. |
Yönetimin sıkça sorduğu ve bu nedenle sözlüğe eklenmesi gereken iki formül:
Defect Removal Efficiency = (Defects found before release / Total defects found) x 100
Defect Leakage = (Defects found in production / Defects found before release) x 100
Ölçüm tuzağı. Hedef olarak kullanılan herhangi bir ölçüt, iyi bir ölçüt olmaktan çıkar. Günde 30 test senaryosu yazma hedefi koyarsanız, test uzmanları 30 tane önemsiz senaryo yazacaktır. Ölçütleri asla tek başına değil, bir bütün olarak raporlayın ve her verimlilik rakamını bir kalite rakamıyla eşleştirin.
Yazılım Testi Metrikleri Formül Sözlüğü
- Yeniden Çalışma Eforu Oranı = (Bu aşamada harcanan fiili yeniden çalışma çabaları/o aşamada harcanan toplam fiili çabalar) X 100
- Gereksinim Sürünme = (Eklenen toplam gereksinim sayısı/Başlangıç gereksinimlerinin sayısı)X100
- Zamanlama Farkı = (Gerçek Teslimat Tarihi – Planlanan Teslimat Tarihi)
- Testte bir kusur bulmanın maliyeti = (Test için harcanan toplam çaba/testte bulunan hatalar)
- Program kayması = (Fiili bitiş tarihi – Tahmini bitiş tarihi) / (Planlanan Bitiş Tarihi – Planlanan Başlangıç Tarihi) X 100
- Geçilen Test Durumlarının Yüzdesi = (Geçilen Test Sayısı/Gerçekleştirilen toplam test sayısı) X 100
- Başarısız Test Senaryoları Yüzdesi = (Başarısız Test Sayısı/Gerçekleştirilen toplam test sayısı) X 100
- Engellenen Test Senaryolarının Yüzdesi = (Engellenen Test Sayısı/Yürütülen toplam test sayısı) X 100
- Sabit Kusur Yüzdesi = (Düzeltilen Kusurlar/Bildirilen Kusurlar) X 100
- Kabul Edilen Kusur Yüzdesi = (Geliştirme Ekibi Tarafından Geçerli Olarak Kabul Edilen Kusurlar / Bildirilen Toplam Kusurlar) X 100
- Kusurların Ertelenmiş Yüzdesi = (Gelecek sürümler için ertelenen kusurlar /Raporlanan Toplam Kusurlar) X 100
- Kritik Kusur Yüzdesi = (Kritik Kusurlar / Rapor Edilen Toplam Kusurlar) X 100
- Bir geliştirme ekibinin kusurları onarması için geçen ortalama süre = (Hata düzeltmeleri için harcanan toplam süre/Hata sayısı)
- Dönem başına gerçekleştirilen test sayısı = Çalıştırılan test sayısı/Toplam süre
- Test tasarımı verimliliği = Tasarlanan test sayısı /Toplam süre
- İnceleme verimliliğini test edin = İncelenen test sayısı /Toplam süre
- Hata bulma oranıVeya test saati başına hata sayısı = Toplam hata sayısı / Toplam test saati sayısı




