Meny

Hva er testleveranser i programvaretesting?

  • Hoved
  • Annen
  • Hva er testleveranser i programvaretesting?

what are test deliverables software testing

Prøv Instrumentet Vårt For Å Eliminere Problemer

Lær alt om testleveranser i programvaretesting med eksempler:

Et lettelsens sukk kommer for hver tester når den tildelte oppgaven er fullført. På slutten av hver testing må testeren sende de aktuelle testleveransene til klienten.

I denne artikkelen vil vi se nærmere på noen av de viktige testleveransene.

c ++ matriser i funksjoner

Testleveranser brukes generelt gjennom et prosjekt. De brukes i alle testfaser, og de må alltid sendes i tide for å fortsette for videre behandling.

Testleveranser i programvaretesting

Hva du vil lære:

Testleveranser i programvaretesting

Testleveranser spiller en viktig rolle i programvaretesting. Denne artikkelen diskuterer alt om testleveranser i detalj.

Noen av de viktigste testleveransene er vervet nedenfor for din referanse:

  • Teststrategi
  • Testplan og estimering
  • Test scenario
  • Test tilfeller og testdata
  • RTM
  • Testoppsummeringsrapport
  • Testavslutningsrapport
  • Hendelsesrapport

Teststrategi

Teststrategi vil bli bestemt ut fra spesifikasjonene for forretningskrav. Det er et viktig dokument som inneholder alle detaljene i testarbeidet som skal utføres. Det er et komplett styringsdokument.

Sammenlignet med testplanen er dette et dokument på høyt nivå og blir vanligvis utarbeidet av testleder eller leder. Testmål, testtilnærming, testomfang, inngangs- og utgangskriterier, typer og nivåer av testing, milepæler, bemanning osv. Må nevnes her.

Testplan og estimering

Detaljer om granulatnivå for hvert trinn i testen bør nevnes her. Generelt fører en skikkelig plan til en riktig arbeidsstruktur. Tilsvarende fører en god plan til god testing.

Testmål, testtilnærming, testomfang, inngangs- og utgangskriterier, typer og nivåer av testing, milepæler, bemanning osv. Bør nevnes her på en detaljert måte.

Hovedplanen som inkluderer hvordan testing skal gjennomføres brukes til enkle prosjekter.

Anslag: Estimering definerer hvor lenge hvert trinn vil oppstå i testing sammen med den totale kostnaden.

Les også => En perfekt testplanopplæring - En grundig guide

Test Scenario

Vi vil forstå dette med et eksempel nå. La oss ta togreservasjonen som et eksempel her. Alle funksjonalitetene vi trenger å teste er nevnt i skjemaer på høyt nivå i testscenariedokumentet. Med enkle ord betyr det en gruppe lignende aktiviteter som skal utføres.

c ++ programmeringsintervju spørsmål

To teknikker for scenariet:

# 1) Bruk sak

Det er den målrettede metoden som er et sett av interaksjoner mellom de eksterne faktorene og systemet. Komponentene inkluderer primær flyt, alternativ flyt, utløsere eller aktiviteter, unntaksflyter, forutsetninger, etterbetingelser osv.

Eksempel:

Bruk sakseksempel

(bilde kilde )

# 2) ACE (aktivitetskomponentelement)

Activity Component Element-prosessen bryter virksomhetskravene inn i aktiviteter.

Eksempel:

Generelt bestiller vi en billett ved å fylle ut passasjerdetaljer, kjønn osv. Derfor må vi validere følgende felt som derved blir scenarier.

  • Reservasjon: Sjekk reservasjonsfunksjonaliteten.
  • Passasjer detaljer: Sjekk funksjonene for kjønn, alder og kjønnsfelt.
  • Endre: Sjekk om modifikasjonsfunksjonaliteten fungerer som den skal.
  • Konsesjon: Sjekk om konsesjonsfunksjonaliteten fungerer som den skal.
  • Utsikt: Sjekk om visningsfunksjonaliteten fungerer som den skal.
  • Avbryt: Sjekk om avbrytingsfunksjonaliteten fungerer som den skal.

Her kan konsesjonen kalles et “alternativt scenario” som brukeren kan bestille med eller uten det basert på alder. Målet er imidlertid det samme, dvs. å bestille en billett.

Testforsøk

Ved å ta det samme eksemplet ovenfor på reservasjonssiden, skrives testsakene som følger:

Reservasjon:

  • Sjekk om brukeren kan bestille en billett ved å fylle ut gyldige detaljer i alle feltene.
  • Sjekk om brukeren kan bestille en billett ved å fylle ugyldige detaljer i alle feltene.
  • Sjekk om brukeren kan bestille en billett ved å legge igjen et tomt felt.

Passasjer detaljer:

  • Sjekk om brukeren kan bestille en billett ved å angi et gyldig navn.
  • Sjekk om brukeren kan bestille en billett ved å angi et ugyldig navn.
  • Sjekk om brukeren kan bestille en billett ved å velge ett kjønn om gangen.
  • Sjekk om brukeren kan bestille en billett ved å angi alder over 60 år.
  • Sjekk om brukeren kan bestille en billett ved å oppgi en alder under 60 år.
  • Sjekk om brukeren kan bestille en billett ved å oppgi en gyldig alder over 5 år.
  • Sjekk om brukeren ikke kan bestille ved å angi en alder under 5 år.

Endre:

  • Sjekk om brukeren kan endre navnefeltet.
  • Sjekk om brukeren kan endre kjønnsfeltet.
  • Sjekk om brukeren kan endre aldersfeltet.

Konsesjon:

  • Sjekk om brukeren kan få konsesjon ved å velge “ Pensjonist ”Alternativet.
  • Sjekk om brukeren kan få konsesjon ved å velge “ Handikappede / funksjonshemmede ”Alternativet.

Utsikt:

  • Sjekk om brukeren kan se billetten reservert.

Avbryt:

  • Sjekk om brukeren kan kansellere billetten.

Dermed forteller testtilfeller hva som må testes i detalj. Testtilfeller må skrives på et enkelt språk og skal være lett forståelig. Den skal skrives i riktig format slik den berørte klienten ber om det.

Testdata

Noen prosjekter trenger forhåndsdata fra klienten før de fortsetter med gjennomføringen av testsaken. Testdata må brukes for å utføre testing.

Eksempel: I sykehusportalen for å få en injeksjon, er det viktig å få pasientopplysningene til å sjekke alternativet om injeksjonspåminnelse.

hvordan du åpner en swf-fil i krom

Her er 'pasientdetaljene' testdataene.

Foreslått lese => Testdata - Betydning og tilberedningsteknikker med eksempler

RTM / kravsporbarhetsmatrise

  • Som navnet antyder, betyr det ganske enkelt at du må kartlegge alle krav med riktig testtilfelle.
  • Det hjelper oss med å sjekke om vi har dekket alle kravene i testsakene våre eller ikke.
  • Det hjelper med omarbeiding eller neste påfølgende utgivelser av et prosjekt.
  • Klienten kan enkelt sjekke dekningsstatusen vår og kjenne testprosessen vår.

RTM

Test Sammendrag Rapport

Testoppsummeringsrapport oppsummerer alle testaktivitetene som er utført, og testresultatene er samlet i den. All testinformasjon som medlemmer som er involvert i testing, mål, omfang, klientdetaljer, testtilnærming brukt, testresultater, feilrapport osv. Bør nevnes her.

Testoppsummeringsrapporten bør imidlertid utarbeides i henhold til klientens råd. Dermed er det et nyttig dokument for klienten også å gjennomgå den totale ytelsen.

Test avsluttingsrapport

Det betyr at vi skal stenge prosjektet etter testing og feilretting. Så her må vi gi en detaljert analyse av utførelsen av testene.

Feilene som er funnet og løst, må nevnes her. Den samlede kravdekningen ses i denne rapporten. Det er vanligvis utarbeidet av teamledelsen eller lederen. Alle utgangskriteriene bør oppfylles tilsvarende.

Hendelsesrapport

Mens en formasjon kjøres hvis en bruker finner feil, bør det heves en hendelsesrapport (IR). Dette betyr at det er en mangel, og dermed må henrettelsen stoppes. Vi må nå heve en hendelsesrapport til klienten for å be dem om tillatelse til å utføre feilområdene igjen som en egen testsak.

Dette er virkelig et svart merke og forventes ikke av en tester. Alle feilene må finnes i selve tørrkjøringen. Hvis det blir savnet og funnet i formell henrettelse, blir det en IR.

Eksempel:

Hvis jeg savner viss funksjonalitet i mobiltesting, si ' skjermsparer endring ' alternativ. Så når jeg utfører en testtilfelle blir jeg låst, og jeg vil ikke være i stand til å gå videre på grunn av dette alternativet. Så hever jeg en IR og skriver en egen testtilfelle for å utføre skjermspareralternativet.

Konklusjon

Artefaktene som sendes til interessentene i et programvareprosjekt under STLC er kjent som Test Deliverables. Vi så på de viktigste testleveransene i denne artikkelen.

Vi håper denne artikkelen hjalp deg med å lære om testleveranser i programvaretesting !!

Anbefalt lesing

^