Meny

Testtäckning vid programvarutestning (tips för att maximera testtäckning)

test coverage software testing

Prova Vårt Instrument För Att Eliminera Problem

Programtest Testtäckning Komplett guide: Hur man testar mer, sparar tid och uppnår bättre testresultat:

Programvarutestning är en viktig aktivitet i livscyklerna för programvaruutveckling och underhåll. Det är en metod som ofta används för att bestämma och förbättra mjukvarukvaliteten.

Utvecklingen är mer systematisk idag och organisationer söker åtgärder för att testa fullständighet och effektivitet för att visa testkriterier. Av dem alla anses täckningen vara särskilt värdefull.

Vad du kommer att lära dig:

Vad är testtäckning?

Enkelt uttryckt är täckningen 'Vad testar vi och hur mycket testar vi?'

Testtäckning hjälper till att övervaka testkvaliteten och hjälper testare att skapa tester som täcker områden som saknas eller inte validerats.

testtäckning

De flesta lag baserar sina täckningsberäkningar enbart på funktionskrav. Det är också rättvist eftersom en applikation först och främst ska göra vad den ska göra. Om inte, dess hastighet, säkerhet eller användarvänlighet - inget av det betyder något.

Men om dedikerad och oberoende icke-funktionell testning team arbetar med prestanda, säkerhet, användbarhetstest, etc., då måste de spåra sina krav hela vägen till exekvering genom testtäckningsanalys.

Testtäckning och kodtäckning

Testtäckning förväxlas ofta med kodtäckning. Även om de underliggande principerna är desamma är de två olika saker.

Kodtäckning talar verkligen om prövningar för enhetstester som måste rikta in sig på alla områden i koden minst en gång och görs av utvecklare.

Test täckning, å andra sidan, är testa alla krav åtminstone en gång och är uppenbarligen en QA-teamaktivitet.

Vad som verkligen kvalificerar sig för att vara ett täckt krav beror på tolkningen av varje lag.

Till exempel , Vissa lag kallar ett krav täckt om det finns minst ett testfall mot det. Ibland täcks det om minst en lagmedlem tilldelas det. Eller om alla testfall som är associerade med det utförs.

  • Om det skapas tio krav och 100 tester - när dessa 100 tester riktar sig till alla de tio kraven och inte utelämnar några - kallar vi detta tillräcklig täckning på designnivå.
  • När endast 80 av de skapade testerna körs och riktar sig bara mot 6 av kraven. Vi säger att fyra krav inte täcks trots att 80% av testningen är klar. Detta är täckningsstatistik på exekveringsnivå.
  • När endast 90 tester relaterade till åtta krav har tilldelat testare och resten av dem inte, säger vi att testuppgiften täcker 80% (8 av 10 krav).

Det är också viktigt när du ska beräkna täckningen.

vilket program öppnar en json-fil

Om du gör det för tidigt i processen kommer du att se många luckor eftersom sakerna fortfarande är ofullständiga. Så det rekommenderas i allmänhet att vänta tills den senaste byggnaden dvs Final Regression Build. Detta ger en korrekt täckning av de utförda testerna för de angivna kraven.

Läs också => Process för frigöring och distribution

Min erfarenhet

Scen för 8 år sedan: När jag hade två års erfarenhet av mjukvarutestningsindustrin tänkte jag att det var okej om jag inte känner till några grundläggande frågor om programvarutestning som något man kan lära sig med erfarenhet och jag också kommer att göra.

Jag hade rätt - och fel också.

Just för att med erfarenhet lär du dig att se en större bild, du förstår den verkliga innebörden av 'Kritisk situation' och du förstår slutanvändaren mer.

Fel eftersom inget av de nämnda sakerna kräver erfarenhet utan tidigt lärande, vilket jag förstod väldigt sent. Det är den uppmuntrande faktorn att skriva detta inlägg.

Maximera testtäckningen på kortare tid

Här är min erfarenhet från en av intervjuerna vid den tiden:

Hur ser du till att testtäckningen är fullständig eller maximal? Jag blev tillfrågad.

Ummmm …… Jag ser till att jag testar alla funktioner , Jag sade.

S o du säger att när du väl testat alla funktioner känner du att du har täckt maximalt applikation / produkt när det gäller testning intervjuade intervjuaren.

Ummm ... ja ... .mmmm .... Ja, för när du testar alla funktioner är du säker på applikationens / produktens beteende, Jag stödde mitt svar .

Jag håller med, men min fråga är - kommer det att ge dig förtroende för att din testtäckning är maximal eller fullständig? intervjuaren var inte på humör för att släppa mig.

Nu blev jag otålig, okänd om det faktum att jag skulle lära mig ett av de viktigaste ämnena om testning av programvara - ' Testtäckning ” .

I stället för att återge utdrag från intervjun sammanfattar jag här vad jag lärde mig om Testing Coverage den dagen. Men innan det är klart på en punkt - testtäckning betyder aldrig att du ska veta om du testar tillräckligt eller inte, det betyder inte att du testar perfekt eller inte.

Test täckning mening

Testtäckning kan ha en annan betydelse i olika sammanhang. Låt oss upptäcka dessa sammanhang en efter en:

Produkttäckning - Vilka aspekter av produkten tittade du på?

Ja, när testtäckningen mäts i termer av produkt är huvudområdet att fokusera på - vilka produktområden du har testat och vilka förblir oproverade?

Exempel 1:

Om “kniv” är en produkt testar du; bara koncentrera dig inte på att kontrollera om det skär grönsakerna / frukterna ordentligt. Det finns andra aspekter att leta efter som - användaren ska kunna hantera det bekvämt.

Exempel 2:

Om 'anteckningsblock' är en applikation testar du, att kontrollera relevanta funktioner är en måste sak.

Men andra aspekter som ska tas hand om är - applikationen svarar ordentligt när du använder andra applikationer samtidigt, applikationen kraschar inte när användaren försöker göra något ovanligt , får användaren korrekta varnings- / felmeddelanden, användaren kan förstå och använda applikationen enkelt, hjälpinnehåll finns tillgängligt vid behov.

Om du inte tittar på de nämnda scenarierna kan du inte hävda att testtäckningen för applikationen är fullständig.

Risktäckning - Vilka risker har du testat för?

Risktäckning är en annan aspekt för att ha fullständig testtäckning. Du kan inte märka produkten eller applikationen som 'testad' förrän du testar de därmed sammanhängande riskerna. Täckning av tillhörande risker är en viktig faktor i den totala testtäckningen.

Exempel 1:

När en testare berättar att han / hon har testat flygplanets interna system och att det fungerar bra, men bara flygplanets kapacitet täcktes inte under testet - vad skulle din reaktion vara när du testade ett flygplan?

Det är vad risk täckning innebär. Att identifiera risk enligt applikationen / produkten och testa den noggrant är alltid en bra praxis.

Exempel 2:

När testaren testade en e-handelswebbplats ansåg testaren alla effektiva faktorer men ansåg inte risken för att antalet användare skulle komma åt webbplatsen samtidigt och på Super-ERBJUDANDEN, visade sig den risk som inte betraktades vara ett stort misstag.

Rekommenderad läsning =>

Krav på täckning - Vilka krav har du testat för?

Om en produkt eller applikation utvecklas mycket bra men om den inte stämmer överens med kundens krav, är den till ingen nytta. Kravstäckning vid testning är lika viktigt som produkttäckning.

dijkstras algoritm java med prioritetskö

Exempel 1:

Upphetsad för familjefunktionen bad du skräddaren att sy din klänning och sätta på de påfågelblå showknapparna på halsen.

När han syr klänningen, tänkte skräddaren att det inte skulle se bra ut att sätta knapparna på halsen så han sydde en guldfärgad kant istället. På försöksdagen ropade den olyckliga kunden definitivt till skräddaren för att inte hålla sig till kraven.

Exempel 2:

Under testning av en chattapplikation tog testaren hand om alla viktiga punkter som flera användare som chattar i en grupp, två användare som chattar oberoende, alla typer av uttryckssymboler tillgängliga, uppdateringar skickas till användaren omedelbart etc. men glömde att titta på kravdokument, vilket tydligt nämnde att när två användare chattar oberoende, bör videosamtalet vara aktiverat.

Klienten marknadsförde chattapplikationen och hävdade att den skulle tillåta samtal, medan två användare chattade självständigt. Du kan föreställa dig vad som skulle ha hänt med chattapplikationen.

Också läsa => Hur man skapar krav Spårbarhetsmatris

Hur antar jag en korrekt testtäckningsmetod?

Medvetenhet är allt:

Först och främst måste QA-teamet veta hur mycket arbete som är involverat och var designuppgifterna ligger. På detta sätt kommer de att vara medvetna om fler tester ska läggas till. För att göra detta kan du använda en RTM som det är vanligt.

=> Läs den här artikeln om du vill veta mer om den och hur du använder den: Hur man skapar krav Spårbarhetsmatris - Exakt process med exempelmall

För det andra, kontrollera resurstilldelning och testkörningsprocessen för att se om allt testas på ett mer effektivt sätt.

En tabell som nedan kan vara till hjälp:

TesttypTotalt antal fallExekverade ärendenStatusKommentarer
Funktionell1008050 pass, 30 misslyckas
Kompatibilitet100femtio45 pass, 5 misslyckas
Användbarhet10010098 pass, 2 misslyckas
Slutlig regression10010099 pass, 1 misslyckas

Hur ser jag till att allt testas?

  • Varje testare bör vara medveten om kraven och testmetoderna
  • Prioritera dina krav och fokusera din energi där det behövs mest
  • Bli informerad om hur en viss version skiljer sig från den tidigare så att du kan identifiera kritiska krav mer exakt och fokusera på maximal positiv täckning
  • Anpassa testautomatisering
  • Använd verktyg för testhantering att alltid hålla kunskapen
  • Smart arbetsuppgift - Kanalisera dina bästa resurser mot kritiska uppgifter och låt nya testare utforska mer för ett nytt perspektiv
  • Underhålla en checklista för alla uppgifter och diverse aktiviteter
  • Interagera mer med dina Dev / Scrum / BA-team för att få inblick i applikationsbeteendet
  • Håll koll på alla dina byggcykler och korrigeringar
  • Identifiera de mest påverkande problemen i de initiala byggnaderna (när det är möjligt) så att de senare kan arbeta för bättre stabilitet och nå de områden som blockeras av tidigare problem

Kritiska områden och metoder för effektiv testning

effektiv testning

# 1)Resurstumling: Utbyta uppgifter mellan dina teammedlemmar. Detta hjälper till att förbättra engagemang och förhindra kunskapskoncentration.

#två)Kompatibilitetstäckning: Se till att du är medveten om och inkluderar olika webbläsare och plattformar för att testa din ansökan.

# 3)Äganderätt: Gör testare ansvariga och ge dem en fri tygla (med övervakning och support förstås) för den modul / uppgift som de arbetar med. Detta hjälper till att bygga ansvar och låter dem prova kreativa sätt istället för att följa misshandlad på vägen.

# 4)Tidsfrister: Att känna till tidsfristerna för släpp innan testfasen inleds hjälper till med effektiv planering

# 5)Kommunikation : Håll kontakten med utvecklaren och andra lag mellan släppcykler för att veta vad som händer.

# 6)Upprätthålla en RTM: Fungerar som ett bra derivat till Intressenter eller klienter , baserat på vilket släppschemat kan bekräftas

Fördelar med att testa täckningsmedvetenhet för en testare:

  • Det hjälper främst med att testa uppgiftsprioritering
  • Det hjälper till att uppnå 100% kravtäckning eller med andra ord förhindrar kravläckage
  • Effektanalys blir lättare
  • Användbar för att bestämma EXIT-kriterier
  • Aktiverar en testledning för att förbereda en klar testavslutningsrapport

Slutsats

Testtäckningen slutar inte med nämnda sammanhang. Det finns många andra punkter som bör övervägas när det gäller testtäckning.

Det är inte alltid sant att när du testar mer blir resultaten bättre. Faktum är att när du testar mer utan någon uppenbar strategi kommer du förmodligen att investera mycket tid.

Med ett mer strukturerat tillvägagångssätt, som strävar efter 100% kravtäckning och effektiva testmetoder, kompromissar du inte med kvaliteten.

Vi hoppas att de tekniker som beskrivs i den här artikeln kommer att ge dig några tips.

Häll i dina kommentarer och åsikter om inlägget. Som vanligt hör vi gärna av dig.

Rekommenderad läsning

^