Adatvezérlés 2.

Bevezető

Ez a rész a problémáról fog szólni. Akik nem szeretik a sorozat végi cliffhanger okozta feszültséget, várják meg az olvasással a hamarosan megjelenő következő részt, ahol a gonosz probléma elnyeri méltó megoldását. Az előző rész pedig itt található: Adatvezérlés 1.

Gonosz probléma

Van egy Python programunk, ami elég egyszerű, parancssoros programocska. A feladata, hogy argumentumnak megadott három hosszértékről eldöntse, hogy lehetnek-e egy háromszög oldalai. A program kimenete vagy az, hogy „triangle” (háromszög), vagy az, hogy „not triangle” (nem háromszög).

Itt kérek elnézést azoktól, akik a matekot nem kedvelik, ígérem kíméletesen járok el. Egyszerű leszek és nélkülözni fogom a matematika kíméletlen szakmai nyelvezetét.

Szóval három hosszérték akkor alkothat háromszöget, ha bármelyik kettő összege nagyobb a harmadiknál. Ez egyszerű, de mégsem biztos, hogy a programozónak sikerült hibamentesen megvalósítani a megoldást. (Spoiler: a program hibás! 🙂 )

Így tudod kipróbálni parancssorból:

Ennek az eredménye az lesz, hogy „triangle”, mivel

  • 3+4 > 5,
  • 3+5 > 4 és
  • 4+5 > 3 is igaz.

Ez esetben jól működik a program.

Robot Framework első nekifutás

Ahhoz, hogy tudjuk parancssorból futtatni az is_trangle.py programot, szükségünk lesz a „Process” könyvtárra:

Ha megvizsgáljuk a Process könyvtár adta lehetőségeket, hamar megtaláljuk a megoldást (triangle_test.robot):

Az is_triangle.py programot a triangle_test.robot állomány mellé kell tenni és futtatható a teszt. A teszt működése:

  • A „Run Process” kulcsszó lefuttatja a kívánt parancssori utasítást a paraméterkekkel és az eredményt a ${result} változóba írja. 
  • A „Shuold Be Equal” kulcsszó összehasonlítja a kimenet szöveg részét (${result.stdout}) az elvárt eredménnyel, ami: „triangle”.
  • Ha a két összehasonlított érték
    • megegyezik, akkor a teszt végeredménye „PASS”,
    • ha nem egyezik meg, akkor azt írja ki, hogy: „Expected result: „triangle”, but the actual result not triangle”.
  • A False paraméter azért kell a végén, mert saját hibaüzenetet akarunk kiíratni.

Szépítés

Az előző megoldás nagyon fapados és a teszteset „olvashatatlan” ezért elvégezzük az alapvető átalakításokat, hogy mindenki meg legyen elégedve a munkánkkal.

  • A „csúnya részt” áttesszük kulcsszóba,
  • az oldalak hosszát és az elvárt eredményt paraméterként kezeljük,

Miért nem jó ez nekünk?

Ezzel a módszerrel így néz ki a teljes kód:

Ez jó megoldás, de nem ez lesz a legjobb lehetőségünk. Ha új tesztadatokkal is szeretnénk végrehajtani a tesztet, akkor sokszorozni kell ugyanazt a tesztesetet. Márpedig szeretnénk más tesztadatokkal is megvizsgálni, mert jó tesztelők vagyunk.

Tesztesetek

Egy kis ekvivalencia osztályozással hamar eszünkbe jutnak a következő esetek. (Remélem nektek ennél több is eszetekbe jut! J)

Oké, ez itt csak összesen 6 eset. Ennyi lehetőségnél még gondolhatjuk azt, hogy nem túl nagy ár megírni a 6 esetet külön-külön. De ez csak egy példázat. Az előző cikkben említett 2000 felhasználó aktiválására biztos nem jó megoldás 2000 tesztesetet írni.

Cliffhanger

Pont az ilyen helyzetek mentőöve az adatvezérlés.

A következő részben megtudhatjuk, hogy a hős adatvezérlés hogyan győzte le a gonosz problémát Robot Frameworkben.

Addig is: Jó tesztet!

Hajrá!

Megosztás

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

Kapcsolódó cikkek

20 év szoftvertesztelés után ezt látjuk minden sikeres szoftverprojektben

Húsz év és több száz projekt után az ember már nem az egyedi eseteket jegyzi meg, hanem az ismétlődő mintákat. A legérdekesebb felismerés az, hogy a sikeres szoftverprojektek mennyire hasonlítanak egymásra. Más az iparág, más a technológia, más a csapat, mégis ugyanazok az elvek térnek vissza bennük, újra és újra. A kudarcok ezzel szemben mind

T&M vagy fix projekt? Melyik tesztelési modell mikor működik jobban?

Amikor egy cég külső tesztelési partnert von be, az egyik legkorábbi kérdés nem szakmai, hanem pénzügyi: milyen konstrukcióban dolgozzunk együtt? A válasz sokszor a beszerzési reflexből születik: „adjatok egy fix árat, hogy tudjam, mennyibe kerül”. Érthető igény, de nem mindig a legjobb döntés. A fix ár és a másik klasszikus modell, a T&M (Time and

Scroll to Top

Elérhető tesztelőink

Nézze meg szakértőink profiljait, tapasztalatát és kompetenciáit, és találja meg a projektjéhez illő szakembert.

Töltse le tesztelőink szakmai profilját

Adja meg elérhetőségét egyszer és férjen hozzá valamennyi elérhető profilhoz.