🥇Unit tesztek az adatbázisban - hogyan csináljuk ezt a Sportmesternél, második rész

Első rész — itt.

Képzeljünk el egy helyzetet. Ön előtt egy új funkció fejlesztésének feladata áll. Ön rendelkezik a korábbi munkatársak eredményeivel. Ha feltételezzük, hogy nincsenek erkölcsi kötelezettségei, hogyan járna el?

Legtöbbször az összes régi munka elfelejtődik, és minden újra kezdődik. Senki sem szereti bogarászni a mások által írt kódban, és ha van rá idő, miért ne foglalkoznánk a saját rendszerünk létrehozásával? Ez a tipikus hozzáállás, és sok szempontból helyes. De a mi projektünkben nem így jártunk el. Az automatikus tesztelési rendszer alapjául a korábbiak utPLSQL alapú unit tesztjeivel dolgoztunk, majd párhuzamos irányokban indultunk el.

Régi unit tesztek helyreállítása. A helyreállítás alatt a tesztek meglévő lojalitási rendszer állapotához való igazítását és a tesztek utPLSQL szabványoknak való megfeleltetését értjük.
A probléma megoldása a megértés terén, hogy pontosan milyen módszerek és folyamatok vannak automatikus tesztekkel lefedve. Ezt az információt vagy fejben kell tartani, vagy közvetlenül az automatikus teszt kódja alapján kell következtetéseket levonni. Ezért úgy döntöttünk, hogy létrehozunk egy katalogust. Minden automatikus teszthöz egyedi mnemonikus kódot rendelünk, leírást készítünk és rögzítjük a beállításokat (például, milyen körülmények között kell futnia, vagy mi történjen, ha a teszt futása sikertelen lett). Alapvetően metainformációkat töltöttünk ki az automatikus tesztekről, és ezeket a metainformációkat az utPLSQL séma szabványos tábláiba helyeztük.
Tágítási stratégia meghatározása, azaz annak a funkciónak a kiválasztása, amely automatikus tesztekkel ellenőrizhető. Három dologra szeretnénk figyelni: a rendszer új fejlesztései, a gyártási incidensek és a rendszer kulcsfolyamatai. Így párhuzamosan fejlődünk a kiadással, biztosítva a magasabb minőséget, és közben bővítjük a regressziót, valamint biztosítjuk a rendszer megbízhatóságát kritikus helyeken. Az első ilyen szűk keresztmetszet a kedvezmények és jutalmak elosztásának folyamata volt.
Természetesen új automatikus tesztek fejlesztésével foglalkoztunk. Az egyik első kiadási feladat a rendszerszintű lojalitási minták teljesítményének értékelése volt. A projektünkben van egy blokk, amelyben rögzített SQL lekérdezések találhatók, amelyek különböző feltételek alapján válogatják az ügyfeleket. Például az összes ügyfél listájának lekérése, akinek az utolsó vásárlása egy adott városban történt, vagy azoknak az ügyfeleknek a listája, akiknek a vásárlásának átlagos összege magasabb egy meghatározott értéknél. Automatikus tesztek írásával ellenőriztük a meghatározott mintákat, rögzítettük a referencia teljesítményparamétereket, továbbá lehetőségünk nyílt terheléses tesztelésre is.
Az automatikus tesztek kezelése kényelmes kell, hogy legyen.. A leggyakrabban végzett két művelet a tesztelés elindítása és a tesztadatok létrehozása. Így a rendszerünkben két segédmodul jelent meg: egy indító modul és egy adatgeneráló modul.
Az indító modul egy univerzális eljárás formájában van megvalósítva, amely egy bemeneti szöveges paramétert fogad. Mint paraméter, átadható a teszt neve, a csomag neve, a teszt azonosítója, az automatikus teszt konfigurációja vagy egy fenntartott kulcsszó. Az eljárás kiválasztja és elindítja az összes automatikus tesztet, amely teljesíti a feltételeket.
Az adatgeneráló modul egy csomag formájában van bemutatva, amelyben minden tesztelendő rendszer objektumhoz (adatbázis táblához) speciális eljárás lett létrehozva, amely adatokat insertál belé. Az eljárás maximálisan kitölti az alapértelmezett értékeket, így az objektumok szinte egyetlen kattintásra létrehozhatók. Az egyszerűbb használat érdekében elkészültek a generált adatok mintái is. Például létrehozni egy ügyfelet meghatározott korosztályban, teszt telefonos kapcsolattal és már lebonyolított vásárlással.
Az automatikus teszteknek elfogadható időn belül kell elindulniuk és működniük. Ezért napi éjszakai indítást szerveztünk, amelynek eredményeiről jelentés készül és elküldésre kerül a fejlesztőcsapat minden tagja számára a vállalati levelezésen keresztül. A régi automatikus tesztek helyreállítása és új tesztek létrehozása után az összes működési idő 30 percet tett ki. Ez a teljesítmény mindenkit kielégített, mivel az indítás munkaidőn kívül történt.
A sebességoptimalizáláson azonban dolgozni kellett. A hűségprogram frissítése a termelési környezetben éjszaka történik. Az egyik kiadás keretében éjszaka sürgősen módosításokat kellett végezni. A 3 órás éjjeli automatikus tesztek eredményeire való félórás várakozás nem tette boldoggá a kiadásért felelős személyt (tisztelettel üdvözöljük Vasjukov Aleksejt!), és másnap reggel sok barátságos szót mondtak a rendszerünkről. Végül 5 perces normát állapítottunk meg a munkára.
A teljesítmény gyorsítása érdekében két módszert alkalmaztunk: az automatikus teszteket három párhuzamos folyamatban kezdtük futtatni, ami a hűségprogramunk architektúrájának köszönhetően nagyon kényelmes. Ezen kívül lemondtunk arról a megközelítésről, amikor az automatikus teszt nem hozott létre tesztadatokat, hanem próbálta megtalálni a rendszerben a megfelelőket. A módosítások után a teljes működési idő 3-4 percre csökkent.
Az automatikus tesztekről szóló projektet képesnek kell lennünk különféle környezetekben telepíteni. A kezdeti időszakban próbálkoztunk saját bat-fájlokat írni, de világossá vált, hogy a saját automatizált telepítés teljes rémálom, és ipari megoldások felé fordultunk. Mivel a projekt nagyon sok kódot tartalmaz (elsősorban az automatikus tesztek kódját tároljuk) és nagyon kevés adatot (a fő adat a tesztkódok metaadatai), ezért a Liquibase bevezetése a projektbe nagyon egyszerűnek bizonyult.
Ez egy adatbázistól független, nyílt forráskódú könyvtár az adatbázis-séma változásainak nyomon követésére, kezelésére és alkalmazására. Parancssoron vagy olyan keretrendszerek segítségével kezelhető, mint az Apache Maven. A Liquibase működési elve meglehetősen egyszerű. Van egy bizonyos módon megszervezett projektünk, amely változásokból vagy skriptekből áll, amelyeket a célkiszolgálóra kell telepíteni, és irányító fájlok, amelyek meghatározzák, milyen sorrendben és mely paraméterekkel kell ezeket a változásokat telepíteni.
Az adatbázis szintjén létrejön egy speciális tábla, amelyben a Liquibase tárolja a változtatások naplóját. Minden módosítás rendelkezik egy kiszámított hash értékkel, amelyet minden alkalommal összehasonlítunk a projekt és az adatbázis állapota között. A Liquibase segítségével könnyedén alkalmazzuk a rendszerünk változásait bármelyik környezetben. Az automatikus teszteket jelenleg a teszt és a kiadási környezeten, valamint a fejlesztők személyes konténerein futtatjuk.

Tehát beszéljünk a tesztelési rendszerünk alkalmazásának eredményeiről.

Természetesen, először is meg vagyunk győződve arról, hogy kezdjük jobb minőségű szoftverek fejlesztését. Az automatikus teszteket naponta és kiadások óráiban futtatják, és tucatnyi hibát találnak. Ráadásul ezek közül egyes hibák csak közvetve kapcsolódnak ahhoz a funkcióhoz, amelyet valójában meg akartunk változtatni. Nagy kétségeink vannak afelől, hogy ezeket a hibákat kézi teszteléssel felfedeztük volna.
A csapatunkban megjelent a bizalom abban, hogy a konkrét funkció helyesen működik... Ez elsősorban a kritikus folyamatainkra vonatkozik. Például az elmúlt hat hónapban nem volt problémánk a kedvezmények és bónuszok elosztásával kapcsolatban a számlán, annak ellenére, hogy a kiadások során változtatásokat hajtottunk végre, míg az előző időszakokban ezekkel kapcsolatban időszakonként problémák merültek fel.
Sikerült csökkenteni a tesztelési iterációk számát. Annak köszönhetően, hogy az automatikus tesztek az új funkciókra készülnek, a minőség-analitikusok és a tesztelők együttműködésében jobb minőségű kódhoz jutnak, mivel az már ellenőrzésen ment keresztül.
Az automatizált tesztelés egy részét a fejlesztők is használják. Például a tesztadatok a konténerekben az objektumok generáló modul segítségével készülnek.
Nem elhanyagolható, hogy kialakult a fejlesztők körében az automatizált tesztelési rendszer "elfogadása". Van megértés arról, hogy ez fontos és hasznos. A saját tapasztalatom alapján azonban ezt messze nem így látom. Az automatikus teszteket írni kell, karbantartani, fejleszteni, az eredményeket elemezni, és gyakran ezek az időbeli ráfordítások egyszerűen nem érnek meg. Sokkal könnyebb bemenni a termelési környezetbe, és ott megoldani a problémákat. Nálunk a fejlesztők sorban állnak, és arra kérnek minket, hogy fedjük le a funkcióikat automatikus tesztekkel.

Mi következik

Beszéljünk a projekt automatizált tesztelésének fejlesztési terveiről.

A sportáruház lojalitási rendszere folyamatosan fejlődik, ezért az automatizált tesztek terjesztését is végtelen mértékben lehet fejleszteni. Így a fejlődés fő iránya a lefedettségi terület bővítése.

Az automatizált tesztek számának növekedésével az összes teszt időtartama is egyre nőni fog, és újra foglalkoznunk kell a teljesítménnyel. Valószínűleg a megoldás a párhuzamos szálak számának növelésében rejlik.

De ezek nyilvánvaló fejlődési irányok. Ha valami kevésbé banálisról beszélünk, emelhetjük ki a következőt:

Jelenleg az automatizált tesztek kezelése a DBMS szintjén történik, azaz PL/SQL tudásra van szükség a sikeres működéshez. Szükség esetén a rendszer kezelését (például futtatásokat vagy metaadatok létrehozását) ki lehet szervezni egy adminisztrátori felületen, például Jenkins használatával vagy hasonló eszközökkel.
Mindenki szereti a mennyiségi és minőségi mutatókat. Az automatizált tesztelésnél egy univerzális mutató a Kód Lefedettség vagy a metrika fedezete. E mutató segítségével megállapíthatjuk, hogy a tesztelt rendszerünk kódjának hány százaléka van lefedve az automatizált tesztekkel. A 12.2-es verziótól kezdve az Oracle lehetőségeket biztosít ennek a mutatónak a kiszámítására, és javasolja a DBMS_PLSQL_CODE_COVERAGE szabványos csomag használatát.
Az automatizált tesztelési rendszerünk kicsit több mint egy éves, és talán most van itt az ideje a lefedettség értékelésének. Az előző projektomban (ami nem a Sportmester volt) hasonló történt. Egy évvel az automatizált teszteken végzett munka után a vezetőség feladatot adott, hogy mérjük fel, hány százalékos a lefedettségünk. Ha a lefedettség meghaladja az 1%-ot, a vezetőség elégedett lett volna. Mi, fejlesztők, körülbelül 10%-os eredményre számítottunk. Aktiváltuk a kód lefedettséget, mérésre került sor, és 20%-ot kaptunk. Örömmel mentünk jutalomért, de hogy mi történt, amikor elmentünk érte, és hová indultunk utána, az már egy teljesen másik történet.
Az automatizált tesztek ellenőrizhetik a kiajánlott webszolgáltatásokat. Az Oracle ezt teljes mértékben lehetővé teszi, és több problémával már nem fogunk találkozni.
És természetesen automatizált tesztelési rendszerünket más projektekben is alkalmazhatjuk. Az általunk kidolgozott megoldás univerzális, és csupán Oracle használatát követeli meg. Hallottam, hogy a Sportmester más projektjein is érdeklődés mutatkozik az automatikus tesztelés iránt, és talán elmegyünk hozzájuk.

Következtetések

Foglaljuk össze. A Sportmester hűségprogramjánál sikerült megvalósítanunk egy automatizált tesztelési rendszert. Ennek alapját Stephen Feiershtein utPLSQL megoldása képezi. Az utPLSQL körül található az automatizált tesztek kódja és a segédprogramok: indító modul, adatgeneráló modul és mások. Az automatizált tesztek naponta futnak, és ami a legfontosabb, működnek és hasznot hoznak. Meg vagyunk győződve arról, hogy jobb minőségű szoftvert kezdtünk el fejleszteni. Ezen felül az általunk kidolgozott megoldás univerzális és szabadon alkalmazható bármelyik projektben, ahol automatizált tesztelést kell szervezni Oracle adatbázisokon.

P.S. Ez a cikk nem lett túl konkrét: sok szöveg található benne, és gyakorlatilag nincsenek technikai példák. Ha globálisan érdekes a téma, készen állunk arra, hogy folytassuk, és visszatérjünk a folytatással, ahol elmondjuk, mi változott az elmúlt fél évben, és bemutatunk kód példákat.

Kérjük, írjon kommentárokat, ha vannak olyan szempontok, amelyekre a jövőben érdemes lenne fókuszálni, vagy kérdések, amelyek megválaszolásra várnak.

Csak a regisztrált felhasználók vehetnek részt a szavazáson. Kérem, jelentkezzen be., kérem.