Software Testing Metrics: Hva er, typer og eksempel
Thomas Hamilton
⚡ Smart oppsummering
Programvaretestingsmålinger er kvantitative mål på fremdriften, kvaliteten og produktiviteten til en testprosess. Denne veiledningen dekker de tre måletypene, basis- og beregnet skille, målelivssyklusen og en formelordliste du kan bruke direkte.
Hva er programvaretestingsmålinger?
Software Testing Metrics er de kvantitative målene som brukes til å estimere fremdriften, kvaliteten, produktiviteten og helsen til programvaretestprosessen. Målet med beregninger for programvaretesting er å forbedre effektiviteten og effektiviteten i programvaretestprosessen og å hjelpe til med å ta bedre beslutninger for videre testprosess ved å gi pålitelige data om testprosessen.
En måleenhet uttrykker, i kvantitative termer, i hvilken grad et system, en komponent eller en prosess har en gitt egenskap. En enkel analogi er en bils faktiske ukentlige drivstofforbruk sammenlignet med tallet produsenten oppgir.
Programvaretestmålinger – Forbedrer effektiviteten og effektiviteten til en programvaretestprosess.
Programvaretestmålinger eller programvaretestmåling er den kvantitative indikasjonen på omfang, kapasitet, dimensjon, mengde eller størrelse på en eller annen egenskap ved en prosess eller et produkt.
Eksempel på programvaretestmåling: Totalt antall defekter
Hvorfor er testmålinger viktige?
«Vi kan ikke forbedre det vi ikke kan måle.» Testmålinger finnes for å gjøre testprosessen målbar.
- Bestem hva neste fase av aktivitetene skal være
- Gi bevis for en påstand eller en forutsigelse om kvalitet
- Identifiser hvilken type forbedring som er nødvendig
- Begrunn en endring av prosess eller teknologi
Les mer om den Viktigheten av testmålinger
Typer testmålinger
- Prosessmålinger: Den kan brukes til å forbedre prosesseffektiviteten til SDLC (Programvareutvikling livssyklus)
- Produktberegninger: Den omhandler kvaliteten på programvareproduktet
-
Prosjektberegninger: Den kan brukes til å måle effektiviteten til et prosjektteam eller et hvilket som helst testverktøy brukes av teammedlemmene
Å velge riktige målinger er viktigere enn å samle mange av dem. Vurder følgende før du bestemmer deg for et sett:
- Fiks målgruppen for beregningsforberedelsen
- Definer målet for beregninger
- Introduser alle relevante beregninger basert på prosjektbehov
- Vei kostnadene og fordelene ved hver måleenhet, og hvilken fase i prosjektets livssyklus den gir mest verdi i.
Manuelle testmålinger
In Engineering programvare, Manuelle testmålinger er klassifisert i to klasser
- Grunnmålinger
- Beregnede beregninger
Basisberegninger er rådataene samlet inn av testanalytiker under utvikling og utførelse av testcase (# av testtilfeller utført, # av testtilfeller). Mens beregnede beregninger er utledet fra dataene som er samlet inn i basisberegninger. Beregnede beregninger følges vanligvis av testlederen for testrapportering (% fullført, % testdekning).
Avhengig av prosjektet eller forretningsmodellen, er de viktigste målene vanligvis:
- Produktivitetsmålinger for utførelse av testtilfeller
- Produktivitetsberegninger for forberedelse av testcase
- Defektberegninger
- Mangler etter prioritet
- Defekter etter alvorlighetsgrad
- Defekt glideforhold
Manuelle vs. automatiserte testmålinger
Målingene beskrevet ovenfor forutsetter en manuelt utført pakke. En automatisert pakke måles annerledes, fordi utførelsesinnsats ikke lenger er begrensningen.
| Kriterier | Manuelle testmålinger | Målinger for automatiseringstesting |
|---|---|---|
| Primært fokus | Innsats og gjennomføringsfremgang | Dekning, stabilitet og kjøretid |
| Typisk mål | Testtilfeller utført per dag | Prosentandel for automatiseringsdekning |
| Kvalitetssignal | Funnede feil per testtime | Ustabil testrate, andelen ustabile tester |
| Kostnadsmål | Testertimer | Skriptvedlikeholdstimer per utgivelse |
| Hastighetsmål | Syklusvarighet i dager | Suite-kjøringstid i minutter |
Automation Coverage = (Test cases automated / Total test cases) x 100 Flaky Test Rate = (Tests with inconsistent results / Total automated tests) x 100
Ustabil testrate fortjener spesiell oppmerksomhet. Når den passerer omtrent 5 prosent, begynner teamene å ignorere røde builds, og på det tidspunktet slutter suiten å gi informasjon uavhengig av hvor høy dekningen er.
Test Metrics Livssyklus i Software Engineering
| Ulike stadier av Metrics livssyklus | Trinn under hvert trinn |
|---|---|
| Analyse |
|
| Kommunisere |
|
| Evaluering |
|
| Report |
|
Slik beregner du en testmåling
| Sr# | Trinn for å teste beregninger | Eksempel |
|---|---|---|
| 1 | Identifiser nøkkelen programvaretesting prosesser som skal måles | Testing av fremgang trackongeprosess |
| 2 | I dette trinnet bruker testeren dataene som en grunnlinje for å definere beregningene | Antall testsaker som er planlagt utført per dag |
| 3 | Bestemmelse av informasjonen som skal følges, en hyppighet av trackongen og den ansvarlige personen | Den faktiske testutførelsen per dag vil bli fanget opp av testlederen på slutten av dagen |
| 4 | Effektiv beregning, styring og tolkning av de definerte beregningene | De faktiske testsakene utført per dag |
| 5 | Identifiser forbedringsområdene avhengig av tolkningen av definerte beregninger | If testforsøk utførelsen faller under det avtalte målet, undersøke årsaken og foreslå korrigerende tiltak |
Eksempel på en testmetrikkberegning
Ta prosentandelen av utførte testtilfeller som et eksempel. For å uttrykke utførelsesstatus som prosentandel, bruk formelen:
Percentage test cases executed= (No of test cases executed/ Total no of test cases written) X 100
Hvis 250 testtilfeller ble skrevet og 175 er blitt utført, er resultatet (175 / 250) x 100 = 70 prosent.
Det samme mønsteret gjelder for alle andre utførelsesparametere: testtilfeller som ikke er utført, bestått, mislyktes og blokkert. Hver av dem er ganske enkelt en annen teller over samme nevner.
De viktigste testmålingene for Track
Ordlisten på slutten av denne veiledningen viser alle formler som er i vanlig bruk. I praksis trenger en rapporteringspakke sjelden mer enn åtte. Det er disse som konsekvent styrer en beslutning.
| Metric | Hva det svarer på | Pass opp for |
|---|---|---|
| Utførelsesprosent for testtilfeller | Hvor langt er vi i den planlagte løpeturen? | Sier ingenting om kvalitet, bare fremgang |
| Defekttetthet | Defekter per størrelsesenhet, så hvilken modul er svakest? | Avhenger av et konsistent størrelsesmål |
| Effektivitet for fjerning av feil | Hvor stor andel av feil oppdaget vi før lansering? | Kan først ferdigstilles etter at produksjonsdataene er mottatt |
| Defektlekkasje | Hvor mange feil har nådd kunden? | Det viktigste kvalitetssignalet |
| Testdekning | Hvor mye av kravsettet blir utøvd? | Høy dekning med svake påstander beviser ingenting |
| Indeks for feilalvorlighet | Er de åpne defektene alvorlige eller kosmetiske? | Å telle feil uten vekting er misvisende |
| Gjennomsnittlig tid til reparasjon | Hvor raskt snur teamet en feil? | Skjevt av noen få langvarige feil |
| Produktivitet for testutførelse | Hvor mange saker fullfører en tester per dag? | Oppfordrer til overfladiske tester hvis de brukes som mål |
To formler som er verdt å legge til i ordlisten fordi det er disse ledelsen ber om:
Defect Removal Efficiency = (Defects found before release / Total defects found) x 100
Defect Leakage = (Defects found in production / Defects found before release) x 100
Målefellen. Enhver metrikk som brukes som mål slutter å være et godt mål. Sett et produktivitetsmål på 30 testtilfeller per dag, så skriver testerne 30 trivielle. Rapporter metrikker som et sett, aldri isolert, og par hvert produktivitetstall med et kvalitetstall.
Ordliste for formel for programvaretestingsmålinger
- Rework innsatsforhold = (Faktisk omarbeidsinnsats brukt i den fasen/ total faktisk innsats brukt i den fasen) X 100
- Krav Kryp = (Totalt antall krav lagt til/Antall innledende krav)X100
- Tidsplanavvik = (Faktisk leveringsdato – planlagt leveringsdato)
- Kostnad for å finne en feil ved testing = (Total innsats brukt på testing/defekter funnet i testing)
- Tidsplanglidning = (Faktisk sluttdato – estimert sluttdato) / (Planlagt sluttdato – Planlagt startdato) X 100
- Prosentandel beståtte testtilfeller = (Antall beståtte tester/Totalt antall utførte tester) X 100
- Prosentandel mislykkede testtilfeller = (Antall mislykkede tester/Totalt antall utførte tester) X 100
- Prosentandel blokkerte testtilfeller = (Antall blokkerte tester/Totalt antall utførte tester) X 100
- Prosentandel faste feil = (Defekter rettet/mangler rapportert) X 100
- Prosentandel aksepterte defekter = (Defekter akseptert som gyldige av utviklerteamet /totalt defekter rapportert) X 100
- Defekter utsatt prosentandel = (Defekter utsatt for fremtidige utgivelser /Totalt rapporterte feil) X 100
- Prosent av kritiske defekter = (Kritiske defekter / Totale defekter rapportert) X 100
- Gjennomsnittlig tid for et utviklingsteam for å reparere defekter = (Total tid tatt for feilrettinger/antall feil)
- Antall tester som kjøres per tidsperiode = Antall kjørte tester/Total tid
- Test designeffektivitet = Antall tester designet /Total tid
- Test gjennomgang effektivitet = Antall tester gjennomgått /Total tid
- Feilfunnfrekvens, eller defekter per testtime = Totalt antall defekter / Totalt antall testtimer
