Menu

Testdækning i softwaretest (tip til maksimering af testdækning)

test coverage software testing

Prøv Vores Instrument Til At Fjerne Problemer

Software Testing Test Dækning Komplet guide: Sådan tester du mere, sparer tid og opnår bedre testresultater:

Softwaretest er en væsentlig aktivitet i softwareudviklingen og vedligeholdelsescyklussen. Det er en praksis, der ofte bruges til at bestemme og forbedre softwarekvaliteten.

Udvikling er mere systematisk i dag, og organisationer søger målinger for at teste fuldstændighed og effektivitet for at vise testafslutningskriterier. Af dem alle betragtes dækning som særlig værdifuld.

Hvad du lærer:

Hvad er testdækning?

Kort sagt, dækning er 'Hvad tester vi, og hvor meget tester vi?'

formørkelse ide til c / c ++

Testdækning hjælper med at overvåge testkvaliteten og hjælper testere med at oprette tests, der dækker områder, der mangler eller ikke er valideret.

test dækning

De fleste hold baserer deres dækningsberegninger alene på funktionelle krav. Det er også retfærdigt, fordi en applikation først og fremmest skal gøre, hvad den skal. Hvis ikke, dens hastighed eller sikkerhed eller brugervenlighed - intet af det betyder noget.

Men hvis dedikeret og uafhængig ikke-funktionel test hold arbejder på ydeevne, sikkerhed, brugervenlighedstest osv., så bliver de nødt til at spore deres krav hele vejen til udførelse gennem analyser af testdækning.

Testdækning og kodedækning

Testdækning forveksles ofte med kodedækning. Selvom de underliggende principper er de samme, er de to forskellige ting.

Kodedækning taler virkelig om enhedstestpraksis, der skal målrette mod alle områder af koden mindst én gang og udføres af udviklere.

Testdækning er derimod teste ethvert krav mindst én gang og er naturligvis en QA-teamaktivitet.

Hvad der virkelig kvalificerer sig til at være et dækket krav, afhænger af fortolkningen af ​​hvert hold.

For eksempel , Nogle hold kalder et krav dækket, hvis der er mindst en testsag mod det. Nogle gange er det dækket, hvis mindst et teammedlem er tildelt det. Eller hvis alle testsager, der er knyttet til det, udføres.

  • Hvis der er oprettet 10 krav og 100 tests - når disse 100 tests målretter mod alle de 10 krav og ikke udelader nogen - kalder vi dette tilstrækkelig testdækning på designniveau.
  • Når kun 80 af de oprettede tests udføres, og målrette kun mod 6 af kravene. Vi siger, at 4 krav ikke er dækket, selvom 80% af testen er udført. Dette er dækningsstatistikker på et eksekveringsniveau.
  • Når kun 90 tests, der vedrører 8 krav, har tildelt testere, og resten af ​​dem ikke er det, siger vi, at testopgavens dækning er 80% (8 ud af 10 krav).

Det er også vigtigt, hvornår dækningen skal beregnes.

Hvis du gør dette for tidligt i processen, vil du se en masse huller, fordi tingene stadig er ufuldstændige. Så det anbefales generelt at vent til den sidste bygning dvs. Final Regression Build. Dette giver en korrekt dækning af de test, der er udført for de givne krav.

Læs også => Styringsproces for frigivelse og implementering

Min erfaring

Scene 8 år siden: Da jeg havde to års erfaring i softwaretestindustrien, tænkte jeg, at det var okay, hvis jeg ikke kender nogle grundlæggende om softwaretest, som noget man kan lære med erfaring, og det gør jeg også.

Jeg havde ret - og også forkert.

Lige fordi med erfaring lærer du at se et større billede, du forstår den virkelige betydning af 'Kritisk situation' og du forstår slutbrugeren mere.

Forkert, fordi ingen af ​​de nævnte ting kræver erfaring, men tidlig læring, hvilket jeg forstod meget sent. Det er den opmuntrende faktor til at skrive dette indlæg.

Maksimer testdækningen på kortere tid

Her er min erfaring fra et af interviewene på det tidspunkt:

Hvordan sørger du for, at testdækningen er komplet eller maksimal? Blev jeg spurgt.

Ummmm …… Jeg sørger for at teste enhver funktionalitet , Jeg sagde.

S o du siger, at når du først har testet alle funktionerne, føler du, at du har dækket et maksimalt antal applikationer / produkter, hvad angår test , svarede intervieweren.

Ummm ... godt… .ummm…. Ja, for når du tester alle funktionerne, er du sikker på applikationens / produktets adfærd, Jeg støttede mit svar .

Jeg er enig, men mit spørgsmål er - vil det give dig tillid til, at din testdækning er maksimal eller fuldstændig? intervieweren var ikke i humør til at lade mig gå.

Nu voksede jeg utålmodig, ukendt om det faktum, at jeg skulle lære et af de vigtigste emner om softwaretest - ' Testdækning ” .

I stedet for at gengive uddragene af interviewet opsummerer jeg her, hvad jeg lærte om Testing Coverage, den dag. Men før det skal vi være klare på et punkt - testdækning betyder ikke nogensinde at vide, om du tester nok eller ej, og det betyder heller ikke, at du tester perfekt eller ej.

Test dækning betydning

Testdækning kan have en anden betydning i forskellige sammenhænge. Lad os opdage disse sammenhænge en efter en:

Produktdækning - Hvilke aspekter af produktet så du på?

Ja, når testdækningen måles i form af produkt, er det vigtigste område at fokusere på - hvilke produktområder, du har testet, og hvilke forbliver uprøvede?

Eksempel 1:

Hvis “kniv” er et produkt, tester du; bare ikke koncentrere dig om at kontrollere, om det skærer grøntsagerne / frugterne ordentligt. Der er andre aspekter at se efter som - brugeren skal kunne håndtere det komfortabelt.

Eksempel 2:

Hvis 'notesblok' er en applikation, tester du, det er en nødvendighed at kontrollere relevante funktioner.

Men andre aspekter, der skal tages hånd om, er - applikationen reagerer korrekt, mens du bruger andre applikationer samtidigt, applikationen går ikke ned når brugeren forsøger at gøre noget usædvanligt , får brugeren ordentlige advarsler / fejlmeddelelser, brugeren er i stand til let at forstå og bruge applikationen, hjælpeindhold er tilgængeligt, når det er nødvendigt.

Hvis du ikke ser på de nævnte scenarier, kan du ikke hævde, at testdækningen for applikationen er komplet.

youtube til mp3 over 20 min

Risikodækning - Hvilke risici har du testet for?

Risikodækning er et andet aspekt for at have komplet testdækning. Du kan ikke mærke produktet eller applikationen som 'testet', før du også tester de tilknyttede risici. Dækning af tilknyttede risici er en vigtig faktor i den samlede testdækning.

Eksempel 1:

Når en tester fortæller dig, at han / hun fuldt ud har testet flyets interne system, og det fungerer fint, mens det tester et fly, mens det kun er flyets evne til at flyve, blev det ikke dækket under testen - hvad ville din reaktion være?

Nå, det er hvad risikodækning betyder. At identificere risiko i henhold til applikationen / produktet og teste det grundigt er altid en god praksis.

Eksempel 2:

Under test af et e-handelswebsted overvejede tester enhver effektiv faktor, men overvejede ikke risikoen for, at antallet af brugere besøgte webstedet samtidigt og på Super TILBUD-dagen, viste den ikke betragtede risiko sig at være en kæmpe fejltagelse.

Anbefalet læsning =>

Krav til dækning - Hvilke krav har du testet for?

Hvis et produkt eller en applikation er udviklet meget godt, men hvis den ikke matcher kundens krav, er den ikke til nogen nytte. Kravsdækning under test er lige så vigtig som produktdækning.

Eksempel 1:

Spændt efter familiefunktionen bad du skrædderen om at sy din kjole og tage de påfuglblå showknapper på halsen på.

Mens han syede kjolen, tænkte skrædderen, at det ikke ville se godt ud at sætte disse knapper på halsen, så han syede en gyldenfarvet kant i stedet. På prøvedagen råbte den ulykkelige kunde bestemt til skrædderen for ikke at holde sig til kravene.

Eksempel 2:

Under testning af en chatapplikation tog testeren sig af alle de vigtige punkter, som flere brugere chatter i en gruppe, to brugere chatter uafhængigt, alle typer tilgængelige humørikoner, opdateringer sendt til brugeren med det samme osv. Men glemte at se på kravdokumentet, som tydeligt nævnte, at når to brugere chatter uafhængigt, skal videoopkaldsmulighed være aktiveret.

Klienten markedsførte chatapplikationen og hævdede, at den ville tillade opkald, mens to brugere chatter uafhængigt. Du kan forestille dig, hvad der ville være sket med chatapplikationen.

Også Læs => Sådan oprettes krav Sporbarhedsmatrix

Hvordan vedtager man en ordentlig testdækningsmetode?

Bevidsthed er alt:

Første ting først, QA-teamet skal vide, hvor meget arbejde der er involveret, og hvor designopgaverne ligger. På denne måde vil de være opmærksomme på, hvis der skal tilføjes flere tests. For at gøre dette kan du bruge en RTM, som det er den typiske praksis.

=> Tjek denne artikel for at vide mere om den, og hvordan du bruger den: Sådan oprettes krav Sporbarhedsmatrix - Præcis proces med prøve skabelon

For det andet skal du kontrollere ressourcetildeling og testudførelsesproces for at se om alt testes på en mere effektiv måde.

En tabel som nedenfor kan være nyttig:

TesttypeI alt tilfældeUdførte sagerStatusKommentarer
Funktionel1008050 pass, 30 mislykkes
Kompatibilitet100halvtreds45 passerer, 5 mislykkes
Anvendelighed10010098 pass, 2 mislykkes
Endelig regression10010099 pas, 1 mislykkes

Hvordan kan man sikre, at alt testes?

  • Hver tester skal være opmærksom på kravene og testmetoderne
  • Prioriter dine krav og fokuser din energi, hvor det er mest nødvendigt
  • Bliv informeret om, hvordan en bestemt frigivelse er forskellig fra den forrige, så du kan identificere kritiske krav mere præcist og fokusere på maksimal positiv dækning
  • Tilpas testautomatisering
  • Brug teststyringsværktøjer at altid være i know
  • Smart arbejdsopgave - Kanaliser dine bedste ressourcer mod kritiske opgaver, og lad nye testere udforske mere for et nyt perspektiv
  • Vedligeholdelse af en tjekliste til alle opgaver og diverse aktiviteter
  • Interagere mere med dine Dev / Scrum / BA-teams for at få indsigt i applikationsadfærden
  • Hold styr på alle dine byggecyklusser og rettelser
  • Identificer de mest påvirkende problemer i den oprindelige builds selv (når det er muligt), så de senere kan arbejde for bedre stabilitet og nå de områder, der er blokeret af tidligere problemer

Kritiske områder og metoder til effektiv testning

effektiv test

# 1)Ressource sammenblanding: Udveksle opgaver mellem dine teammedlemmer. Dette hjælper med at forbedre engagement og forhindre koncentration af viden.

#to)Kompatibilitetsdækning: Sørg for, at du er opmærksom og inkluderer forskellige browsere og platforme for at teste din ansøgning.

# 3)Ejendomsret: Gør testere ansvarlige og giv dem frie tøjler (med overvågning og support selvfølgelig) til det modul / opgave, de arbejder på. Dette hjælper med at opbygge ansvar og lader dem prøve kreative måder i stedet for at følge den slagne vej.

# 4)Frister: At kende frigørelsesfristerne inden påbegyndelsen af ​​testfasen hjælper med effektiv planlægning

# 5)Meddelelse : Hold kontakten med udvikleren og andre hold imellem frigivelsescyklusser for at vide, hvad der foregår.

# 6)Oprethold en RTM: Fungerer som et godt derivat af Interessenter eller klienter , baseret på hvilken frigivelsesplanen kan bekræftes

Fordele ved at teste dækningsbevidsthed for en tester:

  • Det hjælper primært med at prioritere testopgaver
  • Det hjælper med at opnå 100% kravsdækning eller med andre ord forhindrer det lækage af krav
  • Effektanalyse bliver lettere
  • Nyttig til bestemmelse af EXIT-kriterier
  • Aktiverer en testledning til at forberede en klar rapport om lukning af test

Konklusion

Testdækning slutter ikke med de nævnte sammenhænge. Der er mange andre punkter, der skal overvejes, når det kommer til testdækning.

Det er ikke altid sandt, at resultaterne er bedre, når du tester mere. Faktisk, når du tester mere uden tilsyneladende strategi, vil du sandsynligvis ende med at investere meget tid.

Med en mere struktureret tilgang, der sigter mod 100% dækning af kravene og effektive testmetoder, går du ikke på kompromis med kvaliteten.

Vi håber, at de teknikker, der er beskrevet i denne artikel, vil give dig nogle tip.

Hæld dine kommentarer og synspunkter om indlægget. Som normalt elsker vi at høre fra dig.

Anbefalet læsning

^