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

Prvi dio - ovdje.

Zamislite situaciju. Suočeni ste sa zadatkom razvoja nove funkcionalnosti. Imate iskustva od svojih prethodnika. Pod pretpostavkom da nemate moralne obaveze, šta biste uradili?

Najčešće se zaborave svi stari razvoji i sve počinje iznova. Niko ne voli da kopa po tuđem kodu, a ako imate vremena, zašto ne biste počeli kreirati svoj sistem? Ovo je tipičan pristup i u mnogo čemu je ispravan. Ali u našem projektu postupili smo drugačije. Zasnovali smo budući sistem automatizovanog testiranja na razvoju jediničnih testova na utPLSQL od naših prethodnika, a zatim smo krenuli sa radom u nekoliko paralelnih pravaca.

1. Vraćanje starih jediničnih testova. Oporavak znači prilagođavanje testova postojećem stanju sistema lojalnosti i prilagođavanje testova utPLSQL standardima.
2. Rješavanje problema sa razumijevanjem, a šta tačno, koje metode i procese, pokrili smo autotestovima. Morate ili zadržati ove informacije u svojoj glavi ili izvući zaključke direktno na osnovu koda autotestova. Stoga smo odlučili napraviti katalog. Svakom autotestiranju smo dodijelili jedinstveni mnemonički kod, kreirali opis i popravili postavke (na primjer, pod kojim uslovima bi trebalo da se pokrene ili šta bi se trebalo dogoditi ako testiranje ne uspije). U suštini, popunili smo metapodatke o autotestovima i stavili ove metapodatke u standardne tabele utPLSQL šeme.
3. Definicija strategije ekspanzije, tj. izbor funkcionalnosti koja podliježe verifikaciji autotestovima. Odlučili smo da obratimo pažnju na tri stvari: nova poboljšanja sistema, incidente iz proizvodnje i ključne procese sistema. Dakle, razvijamo se paralelno sa izdavanjem, osiguravajući njegov veći kvalitet, istovremeno proširujući obim regresije i osiguravajući pouzdanost sistema na kritičnim mjestima. Prvo takvo usko grlo bio je proces raspodjele popusta i bonusa čekom.
4. Naravno, počeli smo razvijati nove autotestove. Jedan od prvih zadataka izdavanja bio je procijeniti performanse unaprijed definiranih uzoraka sistema lojalnosti. Naš projekat ima blok rigidno fiksiranih sql upita koji biraju klijente prema uslovima. Na primjer, dobijete listu svih kupaca čija je posljednja kupovina bila u određenom gradu ili listu kupaca čiji je prosječni iznos kupovine iznad određene vrijednosti. Nakon što smo napisali autotestove, provjerili smo unaprijed definirane uzorke, fiksne parametre performansi benčmarka, a dodatno smo dobili i testiranje opterećenja.
5. Rad sa autotestovima trebao bi biti zgodan. Dvije najčešće radnje su pokretanje autotestova i generiranje testnih podataka. Tako su se u našem sistemu pojavila dva pomoćna modula: modul za lansiranje i modul za generisanje podataka.

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

   Modul generisanja podataka predstavljen je kao paket, u kojem je za svaki objekat testiranog sistema (tabela u bazi podataka) kreirana posebna procedura koja u njega ubacuje podatke. U ovoj proceduri, zadane vrijednosti se ispunjavaju do maksimuma, što osigurava stvaranje objekata doslovno na klik prsta. A radi lakšeg korištenja, kreirani su predlošci za generirane podatke. Na primjer, kreirajte klijenta određene dobi sa probnim telefonom i obavljenom kupovinom.

6. Autotestovi bi se trebali pokrenuti i pokrenuti u razumnom vremenu za vaš sistem. Zbog toga je organizovano dnevno noćno lansiranje, na osnovu kojih se generiše izveštaj o rezultatima i šalje celom razvojnom timu korporativnom poštom. Nakon vraćanja starih autotestova i kreiranja novih, ukupno vrijeme rada je bilo 30 minuta. Ovakav nastup je svima odgovarao, budući da je lansiranje bilo van radnog vremena.

   Ali morali smo raditi na optimizaciji brzine rada. Sistem lojalnosti proizvodnje se ažurira noću. U sklopu jednog od izdanja, morali smo hitno izvršiti promjene noću. Polusatno čekanje na rezultate autotestiranja u tri sata ujutro nije usrećilo osobu odgovornu za izdavanje (gorljivi pozdrav Alekseju Vasjukovu!), a sledećeg jutra izrečeno je mnogo toplih reči našem sistemu. Ali kao rezultat, postavljen je 5-minutni standard za rad.

   Da bismo ubrzali performanse, koristili smo dvije metode: pokrenuli smo autotestove u tri paralelne niti, jer je to vrlo zgodno zbog arhitekture našeg sistema lojalnosti. I napustili smo pristup kada autotest ne kreira test podatke za sebe, već pokušava da pronađe nešto prikladno u sistemu. Nakon izmjena, ukupno vrijeme rada je smanjeno na 3-4 minute.

7. Projekat sa autotestovima trebao bi biti u mogućnosti da se postavi na različite štandove. Na početku puta bilo je pokušaja da napišemo vlastite batch fajlove, ali je postalo jasno da je samonapisana automatska instalacija potpuni užas, pa smo se okrenuli industrijskim rješenjima. Zbog činjenice da projekat ima puno koda direktno (prije svega, pohranjujemo kod autotestova) i vrlo malo podataka (glavni podaci su metapodaci o autotestovima), pokazalo se da je vrlo lako integrirati u Liquibase projekat.

   To je nezavisna biblioteka otvorenog koda za praćenje, upravljanje i primenu promena šeme baze podataka. Upravlja se preko komandne linije ili okvira kao što je Apache Maven. Princip rada Liquibase-a je prilično jednostavan. Imamo projekat organizovan na određen način, koji se sastoji od promena ili skripti koje treba da se roluju na ciljni server, i kontrolnih fajlova koji određuju kojim redosledom i sa kojim parametrima te promene treba da se instaliraju.

   Na nivou DBMS-a kreira se posebna tabela u kojoj 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 Liquibase-u, lako možemo uvesti promjene u naš sistem na bilo koje kolo. Automatski testovi se sada izvode na krugovima za testiranje i oslobađanje, kao i na kontejnerima (kola osobnog programera).

Dakle, hajde da pričamo o rezultatima primene našeg sistema za testiranje jedinica.

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. Štaviše, neke od ovih grešaka su samo indirektno povezane sa funkcionalnošću koju smo zaista želeli da promenimo. Postoje jake sumnje da su ove greške pronađene ručnim testiranjem.
2. Tim je stekao povjerenje da određena funkcionalnost radi ispravno... Prije svega, to se tiče naših kritičnih procesa. Na primjer, u proteklih šest mjeseci nismo imali problema sa distribucijom popusta i bonusa po čekovima, uprkos promjenama koje smo vršili pri svakom izdanju, iako su se u prethodnim periodima greške dešavale s određenom učestalošću
3. Uspjeli smo smanjiti broj iteracija testiranja. Zbog činjenice da su autotestovi pisani za nove funkcionalnosti, analitičari i honorarni testeri dobijaju kvalitetniji kod, jer već je potvrđeno.
4. Dio razvoja automatiziranog testiranja koriste programeri. Na primjer, testni podaci o kontejnerima kreiraju se pomoću modula za generiranje objekata.
5. Važno je da smo razvili „prihvatanje“ automatizovanog sistema testiranja od strane programera. Postoji razumijevanje da je ovo važno i korisno. I iz vlastitog iskustva mogu reći da je to daleko od slučaja. Autotestove treba pisati, održavati i razvijati, rezultate analizirati, a često se ti vremenski troškovi jednostavno ne isplati. Mnogo je lakše ići u proizvodnju i tamo rješavati probleme. Kod nas se programeri postrojavaju i traže da pokriju svoju funkcionalnost autotestovima.

Šta sledi

Hajde da razgovaramo o planovima razvoja projekta automatizovanog testiranja.

Naravno, sve dok je Sportmaster sistem lojalnosti živ i nastavlja da se razvija, autotestovi se takođe mogu razvijati gotovo beskonačno. Stoga je glavni pravac razvoja proširenje područja pokrivenosti.

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

Ali to su očigledni putevi razvoja. Ako govorimo o nečem netrivijalnijem, ističemo sljedeće:

1. Sada se autotestovima upravlja na nivou DBMS-a, tj. Za uspješan rad potrebno je poznavanje PL/SQL-a. Ako je potrebno, upravljanje sistemom (na primjer, pokretanje ili kreiranje metapodataka) može se ukloniti pomoću neke vrste admin panela koristeći Jenkins ili nešto slično.
2. Svi vole kvantitativne i kvalitativne pokazatelje. Za automatsko testiranje, takav univerzalni indikator je pokrivenost koda ili metrika pokrivenosti koda. Koristeći ovaj indikator, možemo odrediti koji procenat koda našeg sistema koji se testira je pokriven autotestovima. Počevši od verzije 12.2, Oracle pruža mogućnost izračunavanja ove metrike i predlaže korištenje standardnog paketa DBMS_PLSQL_CODE_COVERAGE.

   Naš sistem autotestiranja star je nešto više od godinu dana i možda je vrijeme za procjenu pokrivenosti. U mom posljednjem projektu (projekt koji nije Sportmaster) ovo se dogodilo. Godinu dana nakon rada na autotestovima, menadžment je postavio zadatak da procijeni koji procenat koda smo pokrili. Sa više od 1% pokrivenosti, menadžment bi bio zadovoljan. Mi, programeri, očekivali smo rezultat od oko 10%. Zeznuli smo pokrivenost koda, izmjerili, dobili 20%. Da proslavimo, išli smo po nagradu, ali kako smo to išli i kuda smo kasnije otišli, to je sasvim druga priča.

3. Autotestovi mogu testirati izložene web usluge. Oracle vam to dozvoljava i više nećemo imati niz problema.
4. I, naravno, naš automatizirani sistem testiranja može se primijeniti na drugi projekat. Rješenje koje smo dobili je univerzalno i zahtijeva samo korištenje Oraclea. Čuo sam da postoji interesovanje za automatizovano testiranje na drugim Sportmaster projektima i, možda, idemo na njih.

nalazi

Hajde da rezimiramo. Na projektu sistema lojalnosti u Sportmasteru uspjeli smo implementirati automatizirani sistem testiranja. Njegova osnova je utPLSQL rješenje Stephena Feuersteina. Oko utPLSQL je kod za autotestove i pomoćne samopisne module: pokretač, modul za generisanje podataka i drugi. Autotestovi se izvode svakodnevno i, što je najvažnije, rade i imaju koristi. Uvjereni smo da smo počeli sa izdavanjem softvera višeg kvaliteta. Istovremeno, rezultirajuće rješenje je univerzalno i može se slobodno primijeniti na bilo koji projekt gdje je potrebno organizirati automatizirano testiranje na Oracle DBMS-u.

PS Ovaj članak se pokazao ne baš konkretan: ima puno teksta i praktički nema tehničkih primjera. Ako je tema globalno interesantna, onda smo spremni da je nastavimo i vratimo se nastavkom, gde ćemo vam reći šta se promenilo u proteklih šest meseci i dati primere koda.

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

Samo registrovani korisnici mogu učestvovati u anketi. Prijavite semolim.

Hoćemo li pisati više o ovome?

• Ma naravno

• Ne hvala

Glasalo je 12 korisnika. 4 korisnika je bila uzdržana.

izvor: www.habr.com