Testi enot v DBMS - kako to počnemo v Sportmasterju, drugi del

prvi del - tukaj.

Predstavljajte si situacijo. Soočeni ste z nalogo razvoja novih funkcionalnosti. Imate napredek od svojih predhodnikov. Če predpostavimo, da nimate moralnih obveznosti, kaj bi storili?

Najpogosteje so vsa stara dogajanja pozabljena in vse se začne znova. Nihče se ne mara poglabljati v kodo nekoga drugega, a če imate čas, zakaj ne bi začeli ustvarjati svojega sistema? To je tipičen pristop in je v veliki meri pravilen. Toda v našem projektu smo naredili narobe. Prihodnji sistem samodejnega testiranja smo zasnovali na razvoju enotnih testov na utPLSQL naših predhodnikov, nato pa smo šli delati v več vzporednih smereh.

1. Obnavljanje starih testov enot. Obnovitev pomeni prilagoditev testov obstoječemu stanju sistema zvestobe in prilagoditev testov standardom utPLSQL.
2. Reševanje problema z razumevanjem, kaj točno, katere metode in procesi so zajeti s samodejnimi testi. Te informacije morate imeti v glavi ali sklepati neposredno na podlagi kode samodejnega testiranja. Zato smo se odločili za izdelavo kataloga. Vsakemu samodejnemu testu smo dodelili edinstveno mnemonično kodo, ustvarili opis in zabeležili nastavitve (na primer, pod kakšnimi pogoji naj se zažene ali kaj naj se zgodi, če zagon testa ne uspe). V bistvu smo napolnili metapodatke o samodejnih testih in te metapodatke umestili v standardne tabele sheme utPLSQL.
3. Opredelitev strategije širitve, tj. izbor funkcionalnosti, ki je predmet preverjanja z avtomatiziranimi testi. Odločili smo se, da bomo pozorni na tri stvari: nove izboljšave sistema, proizvodne incidente in ključne sistemske procese. Tako se razvijamo vzporedno z izdajo, zagotavljamo njeno višjo kakovost, hkrati pa širimo obseg regresije in zagotavljamo zanesljivost sistema na kritičnih mestih. Prvo takšno ozko grlo je bil proces razdeljevanja popustov in bonusov na čeku.
4. Seveda smo začeli razvijati nove avtoteste. Ena od prvih nalog izdaje je bila ocena delovanja vnaprej določenih vzorcev sistema zvestobe. Naš projekt ima blok togo fiksnih poizvedb SQL, ki izbirajo stranke na podlagi pogojev. Pridobite na primer seznam vseh strank, katerih zadnji nakup je bil v določenem mestu, ali seznam strank, katerih povprečni znesek nakupa je nad določeno vrednostjo. Po pisnih samodejnih testih smo preverili vnaprej določene vzorce, zabeležili merilne parametre zmogljivosti in dodatno opravili obremenitveno testiranje.
5. Delo s samodejnimi testi bi moralo biti priročno. Dve najpogostejši dejanji sta izvajanje samodejnih testov in ustvarjanje testnih podatkov. Tako sta se v našem sistemu pojavila dva pomožna modula: zagonski modul in modul za generiranje podatkov.

   Zaganjalnik je predstavljen kot en univerzalni postopek z enim parametrom za vnos besedila. Kot parameter lahko posredujete mnemonično kodo samodejnega preizkusa, ime paketa, ime preizkusa, nastavitev samodejnega preizkusa ali rezervirano ključno besedo. Postopek izbere in zažene vse samodejne teste, ki izpolnjujejo pogoje.

   Modul za generiranje podatkov je predstavljen v obliki paketa, v katerem je za vsak objekt testiranega sistema (tabela v bazi) ustvarjen poseben postopek, ki tja vnaša podatke. V tem postopku so privzete vrednosti čim bolj zapolnjene, kar zagotavlja ustvarjanje predmetov dobesedno s klikom prsta. Za lažjo uporabo so bile ustvarjene predloge za ustvarjene podatke. Ustvarite na primer stranko določene starosti s testnim telefonom in opravljenim nakupom.

6. Samodejni testi se morajo začeti in izvajati v času, ki je sprejemljiv za vaš sistem. Zato je bil organiziran dnevni nočni zagon, na podlagi katerega se ustvari poročilo o rezultatih, ki se pošlje celotni razvojni ekipi preko korporativne pošte. Po obnovitvi starih samodejnih testov in ustvarjanju novih je bil skupni čas delovanja 30 minut. Ta izvedba je ustrezala vsem, saj je lansiranje potekalo izven delovnega časa.

   Vendar smo morali delati na optimizaciji hitrosti dela. Sistem zvestobe v proizvodnji se posodablja ponoči. V okviru ene od izdaj smo morali ponoči narediti nujne spremembe. Polurno čakanje na rezultate avtotestov ob treh zjutraj ni razveselilo osebe, odgovorne za izdajo (goreč pozdrav Alekseju Vasjukovu!), naslednje jutro pa je bilo našemu sistemu izrečenih veliko prijaznih besed. Toda posledično je bil vzpostavljen 5-minutni standard za delo.

   Za pospešitev delovanja smo uporabili dve metodi: samodejni testi so se začeli izvajati v treh vzporednih nitih, na srečo je to zelo priročno zaradi arhitekture našega sistema zvestobe. In opustili smo pristop, ko avtotest ne ustvarja testnih podatkov zase, ampak poskuša najti nekaj primernega v sistemu. Po spremembah se je skupni čas delovanja zmanjšal na 3-4 minute.

7. Projekt s samodejnimi testi bi moral imeti možnost razmestitve na različnih stojnicah. Na začetku naše poti so bili poskusi pisanja lastnih paketnih datotek, a je postalo jasno, da je avtomatizirana namestitev, ki jo sami pišemo, popolna groza, in usmerili smo se k industrijskim rešitvam. Ker projekt vsebuje veliko neposredne kode (najprej shranimo kodo za avtotest) in zelo malo podatkov (glavni podatek so metapodatki o avtotestih), se je implementacija v projektu Liquibase izkazala za zelo preprosto.

   Je odprtokodna knjižnica, neodvisna od baze podatkov, za sledenje, upravljanje in uveljavljanje sprememb sheme baze podatkov. Upravlja se prek ukazne vrstice ali ogrodij, kot je Apache Maven. Načelo delovanja Liquibase je precej preprosto. Imamo na določen način organiziran projekt, ki je sestavljen iz sprememb ali skriptov, ki jih je treba uvesti na ciljni strežnik, in kontrolnih datotek, ki določajo, v kakšnem zaporedju in s kakšnimi parametri naj se te spremembe namestijo.

   Na ravni DBMS se ustvari posebna tabela, v katero Liquibase shrani dnevnik prevračanja. Vsaka sprememba ima izračunan hash, ki se vsakič primerja med projektom in stanjem v bazi podatkov. Zahvaljujoč Liquibase lahko enostavno uvedemo spremembe našega sistema v katero koli vezje. Samodejni testi se zdaj izvajajo na testnih in sprostitvenih vezjih, pa tudi na vsebnikih (osebnih vezjih razvijalcev).

Torej, pogovorimo se o rezultatih uporabe našega sistema testiranja enot.

1. Seveda smo najprej prepričani, da smo začeli razvijati boljšo programsko opremo. Samodejni testi se izvajajo vsak dan in pri vsaki izdaji je najdenih na desetine napak. Poleg tega so nekatere od teh napak le posredno povezane s funkcionalnostjo, ki smo jo resnično želeli spremeniti. Obstajajo resni dvomi, da so bile te napake odkrite z ročnim testiranjem.
2. Ekipa je zdaj prepričana, da določene funkcionalnosti delujejo pravilno ... Najprej to zadeva naše kritične procese. Na primer, v zadnjih šestih mesecih nismo imeli nobenih težav z delitvijo popustov in bonusov na računih, kljub spremembam izdaje, čeprav so se v prejšnjih obdobjih napake pojavljale pogosteje
3. Uspelo nam je zmanjšati število ponovitev testiranja. Ker so samodejni testi napisani za nove funkcionalnosti, analitiki in občasni preizkuševalci prejmejo kodo višje kakovosti, ker je že preverjeno.
4. Nekatere razvojne dosežke v avtomatiziranem testiranju uporabljajo razvijalci. Na primer, testni podatki o vsebnikih so ustvarjeni z uporabo modula za generiranje objektov.
5. Pomembno je, da smo razvili "sprejemanje" avtomatiziranega sistema testiranja s strani razvijalcev. Obstaja razumevanje, da je to pomembno in koristno. A iz lastnih izkušenj lahko rečem, da še zdaleč ni tako. Avtoteste je treba pisati, jih je treba podpirati in razvijati, rezultate je treba analizirati in pogosto se ti časovni stroški preprosto ne splačajo. Veliko lažje je iti v proizvodnjo in tam reševati težave. Tukaj se razvijalci postavijo v vrsto in nas prosijo, da njihovo funkcionalnost pokrijemo s samodejnimi testi.

Kaj je naslednje?

Pogovorimo se o razvojnih načrtih za projekt avtomatiziranega testiranja.

Seveda, dokler je Sportmasterjev sistem zvestobe živ in se razvija, je mogoče tudi avtoteste razvijati skoraj neskončno. Zato je glavna smer razvoja širitev območja pokritosti.

Z naraščanjem števila samodejnih testov se bo njihov skupni čas delovanja vztrajno povečeval in spet se bomo morali vrniti k vprašanju zmogljivosti. Najverjetneje bo rešitev povečanje števila vzporednih niti.

Toda to so očitne poti razvoja. Če govorimo o nečem bolj netrivialnem, izpostavljamo naslednje:

1. Trenutno se upravljanje samodejnega testiranja izvaja na ravni DBMS, tj. za uspešno delo je potrebno znanje PL/SQL. Če je potrebno upravljanje sistema (na primer zagon ali ustvarjanje metapodatkov), lahko ustvarite nekakšno skrbniško ploščo z uporabo Jenkinsa ali česa podobnega.
2. Vsi imajo radi kvantitativne in kvalitativne kazalnike. Za avtomatizirano testiranje je takšen univerzalni indikator pokritost kode ali metrika pokritosti kode. S pomočjo tega indikatorja lahko ugotovimo, kolikšen odstotek kode našega testiranega sistema je pokrit s samodejnimi testi. Od različice 12.2 dalje Oracle omogoča izračun te metrike in ponuja uporabo standardnega paketa DBMS_PLSQL_CODE_COVERAGE.

   Naš sistem za samodejno testiranje je star malo več kot eno leto in morda je zdaj čas, da ocenimo našo pokritost. Pri mojem zadnjem projektu (ne Sportmaster) se je to zgodilo. Leto po delu na samodejnih testih si je vodstvo zadalo nalogo oceniti, kolikšen odstotek kode pokrivamo. Z več kot 1-odstotnim pokritjem bi bilo vodstvo zadovoljno. Mi, razvijalci, smo pričakovali rezultat približno 10%. Namestili smo pokritost kode, jo izmerili in dobili 20 %. Za proslavo smo šli po nagrado, kako smo šli ponjo in kam smo šli kasneje, je pa čisto druga zgodba.

3. Samodejni testi lahko preverijo izpostavljene spletne storitve. Oracle nam to omogoča precej dobro in ne bomo več naleteli na številne težave.
4. In seveda lahko naš avtomatiziran sistem testiranja uporabimo pri drugem projektu. Rešitev, ki smo jo prejeli, je univerzalna in zahteva le uporabo Oracla. Slišal sem, da se drugi projekti Sportmaster zanimajo za samodejno testiranje in morda bomo šli k njim.

Ugotovitve

Naj povzamemo. Na projektu sistema zvestobe v Sportmastru nam je uspelo implementirati avtomatiziran sistem testiranja. Temelji na rešitvi utPLSQL Stephena Feuersteina. Okoli utPLSQL je koda za samodejno testiranje in pomožni samonapisani moduli: modul za zagon, modul za generiranje podatkov in drugi. Avtotesti se izvajajo vsak dan in, kar je najpomembneje, delujejo in so uporabni. Prepričani smo, da smo začeli izdajati kakovostnejšo programsko opremo. Hkrati je dobljena rešitev univerzalna in jo je mogoče poljubno uporabiti za kateri koli projekt, kjer je potrebno organizirati avtomatizirano testiranje na Oracle DBMS.

PS Ta članek ni zelo specifičen: veliko je besedila in skoraj nič tehničnih primerov. Če je tema na splošno zanimiva, smo jo pripravljeni nadaljevati in se vrniti z nadaljevanjem, kjer vam bomo povedali, kaj se je spremenilo v zadnjih šestih mesecih, in podali primere kode.

Napišite komentarje, če obstajajo točke, ki bi jih bilo treba v prihodnosti poudariti, ali vprašanja, ki zahtevajo razkritje.

V anketi lahko sodelujejo samo registrirani uporabniki. Prijaviti se, prosim.

Bomo še pisali o tem?

• Oh seveda

• Ne hvala

Glasovalo je 12 uporabnikov. 4 uporabnika sta se vzdržala.

Vir: www.habr.com