Szia Habr!
A nevem Maxim Ponomarenko, és fejlesztő vagyok a Sportmasternél. 10 éves tapasztalattal rendelkezem IT területen. Pályáját kézi teszteléssel kezdte, majd áttért az adatbázis-fejlesztésre. Az elmúlt 4 évben a tesztelés és fejlesztés során megszerzett tudást felhalmozva automatizálom a tesztelést DBMS szinten.
Alig több mint egy éve vagyok a Sportmaster csapatában, és automatizált tesztelést fejlesztek az egyik nagy projekthez. Áprilisban a Sportmaster Lab srácai és én felszólaltunk egy krasznodari konferencián, a jelentésem az „Egységtesztek DBMS-ben” címet viselte, és most szeretném megosztani veletek. Sok lesz a szöveg, ezért úgy döntöttem, hogy a jelentést két bejegyzésre osztom. Az elsőben az autotesztekről és általában a tesztelésről lesz szó, a másodikban pedig részletesebben kitérek egységtesztelési rendszerünkre és alkalmazásának eredményeire.
Először is egy kicsit unalmas elmélet. Mi az automatizált tesztelés? Ez egy szoftverrel végzett tesztelés, amelyet a modern IT-ben egyre inkább a szoftverfejlesztésben alkalmaznak. Ez annak köszönhető, hogy a vállalatok növekednek, információs rendszereik bővülnek, és ennek megfelelően nő a tesztelésre váró funkcionalitás mennyisége. A kézi tesztelés lefolytatása egyre drágább.
Egy nagy cégnél dolgoztam, amelynek kéthavonta jelennek meg kiadványai. Ugyanakkor egy egész hónapot azzal töltöttek, hogy egy tucat tesztelő manuálisan ellenőrizte a működőképességet. Egy kis fejlesztői csapat által végrehajtott automatizálásnak köszönhetően másfél év alatt 2 hétre tudtuk csökkenteni a tesztelési időt. Nemcsak a tesztelés sebességét növeltük, hanem a minőségét is javítottuk. Az automatizált tesztek rendszeresen indulnak, és mindig elvégzik az abban foglalt teljes ellenőrzési folyamatot, azaz kizárjuk az emberi tényezőt.
A modern informatika jellemzője, hogy a fejlesztőtől nem csak termékkódot kell írni, hanem olyan egységteszteket is, amelyek ezt a kódot ellenőrzik.
De mi van akkor, ha a rendszere elsősorban szerverlogikára épül? Nincs univerzális megoldás vagy legjobb gyakorlat a piacon. Általában a cégek ezt a problémát úgy oldják meg, hogy saját maguk által írt tesztelési rendszert hoznak létre. Ez egy saját, saját készítésű automatizált tesztelési rendszerünk, amelyet a projektünk során hoztunk létre, és erről a beszámolómban fogok beszélni.
A hűség tesztelése
Először is beszéljünk a projektről, amelyben egy automatizált tesztelőrendszert telepítettünk. Projektünk a Sportmaster hűségrendszer (egyébként már írtunk róla ben ).
Ha cége elég nagy, akkor a hűségrendszere három szabványos tulajdonsággal rendelkezik:
- A rendszer nagyon le lesz terhelve
- A rendszere összetett számítási folyamatokat fog tartalmazni
- Rendszerét aktívan fejlesztjük.
Menjünk sorban... Összességében, ha az összes Sportmaster márkát figyelembe vesszük, akkor több mint 1000 üzletünk van Oroszországban, Ukrajnában, Kínában, Kazahsztánban és Fehéroroszországban. Naponta körülbelül 300 000 vásárlás történik ezekben az üzletekben. Azaz minden második 3-4 csekk bekerül a rendszerünkbe. Hűségrendszerünk természetesen nagyon leterhelt. És mivel aktívan használják, a legmagasabb minőségi színvonalat kell biztosítanunk, mert a szoftver bármilyen hibája jelentős anyagi, hírnév- és egyéb veszteséget jelent.
A Sportmaster ugyanakkor több mint száz különböző promóciót futtat. Különféle akciók vannak: vannak termékakciók, vannak a hét napjára szabott, vannak konkrét üzlethez kötöttek, vannak a nyugta összegére, vannak az áruk darabszámára. Általában véve nem rossz. Az ügyfelek bónuszokat és promóciós kódokat kapnak, amelyeket vásárláskor használnak fel. Mindez oda vezet, hogy bármilyen sorrend kiszámítása nagyon nem triviális feladat.
A rendelésfeldolgozást megvalósító algoritmus valóban szörnyű és bonyolult. És ezen algoritmus bármilyen változtatása meglehetősen kockázatos. Úgy tűnt, hogy a legjelentéktelenebbnek tűnő változtatások egészen beláthatatlan hatásokhoz vezethetnek. De pontosan az ilyen összetett számítási folyamatok, különösen azok, amelyek kritikus funkciókat valósítanak meg, a legjobb jelöltek az automatizálásra. Több tucat hasonló eset kézi ellenőrzése nagyon időigényes. És mivel a folyamat belépési pontja változatlan, miután egyszer leírta, gyorsan létrehozhat automatikus teszteket, és biztos lehet benne, hogy a funkcionalitás működni fog.
Mivel rendszerünket aktívan használják, a vállalkozás újat akar tőled, élni a korral és ügyfélközpontú lesz. Hűségrendszerünkben a kiadások kéthavonta jelennek meg. Ez azt jelenti, hogy kéthavonta el kell végeznünk a teljes rendszer teljes regresszióját. Ugyanakkor természetesen, mint minden modern IT-ben, a fejlesztés sem halad át azonnal a fejlesztőtől a gyártásig. A fejlesztői áramkörről származik, majd egymás után áthalad a tesztpadon, kiadáson, átvételen, és csak ezután kerül a gyártásba. A teszt- és kioldási áramkörökön legalább a teljes rendszer teljes regresszióját kell végrehajtanunk.
A leírt tulajdonságok szinte minden hűségrendszerhez szabványosak. Beszéljünk projektünk jellemzőiről.
Technológiailag hűségrendszerünk logikájának 90%-a szerver alapú, és az Oracle-en van megvalósítva. A Delphiben van egy kliens, amely az automatizált munkahelyi rendszergazda funkcióját látja el. Vannak elérhető webszolgáltatások külső alkalmazásokhoz (például egy webhelyhez). Ezért nagyon logikus, hogy ha automatizált tesztelőrendszert telepítünk, akkor azt Oracle-en fogjuk megtenni.
A Sportmaster hűségrendszere már több mint 7 éve létezik, és egyedi fejlesztők hozták létre... A projektünkben a fejlesztők átlagos száma ez alatt a 7 év alatt 3-4 fő volt. Az elmúlt év során azonban csapatunk jelentősen bővült, és mára 10 ember dolgozik a projekten. Vagyis olyan emberek jönnek a projektbe, akik nem ismerik a tipikus feladatokat, folyamatokat és architektúrát. És megnövekszik annak a veszélye, hogy kihagyunk hibákat.
A projektre jellemző, hogy hiányoznak a dedikált tesztelők, mint személyzeti egységek. Természetesen van tesztelés, de a tesztelést elemzők végzik, amellett, hogy más fő feladataik: kommunikáció az üzleti ügyfelekkel, felhasználókkal, rendszerkövetelmények fejlesztése stb. stb... Annak ellenére, hogy a tesztelést nagyon jó minőségben végzik (ezt különösen illik megemlíteni, mert néhány elemzőnek feltűnhet ez a jelentés), a specializáció és az egy dologra való összpontosítás hatékonysága nem törlődött .
A fentieket figyelembe véve a leszállított termék minőségének javítása és a fejlesztési idő csökkentése érdekében a projekt tesztelésének automatizálásának ötlete nagyon logikusnak tűnik. A hűségrendszer létezésének különböző szakaszaiban pedig az egyes fejlesztők erőfeszítéseket tettek, hogy kódjukat egységtesztekkel fedjék le. Összességében ez egy meglehetősen széttagolt folyamat volt, mindenki a saját architektúráját és módszereit használta. A végeredmények az egységteszteknél közösek voltak: teszteket fejlesztettek ki, használtak egy ideig, tárolták egy változatos fájltárolóban, de valamikor leálltak a futásuk és feledésbe merültek. Ez mindenekelőtt annak volt köszönhető, hogy a tesztek inkább egy konkrét előadóhoz, és nem a projekthez kötöttek.
Az utPLSQL segít
Tudsz valamit Stephen Feuersteinről?
Ez egy okos srác, aki karrierje hosszú részét az Oracle-lel és a PL/SQL-lel való munkának szentelte, és meglehetősen sok munkát írt ebben a témában. Egyik híres könyve a következő: „Oracle PL/SQL. Profiknak." Stephen volt az, aki kifejlesztette az utPLSQL-megoldást, vagy ahogyan ez jelenti a Unit Testing keretrendszert az Oracle PL/SQL-hez. Az utPLSQL megoldást 2016-ban hozták létre, de továbbra is aktívan dolgoznak rajta, és új verziók jelennek meg. A jelentés időpontjában a legújabb verzió 24. március 2019-re nyúlik vissza.
Mi az. Ez egy külön nyílt forráskódú projekt. Súlya néhány megabájt, beleértve a példákat és a dokumentációt. Fizikailag ez egy külön séma az ORACLE adatbázisban csomagokkal és táblákkal az egységtesztek megszervezéséhez. A telepítés néhány másodpercet vesz igénybe. Az utPLSQL megkülönböztető jellemzője az egyszerű használat.
Globálisan az utPLSQL egy egységtesztek futtatására szolgáló mechanizmus, ahol az egységteszt alatt szokásos Oracle kötegelt eljárásokat értünk, amelyek szervezése bizonyos szabályokat követ. Az indításon kívül az utPLSQL tárolja az összes tesztfutás naplóját, és rendelkezik egy belső jelentési rendszerrel is.
Nézzünk egy példát arra, hogyan néz ki az egységteszt kód, ezzel a technikával megvalósítva.
Tehát a képernyőn megjelenik egy tipikus csomagspecifikáció kódja egységtesztekkel. Mik a kötelező követelmények? A csomagot "utp_" előtaggal kell ellátni. Minden teszttel végzett eljárásnak pontosan ugyanazzal az előtaggal kell rendelkeznie. A csomagnak két szabványos eljárást kell tartalmaznia: „utp_setup” és „utp_teardown”. Az első eljárást az egyes egységtesztek újraindításával hívják meg, a másodikat az indítás után.
Az „utp_setup” rendszerint felkészíti rendszerünket egy egységteszt futtatására, például tesztadatok létrehozására. „utp_teardown” - éppen ellenkezőleg, minden visszatér az eredeti beállításokhoz, és visszaállítja az indítási eredményeket.
Íme egy példa a legegyszerűbb egységtesztre, amely ellenőrzi a megadott ügyfél telefonszám normalizálását a törzsvásárlói rendszerünk szabványos űrlapjára. Nincsenek kötelező szabványok az eljárások egységtesztekkel történő megírására. Általában a tesztelt rendszer metódusát hívják meg, és az ezzel a módszerrel visszaadott eredményt összehasonlítják a referencia módszerrel. Fontos, hogy a referencia eredmény és a kapott eredmény összehasonlítása szabványos utPLSQL metódusokon keresztül történjen.
Egy egységteszt tetszőleges számú ellenőrzést tartalmazhat. Amint a példából látható, négy egymást követő hívást kezdeményezünk a tesztelt módszerrel, hogy normalizáljuk a telefonszámot, és minden hívás után kiértékeljük az eredményt. Az egységteszt kidolgozásakor figyelembe kell venni, hogy vannak olyan ellenőrzések, amelyek semmilyen módon nem érintik a rendszert, és néhány után vissza kell térni a rendszer eredeti állapotába.
Például a bemutatott egységtesztben egyszerűen formázzuk a bevitt telefonszámot, ami semmilyen módon nem befolyásolja a hűségrendszert.
Ha pedig egységteszteket írunk egy új kliens létrehozásának módszerével, akkor minden teszt után egy új kliens jön létre a rendszerben, ami befolyásolhatja a teszt későbbi elindítását.
Így futnak az egységtesztek. Két lehetséges indítási lehetőség van: az összes egységteszt futtatása egy adott csomagból vagy egy adott egységteszt futtatása egy adott csomagban.
Így néz ki egy példa egy belső jelentési rendszerre. Az egységteszt eredményei alapján az utPLSQL egy kis jelentést készít. Ebben látjuk az egyes konkrét ellenőrzések eredményét és az egységteszt összesített eredményét.
Az automatikus tesztek 6 szabálya
A hűségrendszer automatizált tesztelésére szolgáló új rendszer létrehozásának megkezdése előtt a menedzsmenttel közösen meghatároztuk azokat az elveket, amelyeknek a jövőbeni automatizált tesztjeinknek meg kell felelniük.
- Az automatikus teszteknek hatékonynak és hasznosnak kell lenniük. Vannak csodálatos fejlesztőink, akiket feltétlenül meg kell említeni, mert néhányan valószínűleg látni fogják ezt a jelentést, és csodálatos kódot írnak. De még a csodálatos kódjuk sem tökéletes, és vannak, vannak és továbbra is tartalmazni fog hibákat. Ezeknek a hibáknak a megtalálásához automatikus tesztekre van szükség. Ha ez nem így van, akkor vagy rossz autoteszteket írunk, vagy olyan holt területre jutottunk, ami elvileg nem fejlesztés alatt áll. Mindkét esetben valamit rosszul csinálunk, és a megközelítésünknek egyszerűen nincs értelme.
- Automatikus teszteket kell használni. Nincs értelme sok időt és erőfeszítést költeni egy szoftvertermék megírására, raktárba helyezni és elfelejteni. A teszteket a lehető leggyakrabban kell lefuttatni.
- Az automatikus teszteknek stabilan kell működniük. A napszaktól, az indítóállványtól és egyéb rendszerbeállításoktól függetlenül a tesztfutásoknak ugyanarra az eredményre kell vezetniük. Ezt általában az a tény biztosítja, hogy az automatikus tesztek speciális tesztadatokkal működnek, rögzített rendszerbeállításokkal.
- Az automatikus teszteknek a projektje számára elfogadható sebességgel kell működniük. Ez az idő rendszerenként egyedileg kerül meghatározásra. Vannak, akik megengedhetik maguknak, hogy egész nap dolgozzanak, míg mások kritikus fontosságúnak tartják, hogy ezt másodpercek alatt végezzék el. Kicsit később elmondom, milyen sebességi szabványokat értünk el a projektünk során.
- Az automatikus tesztelés fejlesztésének rugalmasnak kell lennie. Nem tanácsos megtagadni a funkcionalitás tesztelését pusztán azért, mert korábban még nem tettük meg, vagy valamilyen más okból. Az utPLSQL nem szab semmilyen korlátozást a fejlesztésre, az Oracle pedig elvileg sokféle dolog megvalósítását teszi lehetővé. A legtöbb problémára van megoldás, csak idő és erőfeszítés kérdése.
- Telepíthetőség. Több standunk is van, ahol teszteket kell futtatnunk. Minden standnál bármikor frissíthető egy adatkiírás. A projektet automatikus tesztekkel kell végrehajtani oly módon, hogy fájdalommentesen elvégezhesse a teljes vagy részleges telepítést.
A pár napon belüli második bejegyzésben pedig elmondom, hogy mit csináltunk és milyen eredményeket értünk el.
Forrás: will.com