Robot Framework tippek trükkök: vezéreljünk PICT segítségével

Előzmények

Akik olvasói a blognak, tudják, hogy a pict nem egy képszerkesztő eszköz, hanem páronkénti tesztelést támogató eszköz. Itt olvashatod el: PICT 1, PICT 2
Volt már egy cikksorozat az adatvezérelt tesztelésről, aminek a 3. részében bemutattuk, hogy Robot Frameworkkel hogyan lehet megvalósítani az adatvezérelt tesztelést. Ezt a cikket itt találod: ADATVEZÉRLÉS 3
Most azt szeretném megmutatni, hogyan lehet párosítani ezt a két eszközt. A cikk az előző két eszköz ismeretére épít.

Mire lesz szükségünk?

  • Szükségünk lesz a Robot Framework-höz telepített Data Driver könyvtárra.
  • Szükségünk lesz a MS PICT segédprogramra. Be kell állítani, hogy a futtató állomány Path-on legyen.
  • A pict adatmodell állomány (amiben az alapadatok vannak) kiterjesztésének .pict -nek és a kódolásának UTF-8 -nak kell lennie.

Hogyan csináld?

Az Adatvezérlés (Adatvezérlés 3) cikkhez képest egyetlen különbség a Settings részben a Data Driver könyvtár meghívásánál van. A könyvtár paraméterének meg kell adni a .pict állományt. Valahogy így:

*** Settings *** 
Library DataDriver alapadat.pict

Az adatvezérlő könyvtár a .pict kiterjesztést “látva” ezt az állományt a pict programnak küldi, ami előállítja a kívánt kombinációt és ezt .picout állományként menti a .pict mellé. A robot DataDriver könyvtára ebben az eredményállományban található rekordokat fogja bemeneti tesztadatoknak tekinteni.

Valójában a pict program bármely paraméterét is megadhatjuk a könyvtár meghívás sorában egy pict_option paraméterrel, pl. így:

*** Settings *** 
Library DataDriver alapadat.pict pict_options=/o:3 /r

Innentől pont ugyanazt kell csinálni, amit az Adatvezérlés (Adatvezérlés 3) cikkben írtunk. Meg kell határozni a Test Template-et, létre kell hozni egyetlen tesztesetet és azt a kulcsszót, amit megadtunk a Test Template résznél.

Hajrá!

A PICT és a Robot Framework keresztezése nagyon egyszerű és nagyon hatásos fegyver az adatvezérelt tesztelésnél. Az is könnyen megoldható, hogy minden futásnál más-más paraméter-párosításokkal fusson le a teszt. (Erről a PICT képes gondoskodni, ha szépen kérjük 🙂 )

Hatékony tesztelést!

Megosztás

Kérsz értesítést a legújabb cikkekről?

Feliratkozom

Kapcsolódó cikkek

Miért nem szabad a fejlesztőnek a saját kódját tesztelnie?

A fejlesztő megírja a funkciót. Megírja hozzá a teszteket is – alaposan, lelkiismeretesen. Minden teszt zöld. A kód átmegy a pipeline-on, kimegy élesbe. Két héttel később a rendszer elhasal egy olyan eseten, amire senki nem gondolt. A tesztek nem hazudtak. Egyszerűen nem a jó kérdést tették fel. Ez a cikk nem arról szól, hogy a

Mennyi pénzbe kerül egy későn megtalált hiba?

Képzeljünk el egy egyetlen félreérthető mondatot egy több száz oldalas követelményspecifikációban. A mondat egy kerekítési szabályról szól, és kétféleképpen is értelmezhető. A fejlesztő az egyik értelmezés szerint kódolja le – teljesen logikusan, jóhiszeműen, a saját olvasata alapján. Ha ezt a mondatot valaki a specifikáció átolvasásakor megkérdőjelezi, a „javítás” költsége nagyjából tíz perc: egy tisztázó kérdés

A tesztelés nem költség, hanem bevételvédelem

Képzeljünk el egy hétfő reggeli vezetői értekezletet, ahol a pénzügyi igazgató (CFO) a negyedéves költségvetést vizsgálva megáll a „Minőségbiztosítás (QA) és Szoftvertesztelés” sornál. „Miért költünk ennyit arra, hogy hibákat keressünk a kódunkban? Nem lenne egyszerűbb, ha a fejlesztőink eleve jobban figyelnének, és hibátlan kódot adnának ki?” – hangzik el a klasszikus kérdés. Ez a felvetés

Scroll to Top