Meny

Viktige målinger og målinger av programvaretest - forklart med eksempler og grafer

important software test metrics

Prøv Instrumentet Vårt For Å Eliminere Problemer

I programvareprosjekter er det viktigst å måle kvaliteten, kostnaden og effektiviteten til prosjektet og prosessene. Uten å måle disse kan ikke et prosjekt fullføres.

I dagens artikkel vil vi lære med eksempler og grafer - Programvare Test målinger og målinger og hvordan du bruker disse i programvaretestprosessen.

Det er en kjent uttalelse: 'Vi kan ikke kontrollere ting som vi ikke kan måle'.

Her betyr det å kontrollere prosjektene hvordan en prosjektleder / leder kan identifisere avvikene fra testplanen ASAP for å reagere i perfekt tid. Generering av testmålinger basert på prosjektets behov er veldig viktig for å oppnå kvaliteten på programvaren som testes.

Programvare Test målinger og målinger

Programvare testing målinger og målinger

Hva du vil lære:

Hva er beregning av programvaretesting?

En beregning er et kvantitativt mål på i hvilken grad et system, systemkomponent eller prosess har et gitt attributt.

Beregninger kan defineres som “STANDARDER AV MÅL ”.

Programvare beregninger brukes til å måle kvaliteten på prosjektet. Enkelt, en beregning er en enhet som brukes til å beskrive et attributt. Metrisk er en skala for måling.

Anta at 'Kilogram' generelt er en beregning for å måle attributtet 'Vekt'. Tilsvarende, i programvare, 'Hvor mange problemer finnes i tusen linjer med kode?', H også Antall problemer er en måling og antall linjer med kode er en annen måling. Metrisk er definert fra disse to målingene .

Eksempel på testberegninger:

  • Hvor mange mangler finnes i modulen?
  • Hvor mange testsaker blir utført per person?
  • Hva er testdekning%?

Hva er måling av programvaretest?

Måling er kvantitativ indikasjon på omfang, mengde, dimensjon, kapasitet eller størrelse på noe attributt til et produkt eller en prosess.

Eksempel på testmåling: Totalt antall feil.

Se diagrammet nedenfor for en klar forståelse av forskjellen mellom måling og beregning.

forskjellen mellom måling og beregninger

Hvorfor teste beregninger?

Generering av testvariabler for programvare er det viktigste ansvaret for programvaretestlederen / lederen.

Testmålinger er vant til,

  1. Ta avgjørelsen for neste fase av aktiviteter, for eksempel, estimer kostnadene og tidsplanen for fremtidige prosjekter.
  2. Forstå hva slags forbedring som kreves for å lykkes med prosjektet
  3. Ta en beslutning om prosessen eller teknologien som skal endres osv.

Viktigheten av beregning av programvaretest:

Som forklart ovenfor er testmålinger det viktigste for å måle kvaliteten på programvaren.

Nå, hvordan kan vi måle kvaliteten på programvaren ved å bruke Metrics ?

Anta at hvis et prosjekt ikke har noen beregninger, hvordan måles kvaliteten på arbeidet som blir utført av en testanalytiker?

For eksempel, En testanalytiker må,

  1. Utform testkassene for 5 krav
  2. Utfør de utformede testtilfellene
  3. Logg feilene og trenger å mislykkes i de relaterte testtilfellene
  4. Etter at mangelen er løst, må vi teste feilen på nytt og utføre den tilsvarende mislykkede testsaken på nytt.

I det ovennevnte scenariet, hvis ikke beregninger følges, vil arbeidet fullført av testanalytikeren være subjektivt, dvs. Testrapport vil ikke ha riktig informasjon for å vite statusen til arbeidet / prosjektet hans.

Hvis beregninger er involvert i prosjektet, kan den eksakte statusen for hans / hennes arbeid med riktige tall / data publiseres.

dvs. i testrapporten kan vi publisere:

  1. Hvor mange testtilfeller er designet per krav?
  2. Hvor mange testsaker er det ennå ikke å utforme?
  3. Hvor mange prøvesaker blir utført?
  4. Hvor mange testsaker er bestått / mislyktes / sperres?
  5. Hvor mange testtilfeller er ennå ikke utført?
  6. Hvor mange feil er identifisert og hva er alvorlighetsgraden av disse feilene?
  7. Hvor mange testsaker mislyktes på grunn av en bestemt feil? etc.

Basert på prosjektets behov kan vi ha flere beregninger enn en ovennevnte liste, for å vite status for prosjektet i detalj.

Basert på de ovennevnte beregningene, vil testledelsen / lederen få forståelse for de nevnte hovedpoengene.

  • % ge av fullført arbeid
  • % ge av arbeidet som ennå ikke er fullført
  • På tide å fullføre gjenværende arbeid
  • Om prosjektet går i henhold til tidsplanen eller henger etter? etc.

Basert på beregningene, hvis prosjektet ikke skal fullføres i henhold til tidsplanen, vil lederen alarmere til klienten og andre interessenter ved å oppgi årsakene til at det henger etter for å unngå overraskelser i siste øyeblikk.

Metrics Life Cycle

Metrics Life Cycle

Typer av manuelle testmålinger

Testmålinger er hovedsakelig delt inn i 2 kategorier.

  1. Grunnmålinger
  2. Beregnede beregninger

Basis beregninger: Grunnmålinger er beregningene som er hentet fra dataene som ble samlet inn av testanalytikeren under utviklingen og gjennomføringen av testsaken.

Disse dataene vil bli sporet gjennom testens livssyklus. Dvs. samle inn data som Total nr. av testsaker utviklet for et prosjekt (eller) nei. av testsaker må utføres (eller) nei. av testsaker bestått / mislyktes / sperret etc.

Beregnede beregninger: Beregnede beregninger er avledet fra dataene som er samlet i grunnverdier. Disse beregningene blir vanligvis sporet av testledelsen / lederen for testrapporteringsformål.

Eksempler på beregning av programvaretesting

La oss ta et eksempel for å beregne forskjellige testberegninger som brukes i testrapporter for programvare:

Nedenfor er tabellformatet for dataene hentet fra testanalytikeren som faktisk er involvert i testing:

Eksempel på beregning av programvaretesting

Definisjoner og formler for beregning av beregninger:

# 1)% ge Test tilfeller utført : Denne beregningen brukes til å oppnå eksekveringsstatus for testsakene når det gjelder% ge.

% ge Test tilfeller utført = ( Antall prøvesaker utført / Totalt nr. av testsaker skrevet) * 100.

Så fra dataene ovenfor,
% ge Testtilfeller utført = (65/100) * 100 = 65%

# 2)% ge Test tilfeller ikke utført : Denne beregningen brukes til å oppnå den ventende utførelsesstatus for testsakene i%%.

% ge Test tilfeller ikke utført = ( Antall testsaker ikke utført / Totalt nr. av testsaker skrevet) * 100.

Så fra dataene ovenfor,
% ge Testtilfeller blokkert = (35/100) * 100 = 35%

Test beregninger graf 1

Test beregninger graf 2

# 3)% ge Test tilfeller bestått : Denne beregningen brukes til å oppnå Pass% ge av de utførte testsakene.

% ge Test tilfeller bestått = ( Antall prøvesaker Bestått / Totalt nr. av testsaker utført) * 100.

Så fra dataene ovenfor,
% ge Test tilfeller bestått = (30/65) * 100 = 46%

# 4)% ge Test tilfeller mislyktes : Denne beregningen brukes til å oppnå feil% ge av de utførte testsakene.

% ge Test tilfeller mislyktes = ( Antall testsaker Mislyktes / Totalt nr. av testsaker utført) * 100.

Så fra dataene ovenfor,
% ge Test tilfeller bestått = (26/65) * 100 = 40%

# 5)% ge Testtilfeller blokkert : Denne beregningen brukes til å oppnå den blokkerte% ge av de utførte testsakene. En detaljert rapport kan leveres ved å spesifisere den faktiske årsaken til å blokkere testsakene.

beste videospillbedriftene å jobbe for 2018

% ge Testtilfeller Blokkert = ( Antall testsaker Blokkert / Totalt nr. av testsaker utført) * 100.

Så fra dataene ovenfor,
% ge Testtilfeller blokkert = (9/65) * 100 = 14%

Test beregninger graf 3

Test beregninger graf 4

# 6) Defekt tetthet= Antall defekter identifisert / størrelse

( Her anses 'Størrelse' som et krav. Derfor beregnes mangeltettheten som et antall feil identifisert per krav. På samme måte kan defekt tetthet beregnes som et antall defekter identifisert per 100 linjer med kode (ELLER) Antall defekter identifisert per modul, etc. )

Så fra dataene ovenfor,
Defekt tetthet = (30/5) = 6

# 7) Effektivitet for fjerning av mangler (DRE)= ( Antall feil funnet under QA-testing / (Antall feil funnet under QA-testing + Antall feil funnet av sluttbruker)) * 100

DRE brukes til å identifisere testeffektiviteten til systemet.
Anta at vi under utvikling og QA-testing har identifisert 100 feil.
Etter QA-testen, under Alpha & Beta-testing, identifiserte sluttbrukeren / klienten 40 feil, som kunne ha blitt identifisert i løpet av QA-testfasen.

Nå vil DRE beregnes som,
DRE = (100 / (100 + 40)) * 100 = (100/140) * 100 = 71%

# 8) Feillekkasje: Defektlekkasje er beregningen som brukes til å identifisere effektiviteten av QA-testingen dvs. hvor mange mangler som blir savnet / glidd under QA-testen.

Feillekkasje = ( Antall feil funnet i UAT / antall feil funnet i QA-testing.) * 100

Anta at vi under utvikling og QA-testing har identifisert 100 feil.
Etter QA-testen, under Alpha & Beta-testing, identifiserte sluttbruker / klient 40 feil, som kunne ha blitt identifisert i løpet av QA-testfasen.

Feillekkasje = (40/100) * 100 = 40%

# 9) Feil etter prioritet : Denne beregningen brukes til å identifisere nei. av feil identifisert basert på alvorlighetsgraden / prioriteten til feilen som brukes til å bestemme kvaliteten på programvaren.

% ge Kritiske feil = Antall identifiserte kritiske feil / Totalt antall av defekter identifisert * 100
Fra dataene som er tilgjengelige i tabellen ovenfor,
% ge kritiske feil = 6/30 * 100 = 20%

% ge Høye mangler = Antall identifiserte høye mangler / Totalt antall av defekter identifisert * 100
Fra dataene som er tilgjengelige i tabellen ovenfor,
% ge høye feil = 10/30 * 100 = 33,33%

% ge Medium Defekter = Antall identifiserte Medium Defekter / Totalt nr. av defekter identifisert * 100
Fra dataene som er tilgjengelige i tabellen ovenfor,
% ge Medium feil = 6/30 * 100 = 20%

% ge lave mangler = antall identifiserte lave mangler / totalt nr. av defekter identifisert * 100
Fra dataene som er tilgjengelige i tabellen ovenfor,
% ge lave mangler = 8/30 * 100 = 27%

Test beregninger diagram 5

Anbefalt lesing=> Hvordan skrive en effektiv testsammendragsrapport

Konklusjon

Beregningene gitt i denne artikkelen brukes hovedsakelig til å generere Daglig / ukentlig statusrapport med nøyaktige data under testutviklings / utførelsesfasen, og dette er også nyttig for å spore prosjektstatus og kvalitet på programvaren.

Om forfatteren : Dette er et gjestepost av Anuradha K. Hun har 7+ års erfaring med programvaretesting og jobber for tiden som konsulent for et MNC. Hun har også god kunnskap om mobilautomatiseringstesting.

Hvilke andre testberegninger bruker du i prosjektet ditt? Som vanlig, gi oss beskjed om dine tanker / spørsmål i kommentarene nedenfor.

Anbefalt lesing

^