Mikä on vikatiheys? Laskekaava esimerkin avulla

Mikä on vikatiheys?

Vian tiheys on ohjelmistossa tai moduulissa tietyn toiminta- tai kehitysjakson aikana vahvistettujen vikojen lukumäärä jaettuna kyseisen ohjelmiston tai moduulin koolla. Sen avulla tiimi voi päättää, onko ohjelmisto valmis julkaistavaksi.

Virhetiheys lasketaan tuhatta koodiriviä kohden, joka tunnetaan myös nimellä KLOC. Koska luku normalisoidaan koon mukaan, suurta moduulia, jossa on paljon virheitä, ja pientä moduulia, jossa on vähän virheitä, voidaan verrata samalla mittakaavalla, mitä raaka virheiden määrä ei koskaan mahdollista.

Mittari raportoidaan yleensä testisyklin lopussa ja tracked-julkaisu julkaisun jälkeen, joten se sijoittuu muun rinnalle vianhallinnan prosessi vuonna ohjelmistotestauksen elinkaari.

Kuinka laskea vikatiheys

Kaava vikatiheyden mittaamiseksi:

Defect Density = Defect count/size of the release

Julkaisun kokoa voidaan mitata koodirivin (LOC) avulla.

Kolme yksityiskohtaa ratkaisee, onko tuloksena olevalla luvulla mitään merkitystä:

• Kokoyksikkö. LOC ja KLOC ovat yleisimmät yksiköt. Funktiopisteitä käytetään silloin, kun tiimit haluavat koon mittauksen, joka ei muutu ohjelmointikielen mukaan, ja jotkut tiimit normalisoivat sen sijaan moduulin tai komponentin mukaan.
• Mikä lasketaan virheeksi. Vain vahvistetut viat kuuluvat osoittajaan. Kaksoiskappaleet, hylätyt raportit ja parannuspyynnöt on jätettävä pois, tai luku kasvaa ilman koodin laadun muutosta.
• Mittausikkuna. Järjestelmätestauksen aikana löydetyt viat, regressiotestaus, ja julkaisun jälkeen kuvaavat eri asioita, joten jakso on ilmoitettava numerolla.

Esimerkki virhetiheydestä

Oletetaan, että ohjelmistotuotteeseesi on integroitu kolme moduulia. Jokaisesta moduulista on löydetty seuraava määrä virheitä:

• Moduuli 1 = 10 virhettä
• Moduuli 2 = 20 virhettä
• Moduuli 3 = 10 virhettä

Kokonaismäärä vikoja = 10 + 20 + 10 = 40

Kunkin moduulin koodirivien kokonaismäärä on:

• Moduuli 1 = 1000 LOC
• Moduuli 2 = 1500 LOC
• Moduuli 3 = 500 LOC

Kokonaislinja Code = 1000+1500+500 = 3000

Vian tiheys lasketaan seuraavasti:

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

Saman laskelman soveltaminen moduulikohtaisesti on hyödyllisempi kuin yhdistetty luku, kuten alla oleva kaavio osoittaa: Moduuli 2 sisältää 20 vikaa 1500 paikallisella virhealueella ja moduuli 3 sisältää 10 vikaa vain 500 paikallisella virhealueella, joten moduuli 3 on näistä kahdesta tiheämpi ja riskialttiimpi, vaikka se raportoi vähemmän virheitä.

Vikatiheyden standardi

Vikatiheydelle ei ole olemassa kiinteää standardia. Tutkimukset viittaavat siihen, että yksi vika tuhatta koodiriviä kohden pidetään yleensä merkkinä hyvästä projektin laadusta, ja tämä luku on alan laajimmin siteerattu nyrkkisääntö.

Odotusarvo kyllä ​​muuttuu toimialueen mukana. Turvallisuuskriittisten ja säänneltyjen ohjelmistojen, kuten avioniikan ja lääkinnällisten laitteiden, tavoite on selvästi alle yksi vika KLOC:ia kohden, kun taas tavalliset liiketoimintasovellukset ovat rutiininomaisesti tämän rajan yläpuolella. Koska laskentasäännöt, kokoyksiköt ja testaussyvyys vaihtelevat organisaatioiden välillä, julkaistusta tutkimuksesta otettu vertailuarvo on verrattavissa vain projektiin, joka mittaa samalla tavalla. Mittarin käytännön käyttö on siis sisäistä: vertaa julkaisua saman tuotteen edelliseen julkaisuun, joka on mitattu identtisesti.

Vikatiheyteen vaikuttavat tekijät

Sama koodikanta voi tuottaa hyvin erilaisia ​​vikatiheyslukuja seuraavista tekijöistä riippuen:

• Code monimutkaisuus. Syvästi sisäkkäinen logiikka ja korkea syklomaattinen monimutkaisuus tuottaa enemmän virheitä riviä kohden kuin suoraviivainen koodi.
• Huomioon otettujen vikojen tyyppi. Lasketaan mukaan vain toiminnalliset viat tai käytettävyys, dokumentaatio ja ei-toiminnallinen havainnot, muuttaa osoittajaa merkittävästi.
• Huomioitava ajanjakso. Kahden viikon testisyklin aikana mitattu luku ei ole verrattavissa kuuden kuukauden tuotantokäytön aikana mitattuun lukuun.
• Kehittäjä- ja testaajaosaaminen. Kokeneet kehittäjät injektoivat vähemmän vikoja ja kokeneet testaajat löytävät enemmän olemassa olevia vikoja, joten nämä kaksi vaikutusta vetävät metriikkaa vastakkaisiin suuntiin.
• Testin kattavuus. Vikoja, joita ei koskaan etsitty, ei koskaan lasketa mukaan, joten testin kattavuus rajoittaa hiljaa kuinka korkeaksi mitattu tiheys voi nousta.

Vikatiheys vs. muut vikamittarit

Vikatiheys vastaa yhteen kysymykseen: kuinka keskittyneitä tunnetut viat ovat. Kolme rinnakkaismittaria vastaavat kysymyksiin, joihin se ei pysty, ja useimmat tiimit raportoivat ne yhdessä.

Yhdessä luettuna nämä neljä antavat kokonaiskuvan: alhainen vikatiheys ja korkea vikavuoto viittaavat pinnalliseen testaukseen eikä puhtaaseen koodiin, mistä seuraavassa osiossa varoitetaan juuri virheellisestä tulkinnasta.

Virhetiheyden edut

Seuraavat ovat vikatiheyden edut:

• Se auttaa mittaamaan testauksen tehokkuutta.
• Se auttaa erottamaan vikapitoisuuden komponenttien ja ohjelmistomoduulien välillä.
• Se on hyödyllinen korjauksia tai parannuksia vaativien alueiden tunnistamisessa.
• Se on hyödyllinen osoittamaan korkean riskin komponentteja, jotka vaikuttavat suoraan riskiperusteinen testaus.
• Se auttaa tunnistamaan eri resurssien koulutustarpeita.
• Se voi olla hyödyllinen vikojen aiheuttaman testaus- ja uudelleentyöstötyön arvioinnissa.
• Se voi arvioida ohjelmistossa jäljellä olevia vikoja.
• Ennen julkaisua se auttaa määrittämään, onko tähän mennessä tehty testaus riittävää.
• Se luo historiallisen vertailukohdan, jota vasten myöhempiä julkaisuja voidaan mitata.

Vikatiheyden rajoitukset

Mittari on helppo laskea ja helppo tulkita väärin. Seuraavat rajoitukset ratkaisevat, kuinka paljon painoarvoa sillä on julkaisupäätöksessä:

• Havaitsemattomat viat ovat näkymättömiä. Osoittaja sisältää vain testauksessa löydetyt viat, joten heikosti testattu moduuli raportoi imartelevan luvun.
• Vakavuusaste jätetään huomiotta. Yksi maksutapahtumaa vioittava vika ja yksi kosmeettinen kohdistusongelma lasketaan samaksi, minkä vuoksi niiden rinnalle tarvitaan vakavuusasteen mukaan painotettu näkökulma.
• Vikojen määritelmät vaihtelevat. Kaksi eri tavalla laskevaa joukkuetta tuottavat lukuja, joita ei voida verrata edes saman organisaation sisällä.
• Koodirivit ovat heikko koon sijaisarvo. Pitkäkestoinen koodi pienentää tiheyttä parantamatta mitään, eikä yksikköä voida verrata eri ohjelmointikielten välillä.
• Mittaria voi pelata. Rajatapausraporttien hylkääminen tai rivimäärän paisuttelu parantavat lukua parantamatta tuotetta.

Mikään tästä ei tee vikatiheydestä hyödytöntä. Se tekee siitä yhden tuotteen trendi-indikaattorin, jota mitataan jatkuvasti, eikä pistemäärää, jolla voidaan vertailla tiimejä toisiinsa.

Kuinka vähentää vikatiheyttä

Virhetiheyden vähentäminen tarkoittaa aidosti, eikä vain paperilla, virheiden ehkäisemistä aikaisemmin ja muiden löytämistä ennen julkaisua. Seuraavat käytännöt toistuvat julkaistuissa ohjeissa:

• Siirrä testaus aikaisemmaksi. Testaajien mukaan ottaminen vaatimus- ja suunnitteluvaiheeseen poistaa epäselvyydet ennen kuin niistä tulee koodia, jolloin viat on halvinta poistaa.
• Review-koodia ennen yhdistämistä. Vertaisarviointi löytää logiikkavirheitä, väärin tulkittuja vaatimuksia ja suunnitteluvirheitä, joita ei ole yksikkötesti oli kirjoitettu etsittäväksi.
• Automatisoi regressiosarja. Tarkistuksen suorittaminen jokaiselle commitille jatkuva integrointi estää vanhojen virheiden palaamisen uuden koodin kirjoittamisen aikana.
• Kirjoita ensin testit. Testilähtöinen kehitys pakottaa jokaisen toiminnan määrittelemään ennen sen toteuttamista, ja mutaatiotestaus voi sitten varmistaa, että testit todella väittävät jotakin.
• Käytä staattista analyysia. Automaattinen koodin skannaus merkitsee null-viittaukset, resurssivuodot ja monimutkaisuuspisteet ennen yksittäistä testiajoa.
• Refaktoroi tiheät moduulit. Kun vikatiheysanalyysi on tunnistanut huonoimmat komponentit, niiden jakaminen ja yksinkertaistaminen yleensä vähentää sekä monimutkaisuutta että vikamäärää.
• Syötä virheet takaisin prosessiin. Retrospektiivien perussyyanalyysi muuttaa yksittäiset viat prosessikorjauksiksi kertaluonteisten korjausten sijaan.

Tracked-julkaisu julkaisun rinnalla ohjelmistotestaustekniikat ja peittotietojen perusteella vikatiheydestä tulee raporttikortista pikemminkin ennakkovaroitusjärjestelmä.

UKK