Menu

Vigtige softwaretestmålinger og målinger - forklaret med eksempler og grafer

important software test metrics

Prøv Vores Instrument Til At Fjerne Problemer

I softwareprojekter er det meget vigtigt at måle projektets kvalitet og omkostninger og effektivitet. Uden at måle disse kan et projekt ikke gennemføres med succes.

I dagens artikel vil vi lære med eksempler og grafer - Softwaretestmålinger og målinger og hvordan man bruger disse i softwaretestprocessen.

Der er en berømt erklæring: 'Vi kan ikke kontrollere ting, som vi ikke kan måle'.

Her betyder styring af projekterne, hvordan en projektleder / lead kan identificere afvigelser fra testplanen ASAP for at reagere i perfekt tidspunkt. Generering af testmålinger baseret på projektets behov er meget vigtig for at opnå kvaliteten af ​​den software, der testes.

Softwaretestmålinger og målinger

Softwaretestmålinger og målinger

Hvad du lærer:

Hvad er metrics til softwaretest?

En metrisk er et kvantitativt mål for, i hvilket omfang et system, en systemkomponent eller en proces har en given attribut.

Metrics kan defineres som “STANDARDER AF MÅLING ”.

Software metrics bruges til at måle projektets kvalitet. Simpelthen er en metric en enhed, der bruges til at beskrive en attribut. Metrisk er en skala til måling.

Antag generelt, 'Kilogram' er en metric til måling af attributten 'Vægt'. Tilsvarende i software, 'Hvor mange problemer findes i tusind linjer kode?', H også Antal udgaver er en måling, og antal linjer med kode er en anden måling. Metrisk defineres ud fra disse to målinger .

Eksempel på testmetrics:

  • Hvor mange defekter findes der i modulet?
  • Hvor mange testsager udføres pr. Person?
  • Hvad er testdækning%?

Hvad er måling af softwaretest?

Måling er kvantitativ angivelse af omfang, størrelse, dimension, kapacitet eller størrelse for en eller anden egenskab ved et produkt eller en proces.

Eksempel på testmåling: Samlet antal fejl.

qtp interview spørgsmål og svar til erfarne

Se nedenstående diagram for en klar forståelse af forskellen mellem måling og målinger.

forskel mellem måling og målinger

Hvorfor teste målinger?

Generering af softwaretestmålinger er det vigtigste ansvar for softwaretestledningen / manager.

Testmålinger bruges til at,

  1. Tag beslutningen om den næste fase af aktiviteter som f.eks. Estimer omkostningerne og tidsplanen for fremtidige projekter.
  2. Forstå den slags forbedring, der kræves for at få succes med projektet
  3. Tag en beslutning om den proces eller teknologi, der skal ændres osv.

Vigtigheden af ​​metrics til test af software:

Som forklaret ovenfor er testmålinger det vigtigste for at måle kvaliteten af ​​softwaren.

Nu, hvordan kan vi måle kvaliteten af ​​softwaren ved hjælp af metrics ?

Antag, at hvis et projekt ikke har nogen målinger, hvordan måles så kvaliteten af ​​det arbejde, der udføres af en testanalytiker?

For eksempel, En testanalytiker skal

  1. Design testcases til 5 krav
  2. Udfør de designede testsager
  3. Log fejl og behov for at mislykkes i de relaterede testsager
  4. Når manglen er løst, er vi nødt til at teste fejlen igen og udføre den tilsvarende mislykkede testtilfælde igen.

I ovenstående scenarie, hvis målinger ikke følges, vil det arbejde, der er udført af testanalytikeren, være subjektivt, dvs. Test rapport vil ikke have de rette oplysninger til at kende status for sit arbejde / projekt.

Hvis metrics er involveret i projektet, kan den nøjagtige status for hans / hendes arbejde med korrekte numre / data offentliggøres.

dvs. i testrapporten kan vi offentliggøre:

  1. Hvor mange testcases er designet pr. Krav?
  2. Hvor mange testtilfælde er der endnu ikke designet?
  3. Hvor mange testsager udføres?
  4. Hvor mange testsager er bestået / mislykkedes / blokeret?
  5. Hvor mange testsager er endnu ikke udført?
  6. Hvor mange mangler er identificeret, og hvad er sværhedsgraden af ​​disse mangler?
  7. Hvor mange testsager mislykkedes på grund af en bestemt fejl? etc.

Baseret på projektets behov kan vi have flere målinger end en ovennævnte liste for at kende projektets status i detaljer.

Baseret på ovenstående målinger får testledelsen / manager forståelsen af ​​nedenstående nøglepunkter.

  • % ge af afsluttet arbejde
  • % ge af det arbejde, der endnu ikke er afsluttet
  • Tid til at afslutte det resterende arbejde
  • Uanset om projektet forløber i henhold til tidsplanen eller forsinket? etc.

Baseret på metrics, hvis projektet ikke skal gennemføres i henhold til tidsplanen, vil lederen alarmere over for klienten og andre interessenter ved at angive grundene til, at der er forsinket for at undgå overraskelser i sidste øjeblik.

Metrics livscyklus

Metrics livscyklus

Typer af manuelle testmålinger

Testmålinger er hovedsageligt opdelt i 2 kategorier.

  1. Grundlæggende målinger
  2. Beregnede metrics

Grundlæggende målinger: Base-metrics er de metrics, der stammer fra de data, der er indsamlet af testanalytikeren under testsagens udvikling og udførelse.

Disse data spores i hele testlivscyklussen. Dvs. indsamling af data som Total nr. af testcases udviklet til et projekt (eller) nr. af testsager skal udføres (eller) nej. af testsager bestået / mislykket / blokeret osv.

Beregnede metrics: Beregnede metrics er afledt af de data, der er indsamlet i basismetrics. Disse målinger spores normalt af testledningen / manager til testrapporteringsformål.

Eksempler på metrics til softwaretest

Lad os tage et eksempel til at beregne forskellige testmålinger, der bruges i softwaretestrapporter:

Nedenfor er tabelformatet for data hentet fra testanalytikeren, der faktisk er involveret i testning:

Eksempel på software-testmålinger

Definitioner og formler til beregning af metrics:

# 1)% ge Test sager udført : Denne metric bruges til at opnå eksekveringsstatus for testsagerne udtrykt i% ge.

% ge Test sager udført = ( Antal eksekverede testsager / Samlet nr. af de skriftlige testsager) * 100.

Så fra ovenstående data,
% ge Testcases udført = (65/100) * 100 = 65%

# 2)% ge Test sager ikke udført : Denne metric bruges til at opnå testens ventende udførelsesstatus i% ge.

% ge Test sager ikke udført = ( Antal testsager, der ikke er udført / Samlet nr. af de skriftlige testsager) * 100.

Så fra ovenstående data,
% ge Test tilfælde blokeret = (35/100) * 100 = 35%

Test metrics graf 1

Test metrics graf 2

# 3)% ge Test tilfælde bestået : Denne metric bruges til at opnå Pass% ge af de udførte testsager.

% ge Testcases bestået = ( Antal testsager bestået / Samlet nr. af eksekverede testsager) * 100.

Så fra ovenstående data,
% ge Testcases bestået = (30/65) * 100 = 46%

# 4)% ge Test tilfælde mislykkedes : Denne metric bruges til at opnå Fail% ge af de udførte testsager.

% ge Test tilfælde mislykkedes = ( Antal testsager mislykkedes / Samlet nr. af eksekverede testsager) * 100.

Så fra ovenstående data,
% ge Testcases bestået = (26/65) * 100 = 40%

# 5)% ge Test tilfælde blokeret : Denne metric bruges til at opnå den blokerede% ge af de udførte testsager. En detaljeret rapport kan indsendes ved at angive den faktiske årsag til at blokere testsagerne.

% ge Test tilfælde Blokeret = ( Antal testsager Blokeret / Samlet nr. af eksekverede testsager) * 100.

Så fra ovenstående data,
% ge Test tilfælde blokeret = (9/65) * 100 = 14%

Test metrics graf 3

Test metrics graf 4

# 6) Defektdensitet= Antal identificerede mangler / størrelse

( Her betragtes 'størrelse' som et krav. Derfor beregnes defektdensiteten her som et antal defekter identificeret pr. Krav. Tilsvarende kan defektdensitet beregnes som et antal identificerede defekter pr. 100 linier kode (ELLER) Antal defekter identificeret pr. Modul osv. )

Så fra ovenstående data,
Defektdensitet = (30/5) = 6

# 7) Effektivitet til fjernelse af defekter (DRE)= ( Antal defekter fundet under QA-test / (antal defekter fundet under QA-test + antal defekter fundet af slutbruger)) * 100

DRE bruges til at identificere systemets testeffektivitet.
Antag, at vi under udvikling og QA-test har identificeret 100 defekter.
Efter QA-testen, under Alpha & Beta-test, identificerede slutbrugeren / klienten 40 fejl, som kunne have været identificeret i QA-testfasen.

Nu beregnes DRE som,
DRE = (100 / (100 + 40)) * 100 = (100/140) * 100 = 71%

# 8) Defekt lækage: Defektlækage er den metric, der bruges til at identificere effektiviteten af ​​QA-testen dvs. hvor mange fejl, der er gået glip af / glider under QA-testen.

Defekt lækage = ( Antal defekter fundet i UAT / antal defekter fundet i QA-test.) * 100

Antag, at vi under udvikling og QA-test har identificeret 100 defekter.
Efter QA-testen identificerede slutbruger / klient under Alpha- og Beta-test 40 fejl, som kunne have været identificeret under QA-testfasen.

Fejllækage = (40/100) * 100 = 40%

# 9) Mangler efter prioritet : Denne metric bruges til at identificere nr. af mangler identificeret baseret på alvorligheden / prioriteten af ​​den defekt, der bruges til at bestemme kvaliteten af ​​softwaren.

% ge Kritiske defekter = Antal identificerede kritiske defekter / Samlet nr. af identificerede mangler * 100
Fra de tilgængelige data i ovenstående tabel
% ge Kritiske fejl = 6/30 * 100 = 20%

% ge Høje defekter = Antal identificerede høje mangler / Samlet nr. af identificerede mangler * 100
Fra de tilgængelige data i ovenstående tabel
% ge Høje fejl = 10/30 * 100 = 33,33%

% ge Medium defekter = Antal identificerede medium defekter / Total nr. af identificerede mangler * 100
Fra de tilgængelige data i ovenstående tabel
% ge Medium fejl = 6/30 * 100 = 20%

% ge lave mangler = antal identificerede lave mangler / samlet nr. af identificerede mangler * 100
Fra de tilgængelige data i ovenstående tabel
% ge lave mangler = 8/30 * 100 = 27%

Test metrics graf 5

Anbefalet læsning=> Sådan skriver du en effektiv testoversigtsrapport

Konklusion

De målinger, der er angivet i denne artikel, bruges hovedsageligt til at generere Daglig / ugentlig statusrapport med nøjagtige data under testsagens udvikling / udførelsesfase, og dette er også nyttigt til at spore projektets status og kvalitet af softwaren.

Om forfatteren : Dette er et gæstepost af Anuradha K. Hun har 7+ års erfaring med softwaretest og arbejder i øjeblikket som konsulent for et MNC. Hun har også godt kendskab til test af mobilautomatisering.

Hvilke andre testmålinger bruger du i dit projekt? Lad os som sædvanligt vide dine tanker / spørgsmål i kommentarerne nedenfor.

Anbefalet læsning

^