Meny

Komplett funksjonell testguide med typer og eksempler

complete functional testing guide with its types

Prøv Instrumentet Vårt For Å Eliminere Problemer

En grundig omfattende funksjonell testopplæring med typer, teknikker og eksempler:

Hva er funksjonstesting?

Funksjonstesting er en slags black-box testing som utføres for å bekrefte at funksjonaliteten til et program eller et system oppfører seg som forventet.

Det er gjort for å verifisere funksjonaliteten til en applikasjon.

LISTE over veiledningene dekket i denne serien:

Opplæring # 1: Hva er funksjonstesting (denne opplæringen)
Opplæring # 2: Funksjonalitetstest Intervju spørsmål
Opplæring # 3: Topp funksjonelle automatiserings testverktøy
Opplæring # 4: Hva er ikke-funksjonell testing?
Opplæring # 5: Forskjellen mellom enhet, funksjonell og Integrering Testing
Opplæring # 6 : Hvorfor funksjonstesting og ytelsestesting bør gjøres samtidig

Verktøy:

Opplæring # 7: Funksjonell testautomatisering med Ranorex Studio
Opplæring # 8: UFT funksjonsverktøy Nye funksjoner
Opplæring # 9: Funksjonell automatisering på tvers av nettlesere ved hjelp av Parrot QA Tool
Opplæring # 10: Jubula Open Source Tool tutorial for funksjonalitetstesting

funksjonstesting

Hva du vil lære:

Introduksjon til funksjonstesting

Det må være noe som definerer hva som er akseptabel oppførsel og hva som ikke er.

Dette er spesifisert i en funksjonell eller kravspesifikasjon. Det er et dokument som beskriver hva en bruker har tillatelse til å gjøre det, slik at han kan bestemme applikasjonens eller systemets samsvar med det. I tillegg kan dette noen ganger også medføre at de faktiske scenariene for virksomheten blir validert.

Derfor kan funksjonstesting utføres via to populære teknikker :

  • Testing basert på krav: Inneholder alle funksjonelle spesifikasjoner som danner grunnlag for alle testene som skal utføres.
  • Testing basert på forretningsscenarier: Inneholder informasjonen om hvordan systemet vil bli oppfattet fra et forretningsprosessperspektiv.

Testing og kvalitetssikring er en stor del av SDLC-prosessen. Som tester må vi være oppmerksomme på alle typer tester, selv om vi ikke er direkte involvert i dem daglig.

Ettersom testing er et hav, er omfanget av det så stort, og vi har dedikerte testere som utfører forskjellige typer testing . Sannsynligvis må vi alle være kjent med de fleste begrepene, men det vil ikke skade å organisere det hele her.

Funksjonelle testtyper

Funksjonstesting har mange kategorier, og disse kan brukes basert på scenariet.

De mest fremtredende typene diskuteres kort nedenfor:

Enhetstesting :

Enhetstesting utføres vanligvis av en utvikler som skriver forskjellige kodenheter som kan være relatert eller ikke-relatert for å oppnå en bestemt funksjonalitet. Hans, dette innebærer vanligvis å skrive enhetstester som vil kalle metodene i hver enhet og validere de når de nødvendige parametrene er passert, og returverdien er som forventet.

Kodedekning er en viktig del av enhetstesting der testtilfellene må eksistere for å dekke de følgende tre:

i) Linjedekning
ii) Kodeveidekning
iii) Metodedekning

Sanity Testing : Testing som gjøres for å sikre at alle de viktigste og viktige funksjonene til applikasjonen / systemet fungerer som de skal. Dette gjøres vanligvis etter en røykprøve.

Røykprøving : Testing som gjøres etter at hver build er utgitt for å teste for å sikre byggestabilitet. Det kalles også som testing for byggverifisering.

Regresjonstester : Testing utført for å sikre at tilsetning av ny kode, forbedringer, reparasjon av feil ikke bryter den eksisterende funksjonaliteten eller forårsaker ustabilitet, og fungerer fremdeles i henhold til spesifikasjonene.

Regresjonstester trenger ikke å være så omfattende som de faktiske funksjonstestene, men de skal sikre nettopp dekning for å bekrefte at funksjonaliteten er stabil.

Integrasjonstester : Når systemet er avhengig av flere funksjonelle moduler som kan fungere perfekt hver for seg, men må jobbe sammenhengende når de er slått sammen for å oppnå et slutt-til-slutt-scenario, kalles validering av slike scenarier Integrasjonstesting.

Beta / brukervennlighetstesting : Produktet blir eksponert for den faktiske kunden i en produksjon som et miljø, og de tester produktet. Brukerens komfort er hentet fra dette, og tilbakemeldingen er hentet. Dette er likt det som ble testet med brukeraksept.

La oss representere dette i et enkelt flytskjema:

Funksjonelle testkategorier

Funksjonell systemtesting:

Systemtesting er en testing som utføres på et komplett system for å verifisere om det fungerer som forventet når alle modulene eller komponentene er integrert.

Test til slutt til slutt utføres for å verifisere produktets funksjonalitet. Denne testingen utføres bare når systemintegrasjonstesting er fullført, inkludert både funksjonelle og ikke-funksjonelle krav.

=> Forskjellen mellom test av enhet, funksjon og integrasjon

Prosess

Denne testprosessen har tre hovedtrinn:

Trinn for funksjonell testing prosess

Tilnærming, teknikker og eksempler

Funksjonell eller atferdstesting genererer en utgang basert på gitte innganger og avgjør om systemet fungerer som angitt i spesifikasjonene.

Derfor vil den billedlige representasjonen se ut som vist nedenfor:

Funksjonell testprosess

Inngangs- / utgangskriterier

Oppføringskriterier:

  • Kravspesifikasjonsdokumentet er definert og godkjent.
  • Test tilfeller er utarbeidet.
  • Testdata er opprettet.
  • Miljøet for testing er klart, alle verktøyene som kreves er tilgjengelige og klare.
  • Hele eller delvis søknad er utviklet og enhetstestet og er klar for testing.

Utgangskriterier:

  • Utførelsen av alle funksjonstestsakene er fullført.
  • Ingen kritiske eller P1, P2 feil er åpne.
  • Rapporterte feil er blitt anerkjent.

Involverte trinn

De forskjellige trinnene som er involvert i denne testingen er nevnt nedenfor:

  • Det aller første trinnet involvert er å bestemme funksjonaliteten til produktet som må testes, og det inkluderer testing av hovedfunksjonalitetene, feiltilstand og meldinger, brukervennlighetstesting, dvs. om produktet er brukervennlig eller ikke, etc.
  • Neste trinn er å lage inngangsdata for funksjonaliteten som skal testes i henhold til kravspesifikasjonen.
  • Senere, fra kravspesifikasjonen, bestemmes utdataene for funksjonaliteten som testes.
  • Forberedte testsaker utføres.
  • Faktisk utgang, dvs. utdata etter gjennomføring av testtilfelle og forventet utgang (bestemt ut fra kravspesifikasjon) sammenlignes for å finne ut om funksjonaliteten fungerer som forventet eller ikke.

Nærme seg

Ulike typer scenarier kan tenkes på og forfattes i form av 'testcases'. Som kvalitetsfolk vet vi alle hvordan skjelettet til en testsak ser ut.

Den har for det meste fire deler:

  • Testoppsummering
  • Forutsetninger
  • Test trinn og
  • Forventede resultater.

Å forsøke å skrive hver type test er ikke bare umulig, men også tidkrevende og kostbart.

Vanligvis vil vi avdekke maksimale feil uten noen rømning med eksisterende tester. Derfor trenger kvalitetssikring å bruke optimaliseringsteknikker og strategisere hvordan de vil nærme seg testingen.

La oss forklare dette med en eksempel.

Eksempler på brukstilfeller for funksjonstesting:

Ta en online HRMS-portal der den ansatte logger på med sin brukerkonto og passord. På påloggingssiden er det to tekstfelt for brukernavn og passord, og to knapper: Pålogging og Avbryt. Vellykket pålogging tar brukeren til HRMS-hjemmesiden og avbryt vil avbryte påloggingen.

Spesifikasjonene er som vist nedenfor:

#1 ) Bruker-ID-feltet tar minst 6 tegn, maksimalt 10 tegn, tall (0-9), bokstaver (a-z, A-z), spesialtegn (bare understrek, periode, bindestrek tillatt), og det kan ikke stå tomt. Bruker-ID må begynne med et tegn eller et tall og ikke spesialtegn.

#to) Passordfeltet tar minst 6 tegn, maksimalt 8 tegn, tall (0-9), bokstaver (a-z, A-Z), spesialtegn (alle), og kan ikke være blanke.

Eksempel på bruk - HRMS Online Portal

Den grunnleggende tilnærmingen til å teste dette scenariet kan klassifiseres i to brede kategorier:

  1. Positiv testing og
  2. Negativ testing

Selvfølgelig har hver av disse kategoriene sin underseksjon av tester som skal utføres.

Positive tester er glade banetester som er gjort for å sikre at produktet oppfyller - i det minste grunnleggende krav som er avgjørende for kundebruk.

Negative scenarier sørg for at produktet oppfører seg ordentlig selv når det utsettes for uventede data.

Foreslått lese => Hva er negativ testing og hvordan du skriver negative testtilfeller

La meg nå prøve å strukturere testteknikkene ved hjelp av et flytskjema nedenfor. Vi kommer inn på detaljene i hver av disse testene.

Funksjonelle testteknikker

Funksjonelle testteknikker

# 1) Sluttbrukerbasert / Systemtester

Systemet som testes kan ha mange komponenter som når de kobles sammen oppnår brukerscenariet.

I Eksempel , vil et kundescenario inkludere oppgaver som å laste inn HRMS-applikasjoner, legge inn riktig legitimasjon, gå til hjemmesiden, utføre noen handlinger og logge av systemet. Denne spesielle strømmen må fungere uten feil for et grunnleggende forretningsscenario.

gratis hurtigbokalternativ for småbedrifter

Noen eksempler er gitt nedenfor:

Sl NeiSammendragForutsetningTestforsøkForventede resultater.
1.Fullt privilegert bruker kan gjøre kontoendringer1) Brukerkonto må eksistere
2) Brukeren må ha de nødvendige rettighetene		1) Bruker angir bruker-ID og passord
2) Brukeren ser redigeringstillatelser for å endre selve kontoen
3) Bruker endrer kontoinformasjon og lagrer.
4) Bruker logger ut.		1) Bruker er logget inn på hjemmesiden
2) Redigeringsskjermbildet presenteres for brukeren.

3) Kontoinformasjon lagres
4) Brukeren føres tilbake til påloggingssiden
to.En annen gyldig bruker uten fulle rettigheter1) Brukerkonto må eksistere
2) Brukeren må ha minimumsrettigheter		1) Bruker angir bruker-ID og passord
2) Brukeren ser redigeringstillatelser for å endre bare visse felt.
3) Bruker endrer bare disse feltene og lagrer.
4) Bruker logger ut.		1) Bruker er logget inn på hjemmesiden
2) Redigeringsskjermbildet presenteres kun for brukeren på visse felt. Kontofeltene er nedtonede.
3) Feltene som er modifisert lagres
4) Brukeren føres tilbake til påloggingssiden

Dette er et grunnleggende eksempel på hvordan testsaker er skrevet for situasjoner. Formatet ovenfor vil også gjelde for alle testene nedenfor. Av hensyn til sterk konseptuell forankring har jeg bare lagt inn noen enkle tester over og under.

# 2) Ekvivalens tester

I Partisjonering av ekvivalens testdataene er adskilt i forskjellige partisjoner kalt ekvivalensdataklasser. Data i hver partisjon må oppføre seg på samme måte, derfor trenger bare en tilstand å testes. På samme måte, hvis en tilstand i en partisjon ikke fungerer, vil ingen av de andre fungere.

For eksempel , i scenariet ovenfor kan bruker-ID-feltet ha maksimalt 10 tegn, så det å oppgi data> 10 skal oppføre seg på samme måte.

# 3) Grenseverditester

Grensetester innebærer datagrenser for applikasjonen og validerer hvordan den oppfører seg.

Derfor, hvis inngangene leveres utover grenseverdiene, anses det å være negativ testing. Så minimum 6 tegn for brukeren setter grensen. Tester skrevet for å ha bruker-ID<6 characters are boundary analysis tests.

# 4) Beslutningsbaserte tester

Beslutningsbaserte tester er sentrert rundt ideologien om de mulige resultatene av systemet når en bestemt betingelse er oppfylt.

I ovennevnte scenario kan følgende beslutningsbaserte tester umiddelbart utledes:

  1. Hvis feil legitimasjon er angitt, skal det indikere det til brukeren og laste påloggingssiden på nytt.
  2. Hvis brukeren oppgir riktig legitimasjon, bør den ta brukeren til neste brukergrensesnitt.
  3. Hvis brukeren oppgir riktig legitimasjon, men ønsker å avbryte påloggingen, bør den ikke ta brukeren til neste brukergrensesnitt og laste inn påloggingssiden på nytt.

# 5) Alternative flytester

Alternative banetester kjøres for å validere alle mulige måter som eksisterer, bortsett fra hovedflyten for å utføre en funksjon.

# 6) Ad-hoc-tester

Når de fleste feilene blir avdekket gjennom teknikkene ovenfor, ad-hoc tester er en fin måte å avdekke avvik som ikke er observert tidligere. Disse utføres med tankene om å bryte systemet og se om det reagerer elegant.

For eksempel vil en prøvesak være:

  • En bruker er pålogget, men administratoren sletter brukerkontoen mens han utfører noen operasjoner. Det ville være interessant å se hvordan applikasjonen håndterer dette elegant.

Funksjonell vs ikke-funksjonell testing:

Ikke-funksjonelle tester fokus på kvaliteten på applikasjonen / systemet som helhet. Derfor prøver den å utlede hvor godt systemet fungerer i henhold til kundens krav, i motsetning til funksjonen det utfører.

=> Les den nøyaktige forskjellen her

Funksjonell testautomatisering

Kan vi automatisere funksjonelle tester?

Med automatisering kan manuell innsats reduseres, tid kan spares, feilglidning kan unngås og effektiviteten kan økes.

Det er imidlertid ikke mulig å automatisere hver eneste ting. Denne testen kan automatiseres, men brukeren må trene for at testtilfeller skal gjøres. Det er viktig å finne de riktige testtilfellene som skal automatiseres sammen med et passende verktøy.

Automatisering av funksjonelle saker kan ha ulemper som om antall testtilfeller er mye mer og blir tilbakegang igjen og igjen (noe som må gjøres), så kan utvikleren stå overfor et problem med å utføre endringer i koden.

Mange ganger mens du utfører mangelfluktanalyse, ser den fremtredende og flerårige årsaken til rømming ut til å ha mangel på testdekning i en bestemt funksjon.

Igjen, det er flere årsaker til at dette kan skje som mangel på miljøer, mangel på testere, for mange funksjoner som blir levert, mindre tid til å dekke alle testaspektene, og noen ganger bare med utsikt over den.

Mens dedikerte testteam kan gjøre detaljert testing på hver sprint eller hver testsyklus, vil mangler alltid eksistere, og det vil alltid være feil som kan gå glipp av. Dette er et av de grunnleggende behovene for å ha testautomatisering på plass, og dermed ha en markant forbedring i effektiviteten til den totale testprosessen og testdekning.

Selv om automatisert testing aldri kan erstatte manuelle tester, vil det være viktig å ha en ideell blanding av de to for å ha ønsket kvalitet i programvareprosjekter.

Hensyn til automatisering:

#1) Velg riktig automatiseringsverktøy : Det er flere verktøy tilgjengelig i markedet, å velge et automatiseringsverktøy er en virkelig skremmende oppgave! Du kan imidlertid lage en liste over krav, basert på hvilke du kan velge hvilket automatiseringsverktøy du vil bruke.

Noen hovedaspekter å tenke på inkluderer:

  • Velg et verktøy som vil være enkelt å bruke av alle QA-medlemmene i teamet, hvis de ikke allerede har de nødvendige ferdighetene.
  • Verktøyet kan brukes i forskjellige miljøer. Til Eksempel : Kan manusene opprettes på en OS-plattform og kjøres på en annen? Trenger du CLI-automatisering, UI-automatisering, mobilapplikasjonsautomatisering eller alt?
  • Verktøyet må ha alle funksjonene du trenger. Til Eksempel : Hvis noen testere ikke er kjent med et skriptspråk, bør verktøyet ha en innspillings- og avspillingsfunksjon og deretter støtte konvertering av det innspilte skriptet til ønsket skriptspråk. På samme måte, hvis du også trenger verktøyet for å støtte automatiserte byggetester, spesifikk rapportering og logging, må den også kunne gjøre det.
  • Verktøyet må kunne støtte gjenbrukbarhet av testsaker i tilfelle UI-endringer.

Automatiseringsverktøy : Det er ganske mange verktøy som er tilgjengelige for funksjonell automatisering. Selen er sannsynligvis en populær favoritt, men det er også noen andre open source-verktøy som Sahi, Watir, Robotium, AutoIt, etc.

Flere testautomatiseringsverktøy er tilgjengelige i markedet. Men å velge riktig verktøy er veldig viktig for organisasjonen. Det kan avhenge av kravet, brukervennligheten og kostnadene spiller en viktig rolle her.

Nedenfor er noen av de beste funksjonelle testverktøyene:

  • Selen
  • QTP
  • Junit
  • Loadrunner
  • SÅPE
  • TestFullfør

=> Sjekk denne komplette listen over topp funksjonelle automatiseringsverktøy

#to) Velg de riktige testtilfellene for å automatisere : Hvis du vil få mest mulig ut av automatisering, er det viktig å være smart om hva slags tester du velger å automatisere. Hvis det er tester som krever noe oppsett og konfigurasjoner på og av under testutførelsen, er de best å ikke automatisere.

Derfor kan du automatisere tester som:

  • Må kjøres gjentatte ganger.
  • Kjør med forskjellige typer data.
  • Noen P1, P2 testtilfeller tar mye krefter og tid.
  • Tester som er feil utsatt.
  • Sett med tester som må kjøres i forskjellige miljøer, nettlesere osv.

# 3) Dedikert automatiseringsteam : Dette blir sannsynligvis oversett i de fleste organisasjoner, og automatisering pålegges alle medlemmene av QA-teamet.

Hvert teammedlem har varierte erfaringsnivåer, ferdighetssett, interessenivåer, båndbredde for å støtte automatisering, etc. Noen individer er muligens bedre dyktige til å utføre manuelle tester, mens noen andre kanskje kjenner til skript- og automatiseringsverktøy.

I situasjoner som dette er det en god praksis å ta en analyse av alle medlemmene i teamet og ha noen medlemmer dedikert til å gjøre bare automatisering.

Automatiseringsaktivitet krever tid, krefter, kunnskap og et dedikert team som vil bidra til å oppnå de nødvendige resultatene i stedet for å overbelaste alle medlemmene i teamet med både manuell og automatiseringstesting.

# 4) Datadrevne tester: Automatiserte testsaker som krever flere datasett, bør være godt skrevet slik at de kan brukes på nytt. Dataene kan skrives i kilder som tekst- eller egenskapsfil, XML-filer eller leses fra en database.

Uansett hva datakilden er, å lage velstrukturerte automatiseringsdata gjør rammeverket lettere å vedlikeholde og gjør de eksisterende testskriptene utnyttet til sitt fulle potensial.

# 5) UI-endringer må ikke bryte tester: Testtilfellene du oppretter ved hjelp av det valgte verktøyet, må kunne håndtere de potensielle UI-endringene. Tidligere versjoner av selen brukte for eksempel et sted for å identifisere sideelementene.

Derfor, hvis brukergrensesnittet endret seg, ble disse elementene ikke lenger funnet på disse stedene, og vil igjen føre til massesvikt i testene.

Derfor er det viktig å forstå manglene ved verktøyet på forhånd og lage testtilfellene slik at det bare kreves minimale endringer i tilfelle UI-endringer.

# 6) Hyppig testing: Når du har en grunnleggende automatiseringstestbøtte klar, planlegger du å utføre hyppigere av denne bøtta. Dette har en toveis fordel: Den ene er at du kan forbedre automatiseringsrammeverket og gjøre det mer robust, og det andre er at du vil fange flere feil i prosessen.

Fordeler

Nedenfor er de forskjellige fordelene med funksjonstesting:

  • Denne testen reproduserer eller er en kopi av hva det faktiske systemet er, dvs. det er en kopi av hva produktet er i det levende miljøet. Testing er fokusert på spesifikasjonene i henhold til kundens bruk, dvs. systemspesifikasjoner, operativsystem, nettlesere, etc.
  • Det fungerer ikke på noen om og men eller antakelser om systemets struktur.
  • Denne testingen sørger for å levere et produkt av høy kvalitet som oppfyller kundens krav og sørger for at kunden er fornøyd med sluttresultatene.
  • Det sørger for å levere et feilfritt produkt som har alle funksjonene som fungerer i henhold til kundens krav.
  • Risikobasert testing gjøres for å redusere sjansene for enhver form for risiko i produktet.

Begrensninger

Denne testingen er gjort for å sikre at produktet fungerer som forventet, og at hele kravet er implementert, og at produktet er nøyaktig i henhold til kundens krav.

Imidlertid tar det ikke hensyn til de andre faktorene som ytelsen til produktet, dvs. respons, gjennomløpstid osv., Som er viktige og som det kreves veldig mye for å være en del av testingen før du slipper produktet.

Ulemper

  • Det er mange sjanser for å utføre overflødig testing.
  • Logiske feil kan gå glipp av produktet.
  • Denne testingen er basert på kravet, hvis det i tilfelle kravet ikke er fullstendig eller er komplisert eller ikke er klart, blir det vanskelig å utføre denne testen i et slikt scenario og kan også være tidkrevende.

Derfor er begge disse typene testing nødvendige for et kvalitetsprodukt.

Konklusjon

Denne veiledningen har omfattende diskutert alt du trenger å vite om funksjonstesting, helt fra det grunnleggende.

Funksjonstesting er en av de viktigste testprosessene, da den verifiserer funksjonaliteten til et produkt som er mest nødvendig og faktisk det viktige aspektet ved ethvert produkt eller applikasjon.

Om forfatteren: Sanjay Zalavadia - som VP for kundeservice for Zephyr , gir over 15 års ledererfaring innen IT og teknisk support.

Jeg håper at noen av teknikkene vi har foreslått vil være nyttige for alle leserne. Gi oss beskjed om dine tanker i kommentarene nedenfor.

Foreslått lese => Funksjonstestveiledning

Anbefalt lesing

^