Egységtesztek DBMS-ben – hogyan csináljuk a Sportmaster második részében

Első rész - itt.

Képzelj el egy helyzetet. Új funkciók kifejlesztésének feladatával áll szemben. Van tapasztalatod az elődöktől. Feltéve, hogy nincsenek erkölcsi kötelezettségei, mit tenne?

Leggyakrabban az összes régi fejlesztést elfelejtik, és minden kezdődik elölről. Senki sem szeret beleásni valaki más kódjába, és ha van ideje, miért ne kezdené el saját rendszer létrehozását? Ez egy tipikus megközelítés, és sok tekintetben helyes. A projektünkben azonban másként jártunk el. A leendő automatizált tesztelési rendszert az elődeink utPLSQL alapú egységtesztjeinek fejlesztéseire alapoztuk, majd több párhuzamos irányban is munkába álltunk.

1. A régi egységtesztek visszaállítása. A helyreállítás a tesztek hozzáigazítását jelenti a hűségrendszer meglévő állapotához és a tesztek adaptálását az utPLSQL szabványokhoz.
2. A probléma megoldását a megértéssel, és pontosan mit, milyen módszerekkel és folyamatokkal, autotesztekkel fedtük le. Ezt az információt vagy a fejében kell tartania, vagy közvetlenül az automatikus tesztek kódja alapján kell következtetéseket levonnia. Ezért úgy döntöttünk, hogy létrehozunk egy katalógust. Minden automatikus teszthez egyedi mnemonikus kódot rendeltünk, leírást készítettünk, és javítottuk a beállításokat (például milyen feltételek mellett kell futtatni, vagy mi történik, ha a tesztfutás sikertelen). Lényegében kitöltöttük az automatikus tesztek metaadatait, és ezeket a metaadatokat elhelyeztük az utPLSQL séma szabványos tábláiban.
3. A terjeszkedési stratégia meghatározása, i.e. olyan funkciók kiválasztása, amelyek ellenőrzése automatikus tesztekkel történik. Úgy döntöttünk, hogy három dologra figyelünk: a rendszer új fejlesztéseire, a termelésből származó incidensekre és a rendszer kulcsfontosságú folyamataira. Így a kiadással párhuzamosan fejlesztünk, biztosítva annak magasabb minőségét, egyszerre bővítve a regresszió hatókörét és a kritikus helyeken biztosítva a rendszer megbízhatóságát. Az első ilyen szűk keresztmetszet a kedvezmények és bónuszok csekken történő szétosztása volt.
4. Természetesen új autotesztek fejlesztésébe kezdtünk. Az egyik első kiadási feladat a hűségrendszer előre meghatározott mintáinak teljesítményének értékelése volt. Projektünkben van egy mereven rögzített sql lekérdezés blokk, amely a feltételeknek megfelelően választja ki az ügyfeleket. Például készítsen listát azokról az ügyfelekről, akiknek legutóbbi vásárlása egy adott városban történt, vagy azon ügyfelek listáját, akiknek átlagos vásárlási összege egy bizonyos érték felett van. Az automatikus tesztek megírása után előre definiált mintákat, rögzített benchmark teljesítményparamétereket ellenőriztünk, valamint terhelési tesztet kaptunk.
5. Az automatikus tesztekkel való munkavégzés kényelmes legyen. A két leggyakoribb művelet az automatikus tesztek futtatása és a tesztadatok generálása. Így jelent meg rendszerünkben két segédmodul: az indító modul és az adatgeneráló modul.

   Az indító egy általános eljárásként jelenik meg egy beviteli szöveges paraméterrel. Paraméterként megadhat egy automatikus teszt mnemonikus kódot, csomagnevet, tesztnevet, automatikus teszt beállítást vagy fenntartott kulcsszót. Az eljárás kiválasztja és lefuttatja az összes olyan automatikus tesztet, amely megfelel a feltételeknek.

   Az adatgeneráló modult egy csomagként mutatjuk be, melyben a tesztelt rendszer minden egyes objektumához (az adatbázisban egy táblázat) készült egy speciális eljárás, amely oda szúr be adatokat. Ebben az eljárásban az alapértelmezett értékek maximálisan kitöltésre kerülnek, ami biztosítja az objektumok létrehozását szó szerint egy ujj kattintással. A könnyebb használat érdekében pedig sablonokat hoztak létre a generált adatokhoz. Hozzon létre például egy bizonyos korú ügyfelet egy teszttelefonnal és egy befejezett vásárlással.

6. Az automatikus teszteknek a rendszer számára ésszerű időn belül le kell futniuk. Ezért napi éjszakai bevezetést szerveztek, melynek eredménye alapján jelentés készül az eredményekről, amelyet céges postai úton juttatnak el a teljes fejlesztőcsapatnak. A régi automatikus tesztek visszaállítása és újak létrehozása után a teljes futási idő 30 perc volt. Egy ilyen előadás mindenkinek jól esett, hiszen a bemutatóra munkaidőn kívül került sor.

   De dolgoznunk kellett a munka sebességének optimalizálásán. A termelési hűségrendszert éjszaka frissítik. Az egyik kiadás részeként éjszaka sürgősen változtatásokat kellett végrehajtanunk. A fél órás várakozás az automatikus tesztek eredményére hajnali háromkor nem tette boldoggá a kiadásért felelős személyt (buzgó üdvözlet Alekszej Vasjukovnak!), Másnap reggel pedig sok meleg szót mondtak rendszerünknek. De ennek eredményeként 5 perces munkaidőt határoztak meg.

   A teljesítmény felgyorsítására két módszert alkalmaztunk: három párhuzamos szálon indítottuk el az automatikus tesztek futtatását, mivel ez nagyon kényelmes a hűségrendszerünk architektúrája miatt. És elhagytuk azt a megközelítést, amikor az autoteszt nem hoz létre tesztadatokat magának, hanem megpróbál valami megfelelőt találni a rendszerben. A változtatások elvégzése után a teljes működési idő 3-4 percre csökkent.

7. Az automatikus tesztekkel rendelkező projekteket különféle standokon telepíteni kell. Az út elején voltak kísérletek saját kötegfájlok megírására, de világossá vált, hogy a saját kezűleg írt automatizált telepítés teljes horror, és az ipari megoldások felé fordultunk. Tekintettel arra, hogy a projektben nagyon sok kód van közvetlenül (elsősorban az automatikus tesztek kódját tároljuk), és nagyon kevés adatot tartalmaz (a fő adat az automatikus tesztekről szóló metaadatok), nagyon egyszerűnek bizonyult integrálni a Liquibase projekt.

   Ez egy nyílt forráskódú adatbázistól független könyvtár az adatbázisséma-változások nyomon követésére, kezelésére és alkalmazására. Parancssoron vagy olyan keretrendszereken keresztül kezelhető, mint az Apache Maven. A Liquibase működési elve meglehetősen egyszerű. Van egy meghatározott módon szervezett projektünk, amely változtatásokból vagy szkriptekből áll, amelyeket a célszerverre kell görgetni, és olyan vezérlőfájlokból áll, amelyek meghatározzák, hogy ezeket a változtatásokat milyen sorrendben és milyen paraméterekkel kell telepíteni.

   DBMS szinten egy speciális tábla jön létre, amelyben a Liquibase tárolja a visszaállítási naplót. Minden változtatáshoz tartozik egy kiszámított hash, amelyet minden alkalommal összehasonlítanak a projekt és az adatbázisban lévő állapot között. A Liquibase-nek köszönhetően könnyedén bevezethetjük a rendszerünk módosításait bármely áramkörre. Az automatikus tesztek most teszt- és kiadási áramkörökön, valamint konténereken (a fejlesztők személyes áramkörei) futnak.

Tehát beszéljünk az egységtesztelési rendszerünk alkalmazásának eredményeiről.

1. Természetesen mindenekelőtt meg vagyunk győződve arról, hogy elkezdtünk jobb szoftvereket fejleszteni. Az automatikus tesztek naponta futnak, és minden kiadásnál több tucat hibát találnak. Ezen túlmenően ezeknek a hibáknak egy része csak közvetetten kapcsolódik ahhoz a funkcióhoz, amelyet valóban meg akartunk változtatni. Erősen kétségesek, hogy ezeket a hibákat kézi teszteléssel találták meg.
2. A csapat megbizonyosodott arról, hogy bizonyos funkciók megfelelően működnek... Mindenekelőtt ez a kritikus folyamatainkra vonatkozik. Például az elmúlt hat hónapban nem volt problémánk a kedvezmények és bónuszok csekken történő elosztásával, a minden kiadáson végrehajtott változtatás ellenére, bár a korábbi időszakokban bizonyos gyakorisággal fordultak elő hibák
3. Sikerült csökkentenünk a tesztelési iterációk számát. Mivel az automatikus teszteket új funkciókhoz írják, az elemzők és a részmunkaidős tesztelők jobb minőségű kódot kapnak, mert már ellenőrizték.
4. Az automatizált tesztelés fejlesztéseinek egy részét a fejlesztők használják. Például a tárolók tesztadatai az objektumgeneráló modul segítségével jönnek létre.
5. Fontos, hogy kialakítottuk az automatizált tesztelési rendszer fejlesztői általi „elfogadását”. Megértjük, hogy ez fontos és hasznos. És saját tapasztalatom alapján elmondhatom, hogy ez korántsem így van. Autoteszteket kell írni, karbantartani és fejleszteni, az eredményeket elemezni, és gyakran ezek az időköltségek egyszerűen nem érik meg. Sokkal egyszerűbb a gyártáshoz menni, és ott kezelni a problémákat. Hazánkban a fejlesztők felsorakoznak, és azt kérik, hogy funkcionalitásukat autotesztekkel fedezzék.

Mi a következő

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

Természetesen amíg a Sportmaster hűségrendszer él és folyamatosan fejlődik, az autotesztek is szinte vég nélkül fejleszthetők. Ezért a fejlesztés fő iránya a lefedettség bővítése.

Az autotesztek számának növekedésével folyamatosan növekszik a teljes munkájuk ideje, és ismét vissza kell térnünk a teljesítmény kérdésére. Valószínűleg a megoldás a párhuzamos szálak számának növelése lesz.

De ezek a fejlődés nyilvánvaló útjai. Ha valami nem triviálisról beszélünk, akkor a következőket emeljük ki:

1. Most az automatikus teszteket DBMS szinten kezelik, azaz. a sikeres munkához PL/SQL ismerete szükséges. Szükség esetén a rendszerkezelést (például a metaadatok elindítását vagy létrehozását) valamilyen adminisztrációs panel Jenkins vagy valami hasonló segítségével ki tudja venni.
2. Mindenki szereti a mennyiségi és minőségi mutatókat. Az automatikus teszteléshez ilyen univerzális mutató a kódlefedettség vagy a kódlefedettség mérőszáma. Ezzel a mutatóval meg tudjuk határozni, hogy tesztelt rendszerünk kódjának hány százalékát fedik le az autotesztek. A 12.2-es verziótól kezdve az Oracle lehetővé teszi ennek a mutatónak a kiszámítását, és a szabványos DBMS_PLSQL_CODE_COVERAGE csomag használatát javasolja.

   Automatikus tesztrendszerünk alig több mint egy éves, és lehet, hogy itt az ideje, hogy értékeljük a lefedettséget. A legutóbbi projektemben (nem a Sportmaster projektje) ez történt. Egy évvel az autoteszteken való munka után a vezetőség azt a feladatot tűzte ki maga elé, hogy felmérje, hogy a kód hány százalékát fedjük le. Több mint 1%-os lefedettséggel a vezetőség elégedett lenne. Mi, fejlesztők körülbelül 10%-os eredményt vártunk. Elcsavartuk a kódlefedettséget, lemértük, 20%-ot kaptunk. Hogy megünnepeljük, elmentünk a díjért, de az, hogy hogyan és hova jutottunk később, az egy teljesen más történet.

3. Az automatikus tesztek tesztelhetik a nyílt webszolgáltatásokat. Az Oracle lehetővé teszi ezt, és többé nem fogunk találkozni számos problémával.
4. És természetesen az automatizált tesztelési rendszerünk egy másik projektben is alkalmazható. A kapott megoldás univerzális, és csak az Oracle használatát igényli. Azt hallottam, hogy érdeklődnek más Sportmaster projektek automatizált tesztelése iránt, és talán el fogunk menni hozzájuk.

Álláspontja

Foglaljuk össze. A Sportmaster törzsvásárlói rendszer projektjénél sikerült egy automatizált tesztelési rendszert megvalósítanunk. Ennek alapja Stephen Feuerstein utPLSQL megoldása. Az utPLSQL körül található az automatikus tesztek és a kiegészítő, önállóan írt modulok kódja: indító, adatgeneráló modul és mások. Az automatikus tesztek naponta futnak, és ami a legfontosabb, működnek és hasznosak. Meggyőződésünk, hogy elkezdtük a jobb minőségű szoftverek kiadását. Az így létrejött megoldás ugyanakkor univerzális, és szabadon alkalmazható minden olyan projektben, ahol szükség van az Oracle DBMS automatizált tesztelésének megszervezésére.

PS Ez a cikk nem volt túl konkrét: sok a szöveg, és gyakorlatilag nincs technikai példa. Ha a téma globálisan érdekes, akkor készen állunk a folytatásra, és visszatérünk egy folytatással, ahol elmondjuk, mi változott az elmúlt hat hónapban, és kódpéldákat adunk.

Írjon megjegyzéseket, ha vannak olyan pontok, amelyeket a jövőben hangsúlyozni kell, vagy olyan kérdések, amelyek nyilvánosságra hozatalt igényelnek.

A felmérésben csak regisztrált felhasználók vehetnek részt. Bejelentkezés, kérem.

Írjunk erről bővebben?

• Igen, természetesen

• Nem köszönöm

12 felhasználó szavazott. 4 felhasználó tartózkodott.

Forrás: will.com