Software Testing Metrics: Vad är, typer och exempel
Thomas Hamilton
⚡ Smart sammanfattning
Mätvärden för mjukvarutestning är kvantitativa mått på framstegen, kvaliteten och produktiviteten i en testprocess. Den här guiden behandlar de tre mätvärdestyperna, den grundläggande och beräknade skillnaden, mätvärdeslivscykeln och en formelordlista som du kan använda direkt.
Vad är mätvärden för mjukvarutestning?
Mjukvarutestningsmått är de kvantitativa mått som används för att uppskatta framstegen, kvaliteten, produktiviteten och hälsan i mjukvarutestningsprocessen. Målet med mätvärden för mjukvarutestning är att förbättra effektiviteten och effektiviteten i mjukvarutestprocessen och att hjälpa till att fatta bättre beslut för ytterligare testprocess genom att tillhandahålla tillförlitliga data om testprocessen.
Ett mätvärde uttrycker, i kvantitativa termer, i vilken grad ett system, en komponent eller en process besitter en given egenskap. En enkel analogi är en bils faktiska veckovisa bränsleförbrukning jämfört med den siffra som tillverkaren anger.
Mjukvarutestningsmått – Förbättrar effektiviteten och effektiviteten i en mjukvarutestprocess.
Mjukvarutestningsmått eller mjukvarutestmätning är den kvantitativa indikationen på omfattning, kapacitet, dimension, mängd eller storlek hos något attribut hos en process eller produkt.
Exempel för mjukvarutestmätning: Totalt antal defekter
Varför är testmått viktiga?
”Vi kan inte förbättra det vi inte kan mäta.” Testmått finns för att göra testprocessen mätbar.
- Bestäm vad nästa fas av aktiviteterna ska vara
- Ge bevis för ett påstående eller en förutsägelse om kvalitet
- Identifiera vilken typ av förbättring som krävs
- Motivera en förändring av process eller teknik
Läs mer om den Vikten av testmått
Typer av testmått
- Processmått: Den kan användas för att förbättra processeffektiviteten hos SDLC (Programvaruutveckling livscykel)
- Produktstatistik: Det handlar om kvaliteten på mjukvaruprodukten
-
Projektmått: Den kan användas för att mäta effektiviteten hos ett projektteam eller något annat testverktyg som används av teammedlemmarna
Att välja rätt mätvärden är viktigare än att samla in många av dem. Tänk på följande innan du bestämmer dig för en uppsättning:
- Fixa målgruppen för den metriska förberedelsen
- Definiera målet för mätvärden
- Introducera alla relevanta mått baserat på projektbehov
- Väg kostnad och nytta för varje mätvärde och den projektlivscykelfas där det levererar mest värde.
Manuella testmått
In Mjukvaruutveckling, Manuella testmått klassificeras i två klasser
- Basmått
- Beräknade mätvärden
Basmått är rådata som samlats in av testanalytiker under testfallsutvecklingen och exekveringen (# av testfall utförda, # av testfall). Medan beräknade mätvärden härleds från data som samlas in i basmått. Beräknade mätvärden följs vanligtvis av testhanteraren i testrapporteringssyfte (% komplett, % testtäckning).
Beroende på projekt eller affärsmodell är de viktigaste mätvärdena vanligtvis:
- Produktivitetsstatistik för testfallsexekvering
- Produktivitetsmått för förberedelse av testfall
- Defektmått
- Fel efter prioritet
- Defekter efter svårighetsgrad
- Defekt glidförhållande
Manuella kontra automatiserade testmetriker
Mätvärdena som beskrivs ovan förutsätter en manuellt exekverad svit. En automatiserad svit mäts annorlunda, eftersom exekveringsansträngning inte längre är begränsningen.
| Kriterier | Manuella testmetriker | Mätvärden för automatiseringstestning |
|---|---|---|
| Primärt fokus | Insats och utförandeframsteg | Täckning, stabilitet och körtid |
| Typiskt mått | Testfall körda per dag | Automatiseringstäckningsprocent |
| Kvalitetssignal | Upptäckta fel per testtimme | Instabil testfrekvens, andelen instabila tester |
| Kostnadsmått | Testarens timmar | Skriptunderhållstimmar per utgåva |
| Hastighetsmätning | Cykellängd i dagar | Svitens körningstid i minuter |
Automation Coverage = (Test cases automated / Total test cases) x 100 Flaky Test Rate = (Tests with inconsistent results / Total automated tests) x 100
Ojämn testfrekvens förtjänar särskild uppmärksamhet. När den passerar ungefär 5 procent börjar teamen ignorera röda builds, och vid den tidpunkten slutar sviten att tillhandahålla information oavsett hur hög täckningen är.
Testmåtts livscykel i mjukvaruteknik
| Olika stadier av Metrics livscykel | Steg under varje steg |
|---|---|
| Analys |
|
| Kommunicera |
|
| Utvärdering |
|
| Rapport |
|
Hur man beräknar ett testmått
| Sr# | Steg för att testa mätvärden | Exempelvis |
|---|---|---|
| 1 | Identifiera nyckeln mjukvarutestning processer som ska mätas | Testningsförlopp trackungprocessen |
| 2 | I det här steget använder testaren data som baslinje för att definiera måtten | Antalet testfall som planeras att utföras per dag |
| 3 | Bestämning av informationen som ska följas, en frekvens av trackungen och den ansvarige personen | Den faktiska testkörningen per dag kommer att fångas av testledaren i slutet av dagen |
| 4 | Effektiv beräkning, hantering och tolkning av de definierade måtten | De faktiska testfallen som utförs per dag |
| 5 | Identifiera förbättringsområdena beroende på tolkningen av definierade mått | If testfall utförandet inte uppfyller det överenskomna målet, undersöka orsaken och föreslå korrigerande åtgärder |
Exempel på en beräkning av testmetriker
Ta andelen testfall som körs som ett fungerande exempel. För att uttrycka körningsstatus som procentandel, använd formeln:
Percentage test cases executed= (No of test cases executed/ Total no of test cases written) X 100
Om 250 testfall skrevs och 175 har körts, blir resultatet (175 / 250) x 100 = 70 procent.
Samma mönster gäller för alla andra exekveringsparametrar: testfall som inte exekverats, godkänts, misslyckats och blockerats. Varje fall är helt enkelt en annan täljare över samma nämnare.
De viktigaste testmåtten för Track
Ordlistan i slutet av den här handledningen listar alla formler som används ofta. I praktiken behöver ett rapportpaket sällan fler än åtta. Det är dessa som konsekvent styr ett beslut.
| metrisk | Vad det svarar på | Se upp för |
|---|---|---|
| Procentuell körning av testfall | Hur långt har vi kommit i den planerade löprundan? | Säger ingenting om kvalitet, bara framsteg |
| Defektdensitet | Defekter per storleksenhet, så vilken modul är svagast? | Beror på ett konsekvent storleksmått |
| Effektivitet vid borttagning av defekter | Vilken andel fel upptäckte vi före lansering? | Kan endast slutföras efter att produktionsdata har anlänt |
| Defektläckage | Hur många fel nådde kunden? | Den enskilt viktigaste kvalitetssignalen |
| Testtäckning | Hur mycket av kraven uppfylls? | Hög bevakning med svaga påståenden bevisar ingenting |
| Index för defektens allvarlighetsgrad | Är de öppna defekterna allvarliga eller kosmetiska? | Att räkna fel utan viktning är vilseledande |
| Genomsnittlig tid för reparation | Hur snabbt vänder laget en lösning? | Skev av några långvariga defekter |
| Produktivitet för testkörning | Hur många fall slutför en testare per dag? | Uppmuntrar till ytliga tester om de används som mål |
Två formler värda att lägga till i ordlistan eftersom det är de som ledningen efterfrågar:
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ätfällan. Alla mätvärden som används som mål slutar vara ett bra mått. Sätt ett produktivitetsmål på 30 testfall per dag så skriver testarna 30 triviala. Rapportera mätvärden som en uppsättning, aldrig isolerat, och para ihop varje produktivitetssiffra med en kvalitetssiffra.
Ordlista för formel för programvarutestningsmått
- Omarbetningsansträngningsförhållande = (Faktiska omarbetningsinsatser som spenderats i den fasen/ totala faktiska ansträngningar som spenderats i den fasen) X 100
- Krav Kryp = (Totalt antal tillagda krav/antal initiala krav)X100
- Schemavarians = (Faktiskt leveransdatum – planerat leveransdatum)
- Kostnad för att hitta en defekt i testning = (Total ansträngning som lagts ner på testning/defekter som upptäckts i testning)
- Schemaglidning = (Faktiskt slutdatum – Beräknat slutdatum) / (Planerat slutdatum – Planerat startdatum) X 100
- Godkända testfall i procent = (Antal godkända test/Totalt antal utförda test) X 100
- Procentandel av misslyckade testfall = (Antal misslyckade tester/Totalt antal utförda tester) X 100
- Blockerade testfall i procent = (Antal blockerade tester/Totalt antal utförda tester) X 100
- Procentandel fasta defekter = (Defekter åtgärdade/Defekter rapporterade) X 100
- Accepterade defekter i procent = (Defekter accepterade som giltiga av utvecklarteamet /Totalt defekter som rapporterats) X 100
- Defekter Uppskjuten procentandel = (Defekter uppskjutna för framtida utgåvor /Totalt defekter som rapporterats) X 100
- Procent av kritiska defekter = (Kritiska defekter / Totala defekter som rapporterats) X 100
- Genomsnittlig tid för ett utvecklingsteam att reparera defekter = (Total tid för buggfixar/antal buggar)
- Antal körda tester per tidsperiod = Antal körda tester/Total tid
- Testa designeffektivitet = Antal designade tester /Total tid
- Testgranska effektivitet = Antal granskade tester /Total tid
- Felsökningsfrekvens, eller defekter per testtimme = Totalt antal defekter / Totalt antal testtimmar
