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

Hogyan csökkenti a Blind CV a felvételi kockázatot?

A sorozatunk előző részeiben megvizsgáltuk a Blind CV (anonim önéletrajz) módszertan gyakorlati működését (Blind CV a tesztelői staffingban), és beszéltünk a staffing sebességéről. Most azonban egy lépéssel hátrébb lépünk, és a projektmenedzsment egyik legkritikusabb területére fókuszálunk: a kockázatkezelésre. Bármely IT vezető megerősítheti: a szoftverfejlesztés egyik legnagyobb kockázata nem a technológia, hanem az emberi tényező. A rossz

Blind CV a tesztelői staffingban – miért működik?

Bevezetés Az előző cikkünkben (Gyors tesztelői kapacitásbővítés) már érintettük azt a „pánikhelyzetet”, amikor a projektnek tegnapra kellene ember. Ilyenkor a kapkodás a legnagyobb ellenség, és gyakran pont a hagyományos, lassú kiválasztási folyamatok állnak a gyors tűzoltás útjába. Itt jön a képbe a Blind CV (anonim önéletrajz), amiről korábban már írtunk a kockázatcsökkentés kapcsán (Blind CV a

Gyors tesztelői kapacitásbővítés (QA Staffing) – 5 tipikus hiba, amivel elégeted a büdzsét

Bevezetés A projekt késésben van. A határidő vészesen közeleg. A menedzsment ideges. Mi az első reflex? „Fel kell vennünk még embert! Tegnapra!” Ismerős a helyzet? Valószínűleg mindenki találkozott már vele, aki dolgozott IT projektben. A pánikgomb megnyomása ilyenkor természetes reakció. Az extra erőforrás bevonása valóban életmentő lehet, de csak akkor, ha okosan csináljuk. A kapkodó, előkészítetlen

Scroll to Top