Jedinični testovi u DBMS-u - kako to radimo u Sportmasteru, drugi dio

Prvi dio - здесь.

Zamislite situaciju. Suočeni ste sa zadatkom razvoja nove funkcionalnosti. Imate iskustva od svojih prethodnika. Pod pretpostavkom da nemate moralnih obveza, što biste učinili?

Najčešće se sva stara događanja zaborave i sve počinje iznova. Nitko ne voli kopati po tuđem kodu, a ako imate vremena, zašto ne biste počeli stvarati vlastiti sustav? Ovo je tipičan pristup iu mnogim je aspektima točan. Ali u našem projektu postupili smo drugačije. Budući automatizirani sustav testiranja temeljili smo na razvoju jediničnih testova na utPLSQL naših prethodnika, a zatim smo krenuli raditi u nekoliko paralelnih smjerova.

1. Vraćanje starih jediničnih testova. Oporavak podrazumijeva prilagodbu testova postojećem stanju sustava lojalnosti i prilagodbu testova utPLSQL standardima.
2. Rješavanje problema s razumijevanjem, a što točno, kojim metodama i procesima, pokrili smo autotestovima. Morate ili zadržati ove informacije u svojoj glavi, ili izvući zaključke izravno na temelju koda autotestova. Stoga smo odlučili izraditi katalog. Svakom smo autotestu dodijelili jedinstveni mnemonički kod, izradili opis i popravili postavke (na primjer, pod kojim uvjetima se treba izvoditi ili što bi se trebalo dogoditi ako test ne uspije). U biti smo ispunili metapodatke o autotestovima i smjestili te metapodatke u standardne tablice utPLSQL sheme.
3. Definicija strategije širenja, tj. odabir funkcionalnosti koja podliježe provjeri autotestovima. Odlučili smo obratiti pozornost na tri stvari: nova poboljšanja sustava, incidente iz proizvodnje i ključne procese sustava. Dakle, razvijamo se paralelno s izdanjem, osiguravajući njegovu višu kvalitetu, istovremeno proširujući opseg regresije i osiguravajući pouzdanost sustava na kritičnim mjestima. Prvo takvo usko grlo bio je proces raspodjele popusta i bonusa putem čeka.
4. Naravno, počeli smo razvijati nove autotestove. Jedan od prvih zadataka izdanja bio je procijeniti izvedbu unaprijed definiranih uzoraka sustava lojalnosti. Naš projekt ima blok rigidno fiksnih sql upita koji odabiru klijente prema uvjetima. Na primjer, dobijte popis svih kupaca čija je zadnja kupnja bila u određenom gradu ili popis kupaca čiji je prosječni iznos kupovine iznad određene vrijednosti. Nakon što smo napisali autotestove, provjerili smo unaprijed definirane uzorke, fiksne referentne parametre performansi, a dodatno smo dobili testiranje opterećenja.
5. Rad s autotestovima trebao bi biti prikladan. Dvije najčešće radnje su pokretanje autotestova i generiranje testnih podataka. Tako su se u našem sustavu pojavila dva pomoćna modula: modul za pokretanje i modul za generiranje podataka.

   Pokretač je predstavljen kao jedna generička procedura s jednim ulaznim tekstualnim parametrom. Kao parametar možete proslijediti mnemonički kod za autotest, naziv paketa, naziv testa, postavku za autotest ili rezerviranu ključnu riječ. Procedura odabire i pokreće sve autotestove koji ispunjavaju uvjete.

   Modul za generiranje podataka predstavljen je kao paket u kojem je za svaki objekt sustava koji se testira (tablica u bazi podataka) kreirana posebna procedura koja tamo ubacuje podatke. U ovom postupku, zadane vrijednosti se popunjavaju do maksimuma, što osigurava stvaranje objekata doslovno na klik prsta. A radi lakšeg korištenja stvoreni su predlošci za generirane podatke. Na primjer, kreirajte klijenta određene dobi s testnim telefonom i obavljenom kupnjom.

6. Autotestovi bi se trebali pokrenuti i pokrenuti u razumnom vremenu za vaš sustav. Stoga je organizirano dnevno noćno lansiranje na temelju čijih se rezultata generira izvješće o rezultatima koje se korporativnom poštom šalje cijelom razvojnom timu. Nakon vraćanja starih autotestova i stvaranja novih, ukupno vrijeme rada bilo je 30 minuta. Takva izvedba svima je odgovarala, jer je lansiranje održano izvan radnog vremena.

   Ali morali smo poraditi na optimizaciji brzine rada. Sustav lojalnosti proizvodnje ažurira se noću. U sklopu jednog od izdanja, morali smo hitno napraviti izmjene noću. Polusatno čekanje na rezultate autotestova u tri ujutro nije usrećilo osobu odgovornu za puštanje (gorljivi pozdravi Alekseju Vasjukovu!), A sljedećeg jutra puno je toplih riječi izrečeno našem sustavu. Ali kao rezultat, postavljen je 5-minutni standard za rad.

   Kako bismo ubrzali performanse, koristili smo dvije metode: pokrenuli smo autotestove u tri paralelne niti, jer je to vrlo zgodno zbog arhitekture našeg sustava vjernosti. I napustili smo pristup kada autotest ne stvara testne podatke za sebe, već pokušava pronaći nešto prikladno u sustavu. Nakon izmjena, ukupno vrijeme rada smanjeno je na 3-4 minute.

7. Projekt s autotestovima trebao bi se moći implementirati na različitim postoljima. Na početku puta bilo je pokušaja pisanja vlastitih batch datoteka, no postalo je jasno da je samonapisana automatizirana instalacija potpuni užas te smo se okrenuli industrijskim rješenjima. Zbog činjenice da projekt ima puno koda izravno (prije svega, pohranjujemo kod autotestova) i vrlo malo podataka (glavni podaci su metapodaci o autotestovima), pokazalo se da ga je vrlo lako integrirati u Liquibase projekt.

   To je knjižnica neovisna o bazi podataka otvorenog koda za praćenje, upravljanje i primjenu promjena sheme baze podataka. Upravlja se preko naredbenog retka ili okvira kao što je Apache Maven. Princip rada Liquibase je prilično jednostavan. Imamo projekt organiziran na određeni način, koji se sastoji od promjena ili skripti koje je potrebno prebaciti na ciljni poslužitelj i kontrolnih datoteka koje određuju kojim redoslijedom i s kojim parametrima treba instalirati te promjene.

   Na razini DBMS-a kreira se posebna tablica u koju Liquibase pohranjuje dnevnik vraćanja. Svaka promjena ima izračunati hash koji se svaki put uspoređuje između projekta i stanja u bazi podataka. Zahvaljujući Liquibaseu, možemo jednostavno uvesti promjene našeg sustava u bilo koje kolo. Autotestovi se sada pokreću na petljama za testiranje i otpuštanje, kao i na spremnicima (osobne petlje programera).

Dakle, razgovarajmo o rezultatima primjene našeg sustava jediničnog testiranja.

1. Naravno, prije svega, uvjereni smo da smo počeli razvijati bolji softver. Autotestovi se izvode svakodnevno i pronalaze desetke grešaka u svakom izdanju. Štoviše, neke od ovih grešaka samo su neizravno povezane s funkcionalnošću koju smo stvarno željeli promijeniti. Postoje jake sumnje da su te pogreške pronađene ručnim testiranjem.
2. Tim je stekao povjerenje da određene funkcionalnosti rade ispravno... Prije svega, to se odnosi na naše kritične procese. Na primjer, tijekom proteklih šest mjeseci nismo imali problema s raspodjelom popusta i bonusa putem čekova, unatoč izmjenama koje su napravljene pri svakom izdanju, iako su se u prethodnim razdobljima pogreške javljale s određenom učestalošću
3. Uspjeli smo smanjiti broj ponavljanja testiranja. Zbog činjenice da se autotestovi pišu za nove funkcionalnosti, analitičari i honorarni testeri dobivaju kvalitetniji kod, jer to je već provjereno.
4. Dio razvoja automatiziranog testiranja koriste programeri. Na primjer, testni podaci o spremnicima izrađuju se pomoću modula za generiranje objekata.
5. Važno je da smo razvili "prihvaćanje" automatiziranog sustava testiranja od strane programera. Postoji razumijevanje da je to važno i korisno. A iz vlastitog iskustva mogu reći da je to daleko od slučaja. Autotestove treba pisati, treba ih održavati i razvijati, rezultate analizirati, a često ti vremenski troškovi jednostavno nisu isplativi. Puno je lakše otići u proizvodnju i tamo se nositi s problemima. U našoj zemlji programeri stoje u redu i traže da pokriju svoju funkcionalnost autotestovima.

što dalje

Razgovarajmo o razvojnim planovima projekta automatiziranog testiranja.

Naravno, sve dok Sportmasterov sustav vjernosti postoji i razvija se, autotestovi se također mogu razvijati gotovo u nedogled. Stoga je glavni smjer razvoja širenje područja pokrivanja.

Kako se broj autotestova povećava, ukupno vrijeme njihovog rada će se stalno povećavati, pa ćemo se opet morati vratiti na pitanje performansi. Najvjerojatnije će rješenje biti povećanje broja paralelnih niti.

Ali to su očiti putevi razvoja. Ako govorimo o nečemu što nije trivijalno, ističemo sljedeće:

1. Sada se autotestovima upravlja na razini DBMS-a, tj. za uspješan rad potrebno je poznavanje PL/SQL. Ako je potrebno, upravljanje sustavom (na primjer, pokretanje ili stvaranje metapodataka) može se izvršiti pomoću neke vrste administratorske ploče pomoću Jenkinsa ili nečeg sličnog.
2. Svi vole kvantitativne i kvalitativne pokazatelje. Za automatsko testiranje takav univerzalni pokazatelj je pokrivenost kodom ili metrika pokrivenosti koda. Pomoću ovog pokazatelja možemo odrediti koji je postotak koda našeg sustava koji se testira pokriven autotestovima. Počevši od verzije 12.2, Oracle pruža mogućnost izračuna ove metrike i predlaže korištenje standardnog paketa DBMS_PLSQL_CODE_COVERAGE.

   Naš sustav za automatsko testiranje star je nešto više od godinu dana i možda je vrijeme da procijenimo pokrivenost. U mom zadnjem projektu (projektu koji nije Sportmaster) dogodilo se to. Godinu dana nakon rada na autotestovima, uprava je postavila zadatak procijeniti koji smo postotak koda pokrili. S više od 1% pokrića, menadžment bi bio sretan. Mi, programeri, očekivali smo rezultat od oko 10%. Zeznuli smo pokrivenost koda, izmjerili je, dobili 20%. Da proslavimo, išli smo po nagradu, ali kako smo išli po nju i gdje smo kasnije otišli, sasvim je druga priča.

3. Autotestovi mogu testirati izložene web usluge. Oracle vam to omogućuje i više nećemo nailaziti na niz problema.
4. I, naravno, naš automatizirani sustav testiranja može se primijeniti na drugi projekt. Rješenje koje smo dobili je univerzalno i zahtijeva samo korištenje Oraclea. Čuo sam da postoji interes za automatizirano testiranje na drugim projektima Sportmastera i možda ćemo ići na njih.

Zaključci

Da rezimiramo. Na projektu sustava vjernosti u Sportmasteru uspjeli smo implementirati automatizirani sustav testiranja. Njegova osnova je utPLSQL rješenje Stephena Feuersteina. Oko utPLSQL-a nalazi se kod za autotestove i pomoćne module koje ste sami napisali: pokretač, modul za generiranje podataka i drugi. Autotestovi se izvode svakodnevno i, što je najvažnije, rade i imaju koristi. Uvjereni smo da smo počeli izdavati softver više kvalitete. Istovremeno, dobiveno rješenje je univerzalno i može se slobodno primijeniti na bilo koji projekt gdje je potrebno organizirati automatizirano testiranje na Oracle DBMS.

PS Ovaj se članak pokazao ne baš konkretnim: ima puno teksta i praktički nema tehničkih primjera. Ako je tema globalno zanimljiva, spremni smo je nastaviti i vratiti se s nastavkom, gdje ćemo vam reći što se promijenilo u proteklih šest mjeseci i dati primjere koda.

Napišite komentare ako postoje točke koje bi trebalo naglasiti u budućnosti ili pitanja koja zahtijevaju otkrivanje.

U anketi mogu sudjelovati samo registrirani korisnici. Prijaviti se, molim.

Hoćemo li pisati više o ovome?

• Da naravno

• Ne hvala

Glasovalo je 12 korisnika. Suzdržana su bila 4 korisnika.

Izvor: www.habr.com