Meny

Testutførelse i programvaretesting: Nøyaktig prosess og plan med eksempel

test execution software testing

Prøv Instrumentet Vårt For Å Eliminere Problemer

Nøyaktig prosess og planlegger å utføre testsaker med reelle eksempler.

I dag, i vår Programvaretesting minikurs , vi går videre til den siste fasen av STLC, som er Testutførelse .

Du kan sjekke ut listen over alle opplæringene som er lagt ut i denne gratis QA-opplæringsserien på denne siden: End to End programvare testing trening på et live prosjekt.

Testutførelse er uten tvil den viktigste og 'skjerende' fasen i STLC og også hele utviklingssyklusen. Årsaken er - hvert team / teammedlems bidrag og arbeid blir validert her:

Testutførelse i programvaretesting

  • Har forretningsanalytikeren tolket kravene riktig?
  • Har utviklingsteamet oversatt forretningskravene til funksjonelle krav og til slutt å kode riktig?
  • Har dataarkitekten og DBA-ene designet de riktige backend-systemene?

Vel, testutførelse er der alle svarene på disse spørsmålene vil bli funnet. Det gjør oss, QA som helter i hele programvarebyggingsprosessen, ikke sant? :)

Testutførelse er også 'Test' -delen av SDLC.

gratis SQL-programvare for Windows 10

Når testtilfellene er skrevet, delt med BAs og Dev-teamet, gjennomgått av dem, blir endringer varslet til QA-teamet (hvis noen), gjør QA-teamet nødvendige endringer - Testdesignfasen er fullført. Nå å gjøre testsakene klare betyr ikke at vi kan starte testkjøringen. Vi må ha søknaden klar også blant annet.

Hva du vil lære:

Retningslinjer for testutførelse

La oss nå lage en liste over alle ting som er viktige for å forstå testutførelsesfasen:

#1) De bygge (koden som er skrevet av dev-teamet er pakket inn i det som refereres til en build - dette er ingenting annet enn en installerbar programvare (AUT), klar til å distribueres til QA-miljø.) blir distribuert (med andre ord installert og gjort tilgjengelig) for QA-miljøet er en av de viktigste aspektene som må skje for at testutførelsen skal starte.

#to) Testutførelse skjer i QA-miljø . For å sikre at dev-teamets arbeid med koden ikke er på samme sted der QA-teamet tester, er allmennpraksis å ha et dedikert Dev- og QA-miljø. (Det er også et produksjonsmiljø for å være vert for live-applikasjonen).

Dette er i utgangspunktet for å bevare integriteten til applikasjonen på forskjellige stadier i SDLC-livssyklusen. Ellers er ideelt sett alle tre miljøene identiske.

# 3) Test teamets størrelse er ikke konstant fra begynnelsen av prosjektet. Når testplanen er igangsatt, kan teamet bare ha en teamleder. I løpet av testdesignfasen kommer noen få testere ombord. Testutførelse er fasen når laget har maksimal størrelse.

# 4) Testutførelse skjer også i minst to sykluser (3 i noen prosjekter). Vanligvis i hver syklus vil alle testtilfeller (hele testpakken) bli utført. Målet med den første syklusen er å identifisere blokkerende, kritiske feil og de fleste av de høye feilene.

Målet med den andre syklusen er å identifisere gjenværende høye og mellomstore feil, korrigere hull i skriptene og oppnå resultater.

# 5) Testutførelsesfasen består av- Utføre testskriptene + Vedlikeholde testskriptet (rette hull i skriptene) + Rapportering (feil, status, beregninger osv.) Derfor, når du planlegger denne faseplanen og innsatsen bør estimeres tar hensyn til alle disse aspektene, og ikke bare skriptutførelsen.

# 6) Etter at testskriptet er ferdig og AUT er distribuert - og før testutførelsen begynner, er det et mellomledd. Dette kalles “Test Readiness Review (TRR)” . Dette er et slags overgangstrinn som vil avslutte testdesignfasen og lette oss i testutførelsen.

For informasjon om dette trinnet og et eksempel 'Sjekkliste for testberedskap', sjekk ut denne lenken: Sjekkliste for programvaretesting

hvordan reverserer du en matrise på plass i java?

# 7) I tillegg til TRR, er det få flere tilleggskontroller før vi sørger for at vi kan fortsette med å godta den nåværende versjonen som er distribuert i QA-miljøet for testutførelse.

Det er de Røyk- og sunnhetstester . Detaljert informasjon om hva dette er er på: Hva er røyk- og sunnhetstest?

# 8) Etter vellykket gjennomføring av TRR, Smoke and Sanity-tester begynner testsyklusen offisielt.

# 9) Utforskende testing vil bli utført når bygningen er klar for testing. Hensikten med denne testen er å sørge for at kritiske feil blir fjernet før neste testnivå kan starte. Denne utforskende testingen utføres i applikasjonen uten testskripter og dokumentasjon. Det hjelper også å bli kjent med AUT.

# 10) Akkurat som de andre fasene i STLC, er arbeidet delt mellom teammedlemmer også i testutførelsesfasen. Inndelingen kan være basert på modulvis eller testtelling eller noe annet som kan være fornuftig.

#elleve) Det primære utfallet av testutførelsesfasen er i form av rapporter, det vil si hovedsakelig dvs. Den detaljerte prosessen for rapportering finner du på Testutførelsesrapporter.

Nye kolonner i dokumentet om prøvesaker

Test Case-dokumentet må nå utvides med følgende to kolonner - Status og faktisk resultat .

( Merk : For live-prosjekt Testutførelse har vi lagt til og oppdatert disse kolonnene med resultater for testutførelse i regnearket for testtilfeller som er gitt for nedlasting nedenfor)

# 1) Statuskolonne

Testutførelse er bare å bruke testtrinnene på AUT, levere testdata (som identifisert i testdokumentet) og observere AUT atferd for å se om den tilfredsstiller det forventede resultatet eller ikke.

Hvis det forventede resultatet ikke blir oppfylt, kan det tolkes som en mangel. Og statusen til testsaken blir 'Mislykket', og hvis forventet resultat blir oppfylt, er statusen 'Bestått'. Hvis testsaken ikke kan utføres på grunn av noen årsaker (en eksisterende mangel eller et miljø som ikke støtter), vil statusen bli 'blokkert'.

Status for en testtilfelle som ennå ikke skal kjøres kan settes til Ingen kjøring / ikke utført eller kan stå tom.

  • For et testsak med flere trinn, hvis et bestemt trinns (midt i testsaken trinnene) forventede resultat ikke blir oppfylt, kan testsakens status settes til 'Mislykkes' akkurat der, og de neste trinnene trenger ikke utføres.
  • Statusen 'Mislykkes' kan angis i rød farge, hvis du vil gjøre oppmerksom på den med en gang.

# 2) Faktisk resultatkolonne

Dette er et rom der vi testere kan registrere hva avviket i forventet resultat er. Når det forventede resultatet er oppfylt (eller en testtilfelle som har statusen 'Bestått'), kan dette feltet stå tomt. For, hvis det forventede resultatet blir oppfylt, betyr det det faktiske resultatet = forventet resultat, som betyr at omskriving av det i den faktiske resultatkolonnen vil være en repetisjon og redundans.

Et skjermbilde av avviket kan legges til denne kolonnen for å få bedre klarhet i hva problemet er.

Testutførelsesresultater for OrangeHRM Live Project

La oss nå få OrangeHRM og utføre testutførelsen basert på de ovennevnte retningslinjene.

intervju spørsmål om avslappende nettjenester

Her er noen punkter å merke seg:

  • Den utvidede prøvesaksmalen.
  • Undersøkende testing som angitt skal utføres uten testmanus. Så vær så snill å teste søknaden parallelt slik du ønsker det.
  • På grunn av begrensningene vi har med å presentere live-prosjektet i form av lesbart innhold, vises bare en begrenset mengde testtilfeller / funksjonalitet i OrangeHRM-applikasjonen i eksemplet på testutførelsesmalen. Igjen, vær så snill å jobbe med mer for den mest praktiske opplevelsen.
  • Sanity og Smoke test suitene blir også lagt til i dokumentet, for å gi deg en ide om hva slags testsaker som vurderes for disse trinnene.
  • Mangler er ikke logget ennå, selv om statusen til noen testsaker er satt til 'Mislykket'. Dette er fordi det å logge feilene er det viktigste / ofte arbeidet med et aspekt av livet vårt som testere. Så, vi vil håndtere det i detalj i neste artikkel.

Test tilfeller med utførelsesresultater:

=> Klikk her for å laste ned dokumentet Test Case Execution.

Det inneholder - Resultatutførelse av prøvesaker, Røykprøver, sunnhetstester, utforskende test - regneark

Til slutt, hvis et testadministrasjonsverktøy ble brukt til å lage og vedlikeholde testsaken, kan det samme også brukes til testutførelse. Bruken av et verktøy gjør rapporteringen enklere, men ellers er prosessen med å kjøre testsakene den samme. Ta en titt på denne artikkelen for å få en ide om hvordan du bruker HP ALM til testutførelse .

(Klikk på bildet for en forstørret visning)

ALM for testutslippsresultat

Dette bringer oss til slutten av et annet interessant segment av testprosessen. I neste og siste artikkel av dette gratis online programvaretesting QA-trening minikurs , vil vi se nærmere på mangler; avslutt emner som 'når skal du slutte å teste', beregninger og kvalitetssikring.

=> QA treningsdag 6: Feilsøking, testberegning og testavmelding

Gi oss beskjed om hvordan vi har det, og følg med på neste artikkel.

Anbefalt lesing

^