Komplet funktionel testguide med dens typer og eksempel

complete functional testing guide with its types

En dybtgående omfattende funktionel testvejledning med typer, teknikker og eksempler:

Hvad er funktionstestning?

Funktionel test er en slags black-box test, der udføres for at bekræfte, at funktionaliteten i et program eller system opfører sig som forventet.

Det gøres for at verificere al funktionalitet i en applikation.

LISTE over de selvstudier, der er dækket af denne serie:

Tutorial # 1: Hvad er funktionstest (denne vejledning)
Tutorial # 2: Funktionstest Interviewspørgsmål
Tutorial # 3: Top funktionelle automatiserings testværktøjer
Tutorial # 4: Hvad er ikke-funktionel test?
Tutorial # 5: Forskellen mellem enhed, funktionel og Integration Testning
Tutorial # 6 : Hvorfor funktionalitet og ydelsestest skal udføres samtidigt

Værktøjer:

Tutorial # 7: Funktionel testautomatisering med Ranorex Studio
Tutorial # 8: UFT funktionelt værktøj Nye funktioner
Tutorial # 9: Cross Browser Functional Automation ved hjælp af Parrot QA Tool
Tutorial # 10: Jubula Open Source Tool tutorial til funktionstest

Hvad du lærer:

• Introduktion til funktionstest
  • Funktionelle testtyper
  • Behandle
  • Indgangs- / udgangskriterier
    • Indgangskriterier:
    • Udgangskriterier:
  • Involverede trin
  • Nærme sig
  • Funktionelle testteknikker
    • # 1) Slutbrugerbaseret / Systemtest
    • # 2) Ækvivalens test
    • # 3) Grænseværditest
    • # 4) Beslutningsbaserede tests
    • # 5) Alternative flowtests
    • # 6) Ad hoc-tests
  • Funktionel testautomatisering
  • Fordele
  • Begrænsninger
  • Konklusion
  • Anbefalet læsning

Introduktion til funktionstest

Der skal være noget, der definerer, hvad der er acceptabel adfærd, og hvad der ikke er.

Dette er specificeret i en funktionel eller kravspecifikation. Det er et dokument, der beskriver, hvad en bruger har tilladelse til at gøre det, at han kan bestemme applikationens eller systemets overensstemmelse med det. Derudover kan dette undertiden også medføre, at de faktiske forretningssidescenarier valideres.

Derfor kan funktionstest udføres via to populære teknikker :

• Test baseret på krav: Indeholder alle de funktionelle specifikationer, der danner grundlag for alle de test, der skal udføres.
• Test baseret på forretningsscenarier: Indeholder oplysningerne om, hvordan systemet opfattes ud fra et forretningsprocesperspektiv.

Test og kvalitetssikring er en stor del af SDLC-processen. Som tester skal vi være opmærksomme på alle typer test, selvom vi ikke er direkte involveret i dem dagligt.

Da test er et hav, er omfanget af det faktisk så stort, og vi har dedikerede testere, der udfører forskellige former for test . Vi må sandsynligvis alle være fortrolige med de fleste af begreberne, men det vil ikke skade at organisere det hele her.

Funktionelle testtyper

Funktionel test har mange kategorier, og disse kan bruges ud fra scenariet.

De mest fremtrædende typer diskuteres kort nedenfor:

Enhedstest :

Enhedstest udføres normalt af en udvikler, der skriver forskellige kodeenheder, der kan være relaterede eller ikke-relaterede for at opnå en bestemt funktionalitet. Hans, dette indebærer normalt at skrive enhedstest, der kalder metoderne i hver enhed og validerer dem, når de krævede parametre overføres, og dens returværdi er som forventet.

Kodedækning er en vigtig del af enhedstest, hvor testsagerne skal eksistere for at dække nedenstående tre:

i) Linjedækning
ii) Dækning af kodesti
iii) Metodedækning

Sanity Testing : Test der udføres for at sikre, at alle de vigtigste og vitale funktioner i applikationen / systemet fungerer korrekt. Dette gøres normalt efter en røgtest.

Røgtest : Test, der udføres efter hver build er frigivet for at teste for at sikre build-stabilitet. Det kaldes også som test af buildverifikation.

Regressionstest : Test udført for at sikre, at tilføjelse af ny kode, forbedringer, rettelse af fejl ikke bryder den eksisterende funktionalitet eller forårsager ustabilitet og stadig fungerer i henhold til specifikationerne.

Regressionstest behøver ikke være så omfattende som de faktiske funktionstest, men skal sikre lige så meget dækning for at bekræfte, at funktionaliteten er stabil.

Integrationstests : Når systemet er afhængig af flere funktionelle moduler, der måske fungerer perfekt, men skal arbejde sammenhængende, når de er sammenkoblet for at opnå et ende-til-slut-scenarie, kaldes validering af sådanne scenarier Integrationstest.

Beta / brugervenlighedstest : Produktet udsættes for den faktiske kunde i en produktion som et miljø, og de tester produktet. Brugerens komfort stammer fra dette, og feedbacken er taget. Dette svarer til testet af brugeraccept.

Lad os repræsentere dette i et let flowdiagram:

Test af funktionelt system:

Systemtest er en test, der udføres på et komplet system for at kontrollere, om det fungerer som forventet, når alle moduler eller komponenter er integreret.

Test til ende til slut udføres for at verificere produktets funktionalitet. Denne test udføres kun, når test af systemintegration er afsluttet, herunder både de funktionelle og ikke-funktionelle krav.

=> Forskellen mellem test af enhed, funktion og integration

Behandle

Denne testproces har tre hovedtrin:

Tilgang, teknikker og eksempler

Funktionel eller adfærdsmæssig test genererer en output baseret på de givne input og bestemmer, om systemet fungerer korrekt i henhold til specifikationerne.

Derfor vil den billedlige gengivelse se ud som vist nedenfor:

Indgangs- / udgangskriterier

Indgangskriterier:

• Kravspecifikationsdokumentet er defineret og godkendt.
• Testcases er udarbejdet.
• Testdata er oprettet.
• Miljøet til test er klar, alle nødvendige værktøjer er tilgængelige og klar.
• Hele eller delvise applikationer er udviklet og enhedstestet og klar til test.

Udgangskriterier:

• Udførelsen af ​​alle funktionelle testsager er afsluttet.
• Ingen kritiske eller P1, P2 bugs er åbne.
• Rapporterede fejl er blevet anerkendt.

Involverede trin

De forskellige trin involveret i denne test er nævnt nedenfor:

• Det allerførste trin involveret er at bestemme funktionaliteten af ​​det produkt, der skal testes, og det inkluderer test af hovedfunktionaliteter, fejltilstand og meddelelser, test af brugervenlighed, dvs. om produktet er brugervenligt eller ej osv.
• Det næste trin er at oprette inputdata til den funktionalitet, der skal testes i henhold til kravspecifikationen.
• Senere bestemmes output fra kravspecifikationen for den funktionalitet, der testes.
• Forberedte testsager udføres.
• Faktisk output, dvs. output efter udførelse af testtilfælde og forventet output (bestemt ud fra kravspecifikation) sammenlignes for at finde ud af, om funktionaliteten fungerer som forventet eller ej.

Nærme sig

Forskellige slags scenarier kan overvejes og udarbejdes i form af 'testcases'. Som QA-folk ved vi alle, hvordan skelettet til en testsag ser ud.

Det har for det meste fire dele til det:

• Testoversigt
• Forudsætninger
• Test trin og
• Forventede resultater.

At forsøge at oprette enhver form for test er ikke kun umuligt, men også tidskrævende og dyrt.

Typisk vil vi afdække de maksimale fejl uden nogen undslip med eksisterende tests. Derfor er QA nødt til at bruge optimeringsteknikker og strategisere, hvordan de vil nærme sig testningen.

Lad os forklare dette med en eksempel.

Eksempler på anvendelse af funktionstestning:

Tag en online HRMS-portal, hvor medarbejderen logger ind med sin brugerkonto og adgangskode. På login-siden er der to tekstfelter til brugernavnet og adgangskoden og to knapper: Login og Annuller. Vellykket login fører brugeren til HRMS-startsiden, og annullering annullerer login.

Specifikationerne er som vist nedenfor:

# 1) Bruger-id-feltet tager mindst 6 tegn, maksimalt 10 tegn, tal (0-9), bogstaver (a-z, A-z), specialtegn (kun understregning, punktum, bindestreg tilladt), og det kan ikke efterlades tomt. Bruger-id skal begynde med et tegn eller et tal og ikke specialtegn.

#to) Adgangskodefeltet tager mindst 6 tegn, maksimalt 8 tegn, tal (0-9), bogstaver (a-z, A-Z), specialtegn (alle) og kan ikke være blanke.

Den grundlæggende tilgang til test af dette scenario kan klassificeres i to brede kategorier:

1. Positiv testning og
2. Negativ testning

Selvfølgelig har hver af disse kategorier sit underafsnit af tests, der skal udføres.

Positive tests er happy path-tests, der udføres for at sikre, at produktet opfylder - i det mindste de grundlæggende krav, der er vitale for kundernes brug.

Negative scenarier Sørg for, at produktet opfører sig ordentligt, selv når det udsættes for uventede data.

Foreslået læsning => Hvad er negativ test og hvordan man skriver negative testtilfælde

Lad mig nu prøve at strukturere testteknikkerne ved hjælp af nedenstående flowdiagram. Vi kommer ind på detaljerne i hver af disse tests.

Funktionelle testteknikker

# 1) Slutbrugerbaseret / Systemtest

Det testede system kan have mange komponenter, som når de sammenkobles opnår brugerscenariet.

I Eksempel , et kundescenarie vil omfatte opgaver som indlæsning af HRMS-applikationer, indtastning af de korrekte legitimationsoplysninger, gå til startsiden, udføre nogle handlinger og logge ud af systemet. Denne særlige strøm skal fungere uden fejl i et grundlæggende forretningsscenarie.

sql scenariobaserede spørgsmål og svar

Nogle eksempler er angivet nedenfor:

Dette er et grundlæggende eksempel på, hvordan testsager oprettes i situationer. Ovenstående format gælder også for alle nedenstående tests. Af hensyn til en stærk begrebsmæssig forankring har jeg kun lagt nogle enkle tests op og ned.

# 2) Ækvivalens test

I Ækvivalenspartitionering testdataene er adskilt i forskellige partitioner kaldet ækvivalensdataklasser. Data i hver partition skal opføre sig på samme måde, derfor skal kun én betingelse testes. Tilsvarende, hvis en tilstand i en partition ikke fungerer, så fungerer ingen af ​​de andre.

For eksempel , i ovenstående scenarie kan bruger-id-feltet maksimalt have 10 tegn, så indtastning af data> 10 skal opføre sig på samme måde.

# 3) Grænseværditest

Grænsetest indebærer datagrænser for applikationen og validerer, hvordan den opfører sig.

Derfor, hvis input leveres ud over grænseværdierne, betragtes det som negativ test. Så mindst 6 tegn for brugeren indstiller grænseværdien. Test skrevet for at have bruger-id<6 characters are boundary analysis tests.

# 4) Beslutningsbaserede tests

Beslutningsbaserede tests er centreret omkring ideologien om de mulige resultater af systemet, når en bestemt betingelse er opfyldt.

I ovenstående scenario kan følgende beslutningsbaserede tests straks udledes:

1. Hvis de forkerte legitimationsoplysninger er indtastet, skal det angive det til brugeren og indlæse login-siden igen.
2. Hvis brugeren indtaster de korrekte legitimationsoplysninger, skal det føre brugeren til næste brugergrænseflade.
3. Hvis brugeren indtaster de korrekte legitimationsoplysninger, men ønsker at annullere login, skal det ikke tage brugeren til næste brugergrænseflade og genindlæse login-siden.

# 5) Alternative flowtests

Der køres alternative statest for at validere alle mulige måder, der findes, bortset fra hovedstrømmen for at udføre en funktion.

# 6) Ad hoc-tests

Når de fleste af fejlene afdækkes gennem ovenstående teknikker, ad hoc-tests er en fantastisk måde at afdække uoverensstemmelser, der ikke er observeret tidligere. Disse udføres med den tankegang at bryde systemet og se om det reagerer yndefuldt.

For eksempel , ville en prøveeksempel være:

• En bruger er logget ind, men administratoren sletter brugerkontoen, mens han udfører nogle handlinger. Det ville være interessant at se, hvordan applikationen håndterer dette yndefuldt.

Funktionel vs ikke-funktionel test:

Ikke-funktionelle tests fokus på kvaliteten af ​​applikationen / systemet som helhed. Derfor forsøger det at udlede, hvor godt systemet fungerer i henhold til kundens krav i modsætning til den funktion, det udfører.

=> Læs den nøjagtige forskel her

Funktionel testautomatisering

Kan vi automatisere funktionelle tests?

Med Automation kan manuel indsats reduceres, tid kan spares, fejludglidning kan undgås, og effektiviteten kan øges.

Det er dog ikke muligt at automatisere hver eneste ting. Denne test kan automatiseres, men brugeren er nødt til at træne for, at testsagerne skal ske, for at automatiseringen kan udføres. Det er vigtigt at finde de rigtige testsager, der skal automatiseres sammen med et passende værktøj.

Automatisering af funktionelle sager kan have ulemper, som hvis antallet af testsager er meget mere og regresseres igen og igen (hvilket skal gøres), så kan udvikleren stå over for et problem med at foretage ændringer i koden.

Mange gange under udførelse af mangelflugtanalyse synes den fremtrædende og flerårige årsag til flugt at have en mangel på testdækning i en bestemt funktion.

Igen er der flere årsager til, at dette kan ske som mangel på miljøer, mangel på testere, for mange funktioner, der leveres, mindre tid til at dække alle testaspekterne og nogle gange simpelthen med udsigt over det.

Mens dedikerede testteam muligvis udfører detaljeret test på hver sprint eller hver testcyklus, vil der altid være mangler, og der vil altid være fejl, der kan gå glip af. Dette er et af de grundlæggende behov for at have testautomatisering på plads og derved få en markant forbedring i effektiviteten af ​​den samlede testproces og dækning af testcase.

Selvom automatiseret test aldrig kan erstatte manuelle tests, vil det være vigtigt at have en ideel blanding af de to for at have den ønskede kvalitet i softwareprojekter.

Overvejelser om automatisering:

# 1) Vælg det rigtige automatiseringsværktøj : Der er flere værktøjer til rådighed på markedet, det er en virkelig skræmmende opgave at vælge et automatiseringsværktøj! Du kan dog oprette en liste over krav, som du kan vælge, hvilket automatiseringsværktøj du vil bruge.

Nogle primære aspekter at tænke på inkluderer:

• Vælg et værktøj, der er let at bruge af alle QA-medlemmerne i teamet, hvis de ikke allerede har de nødvendige færdigheder.
• Værktøjet kan bruges i forskellige miljøer. Til Eksempel : Kan scripts oprettes på en OS-platform og køres på en anden? Har du brug for CLI-automatisering, UI-automatisering, mobilapplikationsautomatisering eller alt?
• Værktøjet skal have alle de funktioner, du har brug for. Til Eksempel : Hvis nogle testere ikke er fortrolige med et script-sprog, skal værktøjet have en optage- og afspilningsfunktion og derefter understøtte konvertering af det indspillede script til det ønskede script-sprog. Ligeledes, hvis du også har brug for værktøjet til at understøtte automatiserede buildtests, specifik rapportering og logning, skal det også være i stand til at gøre det.
• Værktøjet skal være i stand til at understøtte genanvendelighed af testsager i tilfælde af UI-ændringer.

Automatiseringsværktøjer : Der er en hel del værktøjer, der er tilgængelige til funktionel automatisering. Selen er sandsynligvis en varm favorit, men der er også nogle andre open source-værktøjer som Sahi, Watir, Robotium, AutoIt osv.

Flere testautomationsværktøjer er tilgængelige på markedet. Men at vælge det rette værktøj er meget vigtigt for organisationen. Det kan afhænge af kravet, brugervenligheden og omkostningerne spiller en vigtig rolle her.

Nedenfor er nogle af de øverste funktionelle testværktøjer:

• Selen
• QTP
• Junit
• Loadrunner
• SÆBE
• TestFuldfør

=> Tjek denne komplette liste over de mest funktionelle automatiseringsværktøjer

#to) Vælg de rigtige testsager, der skal automatiseres : Hvis du vil få det bedste ud af automatisering, er det vigtigt at være smart med den slags test, du vælger at automatisere. Hvis der er tests, der kræver nogle opsætninger og konfigurationer til og fra under testudførelse, er det bedst at efterlade ikke-automatiserede.

Derfor kan du automatisere tests, der:

• Skal køres gentagne gange.
• Kør med forskellige slags data.
• Nogle P1, P2 test tilfælde tager meget kræfter og tid.
• Test, der er udsat for fejl.
• Sæt med tests, der skal køres i forskellige miljøer, browsere osv.

# 3) Dedikeret automatiseringsteam : Dette overses sandsynligvis i de fleste organisationer, og automatisering pålægges alle medlemmer af QA-teamet.

Hvert teammedlem har varierede erfaringsniveauer, færdigheder, interesseniveauer, båndbredde til understøttelse af automatisering osv. Nogle individer er muligvis bedre dygtige til at udføre manuelle tests, mens nogle andre måske kender scripting og automatiseringsværktøjer.

I situationer som denne er det en god praksis at tage en analyse af alle medlemmerne af teamet og have nogle medlemmer dedikeret til kun at gøre automatisering.

Automatiseringsaktivitet kræver tid, kræfter, viden og et dedikeret team, der hjælper med at opnå de krævede resultater i stedet for at overbelaste alle medlemmerne af teamet med både manuel og automatiseringstest.

# 4) Datadrevne tests: Automatiserede testsager, der kræver flere datasæt, skal være godt skrevet, så de kan genbruges. Dataene kan skrives i kilder såsom tekst- eller egenskabsfil, XML-filer eller læses fra en database.

Uanset hvilken datakilde der er, gør oprettelse af velstrukturerede automatiseringsdata rammen lettere at vedligeholde og gør de eksisterende testskripter brugt til deres fulde potentiale.

# 5) UI-ændringer må ikke bryde test: De testsager, du opretter ved hjælp af det valgte værktøj, skal kunne håndtere de potentielle UI-ændringer. For eksempel brugte tidligere versioner af selen en placering til at identificere sideelementerne.

Derfor, hvis brugergrænsefladen ændrede sig, blev disse elementer ikke længere fundet på disse steder og vil igen føre til massefejl i testene.

Derfor er det vigtigt at forstå værktøjets mangler på forhånd og oprette testsagerne, så der kun kræves minimale ændringer i tilfælde af UI-ændringer.

# 6) Hyppig test: Når du har en grundlæggende automatiseringstestskovl klar, planlæg at have en hyppigere udførelse af denne skovl. Dette har en tovejs fordel: Den ene er, at du kan forbedre automatiseringsrammen og gøre den mere robust, og den anden er, at du vil fange flere fejl i processen.

Fordele

Nedenfor er de forskellige fordele ved funktionstest:

• Denne test reproducerer eller er en replika af, hvad det faktiske system er, dvs. det er en replika af, hvad produktet er i det levende miljø. Test er fokuseret på specifikationerne i henhold til kundens brug, dvs. systemspecifikationer, operativsystem, browsere osv.
• Det fungerer ikke på nogen hvis og men eller antagelser om systemets struktur.
• Denne test sikrer at levere et produkt af høj kvalitet, der opfylder kundens krav og sørger for, at kunden er tilfreds med slutresultaterne.
• Det sikrer at levere et fejlfrit produkt, der har alle de funktioner, der fungerer efter kundens krav.
• Risikobaseret test udføres for at mindske chancerne for enhver form for risiko i produktet.

Begrænsninger

Denne test udføres for at sikre, at produktet fungerer som forventet, og at hele kravet er implementeret, og at produktet er nøjagtigt som kundens krav.

Det overvejer dog ikke de andre faktorer såsom produktets ydeevne, dvs. respons, gennemløbstid osv., Som er vigtige og meget krævet for at være en del af testningen, før produktet frigives.

Ulemper

• Der er mange chancer for at udføre overflødig test.
• Logiske fejl kan gå glip af produktet.
• Denne testning er baseret på kravet, hvis det i tilfælde af, at kravet ikke er komplet eller er kompliceret eller ikke er klart, at udføre denne test i et sådant scenario bliver vanskelig og også kan være tidskrævende.

Derfor er begge disse typer af tests grundlæggende nødvendige for et kvalitetsprodukt.

Konklusion

Denne tutorial har grundigt diskuteret alt, hvad du har brug for at vide om funktionel test, lige fra det grundlæggende.

Funktionel test er en af ​​de vigtige testprocesser, da den verificerer funktionaliteten af ​​et produkt, der er det mest krævede og faktisk det vigtige aspekt af ethvert produkt eller applikation.

Om forfatteren: Sanjay Zalavadia - som VP for kundeservice for Zephyr , bringer over 15 års ledelseserfaring inden for IT og teknisk support.

Jeg håber, at nogle af de teknikker, vi har foreslået, vil være nyttige for alle læsere. Fortæl os dine tanker i kommentarerne nedenfor.

Foreslået læsning => Feature Testing Tutorial

Anbefalet læsning

• Funktionel testning mod ikke-funktionel testning
• Alpha-test og betatestning (En komplet guide)
• Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
• Forskellene mellem enhedstest, integrationstest og funktionstest
• Typer af softwaretest: Forskellige testtyper med detaljer
• Spock til integration og funktionstest med selen
• Build Verification Testing (BVT Testing) Komplet guide
• En komplet ikke-funktionel testguide til begyndere