Menu

Hvad er automatiseringstest (ultimativ guide til start af testautomatisering)

what is automation testing

Prøv Vores Instrument Til At Fjerne Problemer

En komplet guide til start af automatiseringstest på dit projekt:

Hvad er automatiseringstest?

Automatiseringstest er en softwaretestteknik til at teste og sammenligne det faktiske resultat med det forventede resultat. Dette kan opnås ved at skrive testskripter eller ved hjælp af ethvert automatiserings testværktøj. Testautomatisering bruges til at automatisere gentagne opgaver og andre testopgaver, som er vanskelige at udføre manuelt.

guide til automatiseringstest

Vil du starte automatiseringstesten på dit projekt, men kæmper du med de mest grundlæggende trin som nævnt nedenfor:

  • Hvordan introducerer jeg automatisering til dit projekt?
  • Hvordan vælger jeg det bedste og rigtige automatiseringsværktøj?
  • Hvordan udvikler man scripts effektivt?
  • Hvordan udføres og vedligeholdes testskripter?
  • Og endelig, hvad er de bedste fremgangsmåder, du skal følge for en vellykket automatiseringstest?

I dag har vi planlagt at berige din viden med en række tutorials om “ Kom godt i gang med automatiseringstest ”. Denne serie af automatiseringsvejledninger vil besvare alle ovenstående spørgsmål trin for trin med enkle eksempler.

Lad os tage et kig på serien af ​​tutorials om start af automatisering på dit projekt !!

Automatisering slut-til-slut-proces:

Vejledning nr. 1 : Bedste guide til at starte automatisering på dit projekt
Tutorial # 2: Typer af automatiserede tests og nogle misforståelser
Tutorial # 3: 10 trin til at introducere automatisering på dit projekt
Tutorial # 4: A til Z-vejledningen om valg af det bedste automatiseringsværktøj
Tutorial # 5: Skriptudvikling og automatiseringsrammer
Tutorial # 6: Udførelse og rapportering af automatisering
Tutorial # 7: Bedste praksis og strategier for testautomatisering

Tips til automatisering:

Tutorial # 8: 10 tip, du skal læse, inden du automatiserer dit testarbejde
Tutorial # 9: Hvordan adskiller testplanlægning sig for manuelle og automatiseringsprojekter
Tutorial # 10: Hvornår skal man vælge automatisering?
Tutorial # 11: Automatiseringstestudfordringer
Tutorial # 12: Vejledning til implementering af bevis for koncept (POC) i automatisering
Tutorial # 13: Sådan vælges korrekte testtilfælde til automatisering
Tutorial # 14: Sådan oversættes manuelle testsager til automatiseringsskripter

Automatiseringskarriere:

Tutorial # 15: Tips til at blive en bedre automatiseringstester
Tutorial # 16: Testautomatisering - er det en specialiseret karriere? Kan normale testere også automatisere?

Populære automatiseringsværktøjer:

Tutorial # 17: Selen Tutorials 31+ Bedste gratis Selen Training Tutorials
Tutorial # 18: QTP-vejledninger
Tutorial # 19: Testværktøj til SoapUI Web Services
Tutorial # 20: HP LoadRunner til ydelsestest

Automatiseringsrammer:

Tutorial # 21: Hvorfor har vi brug for rammer til automatisering
Tutorial # 22: Mest populære automatiseringsrammer

Automatisering i Agile:

Tutorial # 23: Sådan implementeres effektiv automatisering i den agile verden

Andre automatiseringsværktøjer:

Tutorial # 24: Bedste automatiseringstestværktøjer
Tutorial # 25: Sikuli GUI-automatiseringsværktøj
Tutorial # 26: PowerShell: Desktop Application UI Automation With PowerShell
Tutorial # 27: Catalon Automation Recorder (Selenium IDE Alternative)
Tutorial # 28: Geb Tool: Browserautomatisering ved hjælp af Geb Tool
Tutorial # 29: AutoIt: Sådan håndteres Windows Pop-up ved hjælp af AutoIt
Tutorial # 30: Agurk: Automatisering ved hjælp af agurkværktøj og selen
Tutorial # 31: Vinkelmåler testværktøj til end-to-end test af AngularJS applikationer

Test af mobil automatisering:

Tutorial # 32: Appium Studio praktisk vejledning
Tutorial # 33: Appium Tutorial for begyndere
Tutorial # 34: Selendroid Tutorial: Android Mobile Automation Framework
Tutorial # 35: Ranorex-selvstudie: Et kraftfuldt testværktøj til desktop, web og mobil

Domænespecifikke automatiseringseksempler:

Tutorial # 36: Automatisering af JAVA / J2EE applikationer

Interviewforberedelse til automatiseringsjob:

Tutorial # 37: Interviewspørgsmål om automatiseringstest
Tutorial # 38: Selenium Interview Spørgsmål

Lad os udforske den første tutorial fra 'The Ultimate Guide to Automation Testing' -serien !!

Hvad du vil lære:

Hvad er automatiseringstest?

Hvis en software kan gøre noget, så hvorfor kan en software ikke teste en software?

Lyder denne erklæring logisk for dig?

Hvis ja, så tillykke, tænker du nu på Test Automation, som er det centrale punkt, som vi skal diskutere i denne serie af informative tutorials.

Forestil dig dig selv den første dag på dit job som SQA. Du får en ansøgning, der skal testes. Det er en ERP-applikation, der indeholder 100'ers formularer og tusinder af rapporter. Du begynder din sonderende test ved at åbne en formular, der indeholder omkring 50 forskellige felter.

Du forsøger at indtaste tilfældige data i denne form, som tog omkring 20 minutter. Tryk derefter på send. Wolla !! Der vises en fejlmeddelelse, der ligner en ikke-håndteret undtagelse. Du bliver meget glad. Du noterer stolt trinnene og rapporterer fejlen i dit fejlstyringssystem. Stor indsats, du føler dig virkelig selvsikker og energisk. Du fortsætter testen, indtil dagen slutter, og finder nogle flere fejl. “Fantastisk første dag”, tænkte du.

Nu kommer den næste dag, udvikleren har løst problemet og frigiver en ny version af bygningen. Du tester den samme form med de samme trin, og du fandt ud af, at fejlen er rettet. Du markerer det som løst. Stor indsats. Du har bidraget til produktets kvalitet ved at identificere denne fejl, og da denne fejl er rettet, forbedres kvaliteten.

Nu kommer den tredje dag, en udvikler har igen frigivet en nyere version. Nu skal du igen teste den formular for at sikre dig, at der ikke findes noget regressionsproblem. Samme 20 minutter. Nu føler du dig lidt keder.

Forestil dig nu 1 måned fra nu af, nyere versioner frigives konstant, og på hver udgivelse skal du teste denne lange form plus 100 andre former som denne, bare for at sikre, at der ikke er nogen regression.

Nu føler du dig vred. Du føler dig træt . Du begynder at springe trin over. Du udfylder kun 50% af de samlede felter. Din nøjagtighed er ikke den samme, din energi er ikke den samme og bestemt, dine trin er ikke de samme.

Og en dag rapporterer klienten den samme fejl i samme form. Du føler dig ynkelig. Du føler dig selvtillid nu. Du tror, ​​du ikke er kompetent nok. Ledere stiller spørgsmålstegn ved din evne.

Jeg har en nyhed til dig; dette er historien om 90% af de manuelle testere derude. Du er ikke anderledes.

Regression problemer er de mest smertefulde problemer. Vi er mennesker. Og vi kan ikke gøre det samme med den samme energi, hastighed og nøjagtighed hver dag. Dette er hvad maskiner gør. Dette er hvad der kræves automatisering for at gentage de samme trin med samme hastighed, nøjagtighed og energi, som de blev gentaget første gang.

hvordan åbner jeg en torrentfil

Jeg håber du får min pointe !!

automatiseringstest af en ven

Hver gang en sådan situation opstår, skal du automatisere din testsag. Testautomation er din ven . Det hjælper dig med at fokusere på ny funktionalitet, mens du tager dig af regressionerne. Med automatisering kan du udfylde formularen på mindre end 3 minutter.

Scriptet udfylder alle felterne og fortæller dig resultatet sammen med skærmbilleder. I tilfælde af fiasko kan det lokalisere det sted, hvor testsagen mislykkedes, hvilket hjælper dig med at reproducere det let.

Automatisering - En omkostningseffektiv metode til regressionstest

Automatiseringsomkostningerne er oprindeligt højere. Det inkluderer omkostningerne til værktøjet, derefter omkostningerne til ressourcen til automatiseringstest og hans / hendes træning.

Men når scripts er klar, kan de udføres hundreder af gange gentagne gange med samme nøjagtighed og ret hurtigt. Dette sparer mange timers manuel test. Så omkostningerne falder gradvist, og i sidste ende bliver det en omkostningseffektiv metode til Regressionstest .

Scenarier, der kræver automatisering

Ovenstående scenario er ikke det eneste tilfælde, hvor du har brug for automatiseringstest. Der er flere situationer, som ikke kan testes manuelt.

For eksempel ,

  1. Sammenligning af to billeder pixel for pixel.
  2. Sammenligning af to regneark, der indeholder tusinder af rækker og kolonner.
  3. Test af en applikation under belastning af 100.000 brugere.
  4. Benchmarks for ydeevne.
  5. Test af applikationen i forskellige browsere og på forskellige operativsystemer parallelt.

Disse situationer kræver og bør testes af værktøjer.

Så hvornår skal man automatisere?

Dette er en æra af agil metode i SDLC, hvor udvikling og test vil gå næsten parallelt, og det er meget vanskeligt at beslutte, hvornår man skal automatisere.

Overvej følgende situationer, inden du går ind i automatisering

  • Produktet kan være i sine primitive faser, når produktet ikke engang har et brugergrænseflade, på disse stadier skal vi have en klar overvejelse om, hvad vi vil automatisere. Følgende punkter skal huskes.
    • Test bør ikke være forældet.
    • Efterhånden som produktet udvikler sig, skal det være let at vælge på scripts og tilføje det.
    • Det er meget vigtigt ikke at blive båret væk og sikre, at scripts er lette at fejle.
  • Forsøg ikke UI-automatisering i de indledende faser, da UI udsættes for hyppige ændringer, hvorved scripts mislykkes. Så vidt muligt vælg API-niveau / Ikke-UI-automatisering, indtil produktet stabiliseres. API-automatisering er let at rette og fejle.

Sådan afgøres de bedste automatiseringssager:

Automatisering er en integreret del af en testcyklus, og det er meget vigtigt at beslutte, hvad vi vil opnå med automatisering, inden vi beslutter at automatisere.

Fordelene, som automatisering ser ud til at give, er meget attraktive, men på samme tid kan en dårligt organiseret automatiseringspakke ødelægge hele spillet. Testere kan ende med at debugge og rette scriptsne det meste af tiden, hvilket resulterer i tab af testtid.

Effektiv testautomatisering

Denne serie forklarer dig om, hvordan en automatiseringspakke kan gøres effektiv nok til at afhente de rigtige testsager og give de rigtige resultater med de automatiseringsskripter, vi har.

Jeg har også dækket svarene på spørgsmål som Hvornår skal man automatisere, Hvad man skal automatisere, Hvad man ikke skal automatisere og Hvordan man strategiserer automatisering.

De rigtige tests til automatisering

Den bedste måde at tackle dette problem på er hurtigt at komme med en “automatiseringsstrategi”, der passer til vores produkt.

Ideen er at gruppere testsagerne, så hver gruppe giver os forskellige resultater. Illustrationen nedenfor viser, hvordan vi kunne gruppere vores lignende testtilfælde afhængigt af det produkt / den løsning, vi tester.

Gruppering af testtilfælde

Lad os nu dykke dybt og forstå, hvad hver gruppe kan hjælpe os med at opnå:

# 1) Lav en testpakke med alle de grundlæggende funktioner Positive tests . Denne suite skal automatiseres, og når denne suite køres mod enhver build, vises resultaterne med det samme. Ethvert script, der fejler i denne suite, fører til S1- eller S2-defekt, og det byggespecifikke kan diskvalificeres. Så vi har sparet meget tid her.

Som et yderligere trin kan vi tilføje denne automatiserede testpakke som en del af BVT (Build verification tests) og kontrollere QA-automatiseringsscripts i produktopbygningsprocessen. Så når build er klar, kan testere kontrollere, om automatiserings testresultaterne er, og beslutte, om build er egnet eller ikke til installation og yderligere testproces.

Dette opnår klart målene for automatisering, som er:

  • Reducer testindsatsen.
  • Find fejl på tidligere stadier.

#to) Dernæst har vi en gruppe af End to End tests .

Under store løsninger er det nøglen at teste en ende-til-slut-funktionalitet, især i de kritiske faser af projektet. Vi burde have et par automatiseringsskripter, der også rører end-to-end løsningstestene. Når denne suite køres, skal resultatet indikere, om produktet som helhed fungerer, som det forventes eller ej.

Automatiseringstestpakken skal angives, hvis nogen af ​​integrationsstykkerne er brudt. Denne pakke behøver ikke at dække hver eneste lille funktion / funktionalitet i løsningen, men den skal dække produktets arbejde som helhed. Når vi har en alfa eller en beta eller andre mellemliggende udgivelser, så er sådanne scripts nyttige og giver kunderne et vist niveau af tillid.

For at forstå bedre, lad os antage, at vi tester en online shopping portal , som en del af slut-til-slut-testene, skal vi kun dække de involverede nøgletrin.

Som angivet nedenfor:

  • Bruger login.
  • Gennemse og vælg emner.
  • Betalingsmulighed - dette dækker frontend-testene.
  • Backend ordrehåndtering (involverer kommunikation med flere integrerede partnere, kontrol af lager, e-mail til brugeren osv.) - dette vil hjælpe med at teste integrationen af ​​individuelle stykker og også kernen i produktet.

Så når et sådant script køres, giver det tillid til, at løsningen som helhed fungerer fint.!

# 3) Det tredje sæt er Funktions- / funktionalitetsbaserede tests .

Til eksempel , Vi har muligvis funktionalitet til at gennemse og vælge en fil, så når vi automatiserer dette, kan vi automatisere sager, så de inkluderer valg af forskellige typer filer, filstørrelser osv., Så funktionstest udføres. Når der er ændringer / tilføjelser til denne funktionalitet, kan denne suite tjene som en regressionssuite.

# 4) Næste på listen ville være UI-baserede tests. Vi kan have en anden pakke, der vil teste rent UI-baserede funktioner som pagination, tekstboksbegrænsning, kalenderknap, drop-down, grafer, billeder og mange sådanne UI-centrerede funktioner. Fejl i disse scripts er normalt ikke meget kritisk, medmindre brugergrænsefladen er helt nede, eller visse sider ikke vises som forventet!

# 5) Vi kan have endnu et sæt tests, der er enkle, men meget besværlige, der skal udføres manuelt. Kedelige men enkle tests er de ideelle automatiseringskandidater, for eksempel at indtaste detaljer om 1000 kunder i databasen har en simpel funktionalitet, men ekstremt kedelig at udføre manuelt, sådanne tests skal automatiseres. Hvis ikke, ender de for det meste med at blive ignoreret og ikke testet.

Hvad IKKE skal automatisere?

Nedenfor er der få test, som ikke bør automatiseres.

# 1) Negative tests / failover-tests

Vi bør ikke forsøge at automatisere negative eller failover-tests , hvad angår disse tests, skal testerne tænke analytisk, og negative tests er ikke rigtig ligetil for at give et bestået eller fejlet resultat, som kan hjælpe os.

Negative tests vil have brug for en masse manuel indgriben for at simulere en faktisk situation efter katastrofegendannelse. Bare for at eksemplificere tester vi funktioner som webtjenestes pålidelighed - for at generalisere det her ville hovedformålet med sådanne tests være at forårsage bevidste fejl og se, hvor godt produktet formår at være pålideligt.

Simulering af ovenstående fejl er ikke ligetil, det kan involvere indsprøjtning af nogle stubbe eller brug af nogle værktøjer imellem, og automatisering er ikke den bedste måde at gå her.

# 2) Ad hoc-tests

Disse tests er måske ikke rigtig relevante for et produkt til enhver tid, og det kan endda være noget, som testeren kunne tænke på på det tidspunkt i projektinitieringen, og også indsatsen for at automatisere en ad hoc-test skal valideres mod kritikken af den funktion, som testene berører.

For eksempel , En tester, der tester en funktion, der beskæftiger sig med komprimering / kryptering af data, kan have udført intense ad-hoc-tests med forskellige data, filtyper, filstørrelser, korrupte data, en kombination af data ved hjælp af forskellige algoritmer på tværs af flere platforme osv.

Når vi planlægger automatisering Vi vil muligvis prioritere og ikke udtømme automatisering af alle ad hoc-testene for denne funktion alene og ender med lidt tid til automatisering af de andre nøglefunktioner.

# 3) Test med massiv forudindstilling

Der er tests, der kræver nogle enorme forudsætninger.

For eksempel, Vi har muligvis et produkt, der integreres med en tredjepartssoftware til nogle af funktionerne, da produktet integreres med ethvert meddelelseskøsystem, der kræver installation på et system, opsætning af køer, oprettelse af køer osv.

Den 3rdfestsoftware kan være hvad som helst, og opsætningen kan være kompleks i naturen, og hvis sådanne scripts automatiseres, vil disse for altid være afhængige af funktionen / opsætningen af ​​den tredjepartssoftware.

Forudsætningen inkluderer:

På nuværende tidspunkt kan ting se enkle og rene ud, da begge sideopsætninger udføres, og alt er i orden. Vi har ved flere lejligheder set, at når et projekt går ind i vedligeholdelsesfasen, flyttes projektet til et andet team, og de ender med at debugge sådanne scripts, hvor selve testen er meget enkel, men scriptet mislykkes på grund af en 3rdpart software problem.

Ovenstående er blot et eksempel, hold generelt øje med tests, der har besværlige forudindstillinger for en simpel test, der følger.

Simpel eksempel på testautomatisering

Når du tester en software (på internettet eller på skrivebordet), bruger du normalt en mus og et tastatur til at udføre dine trin. Automatiseringsværktøjet efterligner de samme trin ved hjælp af scripting eller et programmeringssprog.

For eksempel , hvis du tester en lommeregner, og testtilfældet er, at du skal tilføje to tal og se resultatet. Scriptet udfører de samme trin ved at bruge din mus og tastatur.

implementering af en graf i c ++

Eksemplet er vist nedenfor.

Manuel test sag trin:

  1. Start lommeregner
  2. Tryk på 2
  3. Tryk på +
  4. Tryk på 3
  5. Tryk på =
  6. Skærmen skal vise 5.
  7. Luk lommeregner.

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(); }

Ovenstående script er blot en kopiering af dine manuelle trin. Scriptet er let at oprette og også let at forstå.

Hvad er påstande?

Den næstsidste linje i scriptet har brug for mere forklaring.

Assert.AreEqual (“5”, txtResult.DisplayText, ”Lommeregner viser ikke 5);

I hvert testtilfælde har vi nogle forventede eller forudsagte resultater i slutningen. I ovenstående script har vi en forventning om, at '5' skal vises på skærmen. Det faktiske resultat er det resultat, der vises på skærmen. I hvert test tilfælde sammenligner vi det forventede resultat med det faktiske resultat.

Det samme gælder også automatiseringstest. Den eneste forskel her er, når vi foretager denne sammenligning i testautomatisering, kaldes det noget andet i hvert værktøj.

Nogle værktøjer kalder det som “ Påstand ”, Nogle kalder det som“ kontrolpunkt ”Og nogle kalder det som“ validering ”. Men dybest set er dette bare en sammenligning. Hvis denne sammenligning mislykkes, for For eksempel. en skærm viser 15 i stedet for 5, så denne påstand / kontrolpunkt / validering mislykkes, og din testsag er markeret som mislykket.

Når en testsag mislykkes på grund af en påstand, betyder det, at du har registreret en fejl gennem testautomatisering. Du skal rapportere det til dit fejlhåndteringssystem, ligesom du normalt gør ved manuel test.

I ovenstående script har vi udført en påstand i næstsidste linje. 5 er det forventede resultat, txtResult . DisplayText er det faktiske resultat, og hvis de ikke er ens, får vi vist en besked om, at 'Lommeregner ikke viser 5'.

Konklusion

Ofte støder testere på projektfrister og mandater til at automatisere alle sager for at forbedre testestimaterne.

Der er nogle almindelige 'forkerte' opfattelser af automatisering.

De er:

  • Vi kan automatisere alle testsager.
  • Automatisering af test reducerer testtiden enormt.
  • Ingen bugs introduceres, hvis automatiseringsskripter kører problemfrit.

Vi skal være klare over, at automatisering kun kan reducere testtiden for visse typer tests. Automatisering af alle test uden plan eller sekvens vil føre til massive scripts, som er tung vedligeholdelse, mislykkes ofte og også har brug for en masse manuel indgriben. Også i konstant udviklende produkter kan automatiseringsscripts blive forældede og have brug for nogle konstante kontroller.

Gruppering og automatisering af de rigtige kandidater sparer meget tid og giver alle fordelene ved automatisering.

Denne fremragende tutorial kan sammenfattes i kun 7 point.

Automatiseringstest:

  • Er testen, der udføres programmatisk.
  • Bruger værktøjet til at kontrollere udførelsen af ​​test.
  • Sammenligner forventede resultater med de faktiske resultater (Assertions).
  • Kan automatisere nogle gentagne men nødvendige opgaver ( For eksempel. Dine tilfælde af regressionstest).
  • Kan automatisere nogle opgaver, som er vanskelige at udføre manuelt (For eksempel.Load test scenarier).
  • Scripts kan køre hurtigt og gentagne gange.
  • Er omkostningseffektivt i det lange løb.

Her forklares automatisering i enkle vendinger, men det betyder ikke, at det altid er nemt at gøre. Der er udfordringer, risici og mange andre forhindringer involveret i det. Der er adskillige måder, hvorpå testautomatisering kan gå galt, men hvis alt går godt, så er fordelene ved testautomatisering virkelig enorme.

Kommende i denne serie:

I vores kommende tutorials vil vi diskutere flere aspekter relateret til automatisering.

Disse inkluderer:

  1. Typer af automatiserede tests og nogle misforståelser.
  2. Sådan introduceres automatisering i din organisation og undgår almindelige faldgruber, når du foretager testautomatisering.
  3. Værktøjsudvælgelsesprocessen og sammenligning af forskellige automatiseringsværktøjer.
  4. Scriptudvikling og automatiseringsrammer med eksempler.
  5. Udførelse og rapportering af testautomatisering.
  6. Bedste praksis og strategier for testautomatisering.

Er du ivrig efter at vide mere om hvert eneste koncept med automatiseringstest? Hold øje med og hold dig opdateret med vores liste over kommende tutorials i denne serie, og du er velkommen til at udtrykke dine tanker i kommentarfeltet nedenfor.

NÆSTE vejledning # 2

Anbefalet læsning

^