Menu

Typer af automatiseringstest og nogle misforståelser

types automation testing

Prøv Vores Instrument Til At Fjerne Problemer

Lær de forskellige typer automatiseringstest med nogle misforståelser om testautomatisering:

I denne anden del af test automatiseringsvejledningsserier , Vil jeg kort beskrive typerne af automatiserede tests, og vigtigst af alt vil jeg fjerne nogle misforståelser om testautomatisering.

Hvad er automatiseringstest?

Automatiseringstest kan defineres som en måde at køre et sæt tests igen og igen uden at skulle udføre dem manuelt. At introducere automatiseringstest i din teststrategi er en måde at spare penge og tid på.

typer automatiseringstest

Hvad du vil lære:

Typer af automatiseringstest

Typer af automatiseringstest definerer, hvilken type testsuiter der kan automatiseres. Mange testere forveksler dette emne med de typer automatiseringsrammer, der definerer, hvordan du vil designe din testpakke til en automatiseringspakke, der kan udføres bekvemt.

I denne artikel vil vi se nærmere på automatiseringstesttyperne og i sidste ende tage et kort kig på automatiseringsrammerne.

Typer af automatisering

Lad os forstå ovenstående klassifikationer i detaljer:

Automatisering baseret på typen af ​​testning

Automatisering af funktionelle tests:

hvilken enhed udfører oversættelse af netværksadresse (nat)?

Funktionelle tests er skrevet for at teste forretningslogikken bag en applikation. Automatisering af disse betyder skriveskripter for at validere den forretningslogik og den forventede funktionalitet fra applikationen.

Automatisering af ikke-funktionelle tests:

Ikke-funktionelle tests definerer applikationens ikke-forretningsmæssige krav. Dette er kravene relateret til ydeevne, sikkerhed, databaser osv. Disse krav kan forblive konstante eller kan skaleres i henhold til størrelsen på softwaren.

Automatisering baseret på testfasen

Automatisering af enhedstest:

Disse tests køres i selve udviklingsfasen, ideelt set af udvikleren efter afslutningen af ​​udviklingen, og inden systemet afleveres til testerne til test.

Automatisering af API-tests:

API-test køres i integrationsfasen. Disse kan køres af udviklings- eller testteamet og kan køres før eller efter UI-laget er bygget til applikationen. Disse tests er målrettet mod testen baseret på anmodningen og svaret, som applikationen er bygget på.

Automatisering af UI-baserede tests:

UI-baserede tests køres i løbet af testudførelsesfasen. Disse køres specifikt af testerne og køres kun én gang, før applikationsgrænsefladen overdrages til dem. Disse tester programmets funktionalitet og forretningslogik fra applikationens frontende.

Automatisering baseret på typen af ​​test

Enhedstest:

Enhedstest er de tests, der er bygget til at teste koden til en applikation og normalt er indbygget i selve koden. De målretter mod kodningsstandarderne, som hvordan metoderne og funktionerne skrives.

Disse tests er oftere skrevet af udviklerne selv, men i dagens verden kan automatiseringstestere også blive bedt om at skrive dem.

Hvis du udfører disse tests og ikke får nogen fejl fra dem, betyder det, at din kode kompileres og kører uden nogen kodeproblemer. Disse tests målretter normalt ikke de funktionelle aspekter af applikationen, og da de målretter mod kode, er det mere hensigtsmæssigt at automatisere dem, så de kan køres, når og når det kræves af udvikleren.

Røgtest:

Røgtesten er en berømt test udført i testets livscyklus. Disse er test efter byggeriet, de udføres straks efter enhver build er givet ud af applikationen for at sikre, at applikationen stadig fungerer, efter build er udført.

Dette er en lille testpakke og er noget, der vil blive udført flere gange, og dermed giver det mening at automatisere det. Disse tests vil normalt være af funktionel karakter, og afhængigt af applikationstypen kan der vælges et værktøj til dem.

API-test:

API-test er blevet meget berømt i de sidste par år. Applikationer bygget på API-arkitekturen kan udføre denne test.

I API-test validerer testerne applikationens forretningslag ved at kontrollere anmodning-svarkombinationerne for de forskellige API'er, som applikationen er bygget på. API-test kan også udføres som en del af nedenstående integrationstest.

Integrationstest:

Integrationstest, som navnet selv antyder, betyder at teste applikationen ved at integrere alle modulerne og kontrollere applikationens funktionalitet.

Integrationstest kan udføres via API-test eller kan gøres via applikationens UI-lag.

UI-tests:

UI-tests udføres fra UI-laget eller applikationens frontend. Disse kan målrette test funktionaliteten eller simpelthen teste UI-elementerne i en applikation.

Automatisering af brugergrænsefladen for at teste funktionaliteten er en almindelig praksis. At automatisere GUI-funktionerne er dog en af ​​de mere komplicerede automatiseringer.

Regressionstest:

En af de mest almindeligt automatiserede testsuiter er regressionstestpakken. Regression, som du måske allerede ved, er testen, der udføres ved afslutningen af ​​testen af ​​et nyt modul for at sikre, at ingen af ​​de eksisterende moduler er blevet påvirket af det.

Det gentages efter hver ny iteration af testning, og de vigtigste testtilfælde forbliver faste med normalt et par nye tilføjelser efter en ny iteration. Da det ofte køres, prøver næsten alle testteamene at automatisere denne pakke.

Automatisering som kontinuerlig integration:

Kontinuerlig integration kan igen køre på selve de automatiske regressionstest, men for at opnå CI muliggør vi kørsel af regression eller identificeret testpakke hver gang, når en ny implementering er udført.

Sikkerhedstest:

Sikkerhedstest kan være både funktionel såvel som en ikke-funktionel type test, der involverer test af applikationen for sårbarheder. Funktionelle tests består af tests relateret til autorisation osv., Mens ikke-funktionelle krav måske tester for SQL-injektion, scripting på tværs af steder osv.

Ydelsestest og kvalitetskontrol:

Ydelsestest er ikke-funktionelle tests, der retter sig mod kravene som test af belastning, stress, applikations skalerbarhed.

Accept test:

Acceptstest falder igen under funktionstest, som normalt udføres for at sikre, om de acceptkriterier, som klienten har givet, er opfyldt.

Indtil videre har vi beskrevet den type test, der kan automatiseres, og forskellige klassifikationer af det samme, alle klassifikationer vil i sidste ende føre til, at de samme slutresultater af en testsuite bliver automatiseret. Som vi sagde tidligere, kræves der lidt forståelse for, hvordan disse adskiller sig fra rammer.

Når du har identificeret de tests, du vil automatisere fra ovenstående klassifikation, bliver du nødt til at designe din logik på en måde, der udfører disse test problemfrit uden meget manuel indgriben. Dette design af en manuel testpakke til en automatiseret testpakke er, hvor rammerne kommer ind.

Nu vil vi udforske Top 3 testautomatiseringstyper

  1. Enhedstest
  2. API-test
  3. GUI-test

# 1) Automatiske enhedstest

mysql interview spørgsmål og svar til erfarne

Automatiserede enhedstest er skrevet for at teste kodeniveauet. Fejl identificeres i funktionerne, metoderne og rutinerne skrevet af udviklerne.

Nogle virksomheder beder udviklerne om at lave enhedstesten selv, og nogle ansætter specialiserede testautomatiseringsressourcer. Disse ressourcer har adgang til kildekode, og de skriver enhedstest for at bryde produktionskoden.

På grund af tilstedeværelsen af ​​enhedstest kører alle enhedstest, når koden kompileres, og fortæller os resultatet, at hvis al funktionalitet fungerer. Hvis en enhedstest mislykkes, betyder det, at der nu er en fejl til stede i produktionskoden.

Nogle af de mest populære værktøjer, der findes på markedet, inkluderer NUnit og JUnit . Microsoft giver også sin egen ramme for kaldet enhedstest MSTest . Gå gennem hjemmesiderne for disse værktøjer, og de giver dig flere eksempler og vejledninger i, hvordan du skriver enhedstest.

#to) Automatiseret webservice / API-test

En Application Programming Interface (API) gør det muligt for softwaren at tale med andre softwareapplikationer. Ligesom enhver anden software skal API'er testes. I denne type test er GUI normalt ikke involveret.

Hvad vi tester her er normalt funktionalitets-, overholdelses- og sikkerhedsproblemer. I webapplikationer kan vi teste anmodningen og svaret på vores applikation, hvis de er sikre og krypterede eller ej.

Dette er et af eksemplerne, hvor vi kan bruge API-test. Det mest populære værktøj til API-test er SÆBE som har både gratis og betalte versioner. Der er også andre værktøjer, som du kan bruge alt efter dit behov.

# 3) Automatiske GUI-tests.

Denne type automatiseret test er den hårdeste form for automatisering, da den involverer test af en brugergrænseflade til applikationen.

Det er hårdt, da GUI'erne er meget udsat for ændringer. Men denne type test er også tættest på, hvad brugerne vil gøre med vores applikation. Da brugeren vil bruge musen og tastaturet, efterligner automatiserede GUI-tests også den samme adfærd ved at bruge mus og tastatur til at klikke eller skrive til objekter, der findes i brugergrænsefladen.

På grund af dette kan vi finde fejl tidligt, og det kan bruges i mange scenarier såsom regressionstest eller udfyldning af formularer, der tager for meget tid.

De mest populære GUI-testværktøjer inkluderer Micro Focus Unified Functional Testing (UFT) , Selen , Test gennemført og Microsoft kodet brugergrænseflade (som er en del af Visual Studio ultimative og premium-udgaver).

Ligesom typerne af automatiseringstest er der også flere typer rammer.

Automatiseringsrammer

Nogle almindeligt anvendte automatiseringsrammer inkluderer:

  • Lineær (Optag og afspilning)
  • Søgeordsdrevet
  • Datadrevet
  • Sideobjektmodel
  • Modulær

Yderligere læsning => Automatiseringsrammer

Typer, rammer og værktøjer

Som du kan se, er det første trin i processen med automatisering at identificere typen af ​​automatisering, så kan du identificere rammen til design og holde disse i tankerne, du kan vælge de værktøjer, der passer til dine behov.

hvad er de forskellige e-mail-konti

Automatiseringsværktøjer

Baseret på den type test, du målretter mod, og den type ramme, som du måske vil bygge omkring den, er følgende værktøjer tilgængelige til brug:

  • Selen : Meget kraftfuldt værktøj til test af webapplikationer. Giver flere browsersupport.
  • Junit og Nunit: Værktøjer, der hovedsageligt bruges til enhedstest af udviklerne.
  • QTP : Fantastisk værktøj til ikke-webapplikationer og leveres med et indbygget objektopbevaringssted.
  • Sikuli: Open source-værktøj til GUI-test.
  • Sæbe UI: Værktøj til API-test.
  • Stol trygt på: Bibliotek for at oprette en API-testramme.
  • appium : Værktøj, der understøtter mobil test, native app test, hybrid og mobil web applikation test.
  • Jmeter : Et værktøj, der bruges til præstationstest.
  • TestNG: TestNG er ikke et automatiseringsværktøj i sig selv, men det giver stor støtte til automatiseringsrammer bygget med selen, appium, vær sikker osv.

Yderligere læsning => Test automatiseringsværktøjer

Misforståelser om automatiseringstest

I årenes løb har jeg hørt nogle misforståelser om testautomatisering. Jeg synes, jeg også burde rydde dem i denne artikel.

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

Testautomatisering er til at hjælpe testere med at gøre test hurtigere og på en meget pålidelig måde. Det kan aldrig erstatte mennesker.

Tænk på testautomatisering som en bil. Hvis du går, tager det cirka 20 minutter at nå dit hjem. Men hvis du bruger en bil, når du om to minutter. Føreren af ​​bilen er stadig dig, et menneske, men .. bilen hjælper mennesket med at nå sit / hendes mål hurtigere. Også det meste af din energi spares, da du ikke gik. Således kan du bruge denne energi til at udføre vigtigere ting.

Det samme gælder for automatiseringstest. Du bruger den til hurtigt at teste de fleste af dine gentagne, lange og kedelige tests og spare din tid og energi til at fokusere og teste ny og vigtig funktionalitet.

Som James Bach sagde et vidunderligt citat:

”Værktøjer tester ikke. Kun mennesker tester. Værktøjer udfører kun handlinger, der “hjælper” folk med at teste. “

Værktøjer kan klikke på objekter. Men hvor man skal klikke vil altid blive fortalt af en manuel tester. Jeg tror, ​​du får min pointe nu.

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

Hvis du prøver at automatisere 100% af dine testsager, vil du måske være i stand til at gøre det, men hvis du kunne gøre det, bliver vores første punkt falsk. Hvis alt er automatiseret, hvad skal en manuel tester så gøre?

Forvirret? Ret?

Faktisk er pointen, at du ikke kan automatisere 100% af dine testsager. Fordi vi som testere mener, at ingen applikationer kan testes 100%. Der vil altid være nogle scenarier, som vi vil gå glip af. Der vil altid være fejl, der kun kommer, når din applikation vil blive brugt af klienterne.

Hvis applikationen ikke kan testes 100%, hvordan kan du så love 100% automatisering?

Der er også en meget tynd chance for, at du vil være i stand til at automatisere alle dine eksisterende testsager. Der er altid scenarier, som er vanskelige at automatisere og lettere at gøre manuelt.

For eksempel , En bruger vil indtaste dataene, den anden bruger vil godkende dataene, den tredje bruger vil se dataene, og den fjerde bruger er forbudt at se dataene. Disse scenarier kan automatiseres, men de tager meget tid og kræfter. Så det bliver lettere, hvis du bare gør det manuelt.

Husk, vi bruger biler til at gå afstande, men der kan være lange signaler på vej, der vil være brændstofforbrug, der vil være problemer med parkeringsplads, parkeringsafgifter og meget mere hovedpine. I nogle scenarier går vi bare og når vores destination :) .

Således skal du ikke prøve at automatisere alt. Automatiser kun de scenarier, der er vigtige, og dem, der tager meget tid at gøre manuelt.

Misforståelse # 3 . Automatisering involverer kun optagelse og afspilning.

Du må ikke leve i en fantasiverden. Denne fantasi er faktisk skabt af falske reklamer fra forskellige leverandører af automatiseringsværktøjer. De siger, at du bare optager og afspiller dine trin, så bliver dine testcases automatiseret. Nå, det er en stor løgn!

Automatisering er alt og ikke kun optagelse og afspilning. Ren automatiseringsingeniører bruger normalt slet ikke optagelses- og afspilningsfunktion. Optagelse og afspilning bruges generelt til at få en idé om, hvordan værktøjet genererer et script til vores trin.

Når vi først har lært scriptingen at kende, bruger vi altid scripting til at oprette automatiserede tests. Husk, du skal kende programmering, hvis du vil lave testautomatisering . På den anden side skal du ikke være uheldig, hvis du ikke kender programmering. Ligesom enhver anden opgave kan programmering også læres med praksis og dedikation.

Jeg kender mennesker, der ikke engang har en datalogisk baggrund, men de lærer at programmere, og nu er de fantastiske automatiseringsingeniører. Hos Microsoft ansætter de testere, der kan lave programmering. De kaldes SDET (Softwareudviklingsingeniører til test). Den første linje i jobbeskrivelsen siger 'SDET'er skriver meget kode ...'.

Lær at programmere, ikke løbe væk fra det. Det vil gøre dig til en fantastisk tester .

Konklusion

Jeg håber, at denne artikel ville have hjulpet dig med at rydde nogle begreber relateret til testautomatisering.

Vi har dækket et højt niveau af forskellige typer automatiseringstest med forskellige måder at klassificere.

De vigtigste klassifikationer inkluderer:

  • Automatisering baseret på type test (funktionel eller ikke-funktionel).
  • Automatisering baseret på testfasen (Unit, API eller UI).
  • Automatisering baseret på de forskellige testtyper (Multiple testing types).

Vi har også angivet de forskellige værktøjer, der kan bruges til disse typer automatiseret test.

I vores kommende artikel vil vi diskutere trin for trin procedure af hvordan man starter testautomatisering i din organisation .

PREV Tutorial # 1 | NÆSTE vejledning # 3

Anbefalet læsning

^