how choose best automation testing tool
I denne vejledning har vi dækket kriterier for valg af testautomationsværktøj og tjekliste med sammenligningsmatrix for testautomationsværktøjer til din nemme reference.
A til Z-vejledningen om valg af det bedste automatiseringsværktøj til dit projekt:
Dette er 4thtutorial i vores Test Automation Tutorial-serie. Kontroller alle artikler, der er indsendt i denne serie på denne side: => Den ultimative guide til start af automatiseringstest på dit projekt
Valg af testautomatiseringsværktøj er et af de vigtigste trin inden automatisering i enhver organisation.
Det er vigtigt, fordi værktøjet i høj grad vil påvirke hele din automatiseringsindsats. Hvis værktøjet er godt og giver dig de nødvendige funktioner, bliver automatiseringen lettere og effektiv.
Der er mange kriterier, du skal overveje, når du vælger automatiseringsværktøjet. Nogle af dem har jeg diskuteret i en af mine tidligere artikler. Her har jeg listet de vigtigste aspekter, der skal overvejes, mens jeg vælger testautomatiseringsværktøjet.
Hvad du lærer:
- Er automatiseret test en løsning for dig?
- Hvornår giver automatisering af test mening?
- Hvordan vælges automatiseringsværktøjet til dit projekt?
- Testautomatiseringsværktøjs evalueringskriterier
- Testkriterier og tjekliste til valg af automatiseringsværktøj
- Spørgsmål nr. 1: Hvad er budgettet for din organisation til automatiseringsværktøj?
- Spørgsmål nr. 2: Hvad er den aktuelle pris på værktøjet?
- Spørgsmål nr. 3: Understøtter værktøjet operativsystemet / browseren eller den enhed, som din applikation kører i?
- Spørgsmål nr. 4: Understøtter værktøjet de teknologier og tredjepartskontroller, der bruges i din applikation?
- Spørgsmål nr. 5: Hvor mange sprog understøtter værktøjet? Har du dygtige ressourcer til disse sprog?
- Spørgsmål nr. 6: Understøtter værktøjet tilslutning til forskellige datakilder?
- Spørgsmål nr. 7: Hvordan er rapporteringsmekanismen for automatiseringsværktøjet?
- Spørgsmål nr. 8: Kan værktøjet integreres med testcases og bug management repositories?
- Spørgsmål nr. 9: Hvordan er officiel teknisk support til værktøjet?
- Spørgsmål nr. 10: Nogle tekniske aspekter at se
- Konklusion
- Anbefalet læsning
Er automatiseret test en løsning for dig?
Jeg har arbejdet med mange projekter i min karriere. Når du arbejder på det samme projekt i mere end et år, begynder du stærkt at føle et behov for automatisering af nogle opgaver. Du begynder at tænke på at indføre automatiseringstest på projektet, hvis det hidtil ikke er blevet overvejet af projektledelsen.
Et år er tid nok til at nogen kender ind og ud i ethvert projekt. Enkelt gang du kender projektets funktionalitet i detaljer, det bliver lettere at beslutte, hvilke gentagne opgaver der skal automatiseres.
Nogle testere keder sig også gør de samme gentagne opgaver igen og igen, og de begynder stærkt at føle behovet for testautomatisering.
Betyder det, at du skal springe ind i automatiseringstest med det samme?
Absolut ikke!
Der er mange kriterier, du skal arbejde på, før du beslutter, om automatisering er en løsning for dig .
Hvornår giver automatisering af test mening?
- Når der er mange gentagne tests
- Når der er hyppige regressionstest iterationer
- Når du har brug for det simulere et stort antal brugere der bruger applikationsressourcerne
- Når AUT har forholdsvis stabil brugergrænseflade
- Når du har et stort sæt BVT-sager
- Når du ikke kun kan stole på manuel testudførelse for kritisk funktionalitet
Yderligere læsning:
- Hvornår skal du gå til automatisering?
- Tip, du læser, bør før du starter automatiseret test
Når du først ved, at det er det rigtige tidspunkt at investere din tid og penge i et godt automatiseringsværktøj, kan du begynde at lede efter det bedste automatiseringsværktøj, der passer til dine behov.
Hvordan vælges automatiseringsværktøjet til dit projekt?
Automatiseringstests succes afhænger stort set af valget af de rigtige testværktøjer. Det tager meget tid at evaluere relevante automatiseringsværktøjer, der er tilgængelige på markedet. Men dette er en must engangsøvelse, der vil gavne dit projekt i det lange løb.
Der var få situationer, hvor jeg fik chancen for at gennemgå og vælge automatiseringsværktøj til mine projekter. Opgaven var vanskelig, da vi var nødt til at styre vores testbehov og omkostningsbegrænsninger, men det var en værd oplevelse.
Her er de kriterier, du skal overveje, før du vælger et testværktøj:
Testautomatiseringsværktøjs evalueringskriterier
1) Har du den nødvendige dygtige ressource til at afsætte til automatiseringsopgaver?
2) Hvad er dit budget?
3) Opfylder værktøjet dine testbehov? Er det egnet til det projektmiljø og teknologi, du bruger? Understøtter det alle værktøjer og objekter, der bruges i koden? Engang kan du sidde fast i små tests på grund af værktøjets manglende evne til at identificere de objekter, der bruges i applikationen.
Jeg anser ovenstående tre faktorer for at være vigtigst for valg af ethvert værktøj.
4) Tilbyder værktøjet dig den gratis prøveversion, så du kan evaluere den, før du træffer en beslutning? Har værktøjet også alle tilgængelige funktioner i prøveversionen?
5) Er den aktuelle værktøjsversion stabil? Er leverandørfirmaet etableret med god kundesupport samt onlinehjælpsressourcer og brugervejledning?
6) Hvordan er værktøjets indlæringskurve? Er læringstiden acceptabel for dine mål?
7) Ønsker du automatiseringsværktøj til kun dine projektbehov, eller leder du efter et fælles værktøj til alle projekter i din virksomhed? Det ville være et godt valg, hvis du vælger et værktøj, der understøtter de fleste kodningssprog på dine projekter.
qa test interview spørgsmål og svar til erfarne
8) Hvilke testtyper understøtter den? Et værktøj, der understøtter maksimale testtyper (enhed, funktionel, regression osv.), Er altid et bedre valg.Advarsel- Gå ikke efter et værktøj, bare fordi det understøtter alle testtyper. Det er også vigtigt, at værktøjet skal være kraftigt nok til at automatisere dine komplekse krav.
9) Understøtter værktøjet let interface til at oprette og vedligeholde testskripter? Optagelses- og afspilningsværktøj med evner til at redigere indspillede scripts kan være en god løsning.
10) Tilbyder det en simpel grænseflade, men alligevel stærke funktioner til at udføre komplekse opgaver?
elleve) Hvor let er det at levere input-testdata til komplekse test eller belastningstest? Et værktøj, der understøtter testdatainput fra forskellige datafiler, såsom Excel, XML, tekstfil osv., Ville være en stor lettelse for automatiseringen af testerne.
12) Tilbyder det den effektive rapportering med grafisk grænseflade? Klare og koncise rapporter hjælper dig altid med at afslutte testresultaterne hurtigt.
13) Integrerer det godt med dine andre testværktøjer som projektplanlægning og test management værktøjer ?
Du kan også overveje andre kriterier som:
14) Politik til tilbagebetaling af værktøjsleverandør
femten) Eksisterende kundeanmeldelser for værktøjet
16) Tilbyder sælgeren grunduddannelse?
Tips: Kravindsamling er langt det vigtigste skridt til at vælge det rigtige værktøj. Sørg for at kategorisere dine krav i must have, nice to have og ikke krævede funktionskategorier. Dette hjælper dig med hurtigt at evaluere værktøjet. Husk, at du ikke finder et værktøj, der allerede er tilgængeligt på markedet, der understøtter alle dine automatiseringsbehov!
Bedste automatiseringsværktøjer :
HP QTP / UFT og selen er de to mest populære funktionelle testmuligheder, der er tilgængelige i øjeblikket. QTP / UFT er et bedste funktionelle testværktøj, der understøttes på den brede vifte af kodningssprog og -platforme, mens Selen er det bedste open source-funktionelle webtestværktøj.
Læs denne artikel for listen over TOP-værktøjer:
Top 20 bedste værktøjer til automatiseringstest i 2020 (omfattende liste)
I næste artikel vil vi diskutere manuelle og automatiseringstestudfordringer .
Testkriterier og tjekliste til valg af automatiseringsværktøj
10 spørgsmål, du skal stille, inden du vælger det bedste værktøj til automatiseringstest
Stil følgende spørgsmål, når du er i en situation for at vælge automatiseringsværktøjet til din organisation:
Spørgsmål 1: Hvad er budgettet for din organisation til automatiseringsværktøj?
Dette er efter min mening den vigtigste ting, du skal overveje, når du vælger automatiseringsværktøjet.
Hvorfor kigge efter QTP / UFT og undersøge det, når du ikke kan købe licensen? QTP-værktøjet koster omkring $ 8000 (ca.). Hvis din organisation kan købe licensen, og du bliver bekræftet, skal du downloade prøveversionen og lave et drejeautomatiseringsprojekt på den for at teste dens funktion. Ellers skal du ikke bruge tid på at undersøge det. (Jeg taler om dette scenarie, hvis du vil bruge QTP på et live-projekt fra virksomheden. Hvis du downloader det kun til læringsformål, er det OK at downloade prøveversionen.)
Spørgsmål nr. 2: Hvad er værktøjets faktiske pris?
Dernæst er prisen på automatiseringsværktøjet. Der er ikke kun en licenspris, men også prisen på tilføjelser (hvis nødvendigt), supportgebyret, træningsgebyret og opgraderingsgebyret.
Lad os først tale om licensen.
vægtet graf tilstødelsesliste c ++
a) Typer af licenser:
Der er følgende typer licenser.
1) Node-låst brugerlicens.
Den nodelåste brugerlicens understøtter testautomatiseringsværktøjet til brug på en enkelt fysisk computer i dit virksomheds netværk. Du kan kun køre en forekomst af værktøjet på den licenserede computer ad gangen. Denne licens er normalt bundet til maskinens værtsnavn.
2) Samtidig flydende brugerlicens
En flydende brugerlicens kan deles mellem forskellige maskiner, men kan kun bruges af en maskine ad gangen. Det er ikke bundet til maskinnavnet eller noget, i stedet bruger det en licensadministrator (installeret på en server) til at administrere den samme licens på tværs af forskellige maskiner.
Grundlæggende har du ikke den nodelåste licens til at installere værktøjet på en maskine, afinstallere det og derefter installere det igen på enhver anden maskine. Men med flydende brugerlicens har du lov til at gøre det.
3) Kørselstid licens
Ovennævnte to typer licenser købes normalt for at 'udvikle' scripts. Så dette er 'udviklings' -licenser. For at udføre scripts på forskellige maskiner, skal du have 'udførelse' eller 'Runtime' licens for hver maskine.
Eksempel:
For eksempel, hvis en tester har brug for at udvikle og udføre testsager på den samme maskine, så er en udviklingslicens nok.
Men hvis han har brug for at udvikle sig på en maskine og udføre testcases på tre forskellige virtuelle eller fysiske maskiner, skal han købe en 'udviklings' -licens og tre runtime-licenser.
Nogle leverandører tilbyder gratis runtime-licenser (som kodet brugergrænseflade), og nogle tilbyder en pris (som Test Complete, Ranorex osv.). Så alt afhænger af leverandør til sælger.
4) Open Source-licens
Det er din virksomheds valg at vælge et kommercielt værktøj og betale en pris eller gå efter et open source-værktøj.
Kommercielle værktøjer er dyre, men de tilbyder god support og er nemme at bruge med masser af undervisningsmateriale. Kommercielle værktøjer er normalt ”et værktøj til alle behov”. Open source-værktøjer er gratis, men er generelt sværere at lære. Der er lidt officiel support, men du kan finde løsninger ved at besøge forskellige fora. Open source-løsninger er normalt til specifikke behov.
b) Gebyr for support, opgradering og træning:
For support, træning og et opgraderingsgebyr skal du muligvis ringe til virksomhedsrepræsentanten. Nogle virksomheder tilbyder specielle rabatter ved bulkkøb af licenser, så nogle gange nævnes disse oplysninger ikke tydeligt på websteder. Du får kun oplysningerne via opkald eller e-mails.
Spørgsmål nr. 3: Understøtter værktøjet operativsystemet / browseren eller den enhed, som din applikation kører i?
Dette spørgsmål afhænger normalt af den type applikation, du bruger.
a) Hvis desktopbaseret:
Hvis du arbejder på en desktop-applikation, skal du redegøre for, hvor mange operativsystemer du vil teste applikationen. Jeg arbejdede på en desktopbaseret applikation, og jeg ville teste den på Windows 7 og Windows 8.1. Så jeg valgte Coded UI, fordi det understøtter begge dele.
b) Hvis browserbaseret
Hvis du arbejder på en webapplikation, skal du redegøre for, hvor mange browsere du vil teste denne applikation. Jeg ville udføre mine testsager på FireFox, Chrome og IE. Jeg valgte selen til min webapplikation, fordi den understøtter alle disse browsere. Sørg for, at det valgte værktøj skal understøtte både ældre og nyere versioner af dine krævede browsere.
c) Hvis mobilbaseret
Hvis du arbejder på mobilapplikationer, skal du vide, hvilke mobiloperativsystemer du har til at køre dine testcases. Hvis din applikation kører på både Android og IOS, skal dit værktøj understøtte det. Selen har separate drivere til at køre scripts på Android, IOS, Windows Phone og BlackBerry. Du kan også bruge et separat værktøj til hvert af Mobile OS. Der er Robotium til Android, Appium til både IOS og Android og CodedUI til Windows-telefonapps.
Igen kommer dette til debatten om open source vs commercial. Som du kan se, er der separat open source værktøjer til at teste webbaseret , mobilbaseret og desktopbaserede applikationer. Men hvis du går efter et kommercielt værktøj som Test complete, Ranorex eller Test Studio, kan de teste alle tre typer (mobil-, desktop- og browserbaserede applikationer). Så i tilfælde af det kommercielle værktøj skal du kun lære et værktøj til at teste web-, desktop- og mobilapplikationer.
Spørgsmål nr. 4: Understøtter værktøjet de teknologier og tredjepartskontroller, der bruges i din applikation?
Dette er et meget vigtigt aspekt, når du vælger værktøjet. Du skal først vide, at hvilke teknologier der bruges i din applikation. Kontakt dine udviklere og skriv dem ned. Hvis de bruger HTML 5 eller SilverLight i webapplikationer, pas på, der er ikke mange automatiseringsværktøjer, der understøtter dem. Hvis værktøjet hævder støtte til disse teknologier, skal du downloade prøveversionen af dette værktøj og prøve at identificere forskellige objekter i din applikation. Hvis værktøjet ikke identificerer dem, er deres påstand falsk. Denne aktivitet vil redde dig fra den bagefter elendighed.
Test automatiseringsværktøjs sammenligning matrix:
Den følgende tabel sammenligner forskellige værktøjer med hensyn til deres licenspris og deres support til forskellige teknologier. (Du skal tage dette skema som en læringspraksis i, hvordan man laver sammenligninger mellem forskellige værktøjer, men nøjagtigheden af de givne data er ikke 100%)
c ++ dobbeltkædet liste
(Klik på billedet for at se det forstørret)
Y = Understøttet, N = Ikke Understøttet, U = Ukendt
Spørgsmål nr. 5: Hvor mange sprog understøtter værktøjet? Har du dygtige ressourcer til disse sprog?
At lære værktøjet er et aspekt. At lære sproget er et andet aspekt. Hvis du har ressourcer, der har ekspertise inden for Java, og dit værktøj ikke understøtter Java, vil tiden til at lære det nye sprog føjes til din automatiseringsindsats.
Et andet aspekt er, at hvis dit produkt er bygget på Java, skal du have et team af udviklere, der er eksperter i Java. Disse udviklere kan også hjælpe automatiseringsteamet med hensyn til sprogrelaterede problemer. Det er vigtigt at vælge det værktøj, der tilbyder et sprog, der er fortrolig med dine ressourcer, og det hjælper dig med at minimere læringskurven for dine ressourcer.
Det Selen WebDriver tilbyder skrivescript på flere sprog som C #, Java, Python, Ruby og i JavaScript. TestComplete tilbyder også skriveskript på flere script-sprog som VBScript, JScript, DelphiScript, C ++ Script og C # Script.
Spørgsmål nr. 6: Understøtter værktøjet tilslutning til forskellige datakilder?
Hvis vi bruger en automatiseringsramme som nøgleordsdrevet eller datadrevet, skal vi have mulighed for at forbinde vores værktøj til enhver datakilde. Hvis værktøjet let giver forbindelse til forskellige datakilder, vil det være meget gavnligt.
Se understøttelsen af almindelige datakilder, såsom en CSV-fil, Excel-fil, XML-fil og database. Hvis disse er til stede i et værktøj, er du klar til at gå.
Spørgsmål nr. 7: Hvordan er rapporteringsmekanismen for automatiseringsværktøjet?
Når vi udfører scriptet, vil det enten bestå eller mislykkes. I tilfælde af aflevering er der ikke meget information, bortset fra varighed og miljøoplysninger. Men i tilfælde af fiasko har vi brug for en omfattende rapport om fiaskoen. Rapporten skal fortælle os, nøjagtigt på hvilket trin scriptet mislykkes. Et øjebliksbillede af øjeblikket med fiasko vil være en ekstra fordel.
Denne rapport skal også eksporteres til forskellige formater, så vi kan dele dette med interessenter. I mange værktøjer er disse indstillinger indbygget, og i nogle værktøjer er der måder at gøre din rapport omfattende. Dette er en anden ting at se på, når du downloader prøveversionen af værktøjet. Hvis det giver omfattende rapporter om fejl, er det bedst for organisationen.
Spørgsmål nr. 8: Kan værktøjet integreres med testcases og bug management repositories?
Der er en god chance for, at din organisation allerede bruger en testcase eller bug management værktøj . Virksomheder ønsker åbenbart, at deres automatiserede værktøj skal integreres med deres eksisterende test case management-værktøj, så hele deres applikations livscyklus styres korrekt. Dette aspekt skal også ses, når du vælger testautomatiseringsværktøjet.
QTP understøtter QLM, kodet UI understøtter TFS og TestComplete understøtter QAComplete. Nogle open source-værktøjer har også support til at integrere med eksisterende open source testhåndteringsværktøjer. Det hele afhænger af, hvad din organisation faktisk bruger.
Spørgsmål nr. 9: Hvordan er officiel teknisk support til værktøjet?
Her taler vi kun om kommercielle værktøjer. Når du vælger et kommercielt værktøj, er deres supportaspekt meget vigtigt. Se undervisningsmaterialet på hjemmesiden. Indeholder hjemmesiden videoer og tutorials? Har webstedet et officielt forum til at stille spørgsmål? Download prøveperioden og skyde et spørgsmål på deres forum og se, hvor mange dage det bliver besvaret. Giver de support til et opkald?
Ovenstående spørgsmål bør virkelig stilles hver gang, fordi du bruger en god sum penge på værktøjet. Hvis værktøjet ikke har god support, skal du ikke gider at købe det.
Spørgsmål nr. 10: Nogle tekniske aspekter at se
Der er nogle andre tekniske aspekter at se så godt som:
a) Optagelse og afspilning understøttes
Det er ikke en anbefalet tilgang til testautomatisering, men det er godt at have et værktøj. Det forenkler læringsprocessen for værktøjet og hjælper med at lette scenarier, der let kan automatiseres.
b) Forskellige genkendelsesmetoder og understøttelse af objektmapping
Der skal være en række forskellige valg af det samme objekt med forskellige metoder. Nogle genstande er svære at genkende. Så de mange valgmuligheder er altid nyttige.For eksempel, understøtter selen valg af objekter efter id, navn, klasse, link test, XPATH , CSS-vælger og JavaScript. Her er en tutorial om - hvordan QTP identificerer objekter entydigt . Hvis en valgmetode ikke fungerer, har vi en række andre metoder at vælge imellem, som altid er nyttige.
Tilsvarende skal der være en mulighed for korrekt at kortlægge disse objekter i objektopbevaringsområdet. Dette arkiv skal let kunne opdateres og administreres. Bare for at minde dig om, at Selen ikke har indbygget understøttelse af objektmapping.
c) Forskellige kontrolpunkter eller påstandssupport.
Testsagen er bestået eller mislykkedes baseret på kontrolpunkter eller påstande. Hvis værktøjet har en række forskellige metoder til at kontrollere dine forventede resultater, er det gavnligt. QTP har en række kontrolpunkter såsom Standard , Bitmap , Bord , XML, database og kontrolindhold for filindhold.
d) Håndtering af gendannelsesscenarier.
Hvis testsagen mislykkes, og du vil fortsætte udførelsen, understøtter værktøjet så let? Hvis genoprettelsesscenarier er lette at administrere i et værktøj, giver det dig mulighed for at udføre testsager uden nogen fejl. Du kan køre testsagerne om natten, og om morgenen får du resultaterne, der angiver, hvilke testsager der mislykkes, og hvilke testsager der er bestået. Dette sker kun, hvis opsving fra mislykkede testsager let kan styres af værktøjet. Ellers spildes en god mængde automatiseringsindsats i håndtering af gendannelsesscenarier. Se gendannelsesscenarier styring i QTP .
Konklusion
Husk altid, at intet værktøj er et godt eller dårligt værktøj. Det hele afhænger af dine krav og produktets natur.
Selen kan være det mest populære automatiseringsværktøj, men hvis dit produkt er desktopbaseret, har dette værktøj ikke noget for dig. Forstå dit produkt først, og søg derefter efter det passende værktøj, der matcher dit krav ved hjælp af de retningslinjer, der er nævnt i denne vejledning.
Korrekt valg af automatiseringsværktøj spiller en vigtig rolle i vellykket automatisering.
Næste vejledning - Vores næste tutorial i denne serie er om 'Script-udvikling og automatiseringsrammer med eksempler'. Igen, tjek alle tutorials i denne serie på denne side .
Du er velkommen til at sende dine forespørgsler / kommentarer nedenfor om valg af det rigtige automatiseringsværktøj.
PREV Tutorial # 3 | NÆSTE vejledning nr. 5
Anbefalet læsning
- Sikuli GUI Automation Testing Tool - Beginner's Guide Part # 2
- Alpha-test og betatestning (En komplet guide)
- Geb Tutorial - Browserautomatiseringstest ved hjælp af Geb Tool
- Build Verification Testing (BVT Testing) Komplet guide
- Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
- Funktionel testning mod ikke-funktionel testning
- Trin for trin vejledning til implementering af bevis for koncept (POC) i automatiseringstest
- 10-trins automatiseringstestproces: Sådan starter du automatiseringstest i din organisation