Meny

Hva er automatiseringstesting (Ultimate Guide to Start Test Automation)

what is automation testing

Prøv Instrumentet Vårt For Å Eliminere Problemer

En komplett guide for å starte automatiseringstesting på prosjektet ditt:

Hva er automatiseringstesting?

Automatiseringstesting er en programvaretesteteknikk for å teste og sammenligne det faktiske utfallet med det forventede resultatet. Dette kan oppnås ved å skrive testskripter eller bruke et hvilket som helst automatiseringsprøveverktøy. Testautomatisering brukes til å automatisere repeterende oppgaver og andre testoppgaver som er vanskelige å utføre manuelt.

hvordan du legger til verdier i en matrise

guide for automatiseringstesting

Vil du starte automatiseringstesten på prosjektet ditt, men sliter du med de mest grunnleggende trinnene som nevnt nedenfor:

  • Hvordan introdusere automatisering til prosjektet ditt?
  • Hvordan velge det beste og riktige automatiseringsverktøyet?
  • Hvordan utvikle skript effektivt?
  • Hvordan utføre og vedlikeholde testskript?
  • Og til slutt, hva er de beste fremgangsmåtene du må følge for vellykket automatiseringstesting?

I dag har vi planlagt å berike din kunnskap med en serie veiledninger om “ Komme i gang med automatiseringstesting ”. Denne serien med automatiseringsveiledninger vil svare på alle spørsmålene ovenfor trinnvis med enkle eksempler.

La oss ta en titt på serien Tutorials om å starte automatisering på prosjektet ditt !!

Automatisering slutt-til-slutt-prosess:

Opplæring # 1 : Beste guide for å starte automatisering på prosjektet ditt
Opplæring nr. 2: Typer automatiserte tester og noen misoppfatninger
Opplæring # 3: 10 trinn for å introdusere automatisering i prosjektet ditt
Opplæring # 4: Veiledningen A til Å om valg av det beste automatiseringsverktøyet
Opplæring # 5: Framework for skriptutvikling og automatisering
Opplæring # 6: Utførelse og rapportering av automatisering
Opplæring # 7: Beste praksis og strategier for testautomatisering

Tips om automatisering:

Opplæring # 8: 10 tips du bør lese før du automatiserer testarbeidet ditt
Opplæring 9: Hvordan er testplanlegging forskjellig for manuelle og automatiseringsprosjekter
Opplæring # 10: Når skal du velge automatisering?
Opplæring # 11: Automatiseringstestutfordringer
Opplæring # 12: Guide to Implement Proof of Concept (POC) in Automation
Opplæring # 13: Hvordan velge riktige testtilfeller for automatisering
Opplæring # 14: Hvordan oversette manuelle testtilfeller til automatiseringsskript

Automasjonskarriere:

Opplæring # 15: Tips for å bli en bedre automatiseringstester
Opplæring nr. 16: Testautomatisering - er det en spesialisert karriere? Kan normale testere gjøre automatisering også?

Populære automatiseringsverktøy:

Opplæring nr. 17: Selen Tutorials 31+ Beste gratis Selen Training Tutorials
Opplæring # 18: QTP opplæringsprogrammer
Opplæring # 19: Testverktøy for SoapUI Web Services
Opplæring nr. 20: HP LoadRunner for ytelsestesting

Automatiseringsrammer:

Opplæring # 21: Hvorfor trenger vi rammeverk for automatisering
Opplæring # 22: Mest populære automatiseringsrammer

Automatisering i smidig:

Opplæring # 23: Hvordan implementere effektiv automatisering i den smidige verden

Andre automatiseringsverktøy:

Opplæring # 24: Beste automatiseringstestverktøy
Opplæring # 25: Sikuli GUI Automation Tool
Opplæring # 26: PowerShell: Desktop Application UI Automation With PowerShell
Opplæring nr.27: Catalon Automation Recorder (Selen IDE Alternative)
Opplæring # 28: Geb Tool: Nettleserautomatisering ved hjelp av Geb Tool
Opplæring # 29: AutoIt: Hvordan håndtere Windows Pop-up ved hjelp av AutoIt
Opplæring # 30: Agurk: Automatisering ved hjelp av agurkverktøy og selen
Opplæring # 31: Protractor Testing Tool for End-to-End-testing av AngularJS-applikasjoner

Mobil automatiseringstesting:

Opplæring # 32: Appium Studio praktisk veiledning
Opplæring # 33: Appium-veiledning for nybegynnere
Opplæring # 34: Selendroid Tutorial: Android Mobile Automation Framework
Opplæring # 35: Ranorex Tutorial: Et kraftig verktøy for skrivebord, nett og mobil

Domenespesifikke automatiseringseksempler:

Opplæring # 36: Automatisering av JAVA / J2EE-applikasjoner

Intervjuforberedelse for automatiseringsjobber:

Opplæring # 37: Intervju spørsmål om automatiseringstesting
Opplæring # 38: Selenium Interview Questions

La oss utforske den første veiledningen fra 'The Ultimate Guide to Automation Testing' -serien !!

Hva du vil lære:

Hva er automatiseringstesting?

Hvis en programvare kan gjøre noe, hvorfor kan ikke en programvare teste en programvare?

Høres denne uttalelsen logisk ut for deg?

Hvis ja, så gratulerer, nå tenker du på Test Automation, som er midtpunktet vi skal diskutere i denne serien med informative opplæringsprogrammer.

Forestill deg deg selv n den første dagen på jobben din som SQA. Du får en søknad som skal testes. Det er et ERP-program som inneholder 100-talls skjemaer og tusenvis av rapporter. Du begynner din utforskende testing ved å åpne et skjema som inneholder rundt 50 forskjellige felt.

Du prøver å legge inn tilfeldige data i dette skjemaet som tok rundt 20 minutter. Deretter trykker du på send. Wolla !! Det vises en feilmelding som ser ut som et ubehandlet unntak. Du blir veldig glad. Du noterer stolt ned trinnene og rapporterer feilen i feilbehandlingssystemet ditt. Stor innsats, du føler deg veldig trygg og energisk. Du fortsetter testingen til dagen slutter og finner noen flere feil. “Fantastisk første dag”, tenkte du.

Nå kommer neste dag, utvikleren har løst problemet og lanserer en ny versjon av bygningen. Du tester det samme skjemaet med de samme trinnene, og du fant ut at feilen er løst. Du merker det som løst. God innsats. Du har bidratt til kvaliteten på produktet ved å identifisere den feilen, og da denne feilen er løst, forbedres kvaliteten.

Nå kommer den tredje dagen, en utvikler har igjen gitt ut en nyere versjon. Nå må du igjen teste det skjemaet for å sikre at det ikke blir funnet noe regresjonsproblem. Samme 20 minutter. Nå kjenner du deg litt lei.

Tenk deg om 1 måned fra nå av, nyere versjoner slipper stadig, og på hver utgivelse må du teste denne lange skjemaet pluss 100 andre former som dette, bare for å være sikker på at ingen regresjon er der.

Nå føler du deg sint. Du føler deg sliten . Du begynner å hoppe over trinn. Du fyller bare rundt 50% av de totale feltene. Nøyaktigheten din er ikke den samme, energien din er ikke den samme og definitivt, trinnene dine er ikke de samme.

Og en dag rapporterer klienten den samme feilen i samme form. Du føler deg patetisk. Du føler deg selvtillit nå. Du tror du ikke er kompetent nok. Ledere stiller spørsmål ved din evne.

Jeg har en nyhet til deg; dette er historien om 90% av de manuelle testerne der ute. Du er ikke annerledes.

Regresjonsproblemer er de mest smertefulle problemene. Vi er mennesker. Og vi kan ikke gjøre det samme med samme energi, hastighet og nøyaktighet hver dag. Dette er hva maskiner gjør. Dette er hva automatisering er nødvendig for å gjenta de samme trinnene med samme hastighet, nøyaktighet og energi som de ble gjentatt første gang.

Jeg håper du får poenget mitt !!

automatiseringstesting av en venn

Når en slik situasjon oppstår, bør du automatisere testsaken din. Testautomatisering er din venn . Det vil hjelpe deg å fokusere på ny funksjonalitet mens du tar vare på regresjonene. Med automatisering kan du fylle ut skjemaet på mindre enn 3 minutter.

Skriptet vil fylle alle feltene og fortelle deg resultatet sammen med skjermbilder. I tilfelle feil, kan den finne stedet hvor testsaken mislyktes, og dermed hjelpe deg med å reprodusere den uten problemer.

Automatisering - en kostnadseffektiv metode for regresjonstesting

Automasjonskostnadene er virkelig høyere i utgangspunktet. Det inkluderer kostnadene for verktøyet, deretter kostnadene for automatiseringstestressursen og hans / hennes opplæring.

Men når manusene er klare, kan de utføres hundrevis av ganger gjentatte ganger med samme nøyaktighet og ganske raskt. Dette vil spare mange timer med manuell testing. Så kostnadene synker gradvis, og til slutt blir det en kostnadseffektiv metode for Regresjonstesting .

Scenarier som krever automatisering

Ovenstående scenario er ikke det eneste tilfellet når du trenger automatiseringstesting. Det er flere situasjoner som ikke kan testes manuelt.

For eksempel ,

  1. Sammenligning av to bilder piksel for piksel.
  2. Sammenligning av to regneark som inneholder tusenvis av rader og kolonner.
  3. Testing av et program under belastning på 100 000 brukere.
  4. Ytelsesverdier.
  5. Testing av applikasjonen i forskjellige nettlesere og på forskjellige operativsystemer parallelt.

Disse situasjonene krever og bør testes av verktøy.

Så når skal man automatisere?

Dette er en æra av smidig metodikk i SDLC, hvor utvikling og testing vil gå nesten parallelt, og det er veldig vanskelig å bestemme når man skal automatisere.

Vurder følgende situasjoner før du går inn i automatisering

  • Produktet kan være i sine primitive stadier, når produktet ikke en gang har et brukergrensesnitt, på disse trinnene må vi ha en klar tanke på hva vi vil automatisere. Følgende punkter bør huskes.
    • Testene skal ikke være foreldet.
    • Etter hvert som produktet utvikler seg, bør det være enkelt å plukke på manusene og legge til det.
    • Det er veldig viktig å ikke la seg rive med og sørge for at manusene er enkle å feilsøke.
  • Ikke prøv automatisering av brukergrensesnitt i de aller første stadiene, ettersom brukergrensesnittet blir utsatt for hyppige endringer, og vil føre til at skript mislykkes. Så langt som mulig velger du API-nivå / ikke-UI-nivåautomatisering til produktet stabiliserer seg. API-automatisering er enkelt å fikse og feilsøke.

Hvordan bestemme de beste automatiseringssakene:

Automatisering er en integrert del av en testsyklus, og det er veldig viktig å bestemme hva vi vil oppnå med automatisering før vi bestemmer oss for å automatisere.

Fordelene som automatisering ser ut til å gi er veldig attraktive, men samtidig kan en dårlig organisert automatiseringspakke ødelegge hele spillet. Testere kan ende opp med å feilsøke og fikse skriptene mesteparten av tiden, noe som resulterer i tap av testtid.

Effektiv testautomatisering

Denne serien forklarer deg om hvordan en automatiseringspakke kan gjøres effektiv nok til å plukke opp de riktige testtilfellene og gi de riktige resultatene med automatiseringsskriptene vi har.

Jeg har også dekket svarene på spørsmål som Når skal man automatisere, Hva skal jeg automatisere, Hva ikke å automatisere og Hvordan strategisere automatisering.

Riktige tester for automatisering

Den beste måten å takle dette problemet på er å raskt komme med en “automatiseringsstrategi” som passer vårt produkt.

Tanken er å gruppere testsakene slik at hver gruppe vil gi oss en annen type resultat. Illustrasjonen nedenfor viser hvordan vi kunne gruppere våre lignende testtilfeller, avhengig av produktet / løsningen vi tester.

Gruppering av testtilfeller

La oss nå dykke dypt og forstå hva hver gruppe kan hjelpe oss med å oppnå:

#1) Lag en testpakke med alle grunnleggende funksjoner Positive tester . Denne suiten skal automatiseres, og når denne suiten kjøres mot en hvilken som helst versjon, vises resultatene umiddelbart. Ethvert skript som feiler i denne suiten, fører til S1- eller S2-feil, og det spesifikke bygget kan diskvalifiseres. Så vi har spart mye tid her.

Som et ekstra trinn kan vi legge til denne automatiserte testpakken som en del av BVT (Build verification tests) og sjekke QA-automatiseringsskriptene i produktbyggingsprosessen. Så når bygningen er klar, kan testere sjekke om resultatene for automatiseringstesten, og bestemme om bygningen er egnet eller ikke for installasjon og videre testprosess.

Dette oppnår klart automatiseringsmålene som er:

  • Reduser testinnsatsen.
  • Finn feil på tidligere stadier.

#to) Deretter har vi en gruppe End to End-tester .

Under store løsninger er det nøkkelen å teste en ende-til-slutt-funksjonalitet, spesielt i de kritiske stadiene av prosjektet. Vi burde ha noen få automatiseringsskripter som også berører end-to-end løsningstester. Når denne suiten kjøres, skal resultatet indikere om produktet som helhet fungerer som forventet eller ikke.

Automasjonstestpakken bør angis hvis noen av integrasjonsbitene er ødelagte. Denne suiten trenger ikke å dekke hver eneste lille funksjon / funksjonalitet i løsningen, men den skal dekke arbeidet til produktet som helhet. Hver gang vi har en alfa eller en beta eller andre mellomliggende utgivelser, så er slike skripter nyttige og gir kundene noe selvtillit.

For å forstå bedre, la oss anta at vi tester en online shopping portal , som en del av testene fra slutt til slutt, bør vi bare dekke de viktigste trinnene som er involvert.

Som gitt nedenfor:

  • Brukerinnlogging.
  • Bla gjennom og velg elementer.
  • Betalingsalternativ - dette dekker frontend-testene.
  • Administrasjon av backendordre (innebærer å kommunisere med flere integrerte partnere, sjekke lagerbeholdning, sende e-post til brukeren osv.) - dette vil hjelpe testintegrasjonen av individuelle brikker og også kjernen i produktet.

Så når et slikt skript kjøres, gir det en tillit til at løsningen som helhet fungerer bra.!

# 3) Det tredje settet er Funksjons- / funksjonsbaserte tester .

Til eksempel , Vi kan ha funksjonaliteten til å bla gjennom og velge en fil, så når vi automatiserer dette, kan vi automatisere saker for å inkludere utvalg av forskjellige typer filer, størrelser på filer osv., Slik at funksjonstesting er gjort. Når det er noen endringer / tillegg til denne funksjonaliteten, kan denne suiten tjene som en regresjonspakke.

# 4) Neste på listen ville være UI-baserte tester. Vi kan ha en annen pakke som vil teste rent brukergrensesnittbaserte funksjoner som paginering, begrensning av tekstboksen, kalenderknapp, nedtrekksbilder, grafer, bilder og mange slike UI-sentriske funksjoner. Feil i disse skriptene er vanligvis ikke veldig kritisk med mindre brukergrensesnittet er helt nede eller visse sider ikke vises som forventet!

# 5) Vi kan ha enda et sett med tester som er enkle, men veldig arbeidskrevende å utføre manuelt. Kjedelige, men enkle tester er de ideelle automatiseringskandidatene, for eksempel å legge inn detaljer om 1000 kunder i databasen har en enkel funksjonalitet, men ekstremt kjedelig å utføre manuelt, slike tester bør automatiseres. Hvis ikke, ender de opp med å bli ignorert og ikke testet.

Hva IKKE å automatisere?

Nedenfor er noen få tester som ikke bør automatiseres.

# 1) Negative tester / failover-tester

Vi bør ikke prøve å automatisere negative eller failover-tester , når det gjelder disse testene, må testerne tenke analytisk, og negative tester er ikke veldig enkle å gi et bestått eller ikke-godkjent resultat som kan hjelpe oss.

Negative tester vil trenge mye manuell inngrep for å simulere et faktisk scenario for katastrofegjenoppretting. Bare for å eksemplifisere at vi tester funksjoner som påliteligheten til webtjenester - å generalisere det her, vil hovedmålet med slike tester være å forårsake bevisste feil og se hvor godt produktet klarer å være pålitelig.

Å simulere feilene ovenfor er ikke grei, det kan innebære å injisere noen stubber eller bruke noen verktøy i mellom, og automatisering er ikke den beste måten å gå hit.

# 2) Ad hoc-tester

Disse testene er kanskje ikke relevante for et produkt til enhver tid, og dette kan til og med være noe som testeren kunne tenke seg på det stadiet av prosjektinitieringen, og også innsatsen for å automatisere en ad hoc-test må valideres mot kritikken av funksjonen som testene berører.

For eksempel , En tester som tester en funksjon som omhandler komprimering / kryptering av data, kan ha gjort intense ad-hoc-tester med en rekke data, filtyper, filstørrelser, korrupte data, en kombinasjon av data, ved hjelp av forskjellige algoritmer, på tvers av flere plattformer etc.

Når vi planlegger for automasjon Det kan være lurt å prioritere og ikke gjøre omfattende automatisering av alle ad hoc-testene for den funksjonen alene, og ende opp med litt tid til å automatisere de andre viktige funksjonene.

# 3) Tester med massiv forhåndsoppsett

Det er tester som krever enorme forutsetninger.

For eksempel, Vi kan ha et produkt som integreres med en tredjeparts programvare for noen av funksjonene, ettersom produktet integreres med et hvilket som helst meldingskøsystem som krever installasjon på et system, oppsett av køer, oppretting av køer etc.

3rdpartiprogramvare kan være hva som helst, og oppsettet kan være komplekst og hvis slike skript automatiseres, vil disse for alltid være avhengig av funksjonen / oppsettet til den tredjepartsprogramvaren.

Forutsetningen inkluderer:

For øyeblikket kan ting se enkle og rene ut siden begge sideoppsett blir gjort og alt er bra. Vi har ved flere anledninger sett at når et prosjekt går inn i vedlikeholdsfasen, blir prosjektet flyttet til et annet team, og de ender med å feilsøke slike skript der selve testen er veldig enkel, men skriptet mislykkes på grunn av en 3rdfestprogramvareproblem.

Ovennevnte er bare et eksempel, generelt, hold øye med tester som har møysommelige forhåndsinnstillinger for en enkel test som følger.

Enkelt eksempel på testautomatisering

Når du tester en programvare (på nettet eller på skrivebordet), bruker du vanligvis mus og tastatur for å utføre trinnene dine. Automatiseringsverktøy etterligner de samme trinnene ved å bruke skript eller et programmeringsspråk.

For eksempel , hvis du tester en kalkulator og testtilfellet er at du må legge til to tall og se resultatet. Skriptet vil utføre de samme trinnene ved å bruke musen og tastaturet.

programvare for å laste ned videoer fra hvilket som helst nettsted

Eksemplet er vist nedenfor.

Manuelle trinn

  1. Start kalkulator
  2. Trykk på 2
  3. Trykk på +
  4. Trykk på 3
  5. Trykk =
  6. Skjermen skal vise 5.
  7. Lukk kalkulator.

Automatiseringsskript:

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

Ovennevnte skript er bare en duplisering av de manuelle trinnene. Manuset er enkelt å lage og lett å forstå også.

Hva er påstander?

Den nest siste linjen i skriptet trenger litt mer forklaring.

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

I hvert testtilfelle har vi noen forventede eller spådde resultater på slutten. I ovenstående skript har vi en forventning om at “5” skal vises på skjermen. Det faktiske utfallet er resultatet som vises på skjermen. I hvert testtilfelle sammenligner vi forventet utfall med det faktiske utfallet.

Det samme gjelder også automatiseringstesting. Den eneste forskjellen her er, når vi gjør den sammenligningen i testautomatisering, så kalles det noe annet i hvert verktøy.

Noen verktøy kaller det som “ Påstand ”, Noen kaller det som“ kontrollpunkt ”Og noen kaller det som“ validering ”. Men i utgangspunktet er dette bare en sammenligning. Hvis denne sammenligningen mislykkes, for F.eks. en skjerm viser 15 i stedet for 5, da mislykkes dette påstanden / sjekkpunktet / valideringen, og testsaken din blir merket som mislykket.

Når en testsak mislykkes på grunn av en påstand, betyr det at du har oppdaget en feil gjennom testautomatisering. Du må rapportere det til feilbehandlingssystemet ditt, akkurat som du vanligvis gjør ved manuell testing.

I skriptet ovenfor har vi utført en påstand i nest siste linje. 5 er forventet utfall, txtResult . DisplayText er det faktiske utfallet, og hvis de ikke er like, vil vi få vist en melding om at 'Kalkulator ikke viser 5'.

Konklusjon

Ofte kommer testere over prosjektfrister og mandater for å automatisere alle sakene for å forbedre testestimatene.

Det er noen vanlige 'gale' oppfatninger om automatisering.

De er:

  • Vi kan automatisere alle testsaker.
  • Automatisering av tester vil redusere testtiden enormt.
  • Ingen feil blir introdusert hvis automatiseringsskript kjører problemfritt.

Vi bør være tydelige på at automatisering bare kan redusere testtiden for visse typer tester. Å automatisere alle testene uten plan eller sekvens vil føre til massive skript som er tungt vedlikehold, mislykkes ofte og trenger mye manuell inngrep også. Også i stadig utviklende produkter kan automatiseringsskrips bli foreldet og trenger noen konstante kontroller.

Gruppering og automatisering av de riktige kandidatene vil spare mye tid og gi alle fordelene med automatisering.

Denne utmerkede opplæringen kan oppsummeres i bare 7 poeng.

Automatiseringstesting:

  • Er testingen som gjøres programmatisk.
  • Bruker verktøyet til å kontrollere utførelsen av tester.
  • Sammenligner forventede resultater med de faktiske resultatene (Assertions).
  • Kan automatisere noen repeterende, men nødvendige oppgaver ( F.eks. Dine regresjonstesttilfeller).
  • Kan automatisere noen oppgaver som er vanskelige å gjøre manuelt (F.eks.Load testing scenarier).
  • Skript kan kjøres raskt og gjentatte ganger.
  • Er kostnadseffektivt i det lange løp.

Her forklares automatisering enkelt, men det betyr ikke at det alltid er enkelt å gjøre. Det er utfordringer, risiko og mange andre hindringer involvert i det. Det er mange måter testautomatisering kan gå galt på, men hvis alt går bra, er fordelene med testautomatisering veldig store.

Kommende i denne serien:

I de kommende opplæringene vil vi diskutere flere aspekter knyttet til automatisering.

Disse inkluderer:

  1. Typer automatiserte tester og noen misoppfatninger.
  2. Hvordan introdusere automatisering i organisasjonen din og unngå vanlige fallgruver når du gjør testautomatisering.
  3. Verktøyvalgsprosessen og sammenligning av forskjellige automatiseringsverktøy.
  4. Skriptutvikling og automatiseringsrammer med eksempler.
  5. Utførelse og rapportering av testautomatisering.
  6. Beste praksis og strategier for testautomatisering.

Er du ivrig etter å vite mer om hvert eneste konsept med automatiseringstesting? Se opp og følg med på listen vår over kommende opplæringsprogrammer i denne serien, og uttrykk gjerne tankene dine i kommentarfeltet nedenfor.

NESTE veiledning nr. 2

Anbefalt lesing

^