Hvad er forskellen mellem QTP og Selen-automatiserede værktøjer?

Bedste svar

QTP

  1. QTP nu UFT er licenseret værktøj leveret af HP , kan den bruges til automatisering af webapplikation, Windows Desktop-applikation, Oracle-applikation for at nævne nogle få. Skønt gratis download med nogle tilføjelser leveres af HP til en måneds brug. Sprog i QTP.
  2. QTP selv leveres med en indbygget IDE
  3. QTP-scripts kan køres sekventielt.

Selen

  1. Selen er mere en automatiseringsramme snarere end et værktøj og bruges til automatisering af kun webapplikationer.
  2. Java er det primære sprogvalg til at udvikle dine scripts, selvom du kan bruge C # , Python så godt
  3. Eclipse bruges primært til at skrive testscripts
  4. Selen kan bruges til at køre testsager parallelt.

På oversigtsniveau er både QTP og Selen gode værktøjer til automatisering, afhængigt af dig pon-krav, tilgængelighed og færdigheder kan et af disse værktøjer vælges.

Svar

Hvis du er i en situation med at bestemme din karriere på UFT eller selen. Jeg vil gerne give noget indblik i testautomationsindustrien, de almindelige myter, der bor omkring forskellige værktøjer og tankegangen hos mennesker selv.

Vi taler rent om GUI-testværktøjer her. Først og fremmest skal vi forstå, hvor meget GUI-test, vi vil gøre i fremtiden. Typiske moderne udviklingsprojekter lægger stor vægt på et omvendt pyramidekoncept med test, hvor du gør helvede med en masse test i starten af ​​projektet, og når softwaren krydser gennem udviklingscyklussen, reduceres testmængden drastisk. Så altid sker den såkaldte GUI-test temmelig sent i spillet. Hvilket igen betyder, at mængden af ​​GUI-test vil være relativt mindre i fremtiden. Der er mange organisationer, der har en enorm mængde regressionskripter, som de kører og kører for evigt.

Næste ting er valget af værktøjer. Mange produktejere eller organisationer går med de vanvittige præsentationer, der leveres af mange servicebaserede virksomheder, som kun skaber deres proprietære software, bare for at skabe et monopol i en organisation, der varer evigt. Dengang husker jeg, når kommercielle værktøjer som qtp, rft osv. Var det eneste på markedet, servicevirksomhederne havde på deres proprietære produkter, og det største salgsargument er reduktion i omkostninger. Men alle, hvor junky de ville være. Så kom selen, og det gav bogstaveligt talt friheden til mere magtfuldt at skabe en tilpasset automatiseringsløsning.

Her begynder problemet. Lad mig give et eksempel med de nuværende udviklingsstrategier, hvis du vil vælge en automatiseringsstrategi, der skal implementeres, så er det første, der skal overvejes, at have en automatiseringsramme, der er synkroniseret med din udviklingsplatform. Hvis din udvikling bruger dotnet, skal du bruge kodet brugergrænseflade til automatisering, i stedet for at bruge selen er virkelig en dårlig idé. Som de fleste mennesker gør. Eller de implementerer selen med c #.

Det næste store problem er med automatiseringstestere, som i de fleste tilfælde ved, hvordan man får tingene gjort. Men de vil ikke være i stand til at retfærdiggøre, hvorfor de fulgte denne tilgang. I et typisk udviklingsmiljø følger vi strenge principper og kodningsstandarder, men i de fleste automatiseringsprojekter følges det ikke. Og tilgangen til at automatisere et scenario betyder virkelig noget. Folk går for det meste bare med det, der flimrer i deres sind først. Og det sjove er, at det vil få deres arbejde udført for dengang, men på lang sigt vil det helt sikkert skabe problemer.

Selen, årsagen til dets hit i branchen kommer hånd i hånd med, at branchen anvender agile metoder. HP var lidt sent i dette spil ved at bringe LeanFT, når selen allerede har fanget branchen. Vi skal også tænke på, hvor mange organisationer, der har implementeret Selenium, virkelig har fået fordelen ud af det. Problemet med selen kommer, når lydstyrken bliver enorm. Begrebet sporbarhed, test case management, effektiv filtrering, risikobaseret test er virkelig svært med selen. Du er nødt til at lægge en enorm udviklingsindsats for at gøre rammen komplet. Sig, at du har gjort det, og at du også har taget ansvaret for at opretholde den ramme, der blev udviklet internt, og der er altid en læringskurve. Meget store organisationer går med metodologi bare fordi de kan, og de har brugen af ​​det. Når jeg siger stort, er det lige så stort som Google, Amazon, PayPal osv. Men for andre virksomheder, som de har brug for at analysere, er det værd at tage en sådan byrde.

Dette er, når hensynet til kommercielle værktøjer kommer i billedet. De har det hele, faktisk leverer de mange ting, du aldrig engang bruger, og de opkræver for dig.Nu er det traditionelle problem med disse kommercielle værktøjer siden så lang tid succesen er hos de mennesker, der implementerer et automatiseringsprojekt i starten. En person, der lærer ind og ud af et kommercielt værktøj, afslutter alle mulige certificeringer, er ikke kvalificeret til at gennemføre projektet. For eksempel, hvis du tager HP-certificering, er der HP ATP og HP ASE. De fleste mennesker gennemfører ATP, men meget få gennemfører ASE. En ASE er den, der virkelig er kapabel til at gennemføre et projekt. Ikke ATP. (Jeg mente ikke certificering er must) En person med meget implementeringserfaring sammen med en fremragende viden i de værktøjer, der kan retfærdiggøre, hvorfor man bruger denne fremgangsmåde i stedet for bare at kaste en hvilken som helst fremgangsmåde, skal være der implementerer den. produktvirksomhed ville have håndhævet bestemte måder, bedste praksis og tilgange. Men folk, der bruger værktøjerne, bryder sig næppe om disse dokumentationer. MAC. Med UFT kan du udføre både funktionel API-test såvel som du kan automatisere ethvert program. LeanFT kan hjælpe dig med at automatisere i udviklingsmiljøet så let. Der er noget, der kaldes HP-udvidelsesaccelerator, men næsten ingen ved at bruge det. en masse ting. Men det er som en Lego-blok, du skal bygge det. Og du tager det fulde ansvar for eventuelle problemer, der kan ske næste. Bortset fra disse er der mange værktøjer, der udmærker sig i visse områder, men det er ikke værd at overveje nu.

Bundlinjen er, at det ikke betyder noget, hvilket værktøj du vælger. Det, der er mest nødvendigt, er til sidst at få viden om at implementere en rigtig tilgang, der kun kommer af erfaring. Start hvor som helst, og når du har den rigtige indsigt, uanset hvad du kommer derhen. Og når du måske har lært en hel del mange værktøjer og sprog. Held og lykke !!!

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *