Beste svaret
QTP
- QTP nå UFT er lisensiert verktøy levert av HP , kan den brukes til å automatisere Web Application, Windows Desktop-applikasjon, Oracle-applikasjon for å nevne noen. Selv om gratis nedlasting med noen tillegg er levert av HP for en måneds bruk.
- VBSCRIPT er det primært brukte script Språk i QTP.
- QTP har seg selv en innebygd IDE
- QTP-skript kan kjøres på en sekvensiell måte.
Selen
- Selen er mer et automatiseringsrammer enn verktøy og brukes til å automatisere bare webapplikasjoner.
- Java er det primære valget av språk for å utvikle skriptene dine, selv om du kan bruke C # , Python også
- Formørkelse brukes primært til å skrive testskriptene
- Selen kan brukes til å kjøre testtilfeller parallelt.
På sammendragsnivå er både QTP og Selen fine verktøy for automatisering, avhengig av u Pon-krav, tilgjengelighet og ferdighetssett kan et av disse verktøyene velges.
Svar
Hvis du er i en situasjon for å bestemme karrieren din på UFT eller selen. Jeg vil gjerne gi litt innsikt i Test-automatiseringsindustrien, de vanlige mytene som ligger rundt forskjellige verktøy og tankegangen til mennesker selv.
Vi snakker rent om GUI-testverktøy her. Først og fremst må vi forstå hvor mye GUI-testing vi skal gjøre i fremtiden. Typiske moderne utviklingsprosjekter legger stor vekt på et omvendt pyramidekonsept med testing hvor du gjør mye testing helt i begynnelsen av prosjektet, og når programvaren går gjennom utviklingssyklusen, reduseres testmengden drastisk. Så alltid skjer den såkalte GUI-testen ganske sent i spillet. Noe som igjen betyr at mengden GUI-testing vil være relativt mindre i fremtiden. Det er mange organisasjoner som har enorme mengder regresjonsskript som de kjører og kjører for alltid.
Neste ting er valg av verktøy. Mange produkteiere eller organisasjonene følger med de sprø presentasjonene som tilbys av mange tjenestebaserte selskaper som bare lager sine proprietære programvare bare for å skape et monopol i en organisasjon som varer evig. Da husker jeg da kommersielle verktøy som qtp, rft osv. Var det eneste i markedet servicenivåbedriftene var på sine proprietære produkter, og det viktigste salgsargumentet er reduksjon i kostnadene. Men alle hvor søppel de ville være. Så kom selen, og det ga bokstavelig talt friheten til å kraftigere lage en tilpasset automatiseringsløsning.
Her begynner problemet. La meg gi et eksempel, med de nåværende utviklingsstrategiene hvis du vil velge en automatiseringsstrategi som skal implementeres, så er det første som bør vurderes å ha et automatiseringsrammeverk som er synkronisert med utviklingsplattformen din. Hvis utviklingen din bruker dotnet, så bruk kodet brukergrensesnitt for automatisering, men det er virkelig en dårlig ide å bruke selen. Som folk flest gjør. Eller de vil implementere selen med c #.
Det neste store problemet er med automatiseringstesterne som i de fleste tilfeller vet hvordan de skal få ting gjort. Men de vil ikke kunne rettferdiggjøre hvorfor de fulgte denne tilnærmingen. I et typisk utviklingsmiljø følger vi strenge prinsipper og kodestandarder, men i de fleste automatiseringsprosjektene følges det ikke. Og tilnærmingen til å automatisere et scenario betyr virkelig noe. Mennesker går for det meste bare med det som flimrer i tankene først. Og det morsomme er at det vil få jobben deres gjort for det, men på lang sikt vil det sikkert skape problemer.
Selen, årsaken til dens suksess i bransjen, kommer hånd i hånd med at bransjen tar i bruk smidige metoder. HP var litt sent ute i dette spillet ved å bringe LeanFT når selen allerede har fanget bransjen. Vi burde også tenke på hvor mange organisasjoner som har implementert Selen virkelig har fått fordelen av det. Problemet med selen kommer når volumet blir stort. Konseptet med sporbarhet, testsaksbehandling, effektiv filtrering, risikobasert testing er veldig vanskelig når det gjelder selen. Du må legge ned en enorm utviklingsinnsats for å gjøre rammeverket komplett. Si at du har gjort det, og at du også har tatt ansvaret for å opprettholde det rammeverket, som ble utviklet i huset, og det er alltid en læringskurve. Svært store organisasjoner går med metodikk bare fordi de kan, og de har bruk av det. Når jeg sier stort, er det like stort som Google, Amazon, PayPal osv. Men for andre selskaper de trenger å analysere, er det verdt å ta en slik byrde.
Dette er når vurderingen av kommersielle verktøy kommer inn i bildet. De har alt, faktisk gir de mange ting du aldri bruker, og de tar betalt for deg.Nå er det tradisjonelle problemet med dette kommersielle verktøyet siden så lang tid suksessen er hos menneskene som implementerer et automatiseringsprosjekt helt i begynnelsen. En person som lærer inn og ut av et kommersielt verktøy, fullfører alle mulige sertifiseringer Kvalifiserer ikke til å gjennomføre prosjektet. Hvis du for eksempel tar HP-sertifisering, er det HP ATP og HP ASE. De fleste fullfører ATP, men svært få fullfører ASE. En ASE er den som virkelig er i stand til å implementere et prosjekt. Ikke ATP. (Jeg mente ikke sertifisering er must) En person med veldig implementeringserfaring sammen med utmerket kunnskap i verktøyene som kan rettferdiggjøre hvorfor bruke denne tilnærmingen i stedet for bare å kaste rundt en hvilken som helst tilnærming, bør være der implementere den. Uansett hvilke verktøy de bruker, produktselskap ville ha håndhevet visse måter, beste fremgangsmåter og tilnærminger. Men folk som bruker verktøyene bryr seg nesten ikke om disse dokumentasjonene.
Per i dag er det kraftigste automatiseringsverktøyet KODET UI, TFS, selv om det har problemer med MAC. Med UFT kan du utføre både funksjonelle API-tester så vel som du kan automatisere alle applikasjoner. LeanFT kan hjelpe deg med å automatisere i utviklingsmiljø så enkelt. Det er noe som kalles HP utvidelsesakselerator, men nesten ingen vet å bruke det. Selen har mange ting. Men det er som en Lego-blokk du må bygge den. Og du tar det fulle ansvaret for eventuelle problemer som kan skje videre. Bortsett fra disse er det mange verktøy som utmerker seg i visse områder, men det er ikke verdt å vurdere nå.
Poenget er at det ikke betyr noe hvilket verktøy du velger. Det som trengs mest er å til slutt få kunnskapen om å implementere en riktig tilnærming som bare kommer av erfaring. Start hvor som helst og når du har riktig innsikt uansett hva du kommer dit. Og når du kanskje har lært ganske mye mange verktøy og språk. Lykke til!