Helló, Habr!
A nevem Maxim Ponomarenko, és a Sportmasternél dolgozom fejlesztőként. 10 éves tapasztalatom van az IT szektorban. A karrierem a manuális tesztelés területén kezdtem, majd az adatbázisok fejlesztésére váltottam. Az utolsó 4 évben, a tesztelés és fejlesztés során megszerzett tudásaimat összegyűjtve, az adatbázis szintű tesztelés automatizálásával foglalkozom.
A Sportmaster csapatában több mint egy éve dolgozom, és egy nagyobb projekt keretében automatizált tesztelés fejlesztésén dolgozom. Áprilisban a Sportmaster Lab csapatával részt vettünk egy konferencián Krasznodárban, ahol az előadásom címe „Unit-tesztek az adatbázisokban” volt, és most ezt szeretném megosztani veletek. Sok szövegre számíthattok, ezért úgy döntöttem, hogy az előadásomat két bejegyzésre bontom. Az elsőben az automatizált tesztekről és a tesztelésről általában beszélünk, míg a másodikban részletesebben megállok a mi unit-tesztelési rendszerünknél és annak alkalmazásának eredményeinél.
Kezdjük egy kicsit unalmas elmélettel. Mi az automatizált tesztelés? Olyan tesztelés, amelyet szoftveres eszközökkel végeznek, és a modern IT világában egyre gyakrabban alkalmazzák szoftverfejlesztés során. Ennek az az oka, hogy a cégek növekednek, az információs rendszereik fejlődnek, és ezzel együtt nő az tesztelendő funkciók száma is. A manuális tesztelés végzése egyre költségesebb és időigényesebb.
Dolgoztam egy nagy cégnél, ahol a kiadások két havonta történtek. Egy hónapot töltöttek azzal, hogy egy tucat tesztelő kézzel ellenőrizze a funkciókat. Az automatizálás bevezetésének köszönhetően, egy kis fejlesztőcsapattal másfél év alatt a tesztelési időt 2 hétre tudtuk csökkenteni. Nemcsak a tesztelés sebességét növeltük, hanem a minőségét is. Az automatikus tesztek rendszeresen futnak, és mindig végrehajtják az összes beépített ellenőrzést, tehát kizárjuk az emberi tényezőt.
A modern IT egyik jellemzője, hogy a fejlesztőtől nemcsak a termék kódolását várják el, hanem unit-teszteket is kell írnia, amelyek ellenőrzik ezt a kódot.
De mit tegyünk, ha a rendszerünk főleg szerveroldali logikára épül? Nem létezik egyetemes megoldás vagy bevált gyakorlat a piacon. Általában a cégek saját, egyedi tesztelési rendszerek létrehozásával oldják meg ezt a problémát. A mi projektünkben is létrehoztunk egy ilyen egyedi automatizált tesztelési rendszert, amelyről a beszámolómban mesélek.
Lojalitás tesztelése
Először is beszéljünk arról a projektről, ahol az automatizált tesztelési rendszert bevezettük. A mi projektünk a Sportmaster hűségprogramja (mellesleg már írtunk róla a ).
Ha a cége elég nagy, a hűségprogramja három standard jellemzővel fog rendelkezni:
- A rendszer intenzív terhelés alatt fog működni
- A rendszer bonyolult számítási folyamatokat fog tartalmazni
- A rendszer folyamatosan fejlesztés alatt lesz.
Rendben, nézzük sorjában… Összességében, ha figyelembe vesszük a Sportmaster összes márkáját, Oroszország, Ukrajna, Kína, Kazahsztán és Fehéroroszország területén több mint 1000 boltunk van. Ezekben a boltokban naponta körülbelül 300 000 vásárlás történik. Tehát másodpercenként 3-4 blokk érkezik a rendszerünkbe. Természetesen a hűségprogramunk erősen terhelt. Mivel aktívan használják, a legmagasabb minőségi normákat kell biztosítanunk, hiszen bármilyen programhibának komoly pénzügyi, hírnévbeli és egyéb veszteségei vannak.
A Sportmasternél egy időben több mint száz különböző akció is zajlik. Az akciók nagyon változatosak: vannak termékekhez kötöttek, vannak a hét napjához kapcsolódók, vannak konkrét boltokra vonatkozóak, akciók a blokk összegére, és a mennyiségre vonatkozó akciók. Igazán komoly. Az ügyfeleknek vannak bónuszaik, és promóciós kódjaik, amelyeket a vásárlások során használnak. Mindez azt eredményezi, hogy bármely rendelés kiszámítása rendkívül nem triviális feladat.
A rendelésfeldolgozást megvalósító algoritmus igazán borzalmas és bonyolult. Bárminemű módosítás az algoritmusban meglehetősen kockázatos dolog. Úgy tűnik, hogy a legkülsőleg jelentéktelen változtatások is elegendőek ahhoz, hogy meglehetősen kiszámíthatatlan hatásokhoz vezessenek. Pedig ezek a bonyolult számítási folyamatok, különösen azok, amelyek kritikus funkciót valósítanak meg – a legjobb jelöltek az automatizálásra. Kézi ellenőrzése több tucat azonos típusú esetnek igazán időigényes. Mivel a folyamat belépési pontja változatlan, egyszeri leírás után viszonylag gyorsan előállíthatjuk az automatikus teszteket, és biztosak lehetünk a funkció működésében.
Mivel a rendszerünket aktívan használják, a vállalkozás új dolgokat vár tőletek, lépést tartva az idővel és ügyfélközpontúnak lenni. A hűségprogramunkban a kiadások kétévente következnek be. Tehát kétévente kötelező teljes regressziót végezni az egész rendszeren. Ugyanakkor, természetesen, mint bármely modern IT területen, a fejlesztés nem kerül közvetlenül a fejlesztőtől a termelésbe. A fejlesztő kontúron kezdődik, majd fokozatosan áthalad a tesztkörnyezeten, a kiadási, az elfogadó környezete, és csak ezután kerül a termelésbe. Legalább a teszt- és kiadókörnyezeteken kötelező teljes regressziót végezni az egész rendszeren.
A fent leírt tulajdonságok gyakorlatilag bármely hűségprogramra érvényesek. Beszéljünk a projektünk sajátosságairól.
Technológiai szempontból a hűségprogramunk logikájának 90%-a szerveroldali, és Oracle-on valósították meg. Van egy Delphi alapú kliens, amely az APM-adminisztrátor funkciót látja el. Külső alkalmazások számára webszolgáltatásokat is biztosítunk (például weboldal). Ezért nagyon logikus, hogy ha automatizált tesztelési rendszert akarunk kiépíteni, akkor ezt Oracle-on kell tennünk.
A Sportmaster-nél már több mint 7 éve működik a hűségprogram, amelyet egyedi fejlesztők hoztak létre… Az elmúlt 7 év során a projektünkhöz átlagosan 3-4 fejlesztő csatlakozott. Azonban az utolsó évben a csapatunk jelentősen megnövekedett, és most már 10 ember dolgozik a projekten. Ez azt jelenti, hogy olyan emberek érkeznek a projekthez, akik nincsenek tisztában a tipikus feladatokkal, folyamatokkal és architektúrával. Itt megnövekedett a kockázata annak, hogy hibákat fogunk elszalasztani.
A projektre jellemző, hogy nincsenek dedikált tesztelők mint állandó munkavállalók. A tesztelés természetesen zajlik, de ezt az analitikusok végzik, a többi fő feladatuk mellett: a business ügyfelekkel való kommunikáció, a felhasználói interakciók, a rendszer követelményeinek kidolgozása stb. Annak ellenére, hogy a tesztelés rendkívül alapos (különösen érdemes megemlíteni, mivel az analitikusok közül valakinek szembe jöhet ez a jelentés), senki sem vitathatja a specializáció és a fókusz jelentőségét egy adott feladatra.
Figyelembe véve az eddigieket, a kibocsátott termék minőségének javítása és a fejlesztési idő csökkentése érdekében a tesztelés automatizálásának ötlete nagyon logikusnak tűnik. A hűségprogram különböző szakaszaiban különböző fejlesztők tettek erőfeszítéseket, hogy a kódjukat egység tesztekkel lefedjék. Ez egy meglehetősen szétszórt folyamat volt, ahol mindenki a saját architektúráját és módszereit használta. Az egységtesztek közös végső eredménye az volt: a tesztek kidolgozva, egy ideig használva, fájlverziós tárolóba helyezve, de egy idő után nem futottak már és feledésbe merültek. Ez elsősorban amiatt történt, hogy a tesztek inkább a konkrét végrehajtóra voltak szabva, nem pedig a projektre.
Segítségünkre van az utPLSQL
Tud valamit Stephen Feuersteinről?
Ő egy okos ember, aki karrierje jelentős részét az Oracle-lel és a PL/SQL-lel való munkára szentelte, és emellett számos művet írt erről a témáról. Az egyik legismertebb könyve így nevezik: „Oracle PL/SQL. Szakembereknek”. Stephen nevéhez fűződik az utPLSQL megoldás kidolgozása, vagyis az Unit Testing framework for Oracle PL/SQL. Az utPLSQL megoldást 2016-ban hozták létre, de továbbra is aktívan dolgoznak rajta, és új verziókat bocsátanak ki. A beszámoló időpontjában az utolsó verzió 2019. március 24-i dátumban került kiadásra.
De mi is ez valójában? Ez egy külön projekt, amely nyílt forráskódú. Néhány megabájtot foglal el, beleértve példákat és dokumentációt. Fizikailag egy külön sémaként jelenik meg az ORACLE adatbázisban, amely csomagok és táblák halmazát tartalmazza az egységtesztelés megszervezésére. A telepítés néhány másodpercet vesz igénybe. Az utPLSQL kiemelkedő jellemzője a használatának egyszerűsége.
Globálisan az utPLSQL egy mechanizmus az egységtesztek futtatására, ahol az egységteszt alatt a szokásos Oracle csomagprocedúrák értendők, amelyek szervezésére bizonyos szabályok vonatkoznak. Az utPLSQL-ben nemcsak a tesztelési indításokat tárolják, hanem van egy belső jelentési rendszer is.
Nézzük meg például, hogyan néz ki egy egységteszt kódja, amelyet ezen módszer szerint valósítottak meg.
Az előtérben a csomag tipikus specifikációjának kódja látható egységtesztekkel. Mik az elvített követelmények? A csomagnak „utp_” előtaggal kell rendelkeznie. Ugyanazzal az előtaggal kell rendelkeznie minden tesztprocedúrának is. A csomagban kötelezően két standard eljárásnak kell szerepelnie: „utp_setup” és „utp_teardown”. Az első eljárás minden egységteszt újraindításakor kerül meghívásra, a második - a futtatás után.
Az „utp_setup” általában felkészíti a rendszert az egységteszt indítására, például tesztadatokat hoz létre. Az „utp_teardown” viszont mindent visszaállít az alapbeállításokra, és törli a futtatás eredményeit.
Ez egy példa a legegyszerűbb unit-tesztre, amely a kliens által megadott telefonszám normalizálását ellenőrzi, hogy az megfeleljen a hűségprogramunk standard formátumának. Nincsenek kötelező standardok arra vonatkozóan, hogyan kell unit-teszteket írni. Általában egy tesztelt rendszer egyik metódusát hívjuk meg, és az e metódus által visszaadott eredményt összehasonlítjuk egy referenciaértékkel. Fontos, hogy az összehasonlítás referenciaként használt eredmény és a kapott eredmény között standard utPLSQL-módszerekkel történjen.
A unit-teszt során bármennyi ellenőrzés végezhető. Ahogy a példából is látszik, négy egymást követő hívást végzünk a telefon szám normalizáló tesztelt metódusán, és minden hívás után értékeljük az eredményt. Unit-teszt készítésekor figyelembe kell venni, hogy léteznek olyan ellenőrzések, amelyek nem befolyásolják a rendszert, és bizonyosak után vissza kell állni a rendszer kezdeti állapotába.
Például a bemutatott unit-tesztben egyszerűen formázzuk a belépő telefonszámot, ami nem befolyásolja a hűségprogramot.
De ha új kliens létrehozására vonatkozó unit-teszteket írunk, akkor minden ellenőrzés után új kliens kerül a rendszerbe, ami befolyásolhatja a tesztek későbbi futtatását.
Így futnak a unit-tesztek. Kétféle futtatás elfogadható: az összes unit-teszt indítása egy adott csomagból, vagy egy adott unit-teszt végrehajtása egy adott csomagban.
Ez így néz ki a belső jelentési rendszer példájában. Az utPLSQL unit-tesztjeinek futása után egy kis jelentés készül. Ebben láthatjuk az egyes ellenőrzések eredményét és a unit-teszt összesített eredményét.
6 automatizált teszt szabály
Mielőtt új automatizált tesztelési rendszert kezdtünk volna el létrehozni a hűségprogram számára, közösen a menedzsmenttel meghatároztuk az elveket, amelyeknek a jövőbeli automatizált tesztjeinknek meg kell felelniük.
- Az automatizált teszteknek hatékonyaknak kell lenniük, és valóban hasznot kell hozniuk. Kiváló fejlesztőink vannak, akikről mindenképpen beszélni kell, hiszen közülük biztosan többen látni fogják ezt az előadást, és csodálatos kódot írnak. De még a csodálatos kódjuk sem tökéletes, és hibákat tartalmazott, tartalmaz és tartalmazni fog. Az automatizált teszteknek ezeket a hibákat kell felfedezniük. Ha ez nem így van, akkor vagy rossz automatizált teszteket írunk, vagy egy olyan holt pontban vagyunk, amely alapvetően nem fejlődik. Mindkét esetben valamit rosszul csinálunk, és a megközelítésünk értelmetlen.
- Az automatizált teszteket használni kell. Haszontalan rengeteg időt és energiát pazarolni egy szoftvertermék megírására, összerakni a repozitóriumát, majd elfelejteni. A teszteket futtatni kell, és minél rendszeresebben.
- Az automatizált teszteknek stabilan kell működniük. Függetlenül az időponttól, a tesztelési környezettől és a rendszer egyéb beállításaitól, a tesztfutásoknak mindig ugyanazt az eredményt kell adniuk. Ez általában úgy biztosított, hogy az automatizált tesztek speciális tesztadatokkal dolgoznak, rögzített rendszerbeállításokkal.
- Az automatizált teszteknek a projekted számára elfogadható sebességgel kell működniük. Ez az idő minden rendszer esetében egyedi. Valaki dolgozhat egész nap, míg másoknak másodpercekbe kell beleférniük. Milyen sebességi normákat értünk el a projektünkben, azt később elmondom.
- Az automatizált tesztek fejlesztésének rugalmasnak kell lennie. Nem ajánlott lemondani bármilyen funkcióellenőrzésről csak azért, mert még soha nem csináltuk, vagy valamilyen más meggyőződés miatt. Az utPLSQL nem helyez el korlátozásokat a fejlesztésre, míg az Oracle alapvetően lehetővé teszi a legkülönbözőbb dolgok megvalósítását. A legtöbb feladatnak van megoldása, csak idő kérdése és a ráfordított erőfeszítéseké.
- Bevethetőség. Több tesztkörnyezetünk van, ahol szükség van tesztek futtatására. Minden egyes tesztkörnyezetben bármikor frissíthető az adatmentés. A projektet automatizált tesztekkel úgy kell irányítani, hogy legyen lehetőség a teljes vagy részleges telepítés fájdalommentes végrehajtására.
A második bejegyzésben néhány nap múlva elmondom, mit tettünk és milyen eredményeket értünk el.
Forrás: habr.com
