TESTPLAN - PROGRAMVARETESTING

En testplan er et detaljert dokument som beskriver områder og aktiviteter for programvaretesting. Den skisserer teststrategi, mål, testplan, nødvendige ressurser (menneskelige ressurser, programvare og maskinvare), testestimering og testleveranser.

Testplanen er en base for hver programvares testing. Det er den mest avgjørende aktiviteten som sikrer tilgjengelighet av alle listene over planlagte aktiviteter i en passende rekkefølge.

Testplanen er en mal for gjennomføring av programvaretestaktiviteter som en definert prosess som er fullstendig overvåket og kontrollert av testlederen. Testplanen utarbeides av testlederen (60 %), testlederen (20 %) og av testingeniøren (20 %).

Typer testplan

Det er tre typer testplan

Master Test Plan
Fasetestplan
Testtypespesifikke testplaner

Master Test Plan

Master Test Plan er en type testplan som har flere testnivåer. Den inkluderer en komplett teststrategi.

Fasetestplan

En fasetestplan er en type testplan som tar for seg en hvilken som helst fase av teststrategien. For eksempel en liste over verktøy, en liste over testtilfeller osv.

Spesifikke testplaner

Spesifikk testplan designet for hovedtyper av testing som sikkerhetstesting, belastningstesting, ytelsestesting osv. Med andre ord, en spesifikk testplan designet for ikke-funksjonell testing.

Hvordan skrive en testplan

Å lage en testplan er den mest avgjørende oppgaven i testadministrasjonsprosessen. I henhold til IEEE 829, følg de følgende sju trinnene for å utarbeide en testplan.

Først analyserer du produktstruktur og arkitektur.
Design nå teststrategien.
Definer alle testmålene.
Definer testområdet.
Definer alle brukbare ressurser.
Planlegg alle aktiviteter på en hensiktsmessig måte.
Bestem alle testleveransene.

Test plankomponenter eller attributter

Testplanen består av ulike deler, som hjelper oss å utlede hele testaktiviteten.

Mål: Den består av informasjon om moduler, funksjoner, testdata etc., som indikerer at formålet med applikasjonen betyr applikasjonens oppførsel, mål osv.

Omfang: Den inneholder informasjon som må testes med respektive applikasjon. Omfanget kan videre deles inn i to deler:

I sikte
Utenom omfang

I sikte: Dette er modulene som må testes grundig (i detalj).

Uteomfang: Dette er modulene som ikke trenger å testes grundig.

For eksempel , Anta at vi har en Gmail-applikasjon å teste, hvor funksjoner som skal testes som for eksempel Skriv e-post, sendte elementer, innboks, utkast og funksjoner som ikke testes som for eksempel Hjelp , og så videre, noe som betyr at vi i planleggingsfasen vil bestemme hvilken funksjonalitet som må kontrolleres eller ikke basert på tidsbegrensningen som er gitt i produktet.

Nå hvordan bestemmer vi hvilke funksjoner som ikke skal testes?

string split java

Vi har følgende aspekter der vi kan bestemme hvilken funksjon som ikke skal testes:

Som vi ser ovenfor Hjelp funksjoner kommer ikke til å bli testet, da de er skrevet og utviklet av den tekniske skribenten og anmeldt av en annen profesjonell skribent.
La oss anta at vi har en applikasjon som har P, Q, R og S funksjoner som må utvikles basert på kravene. Men her er S-funksjonen allerede designet og brukt av et annet selskap. Så utviklingsteamet vil kjøpe S fra det selskapet og integrere med tilleggsfunksjoner som P, Q og R.

Nå vil vi ikke utføre funksjonstesting på S-funksjonen fordi den allerede har blitt brukt i sanntid. Men vi vil gjøre integrasjonstesting og systemtesting mellom P-, Q-, R- og S-funksjoner fordi de nye funksjonene kanskje ikke fungerer riktig med S-funksjonen som vi kan se i bildet nedenfor:

Anta at i den første utgivelsen av produktet, elementene som er utviklet, som f.eks P, Q, R, S, T, U, V, W…..X, Y, Z . Nå vil klienten gi kravene til de nye funksjonene som forbedrer produktet i den andre utgivelsen og de nye funksjonene er A1, B2, C3, D4 og E5.

Etter det vil vi skrive omfanget under testplanen som

omfang

Funksjoner som skal testes

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

P, Q, R, S, T

Egenskaper som ikke skal testes

W…..X, Y, Z

Derfor vil vi sjekke de nye funksjonene først og deretter fortsette med de gamle funksjonene fordi det kan bli påvirket etter å ha lagt til de nye funksjonene, noe som betyr at det også vil påvirke innvirkningsområdene, så vi vil gjøre en runde med regresserende testing for P, Q , R…, T funksjoner.

Testmetodikk:

Den inneholder informasjon om å utføre en annen type testing som funksjonstesting, integrasjonstesting og systemtesting, etc. på applikasjonen. I dette vil vi bestemme hvilken type testing; vi vil utføre de ulike funksjonene basert på applikasjonskravet. Og her bør vi også definere hva slags testing vi skal bruke i testmetodikkene, slik at alle, som ledelsen, utviklingsteamet og testteamet, enkelt kan forstå fordi testvilkårene ikke er standard.

For eksempel, for frittstående applikasjoner som f.eks Adobe Photoshop , vil vi utføre følgende typer testing:

Røyktesting → Funksjonstesting → Integrasjonstesting → Systemtesting → Adhoc-testing → Kompatibilitetstesting → Regresjonstesting → Globaliseringstesting → Tilgjengelighetstesting → Brukervennlighetstesting → Pålitelighetstesting → Gjenopprettingstesting → Installasjons- eller avinstallasjonstesting

Og anta at vi må teste https://www.jeevansathi.com/ applikasjon, så vi vil utføre følgende typer testing:

Røyktesting	Funksjonstesting	Integrasjonstesting
Systemtesting	Adhoc testing	Kompatibilitetstesting
Regresjonstesting	Globaliseringstesting	Tilgjengelighetstesting
Brukbarhetstesting	Ytelsestesting

Nærme seg

Dette attributtet brukes til å beskrive flyten til applikasjonen mens du utfører testing og for fremtidig referanse.

Vi kan forstå flyten av applikasjonen ved hjelp av følgende aspekter:

Ved å skrive scenariene på høyt nivå Ved å skrive flytgrafen

Ved å skrive scenariene på høyt nivå

For eksempel , anta at vi tester Gmail applikasjon:

Logg på Gmail - sender en e-post og sjekk om den er på siden Sendte elementer
Logg på …….
……
…….

Vi skriver dette for å beskrive tilnærmingene som må tas for å teste produktet og kun for de kritiske funksjonene der vi skal skrive scenariene på høyt nivå. Her vil vi ikke fokusere på å dekke alle scenariene fordi det kan bestemmes av den aktuelle testingeniøren hvilke funksjoner som må testes eller ikke.

Ved å skrive flytgrafen

Flytgrafen er skrevet fordi å skrive scenariene på høyt nivå tar litt tid, som vi kan se på bildet nedenfor:

Vi lager flytgrafer for å oppnå følgende fordeler som:

Dekning er lett
Sammenslåing er enkelt

Tilnærmingen kan deles inn i to deler som er som følger:

Topp til bunn tilnærming
Bunn til topp tilnærming

Antagelse

Den inneholder informasjon om et problem eller problem som kan oppstå under testprosessen, og når vi skriver testplanene, vil de sikre forutsetningene bli gjort som ressurser og teknologier, etc.

Fare

Dette er utfordringene vi må møte for å teste applikasjonen i den nåværende utgivelsen, og hvis forutsetningene vil mislykkes, er risikoen involvert.

For eksempel, virkningen for en søknad, utgivelsesdatoen blir utsatt.

Avbøtende plan eller beredskapsplan

Det er en reserveplan som er utarbeidet for å overvinne risikoene eller problemene.

La oss se ett eksempel for antakelse, risiko og beredskapsplanen sammen fordi de er samrelaterte til hverandre.

I ethvert produkt er antagelse vi vil gjøre er at alle 3 testingeniørene vil være der frem til ferdigstillelsen av produktet, og hver av dem er tildelt forskjellige moduler som P, Q og R. I dette spesielle scenariet, Fare kan være det hvis testingeniøren forlot prosjektet midt i det.

derfor beredskapsplan vil bli tildelt en primær og underordnet eier til hver funksjon. Så hvis den ene testingeniøren vil forlate, overtar den underordnede eieren den spesifikke funksjonen og hjelper også den nye testingeniøren, slik at han/hun kan forstå de tildelte modulene.

Forutsetningene, risikoen og avbøtende eller beredskapsplaner er alltid nøyaktige på selve produktet. De ulike typene risikoer er som følger:

Kundeperspektiv
Ressurstilnærming
Teknisk mening

Rolle og ansvar

Den definerer hele oppgaven som må utføres av hele testteamet. Når et stort prosjekt kommer, da Testleder er en person som skriver testplanen. Hvis det er 3-4 små prosjekter, vil testlederen tildele hvert prosjekt til hver testleder. Og så skriver testlederen testplanen for prosjektet, som han/hun får tildelt.

La oss se et eksempel der vi vil forstå rollene og ansvaret til testlederen, testlederen og testingeniørene.

Rolle: Testleder

Navn: Ryan

Ansvar:

Forbered (skriv og gjennomgå) testplanen
Gjennomfør møtet med utviklingsteamet
Gjennomfør møtet med testteamet
Gjennomfør møtet med kunden
Gjennomfør ett månedlig stand up-møte
Signer av utgivelsesnotat
Håndtering av eskaleringer og problemer

Rolle: Testleder

Navn: Harvey

Ansvar:

Forbered (skriv og gjennomgå) testplanen
Gjennomfør daglig stand up-møte
Gjennomgå og godkjenne testsaken
Forbered RTM og rapporter
Tilordne 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, gjennomgå og utfør testdokumentene som består av testcase og testscenarier
Les, gjennomgå, forstå og analyser kravet
Skriv flyten av søknaden
Utfør testsaken
RTM for respektive moduler
Defektsporing
Forbered testgjennomføringsrapporten og kommuniser den til testlederen.

Rute

Den brukes til å forklare timingen for å fungere, hva som må gjøres, eller denne egenskapen dekker når nøyaktig hver testaktivitet skal starte og slutte? Og de nøyaktige dataene er også nevnt for hver testaktivitet for den aktuelle datoen.

Derfor, som vi kan se i bildet nedenfor, vil det være en startdato og en sluttdato for den aktuelle aktiviteten; for hver testing til en spesifikk konstruksjon, vil det være den angitte datoen.

For eksempel

Skrive testsaker
Utførelsesprosess

Defektsporing

Det gjøres vanligvis ved hjelp av verktøy fordi vi ikke kan spore statusen til hver feil manuelt. Og vi kommenterer også hvordan vi kommuniserer feilene som blir identifisert under testprosessen og sender det tilbake til utviklingsteamet og hvordan utviklingsteamet vil svare. Her nevner vi også prioriteringen av feilene som høy, middels og lav.

Følgende er ulike aspekter ved defektsporingen:

Blocker eller showstopper

For eksempel

Kritisk

Major

Liten

Høy-P1

Medium-P2

Lav-P3

Derfor, basert på prioriteringen til feil som høy, middels og lav, vil vi kategorisere den som P1, P2, P3 og P4.

Testmiljøer

Dette er miljøene hvor vi skal teste applikasjonen, og her har vi to typer miljøer, som er av programvare og maskinvare konfigurasjon.

De programvarekonfigurasjon betyr detaljene om forskjellige Operativsystemer som for eksempel Windows, Linux, UNIX og Mac og ulike Nettlesere som Google Chrome, Firefox, Opera, Internet Explorer , og så videre.

Og maskinvarekonfigurasjon betyr informasjonen om ulike størrelser av RAM, ROM og prosessorene .

For eksempel

De Programvare inkluderer følgende:

Server

Operativsystem	Linux
Internett server	Apache Tomcat
Applikasjonsserver	Websfære
Database server	Oracle eller MS-SQL Server

Merk: Serverne ovenfor er serverne som brukes av testteamet for å teste applikasjonen.

Klient

Operativsystem	Windows XP, Vista 7
Nettlesere	Mozilla Firefox, Google Chrome, Internet Explorer, Internet Explorer 7 og Internet Explorer 8

Merk: Detaljene ovenfor gir de ulike operativsystemene og nettleserne der testteamet vil teste applikasjonen.

De Maskinvare inkluderer følgende:

Server : Sun StarCat 1500

Denne spesielle serveren kan brukes av testteamet til å teste applikasjonen deres.

Klient:

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

Prosessor	Totalt 2GHz
RAM	2 GB
….	….

Merk: Det vil gi konfigurasjonen av systemene til testingeniørene som er testteamet.

Utviklingsteamet vil gi konfigurasjonen av hvordan programvaren skal installeres. Hvis utviklingsteamet ennå ikke vil gi prosessen, vil vi skrive det som Task-Based Development (TBD) i testplanen.

Inn- og utgangskriterier

Det er en nødvendig betingelse, som må tilfredsstilles før du starter og stopper testprosessen.

Inngangskriterier

Inngangskriteriene inneholder følgende betingelser:

Testing av hvit boks skal være ferdig.
Forstå og analysere kravet og utarbeide testdokumentene eller når testdokumentene er klare.
Testdata skal være klare.
Bygg eller søknaden må utarbeides
Moduler eller funksjoner må tildeles de forskjellige testingeniørene.
Nødvendig ressurs må være klar.

Utgangskriterier

Utgangskriteriene inneholder følgende betingelser:

Når alle testsakene er utført.
De fleste testtilfellene må være det bestått .
Avhenger av alvorlighetsgraden av feilene, noe som betyr at det ikke må være noen blokkering eller større feil, mens det finnes noen mindre feil.

Før vi begynner å utføre funksjonstesting, alle de ovennevnte Inngangskriterier bør følges. Etter at vi utførte funksjonstesting og før vi skal gjøre integrasjonstesting, så Utgangskriterier for funksjonstestingen bør følges fordi % av exitkriteriene bestemmes av møtet med både utviklings- og testleder fordi deres samarbeid kan oppnå prosenten. Men hvis exitkriteriene for funksjonell testing ikke følges, kan vi ikke gå videre til integrasjonstesting.

Her basert på alvorlighetsgraden av feilen betyr at testteamet ville ha bestemt seg for å fortsette videre for de neste fasene.

Test automatisering

I dette vil vi bestemme følgende:

Hvilken funksjon må automatiseres og ikke automatiseres?
Hvilket testautomatiseringsverktøy skal vi bruke på hvilket automatiseringsrammeverk?

Vi automatiserer testsaken først etter den første utgivelsen.

Her oppstår spørsmålet på hvilket grunnlag vi vil bestemme hvilke funksjoner som må testes?

I bildet ovenfor, som vi kan se at de mest brukte funksjonene må teste igjen og igjen. Anta at vi må sjekke Gmail-applikasjonen der de essensielle funksjonene er Skriv e-post, sendte elementer og innboks . Så vi vil teste disse funksjonene fordi mens du utfører manuell testing, tar det mer tid, og det blir også en monoton jobb.

Nå, hvordan bestemmer vi hvilke funksjoner som ikke skal testes?

Anta hjelpen funksjonen til Gmail-applikasjonen testes ikke igjen og igjen fordi disse funksjonene ikke brukes regelmessig, så vi trenger ikke å sjekke den ofte.

Men hvis noen funksjoner er ustabile og har mange feil , som betyr at vi ikke vil teste disse funksjonene fordi de må testes igjen og igjen mens vi utfører manuell testing.

Hvis det er en funksjon som må testes ofte , men vi forventer kravendring for den funksjonen, så vi sjekker den ikke fordi endring av manuelle testtilfeller er mer behagelig sammenlignet med endring i automatiseringstestskriptet.

Beregning av innsats

I dette vil vi planlegge innsatsen som skal brukes av hvert teammedlem.

Test levert

Dette er dokumentene som er resultatet fra testteamet, som vi overleverte til kunden sammen med produktet. Den inkluderer følgende:

Testplan Testtilfeller Testskript RTM (Requirement Traceability Matrix) Feilmelding Testutførelsesrapport Grafer og beregninger Utgivelsesnotater

Grafer og beregninger

Kurve

I dette vil vi diskutere hvilke typer grafer vi sender, og vi vil også gi et utvalg av hver graf.

Som vi kan se, har vi fem forskjellige grafer som viser de ulike aspektene ved testprosessen.

Graf 1: I denne vil vi vise hvor mange defekter som er identifisert og hvor mange defekter som er fikset i hver modul.

Graf 2: Figur én viser hvor mange kritiske, større og mindre defekter som er identifisert for hver modul og hvor mange som er fikset for sine respektive moduler.

Graf 3: I denne spesielle grafen representerer vi bygge klok graf , som betyr at i hvert bygg hvor mange defekter som er identifisert og fikset for hver modul. Basert på modulen har vi bestemt feilene. Vi vil legge til R for å vise antall feil i P og Q, og vi legger også til S for å vise defektene i P, Q og R.

Graf 4: Testlederen vil designe Bug Trend analyse graf som lages hver måned og sende den til ledelsen også. Og det er akkurat som prediksjon som gjøres på slutten av produktet. Og her kan vi også vurdere feilrettingene slik vi kan observere det bue har en oppadgående tendens i bildet nedenfor.

Graf5: De Testleder har designet denne typen grafer. Denne grafen er ment å forstå gapet i vurderingen av feil og de faktiske feilene som har oppstått, og denne grafen bidrar også til å forbedre evalueringen av feil i fremtiden.

Beregninger

Som ovenfor lager vi bugdistribusjonsgrafen, som er i figur 1, og ved hjelp av ovennevnte data vil vi også designe beregningene.

For eksempel

I figuren ovenfor beholder vi journalene til alle testingeniørene i et bestemt prosjekt og hvor mange defekter som er identifisert og fikset. Vi kan også bruke disse dataene til fremtidig analyse. Når et nytt krav kommer, kan vi bestemme hvem som skal tilby den utfordrende funksjonen for testing basert på antall defekter de har funnet tidligere i henhold til beregningene ovenfor. Og vi vil være i en bedre situasjon for å vite hvem som kan håndtere de problematiske egenskapene veldig godt og finne maksimalt antall feil.

Utgivelsesmerknad: Det er et dokument som er utarbeidet under utgivelsen av produktet og signert av testlederen.

På bildet nedenfor kan vi se at sluttproduktet er utviklet og distribuert til kunden, og det siste utgivelsesnavnet er Beta .

De Utgivelsesnotat består av følgende:

Brukermanual.
Liste over ventende og åpne mangler.
Liste over lagt til, endret og slettet funksjoner.
Liste over plattformen (operativsystem, maskinvare, nettlesere) som produktet er testet på.
Plattform der produktet ikke er testet.
Liste over feil som er rettet i den nåværende utgivelsen, og listen over fikset feil i forrige utgivelse.
Installasjonsprosess
Versjoner av programvaren

For eksempel

Anta at Beta er den andre utgivelsen av applikasjonen etter den første utgivelsen Alfa er utgitt. Noe av defekten som ble identifisert i den første utgivelsen, og som er fikset i den senere utgitte. Og her vil vi også peke på listen over nylig lagt til, modifisert og slettet funksjoner fra alfa-utgivelsen til beta-utgivelsen.

Mal

Denne delen inneholder alle malene for dokumentene som skal brukes i produktet, og alle testingeniørene vil kun bruke disse malene i prosjektet for å opprettholde konsistensen til produktet. Her har vi ulike typer maler som brukes under hele testprosessen som:

Test case mal
Mal for gjennomgang av testcase
RTM-mal
Feilrapportmal
Testgjennomføringsrapport

La oss se ett eksempel på testplandokumentet

Side 1

Side3-side18

Side-20

På side 1 fyller vi først og fremst bare Versjoner, forfatter, kommentarer og anmeldt av feltene, og etter at lederen har godkjent det, vil vi nevne detaljene i Godkjent innen og godkjenningsdato Enger.

For det meste er testplanen godkjent av testlederen, og testingeniørene vurderer den kun. Og når de nye funksjonene kommer, vil vi modifisere testplanen og gjøre den nødvendige modifikasjonen Versjon feltet, og deretter sendes det igjen for videre gjennomgang, oppdatering og godkjenning av lederen. Testplanen må oppdateres hver gang det har skjedd endringer. På side 20 står Referanser spesifiser detaljene om alle dokumentene som vi skal bruke til å skrive testplandokumentet.

Merk:

Hvem skriver testplanen?

Testleder→60 %
Testleder→20 %
Testingeniør→20 %

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

Hvem vurderer testplanen?

Testleder
Testleder
Testingeniør
Kunde
Utviklingsteam

Testingeniøren gjennomgår testplanen for sitt modulperspektiv og testlederen gjennomgår testplanen basert på kundens mening.

Hvem godkjenner testplanen?

Kunde
Testleder

Hvem skriver testsaken?

Testleder
Testingeniør

Hvem vurderer testsaken?

Testingeniør
Testleder
Kunde
Utviklingsteam

Hvem godkjenner testsakene?

Testleder
Testleder
Kunde

Retningslinjer for testplan

Skjul testplanen din.
Unngå overlapping og redundans.
Hvis du tror at du ikke trenger en del som allerede er nevnt ovenfor, slett den delen og fortsett videre.
Vær spesifikk. For eksempel, når du spesifiserer et programvaresystem som en del av testmiljøet, nevner du programvareversjonen i stedet for bare navn.
Unngå lange avsnitt.
Bruk lister og tabeller der det er mulig.
Oppdater planen ved behov.
Ikke bruk et utdatert og ubrukt dokument.

Viktigheten av testplan

Testplanen gir retning til vår tenkning. Dette er som en regelbok, som må følges.
Testplanen hjelper til med å bestemme nødvendig innsats for å validere kvaliteten på programvareapplikasjonen under testen.
Testplanen hjelper disse menneskene til å forstå testdetaljene som er relatert til utsiden som utviklere, forretningsledere, kunder, etc.
Viktige aspekter som testplan, teststrategi, testomfang etc er dokumentert i testplanen slik at ledergruppen kan gjennomgå dem og gjenbruke dem til andre lignende prosjekter.