Bok, Habr!
Zovem se Maksim Ponomarenko i ja sam programer u Sportmasteru. Imam deset godina iskustva u IT sektoru. Karijeru sam započeo u području ručnog testiranja, a zatim se preusmjerio na razvoj baza podataka. Posljednje četiri godine, akumulirajući znanja stečena u testiranju i razvoju, bavim se automatizacijom testiranja na razini sustava upravljanja bazama podataka.
U timu Sportmastera sam nešto više od godine dana i na jednom od većih projekata se bavim razvojem automatiziranog testiranja. U travnju smo s ekipom iz Sportmaster Lab sudjelovali na konferenciji u Krasnodaru, moj izlaganje se zvalo „Unit testovi u sustavu upravljanja bazama podataka“, i sada želim podijeliti to s vama. Bit će puno teksta, pa sam odlučio razbiti izlaganje na dva posta. U prvom ćemo razgovarati o automatiziranim testovima i testiranju općenito, dok ću u drugom detaljnije govoriti o našem sustavu unit testiranja i rezultatima njegove primjene.
Na početku malo dosadne teorije. Što je automatizirano testiranje? To je testiranje koje provode softverski alati, a u modernom IT-u se sve više i više koristi pri razvoju softvera. To je povezano s time da tvrtke rastu, rastu njihovi informacijski sustavi i sukladno tome raste i količina funkcionalnosti koju je potrebno testirati. Provesti ručno testiranje postaje sve skuplje i skuplje.
Radio sam u jednoj velikoj tvrtki čiji se izdanja objavljuju svaka dva mjeseca. Pri tome se cijeli mjesec troši na to da desetak testera ručno provjeravaju funkcionalnost. Zahvaljujući implementaciji automatizacije, mala ekipa programera uspjela je tijekom godinu i pol dana smanjiti vrijeme testiranja na 2 tjedna. Ne samo da smo povećali brzinu testiranja, nego i poboljšali njegovu kvalitetu. Automatizirani testovi se redovito pokreću i uvijek izvršavaju cijeli set ugrađenih provjera, što znači da isključujemo ljudski faktor.
Za moderni IT karakteristično je to da od programera može biti zahtijevano ne samo pisanje koda proizvoda, nego i pisanje unit testova koji provjeravaju taj kod.
Što učiniti ako se vaš sustav prvenstveno oslanja na serversku logiku? Na tržištu ne postoji univerzalno rješenje niti najbolje prakse. Obično, tvrtke rješavaju ovaj problem stvaranjem vlastitog sustava za testiranje. Takav vlastiti sustav automatiziranog testiranja razvijen je u našem projektu, a o njemu ću govoriti u svom izlaganju.
Testiranje lojalnosti
Najprije ćemo razgovarati o projektu u kojem smo postavili sustav automatiziranog testiranja. Naš projekt je sustav lojalnosti Sportmastera (usput, već smo pisali o njemu u ).
Ako je vaša tvrtka dovoljno velika, vaš sustav lojalnosti imat će tri standardne osobine:
- Vaš sustav bit će visoko opterećen
- Vaš sustav će sadržavati složene računske procese
- Vaš sustav će se aktivno nadograđivati.
Idemo redom… Ukupno, ako gledamo sve marke Sportmastera, imamo više od 1000 trgovina na području Rusije, Ukrajine, Kine, Kazahstana i Bjelorusije. U tim trgovinama svaki dan se odvija oko 300.000 kupnji. To znači da u naš sustav svake sekunde stigne 3-4 računa. Naravno, naš sustav lojalnosti je visoko opterećen. A kako se aktivno koristi, moramo osigurati najviše standarde njegove kvalitete, jer svaka greška u softveru može dovesti do velikih financijskih, reputacijskih i drugih gubitaka.
Istovremeno u Sportmasteru radi više od stotinu različitih akcija. Akcije su raznolike: postoje akcije na proizvode, one vezane uz dan u tjednu, akcije povezane s određenom trgovinom, akcije na iznos računa, hajde i na količinu proizvoda. Ukratko, kompleksno. Klijenti imaju bonuse, postoje promotivni kodovi koji se koriste prilikom kupnje. Sve to dovodi do toga da obračun bilo kojeg narudžbe nije trivijalan zadatak.
Algoritam koji provodi obradu narudžbe je doista strašan i složen. Bilo kakve izmjene u tom algoritmu - prilično su rizične. Čak i naizgled neznatne promjene mogu dovesti do prilično nepredvidivih efekata. Uvijek su takvi složeni računalni procesi, pogotovo oni koji ostvaruju kritičnu funkcionalnost - najbolji kandidati za automatizaciju. Provjeravanje stotina sličnih slučajeva ručno oduzima previše vremena. Kako je ulazna točka u proces nepromijenjena, jednom kada je opišemo, možemo relativno brzo generirati automatizirane testove i biti sigurni u ispravnost funkcionalnosti.
S obzirom na to da naš sustav aktivno koriste korisnici, poslovanje će od vas očekivati nešto novo, da ostanete u toku s vremenom i budete orijentirani na klijente. U našem sustavu lojalnosti, izdanja izlaze svaka dva mjeseca. To znači da svaka dva mjeseca trebamo provesti potpunu regresiju cijelog sustava. Pritom, kao i u svakoj modernoj IT okolini, razvoj ne ide odmah od programera do produkcije. On započinje u razvojnim okruženjima, potom prolazi kroz testne, izdavačke i prihvatne faze, a tek potom završava u produkciji. Na najmanje testnim i izdavačkim okruženjima trebamo provesti potpunu regresiju cijelog sustava.
Opisane karakteristike su standardne za praktički svaki sustav lojalnosti. Razgovarajmo o specifičnostima našeg projekta.
Tehnološki, 90% logike našeg sustava lojalnosti je poslužiteljska i implementirana je na Oracleu. Postoji klijent razvijen u Delphiju koji obavlja funkciju APM-administratora. Postavljeni su web servisi za vanjske aplikacije (na primjer, web stranica). Stoga je prilično logično da ako budemo razvijali sustav automatiziranog testiranja, to radimo na Oracleu.
Sistem lojalnosti u Sportmasteru postoji više od 7 godina i razvijan je od strane pojedinačnih programera... Prosječan broj programera na našem projektu tijekom tih 7 godina bio je 3-4 osobe. No, u posljednjoj godini naš tim se značajno povećao, i sada na projektu radi 10 ljudi. To znači da u projekt dolaze ljudi koji nisu upoznati s tipičnim zadacima, procesima i arhitekturom. Također postoji povećani rizik da ćemo propuštati greške.
Za projekt je karakteristično da nema odvojenih testera kao stalnih zaposlenika. Testiranje, naravno, postoji, ali se njime bave analitičari, uz svoje druge osnovne obaveze: komunikaciju s poslovnim naručiteljima, korisnicima, razradu zahtjeva za sustav i slično... Iako se testiranje provodi vrlo kvalitetno (posebno je važno napomenuti, jer bi neki od analitičara mogli pročitati ovaj izvještaj), učinkovitost specijalizacije i koncentracije na nečemu jednom nikako nije moguće zanemariti.
Uzimajući u obzir sve prethodno navedeno, za poboljšanje kvalitete isporučenog proizvoda i smanjenje vremena razvoja, ideja o automatizaciji testiranja u projektu čini se vrlo logičnom. Tijekom različitih faza postojanja sustava lojalnosti pojedini programeri su se trudili da pokriju svoj kod jediničnim testovima. To je u cjelini bio prilično raspršen proces, gdje je svaki koristio svoju arhitekturu i metode. Zajednički za jedinične testove bili su konačni rezultati: testovi su razvijeni, neko vrijeme korišteni, pohranjeni u verzionom spremištu datoteka, ali su u nekom trenutku prestali s izvođenjem i zaboravljeni. Prije svega, to se događalo zato što su testovi bili više vezani uz konkretnog izvođača, a ne uz projekt.
U pomoć dolazi utPLSQL
Znate li nešto o Stephen Fehrstein?
To je pametan tip koji je veliki deo svoje karijere posvetio radu sa Oracle-om i PL/SQL-om, napisao je prilično mnogo radova na tu temu. Njegova poznata knjiga nosi naziv: „Oracle PL/SQL. Za profesionalce“. Upravo je Steven razvio rešenje utPLSQL, ili, kako se to dekodira, Unit Testing framework for Oracle PL/SQL. Rešenje utPLSQL stvoreno je 2016. godine, ali se na njemu i dalje aktivno radi i izdaju nove verzije. Na dan predavanja, poslednja verzija je izdata 24. marta 2019. godine.
Šta je to? To je poseban open-source projekat. Teži nekoliko megabajta, uključujući primere i dokumentaciju. Fizički predstavlja posebnu šemu u ORACLE bazi podataka sa setom paketa i tabela za organizaciju unit-testiranja. Instalacija traje nekoliko sekundi. Odlike utPLSQL-a su jednostavnost korišćenja.
U globalu, utPLSQL predstavlja mehanizam za pokretanje unit-testova, gde se pod unit-testom smatraju obične Oracle paketne procedure, čija organizacija odgovara određenim pravilima. Pored pokretanja, utPLSQL čuva log svih vaših testnih pokretanja, kao i unutrašnji sistem izveštavanja.
Hajde da pogledamo primer kako izgleda kod unit-testa, realizovan prema ovoj metodologiji.
Dakle, na ekranu je prikazan kod tipične specifikacije paketa sa unit-testovima. Koji su obavezni zahtevi? Paket treba da ima prefiks „utp_“. Iste prefikse moraju imati sve procedure sa testovima. U paketu moraju postojati dve standardne procedure: „utp_setup“ i „utp_teardown“. Prva procedura se poziva pre pokretanja svakog unit-testa, dok se druga poziva nakon pokretanja.
„utp_setup“ obično priprema naš sistem za pokretanje unit-testa, na primer, kreira testne podatke. „utp_teardown“ – naprotiv, vraća sve na izvorne postavke i briše rezultate pokretanja.
Evo primjera najjednostavnije unit-test procedure koja provjerava normalizaciju unesenog broja telefona klijenta u standardni oblik za naš sustav lojalnosti. Ne postoje obavezni standardi za pisanje procedura s unit-testovima. Obično se poziva neka metoda testiranog sustava, a rezultat koji ta metoda vrati uspoređuje se s uzorakom. Važno je da se usporedba uzornog rezultata i dobivenog provodi putem standardnih utPLSQL metoda.
U unit-testu može biti bilo koji broj provjera. Kao što se može vidjeti iz primjera, izvodimo četiri uzastopna poziva testirane metode za normalizaciju broja telefona i nakon svakog poziva ocjenjujemo rezultat. Tijekom razvoja unit-testa treba imati na umu da postoje provjere koje ne utječu na sustav, dok se nakon nekih mora vraćati na početno stanje sustava.
Na primjer, u prikazanom unit-testu jednostavno formatiramo ulazni broj telefona, što ne utječe na sustav lojalnosti.
A ako pišemo unit-teste za metodu stvaranja novog klijenta, nakon svake provjere u sustavu će biti stvoren novi klijent, što može utjecati na kasnije izvođenje testa.
Tako se pokreću unit-testovi. Dopuštena su dva načina pokretanja: pokretanje svih unit-testova iz određenog paketa ili pokretanje određenog unit-testa unutar određenog paketa.
Ovo je primjer unutarnjeg sustava izvještavanja. Na temelju rezultata rada unit-testa utPLSQL stvara kratki izvještaj. U njemu vidimo rezultate svake pojedinačne provjere i ukupni rezultat izvršenja unit-testa.
6 pravila automatiziranih testova
Prije nego što započnemo s izradom novog sustava automatiziranog testiranja sustava lojalnosti, u suradnji s vodstvom smo definirali načela kojima naši budući automatizirani testovi trebaju odgovarati.
- Automatizirani testovi moraju biti učinkoviti i donijeti koristi. Imamo sjajne programere o kojima treba reći, jer će netko od njih sigurno vidjeti ovu prezentaciju, a oni pišu fantastičan kod. No čak ni njihov fantastičan kod nije savršen i sadržava, sadrži i sadržavat će greške. Automatizirani testovi moraju te greške otkrivati. Ako to nije slučaj, ili pišemo loše automatizirane testove, ili smo došli u mrtvu točku koja se uopće ne osvežava. U oba slučaja nešto radimo pogrešno i naš pristup jednostavno je besmislen.
- Automatizirani testovi moraju se koristiti. Besmisleno je trošiti hrpu vremena i truda na pisanje softverskog proizvoda, pohranjivanje u repozitorij i zaboravljanje na njega. Testovi moraju biti pokrenuti, i to što je moguće redovitije.
- Automatizirani testovi moraju raditi stabilno. Bez obzira na doba dana, okruženje za pokretanje i ostale postavke sustava, pokretanje testova treba dati isti rezultat. Obično to osigurava da automatizirani testovi rade s posebnim testnim podacima uz fiksne postavke sustava.
- Automatizirani testovi trebaju raditi s prihvatljivom brzinom za vaš projekt. Ova brzina određena je individualno za svaki sustav. Netko može raditi cijeli dan, dok je za nekoga ključno završiti unutar sekundi. O kakvim smo brzinama postigli u našem projektu, reći ću malo kasnije.
- Razvoj automatiziranih testova mora biti fleksibilan. Ne preporučuje se odustajanje od provjere bilo koje funkcionalnosti samo zato što to do sada nismo radili ili iz nekih drugih uvjerenja. utPLSQL ne nameće nikakva ograničenja na razvoj, a Oracle u principu omogućuje implementaciju raznih stvari. Većina zadataka ima rješenje, samo je pitanje vremena i uloženog truda.
- Implementacija. Imamo nekoliko okruženja gdje je potrebno pokretanje testova. U svakom od okruženja može u bilo kojem trenutku biti ažurirana baza podataka. Projekt s automatiziranim testovima treba se voditi na način koji omogućava bezbolnu potpunu ili djelomičnu instalaciju.
U drugom postu za nekoliko dana reći ću što smo napravili i kakve smo rezultate postigli.
Izvor: habr.com
