ODT és KDT a testcomplete mítosz vagy valóság?

A TestComplete eszköz hosszú ideig (mivel a régi verzió) modulokat is, elhelyezni, mint egy ODT (Object-alapú tesztelés) és KDT (kulcsszó alapú tesztelés). Ezek a modulok megfelelő végrehajtását ilyen megközelítés, vagy ez csak egy fantázianév? Róla, és úgy gondolják, ezt a cikket.

Minden, ami meg van írva az alábbiakban - pusztán véleményem alapján 5 éves tapasztalattal rendelkezik a automatizálás TestComplete, hiszen 6.0-s verziója, és befejezve az utolsó (jelenleg 9.10).

Néhány szó a TestComplete

TestComplete - egy nagyszerű eszköz. Automatizálását asztali alkalmazást, amíg az nem egyenlő, ha figyelembe vesszük az ár belépési korlát, a kényelem, a funkcionalitás. A legújabb verzió (mivel 8,0) is nagyon sokat finomodott képes automatizálni webes alkalmazás. Elképzelhető, hogy hamarosan versenyezni TestComplete WebDriver (mindenben, kivéve az ár).

Ez is egy nagyon nagy plusz eszköz - támogatása például Flash, Flex, AJAX, Silverlight. Nos, a másik (ami azonban vannak más eszközök).

Ezzel szemben az azonos (versenytárs) QTP, TestComplete például felkínálja a script nyelvek: C ++, C #, DelphiScript, VBS, JScript. Nem mindenki használja (ez levelet külön felülvizsgálat), de van egy választás - ez már önmagában is egy plusz.

Van is egy teljes funkcionalitású 30 napos próbaverzió Enterprise, ami nagyon kényelmes és jó.

modulok TestComplete

Az modulok Megértem azokat a dolgokat, hogy ki lehet egészíteni a projekt TestComplete. Ez a modul a „széles” a szó szoros értelmében.

Ahhoz, hogy összeállítsa a vizsgálat öltöny és hozzon létre egy keret, akkor meg kell határozni a használandó modulokat és megérteni, hogy pontosan hogyan akarjuk őket használni. Változtassa meg a kiválasztást a kulcs nélküli modulok jelentős újraírás nem lehetséges, úgyhogy ez elég finom és fontos pont.

Ha leírjuk az egyes modulok külön-külön (ha van türelme), akkor közzé egy kis könyvet. Fogom leírni a véleményét két modulból áll: ODT és KDT, amelyeket gyakran használnak, és amelyek használata láttam egy csomó hibát a gyakorlatban.

Elég bevezetése, menjünk

Állványok objektum-alapú tesztelés. Furcsa kifejezés. Sehol, kivéve TestComplete használom ezt a kifejezést még nem láttam. Ott OOP, DSL, PageObject ... Googling «ODT» - fog lepődni, azt hiszem ... ODT a TestComplete a klasszikus alkalmazás - egy tároló a tárgyak - osztályok és az adatok. Kényelmes, vagy sem - erről bővebben alább. Csak egy gyors megjegyzés: ha használja a kifejezést ODT a kommunikáció, emlékszem - úgy ismert, csak azoknak, akik ismerik TestComplete.

Akkor létre osztályokat. Miért? Azt hiszem, a fő gondolat az volt, hogy kompenzálja a „szegénység” a szkriptnyelveket OOP. Osztályba lehet létrehozni osztályok és néhány osztályok öröklik másoktól. Módszerek Ezen osztályok lehet venni a script, árukapcsolás a kívánt funkciót, mint egy osztály módszer. Ezt meg lehet tenni akár kézzel (de Automator - ez érdektelen és nem hatékony), és szkriptek (ez érdekes).

Mi teszi az osztályok létrehozását ODT.Classes?

  • A lehetőség, hogy a rendelkezésre álló módszerek és tárgyak tulajdonságait után a „pont” a folyamat az írás kód
  • Képesség, hogy kézzel leírni néhány formák és tárgyak osztályok
  • Lehetőség öröklés
  • Képes létrehozni vizsgálati adatok szokások, amelynek típusa az osztály

Az utolsó - elég kényelmes (de erről bővebben alább a Data). A többi - meglehetősen kétes előny, figyelembe véve a hátrányait osztályok segítségével:

  • Ahhoz, hogy automatikusan generál osztályok scriptek ODT.Classes tervezők kell leírni az összes módszer, és hívja ezeket a konstruktőrök. Ez még mindig szükség van „gyűjtő” Mindezen tervezők. Továbbá, az eljárás nevét átadott string (lásd a kódot és a leírást alább). Ha egy metódus átnevezték a kódot, és elfelejtettem, hogy nevezze át a kivitelező, akkor veszi észre, hogy nem nagyon hamar ...
  • Bővül a pop-up a rendelkezésre álló módszerek és tulajdonságok után a „pont” elég lassú. Azt veszi észre, hogy csak egy nagy projekt, ahol teszt ruha elég erős nő. Tulajdonképpen, ha a változás lesz drága

Például egy olyan módszer, és AddUser UsersCount ingatlan osztályba felhasználók, meg kell írni a kódot, mint ez:

Mint látható, a neve a method = UsersForm.AddUser és egy string (fájlnév, mely otthont ad a módszer + módszer neve).

A gyakorlatban azt próbálta használni ezeket az osztályokat a ODT. De a végén volt több hátránnyal, és váltottam használni JScript nyelvű osztályok. Igen, nincs öröklés, de anélkül, hogy meg lehet építeni egy jó keretet (annál is inkább, ODT.Classes mindig nincs beágyazás, polimorfizmus, és hasonlók, és már csak az öröklés és az ő egyetlen értelmes kása főzni kemény)

Hozzon létre egy osztályt (lehet üres)

Írása kód hozzáadásával az érintett tárgyak (type = ebbe az osztályba), és a kívánt tulajdonságok

ODT.Data mérete kimutatták, hogy nincs hatással a végrehajtási sebesség és a kényelem a munka (fékek, akkor használja az osztályok, nem vette észre).

Következtetés ODT: fel lehet használni, de nem minden és nem mindig. Egy jó használat esetén (egy lehetséges): ODT.Data tárolására vizsgálati adatok és ODT.Classes sablonokat tárgyakat.

kulcsszó tesztek

KDT (kulcsszó-alapú tesztelés) a klasszikus - ez elég egyszerű megközelítés, amely meghatározza, hogy hogyan és hol a vizsgálatokat úgy kell megtervezni, és hogyan keret is ki kell terjednie, hogy ezeket a teszteket.

TestComplete fejlesztők távú «kifejezés tesztelés» nagyon jó kikerülje a klasszikusok: ez nem egy kulcsszó alapú tesztelés, és a kulcsszó tesztelés. És működik - sokan kezdik keverendő ...

Fogom leírni, hogy mi van a TestComplete, és mi legyen a normál KDT megközelítés. És akkor úgy dönt, hogy használja ezt a modult, vagy sem

Mi a kulcsszó Testing modul TestComplete:

  • Vizuális környezet, amely lehetővé teszi, hogy hozzon létre teszt „egér”, írása nélkül
  • Az ellenőrzőpontok beállítani mindenféle ellenőrzések (beviteli mezők, táblázatok, képek, szolgáltatások, stb.)
  • Interaktív ablak a vizsgálat során a felvétel vagy hozzáadásával ellenőrzőpont
  • Vizualizer, amely lehetővé teszi, hogy adjunk egy ellenőrző a megfelelő helyen és a meglévő vizsgálati (megtartja az összes ablakot, amelyet a vizsgálathoz használt felvételt, majd lehetővé teszi, hogy „visszamenőlegesen” select kontol és add meg ellenőrizni, például)

Akkor hívásokat más, már kész, kulcsszó-vizsgálatok, valamint megírt rutin. Elvileg a korlátozások a funkcionalitás, ez a modul nem. De van egy tulajdonsága, hogy nem a kulcsszó alapú tesztelés, ez - csak egy vizualizációs és az egyszerű élet korai szakaszában a vizsgálat az automatizálás.

Mi az a megközelítés KDT (kulcsszó alapú tesztelés):

  • Az a képesség, hogy írjon vizsgálatok kívül IDE (kulcsszavak vizsgálatok gyakran írnak biznas elemzők és az emberek az ügyfél, aki nagyon jól tudja a domain, de nem érti az automatika)
  • Dictionary of kulcsszavak, mellyel a vizsgált
  • Keretet, amely végrehajtja a kulcsszavak használata (a keret gyakran nem láthatók azok a tesztek kulcsszavak nem szükséges :. Ez az elválasztás történhet szándékosan, hogy külön keret fejlesztőcsapat egy csoportja, akik teszik majd ki-tesztek)

Hogy ez a TestComplete? Semmi baj. Írja tesztek TestComplete lehetetlen; Szótár lett, de nagyon korlátozott (az ellenőrző pontok), a többi kulcsszavak kell leírni (ami logikus elve); keretet is kell, hogy saját.

Nincs TestComplete, hogy egyszerűsítse a keret létrehozását, illetve néhány sablont, hogy magas minőségű KDT? - Nem

Következtetés: KDT megközelítést végrehajtani TestComplete lehet. De mi történik a kimeneten nem lesz semmi köze a modul Kulcsszó tesztelés

Egy kérdésre válaszolva a cím

ODT és KDT a TestComplete: mítosz vagy valóság?

ODT: 50% mítosz, 50% valóság. jelentős előnyöket (szemben osztályok nyelvet, például, JScript) mítosz szempontjából ODT.Classes, ami a gyakorlatban meglehetősen kényelmetlen használni, és nem adnak. A ODT.Data valósíthat öröklés, de hasznosságát meglehetősen csalóka, mivel a hiányosságok a fent leírt. ODT.Data használatra lehet és kell is - a kényelmes vizsgálati adatok tárolására. Együtt a sablon osztály lehetővé teszi, hogy komplex vizsgálati adatok szerkezete, ami kényelmes automatizálás.

KDT: egy mítosz. Van egy modul kifejezés vizsgálata, amelynek semmi köze a megközelítés a kulcsszó-alapú tesztelés. Klasszikus KDT lehet végrehajtani, de ehhez meg kell írni a kódot és a design keretet. Azonban bármilyen súlyos automatizálási jelent keretet úgy, hogy nem ijeszt.

Hogyan kell végrehajtani a gyakorlatban megközelítések ODT és KDT?

A képzés során a „megközelítések fejlesztése a vizsgálati keret (TestComplete)» mi alaposan elemzi az egyes megközelítés: objektum-alapú tesztelés (ODT), adat-vezérelt vizsgálat (DDT), kulcsszó alapú tesztelés (KDT), megtanulják, hogyan kell végrehajtani a semmiből, és megérteni milyen megközelítéseket, amelyek jobban illeszkednek a különböző gyakorlati problémák.

Kapcsolódó cikkek