Hej Habr!
Moje ime je Maxim Ponomarenko i ja sam programer u Sportmasteru. Imam 10 godina iskustva u IT oblasti. Karijeru je započeo u ručnom testiranju, a zatim se prebacio na razvoj baze podataka. Zadnje 4 godine, akumulirajući znanje stečeno u testiranju i razvoju, automatizujem testiranje na nivou DBMS-a.
U Sportmaster timu sam nešto više od godinu dana i razvijam automatizirano testiranje na jednom od velikih projekata. U aprilu smo momci iz Sportmaster Lab-a i ja razgovarali na konferenciji u Krasnodaru, moj izveštaj se zvao „Testovi jedinica u DBMS-u“, a sada želim da ga podelim sa vama. Biće mnogo teksta, pa sam odlučio da izveštaj podelim na dva posta. U prvom ćemo govoriti o autotestovima i testiranju općenito, a u drugom ću se detaljnije zadržati na našem sistemu za testiranje jedinica i rezultatima njegove primjene.
Prvo, malo dosadna teorija. Šta je automatizovano testiranje? Riječ je o testiranju koje se provodi korištenjem softvera, au modernom IT-u sve se više koristi u razvoju softvera. To je zbog činjenice da kompanije rastu, njihovi informacioni sistemi rastu i, shodno tome, raste količina funkcionalnosti koju treba testirati. Provođenje ručnog testiranja postaje sve skuplje.
Radio sam za veliku kompaniju čija izdanja izlaze svaka dva mjeseca. U isto vrijeme, cijeli mjesec je 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 sedmice za godinu i po dana. Ne samo da smo povećali brzinu testiranja, već smo poboljšali i njegovu kvalitetu. Automatski testovi se pokreću redovno i oni uvijek provode cijeli tok provjera koji su u njih uključeni, odnosno isključujemo ljudski faktor.
Moderni IT karakterizira činjenica da se od programera može zahtijevati ne samo da napiše kod proizvoda, već i da napiše jedinične testove koji provjeravaju ovaj kod.
Ali šta ako je vaš sistem baziran prvenstveno na logici servera? Ne postoji univerzalno rješenje ili najbolja praksa na tržištu. Kompanije po pravilu rješavaju ovaj problem kreiranjem vlastitog sistema testiranja koji se piše. Ovo je naš vlastiti automatski sistem za testiranje koji je kreiran na našem projektu i o tome ću govoriti u svom izvještaju.
Testiranje lojalnosti
Prvo, hajde da pričamo o projektu gde smo postavili automatizovani sistem za testiranje. Naš projekat je Sportmaster sistem lojalnosti (o tome smo već pisali u ).
Ako je vaša kompanija dovoljno velika, onda će vaš sistem lojalnosti imati tri standardna svojstva:
- Vaš sistem će biti visoko opterećen
- Vaš sistem će sadržavati složene računarske procese
- Vaš sistem će se aktivno poboljšavati.
Idemo redom... Ukupno, ako uzmemo u obzir sve brendove Sportmaster, onda imamo više od 1000 prodavnica u Rusiji, Ukrajini, Kini, Kazahstanu i Bjelorusiji. U ovim prodavnicama se svakog dana obavi oko 300 kupovine. Odnosno, svake sekunde 000-3 provjere ulaze u naš sistem. Naravno, naš sistem lojalnosti je jako opterećen. A pošto se aktivno koristi, moramo obezbediti najviše standarde njegovog kvaliteta, jer svaka greška u softveru znači velike finansijske, reputacione i druge gubitke.
Istovremeno, Sportmaster vodi više od stotinu različitih promocija. Postoje razne promocije: postoje promocije proizvoda, postoje one posvećene danu u nedelji, postoje one vezane za određenu prodavnicu, postoje promocije za iznos računa, postoje za broj robe. Generalno, nije loše. Klijenti imaju bonuse i promotivne kodove koji se koriste prilikom kupovine. Sve to dovodi do činjenice da je izračunavanje bilo kojeg reda vrlo netrivijalan zadatak.
Algoritam koji implementira obradu naloga je zaista užasan i komplikovan. I bilo kakve promjene ovog algoritma su prilično rizične. Činilo se da bi naizgled beznačajne promjene mogle dovesti do prilično nepredvidivih efekata. Ali upravo su tako složeni računarski procesi, posebno oni koji implementiraju kritičnu funkcionalnost, najbolji kandidati za automatizaciju. Ručna provjera desetina sličnih slučajeva oduzima mnogo vremena. A budući da je ulazna tačka u proces nepromijenjena, nakon što ste je jednom opisali, možete brzo kreirati automatske testove i biti sigurni da će funkcionalnost funkcionirati.
Budući da se naš sistem aktivno koristi, preduzeće će od vas htjeti nešto novo, živjeti u skladu s vremenom i biti orijentirani na kupca. U našem sistemu lojalnosti, izdanja izlaze svaka dva mjeseca. To znači da svaka dva mjeseca trebamo izvršiti potpunu regresiju cijelog sistema. U isto vrijeme, naravno, kao iu svakom modernom IT-u, razvoj ne ide odmah od programera do proizvodnje. Nastaje u krugu programera, zatim sukcesivno prolazi kroz testni sto, oslobađa, prihvata i tek onda završava u proizvodnji. U najmanju ruku, na krugovima za testiranje i oslobađanje, moramo izvršiti potpunu regresiju cijelog sistema.
Opisana svojstva su standardna za gotovo svaki sistem lojalnosti. Hajde da razgovaramo o karakteristikama našeg projekta.
Tehnološki, 90% logike našeg sistema lojalnosti je zasnovano na serveru i implementirano na Oracle. U Delphiju je izložen klijent koji obavlja funkciju automatizovanog administratora radnog mesta. Postoje izložene web usluge za vanjske aplikacije (na primjer web stranicu). Stoga je vrlo logično da ako implementiramo automatizirani sistem za testiranje, to ćemo učiniti na Oracleu.
Sistem 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 tokom ovih 7 godina bio je 3-4 osobe. Ali u protekloj godini naš tim je značajno porastao i sada na projektu radi 10 ljudi. Odnosno, u projekat dolaze ljudi koji nisu upoznati sa tipičnim zadacima, procesima i arhitekturom. I povećan je rizik da ćemo propustiti greške.
Projekat karakteriše nedostatak namenskih testera kao jedinica osoblja. Testiranja, naravno, postoji, ali testiranje sprovode analitičari, pored svojih ostalih glavnih odgovornosti: komunikacija sa poslovnim korisnicima, korisnicima, razvoj sistemskih zahtjeva itd. itd... Unatoč činjenici da se testiranje obavlja vrlo kvalitetno (ovo je posebno primjereno napomenuti, budući da bi neki od analitičara mogli zapeti za oko ovog izvještaja), efikasnost specijalizacije i koncentracije na jednu stvar nije poništena .
Uzimajući u obzir sve navedeno, za poboljšanje kvalitete isporučenog proizvoda i smanjenje vremena razvoja, ideja o automatizaciji testiranja na projektu čini se vrlo logičnom. I u različitim fazama postojanja sistema lojalnosti, pojedinačni programeri su se trudili da svoj kod pokriju jediničnim testovima. Sve u svemu, to je bio prilično nepovezan proces, pri čemu je svako koristio svoju arhitekturu i metode. Konačni rezultati su bili zajednički za testove jedinice: testovi su razvijeni, korišteni neko vrijeme, pohranjeni u verzionisanom skladištu datoteka, ali su u nekom trenutku prestali da rade i bili zaboravljeni. Prije svega, to je bilo zbog činjenice da su testovi bili vezani više za određenog izvođača, a ne za projekt.
utPLSQL dolazi u pomoć
Da li znate nešto o Stephenu Feuersteinu?
Ovo je pametan momak koji je dugi dio svoje karijere posvetio radu sa Oracleom i PL/SQL-om, te je napisao prilično veliki broj 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, okvir za testiranje jedinica za Oracle PL/SQL. UtPLSQL rješenje je kreirano 2016. godine, ali se i dalje aktivno radi na njemu i izlaze nove verzije. U trenutku izvještavanja, najnovija verzija datira od 24. marta 2019. godine.
Šta je. Ovo je poseban projekat otvorenog koda. Teška je nekoliko megabajta, uključujući primjere i dokumentaciju. Fizički, to je zasebna šema u ORACLE bazi podataka sa skupom paketa i tabela za organizaciju jediničnog testiranja. Instalacija traje nekoliko sekundi. Karakteristična karakteristika utPLSQL-a je njegova jednostavnost upotrebe.
U globalu, utPLSQL je mehanizam za izvođenje jediničnih testova, gdje se jedinični test podrazumijeva kao obične Oracle skupne procedure, čija organizacija slijedi određena pravila. Pored pokretanja, utPLSQL pohranjuje dnevnik svih vaših probnih izvođenja, a također ima interni sistem izvještavanja.
Pogledajmo primjer kako izgleda kod za testiranje jedinice, implementiran ovom tehnikom.
Dakle, ekran prikazuje kod za tipičnu specifikaciju paketa sa jediničnim testovima. Koji su obavezni zahtjevi? Paket mora imati prefiks "utp_". Sve procedure sa testovima moraju imati potpuno isti prefiks. Paket mora sadržavati dvije standardne procedure: “utp_setup” i “utp_teardown”. Prva procedura se poziva ponovnim pokretanjem svakog testa jedinice, druga - nakon pokretanja.
“utp_setup”, po pravilu, priprema naš sistem za pokretanje jediničnog testa, na primjer, kreiranje testnih podataka. “utp_teardown” - naprotiv, sve se vraća na originalne postavke i resetuje rezultate pokretanja.
Evo primjera najjednostavnijeg jediničnog testa koji provjerava normalizaciju unesenog broja telefona korisnika na standardni obrazac za naš sistem lojalnosti. Ne postoje obavezni standardi o tome kako pisati procedure sa jediničnim testovima. Po pravilu se poziva metodu sistema koji se testira, a rezultat koji ova metoda vraća se upoređuje sa referentnim. Važno je da se poređenje referentnog rezultata i dobijenog odvija putem standardnih utPLSQL metoda.
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 broj telefona 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 sistem, a nakon nekih morate se vratiti u prvobitno stanje sistema.
Na primjer, u prikazanom jediničnom testu jednostavno formatiramo ulazni broj telefona, što ni na koji način ne utiče na sistem lojalnosti.
A ako pišemo jedinične testove koristeći metodu kreiranja novog klijenta, tada će se nakon svakog testa kreirati novi klijent u sistemu, što može utjecati na naknadno pokretanje testa.
Ovako se izvode testovi jedinica. Postoje dvije moguće opcije pokretanja: pokretanje svih testova jedinice iz određenog paketa ili pokretanje specifičnog testa jedinice u određenom paketu.
Ovako izgleda primjer internog sistema izvještavanja. Na osnovu rezultata testa jedinice, utPLSQL pravi mali izvještaj. U njemu vidimo rezultat za svaku konkretnu provjeru i ukupni rezultat jediničnog testa.
6 pravila autotestova
Prije nego što smo započeli kreiranje novog sistema za automatizirano testiranje sistema lojalnosti, zajedno sa menadžmentom, utvrdili smo principe sa kojima bi naši budući automatizirani testovi trebali biti usklađeni.
- Autotestovi moraju biti efikasni i korisni. Imamo divne programere, koje svakako treba spomenuti, jer će neki od njih vjerovatno vidjeti ovaj izvještaj, i pišu divan kod. Ali čak ni njihov divan kod nije savršen i ima, ima i nastavit će sadržavati greške. Za pronalaženje ovih grešaka potrebni su automatski testovi. Ako to nije slučaj, onda ili pišemo loše autotestove, ili smo došli u mrtvo područje koje se u principu ne razvija. U oba slučaja radimo nešto pogrešno i naš pristup jednostavno nema smisla.
- Treba koristiti autotestove. Nema smisla trošiti puno vremena i truda na pisanje softverskog proizvoda, stavljati ga u spremište i zaboraviti. Testove treba izvoditi, i to što je moguće redovnije.
- Autotestovi bi trebali raditi stabilno. Bez obzira na doba dana, lansirno postolje i druga podešavanja sistema, probni radovi bi trebali dovesti do istog rezultata. U pravilu, to je osigurano činjenicom da autotestovi rade sa posebnim testnim podacima sa fiksnim sistemskim postavkama.
- Autotestovi bi trebali raditi brzinom prihvatljivom za vaš projekat. Ovo vrijeme se određuje pojedinačno za svaki sistem. Neki ljudi mogu priuštiti da rade cijeli dan, dok drugi smatraju da je kritično da to urade za nekoliko sekundi. Reći ću vam malo kasnije koje smo standarde brzine postigli u našem projektu.
- Autotest razvoj bi trebao biti fleksibilan. Nije preporučljivo odbiti testiranje bilo koje funkcionalnosti samo zato što to nismo radili ranije ili iz nekog drugog razloga. utPLSQL ne nameće nikakva ograničenja razvoju, a Oracle vam u principu omogućava implementaciju raznih stvari. Većina problema ima rješenje, samo je pitanje vremena i truda.
- Mogućnost raspoređivanja. Imamo nekoliko štandova na kojima treba da radimo testove. Na svakom štandu, dump podataka se može ažurirati u bilo koje vrijeme. Potrebno je provesti projekt s automatskim testovima na način da možete bezbolno izvršiti njegovu punu ili djelomičnu instalaciju.
A u drugom postu za par dana ću vam reći šta smo uradili i koje smo rezultate postigli.
izvor: www.habr.com