Vad är automatiseringstestning (ultimat guide för att starta testautomatisering)

En komplett guide för att starta automatiseringstestning i ditt projekt:

Vad är automationstestning?

Automationstestning är en programvarutestningsteknik för att testa och jämföra det faktiska resultatet med det förväntade resultatet. Detta kan uppnås genom att skriva testskript eller använda något verktyg för automatiseringstestning. Testautomatisering används för att automatisera repetitiva uppgifter och andra testuppgifter som är svåra att utföra manuellt.

Vill du starta automatiseringstestning i ditt projekt men kämpar du med de mest grundläggande stegen som nämns nedan:

• Hur introducerar du automatisering i ditt projekt?
• Hur väljer du det bästa och rätta automationsverktyget?
• Hur man utvecklar skript på ett effektivt sätt?
• Hur man utför och underhåller testskript?
• Och slutligen vilka är de bästa metoderna som du måste följa för att lyckas med automatiseringstester?

I dag har vi planerat att berika dina kunskaper med en serie handledningar om ”Att komma igång med automatiseringstester”. Denna serie handledningar om automatisering kommer att besvara alla ovanstående frågor steg för steg med enkla exempel.

Låt oss ta en titt på serien av handledningar om att börja automatisera ditt projekt!!!

Automation från början till slut:

Tutorial #1: Bästa guiden för att börja automatisera ditt projekt
Tutorial #2: Typer av automatiserade tester och några missuppfattningar
Tutorial #3: 10 steg för att introducera automatisering i ditt projekt
Tutorial #4: A till Z-guide för att välja det bästa automatiseringsverktyget
Tutorial #5: Skriptutveckling och ramar för automatisering
Tutorial #6: Genomförande och rapportering av automatisering
Tutorial #7: Best Practices and Strategies of Test Automation

Automation Tips:

Tutorial #8: 10 tips du bör läsa innan du automatiserar ditt testarbete
Tutorial #9: Hur skiljer sig testplanering åt mellan manuella och automatiserade projekt
Tutorial #10: När ska du välja automatisering?
Tutorial #11: Automation Test Challenges
Tutorial #12: Guide to Implement Proof of Concept (POC) in Automation
Tutorial #13: How to Select Correct Test Cases for Automation
Tutorial #14: How to Translate Manual Test Cases into Automation Scripts

Automation Career:

Tutorial #15: Tips to Become a Better Automation Tester
Tutorial #16: Test Automation – Is it a Specialized Career? Kan vanliga testare göra automatisering också?

Populära automationsverktyg:

Tutorial #17: Selenium Tutorials 31+ Best Free Selenium Training Tutorials
Tutorial #18: QTP-utbildningar
Utbildning #19: SoapUI Web Services Testing Tool
Tutorial #20: HP LoadRunner för prestandatestning

Automation Frameworks:

Tutorial #21: Varför behöver vi ramverk för automatisering
Tutorial #22: De mest populära ramverken för automatisering

Automation i Agile:

Tutorial #23: Hur man implementerar effektiv automatisering i den agila världen

Andra automatiseringsverktyg:

Tutorial #24: De bästa verktygen för automatiseringstestning
Tutorial #25: Sikuli GUI Automation Tool
Tutorial #26: PowerShell: Desktop Application UI Automation With PowerShell
Tutorial #27: Automatisering av skrivbordstillämpningars användargränssnitt med PowerShell
Tutorial #27: Katalon Automation Recorder (Selenium IDE Alternative)
Tutorial #28: Geb Tool: Browser Automation Using Geb Tool
Tutorial #29: AutoIt: Hur man hanterar Windows Pop-up med AutoIt
Tutorial #30: Cucumber: Automation Using Cucumber Tool and Selenium
Tutorial #31: Protractor Testing Tool for End-to-end Testing of AngularJS Applications

Mobile Automation Testing:

Tutorial #32: Appium Studio Hands-on Tutorial
Tutorial #33: Appium Tutorial for Beginners
Tutorial #34: Selendroid Tutorial: Android Mobile Automation Framework
Tutorial #35: Ranorex Tutorial:

Domänspecifika automationsexempel:

Tutorial #36: Automatisering av JAVA/J2EE-applikationer

Intervjuförberedelser för automationsjobb:

Tutorial #37: Intervjufrågor om automatiseringstestning
Tutorial #38: Intervjufrågor om Selenium

Låt oss utforska den första handledningen i serien ”Den ultimata guiden till automatiseringstestning”!!

Vad är automationstestning?

Om en programvara kan göra vad som helst, varför kan inte en programvara testa en programvara?

Låter detta uttalande logiskt för dig?

Om ja, så gratulerar, du tänker nu på Testautomatisering, vilket är den centrala punkt som vi kommer att diskutera i den här serien av informativa handledningar.

Föreställ dig själv n den första dagen på ditt jobb som SQA. Du presenteras för en applikation som ska testas. Det är en ERP-applikation som innehåller 100-tals formulär och tusentals rapporter. Du börjar din explorativa testning genom att öppna ett formulär som innehåller cirka 50 olika fält.

Du försöker skriva in slumpmässiga data i detta formulär, vilket tog cirka 20 minuter. Sedan trycker du på skicka. Wolla!!! Ett felmeddelande visas som ser ut som ett obehandlat undantag. Du blir väldigt glad. Du noterar stolt stegen och rapporterar felet i ditt felhanteringssystem. Du känner dig verkligen självsäker och energisk. Du fortsätter testningen tills dagen är slut och hittar fler fel. ”Fantastisk första dag”, tänkte du.

Nu kommer nästa dag, utvecklaren har åtgärdat problemet och släpper en ny version av byggnaden. Du testar samma formulär med samma steg och upptäcker att felet är åtgärdat. Du markerar det som åtgärdat. Stor insats. Du har bidragit till produktens kvalitet genom att identifiera felet och eftersom felet är åtgärdat förbättras kvaliteten.

Nu kommer den tredje dagen, en utvecklare har återigen släppt en nyare version. Nu måste du återigen testa formuläret för att se till att inga regressionsproblem uppstår. Samma 20 minuter. Nu känner du dig lite uttråkad.

Föreställ dig nu en månad från och med nu, nyare versioner släpps hela tiden och i varje version måste du testa det här långa formuläret plus 100 andra formulär som liknar det här, bara för att försäkra dig om att det inte finns något regressionsproblem.

Nu känner du dig arg. Du känner dig trött. Du börjar hoppa över steg. Du fyller bara i ungefär 50 % av de totala fälten. Din noggrannhet är inte densamma, din energi är inte densamma och dina steg är definitivt inte desamma.

En dag rapporterar kunden samma fel i samma formulär. Du känner dig patetisk. Du känner dig osäker nu. Du tror att du inte är tillräckligt kompetent. Cheferna ifrågasätter din förmåga.

Jag har en nyhet till dig; detta är historien för 90 procent av de manuella testarna där ute. Du är inte annorlunda.

Regressionsfrågor är de mest smärtsamma frågorna. Vi är människor. Och vi kan inte göra samma sak med samma energi, hastighet och noggrannhet varje dag. Det är vad maskiner gör. Detta är vad automatisering krävs för, för att upprepa samma steg med samma hastighet, noggrannhet och energi som de upprepades första gången.

Jag hoppas att du förstår vad jag menar!!!

När en sådan situation uppstår bör du automatisera ditt testfall. Testautomatisering är din vän. Det hjälper dig att fokusera på ny funktionalitet samtidigt som du tar hand om regressionerna. Med automatisering kan du fylla i formuläret på mindre än tre minuter.

Skriptet fyller i alla fält och berättar resultatet tillsammans med skärmdumpar. Vid fel kan det peka ut platsen där testfallet misslyckades, vilket hjälper dig att enkelt reproducera det.

Automation – en kostnadseffektiv metod för regressionstestning

Automationskostnaderna är verkligen högre initialt. Det inkluderar kostnaden för verktyget, därefter kostnaden för resursen för automatiseringstestning och hans/hennes utbildning.

Men när skripten är färdiga kan de exekveras hundratals gånger upprepade gånger med samma noggrannhet och ganska snabbt. Detta kommer att spara många timmar av manuell testning. Så kostnaden minskar gradvis och i slutändan blir det en kostnadseffektiv metod för regressionstestning.

Scenarier som kräver automatisering

Ovanstående scenario är inte det enda fallet när du behöver automatiseringstestning. Det finns flera situationer, som inte kan testas manuellt.

Till exempel,

1. Vid jämförelse av två bilder pixel för pixel.
2. Vid jämförelse av två kalkylblad som innehåller tusentals rader och kolumner.
3. Testning av ett program under belastning av 100 000 användare.
4. Bänkmärkning av prestanda.
6. Testning av programmet på olika webbläsare och på olika operativsystem parallellt.

Dessa situationer kräver och bör testas med hjälp av verktyg.

Så, när ska man automatisera?

Detta är en era av agil metodik i SDLC, där utveckling och testning kommer att gå nästan parallellt och det är mycket svårt att bestämma när man ska automatisera.

Konsultera följande situationer innan du ger dig in i automatiseringen

• Produkten kan vara i sina primitiva stadier, när produkten inte ens har ett användargränssnitt, i dessa stadier måste vi ha en tydlig tanke om vad vi vill automatisera. Följande punkter bör man komma ihåg.
  • Testerna bör inte vara föråldrade.
  • I takt med att produkten utvecklas bör det vara lätt att plocka fram skript och lägga till.
  • Det är mycket viktigt att inte låta sig ryckas med och se till att skripten är lätta att felsöka.
• Försök inte automatisering av användargränssnittet i de allra första skedena eftersom användargränssnittet är utsatt för frekventa ändringar, vilket leder till att skript misslyckas. I så stor utsträckning som möjligt väljer man att automatisera på API-nivå/inte på UI-nivå tills produkten stabiliseras. API-automation är lätt att åtgärda och felsöka.

Hur man bestämmer sig för de bästa automationsfallen:

Automation är en integrerad del av en testcykel och det är mycket viktigt att bestämma sig för vad vi vill uppnå med automatisering innan vi bestämmer oss för att automatisera.

Fördelarna som automatisering tycks ge är mycket attraktiva, men samtidigt kan en dåligt organiserad automationssvit förstöra hela spelet. Testare kan sluta med att felsöka och fixa skripten för det mesta, vilket resulterar i förlust av testtid.

Den här serien förklarar hur en automatiseringsföljd kan göras tillräckligt effektiv för att plocka upp rätt testfall och ge rätt resultat med de automatiseringsskripten som vi har.

Och jag har också täckt svaren på frågor som När man ska automatisera, Vad man ska automatisera, Vad man inte ska automatisera och Hur man strategiserar automatiseringen.

Rätta tester för automatisering

Det bästa sättet att ta itu med det här problemet är att snabbt komma fram till en ”automatiseringsstrategi” som passar vår produkt.

Idén är att gruppera testfallen så att varje grupp kommer att ge oss en annan typ av resultat. Illustrationen nedan visar hur vi kan gruppera våra liknande testfall beroende på vilken produkt/lösning vi testar.

Låt oss nu dyka djupt och förstå vad varje grupp kan hjälpa oss att uppnå:

#1) Gör en testföljd med alla grundläggande funktionaliteter Positiva tester. Denna svit ska vara automatiserad, och när denna svit körs mot någon build visas resultaten omedelbart. Varje skript som misslyckas i denna svit leder till S1- eller S2-defekt, och det specifika bygget kan diskvalificeras. Så vi har sparat mycket tid här.

Som ett ytterligare steg kan vi lägga till den här automatiserade testsviten som en del av BVT (Build verification tests) och kontrollera QA-automatiseringsskript i produktbyggnadsprocessen. Så när byggnaden är klar kan testarna kontrollera resultaten av automatiseringstestet och besluta om byggnaden är lämplig eller inte för installation och vidare testning.

Detta är ett tydligt sätt att uppnå målen för automatisering som är:

• Minskad testningsinsats.
• Finns fel i tidigare skeden.

#2) Därefter har vi en grupp End to End-tester.

Under stora lösningar håller testning av en end to end-funktionalitet nyckeln, särskilt under de kritiska skedena av projektet. Vi bör ha några automatiseringsskript som berör testerna av end to end-lösningen också. När denna svit körs bör resultatet visa om produkten som helhet fungerar som förväntat eller inte.

Automationstestsviten bör indikeras om någon av integrationsdelarna är trasig. Denna svit behöver inte täcka varje liten funktion i lösningen, men den bör täcka hur produkten som helhet fungerar. Närhelst vi har en alfa- eller beta-version eller någon annan mellanliggande version är sådana skript praktiska och ger kunden en viss grad av förtroende.

För att förstå bättre antar vi att vi testar en online shoppingportal, som en del av testerna från början till slut bör vi endast täcka de viktigaste stegen.

Som nedan:

• Användarinloggning.
• Bläddra och välj artiklar.
• Betalningsalternativ – detta täcker testerna på framsidan.
• Backend orderhantering (innefattar kommunikation med flera integrerade partners, kontroll av lager, e-post till användaren etc.) – detta kommer att hjälpa till att testa integrationen av enskilda delar och även kärnan i produkten.

Så när ett sådant skript körs ger det ett förtroende för att lösningen som helhet fungerar bra.!

#3) Den tredje uppsättningen är de funktions-/funktionsbaserade testerna.

Till exempel kan vi ha funktionaliteten att bläddra och välja en fil, så när vi automatiserar detta kan vi automatisera fall för att inkludera valet av olika typer av filer, storlekar på filer etc., så att funktionstestning görs. När det finns några ändringar/tillägg till denna funktionalitet kan denna svit fungera som en regressionssvit.

#4) Nästa på listan skulle vara UI-baserade tester. Vi kan ha en annan svit som testar rent UI-baserade funktioner som paginering, teckenbegränsning i textrutor, kalenderknapp, drop-downs, grafer, bilder och många sådana UI-centrerade funktioner. Om dessa skript misslyckas är det vanligtvis inte särskilt kritiskt om inte användargränssnittet är helt nere eller om vissa sidor inte visas som förväntat!

#5) Vi kan ha ännu en uppsättning tester som är enkla men mycket arbetsamma att utföra manuellt. Tråkiga men enkla tester är de idealiska automatiseringskandidaterna, till exempel att skriva in uppgifter om 1000 kunder i databasen har en enkel funktionalitet men extremt tråkigt att utföra manuellt, sådana tester bör automatiseras. Om inte slutar de oftast med att ignoreras och inte testas.

Vad ska inte automatiseras?

Nedan följer några tester som inte bör automatiseras.

#1) Negativa tester/Failover-tester

Vi bör inte försöka automatisera negativa tester eller failover-tester, eftersom testarna för dessa tester måste tänka analytiskt och negativa tester är inte riktigt okomplicerade för att ge ett godkänt eller misslyckat resultat som kan hjälpa oss.

Negativa tester kommer att kräva en hel del manuellt ingripande för att simulera ett verkligt katastrofåterställningsscenario. Bara för att exemplifiera så testar vi funktioner som webbtjänsters tillförlitlighet – för att generalisera det här skulle huvudsyftet med sådana tester vara att orsaka avsiktliga fel och se hur väl produkten klarar av att vara tillförlitlig.

Att simulera ovanstående fel är inte okomplicerat, det kan innebära att injicera några stubs eller att använda några verktyg däremellan, och automatisering är inte det bästa sättet att göra det här.

#2) Ad hoc-tester

Dessa tester kanske inte riktigt är relevanta för en produkt vid alla tillfällen och detta kan till och med vara något som testaren kan tänka på i det skedet av projektets initiering, och även ansträngningen för att automatisera ett ad hoc-test måste valideras mot kriticiteten av funktionen som testerna berör.

En testare som testar en funktion som handlar om komprimering/kryptering av data kan t.ex. ha gjort intensiva ad hoc-tester med olika typer av data, filtyper, filstorlekar, korrupta data, en kombination av data, med olika algoritmer, på flera plattformar osv.

När vi planerar för automatisering kanske vi vill prioritera och inte göra en uttömmande automatisering av alla ad hoc-tester för enbart den funktionen, och få lite tid över för att automatisera de andra nyckelfunktionerna.

#3) Tester med massiv förinställning

Det finns tester som kräver några enorma förutsättningar.

Till exempel kan vi ha en produkt som integreras med en programvara från tredje part för vissa av funktionerna, eftersom produkten integreras med något meddelandekösystem som kräver installation på ett system, inställning av köer, skapande av köer osv.

Den tredjepartsprogramvaran kan vara vad som helst och inställningen kan vara komplex till sin natur och om sådana skript är automatiserade kommer dessa för alltid att vara beroende av funktionen/inställningen av den tredjepartsprogramvaran.

Förutsättningar inkluderar:

För tillfället kan saker och ting se enkla och rena ut, eftersom båda sidornas inställningar är gjorda och allt är bra. Vi har sett många gånger att när ett projekt går in i underhållsfasen flyttas projektet till ett annat team, och de slutar med att felsöka sådana skript där det faktiska testet är mycket enkelt, men skriptet misslyckas på grund av ett problem med en programvara från tredje part.

Ovanstående är bara ett exempel, i allmänhet, håll ett öga på tester som har mödosamma förinställningar för ett enkelt test som följer.

Enkel exempel på testautomatisering

När du testar en mjukvara (på webben eller skrivbordet) använder du normalt en mus och ett tangentbord för att utföra dina steg. Automatiseringsverktyget efterliknar samma steg genom att använda skript eller ett programmeringsspråk.

Till exempel, om du testar en miniräknare och testfallet är att du måste addera två tal och se resultatet. The script will perform the same steps by making use of your mouse and keyboard.

The example is shown below.

Manual Test Case Steps:

1. Launch Calculator
2. Press 2
3. Press +
4. Press 3
5. Press =
6. The screen should display 5.
7. Close Calculator.

Automation Script:

//the example is written in MS Coded UI using c# language.public void TestCalculator(){//launch the applicationvar app = ApplicationUnderTest.Launch("C:\\Windows\\System32\\calc.exe");//do all the operationsMouse.Click(button2);Mouse.Click(buttonAdd);Mouse.Click(button3);Mouse.Click(buttonEqual);//evaluate the resultsAssert.AreEqual("5", txtResult.DisplayText,”Calculator is not showing 5);//close the applicationapp.Close();}

The above script is just a duplication of your manual steps. The script is easy to create and easy to understand as well.

What are Assertions?

The second last line of the script needs some more explanation.

Assert.AreEqual(”5”, txtResult.DisplayText,”Calculator is not showing 5);

In every test case, we have some expected or predicted result at the end. In the above script, we have an expectation that ”5” should be shown on the screen. The actual outcome is the result that is displayed on the screen. I varje testfall jämför vi det förväntade resultatet med det faktiska resultatet.

Det samma gäller även för automatiseringstestning. Den enda skillnaden här är att när vi gör den jämförelsen i testautomatisering kallas den för något annat i varje verktyg.

Vissa verktyg kallar den för ”assertion”, vissa kallar den för ”checkpoint” och vissa kallar den för ”validering”. Men i grund och botten är detta bara en jämförelse. Om jämförelsen misslyckas, t.ex. om en skärm visar 15 i stället för 5, misslyckas assertion/checkpoint/validering och testfallet markeras som misslyckat.

När ett testfall misslyckas på grund av en assertion betyder det att du har upptäckt en bugg genom testautomatisering. Du måste rapportera det till ditt felhanteringssystem precis som du normalt gör vid manuell testning.

I ovanstående skript har vi utfört en assertion i den näst sista raden. 5 är det förväntade resultatet, txtResult. DisplayText är det faktiska resultatet och om de inte är lika kommer vi att få ett meddelande om att ”Calculator is not showing 5”.

Slutsats

Ofta stöter testare på projektets deadlines och mandat att automatisera alla fall för att förbättra testuppskattningarna.

Det finns några vanliga ”felaktiga” uppfattningar om automatisering.

De är:

• Vi kan automatisera alla testfall.
• Automatisering av tester kommer att minska testtiden enormt.
• Ingen buggar introduceras om automatiseringsskript körs smidigt.

Vi bör vara tydliga med att automatisering kan minska testtiden endast för vissa typer av tester. Att automatisera alla tester utan någon plan eller sekvens kommer att leda till massiva skript som är tunga att underhålla, misslyckas ofta och kräver en hel del manuellt ingripande också. Dessutom kan automatiseringsskript i produkter som utvecklas kontinuerligt bli föråldrade och kräva vissa ständiga kontroller.

Gruppering och automatisering av rätt kandidater kommer att spara en hel del tid och ge alla fördelar med automatisering.

Denna utmärkta handledning kan sammanfattas i bara 7 punkter.

Automatiseringstestning:

• Är den testning som görs programmatiskt.
• Användning av verktyget för att styra utförandet av testerna.
• Genomför förväntat utfall med det faktiska utfallet (Assertions).
• Kan automatisera vissa repetitiva men nödvändiga uppgifter (t.ex. dina regressionstestfall).
• Kan automatisera vissa uppgifter som är svåra att utföra manuellt (t.ex.g. Scenarier för belastningstestning).
• Skripten kan köras snabbt och upprepade gånger.
• Är kostnadseffektivt i det långa loppet.

Här förklaras automatisering i enkla termer, men det betyder inte att det alltid är enkelt att göra. Det finns utmaningar, risker och många andra hinder som är involverade i det. Det finns många sätt genom vilka testautomatisering kan gå fel, men om allt går bra så är fördelarna med testautomatisering verkligen enorma.

Kommande i den här serien:

I våra kommande handledningar kommer vi att diskutera flera aspekter relaterade till automatisering.

Dessa inkluderar:

1. Typer av automatiserade tester och några missuppfattningar.
2. Hur du introducerar automatisering i din organisation och hur du undviker vanliga fallgropar när du gör testautomatisering.
3. Verktygsvalsprocessen och jämförelse av olika automatiseringsverktyg.
4. Skriptutveckling och automatiseringsramar med exempel.
5. Exekvering och rapportering av testautomatisering.
6. Bästa metoder och strategier för testautomatisering.

.