TechCodeview

En testplan er et detaljeret dokument, som beskriver softwaretestområder og -aktiviteter. Den skitserer teststrategi, mål, testplan, nødvendige ressourcer (menneskelige ressourcer, software og hardware), testestimering og testleverancer.

Testplanen er grundlaget for enhver softwares test. Det er den mest afgørende aktivitet, som sikrer tilgængeligheden af ​​alle lister over planlagte aktiviteter i en passende rækkefølge.

Testplanen er en skabelon til at udføre softwaretestaktiviteter som en defineret proces, der er fuldt overvåget og kontrolleret af testlederen. Testplanen udarbejdes af testlederen (60 %), testlederen (20 %) og af testingeniøren (20 %).

Typer af testplan

Der er tre typer af testplanen

• Master Test Plan
• Fasetestplan
• Testtypespecifikke testplaner

Master Test Plan

Master Test Plan er en type testplan, der har flere niveauer af test. Det inkluderer en komplet teststrategi.

Fasetestplan

En fasetestplan er en type testplan, der adresserer en hvilken som helst fase af teststrategien. For eksempel en liste over værktøjer, en liste over testcases mv.

Specifikke testplaner

Specifik testplan designet til større typer test som sikkerhedstest, belastningstest, ydeevnetest osv. Med andre ord en specifik testplan designet til ikke-funktionel test.

Sådan skriver du en testplan

At lave en testplan er den mest afgørende opgave i teststyringsprocessen. I henhold til IEEE 829 skal du følge de følgende syv trin for at udarbejde en testplan.

• Analyser først produktstruktur og arkitektur.
• Design nu teststrategien.
• Definer alle testmålene.
• Definer testområdet.
• Definer alle brugbare ressourcer.
• Planlæg alle aktiviteter på en passende måde.
• Bestem alle testleverancer.

Test plankomponenter eller attributter

Testplanen består af forskellige dele, som hjælper os med at udlede hele testaktiviteten.

Mål: Den består af information om moduler, funktioner, testdata osv., som angiver formålet med applikationen betyder applikationsadfærd, mål osv.

Omfang: Den indeholder information, der skal testes med respektive applikation. Omfanget kan yderligere opdeles i to dele:

• I omfang
• Uden for rækkevidde

I omfang: Det er de moduler, der skal testes grundigt (i detaljer).

Udenfor omfang: Det er modulerne, som ikke behøver at blive testet grundigt.

For eksempel , Antag, at vi har en Gmail-applikation at teste, hvor funktioner, der skal testes såsom Skriv mail, Sendte elementer, Indbakke, Kladder og funktioner, der ikke testes såsom Hjælp , og så videre, hvilket betyder, at vi i planlægningsfasen beslutter, hvilken funktionalitet der skal kontrolleres eller ej, baseret på den tidsgrænse, der er angivet i produktet.

Nu hvordan beslutter vi, hvilke funktioner der ikke skal testes?

10 millioner

Vi har følgende aspekter, hvor vi kan beslutte, hvilken funktion der ikke skal testes:

• Som vi ser ovenfor Hjælp funktioner vil ikke blive testet, da det er skrevet og udviklet af den tekniske skribent og anmeldt af en anden professionel skribent.
• Lad os antage, at vi har en applikation, der har P, Q, R og S funktioner, som skal udvikles ud fra kravene. Men her er S-funktionen allerede designet og brugt af et andet firma. Så udviklingsteamet vil købe S fra det pågældende firma og integrere med yderligere funktioner såsom P, Q og R.

Nu vil vi ikke udføre funktionel test på S-funktionen, fordi den allerede er blevet brugt i realtid. Men vi vil udføre integrationstesten og systemtesten mellem P-, Q-, R- og S-funktioner, fordi de nye funktioner muligvis ikke fungerer korrekt med S-funktion, som vi kan se på billedet nedenfor:

• Antag i den første udgivelse af produktet, de elementer, der er blevet udviklet, som f.eks P, Q, R, S, T, U, V, W…..X, Y, Z . Nu vil kunden stille kravene til de nye funktioner, som forbedrer produktet i den anden udgivelse, og de nye funktioner er A1, B2, C3, D4 og E5.

Derefter vil vi skrive omfanget under testplanen som

Omfang

Funktioner, der skal testes

A1, B2, C3, D4, E5 (nye funktioner)

P, Q, R, S, T

Funktioner, der ikke skal testes

W…..X, Y, Z

Derfor vil vi først tjekke de nye funktioner og derefter fortsætte med de gamle funktioner, fordi det kan blive påvirket efter tilføjelse af de nye funktioner, hvilket betyder, at det også vil påvirke nedslagsområderne, så vi vil lave en runde med regresserende test for P, Q , R…, T funktioner.

Testmetode:

Den indeholder information om udførelse af en anden form for test som funktionstest, integrationstest og systemtest osv. på applikationen. I dette vil vi beslutte hvilken type test; vi udfører de forskellige funktioner baseret på applikationskravet. Og her bør vi også definere, hvilken slags test vi vil bruge i testmetoderne, så alle, som ledelsen, udviklingsteamet og testteamet nemt kan forstå, fordi testvilkårene ikke er standard.

For eksempel, til selvstændig applikation som f.eks Adobe Photoshop , vil vi udføre følgende typer test:

Røgtest → Funktionstest → Integrationstest → Systemtest → Adhoc-test → Kompatibilitetstest → Regressionstest → Globaliseringstest → Tilgængelighedstest → Usability-test → Pålidelighedstest → Gendannelsestest → Installations- eller afinstallationstest

Og antag, at vi skal teste https://www.jeevansathi.com/ applikation, så vi udfører følgende typer test:

Nærme sig

Denne attribut bruges til at beskrive applikationens flow, mens der udføres test og til fremtidig reference.

Vi kan forstå strømmen af ​​ansøgningen ved hjælp af nedenstående aspekter:

Ved at skrive scenarierne på højt niveau Ved at skrive flowgrafen

Ved at skrive scenarierne på højt niveau

For eksempel , antag, at vi tester Gmail Ansøgning:

• Log ind på Gmail - sender en e-mail og kontroller, om den er på siden Sendte elementer
• Log ind på …….
• ……
• ……..

Vi skriver dette for at beskrive de tilgange, der skal tages for at teste produktet og kun for de kritiske funktioner, hvor vi vil skrive scenarierne på højt niveau. Her vil vi ikke fokusere på at dække alle scenarierne, fordi det kan bestemmes af den pågældende testingeniør, hvilke funktioner der skal testes eller ej.

Ved at skrive flowgrafen

Flowgrafen er skrevet, fordi det tager lidt tid at skrive scenarierne på højt niveau, som vi kan se på billedet nedenfor:

Vi laver flowgrafer for at opnå følgende fordele, såsom:

• Dækning er let
• Sammenlægning er let

Metoden kan opdeles i to dele, som er som følger:

• Top til bund tilgang
• Bund til top tilgang

Antagelse

Den indeholder oplysninger om et problem eller et problem, der kan opstå under testprocessen, og når vi skriver testplanerne, vil de sikrede antagelser blive gjort som ressourcer og teknologier osv.

Risiko

Det er de udfordringer, vi skal stå over for for at teste applikationen i den aktuelle udgivelse, og hvis antagelserne vil fejle, er risiciene involveret.

For eksempel, virkningen for en ansøgning bliver udgivelsesdatoen udskudt.

Afværgeplan eller beredskabsplan

Det er en backup-plan, som er forberedt til at overvinde risici eller problemer.

Lad os se et eksempel på antagelse, risiko og beredskabsplanen sammen, fordi de er co-relaterede til hinanden.

I ethvert produkt er antagelse vi vil gøre, er, at alle 3 testingeniører vil være der indtil færdiggørelsen af ​​produktet, og hver af dem er tildelt forskellige moduler såsom P, Q og R. I dette særlige scenarie, risiko kunne være, at hvis testingeniøren forlod projektet midt i det.

Derfor er beredskabsplan vil blive tildelt en primær og underordnet ejer til hver funktion. Så hvis den ene testingeniør vil forlade, overtager den underordnede ejer den specifikke funktion og hjælper også den nye testingeniør, så han/hun kan forstå deres tildelte moduler.

Antagelserne, risikoen og afbødnings- eller beredskabsplanen er altid præcise på selve produktet. De forskellige typer risici er som følger:

• Kundeperspektiv
• Ressourcetilgang
• Teknisk udtalelse

Rolle & Ansvar

Den definerer den komplette opgave, som skal udføres af hele testteamet. Når et stort projekt kommer, så Test Manager er en person, der skriver testplanen. Hvis der er 3-4 små projekter, vil testlederen tildele hvert projekt til hver testleder. Derefter skriver testlederen testplanen for projektet, som han/hun får tildelt.

Lad os se et eksempel, hvor vi vil forstå rollerne og ansvaret for testlederen, testlederen og testingeniørerne.

Rolle: Test Manager

Navn: Ryan

Ansvar:

• Forbered (skriv og gennemgå) testplanen
• Afhold mødet med udviklingsteamet
• Gennemfør mødet med testteamet
• Afhold mødet med kunden
• Afhold et månedligt stand up møde
• Afmeld release note
• Håndtering af eskalationer og problemer

Rolle: Testleder

Navn: Harvey

Ansvar:

• Forbered (skriv og gennemgå) testplanen
• Afhold dagligt stand up møde
• Gennemgå og godkend testcasen
• Forbered RTM og rapporter
• Tildel moduler
• Håndteringsplan

Rolle: Testingeniør 1, Testingeniør 2 og Testingeniør 3

Navn: Louis, Jessica, Donna

Tildel moduler: M1, M2 og M3

Ansvar:

• Skriv, gennemgå og udfør testdokumenterne, som består af testcase og testscenarier
• Læs, gennemgå, forstå og analyser kravet
• Skriv ansøgningens flow
• Udfør testsagen
• RTM for respektive moduler
• Defekt sporing
• Forbered testudførelsesrapporten og kommuniker den til testlederen.

Tidsplan

Det bruges til at forklare timingen for at arbejde, hvad der skal gøres, eller denne egenskab dækker præcis, hvornår hver testaktivitet skal starte og slutte? Og de nøjagtige data er også nævnt for hver testaktivitet for den bestemte dato.

Derfor, som vi kan se på billedet nedenfor, vil der for den pågældende aktivitet være en startdato og en slutdato; for hver test af en specifik build vil der være den angivne dato.

For eksempel

• Skrivning af testcases
• Udførelsesproces

Defekt sporing

Det gøres generelt ved hjælp af værktøjer, fordi vi ikke kan spore status for hver fejl manuelt. Og vi kommenterer også på, hvordan vi kommunikerer de fejl, der identificeres under testprocessen, og sender dem tilbage til udviklingsteamet, og hvordan udviklingsteamet vil svare. Her nævner vi også prioriteringen af ​​fejlene såsom høj, medium og lav.

Følgende er forskellige aspekter af fejlsporingen:

Teknikker til at spore fejlen
…..
……
……
……Værktøjer til fejlsporing
Vi kan kommentere navnet på værktøjet, som vi vil bruge til at spore fejlene. Nogle af de mest brugte fejlsporingsværktøjer er Jira, Bugzilla, Mantis og Trac osv.<Alvorlighed
Sværhedsgraden kan være som følger:
Blocker eller showstopper
…..
….. (Forklar det med et eksempel i testplanen)
For eksempel , vil der være en defekt i modulet; vi kan ikke gå længere for at teste andre moduler, fordi hvis fejlen er blokeret, kan vi fortsætte med at kontrollere andre moduler.
Kritisk
……
….. (Forklar det med et eksempel i testplanen)
I denne situation vil manglerne påvirke virksomheden.
Major
….
…. (Forklar det med et eksempel i testplanen)
Mindre
…..
….. (Forklar det med et eksempel i testplanen)
Disse defekter er dem, der påvirker udseendet og følelsen af ​​applikationen.Prioritet
Høj-P1
…..
Medium-P2
…..
Lav-P3
…..
…..
P4

Derfor vil vi, baseret på prioriteringen af ​​fejl som høj, medium og lav, kategorisere det som P1, P2, P3 og P4.

Test miljøer

Det er de miljøer, hvor vi vil teste applikationen, og her har vi to typer miljøer, som er af software og hardware konfiguration.

Det software konfiguration betyder detaljerne om forskellige Operativsystemer såsom Windows, Linux, UNIX og Mac og forskellige Browsere synes godt om Google Chrome, Firefox, Opera, Internet Explorer , og så videre.

Og hardware konfiguration betyder oplysningerne om forskellige størrelser af RAM, ROM og processorerne .

For eksempel

• Det Software omfatter følgende:

Server

Bemærk: Ovenstående servere er de servere, der bruges af testteamet til at teste applikationen.

Klient

Bemærk: Ovenstående detaljer angiver de forskellige operativsystemer og browsere, hvor testteamet vil teste applikationen.

• Det Hardware omfatter følgende:

Server : Sun StarCat 1500

Denne særlige server kan bruges af testteamet til at teste deres applikation.

Klient:

Den har følgende konfiguration, som er som følger:

Bemærk: Det vil give konfigurationen af ​​systemerne for testingeniørerne, som er testteamet.

Proces for at installere softwaren
……
…..
…..

Udviklingsteamet vil sørge for konfigurationen af, hvordan softwaren installeres. Hvis udviklingsteamet endnu ikke vil levere processen, vil vi skrive det som Task-Based Development (TBD) i testplanen.

Ind- og udrejsekriterier

Det er en nødvendig betingelse, som skal være opfyldt, før du starter og stopper testprocessen.

Indgangskriterier

Adgangskriterierne indeholder følgende betingelser:

• Test af hvid boks skal være færdig.
• Forstå og analysere kravet og udarbejde testdokumenterne eller hvornår testdokumenterne er klar.
• Testdata skulle være klar.
• Byg eller ansøgningen skal udarbejdes
• Moduler eller funktioner skal tildeles de forskellige testingeniører.
• Den nødvendige ressource skal være klar.

Udgangskriterier

Exitkriterierne indeholder følgende betingelser:

• Når alle testsager er udført.
• De fleste af testcaserne skal være bestået .
• Afhænger af sværhedsgraden af ​​fejlene, hvilket betyder, at der ikke må være nogen blokering eller større fejl, mens der findes nogle mindre fejl.

Inden vi begynder at udføre funktionstest, alt ovenstående Indgangskriterier bør følges. Efter at vi har udført funktionstest, og før vi vil lave integrationstest, så Udgangskriterier for funktionstestningen skal følges, fordi % af exitkriterier bestemmes af mødet med både udviklings- og testleder, fordi deres samarbejde kan opnå procentdelen. Men hvis exitkriterierne for funktionel test ikke følges, så kan vi ikke gå videre til integrationstest.

Her baseret på sværhedsgraden af fejlen betyder, at testholdet ville have besluttet, at det skulle fortsætte i de næste faser.

Test automatisering

I dette vil vi tage stilling til følgende:

• Hvilken funktion skal automatiseres og ikke automatiseres?
• Hvilket testautomatiseringsværktøj skal vi bruge på hvilket automationsframework?

Vi automatiserer testcasen først efter den første udgivelse.

Her opstår spørgsmålet, på hvilket grundlag vi vilje beslutte, hvilke funktioner der skal testes?

I ovenstående billede, som vi kan se, at de mest brugte funktioner skal teste igen og igen. Antag, at vi skal tjekke Gmail-applikationen, hvor de væsentlige funktioner er Skriv mail, Sendte elementer og Indbakke . Så vi vil teste disse funktioner, fordi mens man udfører manuel test, tager det mere tid, og det bliver også et monotont job.

Nu, hvordan beslutter vi, hvilke funktioner der ikke skal testes?

Formode hjælpen Funktionen i Gmail-applikationen testes ikke igen og igen, fordi disse funktioner ikke bruges regelmæssigt, så vi behøver ikke at tjekke den ofte.

Men hvis nogle funktioner er ustabile og har mange fejl , hvilket betyder, at vi ikke vil teste disse funktioner, fordi det skal testes igen og igen, mens vi udfører manuel test.

Hvis der er en funktion, der skal testes ofte , men vi forventer, at kravet ændres for den funktion, så vi tjekker det ikke, fordi det er mere behageligt at ændre de manuelle testsager sammenlignet med ændringer i automatiseringstestscriptet.

Indsats estimering

I dette vil vi planlægge den indsats, der skal anvendes af hvert teammedlem.

Test Leveres

Det er de dokumenter, som er output fra testteamet, som vi afleverede til kunden sammen med produktet. Det omfatter følgende:

Testplan Test Cases Test scripts RTM (Requirement Traceability Matrix) Fejlrapport Testudførelsesrapport Grafer og metrikker Udgivelses noter

Grafer og målinger

Kurve

I dette vil vi diskutere om typerne af grafer vi sender, og vi vil også give et eksempel på hver graf.

Som vi kan se, har vi fem forskellige grafer, der viser de forskellige aspekter af testprocessen.

Graf 1: I dette vil vi vise, hvor mange defekter der er blevet identificeret, og hvor mange defekter der er blevet rettet i hvert modul.

Graf 2: Figur et viser, hvor mange kritiske, større og mindre defekter, der er blevet identificeret for hvert modul, og hvor mange, der er blevet rettet for deres respektive moduler.

Graf 3: I denne særlige graf repræsenterer vi bygge klog graf , hvilket betyder, at i hver build, hvor mange defekter der er blevet identificeret og rettet for hvert modul. Baseret på modulet har vi bestemt fejlene. Vi vil tilføje R for at vise antallet af fejl i P og Q, og vi tilføjer også S for at vise fejlene i P, Q og R.

Graf 4: Testledningen vil designe Bug Trend analyse graf som oprettes hver måned og sendes til ledelsen også. Og det er ligesom forudsigelse, der udføres i slutningen af ​​produktet. Og her kan vi også bedømme fejlrettelserne som vi kan observere det bue har en opadgående tendens på billedet nedenfor.

Graf 5: Det Test Manager har designet denne type graf. Denne graf er beregnet til at forstå hullet i vurderingen af ​​fejl og de faktiske fejl, der er opstået, og denne graf hjælper også med at forbedre evalueringen af ​​fejl i fremtiden.

Metrics

Som ovenfor opretter vi fejlfordelingsgrafen, som er i figur 1, og ved hjælp af ovennævnte data vil vi også designe metrikkerne.

For eksempel

I ovenstående figur gemmer vi optegnelserne for alle testingeniører i et bestemt projekt, og hvor mange defekter der er blevet identificeret og rettet. Vi kan også bruge disse data til fremtidige analyser. Når der kommer et nyt krav, kan vi beslutte, hvem der skal levere den udfordrende funktion til test baseret på antallet af defekter, de har fundet tidligere i henhold til ovenstående metrics. Og vi vil være i en bedre situation til at vide, hvem der kan håndtere de problematiske funktioner meget godt og finde det maksimale antal defekter.

Release Note: Det er et dokument, der er udarbejdet under frigivelsen af ​​produktet og underskrevet af testlederen.

På billedet nedenfor kan vi se, at det endelige produkt er udviklet og implementeret til kunden, og det seneste udgivelsesnavn er Beta .

Det Release note består af følgende:

• Brugermanual.
• Liste over afventende og åbne defekter.
• Liste over tilføjede, ændrede og slettede funktioner.
• Liste over den platform (operativsystem, hardware, browsere), som produktet er testet på.
• Platform, hvor produktet ikke er testet.
• Liste over fejl, der er rettet i den aktuelle udgivelse, og listen over rettede fejl i den forrige udgivelse.
• Installationsproces
• Versioner af softwaren

For eksempel

Antag at Beta er den anden udgivelse af applikationen efter den første udgivelse Alfa er frigivet. Nogle af defekten identificeret i den første udgivelse, og som er blevet rettet i den senere udgivne. Og her vil vi også påpege listen over nyligt tilføjede, ændrede og slettede funktioner fra alfa-udgivelsen til beta-udgivelsen.

Skabelon

Denne del indeholder alle skabelonerne til de dokumenter, der vil blive brugt i produktet, og alle testingeniører vil kun bruge disse skabeloner i projektet for at bevare produktets konsistens. Her har vi forskellige typer skabeloner, som bruges under hele testprocessen såsom:

• Test case skabelon
• Test case review skabelon
• RTM skabelon
• Skabelon for fejlrapport
• Testudførelsesrapport

Lad os se et eksempel på et testplandokument

Side 1

Side 3-side 18

Side-20

På side 1 udfylder vi primært kun Versioner, forfatter, kommentarer og gennemgået af felter, og efter at lederen har godkendt det, vil vi nævne detaljerne i Godkendt af og godkendelsesdato felter.

For det meste er testplanen godkendt af testlederen, og testingeniørerne gennemgår den kun. Og når de nye funktioner kommer, vil vi ændre testplanen og foretage de nødvendige ændringer Version felt, og derefter sendes det igen til yderligere gennemgang, opdatering og godkendelse af lederen. Testplanen skal opdateres, hver gang der er sket ændringer. På side 20 står Referencer angiv detaljerne om alle de dokumenter, som vi skal bruge til at skrive testplandokumentet.

Bemærk:

Hvem skriver testplanen?

• Test lead→60 %
• Test Manager→20 %
• Testingeniør→20 %

Derfor, som vi kan se ovenfra, er testplanen i 60% af produktet skrevet af testlederen.

Hvem gennemgår testplanen?

• Test Lead
• Test Manager
• Testingeniør
• Kunde
• Udviklingsteam

Testingeniøren gennemgår testplanen for deres modulperspektiv, og testlederen gennemgår testplanen baseret på kundens mening.

Hvem godkender testplanen?

• Kunde
• Test Manager

Hvem skriver testcasen?

• Test Lead
• Testingeniør

Hvem gennemgår testcasen?

• Testingeniør
• Test Lead
• Kunde
• Udviklingsteam

Hvem godkender testsagerne?

• Test Manager
• Test Lead
• Kunde

Retningslinjer for testplan

• Skjul din testplan.
• Undgå overlapning og redundans.
• Hvis du mener, at du ikke har brug for en sektion, der allerede er nævnt ovenfor, så slet den sektion og fortsæt.
• Vær specifik. For eksempel, når du angiver et softwaresystem som en del af testmiljøet, så nævn softwareversionen i stedet for kun navn.
• Undgå lange afsnit.
• Brug lister og tabeller, hvor det er muligt.
• Opdater planen efter behov.
• Brug ikke et forældet og ubrugt dokument.

Vigtigheden af ​​testplan

• Testplanen giver retning til vores tænkning. Dette er ligesom en regelbog, som skal følges.
• Testplanen hjælper med at bestemme den nødvendige indsats for at validere kvaliteten af ​​softwareapplikationen under testen.
• Testplanen hjælper disse mennesker med at forstå testdetaljerne, der er relateret til det ydre, såsom udviklere, virksomhedsledere, kunder osv.
• Vigtige aspekter som testplan, teststrategi, testomfang osv. er dokumenteret i testplanen, så ledelsesteamet kan gennemgå dem og genbruge dem til andre lignende projekter.