Mi az a hibasűrűség? Kiszámítandó képlet példával
Thomas Hamilton
⚡ Okos összefoglaló
A hibasűrűség egy szoftvermodulban található megerősített hibák számát méri osztva a modul méretével, amelyet általában ezer sornyi kódra vetítenek ki, és azt jelzi, hogy a build készen áll-e a kiadásra.
Mi az a hibasűrűség?
Hiba sűrűsége egy adott szoftver- vagy modulrészletben a működés vagy fejlesztés egy adott időszakában megerősített hibák száma, osztva a szoftver vagy modul méretével. Ez lehetővé teszi a csapat számára annak eldöntését, hogy egy szoftverrészlet kiadásra kész-e.
A hibasűrűséget ezer sornyi kódra vetítve mérik, más néven KLOC-ként. Mivel a szám méret szerint normalizált, egy nagy, sok hibával rendelkező modul és egy kis, kevés hibával rendelkező modul ugyanazon a skálán hasonlítható össze, amit a nyers hibaszámlálás soha nem tesz lehetővé.
A mutatót általában a tesztciklus végén jelentik, és tracked kiadás kiadás után, így a többi mellett helyezkedik el hibakezelési folyamat a szoftvertesztelés életciklusa.
Hogyan számítsuk ki a hibasűrűséget
Egy képlet a hibasűrűség mérésére:
Defect Density = Defect count/size of the release
A kiadás mérete kódsorokban (LOC) mérhető.
Három részlet dönti el, hogy a kapott szám jelent-e valamit:
- A méretegység. A LOC és a KLOC a leggyakoribb mértékegységek. A függvénypontokat ott használják, ahol a csapatok olyan méretmértéket szeretnének, amely nem változik a programozási nyelvvel, és egyes csapatok modulonként vagy komponensenként normalizálnak.
- Ami hibának számít. Csak a megerősített hibák szerepelhetnek a számlálóban. A duplikátumokat, az elutasított jelentéseket és a fejlesztési kéréseket ki kell zárni, különben a szám a kód minőségének változása nélkül növekszik.
- A mérési ablak. A rendszer tesztelése során talált hibák, regressziós teszt, és a kiadás utáni különböző dolgokat írnak le, ezért a periódust számmal kell megadni.
Példa a hibasűrűségre
Tegyük fel, hogy 3 modul van integrálva a szoftvertermékébe. Mindegyik modulban a következő számú hibát fedezték fel:
- 1. modul = 10 hiba
- 2. modul = 20 hiba
- 3. modul = 10 hiba
Összes hiba = 10+20+10 = 40
Az egyes modulok teljes kódsora a következő:
- 1. modul = 1000 LOC
- 2. modul = 1500 LOC
- 3. modul = 500 LOC
Teljes sor Code = 1000+1500+500 = 3000
A hibasűrűség kiszámítása a következőképpen történik:
Defect Density = 40/3000 = 0.013333 defects/loc = 13.333 defects/Kloc
Ugyanaz a számítás modulonként alkalmazva hasznosabb, mint az összesített érték, ahogy az alábbi diagram is mutatja: a 2. modul 20 hibát hordoz 1500 LOC-ban, a 3. modul pedig 10 hibát hordoz mindössze 500 LOC-ban, tehát a 3. modul a sűrűbb és kockázatosabb a kettő közül, annak ellenére, hogy kevesebb hibát jelentett.
A hibasűrűség szabványa
A hibasűrűségre nincs rögzített szabvány. A tanulmányok azt sugallják, hogy az egyik hiányosság Az ezer sornyi kódra vetített értéket általában a jó projektminőség jelének tekintik, és ez a szám a legszélesebb körben idézett ökölszabály az iparágban.
Az elvárás valóban együtt változik a területtel. A biztonságkritikus és szabályozott szoftverek, mint például a repüléstechnikai és orvostechnikai eszközök, esetében a KLOC-onkénti egy hibaszám alatti célt határoznak meg, míg a szokásos üzleti alkalmazások rutinszerűen e felett vannak. Mivel a számlálási szabályok, a méretegységek és a tesztelési mélység szervezetekenként eltérő, egy publikált tanulmányból vett referenciaérték csak egy olyan projekttel hasonlítható össze, amely ugyanúgy mér. A metrika gyakorlati használata tehát belső: hasonlítson össze egy kiadást ugyanazon termék korábbi, azonosan mért kiadásával.
A hibasűrűséget befolyásoló tényezők
Ugyanaz a kódbázis nagyon eltérő hibasűrűségi értékeket eredményezhet a következő tényezőktől függően:
- Code bonyolultság. Mélyen beágyazott logika és magas ciklomatikus komplexitás soronként több hibát produkál, mint az egyszerű kód.
- A figyelembe vett hibák típusa. Csak a funkcionális hibákat számoljuk, vagy a használhatóságot, a dokumentációt és a hibákat is beleszámítjuk. nem működőképes megállapítások jelentősen megváltoztatják a számlálót.
- A figyelembe vett időtartam. Egy kéthetes tesztciklus alatt mért érték nem összehasonlítható egy hat hónapos gyártási ciklus alatt mért értékkel.
- Fejlesztői és tesztelői készségek. A tapasztalt fejlesztők kevesebb hibát injektálnak, a tapasztalt tesztelők pedig többet találnak a létező hibákból, így a két hatás ellentétes irányba húzza a metrikát.
- Teszt lefedettség. Azokat a hibákat, amelyeket soha nem kerestek, soha nem számolják, tehát teszt lefedettség csendben korlátozza a mért sűrűség magasra emelkedését.
Hibasűrűség vs. egyéb hibametrikák
A hibasűrűség egyetlen kérdésre ad választ: mennyire koncentráltak az ismert hibák. Három kapcsolódó metrika ad választ azokra a kérdésekre, amelyekre nem ad választ, és a legtöbb csapat együtt jelenti őket.
| Metric | Mit mér | Kérdés, amit megválaszol |
| Hiba sűrűsége | Megerősített hibák méret szerint osztva (KLOC vagy funkciópontok) | Melyik modulok tartalmazzák a legtöbb hibát a méretükhöz képest? |
| Hiba Szivárgás | A kiadás után talált hibák aránya az összes hibán belül | Mennyi jutott el a tesztelési folyamaton túlra és a felhasználókhoz? |
| Hibaelhárítási hatékonyság | A kiadás előtt eltávolított hibák aránya az összes hibához képest | Mennyire volt hatékony a tesztelés a hibák időben történő felismerésében? |
| Hibasúlyossági index | A hibákat súlyosság szerint súlyozták, nem pedig egyenlően számolták | Mennyire károsak a hibák, nem csak a számuk? |
Együttesen olvasva a négy teljesebb képet ad: az alacsony hibasűrűség magas hibaszivárgással inkább sekély tesztelésre, mintsem tiszta kódra utal, ami pontosan az a félreolvasás, amire a következő szakasz figyelmeztet.
A hibasűrűség előnyei
A hibasűrűség előnyei a következők:
- Segít a tesztelés hatékonyságának mérésében.
- Segít megkülönböztetni a hibák koncentrációját a komponensek és a szoftvermodulok között.
- Hasznos a javításra vagy fejlesztésre szoruló területek azonosításában.
- Hasznos a magas kockázatú összetevők kiemelésében, ami közvetlenül befolyásolja a kockázatalapú tesztelés.
- Segít azonosítani a különböző erőforrások képzési igényeit.
- Hasznos lehet a hibák által okozott tesztelési és átdolgozási ráfordítás becslésében.
- Képes megbecsülni a szoftverben fennmaradó hibákat.
- A kiadás előtt segít megállapítani, hogy az eddig elvégzett tesztelés elegendő-e.
- Egy történelmi alapot teremt, amelyhez a későbbi kiadások mérhetők.
A hibasűrűség korlátai
A metrika könnyen kiszámítható és könnyen félreolvasható. A következő korlátozások határozzák meg, hogy mekkora súllyal esik latba a kiadási döntésben:
- A nem észlelt hibák láthatatlanok. A számláló csak azokat a hibákat tartalmazza, amelyeket a tesztelés ténylegesen talált, így egy gyengén tesztelt modul hízelgő értéket mutat.
- A súlyosságot figyelmen kívül hagyják. Egyetlen fizetési hibát elrontó hiba és egy kozmetikai illesztési probléma ugyanannak számít, ezért van szükség mellettük egy súlyosság szerinti nézetre is.
- A hibák definíciói eltérőek. Két különbözően számoló csapat olyan számokat hoz létre, amelyeket nem lehet összehasonlítani, még ugyanazon a szervezeten belül sem.
- A kódsorok gyenge méretproxyként működnek. A részletes kód csökkenti a sűrűséget anélkül, hogy bármit is javítana, és az egység nem összehasonlítható a különböző programozási nyelvek között.
- A metrika kijátszható. A határesetnek számító jelentések elutasítása vagy a sorok számának felfújása egyaránt javítja a mutatót a termék fejlesztése nélkül.
Mindez nem teszi a Hibasűrűséget haszontalanná. Egyetlen termék következetesen mért trendjelzőjévé teszi, ahelyett, hogy egy olyan pontszámmá tenné, amellyel a csapatok összehasonlíthatók lennének egymás ellen.
Hogyan csökkenthető a hibasűrűség?
A hibasűrűség csökkentése valójában – nem csak papíron – azt jelenti, hogy a hibákat korábban kell megelőzni, a többit pedig a kiadás előtt kell feltárni. Az alábbi gyakorlatok azok, amelyek a publikált útmutatókban visszatérnek:
- A tesztelés korábbi időpontra váltása. A tesztelők bevonása a követelmény- és tervezési szakaszba még azelőtt elfedi a kétértelműségeket, mielőtt azok kóddá válnának, és ott a legolcsóbb a hibákat eltávolítani.
- Review kódot az összevonás előtt. A szakmai értékelés olyan logikai hibákat, félreértelmezett követelményeket és tervezési hibákat szűr ki, amelyek nem... egységteszt keresésére írták.
- Automatizálja a regressziós csomagot. Ellenőrzések futtatása minden véglegesítésen keresztül folyamatos integráció megakadályozza a régi hibák visszatérését az új kód írása közben.
- Először írj teszteket. Tesztvezérelt fejlesztés arra kényszeríti, hogy minden viselkedést a megvalósítás előtt specifikáljanak, és mutációs tesztelés majd megerősítheti, hogy a kapott tesztek valóban állítanak valamit.
- Használjon statikus analízist. Az automatizált kódszkennelés egyetlen teszt futtatása előtt jelzi a null dereferenciákat, az erőforrás-szivárgásokat és a bonyolultsági gócpontokat.
- Refaktoráld a sűrű modulokat. Miután a Hibasűrűség módszer azonosította a legrosszabb komponenseket, azok felosztása és egyszerűsítése általában csökkenti mind a bonyolultságot, mind a hibák számát.
- A hibákat vissza kell vezetni a folyamatba. A retrospektív vizsgálatok során végzett kiváltó ok-elemzés az egyes hibákat folyamatjavításokká alakítja, nem pedig egyszeri javításokká.
Tracked kiadás a kiadás mellett szoftvertesztelési technikák és a lefedettségi adatok alapján a Hibasűrűség inkább korai figyelmeztető rendszerré, mintsem egy jelentéssé válik.
