Mi a különbség a QTP és a Selenium automatizált eszközök között?

Legjobb válasz

QTP

  1. A QTP most UFT licencelt eszköz a HP , felhasználható a webalkalmazások, a Windows Desktop alkalmazás, az Oracle alkalmazás automatizálására, hogy csak néhányat említsünk. Bár a HP egy hónapos használatra ingyenes letöltést kínál egyes kiegészítőkkel.
  2. A VBSCRIPT az elsődlegesen használt parancsfájl. Nyelv a QTP-ben.
  3. A QTP magában egy beépített IDE-t tartalmaz.
  4. A QTP-szkriptek egymás után futtathatók.

Szelén

  1. A szelén inkább egy automatizálási keretrendszer, nem pedig egy eszköz, és csak a webalkalmazások automatizálására szolgál.
  2. a Java az elsődleges nyelvválasztás a szkriptek fejlesztéséhez, bár a C # , Python is
  3. Az Eclipse-t elsősorban a tesztparancsok írásához használják.
  4. A szelén használható tesztesetek párhuzamos futtatására.

Összefoglaló szinten a QTP és a Selenium is jó eszköz az automatizáláshoz, az u függvényében pon követelmény, rendelkezésre állás és készségkészlet ezek közül az eszközök közül bármelyik választható.

Válasz

Ha olyan helyzetben van, hogy az UFT vagy a szelén mellett döntsön. Szeretnék betekintést nyújtani a teszt automatizálási iparágba, az általános mítoszokba, amelyek a különféle eszközök és az emberek gondolkodásmódja körül mozognak.

Itt pusztán a GUI tesztelő eszközökről beszélünk. Először meg kell értenünk, hogy mennyi GUI tesztet fogunk elvégezni a jövőben. A tipikus modern fejlesztési projektek nagy hangsúlyt fektetnek a teszt inverz piramis koncepciójára, ahol a projekt legelején nagyon sok tesztet végzünk, és miközben a szoftver végigjárja a fejlesztési ciklust, a tesztelés mennyisége drasztikusan csökken. Tehát az úgynevezett GUI tesztelés mindig elég későn történik a játékban. Ami viszont azt jelenti, hogy a GUI tesztelés mennyisége a jövőben viszonylag kevesebb lesz. Sok olyan szervezet van, amelynek rengeteg regressziós szkriptje van, amelyeket örökre futtat és futtat.

A következő dolog az eszközök kiválasztása. Számos terméktulajdonos vagy szervezet vesz részt az őrült előadásokban, amelyeket számos szolgáltató vállalat tart, akik saját szoftvereket hoznak létre csak azért, hogy monopóliumot teremtsenek egy szervezeten belül, és örökké tartson. Akkor emlékszem, amikor a kereskedelmi eszközök, például a qtp, az rft stb. Voltak az egyetlen dolog a piacon, ahol a szolgáltatási szintű vállalatok a saját termékeikre helyezkedtek el, és a legfontosabb értékesítési pont a költségek csökkentése. De mindenki milyen ócska lenne. Aztán jött a szelén, és szó szerint megadta a szabadságot egy testreszabott automatizálási megoldás hatékonyabb létrehozására.

Itt kezdődik a probléma. Hadd mondjak egy példát a jelenlegi fejlesztési stratégiákkal kapcsolatban, ha ki akar választani egy megvalósítandó automatizálási stratégiát, akkor az első szempont, amelyet figyelembe kell venni, hogy rendelkezzen olyan automatizálási keretrendszerrel, amely szinkronban van a fejlesztői platformjával. Ha fejlesztése dotnet-t használ, akkor az automatizáláshoz használja a kódolt felhasználói felületet, ehelyett a szelén használata valóban rossz ötlet. Amit a legtöbb ember csinál. Vagy megvalósítják a szelént c # -val.

A következő nagy probléma az automatizálási tesztelőkkel van, akik a legtöbb esetben tudják, hogyan kell elvégezni a dolgokat. De nem fogják tudni megindokolni, hogy miért követték ezt a megközelítést. Tipikus fejlesztési környezetben szigorú elveket és kódolási szabványokat követünk, de az automatizálási projektek többségében ezt nem követik. És a forgatókönyv automatizálásának megközelítése valóban számít. Az emberek legtöbbször csak azzal járnak, ami először a tudatában villog. És az a vicces, hogy addigra elvégzik a munkájukat, de hosszú távon biztosan problémát fog okozni.

A szelén, az iparágban elért sikereinek oka együtt jár azzal, hogy az ipar agilis módszereket alkalmaz. A HP alig késett ebben a játékban azzal, hogy hozta a LeanFT-t, amikor a szelén máris magával ragadta az ipart. Azt is el kell gondolnunk, hogy hány szervezet, amely megvalósította a Szelént, valóban kihasználta ennek előnyeit. A szelén problémája akkor jelentkezik, amikor a hangerő hatalmas lesz. A nyomonkövethetőség, a tesztesetek kezelése, a hatékony szűrés, a kockázat alapú tesztelés nagyon nehéz a szelén esetében. Hatalmas fejlesztési erőfeszítéseket kell tennie a keretrendszer teljes megvalósítása érdekében. Tegyük fel, hogy ezt megtettétek, és vállaltátok a házban kifejlesztett keretrendszer fenntartását, és mindig van egy tanulási görbe. Nagyon nagy szervezetek csak azért vesznek részt a módszertanban, mert tudnak, és használják is őket. Amikor azt mondom, hogy nagy, akkora, mint a Google, az Amazon, a PayPal stb. De más vállalatok számára, amelyeket elemezniük kell, érdemes-e ekkora terhet vállalniuk.

Ekkor képbe kerül a kereskedelmi eszközök figyelembevétele. Megvan mindenük, sőt, sok olyan anyagot kínálnak, amelyet soha nem is használ, és felszámítják.Most a hagyományos probléma ezzel a kereskedelmi eszközzel, mivel ilyen sokáig a siker azoknál az embereknél van, akik a legelején végrehajtanak egy automatizálási projektet. Az a személy, aki betanul egy kereskedelmi eszközt, és elvégzi az összes lehetséges tanúsítást, nem felel meg a projekt végrehajtásának. Például, ha HP minősítést szerez, akkor ott van a HP ATP és a HP ASE. A legtöbb ember teljesíti az ATP-t, de nagyon kevesen fejezik be az ASE-t. Az ASE az, aki valóban képes végrehajtani a projektet. Nem az ATP. (Nem azt értettem, hogy kötelező a tanúsítás) Az a személy, akinek nagyon gyakorlati tapasztalata van, és kiváló ismerete van az eszközökről, aki meg tudja indokolni, hogy miért használja ezt a megközelítést, és nem csak szemlélni bármilyen megközelítést, annak ott kell megvalósítania. Bármelyik eszközt is használja, a a termékgyártó cég bizonyos módszereket, bevált gyakorlatokat és megközelítéseket érvényesített volna. De az eszközöket használó emberek alig törődnek ezekkel a dokumentációkkal.

A mai napig a leghatékonyabb automatizálási eszköz a CODED UI, a TFS, bár problémái vannak a MAC. Az UFT segítségével mind a funkcionális API tesztelést, mind bármely alkalmazás automatizálását elvégezheti. A LeanFT olyan könnyedén segíthet az automatizálásban a fejlesztői környezetben. Van valami, amit HP kiterjesztési gyorsítónak hívnak, de aligha tudja valaki használni. A szelén sok sok dolog. De olyan, mint egy Lego blokk, meg kell építenie. És vállalja a teljes felelősséget minden olyan kérdésért, amely később bekövetkezhet. Ezeken kívül sok olyan eszköz létezik, amelyek bizonyos területeken kiválóak, de most nem érdemes megfontolni őket.

A lényeg az, hogy nem mindegy, hogy melyik eszközt választja. Amire a legszükségesebb, az az, hogy végül megkapja az ismereteket a helyes megközelítés megvalósításáról, amely csak tapasztalatból származik. Kezdje bárhonnan és akkor, amikor megfelelő belátása van, függetlenül attól, hogy mit ér el. És mire már megtanulhatott egy sok eszköz és nyelv. Sok szerencsét !!!

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük