Hej Habr!
Moje ime je Maxim Ponomarenko i programer sam u Sportmasteru. Imam 10 godina iskustva u IT području. Karijeru je započeo u ručnom testiranju, a zatim se prebacio na razvoj baza podataka. Zadnje 4 godine, skupljajući znanja stečena u testiranju i razvoju, automatizirao sam testiranje na razini DBMS-a.
U Sportmaster timu sam nešto više od godinu dana i razvijam automatizirano testiranje na jednom od velikih projekata. U travnju smo dečki iz Sportmaster Laba i ja govorili na konferenciji u Krasnodaru, moje se izvješće zvalo “Jedinički testovi u DBMS-u”, a sada ga želim podijeliti s vama. Bit će puno teksta pa sam odlučio izvještaj podijeliti u dva posta. U prvom ćemo govoriti o autotestovima i testiranju općenito, au drugom ću se detaljnije osvrnuti na naš sustav jediničnog testiranja i rezultate njegove primjene.
Prvo, malo dosadne teorije. Što je automatizirano testiranje? Riječ je o testiranju koje se provodi softverski, au suvremenoj informatici se sve više koristi u razvoju softvera. To je zbog činjenice da tvrtke rastu, rastu njihovi informacijski sustavi, a sukladno tome raste i količina funkcionalnosti koje je potrebno testirati. Provođenje ručnog testiranja postaje sve skuplje.
Radio sam za veliku tvrtku čija izdanja izlaze svaka dva mjeseca. Pritom je cijeli mjesec potrošeno na to da desetak testera ručno provjeri funkcionalnost. Zahvaljujući implementaciji automatizacije od strane malog tima programera, uspjeli smo smanjiti vrijeme testiranja na 2 tjedna u godinu i pol. Ne samo da smo povećali brzinu testiranja, već smo i poboljšali njegovu kvalitetu. Automatizirani testovi se redovito pokreću i uvijek provode cijeli tijek provjera koji su u njima uključeni, odnosno isključujemo ljudski faktor.
Moderni IT karakterizira činjenica da se od programera može zahtijevati ne samo pisanje koda proizvoda, već i pisanje jediničnih testova koji provjeravaju ovaj kod.
Ali što ako se vaš sustav prvenstveno temelji na poslužiteljskoj logici? Ne postoji univerzalno rješenje ili najbolja praksa na tržištu. U pravilu, tvrtke rješavaju ovaj problem stvaranjem vlastitog sustava testiranja koji sami pišu. Ovo je naš vlastiti automatizirani sustav testiranja koji smo sami napisali i koji je nastao na našem projektu i o njemu ću govoriti u svom izvješću.
Testiranje lojalnosti
Prvo, razgovarajmo o projektu u kojem smo postavili automatizirani sustav testiranja. Naš projekt je sustav vjernosti Sportmaster (usput, o tome smo već pisali u ).
Ako je vaša tvrtka dovoljno velika, tada će vaš sustav lojalnosti imati tri standardna svojstva:
- Vaš sustav će biti visoko opterećen
- Vaš će sustav sadržavati složene računalne procese
- Vaš sustav će se aktivno poboljšavati.
Krenimo redom... Ukupno, ako uzmemo u obzir sve brendove Sportmaster, onda imamo više od 1000 trgovina u Rusiji, Ukrajini, Kini, Kazahstanu i Bjelorusiji. Dnevno se u tim trgovinama obavi oko 300 kupnji. Odnosno, svake sekunde 000-3 provjere ulaze u naš sustav. Naravno, naš sustav lojalnosti je jako opterećen. A budući da se aktivno koristi, moramo osigurati najviše standarde njegove kvalitete, jer svaka greška u softveru znači velike novčane, reputacijske i druge gubitke.
U isto vrijeme Sportmaster provodi više od stotinu različitih promocija. Postoje razne akcije: postoje akcije proizvoda, postoje one posvećene danu u tjednu, postoje one vezane uz određenu trgovinu, postoje akcije za iznos računa, postoje za broj robe. Općenito, nije loše. Klijenti imaju bonuse i promotivne kodove koji se koriste pri kupnji. Sve to dovodi do činjenice da je izračunavanje bilo koje narudžbe vrlo netrivijalan zadatak.
Algoritam koji implementira obradu narudžbi je uistinu užasan i kompliciran. I bilo kakve promjene ovog algoritma su prilično riskantne. Činilo se da bi i naizgled beznačajne promjene mogle dovesti do sasvim nepredvidivih učinaka. Ali upravo su takvi složeni računalni procesi, posebice oni koji implementiraju kritične funkcionalnosti, najbolji kandidati za automatizaciju. Ručno provjeravanje desetaka sličnih slučajeva oduzima puno vremena. A budući da je ulazna točka u proces nepromijenjena, nakon što ste je jednom opisali, možete brzo izraditi automatske testove i biti sigurni da će funkcionalnost raditi.
Budući da se naš sustav aktivno koristi, tvrtka će željeti nešto novo od vas, živjeti u korak s vremenom i biti orijentirana na kupca. U našem sustavu vjernosti, izdanja izlaze svaka dva mjeseca. To znači da svaka dva mjeseca trebamo napraviti kompletnu regresiju cijelog sustava. Istodobno, naravno, kao u svakom modernom IT-u, razvoj ne ide odmah od programera do proizvodnje. Nastaje u krugu programera, zatim sukcesivno prolazi kroz testni stol, puštanje, prihvaćanje i tek onda završava u proizvodnji. Minimalno, na testnim i puštajućim krugovima, moramo izvršiti potpunu regresiju cijelog sustava.
Opisana svojstva standardna su za gotovo svaki sustav lojalnosti. Razgovarajmo o značajkama našeg projekta.
Tehnološki gledano, 90% logike našeg sustava vjernosti temelji se na poslužitelju i implementirano je na Oracleu. U Delphiju je izložen klijent koji obavlja funkciju administratora automatiziranog radnog mjesta. Postoje izložene web usluge za vanjske aplikacije (na primjer web mjesto). Stoga je vrlo logično da ćemo, ako implementiramo automatizirani sustav testiranja, to učiniti na Oracleu.
Sustav lojalnosti u Sportmasteru postoji više od 7 godina i kreiran je od strane pojedinačnih programera... Prosječan broj programera na našem projektu u ovih 7 godina bio je 3-4 osobe. No, tijekom prošle godine naš tim je značajno porastao i sada na projektu radi 10 ljudi. Odnosno, na projekt dolaze ljudi koji nisu upoznati s tipičnim zadacima, procesima i arhitekturom. A postoji i povećani rizik da ćemo propustiti pogreške.
Projekt karakterizira nepostojanje posvećenih testera kao osoblja. Postoji, naravno, testiranje, ali testiranje provode analitičari, uz svoje ostale glavne obveze: komunikaciju s poslovnim korisnicima, korisnicima, razvoj zahtjeva sustava itd. itd... Unatoč činjenici da se testiranje provodi vrlo kvalitetno (ovo je posebno prikladno spomenuti, jer bi nekima od analitičara moglo zapeti za oko u ovom izvješću), učinkovitost specijalizacije i koncentracije na jednu stvar nije poništena .
S obzirom na sve navedeno, za poboljšanje kvalitete isporučenog proizvoda i smanjenje vremena razvoja, ideja automatizacije testiranja na projektu čini se vrlo logičnom. I u različitim fazama postojanja sustava vjernosti, pojedinačni programeri su se trudili pokriti svoj kod jediničnim testovima. Sve u svemu, bio je to prilično nepovezan proces, sa svatko koristio vlastitu arhitekturu i metode. Konačni rezultati bili su uobičajeni za jedinične testove: testovi su razvijeni, korišteni neko vrijeme, pohranjeni u verzioniranoj pohrani datoteka, ali su u nekom trenutku prestali raditi i zaboravljeni. Prije svega, to je zbog činjenice da su testovi bili vezani više za određenog izvođača, a ne za projekt.
utPLSQL dolazi u pomoć
Znate li nešto o Stephenu Feuersteinu?
Radi se o pametnjakoviću koji je dugi dio svoje karijere posvetio radu s Oracleom i PL/SQL-om, te je napisao dosta radova na ovu temu. Jedna od njegovih poznatih knjiga zove se: “Oracle PL/SQL. Za profesionalce." Stephen je bio taj koji je razvio utPLSQL rješenje ili, kako to znači, Unit Testing framework za Oracle PL/SQL. Rješenje utPLSQL je kreirano 2016. godine, ali se na njemu i dalje aktivno radi i izlaze nove verzije. U vrijeme podnošenja izvješća, posljednja verzija datira od 24. ožujka 2019.
Što je. Ovo je zaseban projekt otvorenog koda. Teži nekoliko megabajta, uključujući primjere i dokumentaciju. Fizički, to je zasebna shema u ORACLE bazi podataka sa skupom paketa i tablica za organiziranje jediničnog testiranja. Instalacija traje nekoliko sekundi. Posebnost utPLSQL-a je njegova jednostavnost korištenja.
Globalno gledano, utPLSQL je mehanizam za pokretanje jediničnih testova, pri čemu se jedinični test podrazumijeva kao obične Oracle batch procedure, čija organizacija slijedi određena pravila. Osim pokretanja, utPLSQL pohranjuje dnevnik svih vaših testnih pokretanja, a također ima interni sustav izvješćivanja.
Pogledajmo primjer kako izgleda jedinični testni kod implementiran ovom tehnikom.
Dakle, zaslon prikazuje kod za tipičnu specifikaciju paketa s jediničnim testovima. Koji su obvezni zahtjevi? Paket mora imati prefiks "utp_". Sve procedure s testovima moraju imati potpuno isti prefiks. Paket mora sadržavati dvije standardne procedure: “utp_setup” i “utp_teardown”. Prvi postupak se poziva ponovnim pokretanjem svakog testa jedinice, drugi - nakon pokretanja.
“utp_setup”, u pravilu, priprema naš sustav za pokretanje jediničnog testa, na primjer, stvaranje testnih podataka. “utp_teardown” - naprotiv, sve se vraća na izvorne postavke i resetira rezultate pokretanja.
Evo primjera najjednostavnijeg jediničnog testa koji provjerava normalizaciju unesenog telefonskog broja korisnika na standardni obrazac za naš sustav vjernosti. Ne postoje obavezni standardi o tome kako napisati procedure s jediničnim testovima. U pravilu se poziva metoda sustava koji se testira, a rezultat koji ta metoda vraća uspoređuje se s referentnom. Važno je da se usporedba referentnog i dobivenog rezultata odvija standardnim utPLSQL metodama.
Jedinični test može imati bilo koji broj provjera. Kao što se može vidjeti iz primjera, vršimo četiri uzastopna poziva testiranoj metodi kako bismo normalizirali telefonski broj i procijenili rezultat nakon svakog poziva. Kada razvijate jedinični test, morate uzeti u obzir da postoje provjere koje ni na koji način ne utječu na sustav, a nakon nekih morate se vratiti na izvorno stanje sustava.
Na primjer, u prikazanom jediničnom testu jednostavno formatiramo uneseni telefonski broj, što ni na koji način ne utječe na sustav vjernosti.
A ako pišemo jedinične testove koristeći metodu stvaranja novog klijenta, tada će se nakon svakog testa u sustavu kreirati novi klijent, što može utjecati na naknadno pokretanje testa.
Ovako se izvode jedinični testovi. Postoje dvije moguće opcije pokretanja: izvođenje svih jediničnih testova iz određenog paketa ili izvođenje određenog jediničnog testa u određenom paketu.
Ovako izgleda primjer internog sustava izvješćivanja. Na temelju rezultata jediničnog testa, utPLSQL gradi malo izvješće. U njemu vidimo rezultat za svaku pojedinu provjeru i ukupni rezultat jediničnog testa.
6 pravila autotestova
Prije nego što smo krenuli u izradu novog sustava za automatizirano testiranje sustava lojalnosti, zajedno s menadžmentom odredili smo principe kojih bi se trebali pridržavati naši budući automatizirani testovi.
- Autotestovi moraju biti učinkoviti i korisni. Imamo divne programere, koje svakako treba spomenuti, jer će neki od njih vjerojatno vidjeti ovaj izvještaj, a pišu divan kod. Ali čak ni njihov prekrasan kod nije savršen i ima, ima i nastavit će sadržavati pogreške. Za pronalaženje ovih pogrešaka potrebni su automatski testovi. Ako to nije slučaj, onda ili pišemo loše autotestove, ili smo došli do mrtvog područja koje se u principu ne razvija. U oba slučaja nešto radimo krivo i naš pristup jednostavno nema smisla.
- Treba koristiti autotestove. Nema smisla potrošiti puno vremena i truda na pisanje softverskog proizvoda, staviti ga u repozitorij i zaboraviti. Testove treba izvoditi, i to što je moguće redovitije.
- Autotestovi bi trebali raditi stabilno. Bez obzira na doba dana, postolje za lansiranje i ostale postavke sustava, probna izvođenja trebala bi dovesti do istog rezultata. U pravilu, to je osigurano činjenicom da autotestovi rade s posebnim testnim podacima s fiksnim postavkama sustava.
- Autotestovi bi trebali raditi brzinom prihvatljivom za vaš projekt. Ovo vrijeme se određuje pojedinačno za svaki sustav. Neki ljudi mogu si priuštiti da rade cijeli dan, dok je drugima ključno to učiniti u nekoliko sekundi. Malo kasnije ću vam reći koje smo standarde brzine postigli u našem projektu.
- Razvoj autotesta trebao bi biti fleksibilan. Nije preporučljivo odbiti testiranje bilo koje funkcionalnosti samo zato što to prije nismo učinili ili iz nekog drugog razloga. utPLSQL ne nameće nikakva ograničenja u razvoju, a Oracle vam u načelu omogućuje implementaciju raznih stvari. Većina problema ima rješenje, samo je pitanje vremena i truda.
- Razmjestivost. Imamo nekoliko postolja na kojima trebamo izvoditi testove. Na svakom štandu, ispis podataka može se ažurirati u bilo kojem trenutku. Potrebno je provesti projekt s automatskim testovima na takav način da možete bezbolno provesti njegovu punu ili djelomičnu instalaciju.
A u drugom postu za par dana reći ću vam što smo radili i kakve smo rezultate postigli.
Izvor: www.habr.com