how choose best automation testing tool
I denne opplæringen har vi dekket kriterier for valg av testautomasjonsverktøy og sjekkliste med sammenligningsmatrise for testautomasjonsverktøy for enkel referanse.
Veiledningen A til Å om valg av det beste automatiseringsverktøyet for prosjektet ditt:
Dette er 4thopplæringen i vår Test Automation Tutorial-serie. Sjekk alle artiklene som er lagt ut i denne serien på denne siden: => Den ultimate guiden for å starte automatiseringstesting på prosjektet ditt
Valg av testautomatiseringsverktøy er et av de viktigste trinnene før du starter automatisering i noen organisasjon.
Det er viktig fordi verktøyet i stor grad vil påvirke hele automatiseringsarbeidet ditt. Hvis verktøyet er bra og gir deg nødvendige funksjoner, blir automatiseringen enklere og effektiv.
Det er mange kriterier du bør vurdere når du velger automatiseringsverktøyet. Noen av dem har jeg diskutert i en av mine tidligere artikler. Her har jeg listet opp de viktigste aspektene du bør vurdere når du velger testautomatiseringsverktøyet.
Hva du vil lære:
- Er automatisert testing en løsning for deg?
- Når gir testautomatisering mening?
- Hvordan velge automatiseringsverktøy for prosjektet ditt?
- Evalueringskriterier for testautomatiseringsverktøy
- Testkriterier og sjekkliste for valg av automatiseringsverktøy
- Spørsmål nr. 1: Hva er budsjettet til organisasjonen din for automatiseringsverktøy?
- Spørsmål nr. 2: Hva er verktøyets faktiske pris?
- Spørsmål nr. 3: Støtter verktøyet operativsystemet / nettleseren eller enheten din applikasjon kjører i?
- Spørsmål nr. 4: Støtter verktøyet teknologiene og tredjepartskontrollene som brukes i applikasjonen din?
- Spørsmål nr. 5: Hvor mange språk verktøyet støtter? Har du dyktige ressurser for disse språkene?
- Spørsmål 6: Støtter verktøyet tilkobling til forskjellige datakilder?
- Spørsmål nr. 7: Hvordan er rapporteringsmekanismen til automatiseringsverktøyet?
- Spørsmål nr. 8: Kan verktøyet integreres med testcases og bug management repositories?
- Spørsmål 9: Hvordan er offisiell teknisk støtte for verktøyet?
- Spørsmål nr. 10: Noen tekniske aspekter å se
- Konklusjon
- Anbefalt lesing
Er automatisert testing en løsning for deg?
Jeg har jobbet med mange prosjekter i karrieren min. Når du jobber med det samme prosjektet i mer enn ett år, begynner du å føle behov for å automatisere noen oppgaver. Du begynner å tenke å innføre automatiseringstesting på prosjektet hvis det ikke har blitt vurdert til nå av prosjektledelse.
Ett år er nok tid for alle å kjenne inn og ut i ethvert prosjekt. En gang du kjenner prosjektfunksjonaliteten i detalj, det blir lettere å bestemme hvilke repetitive oppgaver som må automatiseres.
Noen testere kjeder seg også gjør samme repeterende oppgaver igjen og igjen, og de begynner sterkt å føle behovet for testautomatisering.
Betyr det at du bør hoppe inn i automatiseringstesting med en gang?
Definitivt ikke!
Det er mange kriterier du må jobbe med før du bestemmer deg for om automatisering er en løsning for deg .
Når gir testautomatisering mening?
- Når det er mange repetitive tester
- Når det er hyppige regresjonstesting iterasjoner
- Når du trenger det simulere et stort antall brukere som bruker applikasjonsressursene
- Når AUT har relativt stabil brukergrensesnitt
- Når du har et stort sett med BVT-saker
- Når du ikke bare kan stole på manuell testutførelse for kritisk funksjonalitet
Videre lesning:
- Når bør du gå for automatisering?
- Tips du bør lese før du starter automatisert testing
Når du vet at det er riktig tidspunkt å investere tid og penger i et godt automatiseringsverktøy, kan du begynne å lete etter det beste automatiseringsverktøyet som passer dine behov.
Hvordan velge automatiseringsverktøy for prosjektet ditt?
Automasjonstestsuksess avhenger i stor grad av valget av riktige testverktøy. Det tar mye tid å evaluere relevante automatiseringsverktøy som er tilgjengelige i markedet. Men dette er en må engangsøvelse som vil være til fordel for prosjektet ditt i det lange løp.
Det var få situasjoner der jeg fikk sjansen til å gjennomgå og velge automatiseringsverktøy for prosjektene mine. Oppgaven var vanskelig, ettersom vi måtte håndtere testbehov og kostnadsbegrensninger, men det var en verdig opplevelse.
Her er kriteriene du må vurdere før du velger et testverktøy:
Evalueringskriterier for testautomatiseringsverktøy
1) Har du den nødvendige dyktige ressursen du kan bruke til automatiseringsoppgaver?
2) Hva er budsjettet ditt?
3) Oppfyller verktøyet testbehovet ditt? Er det egnet for prosjektmiljøet og teknologien du bruker? Støtter den alle verktøy og objekter som brukes i koden? En gang kan du bli sittende fast for små tester på grunn av verktøyets manglende evne til å identifisere gjenstandene som brukes i applikasjonen.
Jeg anser tre faktorer ovenfor som viktigst for valg av verktøy.
4) Gir verktøyet deg den gratis prøveversjonen slik at du kan evaluere den før du tar en beslutning? Har verktøyet også alle funksjonene som er tilgjengelige i prøveversjonen?
5) Er den nåværende verktøyversjonen stabil? Er leverandørselskapet etablert med god kundesupport samt online hjelpressurser og brukerhåndbok?
6) Hvordan er verktøyets læringskurve? Er læringstiden akseptabel for dine mål?
7) Vil du ha automatiseringsverktøy for bare prosjektbehovene dine, eller leter du etter et felles verktøy for alle prosjekter i bedriften din? Det ville være et godt valg hvis du velger et verktøy som støtter de fleste kodningsspråk på prosjektene dine.
sql spørsmål for praksis med svar
8) Hvilke testtyper støtter den? Et verktøy som støtter maksimale testtyper (enhet, funksjonell, regresjon osv.) Er alltid et bedre valg.Advarsel- Ikke gå etter et verktøy bare fordi det støtter alle testtyper. Det er også viktig at verktøyet skal være kraftig nok til å automatisere de komplekse kravene dine.
9) Støtter verktøyet enkelt grensesnitt for å opprette og vedlikeholde testskript? Opptaks- og avspillingsverktøy med evner til å redigere innspilte skript kan være en god løsning.
10) Tilbyr det enkelt grensesnitt, men likevel kraftige funksjoner for å utføre komplekse oppgaver?
elleve) Hvor enkelt er det å gi inngangstestdata for komplekse eller belastningstester? Et verktøy som støtter testdatainngang fra forskjellige datafiler som Excel, XML, tekstfil etc. vil være en stor lettelse for automatiseringen av testerne.
12) Gir den kraftig rapportering med grafisk grensesnitt? Tydelige og konsise rapporter vil alltid hjelpe deg med å avslutte testresultatene raskt.
1. 3) Integreres det godt med andre testverktøy som prosjektplanlegging og testhåndteringsverktøy ?
Det kan også være lurt å vurdere andre kriterier som:
14) Retningslinjer for tilbakebetaling av verktøy
femten) Eksisterende kundeanmeldelser for verktøyet
16) Gir leverandøren innledende opplæring?
Tips: Kravsamling er uten tvil det viktigste trinnet for å velge riktig verktøy. Sørg for å kategorisere dine krav i funksjoner som må ha, hyggelig å ha og ikke nødvendige funksjoner. Dette vil hjelpe deg med å evaluere verktøyet raskt. Husk at du ikke finner et verktøy som allerede er tilgjengelig i markedet som vil støtte alle dine automatiseringsbehov!
Beste automatiseringsverktøy :
HP QTP / UFT og selen er de to mest populære funksjonelle testalternativene som er tilgjengelige for øyeblikket. QTP / UFT er det beste funksjonelle testverktøyet som støttes på det brede spekteret av kodingspråk og plattformer, mens Selen er det beste funksjonelle webtestverktøyet med åpen kildekode.
Les denne artikkelen for listen over TOP-verktøy:
Topp 20 beste verktøy for automatiseringstesting i 2020 (omfattende liste)
I neste artikkel skal vi diskutere manuelle og automatiseringstestutfordringer .
Testkriterier og sjekkliste for valg av automatiseringsverktøy
10 spørsmål du må stille før du velger det beste verktøyet for automatiseringstesting
Still følgende spørsmål når du er i en situasjon for å velge automatiseringsverktøyet for organisasjonen din:
Spørsmål 1: Hva er budsjettet til organisasjonen din for automatiseringsverktøy?
Dette er, etter min mening, det viktigste du bør vurdere når du velger automatiseringsverktøyet.
Hvorfor se etter QTP / UFT og undersøke det når du ikke kan kjøpe lisensen? QTP-verktøyet koster rundt $ 8000 (ca.). Hvis organisasjonen din kan kjøpe lisensen og du blir bekreftet, bør du laste ned prøveversjonen og lage et pivotautomatiseringsprosjekt for å teste funksjonen. Ellers bør du ikke bruke tid på å undersøke det. (Jeg snakker om dette scenariet hvis du vil bruke QTP på et live-prosjekt fra selskapet. Hvis du laster ned det bare for læringsformål, er det OK å laste ned prøveversjonen.)
Spørsmål nr. 2: Hva er den faktiske prisen på verktøyet?
Neste er prisen på automatiseringsverktøyet. Det er ikke bare en lisenspris, men også prisen på tillegg (hvis nødvendig), supportavgiften, treningsavgiften og oppgraderingsgebyret.
La oss snakke om lisensen først.
a) Typer lisenser:
Det er følgende lisenser.
1) Node-Locked User License.
Den nodelåste brukerlisensen støtter testautomatiseringsverktøyet for bruk på en enkelt fysisk datamaskin i firmaets nettverk. Du kan bare kjøre en forekomst av verktøyet på den lisensierte datamaskinen om gangen. Denne lisensen er vanligvis bundet til maskinens vertsnavn.
beste gratis youtube nedlasting for pc
2) Samtidig flytende brukerlisens
En flytende brukerlisens kan deles mellom forskjellige maskiner, men kan bare brukes av en maskin om gangen. Det er ikke bundet til maskinnavn eller noe, i stedet bruker det en lisensbehandling (installert på en server) for å administrere den samme lisensen på tvers av forskjellige maskiner.
I utgangspunktet, med Node-Locked-lisensen, har du ikke frihet til å installere verktøyet på en maskin, avinstallere det og deretter installere det igjen på en hvilken som helst annen maskin. Men med flytende brukerlisens har du lov til å gjøre det.
3) Kjøretidslisens
Ovennevnte to typer lisenser kjøpes vanligvis for å 'utvikle' skriptene. Så dette er utviklingslisenser. For å utføre skriptene på forskjellige maskiner, må du ha 'utførelse' eller 'Runtime' lisens for hver maskin.
Eksempel:
For eksempel, hvis en tester trenger å utvikle og utføre testtilfeller på samme maskin, er det nok med en utviklingslisens.
Men hvis han trenger å utvikle seg på en maskin og utføre testtilfellene på tre forskjellige virtuelle eller fysiske maskiner, må han kjøpe en 'utvikling' -lisens og tre kjøretidslisenser.
Noen leverandører tilbyr gratis kjøretidslisenser (som kodet brukergrensesnitt), og noen tilbyr en pris (som Test Complete, Ranorex etc.). Så alt avhenger av leverandør til leverandør.
4) Open Source License
Det er bedriftens valg å velge et kommersielt verktøy og betale en kostnad eller velge et åpen kildekodeverktøy.
Kommersielle verktøy er dyre, men de gir god støtte og er enkle å bruke med mye opplæringsmateriell. Kommersielle verktøy er vanligvis 'ett verktøy for alle behov'. Open source-verktøy er gratis, men er generelt vanskeligere å lære. Det er lite offisiell støtte, men du kan finne løsninger ved å besøke forskjellige fora. Åpne kildeløsninger er normalt for spesifikke behov.
b) Avgift for støtte, oppgradering og opplæring:
For støtte, opplæring og et oppgraderingsgebyr, må du kanskje ringe selskapets representant. Noen selskaper tilbyr spesielle rabatter ved bulkkjøp av lisenser, så noen ganger er denne informasjonen ikke tydelig nevnt på nettsteder. Du vil bare få informasjonen via samtale eller e-post.
Spørsmål 3: Støtter verktøyet operativsystemet / nettleseren eller enheten din applikasjon kjører i?
Dette spørsmålet er normalt avhengig av typen applikasjon du bruker.
a) Hvis skrivebordsbasert:
Hvis du jobber med et skrivebordsprogram, bør du skissere det på hvor mange operativsystemer du vil teste det programmet. Jeg jobbet med et skrivebordsbasert program og ønsket å teste det på Windows 7 og Windows 8.1. Så jeg valgte Coded UI fordi det støtter begge deler.
b) Hvis nettleserbasert
Hvis du jobber med et webapplikasjon, bør du skissere det på hvor mange nettlesere du vil teste dette programmet. Jeg ønsket å utføre testsakene mine på FireFox, Chrome og IE. Jeg valgte selen for webapplikasjonen min fordi den støtter alle disse nettleserne. Forsikre deg om at verktøyet du velger skal støtte både eldre og nyere versjoner av de nødvendige nettleserne.
c) Hvis mobilbasert
Hvis du jobber med mobilapplikasjoner, bør du vite hvilke mobiloperativsystemer du har for å kjøre testsakene dine. Hvis applikasjonen din kjører på både Android og IOS, bør verktøyet ditt støtte det. Selen har separate drivere for å kjøre skript på Android, IOS, Windows Phone og BlackBerry. Du kan også bruke et eget verktøy for hvert av Mobile OS. Det er Robotium for Android, Appium for både IOS og Android og CodedUI for Windows-telefonapper.
Igjen kommer dette til debatten om åpen kildekode vs kommersiell. Som du ser er det separate open source verktøy for å teste nettbasert , mobilbasert og desktop-baserte applikasjoner. Men hvis du går etter et kommersielt verktøy som Test complete, Ranorex eller Test Studio, kan de teste alle tre typene (mobil-, desktop- og nettleserbaserte applikasjoner). Så i tilfelle det kommersielle verktøyet, trenger du å lære bare ett verktøy for å teste nett-, skrivebords- og mobilapplikasjoner.
Spørsmål nr. 4: Støtter verktøyet teknologiene og tredjepartskontrollene som brukes i applikasjonen din?
Dette er et veldig viktig aspekt når du velger verktøyet. Du bør vite førstehånds at hvilke teknologier som brukes i applikasjonen din. Rådfør deg med utviklerne og skriv disse ned. Hvis de bruker HTML 5 eller SilverLight i webapplikasjoner, vær forsiktig, det er ikke mange automatiseringsverktøy som støtter dem. Hvis verktøyet krever støtte for disse teknologiene, kan du laste ned prøveversjonen av verktøyet og prøve å identifisere forskjellige objekter i applikasjonen din. Hvis verktøyet ikke identifiserer dem, er kravet deres falskt. Den aktiviteten vil redde deg fra den etterfølgende elendigheten.
Test sammenligningsmatrise for automatiseringsverktøy:
Tabellen nedenfor sammenligner forskjellige verktøy med hensyn til lisenspris og støtte for forskjellige teknologier. (Du bør ta dette diagrammet som en læringspraksis for hvordan du kan lage sammenligninger mellom forskjellige verktøy, men nøyaktigheten til de oppgitte dataene er ikke 100%)
(Klikk på bildet for å se forstørret)
Y = Støttet, N = Støttes ikke, U = Ukjent
Spørsmål nr. 5: Hvor mange språk verktøyet støtter? Har du dyktige ressurser for disse språkene?
Å lære verktøyet er ett aspekt. Å lære språket er et annet aspekt. Hvis du har ressurser som har ekspertise innen Java, og verktøyet ditt ikke støtter Java, vil tiden til å lære det nye språket bli lagt til i automatiseringsarbeidet ditt.
hva er den beste mp3-nedlastingsappen for android
Et annet aspekt er at hvis produktet ditt er bygget på Java, må du ha et team av utviklere som er eksperter på Java. Disse utviklerne kan også hjelpe automatiseringsteamet når det gjelder språkrelaterte problemer. Det er viktig å velge verktøyet som tilbyr et språk som er kjent med ressursene dine, og det vil hjelpe deg med å minimere læringskurven for ressursene dine.
De Selen WebDriver tilbyr skriveskripter på flere språk som C #, Java, Python, Ruby og i JavaScript. TestComplete tilbyr også skriveskript på flere skriptspråk som VBScript, JScript, DelphiScript, C ++ Script og C # Script.
Spørsmål nr. 6: Støtter verktøyet tilkobling til forskjellige datakilder?
Hvis vi bruker et automatiseringsrammeverk som søkeorddrevet eller datadrevet, må vi ha muligheten til å koble verktøyet vårt til hvilken som helst datakilde. Hvis verktøyet lett gir tilkobling til forskjellige datakilder, vil det være veldig gunstig.
Se støtten for vanlige datakilder, for eksempel en CSV-fil, Excel-fil, XML-fil og database. Hvis disse er til stede i et verktøy, er du god å gå.
Spørsmål nr. 7: Hvordan er rapporteringsmekanismen til automatiseringsverktøyet?
Når vi kjører skriptet, vil det enten bestå eller mislykkes. I tilfelle passet er det ikke mye informasjon som trengs bortsett fra varighet og miljøinformasjon. Men i tilfelle feil, trenger vi en omfattende rapport om feilen. Rapporten skal fortelle oss at på hvilket trinn manuset mislykkes. Et øyeblikksbilde av øyeblikket av fiasko vil være en ekstra fordel.
Denne rapporten bør også eksporteres til forskjellige formater, slik at vi kan dele dette med interessenter. I mange verktøy er disse alternativene innebygd, og i noen verktøy er det måter å gjøre rapporten omfattende. Dette er en annen ting å se opp når du laster ned prøveversjonen av verktøyet. Hvis det gir omfattende rapporter om feil, er det best for organisasjonen.
Spørsmål 8: Kan verktøyet integreres i testcases og bug management repositories?
Det er en god sjanse for at organisasjonen din allerede bruker en testtilfelle eller bug management verktøy . Bedrifter ønsker åpenbart at deres automatiserte verktøy skal integreres med sitt eksisterende verktøy for testsaksbehandling, slik at hele applikasjonens livssyklus administreres riktig. Dette aspektet skal også sees når du velger testautomatiseringsverktøyet.
QTP støtter QLM, kodet brukergrensesnitt støtter TFS og TestComplete støtter QAComplete. Noen verktøy for åpen kildekode har også støtte som kan integreres med eksisterende verktøy for åpen kildekontrolltest. Alt avhenger av hva organisasjonen din faktisk bruker.
Spørsmål 9: Hvordan er offisiell teknisk støtte for verktøyet?
Her snakker vi bare om kommersielle verktøy. Når du velger et kommersielt verktøy, er deres støtteaspekt veldig viktig. Se opplæringsmateriellet som tilbys på nettstedet. Inneholder nettstedet videoer og opplæringsprogrammer? Har nettstedet et offisielt forum for å stille spørsmål? Last ned prøveversjonen og skyv et spørsmål på forumet og se hvor mange dager det blir besvart. Gir de støtte for en samtale?
Ovennevnte spørsmål bør virkelig stilles hver gang fordi du bruker en god sum penger på verktøyet. Hvis verktøyet ikke har god støtte, ikke gidder å kjøpe det.
Spørsmål nr. 10: Noen tekniske aspekter å se
Det er noen andre tekniske aspekter å se, så som:
a) Støtte for innspilling og avspilling
Det er ikke en anbefalt tilnærming i testautomatisering, men det er bra å ha et verktøy. Det forenkler læringsprosessen til verktøyet og hjelper enkle scenarier med å bli automatisert.
b) Ulike metoder for gjenkjenning av objekter og støtte for objektkartlegging
Det bør være en rekke valg av det samme objektet med forskjellige metoder. Noen gjenstander er vanskelige å gjenkjenne. Så forskjellige utvalgsmetoder er alltid nyttige.For eksempel, selen støtter valg av objekter etter id, navn, klasse, lenketest, XPATH , CSS-velger og JavaScript. Her er en veiledning om - hvordan QTP identifiserer objekter unikt . Hvis en valgmetode ikke fungerer, har vi en rekke andre metoder å velge mellom, som alltid er nyttig.
På samme måte bør det være et alternativ for å tilordne disse objektene riktig i objektlageret. Dette depotet skal være lett oppdaterbart og administrert. Bare for å minne deg på at Selen ikke har innebygd støtte for objektkartlegging.
c) Ulike kontrollpunkter eller påstandsstøtte.
Testsaken er bestått eller mislyktes basert på sjekkpunkter eller påstander. Hvis verktøyet har en rekke metoder for å kontrollere forventede resultater, er det gunstig. QTP har en rekke sjekkpunkter som Standard , Bitmap , Bord , XML, database og Kontroller innhold for filinnhold.
d) Håndtering av gjenopprettingsscenarier.
Hvis testsaken mislykkes, og du vil fortsette utførelsen, støtter verktøyet så lett? Hvis gjenopprettingsscenarier er enkle å administrere i et verktøy, vil det tillate deg å utføre testsaker uten feil. Du kan kjøre testsakene om natten, og om morgenen får du resultatene som sier hvilke testsaker som mislykkes og hvilke testsaker som blir bestått. Dette vil bare skje hvis gjenoppretting fra mislykkede testtilfeller lett kan håndteres av verktøyet. Ellers vil en god mengde automatiseringsinnsats bli kastet bort i håndteringen av gjenopprettingsscenarier. Se administrasjon av gjenopprettingsscenarier i QTP .
Konklusjon
Husk alltid at ingen verktøy er et godt verktøy eller dårlig verktøy. Alt avhenger av dine krav og produktets natur.
Selen kan være det mest populære automatiseringsverktøyet, men hvis produktet ditt er skrivebordsbasert, har dette verktøyet ingen nytte for deg. Forstå produktet ditt først, og søk deretter etter det riktige verktøyet som samsvarer med kravene dine ved hjelp av retningslinjene nevnt i denne opplæringen.
Riktig valg av automatiseringsverktøy spiller en viktig rolle i vellykket automatisering.
Neste opplæring - Vår neste opplæring i denne serien handler om ‘Skriptutvikling og automatiseringsrammer med eksempler’. Igjen, sjekk alle opplæringene i denne serien på denne siden .
Legg gjerne inn spørsmål / kommentarer nedenfor om valg av riktig automatiseringsverktøy.
PREV Opplæring # 3 | NESTE veiledning nr. 5
Anbefalt lesing
- Sikuli GUI Automation Testing Tool - Beginner's Guide Part # 2
- Alpha Testing og Beta Testing (En komplett guide)
- Geb Tutorial - Browser Automation Testing Using Geb Tool
- Build Verification Testing (BVT Testing) Komplett guide
- Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
- Funksjonstesting mot ikke-funksjonell testing
- Steg for trinn-guide for å implementere bevis på konsept (POC) i automatiseringstesting
- 10-trinns automatiseringstestprosess: Slik starter du automatiseringstesting i organisasjonen din