Pozdravljeni, Habr!
Moje ime je Maxim Ponomarenko in sem razvijalec pri Sportmasterju. Imam 10 let izkušenj na področju IT. Kariero je začel v ročnem testiranju, nato pa se je preusmeril v razvoj baz podatkov. Zadnja 4 leta sem z nabiranjem znanja, pridobljenega pri testiranju in razvoju, avtomatiziral testiranje na ravni DBMS.
V ekipi Sportmaster sem nekaj več kot leto dni in razvijam avtomatsko testiranje na enem večjih projektov. Aprila smo s fanti iz Sportmaster Laba govorili na konferenci v Krasnodarju, moje poročilo se je imenovalo »Preizkusi enot v DBMS« in zdaj ga želim deliti z vami. Besedila bo veliko, zato sem se odločil poročilo razdeliti na dve objavi. V prvem bomo govorili o samodejnih testih in testiranju na splošno, v drugem pa se bom podrobneje posvetil našemu sistemu testiranja enot in rezultatih njegove uporabe.
Najprej malo dolgočasne teorije. Kaj je avtomatizirano testiranje? To je testiranje, ki se izvaja s programsko opremo, v sodobni IT pa se vse bolj uporablja pri razvoju programske opreme. To je posledica dejstva, da podjetja rastejo, rastejo njihovi informacijski sistemi in temu primerno raste količina funkcionalnosti, ki jih je treba testirati. Izvajanje ročnega testiranja postaja vse dražje.
Delal sem za veliko podjetje, katerega objave izhajajo vsaka dva meseca. Hkrati je bil cel mesec porabljen za ročno preverjanje delovanja ducata preizkuševalcev. Zahvaljujoč implementaciji avtomatizacije s strani majhne ekipe razvijalcev, nam je v letu in pol uspelo skrajšati čas testiranja na 2 tedna. Nismo le povečali hitrosti testiranja, ampak smo izboljšali tudi njegovo kakovost. Avtomatski testi se sprožijo redno in vedno izvajajo celoten potek preverjanj, ki so v njih vključeni, torej izključujemo človeški dejavnik.
Za sodobno informacijsko tehnologijo je značilno, da se lahko od razvijalca zahteva ne samo pisanje kode izdelka, ampak tudi pisanje enotnih testov, ki preverjajo to kodo.
Kaj pa, če vaš sistem temelji predvsem na strežniški logiki? Na trgu ni univerzalne rešitve ali najboljših praks. Praviloma podjetja to težavo rešujejo tako, da ustvarijo lasten sistem samonapisanega testiranja. To je naš lastni samodejni sistem testiranja, ki smo ga ustvarili na našem projektu in o njem bom govoril v svojem poročilu.
Preizkušanje zvestobe
Najprej se pogovorimo o projektu, kjer smo uvedli avtomatiziran sistem testiranja. Naš projekt je sistem zvestobe Sportmaster (mimogrede, o njem smo že pisali v ).
Če je vaše podjetje dovolj veliko, bo vaš sistem zvestobe imel tri standardne lastnosti:
- Vaš sistem bo zelo obremenjen
- Vaš sistem bo vseboval zapletene računalniške procese
- Vaš sistem se bo aktivno izboljševal.
Pojdimo po vrsti ... Če upoštevamo vse blagovne znamke Sportmaster, imamo skupaj več kot 1000 trgovin v Rusiji, Ukrajini, na Kitajskem, v Kazahstanu in Belorusiji. Vsak dan se v teh trgovinah opravi okoli 300 nakupov. To pomeni, da vsako sekundo v naš sistem vstopijo 000-3 čeki. Seveda je naš sistem zvestobe zelo obremenjen. In ker se aktivno uporablja, moramo zagotoviti najvišje standarde njegove kakovosti, saj vsaka napaka v programski opremi pomeni velike denarne, ugledne in druge izgube.
Hkrati Sportmaster izvaja več kot sto različnih promocij. Promocije so različne: so akcije izdelkov, so tiste, ki so posvečene dnevu v tednu, so tiste, ki so vezane na določeno trgovino, so promocije za znesek računa, obstajajo za število blaga. Na splošno ni slabo. Stranke imajo bonuse in promocijske kode, ki se uporabljajo pri nakupih. Vse to vodi k dejstvu, da je izračun katerega koli naročila zelo netrivialna naloga.
Algoritem, ki izvaja obdelavo naročil, je resnično grozen in zapleten. In vse spremembe tega algoritma so precej tvegane. Zdelo se je, da lahko najbolj na videz nepomembne spremembe povzročijo precej nepredvidljive učinke. Toda ravno takšni zapleteni računalniški procesi, zlasti tisti, ki izvajajo kritično funkcionalnost, so najboljši kandidati za avtomatizacijo. Ročno preverjanje več deset podobnih primerov je zelo zamudno. In ker je vstopna točka v proces nespremenjena, potem ko jo enkrat opišete, lahko hitro ustvarite samodejne teste in ste prepričani, da bo funkcionalnost delovala.
Ker se naš sistem aktivno uporablja, bo podjetje od vas želelo nekaj novega, živeti v koraku s časom in biti usmerjeno k strankam. V našem sistemu zvestobe izdaje izidejo vsaka dva meseca. To pomeni, da moramo vsaka dva meseca opraviti popolno regresijo celotnega sistema. Hkrati seveda, tako kot v kateri koli sodobni IT, razvoj ne gre takoj od razvijalca do proizvodnje. Nastane v razvijalčevem vezju, nato gre zaporedno skozi preskusno napravo, sprostitev, sprejem in šele nato konča v proizvodnji. Vsaj na testnih in sprožilnih vezjih moramo izvesti popolno regresijo celotnega sistema.
Opisane lastnosti so standardne za skoraj vsak sistem zvestobe. Pogovorimo se o značilnostih našega projekta.
Tehnološko gledano 90 % logike našega sistema zvestobe temelji na strežniku in je implementirano na Oracle. V Delphiju je izpostavljen odjemalec, ki opravlja funkcijo skrbnika avtomatiziranega delovnega mesta. Obstajajo izpostavljene spletne storitve za zunanje aplikacije (na primer spletno mesto). Zato je zelo logično, da če uvedemo avtomatiziran sistem testiranja, to storimo na Oraclu.
Sistem zvestobe v Sportmasterju obstaja že več kot 7 let in so ga ustvarili posamezni razvijalci... Povprečno število razvijalcev na našem projektu v teh 7 letih je bilo 3-4 ljudi. Toda v zadnjem letu se je naša ekipa znatno povečala in zdaj na projektu dela 10 ljudi. Se pravi, da na projekt pridejo ljudje, ki ne poznajo tipičnih nalog, procesov in arhitekture. In obstaja povečano tveganje, da bomo zamudili napake.
Za projekt je značilna odsotnost namenskih preizkuševalcev kot kadrovskih enot. Testiranje seveda obstaja, vendar testiranje izvajajo analitiki, poleg svojih ostalih glavnih zadolžitev: komuniciranje s poslovnimi strankami, uporabniki, razvoj sistemskih zahtev itd. itd... Kljub dejstvu, da je testiranje opravljeno zelo kakovostno (to je še posebej primerno omeniti, saj lahko nekateri analitiki padejo v oči v tem poročilu), učinkovitosti specializacije in koncentracije na eno stvar ni bila preklicana. .
Glede na vse zgoraj navedeno se zdi za izboljšanje kakovosti dobavljenega izdelka in skrajšanje časa razvoja ideja o avtomatizaciji testiranja na projektu zelo logična. In na različnih stopnjah obstoja sistema zvestobe so se posamezni razvijalci trudili, da bi svojo kodo pokrili s testi enot. Na splošno je bil to dokaj nepovezan proces, pri čemer je vsak uporabljal svojo arhitekturo in metode. Končni rezultati so bili skupni testom enote: testi so bili razviti, uporabljeni nekaj časa, shranjeni v shrambi datotek z različicami, vendar so se na neki točki prenehali izvajati in bili pozabljeni. Najprej je bilo to posledica dejstva, da so bili testi bolj vezani na določenega izvajalca in ne na projekt.
utPLSQL priskoči na pomoč
Veste kaj o Stephenu Feuersteinu?
To je pameten človek, ki je dolg del svoje kariere posvetil delu z Oracle in PL/SQL in je napisal kar veliko del na to temo. Ena njegovih znanih knjig se imenuje: »Oracle PL/SQL. Za profesionalce." Stephen je bil tisti, ki je razvil rešitev utPLSQL ali, kot to pomeni, ogrodje za testiranje enot za Oracle PL/SQL. Rešitev utPLSQL je bila ustvarjena leta 2016, vendar se na njej še naprej aktivno dela in objavljajo nove različice. V času poročanja sega zadnja različica 24. marca 2019.
Kaj je to. To je ločen odprtokodni projekt. Tehta nekaj megabajtov, vključno s primeri in dokumentacijo. Fizično gre za ločeno shemo v bazi podatkov ORACLE z naborom paketov in tabel za organiziranje enotnega testiranja. Namestitev traja nekaj sekund. Posebnost utPLSQL je njegova enostavna uporaba.
Globalno gledano je utPLSQL mehanizem za izvajanje enotnih testov, pri čemer enotni test razumemo kot navadne Oraclove paketne procedure, katerih organizacija sledi določenim pravilom. Poleg zagona utPLSQL shranjuje dnevnik vseh vaših testnih zagonov in ima tudi notranji sistem poročanja.
Oglejmo si primer, kako izgleda testna koda enote, implementirana s to tehniko.
Na zaslonu je torej prikazana koda za tipično specifikacijo paketa s testi enote. Katere so obvezne zahteve? Paket mora imeti predpono "utp_". Vsi postopki s testi morajo imeti popolnoma enako predpono. Paket mora vsebovati dva standardna postopka: “utp_setup” in “utp_teardown”. Prvi postopek se pokliče s ponovnim zagonom vsakega testa enote, drugi - po zagonu.
“utp_setup” praviloma pripravi naš sistem za izvajanje testa enote, na primer ustvarjanje testnih podatkov. “utp_teardown” - nasprotno, vse se vrne na prvotne nastavitve in ponastavi rezultate zagona.
Tukaj je primer najenostavnejšega enotnega testa, ki preveri normalizacijo vnesene telefonske številke stranke na standardni obrazec za naš sistem zvestobe. Ni obveznih standardov za pisanje postopkov s testi enot. Praviloma se izvede klic metode testiranega sistema in rezultat, ki ga vrne ta metoda, se primerja z referenčnim. Pomembno je, da primerjava referenčnega rezultata in dobljenega poteka s standardnimi metodami utPLSQL.
Test enote ima lahko poljubno število preverjanj. Kot je razvidno iz primera, opravimo štiri zaporedne klice testirane metode za normalizacijo telefonske številke in po vsakem klicu ocenimo rezultat. Pri razvoju testa enote morate upoštevati, da obstajajo preverjanja, ki na noben način ne vplivajo na sistem, po nekaterih pa se morate vrniti v prvotno stanje sistema.
Na primer, v predstavljenem enotnem testu preprosto oblikujemo vneseno telefonsko številko, kar pa nikakor ne vpliva na sistem zvestobe.
In če pišemo teste enot z metodo ustvarjanja novega odjemalca, potem bo po vsakem testu v sistemu ustvarjen nov odjemalec, kar lahko vpliva na poznejši zagon testa.
Tako se izvajajo testi enot. Obstajata dve možni možnosti zagona: zagon vseh testov enote iz določenega paketa ali zagon določenega testa enote v določenem paketu.
Tako je videti primer sistema internega poročanja. Na podlagi rezultatov testa enote utPLSQL sestavi majhno poročilo. V njej vidimo rezultat za posamezno preverjanje in skupni rezultat testa enote.
6 pravil avtotestov
Preden smo začeli ustvarjati nov sistem avtomatiziranega testiranja sistema zvestobe, smo skupaj z vodstvom določili načela, ki naj bi jih upoštevala naša prihodnja avtomatizirana testiranja.
- Samodejni testi morajo biti učinkoviti in uporabni. Imamo čudovite razvijalce, ki jih je vsekakor treba omeniti, ker bodo nekateri verjetno videli to poročilo, in pišejo čudovito kodo. Toda tudi njihova čudovita koda ni popolna in je, je in bo vsebovala napake. Za iskanje teh napak so potrebni samodejni testi. Če temu ni tako, potem ali pišemo slabe avtoteste ali pa smo prišli v mrtvo območje, ki se načeloma ne razvija. V obeh primerih delamo nekaj narobe in naš pristop preprosto ni smiseln.
- Uporabiti je treba samodejne teste. Nesmiselno je porabiti veliko časa in truda za pisanje programskega izdelka, ga dati v repozitorij in pozabiti. Teste je treba izvajati, in to čim bolj redno.
- Samodejni testi bi morali delovati stabilno. Ne glede na uro dneva, stojalo za zagon in druge sistemske nastavitve bi morale preskusne vožnje voditi do enakega rezultata. Praviloma je to zagotovljeno z dejstvom, da samodejni testi delujejo s posebnimi testnimi podatki s fiksnimi sistemskimi nastavitvami.
- Samodejni testi bi morali delovati s hitrostjo, sprejemljivo za vaš projekt. Ta čas je določen za vsak sistem posebej. Nekateri ljudje si lahko privoščijo, da delajo ves dan, medtem ko se drugim zdi kritično, da to storijo v nekaj sekundah. Malo kasneje vam bom povedal, kakšne hitrostne standarde smo dosegli v našem projektu.
- Razvoj avtotesta mora biti prilagodljiv. Ni priporočljivo zavrniti testiranja katere koli funkcionalnosti samo zato, ker tega nismo storili prej ali iz kakšnega drugega razloga. utPLSQL ne nalaga nobenih omejitev pri razvoju, Oracle pa načeloma omogoča implementacijo različnih stvari. Večina težav ima rešitev, le vprašanje časa in truda je.
- Razporedljivost. Imamo več stojnic, kjer moramo izvajati teste. Na vsakem stojalu je mogoče kadar koli posodobiti izpis podatkov. Potrebno je izvesti projekt s samodejnimi testi tako, da lahko neboleče izvedete njegovo popolno ali delno namestitev.
In v drugi objavi čez nekaj dni vam povem, kaj smo počeli in kakšne rezultate smo dosegli.
Vir: www.habr.com