Meny

Testdekning i programvaretesting (tips for å maksimere testdekning)

test coverage software testing

Prøv Instrumentet Vårt For Å Eliminere Problemer

Programvare Testing Test Dekning Komplett Guide: Hvordan teste mer, spare tid og oppnå bedre testresultater:

Programvaretesting er en viktig aktivitet i programvarens utvikling og vedlikeholdssyklus. Det er en praksis som ofte brukes til å bestemme og forbedre programvarekvaliteten.

Utvikling er mer systematisk i dag og organisasjoner søker tiltak for å teste fullstendighet og effektivitet for å vise kriterier for fullføring av test. Av dem alle anses dekning som spesielt verdifull.

Hva du vil lære:

Hva er testdekning?

Enkelt sagt er dekning 'Hva tester vi og hvor mye tester vi?'

Testdekning hjelper med å overvåke testkvaliteten, og hjelper testere med å lage tester som dekker områder som mangler eller ikke er validert.

testdekning

De fleste lag baserer sine dekningsberegninger på funksjonelle krav alene. Det er også rettferdig fordi først og fremst en applikasjon skal gjøre det den skal. Hvis ikke, hastighet eller sikkerhet eller brukervennlighet - ingenting av det betyr noe.

Imidlertid hvis dedikert og uavhengig ikke-funksjonell testing team jobber med ytelse, sikkerhet, brukervennlighetstesting osv., så må de spore kravene sine helt til utførelse gjennom analyser av testdekning.

hvordan åpne en XML-fil i Word

Test dekning og kodedekning

Testdekning forveksles ofte med kodedekning. Selv om de underliggende prinsippene er de samme, er de to forskjellige ting.

Kodedekning snakker virkelig om enhetstestpraksis som må være målrettet mot alle områdene av koden minst en gang og gjøres av utviklere.

Testdekning er derimot teste alle krav minst en gang og er åpenbart en QA-teamaktivitet.

Hva som virkelig kvalifiserer til å være et dekket krav, avhenger av tolkningen av hvert lag.

For eksempel , Noen lag kaller et krav dekket hvis det er minst en testsak mot det. Noen ganger dekkes det hvis minst ett teammedlem er tildelt det. Eller hvis alle testtilfellene som er knyttet til den, blir utført.

  • Hvis det er laget 10 krav og 100 tester - når disse 100 testene retter seg mot alle de 10 kravene og ikke utelater noen - kaller vi dette tilstrekkelig testdekning på designnivå.
  • Når bare 80 av de opprettet testene blir utført, og målretter bare mot 6 av kravene. Vi sier at 4 krav ikke dekkes, selv om 80% av testingen er utført. Dette er dekningsstatistikk på et utførelsesnivå.
  • Når bare 90 tester relatert til 8 krav har tildelt testere, og resten av dem ikke er det, sier vi at testoppgavedekningen er 80% (8 av 10 krav).

Det er også viktig når du skal beregne dekning.

Hvis du gjør dette for tidlig i prosessen, vil du se mange hull fordi ting fortsatt er ufullstendige. Så det anbefales generelt å vent til den siste bygningen dvs. Final Regression Build. Dette vil gi en korrekt dekning av testene som er utført for de gitte kravene.

Les også => Prosess for styring av frigjøring og distribusjon

Min erfaring

Scene for 8 år siden: Da jeg hadde to års erfaring i programvaretestindustrien, tenkte jeg at det var greit hvis jeg ikke vet noen grunnleggende om programvaretesting som noe man kan lære med erfaring, og jeg også vil gjøre.

Jeg hadde rett - og også feil.

Rett fordi med erfaring lærer du å se et større bilde, du forstår den virkelige betydningen av 'Kritisk situasjon' og du forstår sluttbrukeren mer.

Feil fordi ingen av de nevnte tingene krever erfaring, men tidlig læring, noe jeg forsto veldig sent. Det er den oppmuntrende faktoren til å skrive dette innlegget.

Maksimer testdekningen på kortere tid

Her er min erfaring fra et av intervjuene på den tiden:

Hvordan sørger du for at testdekningen er fullstendig eller maksimal? Jeg ble spurt.

Ummmm …… Jeg sørger for at jeg tester alle funksjoner , Jeg sa.

S o du sier at når du først har testet alle funksjonene, føler du at du har dekket maksimalt med applikasjon / produkt, når det gjelder testing intervjuet intervjueren.

Ummm ... vel ... .mmmm ... .ja, for når du tester alle funksjonene, er du trygg på applikasjonens / produktets oppførsel, Jeg støttet svaret mitt .

Jeg er enig, men spørsmålet mitt er - vil det gi deg tillit til at testdekningen din er maksimal eller fullstendig? intervjueren var ikke i humør for å la meg gå.

Nå ble jeg utålmodig, ukjent med det faktum at jeg skulle lære et av de viktigste emnene om programvaretesting - ' Testdekning ” .

I stedet for å gjengi utdragene av intervjuet, oppsummerer jeg her det jeg lærte om Testing Coverage den dagen. Men før det, skal vi være klare på ett punkt - testdekning betyr ikke noen gang å vite om du tester nok eller ikke, det betyr heller ikke at du tester perfekt eller ikke.

Testdekning betydning

Testdekning kan ha en annen betydning i annen sammenheng. La oss oppdage disse sammenhengene en etter en:

Produktdekning - Hvilke aspekter av produktet så du på?

Ja, når testdekning måles i form av produkt, er hovedområdet å fokusere på - hvilke produktområder du har testet og som forblir uprøvd?

Eksempel 1:

Hvis “kniv” er et produkt, tester du; bare ikke konsentrer deg om å sjekke om det kutter grønnsakene / fruktene ordentlig. Det er andre aspekter å se etter, for eksempel - brukeren skal kunne håndtere det komfortabelt.

Eksempel 2:

Hvis 'notisblokk' er et program, tester du, og det er en nødvendighet å sjekke relevante funksjoner.

Men andre aspekter som skal tas vare på er - applikasjonen reagerer riktig mens du bruker andre applikasjoner samtidig, applikasjonen krasjer ikke når brukeren prøver å gjøre noe uvanlig , får brukeren riktige advarsler / feilmeldinger, brukeren er i stand til å forstå og bruke applikasjonen enkelt, hjelpeinnhold er tilgjengelig når det er nødvendig.

Hvis du ikke ser på de nevnte scenariene, kan du ikke hevde at testdekningen for applikasjonen er fullført.

Risikodekning - Hvilke risikoer har du testet for?

Risikodekning er et annet aspekt for å ha fullstendig testdekning. Du kan ikke merke produktet eller applikasjonen som “testet” før du også tester de tilhørende risikoene. Dekning av tilhørende risiko er en viktig faktor i den totale testdekningen.

Eksempel 1:

Når en tester forteller deg at han / hun har testet det indre systemet til flyet, og det fungerer bra, men bare flyets evner til flyet ble ikke dekket under testing mens du testet - hva ville din reaksjon være?

dijkstras algoritme java ved hjelp av prioritetskø

Vel, det er hva risikodekning betyr. Å identifisere risiko i henhold til applikasjonen / produktet og teste den grundig er alltid en god praksis.

Eksempel 2:

Mens testeren av et e-handelssted vurderte tester hver eneste effektive faktor, men vurderte ikke risikoen for at antall brukere skulle få tilgang til nettstedet samtidig og på SuperTILBUD-dagen, viste den ikke-ansettede risikoen seg å være en stor feil.

Anbefalt lesing =>

Kravsdekning - Hvilke krav har du testet for?

Hvis et produkt eller applikasjon er utviklet veldig bra, men hvis det ikke samsvarer med kundens krav, er det ikke til nytte. Kravdekning under testing er like viktig som produktdekning.

Eksempel 1:

Spent for familiefunksjonen ba du skredderen om å sy kjolen din og ta på deg de påfuglblå showknappene på halsen.

Mens du syr kjolen, tenkte skredderen at det å sette knappene på halsen ikke vil se bra ut, så han sydde en gylden farget kant i stedet. På prøvedagen, absolutt, ropte den ulykkelige kunden til skredderen for ikke å holde seg til kravene.

Eksempel 2:

Mens han testet en chat-applikasjon, tok tester seg av alle viktige punkter som flere brukere som chatter i en gruppe, to brukere som chatter uavhengig, alle typer tilgjengelige uttrykksikoner, oppdateringer sendt til brukeren umiddelbart etc. men glemte å se på kravdokumentet, som tydelig nevnte at når to brukere chatter uavhengig, bør alternativet for videosamtaler være aktivert.

Klienten markedsførte chat-applikasjonen og hevdet at den ville tillate anrop, mens to brukere chatter uavhengig. Du kan forestille deg hva som ville ha skjedd med chat-applikasjonen.

Også lese => Hvordan lage krav Sporbarhetsmatrise

Hvordan vedta en riktig metode for testdekning?

Bevissthet er alt:

Første ting først må QA-teamet vite hvor mye arbeid det er involvert i og hvor designoppgavene ligger. På denne måten vil de være klar over om flere tester skal legges til. For å gjøre dette kan du bruke en RTM som det er vanlig praksis.

=> Sjekk denne artikkelen for å vite mer om den og hvordan du bruker den: Hvordan lage krav Sporbarhetsmatrise - nøyaktig prosess med eksempelmal

For det andre, sjekk ressurstildeling og testutførelsesprosess for å se om alt blir testet på en mer effektiv måte.

En tabell som nedenfor kan være nyttig:

TesttypeTotalt antall tilfellerUtførte sakerStatusKommentarer
Funksjonell1008050 pass, 30 mislykkes
Kompatibilitet100femti45 pass, 5 mislykkes
Brukervennlighet10010098 pass, 2 mislykkes
Endelig regresjon10010099 pass, 1 mislykkes

Hvordan sørge for at alt blir testet?

  • Hver tester bør være klar over kravene og testmetodene
  • Prioriter dine krav og fokuser energien din der det er mest nødvendig
  • Bli informert om hvordan en viss utgivelse er forskjellig fra den forrige, slik at du kan identifisere kritiske krav mer nøyaktig og fokusere på maksimal positiv dekning
  • Tilpass testautomatisering
  • Bruk verktøy for testhåndtering å alltid være i kunnskapen
  • Smart arbeidsoppgave - Kanaliser de beste ressursene dine mot kritiske oppgaver og la nye testere utforske mer for et nytt perspektiv
  • Vedlikeholde en sjekkliste for alle oppgaver og diverse aktiviteter
  • Samhandle mer med Dev / Scrum / BA-teamene dine for å få innsikt i applikasjonsatferden
  • Hold oversikt over alle byggesykluser og reparasjoner
  • Identifiser mest påvirkende problemer i den opprinnelige bygningen selv (når det er mulig) slik at de senere kan jobbe for bedre stabilitet og nå de områdene som er blokkert av tidligere problemer

Kritiske områder og metoder for effektiv testing

effektiv testing

#1)Ressurs jumbling: Utveksle oppgaver mellom teammedlemmene dine. Dette bidrar til å forbedre engasjementet og forhindre kunnskapskonsentrasjon.

#to)Kompatibilitetsdekning: Sørg for at du er klar over og inkluderer forskjellige nettlesere og plattformer for å teste søknaden din.

# 3)Eie: Gjør testere ansvarlige og gi dem frie tøyler (med overvåking og støtte selvfølgelig) for modulen / oppgaven de jobber med. Dette hjelper med å bygge ansvar og lar dem prøve kreative måter i stedet for å følge banket nedover veien.

# 4)Frister: Å kjenne fristene for utgivelse før testfasen begynner, hjelper med effektiv planlegging

# 5)Kommunikasjon : Hold kontakten med utvikleren og andre lag mellom utgivelsessyklusene for å vite hva som skjer.

# 6)Oppretthold en RTM: Fungerer som et godt derivat til Interessenter eller klienter , basert på hvilken utgivelsesplanen kan bekreftes

Fordeler med å teste dekningsbevissthet for en tester:

  • Det hjelper primært med å teste oppgaveprioritering
  • Det hjelper til med å oppnå 100% kravsdekning, eller med andre ord forhindrer det lekkasje av krav
  • Konsekvensanalyse blir lettere
  • Nyttig til å bestemme UTGANGskriterier
  • Gjør det mulig å få en testledning for å forberede en klar testavslutningsrapport

Konklusjon

Testdekning slutter ikke med de nevnte sammenhenger. Det er mange andre punkter som bør vurderes når det gjelder testdekning.

Det er ikke alltid sant at når du tester mer, er resultatene bedre. Faktisk, når du tester mer uten tilsynelatende strategi, vil du sannsynligvis ende opp med å investere mye tid.

Med en mer strukturert tilnærming, et mål om 100% kravsdekning og effektive testmetoder, vil du ikke gå på kompromiss med kvalitet.

Vi håper teknikkene beskrevet i denne artikkelen vil gi deg noen tips.

Hell inn dine kommentarer og synspunkter om innlegget. Som vanlig elsker vi å høre fra deg.

Anbefalt lesing

^