Meny

Typer av automatiseringstesting og noen misoppfatninger

types automation testing

Prøv Instrumentet Vårt For Å Eliminere Problemer

Lær de forskjellige typene av automatiseringstesting med noen misforståelser om testautomatisering:

I denne andre delen av test automatiseringsveiledningsserier , Vil jeg kort beskrive hvilke typer automatiserte tester, og viktigst av alt vil jeg fjerne noen misforståelser om testautomatisering.

Hva er automatiseringstesting?

Automatiseringstesting kan defineres som en måte å kjøre et sett med tester om og om igjen uten å måtte utføre dem manuelt. Å introdusere automatiseringstester i teststrategien din er en måte å spare penger og tid.

typer automatiseringstesting

Hva du vil lære:

Typer av automatiseringstesting

Typer av automatiseringstester definerer hva slags testsuiter som kan automatiseres. Mange testere forveksler dette emnet med typene automatiseringsrammer som definerer hvordan du skal designe testpakken din til en automatiseringspakke som kan utføres på en praktisk måte.

I denne artikkelen vil vi se nærmere på typene Automasjonstesting og til slutt ta en kort titt på automatiseringsrammene.

Typer av automatisering

La oss forstå klassifiseringene ovenfor i detalj:

Automatisering basert på type testing

Automatisering av funksjonelle tester:

Funksjonstester skrives for å teste forretningslogikken bak en applikasjon. Automatisering av disse betyr skriveskriptene for å validere forretningslogikken og funksjonaliteten som forventes av applikasjonen.

Automatisering av ikke-funksjonelle tester:

Ikke-funksjonelle tester definerer applikasjonens ikke-forretningsmessige krav. Dette er kravene knyttet til ytelse, sikkerhet, databaser osv. Disse kravene kan forbli konstante eller kan skaleres i henhold til størrelsen på programvaren.

Automatisering basert på testfasen

Automatisering av enhetstester:

Disse testene kjøres under selve utviklingsfasen, ideelt sett av utvikleren etter fullført utvikling og før de overleverer systemet til testerne for testing.

Automatisering av API-tester:

API-tester kjøres i løpet av integrasjonsfasen. Disse kan kjøres av utviklings- eller testteamet og kan kjøres før eller etter at brukergrensesnittlaget er bygget for applikasjonen. Disse testene retter seg mot testingen basert på forespørselen og svaret som applikasjonen er bygget på.

Automatisering av UI-baserte tester:

UI-baserte tester kjøres i løpet av testutførelsesfasen. Disse kjøres spesifikt av testerne og kjøres bare én gang før brukergrensesnittet til applikasjonen blir overlevert til dem. Disse tester funksjonaliteten og forretningslogikken til applikasjonen fra frontenden av applikasjonen.

Automatisering basert på type tester

Enhetstester:

hva er den beste databaseprogramvaren

Enhetstester er testene som er bygget for å teste koden til et program, og er vanligvis innebygd i selve koden. De retter seg mot kodingsstandardene som hvordan metodene og funksjonene skrives.

Disse testene er oftere skrevet av utviklerne selv, men i dagens verden kan automatiseringstestere også bli bedt om å skrive dem.

Å utføre disse testene og ikke få feil fra dem vil bety at koden din kompileres og kjøres uten kodeproblemer. Disse testene retter seg vanligvis ikke mot de funksjonelle aspektene ved applikasjonen, og ettersom de målretter mot kode, er det mer hensiktsmessig å automatisere dem slik at de kan kjøres når og når utvikleren krever det.

Røykprøver:

Røykprøven er en kjent test utført i testens livssyklus. Dette er tester etter bygging, de blir utført umiddelbart etter at alle bygg er gitt ut av applikasjonen for å sikre at applikasjonen fortsatt fungerer etter at bygningen er gjort.

Dette er en liten testpakke og er noe som vil bli utført flere ganger, og dermed er det fornuftig å automatisere den. Disse testene vil vanligvis være av funksjonell karakter, og avhengig av type applikasjon kan et verktøy velges for dem.

API-tester:

API-testing har blitt veldig kjent de siste årene. Applikasjoner bygget på API-arkitekturen kan utføre denne testen.

I API-testing validerer testerne forretningslaget til applikasjonen ved å sjekke kombinasjonene forespørsel og respons for de forskjellige API-ene som applikasjonen er bygget på. API-tester kan også gjøres som en del av integrasjonstestene nedenfor.

Integrasjonstester:

Integrasjonstest som navnet antyder, betyr å teste applikasjonen ved å integrere alle modulene og sjekke funksjonaliteten til applikasjonen.

Integrasjonstesting kan gjøres gjennom API-testing eller kan gjøres gjennom UI-laget i applikasjonen.

UI-tester:

UI-tester gjøres fra UI-laget eller frontend av applikasjonen. Disse kan målrette testfunksjonaliteten eller bare teste UI-elementene i en applikasjon.

Å automatisere brukergrensesnittet for å teste funksjonaliteten er en vanlig praksis. Å automatisere GUI-funksjonene er imidlertid en av de mer kompliserte automatiseringene.

Regresjonstester:

En av de vanligste automatiserte testsuitene er regresjonstestpakken. Regresjon, som du kanskje allerede vet, er testen som gjøres på slutten av testing av en ny modul for å sikre at ingen av de eksisterende modulene har blitt berørt av den.

Det gjentas etter hver nye iterasjon av testing, og hovedtesttilfellene holder seg fast med vanligvis noen få nye tillegg etter en ny iterasjon. Siden det ofte kjøres, prøver nesten alle testteamene å automatisere denne pakken.

Automatisering som kontinuerlig integrasjon:

Kontinuerlig integrering kan igjen kjøre på de automatiserte regresjonstestene, men for å oppnå CI, gjør vi det mulig å kjøre regresjonen eller den identifiserte testpakken hver gang en ny distribusjon er gjort.

Sikkerhetstester:

Sikkerhetstesting kan være både funksjonell og ikke-funksjonell type testing som involverer testing av applikasjonen for sårbarheter. Funksjonelle tester vil komponere tester relatert til autorisasjon etc., mens ikke-funksjonelle krav kan teste for SQL-injeksjon, skripting på tvers, etc.

Ytelsestester og kvalitetskontroll:

Ytelsestester er ikke-funksjonelle tester som retter seg mot kravene som testing av belastning, stress, skalerbarhet i applikasjonen.

Akseptprøver:

Akseptstester faller igjen under funksjonstester som vanligvis gjøres for å sikre om akseptkriteriene gitt av klienten er oppfylt.

Så langt har vi beskrevet typen tester som kan automatiseres og forskjellige klassifiseringer av det samme, alle klassifiseringer vil til slutt føre til at de samme sluttresultatene til en testpakke blir automatisert. Som vi sa tidligere, kreves det litt forståelse for hvordan disse er forskjellige fra rammer.

Når du har identifisert testene du vil automatisere fra klassifiseringen ovenfor, må du designe logikken din på en måte å utføre disse testene jevnt, uten mye manuell inngrep. Denne utformingen av en manuell testpakke til en automatisert testpakke er hvor rammene kommer inn.

Nå skal vi utforske topp 3 testautomatiseringstyper

  1. Enhetstesting
  2. API-testing
  3. GUI-testing

#1) Automatiserte enhetstester

Automatiserte enhetstester er skrevet for å teste kodenivået. Feil identifiseres i funksjonene, metodene og rutinene som er skrevet av utviklerne.

Noen selskaper ber utviklerne om å gjøre enhetstesten selv, og noen ansetter spesialiserte testautomatiseringsressurser. Disse ressursene har tilgang til kildekoden og de skriver enhetstester for å bryte produksjonskoden.

På grunn av tilstedeværelsen av enhetstester, når koden kompileres, kjører alle enhetstester og forteller oss resultatet at hvis all funksjonaliteten fungerer. Hvis en enhetstest mislykkes, betyr det at det nå er en feil i produksjonskoden.

Noen av de mest populære verktøyene som finnes i markedet inkluderer NUnit og JUnit . Microsoft gir også sitt eget rammeverk for enhetstesting kalt MSTest . Gå gjennom nettstedene til disse verktøyene, og de vil gi deg flere eksempler og veiledninger om hvordan du skriver enhetstester.

#to) Automatiserte Web Service / API-tester

Et applikasjonsprogrammeringsgrensesnitt (API) gjør det mulig for programvaren å snakke med andre programvareapplikasjoner. Akkurat som annen programvare, må API-er testes. I denne typen testing er GUI vanligvis ikke involvert.

Det vi tester her er vanligvis funksjonalitet, samsvar og sikkerhetsproblemer. I webapplikasjoner kan vi teste forespørselen og svaret fra applikasjonen vår om de er sikre og krypterte eller ikke.

Dette er et av eksemplene der vi kan bruke API-testing. Det mest populære verktøyet for API-testing er SÅPE som har både gratis og betalte versjoner. Det er også andre verktøy som du kan bruke i henhold til ditt behov.

# 3) Automatiserte GUI-tester.

Denne typen automatisert testing er den tøffeste formen for automatisering, da den innebærer testing av et brukergrensesnitt for applikasjonen.

hvordan åpne dat-fil på iPhone

Det er tøft, ettersom GUI-ene er svært utsatt for endringer. Men denne typen testing er også nærmest hva brukerne vil gjøre med applikasjonen vår. Siden brukeren bruker musen og tastaturet, etterligner automatiserte GUI-tester også den samme oppførselen ved å bruke mus og tastatur til å klikke eller skrive til objekter som finnes i brukergrensesnittet.

På grunn av dette kan vi finne feil tidlig, og det kan brukes i mange scenarier som regresjonstesting eller å fylle ut skjemaer som tar for lang tid.

De mest populære GUI-testverktøyene inkluderer Micro Focus Unified Functional Testing (UFT) , Selen , Testen er fullført og Microsoft kodet brukergrensesnitt (som er en del av Visual Studio ultimate og premium-utgaver).

Akkurat som typene automatiseringstester, er det også flere typer rammer.

Automatiseringsrammer

Noen vanlige automatiseringsrammer inkluderer:

  • Lineær (innspilling og avspilling)
  • Søkeorddrevet
  • Data drevet
  • Sideobjektmodell
  • Modulær

Videre lesing => Automatiseringsrammer

Typer, rammeverk og verktøy

Som du kan se er det første trinnet i automatiseringsprosessen å identifisere typen automatisering, så kan du identifisere rammeverket for å designe og holde disse i bakhodet. Du kan velge verktøyene som passer dine behov.

Automatiseringsverktøy

Basert på typen testing du målretter mot og typen rammeverk du kanskje vil bygge rundt den, er følgende verktøy tilgjengelige for bruk:

  • Selen : Veldig kraftig verktøy for testing av webapplikasjoner. Gir flere nettleserstøtter.
  • Junit og Nunit: Verktøy som hovedsakelig brukes til enhetstesting av utviklerne.
  • QTP : Flott verktøy for ikke-webapplikasjoner og kommer med et innebygd objektlager.
  • Sikuli: Åpen kildekodeverktøy for GUI-testing.
  • Såpe UI: Verktøy for API-testing.
  • Vær trygg: Bibliotek for å lage et API-testrammeverk.
  • appium : Verktøy som støtter mobil testing, native app testing, hybrid og mobil web applikasjon testing.
  • Jmeter : Et verktøy som brukes til ytelsestester.
  • TestNG: TestNG er ikke et automatiseringsverktøy i seg selv, men det gir god støtte til automatiseringsrammer bygget med selen, appium, vær trygg osv.

Videre lesing => Test automatiseringsverktøy

Misforståelser om automatiseringstesting

Gjennom årene har jeg hørt noen misforståelser om testautomatisering. Jeg tror jeg burde fjerne dem også i denne artikkelen.

Misforståelse nr. 1. Automatisering er her for å erstatte manuelle testere.

Testautomatisering er for å hjelpe testere å gjøre test raskere og på en mye pålitelig måte. Det kan aldri erstatte mennesker.

Tenk på testautomatisering som en bil. Hvis du går, vil det ta rundt 20 minutter å komme til hjemmet ditt. Men hvis du bruker bil, vil du nå i løpet av to minutter. Føreren av bilen er fremdeles du, et menneske, men .. bilen hjelper mennesket med å oppnå sitt mål raskere. Dessuten spares det meste av energien din, ettersom du ikke gikk. Dermed kan du bruke denne energien til å utføre viktigere ting.

Det samme gjelder automatiseringstesting. Du bruker den til raskt å teste de fleste av dine gjentatte, lange og kjedelige tester og spare tid og energi til å fokusere og teste ny og viktig funksjonalitet.

Som James Bach sa et fantastisk sitat:

“Verktøy tester ikke. Bare folk tester. Verktøy utfører bare handlinger som 'hjelper' folk med å teste. “

Verktøy kan klikke på objekter. Men hvor du klikker vil alltid bli fortalt av en manuell tester. Jeg tror du forstår poenget mitt nå.

hvordan du starter en .jar-fil

Misforståelse nr. 2 . Alt under solen kan automatiseres

Hvis du prøver å automatisere 100% av testsakene dine, vil du kanskje kunne gjøre det, men hvis du kan gjøre det, blir vårt første poeng usant. Hvis alt er automatisert, hva vil en manuell tester gjøre?

Forvirret? Ikke sant?

Egentlig er poenget at du ikke kan automatisere 100% av testsakene dine. Fordi vi som testere mener at ingen applikasjoner kan testes 100%. Det vil alltid være noen scenarier som vi vil savne. Det vil alltid være feil som bare kommer når applikasjonen din vil bli brukt av klientene.

Hvis applikasjonen ikke kan testes 100%, hvordan kan du da love 100% automatisering?

Det er også en veldig tynn sjanse for at du vil kunne automatisere alle dine eksisterende testtilfeller. Det er alltid scenarier som er vanskelige å automatisere og som er lettere å gjøre manuelt.

For eksempel , En bruker vil legge inn dataene, den andre brukeren vil godkjenne dataene, den tredje brukeren vil se dataene og den fjerde brukeren er forbudt å se dataene. Disse scenariene kan automatiseres, men de tar mye tid og krefter. Så det blir lettere hvis du bare gjør det manuelt.

Husk at vi bruker biler for å gå til avstander, men det kan være lange signaler på vei, det vil være drivstofforbruk, det vil være problemer med parkeringsplass, parkeringsavgifter og mye mer hodepine. I noen scenarier går vi bare og når målet vårt :) .

Dermed bør du ikke prøve å automatisere alt. Bare automatiser de scenariene som er viktige og de som tar mye tid å gjøre manuelt.

Misforståelse # 3 . Automatisering innebærer bare opptak og avspilling.

Ikke vær i en fantasiverden. Denne fantasien er faktisk skapt av falske annonser fra forskjellige leverandører av automatiseringsverktøy. De sier at du bare tar opp og spiller av trinnene dine, og testtilfellene dine blir automatisert. Vel, det er en stor løgn!

Automatisering er alt og ikke bare innspilling og avspilling. Rene automatiseringsingeniører bruker normalt ikke opptaks- og avspillingsfunksjonen i det hele tatt. Opptak og avspilling brukes vanligvis for å få en ide om hvordan verktøyet genererer et skript for trinnene våre.

Når vi blir kjent med skriptingen, bruker vi alltid skripting for å lage automatiserte tester. Huske, du må kjenne programmering hvis du vil gjøre testautomatisering . På den annen side, ikke bli dis-hearted hvis du ikke kjenner programmering. På samme måte som alle andre oppgaver, kan programmering også læres med øvelse og dedikasjon.

Jeg kjenner mennesker som ikke en gang har en informatisk bakgrunn, men de lærer å programmere, og nå er de fantastiske automatiseringsingeniører. Hos Microsoft ansetter de testere som kan gjøre programmering. De kalles SDET (Programvareutviklingsingeniører for test). Den første linjen i jobbbeskrivelsen sier “SDET’er skriver mye kode….”.

Lær å programmere, ikke løp vekk fra det. Det vil gjøre deg til en fantastisk tester .

Konklusjon

Jeg håper denne artikkelen ville ha hjulpet deg med å fjerne noen konsepter relatert til testautomatisering.

Vi har dekket et høyt nivå av forskjellige typer automatiseringstesting, med forskjellige måter å klassifisere på.

Hovedklassifiseringene inkluderer:

  • Automatisering basert på type testing (funksjonell eller ikke-funksjonell).
  • Automatisering basert på testfasen (Unit, API eller UI).
  • Automatisering basert på de forskjellige typene tester (Multiple testing types).

Vi har også listet opp de forskjellige verktøyene som kan brukes til denne typen automatiserte tester.

I vår kommende artikkel vil vi diskutere trinnvis prosedyre av hvordan du starter testautomatisering i organisasjonen din .

PREV Opplæring # 1 | NESTE veiledning nr. 3

Anbefalt lesing

^