ingen programvara kan någonsin vara helt perfekt. Men är det en licens att skapa sopor? Den saknade ingrediensen är vår motvilja att kvantifiera kvaliteten. För att öka kvaliteten är det mycket viktigt att säkerställa effektiv prestanda för programvara. Programvarutestning krävs för att säkerställa att applikationen körs utan några fel. I denna handledning för programvarutestning kommer jag att berätta allt du behöver veta om testaspekter. I fortsättningen till den tidigare bloggen om vad som är mjukvarutestning, här kommer jag att dyka djupare och täcka nedanstående ämnen.
- introduktion till programvarutestning
- grunderna för programvarutestning
- livscykel för mjukvaruutveckling
- verifierings-och Valideringsmodell
- metoder för programvarutestning
- nivåer för programvarutestning
- Dokumentationsartefakter för programvarutestning
- Bug livscykel
- utmaningar genom manuell testning
- Automation testning vs manuell testning
du kan också gå igenom inspelningen av software testing tutorial där våra Software Testing Training experter har förklarat begreppen ingående.
handledning för programvarutestning för nybörjare /Manuell & Automatiseringstestning
den här videon talar om olika typer av tester, dvs manuella test-och automatiseringstestningsmetoder.
introduktion till programvarutestning
dagens teknikvärld domineras helt av maskiner, och deras beteende styrs av programvaran som driver den. Programvarutestning ger en kostnadseffektiv lösning på alla våra bekymmer. Vad är Software Testing? Programvarutestning är en process för att utvärdera funktionaliteten hos en programvara för att hitta programfel. Den kontrollerar om den utvecklade programvaran uppfyllde de angivna kraven och identifierar eventuella fel i programvaran för att uppnå en kvalitetsprodukt. Det kör i princip ett system för att identifiera eventuella luckor, fel eller saknade krav som strider mot de faktiska kraven.
det anges också som processen att verifiera och validera en mjukvaruprodukt. Det kontrollerar om programvaruprodukten:
- uppfyller de affärs-och tekniska kraven som styrde dess design och utveckling
- fungerar enligt kravet
- kan implementeras med samma egenskaper
låt oss nu gå vidare i Handledningsartikeln för programvarutestning och få lite insikter om grunderna för programvarutestning.
grunderna för programvarutestning
först ska jag berätta vad är livscykeln för mjukvaruutveckling?
Software Development Life Cycle
(SDLC) förkortat Software Development Life Cycle är en process som används av mjukvaruindustrin för att designa, utveckla och testa Högkvalitativ programvara. Det syftar till att producera högkvalitativ programvara som uppfyller eller överträffar kundernas förväntningar, når slutförandet inom tids-och kostnadsberäkningar. Nedan diagram visar olika faser som är involverade i SDLC.
Fig: Software Development Life Cycle-Software Testing Tutorial
Kravfas
Kravsamling och analys är den viktigaste fasen i mjukvaruutvecklingens livscykel. Business analyst samlar kravet från kunden / kunden enligt kundens affärsbehov och dokumenterar kraven i affärskravspecifikationen (dokumentnamnet varierar beroende på organisationen).
Analysfas
när kraven har samlats in och analyserats är nästa steg att definiera och dokumentera produktkraven och få dem godkända av kunden. Detta registreras genom SRS-dokumentet (Software Requirement Specification). Den består av alla produktkrav som ska utformas och utvecklas under projektets livscykel
designfas
denna fas har två steg:
- HLD – Högnivådesign-det ger arkitekturen för mjukvaruprodukten som ska utvecklas och görs av arkitekter och seniorutvecklare
- LLD – Lågnivådesign – den utförs av seniorutvecklare. Här ger det dig insikter om hur varje funktion i produkten ska fungera och hur varje komponent ska fungera.
resultatet från denna fas är Högnivådokumentet och Lågnivådokumentet som fungerar som en ingång till nästa fas.
utvecklingsfas
utvecklare på alla nivåer (seniorer, juniorer, freshers) är involverade i denna fas. Detta är den fas där du börjar bygga koden för programvaran.
testfas
När programvaran är klar skickas den till testavdelningen där de testar den noggrant för olika defekter. Testning av en programvara utförs antingen manuellt eller med hjälp av automatiserade testverktyg och se till att varje komponent i programvaran fungerar bra. När programvaran är felfri går den till nästa steg, vilket är implementering.
distribution & underhållsfas
När produkten är felfri levereras/distribueras den till kunden för deras användning. Deployment görs av Deployment/Implementation engineers. När kunderna börjar använda det utvecklade systemet kommer de faktiska problemen upp och måste lösas från tid till annan. Att upptäcka och lösa dessa problem som kunden hittat kommer i underhållsfasen.
det här handlade om livscykeln för mjukvaruutveckling. Om du vill veta om olika stadier som är involverade i programvarutestprocessen kan du läsa den här bloggen om livscykel för programvarutestning. Efter att ha förstått detta, låt oss gå vidare med denna handledning för programvarutestning och se vad som är V & V-modellen.
V-modellen är nu en av de mest använda mjukvaruutvecklingsprocesserna. Införandet av V-modellen har faktiskt visat genomförandet av testning redan från kravfasen. Det kallas också som verifierings-och Valideringsmodell
Vad är verifiering och validering i programvarutestning?
verifiering: verifiering är en statisk analysteknik. Här görs testning utan att koden körs. Exempel är-recensioner, inspektion och gå igenom.
validering: validering är en process av dynamisk analys där vi utför testning genom att köra koden. Exempel inkluderar funktionella och icke-funktionella testtekniker.
I V-modellen görs utvecklings-och QA-aktiviteterna samtidigt. Här börjar testningen direkt från kravfasen. Verifierings-och valideringsaktiviteterna sker samtidigt. Låt oss titta på figuren nedan för att förstå V-modellen
i en typisk utvecklingsprocess visar vänster sida utvecklingsaktiviteterna och höger sida visar testaktiviteterna. Det borde inte vara fel om jag säger att i utvecklingsfasen utförs både verifiering och validering tillsammans med de faktiska utvecklingsaktiviteterna.
LHS
som tidigare nämnts är aktiviteter på vänster sida utvecklingsaktiviteter. Normalt känner vi, vilka tester kan vi göra i utvecklingsfasen? Men detta är kärnan i denna modell som illustrerar att testning också kan göras i alla utvecklingsfaser.
RHS
testaktiviteterna eller valideringsfasen utförs på höger sida av modellen.
När du har fått lite insikter om detta, låt oss gå vidare med denna handledning för programvarutestning och se vilka olika metoder som programvaran kan testas på.
testmetoder för programvara
det finns tre metoder för att testa programvara och de är följande:
- Black Box Testing
- White Box Testing
- Grey Box Testing
Black Box Testing: det är en metod för mjukvarutestning där den interna strukturen/ designen/ implementeringen av objektet som testas inte är känt för testaren.
White Box Testing: det är en metod för mjukvarutestning där den interna strukturen/ designen/ implementeringen av objektet som testas är känt för testaren.
grå Boxtestning: det är en testteknik som utförs med begränsad information om systemets interna funktionalitet.
Jag hoppas att du förstod nyckelpekare på olika metoder för mjukvarutestning. Låt oss nu gå vidare i den här Handledningsartikeln för programvarutestning och förstå nivåer för programvarutestning.
Programvarutestnivåer
en nivå i programvarutestning är en process där varje enhet eller komponent i en programvara/system testas. Det finns olika testnivåer som hjälper till att kontrollera beteende och prestanda för programvarutestning. Dessa testnivåer är utformade för att känna igen saknade områden och avstämning mellan utvecklingen av livscykelstater. I mjukvaruutveckling livscykelmodell, det kännetecknas faser såsom krav insamling, analys, design, kodning eller utförande, testning och distribution.
alla dessa faser går igenom processen med programvarutestningsnivåer. Det finns huvudsakligen fyra testnivåer och de är:
- enhetstestning
- Integrationstestning
- systemtestning
- Acceptanstestning
i grund och botten börjar det med Enhetstestfasen och slutar med Acceptanstestning.
i nästa avsnitt av denna handledning för programvarutestning kommer jag att dyka djupare in i nästa ämne och förklara vad som är de olika dokumentationsartefakterna i programvarutestning.
Software Testing Documentation Artifacts
dokumentera testfall kommer att underlätta för dig att uppskatta den testinsats du behöver tillsammans med test täckning och spårning och spårning krav. Några vanligt tillämpade dokumentationsartefakter associerade med mjukvarutestning är:
- testplan
- testscenario
- testfall
- Spårbarhetsmatris
Låt oss diskutera var och en av dem i korthet.
- testplan: det ger dig skissstrategin som kommer att implementeras för att testa applikationen.
- testscenario: testscenario kan betraktas som ett enda raduttalande som meddelar det område där din ansökan kommer att experimenteras. Denna artefakt behövs för att säkerställa det övergripande förfarandet testat från början till slut.
- testfall: testfall är inget annat än en uppsättning villkor eller variabler under vilka en testare kommer att avgöra om ett system som testas uppfyller kraven eller fungerar korrekt. Nedan nämnda testfall kontrolleras under testningen.
- funktionella testfall
- testfall med negativa fel
- logiska testfall
- fysiska testfall
- UI – testfall
- Spårbarhetsmatris: det är också känt som en Kravspårbarhetsmatris (RTM). Den innehåller en tabell som skissar kraven när din produkts SDLC-modell skapas. Dessa dokumentera artefakter kan tillämpas för framåt spårning som är att gå från design till kodning eller kan genomföras för bakåt spårning samt som är baksidan av framåt spårning.
detta leder oss till slutet av programvara testning dokumentation artefakter. Låt oss nu gå vidare i den här Handledningsartikeln för programvarutestning och lära oss vad som är felhantering?
Vad är Felhanteringsprocessen?
Defekthantering är en process för att upptäcka buggar och fixa dem. Eftersom buggar är en del av mjukvaruindustrin, förekommer de ständigt i processen för mjukvaruutveckling. Teammedlemmarna måste skriva stora bitar kod varje dag, och de har vanligtvis inte tid att tänka på hur man undviker buggar. Därför kräver varje mjukvaruutvecklingsprojekt en process som hjälper till att upptäcka defekterna och åtgärda dem.
Defekthanteringsprocessen utförs vid produktteststadiet. Utan att inse detta skulle det vara svårt att förstå arten av felhantering.. Vanligtvis testar utvecklarna själva sin produkt. Det finns också en typ av testning som bygger på användarengagemang. Slutanvändarna får ofta möjlighet att rapportera om de buggar de har identifierat. Ändå är detta inte det bästa sättet att testa, eftersom användarna kanske inte kan hitta alla buggar.
felhanteringsprocessen innehåller vanligtvis fyra steg.
- det första steget är steget för att upptäcka felet
- det andra steget är tillägnad formuleringen av felrapporter
- det tredje steget är att fixa felet.
- i det sista steget skapas bugglistan
Låt oss nu gå vidare i Handledningsartikeln för programvarutestning och förstå buggdetekteringsprocessen med hjälp av buggens livscykel.
Bug livscykel
en defekt livscykel är en process där en defekt går igenom olika faser under hela sin livstid. Det börjar när en defekt hittas och slutar när en defekt är stängd, efter att ha säkerställt att den inte reproduceras. En defekt livscykel är relaterad till felet som hittades under testningen.
Bug eller defekt livscykel inkluderar stegen som illustreras i nedanstående figur:
- nya: I det här steget, om en defekt loggas och publiceras för första gången, anges dess tillstånd som nytt.
- tilldelad: efter att testaren har lagt upp felet godkänner testarens ledning att felet är äkta och han tilldelar felet till en motsvarande utvecklare och utvecklarteamet. Det är staten som tilldelats.
- Open: idet här tillståndet har utvecklaren börjat analysera och arbeta med defektfixen.
- fast: eftersom utvecklaren gör nödvändiga kodändringar och verifierar ändringarna kan han/hon göra buggstatus som ’FAST’ och felet skickas till testteamet.
- Test: i detta skede gör testaren testningen av den ändrade koden som utvecklaren har gett tillbaka till honom för att kontrollera om defekten har åtgärdats eller inte.
- verifierad: här testar testaren felet igen efter att det har fixats av utvecklaren. Om det inte finns något fel i programvaran godkänner han att felet är fixat och ändrar statusen till ”verifierad”.
- öppna igen: om felet fortfarande finns även efter att felet har fixats av utvecklaren ändrar testaren statusen till ”återöppnad”. I detta tillstånd går buggen igenom livscykeln igen.
- stängd: så snart felet är fixat testas det av testaren. Om testaren känner att felet inte längre finns i programvaran ändrar han statusen för felet till ”stängt”. Det innebär att felet är fixat, testat och godkänt.
- duplicera: i buggens livscykel, om felet upprepas två gånger eller de två buggarna nämner samma koncept för felet, ändras en buggstatus till ”duplicera”.
- avvisad:om utvecklaren anser att felet inte är äkta, avvisar han felet. Då ändras tillståndet för felet till”avvisat”.
- uppskjuten:om felet ändras till uppskjutet tillstånd betyder att felet förväntas fixas i nästa utgåva.
det här handlade om Bugglivscykeln och Defekthanteringsprocessen. Låt oss nu se vad som är utmaningarna med manuell testning.
utmaningar med manuell testning
testning av en applikation manuellt av QA-testare kallas manuell testning. Här måste alla tester utföras manuellt i varje miljö, med hjälp av en annan datamängd och framgången/ felfrekvensen för varje transaktion ska registreras.
i ovanstående figur kan du se en man som manuellt verifierar transaktioner registreras. Du kan enkelt meddela de utmaningar som han står inför kan orsaka trötthet, tristess, förseningar i arbetet, misstag och fel på grund av manuell ansträngning. Detta ledde till framväxten av Automatiseringstestning.
nu, låt oss gräva i det sista ämnet av software testing tutorial artikeln och se hur Automation testning slår manuell testning.
Automatiseringstestning vs manuell testning
Automatiseringstestning övervinner manuell testning varje gång. Varför? Eftersom det är supersnabbt, kräver mycket mindre investeringar i mänskliga resurser, inte benägna att fel, ofta utförande av tester är möjligt, stöder regressionstestning och även funktionell testning.
Låt oss ta ett exempel och förstå detta. Säg att du har en inloggningssida och du måste verifiera om alla inloggningsförsök är framgångsrika, då blir det väldigt enkelt att skriva en kod som kommer att validera om alla transaktions – / inloggningsförsök är framgångsrika eller inte (automatiserad testfallsexekvering).
alla dessa tester kan konfigureras på ett sådant sätt att de testas i olika miljöer och webbläsare. Inte bara det, du kan också automatisera genereringen av resultatfilen genom att schemalägga den för en viss tid under dagen. Då kan du också automatisera genereringen av rapporter baserat på dessa resultat och vad inte.
viktig punkt här är att automation testning gör en testare jobb, en hel del enklare. Se ovanstående bild som visar en mer avslappnad miljö där samma testare arbetar. Om du vill veta mer om Automatiseringstestning och det allmänt använda Automatiseringstestverktyget Selenium, kan du hänvisa till denna Selenium-handledning.
det här handlade om hur automationstestning glittrar sig inom mjukvarutestning. Det leder oss till slutet av artikeln om handledning för programvarutestning. Jag hoppas att du tyckte att det var informativt och det har hjälpt till att öka värdet på din kunskap.
om du hittade denna” Software Testing Tutorial ” relevant, kolla in live-online Selenium Certification Training av Edureka, ett pålitligt online-lärande företag med ett nätverk av mer än 250,000 nöjda elever spridda över hela världen.