Përshëndetje, Habr!
Më quaj Maxim Ponomarenko dhe unë jam zhvillues në Sportmaster. Kam një përvojë 10-vjeçare në fushën e IT. E fillova karrierën në testimin manual, pastaj kalova në zhvillimin e bazave të të dhënave. Gjatë katër viteve të fundit, duke grumbulluar njohuritë e fituara në testim dhe zhvillim, merrem me automatizimin e testimit në nivelin e DB.
Kam qenë në ekipin e Sportmaster për pak më shumë se një vit dhe në një nga projektet e mëdha po zhvilloj testimin automatizues. Në prill, unë dhe djemtë nga Sportmaster Lab paraqitëm në konferencën në Krasnodar, ligjërata ime kishte titullin «Testet e Njësive në DB», dhe tani dua ta ndaj atë me ju. Do të ketë shumë tekst, prandaj vendosa ta ndaj ligjëratën në dy posta. Në të parin do të flasim për testet automatike dhe testimin në përgjithësi, ndërsa në të dytin do të ndalem më gjatë mbi sistemin tonë të testimit të njësive dhe rezultatet e aplikimit të saj.
Fillimisht pak teori tĂ« mĂ«rzitshme. ĂfarĂ« Ă«shtĂ« testimi automatizuar? Ky Ă«shtĂ« njĂ« testim qĂ« realizohet me mjete software dhe nĂ« IT-nĂ« bashkĂ«kohore pĂ«rdoret gjithnjĂ« e mĂ« shumĂ« gjatĂ« zhvillimit tĂ« softuerit. Kjo vjen si rezultat i rritjes sĂ« kompanive, rritjes sĂ« sistemeve tĂ« tyre informative dhe pĂ«r pasojĂ«, rritjes sĂ« funksionaliteteve qĂ« duhet tĂ« testohen. TĂ« realizosh testim manual po bĂ«het gjithnjĂ« e mĂ« i kushtueshĂ«m.
Kam punuar në një kompani të madhe, ku publikuar një version të ri ndodhte çdo dy muaj. Kështu që një muaj shpenzohej për një grup testuesish që kontrollonin funksionalitetet me duar. Falë implementimit të automatizimit nga një ekip i vogël zhvilluesish, arritëm të zvogëlojmë kohën e testimit në 2 javë për një periudhë 1.5 vjeçare. Jo vetëm që rritëm shbrenditjen e testimit, por gjithashtu e përmirësuam cilësinë e tij. Testet automatike ekzekutohen rregullisht dhe ato gjithmonë realizojnë të gjithë serinë e kontrollimeve që janë vendosur, domethënë, ne eliminojmë faktorët njerëzor.
Për IT-në e sotëm është karakteristikë që nga zhvilluesi kërkohet jo vetëm të shkruaj kodin e produktit, por gjithashtu të shkruaj teste unitare që verifikojnë këtë kod.
Por çfarë të bëni nëse sistemi juaj bazohet kryesisht në logjikën server-side? Nuk ka një zgjidhje universale dhe praktikat më të mira në treg. Zakonisht, kompanitë e zgjidhin këtë problem përmes krijimit të një sistemi të vetë-shkruar testimi. Një sistem të tillë të automatizuar të testimit është krijuar në projektin tonë dhe për të do të flas në prezantimin tim.
Testojmë besnikërinë
Le të fillojmë me projektin ku kemi vendosur sistemin e automatizuar të testimit. Projekti ynë është sistemi i besnikërisë së Sportmaster (për më shumë, kemi shkruar tashmë për të në ).
Nëse kompania juaj është mjaft e madhe, sistemi juaj i besnikërisë do të ketë tri karakteristika standarde:
- Sistemi juaj do të jetë me ngarkesë të lartë
- Sistemi juaj do të përmbajë procese të komplikuara llogaritëse
- Sistemi juaj do të përmirësohet vazhdimisht.
Le të shohim me radhë... Në total, nëse shqyrtojmë të gjitha markat e Sportmaster, në territorin e Rusisë, Ukrainës, Kinës, Kazakistanit dhe Bjellorusisë, kemi më shumë se 1000 dyqane. Në këto dyqane kryhen rreth 300,000 blerje çdo ditë. Kjo do të thotë se çdo sekond në sistemin tonë hyjnë 3-4 çekë. Sigurisht, sistemi ynë i besnikërisë është shumë i ngarkuar. Dhe pasi që përdoret aktivisht, ne duhet të ofrojmë standardet më të larta të cilësisë së tij, sepse çdo gabim në softuer do të sjellë humbje të mëdha financiare, reputacioni dhe humbje të tjera.
Njëkohësisht, në Sportmaster punojnë më shumë se njëqind lloje të ndryshme të promocioneve. Promocionet janë shumë të ndryshme: ka nga ato të produkteve, ka që lidhen me ditën e javës, ka të lidhura me një dyqan të caktuar, ka promocione që varen nga shuma e çekut, ka për numrin e produkteve. Në thelb, jo pak. Klientët kanë bonuset e tyre, kanë kodet promocionale që përdoren gjatë blerjeve. Të gjitha këto e bëjnë kalkulimin e çdo porosie një detyrë mjaft të komplikuar.
Algoritmi që zbatohet për përpunimin e porosisë është vërtet i tmerrshëm dhe i komplikuar. Një ndryshim në këtë algoritëm është një gjë mjaft e rrezikshme. Madje, ndryshime që duken mjaft të vogla mund të sjellin efekte mjaft të paparashikueshme. Proceset e tilla shumë të komplikuara, sidomos ato që realizojnë funksionalitete kritike, janë kandidatët më të mirë për automatizim. Të kontrollosh me dorë dhjetëra raste të ngjashme kërkon shumë kohë. Dhe, duke qenë se pika e hyrjes në proces mbetet e pandryshuar, një herë eartë e përshkruar, mund të krijosh shpejt testet automatike dhe të jesh i sigurt për funksionimin e funksionalitetit.
Pasi sistemi ynë përdoret aktivisht, bizneset do të kërkojnë nga ju diçka të re, të qëndrojnë në hap me kohën dhe të jenë orientuar drejt klientit. Në sistemin tonë të besnikërisë, lëshimet dalin çdo dy muaj. Kjo do të thotë se çdo dy muaj duhet të kryejmë një testim të plotë regres i gjithë sistemit. Natyrisht, si në çdo IT modern, zhvillimi nuk kalon menjëherë nga zhvilluesi në prodhim. Ai fillon në konturin e zhvilluesit, pastaj kalon gradualisht përmes mjedisit testues, atij të lëshimit, pranimit dhe vetëm pastaj arrin në prodhim. Të paktën në mjediset testuese dhe të lëshimit, duhet të kryejmë një testim të plotë regres i gjithë sistemit.
Aftësitë e përshkruara janë standarde për pothuajse çdo sistem besnikërie. Le të flasim për veçoritë e projektit tonë.
Logjika jonë e sistemit të besnikërisë është 90% teknologjike dhe është realizuar në Oracle. Ka një klient të implementuar në Delphi, i cili kryen funksionin e administratorit. Janë ekspozuar shërbime web për aplikacione të jashtme (për shembull, faqja e internetit). Prandaj, është e arsyeshme që po të zhvillojmë një sistem automatizimi të testimit, do ta bëjmë këtë në Oracle.
Sistema e besnikërisë në Sportmaster ekziston prej më shumë se 7 vjetësh dhe është krijuar nga zhvillues të vetëm... Numri mesatar i zhvilluesve në projektin tonë gjatë këtyre 7 viteve ka qenë 3-4 persona. Por në vitin e fundit ekipi ynë është rritur ndjeshëm dhe tani në projekt punojnë 10 persona. Domethënë, shumë njerëz po hyjnë në projekt që nuk janë të njohur me detyrat tipike, proceset, arkitekturën. Kështu, ka një rrezik të rritur që do të lëmë pas gabime.
Kyçi i projektit është se nuk ka testerë të dedikuar si njësi të përhershme. Testimi, pa dyshim, ekziston, por ai merret nga analistët, përveç detyrave të tjera të tyre kryesore, si komunikimi me porositësit e biznesit, përdoruesit, zhvillimi i kërkesave për sistemin etj. Megjithëse testimi kryhet me shumë cilësi (veçanërisht është e rëndësishme të përmendet, sepse ndonjë analist mund ta lexojë këtë raport), efektiviteti i specializimit dhe përqendrimit në një gjë nuk është hequr nga diskutimi.
Duke të gjitha këto, për të rritur cilësinë e produktit të lëshuar dhe për të reduktuar kohën e zhvillimit, ideja e automatizimit të testeve në projekt duket mjaft logjike. Në etapa të ndryshme të ekzistencës së sistemit të besnikërisë, programues të veçantë kanë bërë përpjekje për të mbuluar kodin e tyre me teste njësish. Ky ishte një proces mjaft i çarë, ku çdo individ përdorte arkitekturën dhe metodat e tij. Rezultatet përfundimtare të testeve njësish ishin të përbashkëta: testet zhvilloheshin, përdorej njëfarë kohe, mblidheshin në një depo versionesh të skedarëve, por në një moment të caktuar ndalonin së funksionuari dhe harroheshin. Kjo ndodhte kryesisht sepse testet ishin lidhur më tepër me ekzekutuesin konkret sesa me projektin.
utPLSQL vjen në ndihmë
Dini ndonjë gjë për Steven Feuerstein?
Ky është një njeri i mençur, i cili një pjesë të gjatë të karrierës së tij e ka kushtuar punës me Oracle dhe me PL/SQL, ka shkruar një numër të madh punimesh në këtë fushë. Një nga librat e tij të njohur quhet: «Oracle PL/SQL. Për profesionistët». Pikërisht Stephen i përket zhvillimi i zgjidhjes utPLSQL, ose, siç e dekriptivon, framework i testimit të njësive për Oracle PL/SQL. Zgjidhja utPLSQL u krijua në vitin 2016, por vazhdohet të punohet aktivisht mbi të dhe të lëshohen versione të reja. Në momentin e raportit, versione më e fundit është datuar 24 mars 2019.
ĂfarĂ« Ă«shtĂ« kjo? Ky Ă«shtĂ« njĂ« projekt i veçantĂ« open-source. Peshon disa megabajt duke pĂ«rfshirĂ« shembuj dhe dokumentacion. Fizikisht paraqet njĂ« skemĂ« tĂ« veçantĂ« nĂ« databazĂ«n ORACLE me njĂ« grup paketash dhe tabelash pĂ«r organizimin e testimit tĂ« njĂ«sive. Instalimi zgjat disa sekonda. Karakteristika e veçantĂ« e utPLSQL Ă«shtĂ« thjeshtĂ«sia e shfrytĂ«zimit.
Globalisht, utPLSQL paraqet një mekanizëm për ekzekutimin e testeve unit, ku testi unit përfshin procedurat standarde të paketave Oracle, organizimi i të cilave përputhet me disa rregulla. Përveç ekzekutimit, utPLSQL ruan një log të të gjithë ekzekutimeve të testeve tuaja, dhe po ashtu ka një sistem të brendshëm raportimi.
Le të shohim një shembull se si duket kodi i një testi unit i realizuar sipas kësaj metodologjie.
Pra, në ekran shfaqet kodi i një specifikimi tipik të paketës me teste unit. Cilat janë kërkesat e domosdoshme? Paketa duhet të ketë një prefiks "utp_". Të gjitha procedurat me teste duhet të kenë të njëjtin prefiks. Në paketë duhet të jenë të pranishme dy procedura standarde: "utp_setup" dhe "utp_teardown". Procedura e parë thirret para çdo testi unit, ndërsa e dyta pas ekzekutimit.
"utp_setup", zakonisht, përgatit sistemin tonë për ekzekutimin e testit unit, për shembull, krijon të dhëna testuese. "utp_teardown", nga ana tjetër, rikthen gjithçka në cilësimet e origjinës dhe anulon rezultatet e ekzekutimit.
Ja Ă«shtĂ« njĂ« shembull i testit mĂ« tĂ« thjeshtĂ« unit, i cili kontrollon normalizimin e numrit tĂ« telefonit tĂ« dhĂ«nĂ« nga klienti nĂ« formatin standard tĂ« sistemit tonĂ« tĂ« besnikĂ«risĂ«. Nuk ka standarde tĂ« detyrueshme, si tĂ« shkruhen procedurat me teste unit. Zakonisht, thirret njĂ« metodĂ« e sistemit qĂ« po testohet, dhe rezultati i kthyer nga kjo metodĂ« krahasohet me referencĂ«n. ĂshtĂ« e rĂ«ndĂ«sishme qĂ« krahasimi i rezultatit referencĂ« dhe atij tĂ« marrĂ« tĂ« bĂ«het pĂ«rmes metodave standarde tĂ« utPLSQL.
Në testin unit mund të ketë çdo numër verifikimesh. Siç shihet nga shembulli, ne kryejmë katër thirrje të ndërlidhura të metodës së testuar për normalizimin e numrit të telefonit dhe pas çdo thirrje vlerësojmë rezultatin. Kur zhvilloni një test unit, duhet të keni parasysh që ekzistojnë verifikime që nuk ndikojnë në sistem, dhe pas disa prej tyre duhet të kthehemi në gjendjen fillestare të sistemit.
Për shembull, në testin e paraqitur, ne thjesht formatizojmë numrin e hyrjes së telefonit, që nuk ndikon fare në sistemin e besnikërisë.
Nëse shkruajmë teste unike për metodën e krijimit të një klienti të ri, pas çdo kontrolli në sistem do të krijohet një klient i ri, që mund të ndikojë në ekzekutimin e mëpasshëm të testit.
Kështu fillohen testet unike. Dy varianta të ekzekutimit janë të pranueshme: ekzekutimi i të gjithë testeve unike nga një paketë specifike ose ekzekutimi i një testi unik specifik në një paketë të veçantë.
Këtu shihni një shembull të sistemit të brendshëm të raportimit. Bazuar në rezultatet e punës së testit unik, utPLSQL ndan një raport të vogël. Në të shohim rezultatet për çdo kontroll të veçantë dhe rezultatin e përgjithshëm të ekzekutimit të testit unik.
6 rregulla për testet automatike
Para se të fillonim krijimin e një sistemi të ri të automatizuar të testimit për sistemin e besnikërisë, së bashku me drejtuesit identifikuam parimet, të cilave testet tona të ardhshme automatike duhet t'u përmbahen.
- Testet automatike duhet të jenë efikase dhe të sjellin dobi. Ne kemi zhvillues të shkëlqyer, të cilët duhen përmendur, sepse ndonjë nga ta ndoshta do ta lexojë këtë dokument, dhe ata shkruajnë kod të mrekullueshëm. Por edhe kodi i tyre i shkëlqyer nuk është perfekt dhe përmbante, përmban dhe do të përmbajë gabime. Testet automatike duhet të gjejnë këto gabime. Ndryshe, ne ose po shkruajmë teste automatike të këqija, ose jemi në një zonë të vdekur që në fakt nuk zhvillohet. Në të dy rastet, ne po bëjmë diçka të gabuar dhe qasja jonë është e pafrytshme.
- Testet automatike duhet tĂ« pĂ«rdoren. ĂshtĂ« pa kuptim tĂ« kalosh njĂ« mori kohĂ« dhe energjie nĂ« shkrimin e njĂ« produkti softuerik, ta vendosĂ«sh nĂ« njĂ« depo dhe ta harrosh. Testet duhet tĂ« ekzekutohen dhe sa mĂ« shpesh tĂ« jetĂ« e mundur.
- Testet automatike duhet të punojnë me stabilitet. Pavarësisht nga ora e ditës, ambienti i ekzekutimit dhe cilësitë e tjera të sistemit, ekzekutimet e testeve duhet të çojnë në të njëjtin rezultat. Si rregull, kjo sigurohet nga fakti që testet automatike punojnë me të dhëna speciale testimi me cilësime të fiksuara të sistemit.
- Testet automatik duhet të funksionojnë me një shpejtësi të pranueshme për projektin tuaj. Ky kohë përcaktohet individualisht për çdo sistem. Disa mund të lejojnë punë gjatë gjithë ditës, ndërsa të tjerët janë të detyruar të përfundojnë brenda sekondash. Cilat standarde shpejtësie kemi arritur në projektin tonë, do t'ju tregoj pak më vonë.
- Zhvillimi i testeve automatike duhet të jetë fleksibël. Nuk është e dëshirueshme të heqësh dorë nga kontrolli i ndonjë funksionaliteti thjesht sepse nuk e kemi bërë më parë ose për ndonjë bindje tjetër. utPLSQL nuk ngre asnjë kufizim në zhvillim, ndërsa Oracle në përgjithësi lejon realizimin e gjërave të ndryshme. Shumica e problemeve kanë zgjidhje, pyetja është vetëm për kohën dhe përpjekjet e shpenzuara.
- Deployability. Ne kemi disa blloqe, ku nevojitet ekzekutimi i testeve. Në çdo moment, dumpi i të dhënave mund të përditësohet në çdo bllok. Duhet të menaxhojmë projektin me teste automatike në një mënyrë që të kemi mundësi të kryejmë instalimin e tij të plotë ose të pjesshëm pa probleme.
Dhe në postimin e dytë pas pak ditësh do t'ju tregoj çfarë kemi bërë dhe cilat rezultate kemi arritur.
Burimi: habr.com
