Komplett funktionell testguide med dess typer och exempel

complete functional testing guide with its types

En djupgående omfattande funktionell testhandledning med typer, tekniker och exempel:

Vad är funktionstestning?

Funktionstestning är ett slags svartlåda-test som utförs för att bekräfta att funktionerna i ett program eller system beter sig som förväntat.

Det görs för att verifiera all applikationsfunktionalitet.

LISTA över handledningarna som omfattas av denna serie:

Handledning nr 1: Vad är funktionstestning (denna handledning)
Handledning nr 2: Intervjufrågor om funktionstestning
Självstudie 3: De bästa funktionella testverktygen för automatisering
Självstudie 4: Vad är icke-funktionell testning?
Handledning nr 5: Skillnaden mellan enhet, funktionell och Integration Testning
Självstudie nr 6 : Varför funktionstestning och prestandatestning bör göras samtidigt

Verktyg:

Handledning nr 7: Funktionell testautomation med Ranorex Studio
Självstudie 8: UFT Funktionsverktyg Nya funktioner
Handledning nr 9: Funktionell automatisering över webbläsare med hjälp av Parrot QA Tool
Handledning nr 10: Jubula Open Source Tool tutorial för funktionstestning

Vad du kommer att lära dig:

• Introduktion till funktionstestning
  • Funktionella testtyper
  • Bearbeta
  • In- / utgångskriterier
    • Inträdeskriterier:
    • Utgångskriterier:
  • Steg involverade
  • Närma sig
  • Funktionella testtekniker
    • # 1) Slutanvändarbaserad / systemtest
    • # 2) Likvärdighetstester
    • # 3) Gränsvärde-tester
    • # 4) Beslutsbaserade tester
    • # 5) Alternativa flödestester
    • # 6) Ad-hoc-tester
  • Funktionell testautomation
  • Fördelar
  • Begränsningar
  • Slutsats
  • Rekommenderad läsning

Introduktion till funktionstestning

Det måste finnas något som definierar vad som är acceptabelt och vad inte.

Detta specificeras i en funktion eller kravspecifikation. Det är ett dokument som beskriver vad en användare har tillåtelse att göra så att han kan bestämma applikationens eller systemets överensstämmelse med det. Ibland kan detta också innebära att de faktiska affärssidoscenarierna valideras.

Därför kan funktionstest utföras via två populära tekniker :

• Testning baserat på krav: Innehåller alla funktionsspecifikationer som ligger till grund för alla tester som ska genomföras.
• Testning baserat på affärsscenarier: Innehåller information om hur systemet kommer att uppfattas ur ett affärsprocessperspektiv.

Testning och kvalitetssäkring är en stor del av SDLC-processen. Som testare måste vi vara medvetna om alla typer av test även om vi inte är direkt involverade i dem dagligen.

Eftersom testning är ett hav, är omfattningen av det så stort, och vi har dedikerade testare som utför olika typer av tester . Förmodligen måste vi alla vara bekanta med de flesta begreppen, men det kommer inte att skada att organisera allt här.

Funktionella testtyper

Funktionell testning har många kategorier och dessa kan användas baserat på scenariot.

De mest framträdande typerna diskuteras kort nedan:

Enhetstestning :

Enhetstestning utförs vanligtvis av en utvecklare som skriver olika kodenheter som kan vara relaterade eller inte relaterade för att uppnå en viss funktion. Hans, detta innebär vanligtvis att skriva enhetstester som skulle kalla metoderna i varje enhet och validera dem när de nödvändiga parametrarna passeras, och dess returvärde är som förväntat.

Kodtäckning är en viktig del av enhetstestning där testfallet måste finnas för att täcka nedanstående tre:

i) Linjetäckning
ii) Kodvägstäckning
iii) Metodtäckning

Sanity Testing : Testning görs för att säkerställa att alla viktiga och vitala funktioner i applikationen / systemet fungerar korrekt. Detta görs vanligtvis efter ett röktest.

Rökprovning : Testning som görs efter varje version släpps för att testa för att säkerställa byggstabilitet. Det kallas också som test för byggverifiering.

Regressionstest : Testning utförd för att säkerställa att lägga till ny kod, förbättringar, fixa buggar inte bryter mot den befintliga funktionaliteten eller orsakar instabilitet och fortfarande fungerar enligt specifikationerna.

Regressionstester behöver inte vara lika omfattande som de faktiska funktionstesterna, men de bör säkerställa enbart täckning för att intyga att funktionaliteten är stabil.

Integrationstester : När systemet är beroende av flera funktionella moduler som kan fungera perfekt, men måste arbeta sammanhängande när de klubbas ihop för att uppnå ett slut-till-slut-scenario, kallas validering av sådana scenarier Integrationstestning.

Beta / användbarhetstestning : Produkten exponeras för den faktiska kunden i en produktion som en miljö och de testar produkten. Användarens komfort härrör från detta och återkopplingen tas. Detta liknar testet för användaracceptans.

Låt oss representera detta i ett enkelt flödesschema:

Funktionellt systemtest:

Systemtestning är en testning som utförs på ett komplett system för att verifiera om det fungerar som förväntat när alla moduler eller komponenter är integrerade.

Testning från slut till slut utförs för att verifiera produktens funktionalitet. Denna testning utförs endast när systemintegrationstestningen är komplett inklusive både funktionella och icke-funktionella krav.

=> Skillnaden mellan enhet, funktion och integrationstest

Bearbeta

Denna testprocess har tre huvudsteg:

Tillvägagångssätt, tekniker och exempel

Funktionell eller beteendemässig testning genererar en utgång baserat på givna ingångar och avgör om systemet fungerar korrekt enligt specifikationerna.

Följaktligen kommer den bildliga representationen att se ut som nedan:

In- / utgångskriterier

Inträdeskriterier:

• Kravspecifikationsdokumentet är definierat och godkänt.
• Testfall har förberetts.
• Testdata har skapats.
• Miljön för testning är redo, alla verktyg som krävs är tillgängliga och redo.
• Hela eller partiella applikationer är utvecklade och enhetstestade och redo för testning.

Utgångskriterier:

• Genomförandet av alla funktionella testfall har slutförts.
• Inga kritiska eller P1, P2-buggar är öppna.
• Rapporterade fel har bekräftats.

Steg involverade

De olika stegen som är involverade i denna testning nämns nedan:

• Det allra första steget är att bestämma produktens funktionalitet som behöver testas och det inkluderar testning av huvudfunktionaliteter, felförhållanden och meddelanden, testning av användbarhet, dvs om produkten är användarvänlig eller inte, etc.
• Nästa steg är att skapa indata för funktionaliteten som ska testas enligt kravspecifikationen.
• Senare, från kravspecifikationen, bestäms produktionen för funktionaliteten som testas.
• Förberedda testfall utförs.
• Faktisk utgång, dvs. utdata efter att testfallet har utförts och förväntad utdata (bestämt utifrån kravspecifikation) jämförs för att hitta om funktionaliteten fungerar som förväntat eller inte.

Närma sig

Olika typer av scenarier kan tänkas och skapas i form av ”testfall”. Som QA-folk vet vi alla hur skelettet i ett testfall ser ut.

Det har mestadels fyra delar:

• Testöversikt
• Förutsättningar
• Teststeg och
• Förväntade resultat.

Att försöka författa alla typer av test är inte bara omöjligt utan också tidskrävande och dyrt.

Vanligtvis skulle vi vilja avslöja maximala buggar utan att undkomma med befintliga tester. Därför måste QA använda optimeringstekniker och strategisera hur de skulle närma sig testningen.

Låt oss förklara detta med en exempel.

Exempel på användningsfall för funktionstestning:

Ta en online HRMS-portal där den anställde loggar in med sitt användarkonto och lösenord. På inloggningssidan finns två textfält för användarnamnet och lösenordet och två knappar: Logga in och Avbryt. Framgångsrik inloggning tar användaren till HRMS hemsida och avbryt kommer att avbryta inloggningen.

Specifikationerna är som visas nedan:

# 1) Användar-id-fältet tar minst 6 tecken, högst 10 tecken, siffror (0-9), bokstäver (a-z, A-z), specialtecken (endast understrykning, period, bindestreck tillåten) och det kan inte lämnas tomt. Användar-id måste börja med ett tecken eller ett nummer och inte specialtecken.

#två) Lösenordsfältet tar minst 6 tecken, högst 8 tecken, siffror (0-9), bokstäver (a-z, A-Z), specialtecken (alla) och kan inte vara tomma.

Den grundläggande metoden för att testa detta scenario kan klassificeras i två breda kategorier:

1. Positiv testning och
2. Negativ testning

Naturligtvis har var och en av dessa kategorier sitt underavsnitt av tester som kommer att genomföras.

Positiva tester är lyckliga vägtester som görs för att säkerställa att produkten uppfyller - åtminstone de grundläggande kraven som är viktiga för kundanvändningen.

Negativa scenarier se till att produkten beter sig ordentligt även när den utsätts för oväntade data.

Föreslagen läsning => Vad är negativ testning och hur man skriver negativa testfall

Låt mig nu försöka strukturera testteknikerna med hjälp av ett flödesschema nedan. Vi kommer att ta reda på detaljerna i vart och ett av dessa tester.

Funktionella testtekniker

# 1) Slutanvändarbaserad / systemtest

Systemet som testas kan ha många komponenter som när de kopplas ihop uppnår användarscenariot.

I Exempel , skulle ett kundscenario inkludera uppgifter som att ladda HRMS-applikationer, ange rätt referenser, gå till hemsidan, utföra några åtgärder och logga ut från systemet. Detta specifika flöde måste fungera utan några fel för ett grundläggande affärsscenario.

konvertera youtube till mp3 längre än 20 minuter

Några prover ges nedan:

Detta är ett grundläggande exempel på hur testfall görs för situationer. Formatet ovan gäller också för alla nedanstående tester. För en stark konceptuell jordning har jag bara lagt in några enkla tester ovan och under.

# 2) Likvärdighetstester

I Partitionering av ekvivalens , är testdata separerade i olika partitioner som kallas ekvivalensdataklasser. Data i varje partition måste fungera på samma sätt, därför behöver bara ett villkor testas. På samma sätt, om ett villkor i en partition inte fungerar, fungerar ingen av de andra.

Till exempel , i ovanstående scenario kan användar-id-fältet innehålla högst 10 tecken, så att mata in data> 10 bör uppträda på samma sätt.

# 3) Gränsvärde-tester

Gränstester antyder datagränser för applikationen och validerar hur den beter sig.

Därför, om ingångarna levereras bortom gränsvärdena, anses det vara negativ testning. Så minsta 6 tecken för användaren ställer in gränsgränsen. Tester skrivna för att ha användar-id<6 characters are boundary analysis tests.

# 4) Beslutsbaserade tester

Beslutsbaserade tester är centrerade kring ideologin om systemets möjliga resultat när ett visst villkor är uppfyllt.

I ovanstående scenario kan följande beslutsbaserade tester omedelbart härledas:

1. Om fel inloggningsuppgifter matas in bör det ange detta för användaren och ladda inloggningssidan igen.
2. Om användaren anger rätt autentiseringsuppgifter ska den ta användaren till nästa användargränssnitt.
3. Om användaren anger rätt autentiseringsuppgifter men vill avbryta inloggningen ska det inte ta användaren till nästa användargränssnitt och ladda inloggningssidan igen.

# 5) Alternativa flödestester

Alternativa banprov körs för att validera alla möjliga sätt som finns, förutom huvudflödet för att utföra en funktion.

# 6) Ad-hoc-tester

När de flesta av buggarna upptäcks genom ovanstående tekniker, ad hoc-tester är ett utmärkt sätt att upptäcka eventuella avvikelser som inte observerats tidigare. Dessa utförs med tanke på att bryta systemet och se om det svarar graciöst.

Till exempel skulle ett provfall vara:

• En användare är inloggad, men administratören tar bort användarkontot medan han utför vissa åtgärder. Det vore intressant att se hur applikationen hanterar detta elegant.

Funktionell vs icke-funktionell testning:

Icke-funktionella tester fokusera på kvaliteten på applikationen / systemet som helhet. Därför försöker den härleda hur bra systemet fungerar enligt kundens krav, i motsats till den funktion det utför.

=> Läs den exakta skillnaden här

Funktionell testautomation

Kan vi automatisera funktionella tester?

Med Automation kan manuella ansträngningar minskas, tid kan sparas, felglidning kan undvikas och effektivitet kan ökas.

Det är dock inte möjligt att automatisera allt. Denna testning kan automatiseras, men användaren måste träna för att testfall för att automatiseringen ska kunna göras. Det är viktigt att hitta rätt testfall som ska automatiseras tillsammans med ett lämpligt verktyg.

Automatisering av funktionella ärenden kan ha nackdelar som om antalet testfall är mycket mer och minskas om och om igen (vilket måste göras) då kan utvecklaren möta ett problem med att göra ändringar i koden.

Många gånger under analysen av defektflykt verkar den framträdande och fleråriga orsaken till flykt sakna testtäckning i en viss funktion.

Återigen finns det flera orsaker till att detta händer som brist på miljöer, brist på testare, för många funktioner som levereras, mindre tid för att täcka alla testaspekter och ibland bara med utsikt över det.

Medan dedikerade testteam kan göra detaljerade tester på varje sprint eller varje testcykel, kommer defekter alltid att finnas och det kommer alltid att finnas defekter som kan missas. Detta är ett av de grundläggande behoven för att ha testautomatisering på plats och därigenom få en markant förbättring av effektiviteten i den övergripande testprocessen och testfallets täckning.

Även om automatiserad testning aldrig kan ersätta manuella tester, är det viktigt att ha en perfekt blandning av de två för att ha önskad kvalitet i programvaruprojekt.

Automationsöverväganden:

# 1) Välj rätt automatiseringsverktyg : Det finns flera verktyg tillgängliga på marknaden, att välja ett automatiseringsverktyg är en verklig skrämmande uppgift! Du kan dock göra en lista över krav baserat på vilka du kan välja vilket automatiseringsverktyg du vill använda.

Några primära aspekter att tänka på är:

• Välj ett verktyg som är lätt att använda för alla QA-medlemmar i teamet om de inte redan har de nödvändiga färdigheterna.
• Verktyget kan användas i olika miljöer. För Exempel : Kan skript skapas på en OS-plattform och köras på en annan? Behöver du CLI-automatisering, UI-automatisering, mobilapplikationsautomation eller allt?
• Verktyget måste ha alla funktioner du behöver. För Exempel : Om vissa testare inte är väl insatta i ett skriptspråk, bör verktyget ha en inspelnings- och uppspelningsfunktion och sedan stödja konvertering av det inspelade skriptet till önskat skriptspråk. På samma sätt, om du också behöver verktyget för att stödja automatiserade byggtester, specifik rapportering och loggning, måste det också kunna göra det.
• Verktyget måste kunna stödja återanvändbarheten i testfall vid UI-ändringar.

Automationsverktyg : Det finns en hel del verktyg som finns tillgängliga för funktionell automatisering. Selen är förmodligen en het favorit, men det finns också andra öppen källkodsverktyg som Sahi, Watir, Robotium, AutoIt, etc.

Flera testautomationsverktyg finns på marknaden. Men att välja lämpligt verktyg är mycket viktigt för organisationen. Det kan bero på kravet, användarvänligheten och kostnaden spelar en viktig roll här.

Nedan följer några av de bästa funktionella testverktygen:

• Selen
• QTP
• Junit
• Loadrunner
• TVÅL
• TestComplete

=> Kontrollera den här kompletta listan över de bästa funktionella automatiseringsverktygen

#två) Välj rätt testfall för att automatisera : Om du vill få ut det mesta av automatiseringen är det viktigt att vara smart om vilken typ av tester du väljer för att automatisera. Om det finns tester som kräver vissa inställningar och konfigurationer på och av under testkörning, är de bäst lämnade icke-automatiserade.

Därför kan du automatisera tester som:

• Behöver köras upprepade gånger.
• Kör med olika typer av data.
• Vissa P1, P2 testfall tar mycket ansträngning och tid.
• Tester som är felbenägna.
• Uppsättning tester som måste köras i olika miljöer, webbläsare etc.

# 3) Dedikerad automatiseringsteam : Detta förbises förmodligen i de flesta organisationer och automatisering åläggs alla medlemmar i QA-teamet.

Varje lagmedlem har olika erfarenhetsnivåer, färdighetsuppsättningar, intressenivåer, bandbredd för att stödja automatisering etc. Vissa individer är möjligen bättre skickliga på att utföra manuella tester, medan andra kanske kan skript- och automatiseringsverktyg.

I sådana situationer är det bra att göra en analys av alla medlemmar i teamet och ha några medlemmar dedikerade till att bara göra automatisering.

Automationsaktivitet kräver tid, ansträngning, kunskap och ett dedikerat team som hjälper till att uppnå de önskade resultaten istället för att överbelasta alla medlemmar i teamet med både manuell och automatiseringstestning.

# 4) Datadrivna tester: Automatiserade testfall som kräver flera datauppsättningar bör vara välskrivna så att de kan återanvändas. Uppgifterna kan skrivas i källor som text- eller egenskapsfil, XML-filer eller läsas från en databas.

Oavsett vad datakällan är, skapar en välstrukturerad automatiseringsdata ramarna lättare att underhålla och gör att de befintliga testskripten används till sin fulla potential.

# 5) UI-ändringar får inte bryta testerna: De testfall som du skapar med det valda verktyget måste kunna hantera de potentiella användargränssnittsändringarna. Till exempel använde tidigare versioner av selen en plats för att identifiera sidelementen.

Följaktligen, om användargränssnittet ändrades, hittades dessa element inte längre på dessa platser och kommer i sin tur att leda till massfel av tester.

Därför är det viktigt att förstå bristerna i verktyget i förväg och författa testfallet så att det bara krävs minimala ändringar vid UI-ändringar.

# 6) Frekvent testning: När du har en grundläggande automatiseringsprovskopa redo, planera att ha en mer frekvent körning av denna skopa. Detta har en tvåvägsfördel: En är att du kan förbättra automatiseringsramen och göra den mer robust och den andra är att du kommer att fånga fler buggar i processen.

Fördelar

Nedan listas de olika fördelarna med funktionstestning:

• Denna testning reproducerar eller är en kopia av vad det faktiska systemet är, dvs. det är en kopia av vad produkten är i den levande miljön. Testningen fokuseras på specifikationerna enligt kundanvändningen, dvs. systemspecifikationer, operativsystem, webbläsare etc.
• Det fungerar inte på några om och men eller några antaganden om systemets struktur.
• Denna testning säkerställer att leverera en högkvalitativ produkt som uppfyller kundens krav och ser till att kunden är nöjd med slutresultaten.
• Det säkerställer att leverera en buggfri produkt som har alla funktioner som fungerar enligt kundkravet.
• Riskbaserad testning görs för att minska risken för någon risk i produkten.

Begränsningar

Denna testning görs för att säkerställa att produkten fungerar som förväntat och att hela kravet implementeras och att produkten är exakt enligt kundens krav.

Det tar dock inte hänsyn till de andra faktorerna som produktens prestanda, dvs respons, genomströmningstid etc., som är viktiga och mycket krävs för att vara en del av testningen innan produkten släpps.

Nackdelar

• Det finns många chanser att utföra överflödig testning.
• Logiska fel kan missas i produkten.
• Denna testning baseras på kravet, om det i fall fallet inte är fullständigt eller är komplicerat eller inte är klart, blir det svårt att utföra denna testning i ett sådant scenario och det kan också vara tidskrävande.

Därför behövs i princip båda dessa typer av tester för en kvalitetsprodukt.

Slutsats

Denna handledning har utförligt diskuterat allt du behöver veta om funktionstester, direkt från grunderna.

Funktionstestning är en av de viktigaste testprocesserna eftersom den verifierar funktionaliteten hos en produkt som är den mest krävda och verkligen den viktiga aspekten av en produkt eller applikation.

Om författaren: Sanjay Zalavadia - som VP för kundtjänst för Zephyr , ger över 15 års erfarenhet av ledarskap inom IT och teknisk support.

Jag hoppas att några av de tekniker som vi har föreslagit kommer att vara till nytta för alla läsare. Låt oss veta dina tankar i kommentarerna nedan.

Föreslagen läsning => Feature Testing Tutorial

Rekommenderad läsning

• Funktionell testning mot icke-funktionell testning
• Alfatestning och betatestning (En komplett guide)
• Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
• Skillnaderna mellan enhetstestning, integrationstestning och funktionstestning
• Typer av programvarutestning: Olika testtyper med detaljer
• Spock för integration och funktionstestning med selen
• Byggverifieringstestning (BVT-testning) Komplett guide
• En komplett icke-funktionell testguide för nybörjare