Meny

Vad är Automation Testing (Ultimate Guide to Start Test Automation)

what is automation testing

Prova Vårt Instrument För Att Eliminera Problem

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

Vad är automatiseringstestning?

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 automatiseringstestverktyg. Testautomatisering används för att automatisera repetitiva uppgifter och andra testuppgifter som är svåra att utföra manuellt.

guide för automatiseringstestning

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

  • Hur introducerar jag automatisering till ditt projekt?
  • Hur väljer man det bästa och rätta automatiseringsverktyget?
  • Hur utvecklar man skript effektivt?
  • Hur kör jag och underhåller testskript?
  • Och slutligen, vilka är de bästa metoderna som du behöver följa för framgångsrik automatiseringstestning?

Idag har vi planerat att berika din kunskap med en serie handledning om “ Komma igång med Automation Testing ”. Denna serie av automatiseringshandledning kommer att svara på alla ovanstående frågor steg för steg med enkla exempel.

Låt oss ta en titt på serien Tutorials om att starta automatisering i ditt projekt !!

Automation End-to-end-process:

Handledning nr 1 : Bästa guiden för att starta automatisering i ditt projekt
Handledning nr 2: Typer av automatiserade tester och vissa missuppfattningar
Handledning nr 3: 10 steg för att introducera automatisering i ditt projekt
Handledning nr 4: A till Z-guiden för att välja det bästa automatiseringsverktyget
Handledning nr 5: Skriptutveckling och automatiseringsramar
Självstudie nr 6: Utförande och rapportering av automatisering
Självstudie 7: Bästa praxis och strategier för testautomatisering

.net intervjuer om webbtjänster

Tips för automatisering:

Handledning # 8: 10 tips du bör läsa innan du automatiserar ditt testarbete
Handledning nr 9: Hur skiljer sig testplanering för manuella och automatiseringsprojekt
Handledning nr 10: När ska jag välja automatisering?
Handledning nr 11: Automation Test Utmaningar
Handledning nr 12: Guide till Implement Proof of Concept (POC) i automatisering
Handledning nr 13: Hur man väljer rätt testfall för automatisering
Handledning nr 14: Hur man översätter manuella testfall till automatiseringsskript

Automationskarriär:

Handledning nr 15: Tips för att bli en bättre automatiseringstestare
Handledning nr 16: Testautomation - Är det en specialiserad karriär? Kan normala testare göra automatisering också?

Populära automatiseringsverktyg:

Handledning nr 17: Selen Tutorials 31+ Bästa gratis Selen Training Tutorials
Handledning nr 18: QTP-handledning
Handledning nr 19: SoapUI Web Services Testing Tool
Handledning nr 20: HP LoadRunner för prestandatestning

Automationsramar:

Handledning nr 21: Varför behöver vi ramverk för automatisering
Handledning # 22: Mest populära automatiseringsramar

Automation i Agile:

Handledning nr 23: Hur man implementerar effektiv automatisering i den smidiga världen

Andra automatiseringsverktyg:

Handledning # 24: Bästa verktyg för automatiseringstest
Handledning nr 25: Sikuli GUI Automation Tool
Handledning nr 26: PowerShell: Desktop Application UI Automation With PowerShell
Självstudie nr 27: Catalon Automation Recorder (Selen IDE Alternative)
Handledning # 28: Geb Tool: Browser Automation med Geb Tool
Handledning nr 29: AutoIt: Hur man hanterar popup-fönster i Windows med AutoIt
Självstudie # 30: Gurka: Automation med hjälp av gurkaverktyg och selen
Självstudie nr 31: Protractor Test Tool för End-to-End Testing av AngularJS-applikationer

Testning av mobil automatisering:

Handledning nr 32: Appium Studio praktisk handledning
Handledning nr 33: Appium Tutorial för nybörjare
Handledning # 34: Selendroid-handledning: Android Mobile Automation Framework
Handledning nr 35: Ranorex-handledning: Ett kraftfullt testverktyg för skrivbord, webb och mobil

Domänspecifika automatiseringsexempel:

Handledning # 36: Automatisering av JAVA / J2EE-applikationer

Intervjuförberedelse för automatiseringsjobb:

Handledning nr 37: Intervjufrågor om automatiseringstest
Handledning # 38: Selenintervjuer

Låt oss utforska den första självstudien från 'The Ultimate Guide to Automation Testing' -serien !!

Vad du kommer att lära dig:

Vad är automatiseringstestning?

Om en programvara kan göra någonting då, varför kan inte en programvara testa en programvara?

Låter detta uttalande logiskt för dig?

Om ja, då gratulerar du nu till att tänka på Test Automation, som är den centrala punkten som vi ska diskutera i denna serie informativa handledning.

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

Du försöker ange slumpmässiga data i det här formuläret som 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 antecknar stolt stegen och rapporterar felet i ditt felhanteringssystem. Stor ansträngning, du känner dig riktigt säker och energisk. Du fortsätter testningen tills dagen slutar och hittar några fler buggar. 'Fantastisk första dag', tänkte du.

Nu kommer nästa dag, utvecklaren har fixat problemet och släpper en ny version av build. Du testar samma formulär med samma steg och du upptäckte att felet är fixat. Du markerar det som fixat. Stor ansträngning. Du har bidragit till produktens kvalitet genom att identifiera detta fel och eftersom detta fel är fixat förbättras kvaliteten.

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

Föreställ dig nu om en månad från och med nu, nya versioner släpps ständigt och vid varje släpp måste du testa den här långa formen plus 100 andra former som denna, bara för att se till att ingen regression finns.

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

Och en dag rapporterar klienten samma fel i samma form. Du känner dig patetisk. Du känner dig självförtroende nu. Du tror att du inte är tillräckligt kompetent. Chefer ifrågasätter din förmåga.

Jag har en nyhet åt dig; det här är berättelsen om 90% 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 här är vad maskiner gör. Detta är vad automatisering krävs för att upprepa samma steg med samma hastighet, noggrannhet och energi som de upprepades första gången.

Jag hoppas du får min poäng !!

automatisering testa en vän

När en sådan situation uppstår bör du automatisera ditt testfall. Testautomation ä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 det här formuläret på mindre än tre minuter.

Skriptet fyller alla fält och berättar resultatet tillsammans med skärmdumpar. I händelse av misslyckande kan den lokalisera platsen där testfallet misslyckades, vilket hjälper dig att reproducera det enkelt.

Automation - En kostnadseffektiv metod för regressionstestning

Automationskostnaderna är verkligen högre initialt. Det inkluderar kostnaden för verktyget, sedan kostnaden för automatiseringstestresursen och hans / hennes utbildning.

Men när manusen är klar kan de köras hundratals gånger upprepade gånger med samma noggrannhet och ganska snabbt. Detta sparar många timmar 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 automatisera testning. Det finns flera situationer som inte kan testas manuellt.

Till exempel ,

  1. Jämföra två bilder pixel för pixel.
  2. Jämför två kalkylark som innehåller tusentals rader och kolumner.
  3. Testa en applikation under belastning av 100 000 användare.
  4. Prestandamätvärden.
  5. Testar applikationen i olika webbläsare och på olika operativsystem parallellt.

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

Så när ska man automatisera?

Detta är en era av smidig 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.

Tänk på följande situationer innan du går in i automatisering

  • Produkten kan vara i sina primitiva stadier, när produkten inte ens har ett användargränssnitt, i dessa steg måste vi ha en tydlig tanke på vad vi vill automatisera. Följande punkter bör komma ihåg.
    • Test bör inte vara föråldrade.
    • När produkten utvecklas bör det vara lätt att välja på manusen och lägga till den.
    • Det är mycket viktigt att inte låtas röra sig och se till att skripten är lätta att felsöka.
  • Försök inte att automatisera användargränssnitt i de första inledningarna, eftersom användargränssnittet utsätts för frekventa förändringar, vilket leder till att skript misslyckas. Så långt som möjligt väljer du API-nivå / icke-UI-nivåautomatisering tills produkten stabiliseras. API-automatisering är lätt att fixa och felsöka.

Hur man beslutar om bästa automatiseringsfall:

Automation är en integrerad del av en testcykel och det är mycket viktigt att bestämma vad vi vill uppnå med automatisering innan vi väljer att automatisera.

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

Effektiv testautomatisering

Denna serie förklarar dig om hur en automatiseringssvit kan göras tillräckligt effektiv för att plocka upp rätt testfall och ge rätt resultat med de automatiseringsskript som vi har.

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 automatisering.

Rätt test för automatisering

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

Tanken är att gruppera testfallet så att varje grupp ger oss olika resultat. Illustrationen nedan visar hur vi kunde gruppera våra liknande testfall, beroende på vilken produkt / lösning vi testar.

Gruppera testfall

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

# 1) Skapa en testsvit med alla grundläggande funktioner Positiva tester . Denna svit ska automatiseras, och när den här sviten körs mot alla byggnader visas resultaten omedelbart. Alla skript som misslyckas i den här sviten leder till S1- eller S2-defekt, och det byggspecifika kan diskvalificeras. Så vi har sparat mycket tid här.

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

Detta uppnår tydligt målen för automatisering som är:

  • Minska testansträngningen.
  • Hitta buggar i tidigare skeden.

#två) Därefter har vi en grupp av Slut till slut tester .

Under stora lösningar är det viktigt att testa en slut-till-slut-funktionalitet, särskilt under de kritiska stadierna av projektet. Vi borde ha några automatiseringsskript som också berör lösningstesterna från slut till slut. När den här sviten körs bör resultatet ange om produkten som helhet fungerar som förväntat eller inte.

Automationstestpaketet bör anges om någon av integrationsstyckena går sönder. Denna svit behöver inte täcka varje liten funktion / funktionalitet i lösningen men den ska täcka produktens funktion som helhet. Närhelst vi har en alfa eller en beta eller någon annan mellanliggande version, så är sådana skript till nytta och ger kunden viss grad av förtroende.

För att bättre förstå, låt oss anta att vi testar en online shoppingportal , som en del av testet från slut till slut bör vi endast täcka de viktigaste stegen som är inblandade.

Som anges nedan:

  • Användarnamn.
  • Bläddra och välj objekt.
  • Betalningsalternativ - detta täcker frontend-testerna.
  • Backend orderhantering (innebär att kommunicera med flera integrerade partners, kontrollera lager, skicka e-post till användaren etc) - detta kommer att hjälpa till att testa integrationen av enskilda bitar och även kärnan i produkten.

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

# 3) Den tredje uppsättningen är Funktionsbaserade tester .

För exempel , Vi kan ha funktionalitet för att bläddra och välja en fil, så när vi automatiserar detta kan vi automatisera ärenden så att de inkluderar valet av olika typer av filer, filstorlekar etc, så att funktionstestning görs. När det finns några ändringar / tillägg till den funktionen kan den här sviten 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, begränsning av textruta, kalenderknapp, nedrullningar, grafer, bilder och många sådana UI-centrerade funktioner. Misslyckande med dessa skript är vanligtvis inte särskilt kritiskt om inte användargränssnittet är helt nere eller vissa sidor inte visas som förväntat!

# 5) Vi kan ha ännu en uppsättning tester som är enkla men mycket mödosamma att utföra manuellt. Tråkiga men enkla tester är de perfekta automatiseringskandidaterna, till exempel att skriva in detaljer om 1000 kunder i databasen har en enkel funktionalitet men extremt tråkig att utföra manuellt, sådana tester bör automatiseras. Om inte, blir de oftast ignorerade och inte testade.

Vad ska man INTE automatisera?

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 eller failover-tester , när det gäller dessa tester måste testarna tänka analytiskt och negativa tester är inte riktigt enkla för att ge ett godkänt eller misslyckat resultat som kan hjälpa oss.

Negativa tester kommer att kräva mycket manuellt ingripande för att simulera ett faktiskt scenario för katastrofåterställning. Bara för att exemplifiera testar vi funktioner som webbtjänsternas tillförlitlighet - att generalisera det här skulle huvudsyftet med sådana tester vara att orsaka avsiktliga fel och se hur bra produkten lyckas vara pålitlig.

Att simulera ovanstående fel är inte enkelt, det kan handla om att injicera några stubbar eller använda några verktyg däremellan och automatisering är inte det bästa sättet att gå hit.

# 2) Ad hoc-tester

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

Till exempel , En testare som testar en funktion som handlar om komprimering / kryptering av data kan ha gjort intensiva ad hoc-tester med olika data, filtyper, filstorlekar, korrupt data, en kombination av data, med olika algoritmer, över flera plattformar etc.

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

# 3) Tester med massiv förinstallation

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

Till exempel, Vi kan ha en produkt som integreras med en tredjepartsprogramvara för vissa av funktionerna, eftersom produkten integreras med alla meddelandekösystem som kräver installation i ett system, konfigurering av köer, skapande av köer etc.

3rdpartiprogramvara kan vara vad som helst och installationen kan vara komplex till sin natur och om sådana skript automatiseras kommer dessa för alltid att bero på funktionen / installationen av den tredje partens programvara.

Förutsättningen inkluderar:

För närvarande kan saker och ting se enkla och rena ut eftersom båda inställningarna görs och allt är bra. Vi har vid flera tillfällen sett att när ett projekt går in i underhållsfasen flyttas projektet till ett annat team, och de slutar felsöka sådana manus där själva testet är väldigt enkelt men manuset misslyckas på grund av en 3rdpart mjukvaruproblem.

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

Enkelt exempel på testautomatisering

När du testar en programvara (på webben eller på skrivbordet) använder du vanligtvis en mus och ett tangentbord för att utföra dina steg. Automationsverktyget härmar 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 lägga till två siffror och se resultatet. Manuset kommer att utföra samma steg genom att använda musen och tangentbordet.

verktyg för livscykelhantering för öppen källkod

Exemplet visas nedan.

Manuella testfallsteg:

  1. Starta miniräknare
  2. Tryck på 2
  3. Tryck på +
  4. Tryck på 3
  5. Tryck på =
  6. Skärmen ska visa 5.
  7. Stäng miniräknare.

Automationsskript:

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

Ovanstående skript är bara en kopiering av dina manuella steg. Manuset är enkelt att skapa och lätt att förstå också.

Vad är påståenden?

Den näst sista raden i skriptet behöver lite mer förklaring.

Assert.AreEqual (“5”, txtResult.DisplayText, ”Kalkylatorn visar inte 5);

I varje testfall har vi några förväntade eller förutspådda resultat i slutet. I ovanstående skript har vi en förväntan att '5' ska visas på skärmen. Det faktiska resultatet är resultatet som visas på skärmen. I varje testfall jämför vi det förväntade resultatet med det faktiska resultatet.

Samma sak gäller även automatiseringstestning. Den enda skillnaden här är, när vi gör den jämförelsen i testautomation, så kallas det något annat i varje verktyg.

Vissa verktyg kallar det som “ Påstående ”, Vissa kallar det som“ kontrollstation ”Och vissa kallar det som” validering ”. Men i grund och botten är detta bara en jämförelse. Om denna jämförelse misslyckas, för T.ex. en skärm visar 15 istället för 5 då misslyckas detta påstående / kontrollpunkt / validering och ditt testfall markeras som misslyckat.

När ett testfall misslyckas på grund av ett påstående betyder det att du har upptäckt ett fel 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 ett påstående 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 'Miniräknare visar inte 5'.

Slutsats

Testare stöter ofta på projektets tidsfrister och mandat att automatisera alla ärenden för att förbättra testuppskattningarna.

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

Dom är:

  • Vi kan automatisera varje testfall.
  • Automatisering av tester minskar testtiden enormt.
  • Inga buggar införs om automatiseringsskript fungerar smidigt.

Vi bör vara tydliga att automatisering kan minska testtiden endast för vissa typer av tester. Automatisering av alla tester utan någon plan eller sekvens leder till massiva skript som är tungt underhåll, misslyckas ofta och behöver mycket manuellt ingripande också. Även i ständigt utvecklade produkter kan automatiseringsskript bli föråldrade och behöver några ständiga kontroller.

Gruppering och automatisering av rätt kandidater sparar mycket tid och ger alla fördelarna med automatisering.

Denna utmärkta handledning kan sammanfattas i bara 7 poäng.

Automationstestning:

  • Är testningen som görs programmatiskt.
  • Använder verktyget för att kontrollera genomförandet av tester.
  • Jämför förväntade resultat med de faktiska resultaten (påståenden).
  • Kan automatisera vissa repetitiva men nödvändiga uppgifter ( T.ex. Dina fall av regressionstest).
  • Kan automatisera vissa uppgifter som är svåra att göra manuellt (T.ex.Scenarier för belastningstest).
  • Skript kan köras snabbt och upprepade gånger.
  • Är kostnadseffektivt på lång sikt.

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 involverade i det. Det finns många sätt på vilka testautomation kan gå fel, men om allt går bra är fördelarna med testautomation verkligen enorma.

Kommande i denna serie:

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

Dessa inkluderar:

  1. Typer av automatiserade tester och vissa missuppfattningar.
  2. Hur man introducerar automatisering i din organisation och undviker vanliga fallgropar när man gör testautomation.
  3. Verktygsvalsprocessen och jämförelse av olika automatiseringsverktyg.
  4. Skriptutveckling och automatiseringsramar med exempel.
  5. Utförande och rapportering av testautomation.
  6. Bästa praxis och strategier för testautomatisering.

Vill du veta mer om varje koncept för automatiseringstestning? Se upp och håll dig uppdaterad med vår lista över kommande handledning i denna serie och uttryck gärna dina tankar i kommentarfältet nedan.

NÄSTA självstudie # 2

Rekommenderad läsning

^