Përshëndetje, Habr!
Më quajnë Maksim Ponomarenko dhe jam zhvillues në Sportmaster. Kam 10 vjet përvojë në fushën e IT. Kam nisur karrierën time në testimin manual, pastaj kam kaluar në zhvillimin e bazave të të dhënave. Gjatë katër viteve të fundit, duke grumbulluar njohuritë e fituara nga testimi dhe zhvillimi, merrem me automatizimin e testimit në nivelin e DBMS.
Në ekipin e Sportmaster kam qenë pak më shumë se një vit dhe në një nga projektet e mëdha merrem me zhvillimin e testimit të automatizuar. Në prill, ne me djemtë nga Sportmaster Lab patëm një prezantim në konferencën në Krasnodar, titulli i prezantimit tim ishte "Testet e njësi në DBMS", dhe tani dua ta ndaj atë me ju. Do të ketë shumë tekst, kështu që vendosa ta ndaj prezantimin në dy postime. Në të parin, do të flasim për autotestet dhe testimin në përgjithësi, ndërsa në të dytin do të ndalem më në detaje në sistemin tonë të testimit të njësi dhe rezultatet e zbatimit të saj.
Fillimisht pak teori tĂ« mĂ«rzitshme. ĂfarĂ« Ă«shtĂ« testimi automatik? Ky Ă«shtĂ« njĂ« testim, i cili kryhet me mjete programore, dhe nĂ« IT-nĂ« moderne pĂ«rdoret gjithnjĂ« e mĂ« shumĂ« nĂ« zhvillimin e software-it. Kjo lidhet me faktin se kompanitĂ« rriten, rriten sistemet e tyre informatikĂ« dhe pĂ«r rrjedhojĂ« rritet edhe sasia e funksionaliteteve qĂ« duhet testuar. TĂ« kryesh testim manual po bĂ«het gjithnjĂ« e mĂ« e kushtueshme.
Kam punuar në një kompani të madhe, ku lëshimet bëhen çdo dy muaj. Gjatë kësaj periudhe, një muaj shpenzohej për që dhjetë tester të kontrollonin manualisht funksionalitetin. Falë implementimit të automatizimit nga një ekip i vogël zhvilluesish, arritëm të reduktonim kohën e testimit në 2 javë brenda një viti e gjysmë. Jo vetëm që rritëm shpejtësinë e testimit, por gjithashtu përmirësuam cilësinë e tij. Testet automatike ekzekutohen rregullisht dhe ato gjithmonë realizojnë të gjitha kontrollet e parashikuara, pra ne përjashtojmë faktorët njerëzorë.
Për IT-në moderne karakterizohet fakti se nga zhvilluesi mund të kërkohet jo vetëm të shkruaj kodin e produktit, por edhe të shkruaj teste njësie, të cilat kontrollojnë këtë kod.
Por what do you do if your system is primarily based on server logic? There is no universal solution or best practices on the market. Typically, companies address this issue by creating their own custom testing systems. This particular custom automated testing system was developed for our project, and I will discuss it in my presentation.
Testing Loyalty
First, letâs talk about the project where we deployed the automated testing system. Our project is the loyalty system of Sportmaster (by the way, we have already written about it in ).
If your company is large enough, your loyalty system will have three standard properties:
- Your system will be high-load
- Your system will involve complex computational processes
- Your system will be actively enhanced.
Letâs go in order⊠Together, when considering all Sportmaster brands, we have over 1000 stores in Russia, Ukraine, China, Kazakhstan, and Belarus. In these stores, around 300,000 purchases are made daily. This means that every second, 3-4 receipts enter our system. Naturally, our loyalty system is high-load. And since it is actively used, we must provide the highest quality standards, as any software error leads to significant financial, reputational, and other losses.
At the same time, more than a hundred different promotions are running at Sportmaster. The promotions vary: there are product-related ones, those related to specific days of the week, promotions tied to specific stores, those based on purchase amounts, and many more. In general, itâs quite a lot. Customers have bonuses and promo codes that are used during purchases. All this makes the calculation of any order a rather non-trivial task.
Algoritmi qĂ« realizon procesimin e porosive Ă«shtĂ« vĂ«rtet i frikshĂ«m dhe i ndĂ«rlikuar. Ădo ndryshim nĂ« kĂ«tĂ« algoritmĂ« Ă«shtĂ« njĂ« gjĂ« mjaft e rrezikshme. TĂ« duken ndryshime tĂ« jashtme tĂ« pakta, mund tĂ« çojnĂ« nĂ« efekte mjaft tĂ« paparashikueshme. Dhe pikĂ«risht kĂ«to procese tĂ« ndĂ«rlikuara tĂ« llogaritjes, sidomos ato qĂ« zbatojnĂ« funksionalitet kritik, janĂ« kandidatĂ« tĂ« shkĂ«lqyer pĂ«r automatizim. TĂ« kontrollosh me dorĂ« dhjetĂ«ra raste tĂ« ngjashme Ă«shtĂ« shumĂ« i lodhshĂ«m nĂ« kohĂ«. Dhe pĂ«rderisa pika e hyrjes nĂ« proces mbetet e pandryshuar, njĂ« herĂ« e pĂ«rshkruan atĂ«, mund tĂ« krijosh shpejt teste automatike dhe tĂ« ndihesh i sigurt pĂ«r funksionalitetin.
Duke pasur parasysh se sistemi jonë është përdorur aktivisht, biznesi do të dëshirojë diçka të re nga ju, të jetoni në hap me kohën dhe të jeni të orientuar ndaj klientit. Në sistemin tonë të besnikërisë, publikimet dalin çdo dy muaj. Kështu, çdo dy muaj na nevojitet të kryejmë një regres të plotë të gjithë sistemit. Natyrisht, si në çdo IT moderne, zhvillimi nuk kalon menjëherë nga zhvilluesi në prodhim. Ai lind në kontur të zhvilluesit, pastaj kalon me radhë përmes ekranit të testimit, publikimit, pranimit dhe më në fund arrin në prodhim. Të paktën në konturët e testimit dhe publikimit, ne duhet të kryejmë regres të plotë të gjithë sistemit.
Vetësitë e përshkruara janë standarde për pothuajse çdo sistem besnikërie. Le të flasim për veçoritë e projektit tonë.
Teknologjikisht, 90% e logjikës së sistemit tonë të besnikërisë është serverike dhe realizohet në Oracle. Ka një klient të vendosur në Delphi, i cili kryen funksionin e administratorit ARM. Ka shërbime uebi të vendosura për aplikacione të jashtme (p.sh. faqja e internetit). Prandaj, është mjaft logjike që nëse ne do të zhvillonim një sistem të testimit të automatizuar, do ta bënim këtë në Oracle.
Sistemi i besnikërisë në Sportmaster ekziston për më shumë se 7 vjet dhe është krijuar nga zhvillues të veçantë... Numri mesatar i zhvilluesve në projektin tonë gjatë këtyre 7 viteve ka qenë 3-4 persona. Por gjatë vitit të fundit, ekipi ynë është rritur ndjeshëm, dhe tani mbi projekt punojnë 10 persona. Pra, në projekt vijnë njerëz që nuk janë të njohur me detyrat standarde, proceset dhe arkitekturën. Dhe ekziston një rrezik i shtuar që do të kalojmë konkurrentë.
Projektin karakterizon mungesa e testuesve të dedikuar si njësi të caktuar. Testimi, pa dyshim, ekziston, por testimi merret nga analistët, përveç detyrave të tjera kryesore: komunikimi me tregtarët, përdoruesit, përpunimi i kërkesave për sistemin etj. Megjithatë, efikasiteti i specializimit dhe përqendrimit në një gjë të vetme nuk është anuluar.
Duke marrë parasysh të gjitha të dhënat e mësipërme, për të përmirësuar cilësinë e produktit të ofruar dhe për të shkurtuar kohët e zhvillimit, ideja e automatizimit të testimit në projekt duket mjaft logjike. Dhe në etapa të ndryshme të ekzistencës së sistemit të besnikërisë, zhvillues të veçantë kanë bërë përpjekje për të mbuluar kodin e tyre me testet e njësive. Ky ishte një proces i ndarë, ku secili përdorte arkitekturën dhe metodat e tij. Rezultatet përfundimtare ishin të zakonshme për testet e njësive: testet janë zhvilluar, përdoren për një kohë, grumbullohen në depozitën e versioneve të skedarëve, por në një moment stopojnë së ekzekutimi dhe harrohen. Kjo ndodhte kryesisht sepse testet ishin lidhur më shumë me ekzekutuesin specifik, sesa me projektin.
Për ndihmë vjen utPLSQL
Dini ndonjë gjë për Steven Feuerstein?
Ky është një njeri i zgjuar, që ka kaluar një pjesë të gjatë të karrierës së tij duke punuar me Oracle dhe me PL/SQL, dhe ka shkruar një numër të konsiderueshëm punimesh mbi këtë temë. Një nga librat e tij të njohur është titulluar: «Oracle PL/SQL. Për profesionistët». Pikërisht Steve-i është ai që ka zhvilluar zgjidhjen utPLSQL, ose siç e shpjegon, framework-un për testimin e njësive për Oracle PL/SQL. Zgjidhja utPLSQL u krijua në vitin 2016, por vazhdon të zhvillohet aktivisht dhe të lëshohen versione të reja. Në momentin e paraqitjes, versioni më i fundit daton më 24 mars 2019.
ĂfarĂ« Ă«shtĂ« kjo? Ky Ă«shtĂ« njĂ« projekt i veçantĂ« me burim tĂ« hapur. Peshon disa mega byte, pĂ«rfshirĂ« shembuj dhe dokumentacion. Fizikisht, pĂ«rfaqĂ«son njĂ« skemĂ« tĂ« veçantĂ« nĂ« bazĂ«n e tĂ« dhĂ«nave ORACLE me njĂ« grup paketa dhe tabelash pĂ«r organizimin e testimit tĂ« njĂ«sive. Instalimi merr disa sekonda. NjĂ« veçori e dallueshme e utPLSQL Ă«shtĂ« thjeshtĂ«sia e pĂ«rdorimit.
Globalisht, utPLSQL përfaqëson një mekanizëm për ekzekutimin e testeve të njësive, ku një test njësie kuptohet si procedurat standarde të paketave Oracle, organizimi i të cilave përputhet me disa rregulla. Përveç ekzekutimit, utPLSQL ruan një log të të gjitha ekzekutimeve të testeve tuaja, si dhe ka një sistem të brendshëm raportimi.
Le të shohim një shembull se si duket kodi i një testi njësie, i realizuar sipas kësaj metodike.
Pra, në ekran paraqitet kodi standard i specifikimit të paketës me testet njësive. Cilat janë kërkesat e detyrueshme? Paketa duhet të ketë një prefiks «utp_». Pikerisht i njëjti prefiks duhet të kenë të gjitha procedurat me teste. Në paketë duhet patjetër të jenë dy procedura standarde: «utp_setup» dhe «utp_teardown». Procedura e parë thirret përpara çdo testi njësie, ndërsa e dyta pas ekzekutimit.
«utp_setup», nĂ« pĂ«rgjithĂ«si, pĂ«rgatit sistemin tonĂ« pĂ«r ekzekutimin e testit njĂ«sie, pĂ«r shembull, krijon tĂ« dhĂ«na testimi. «utp_teardown» â pĂ«rkundrazi, kthen gjithçka nĂ« parametrat fillestarĂ« dhe shfuqizon rezultatet e ekzekutimit.
KĂ«tu Ă«shtĂ« njĂ« shembull i testit mĂ« tĂ« thjeshtĂ« unit, i cili kontrollon normalizimin e numrit tĂ« telefonit tĂ« klientit nĂ« formĂ«n standarde pĂ«r sistemin tonĂ« tĂ« besnikĂ«risĂ«. Nuk ka ndonjĂ« standard tĂ« detyrueshĂ«m pĂ«r si duhet tĂ« shkruhen procedurat me teste unit. Rregullisht, bĂ«het thirrja e ndonjĂ« metode tĂ« sistemit qĂ« po testohet, dhe rezultati, i kthyer nga kjo metodĂ«, krahasonhet me standardin. ĂshtĂ« e rĂ«ndĂ«sishme qĂ« krahasimi i rezultatit standard dhe atij tĂ« marrĂ« tĂ« ndodhĂ« pĂ«rmes metodave standarde utPLSQL.
Në testin unit mund të ketë çdo numër kontrollesh. Siç duket nga shembulli, ne bëjmë katër thirrje radhazi të metodës që po testohet për normalizimin e numrit të telefonit dhe pas çdo thirrjeje vlerësojmë rezultatin. Gjatë zhvillimit të testit unit duhet të merret parasysh se ekzistojnë kontrolle që nuk ndikojnë aspak në sistem, ndërsa disa kërkojnë kthimin në gjendjen fillestare të sistemit.
Për shembull, në testin unit të paraqitur, ne thjesht formatizojmë numrin e telefonit të hyrjes, që nuk ndikon aspak në sistemin e besnikërisë.
Por nëse ne shkruajmë testet unit për metodën e krijimit të klientit të ri, pas çdo kontrolli një klient i ri do të krijohet në sistem, e cila mund të ndikojë në ekzekutimin e mëvonshëm të testit.
Kështu ekzekutohen testet unit. Pranohet dy variante ekzekutimi: ekzekutimi i të gjitha testeve unit nga një paketë e caktuar ose ekzekutimi i një testi unit të caktuar në një paketë të caktuar.
Kështu duket një shembull i sistemit të brendshëm të raportim. Nga rezultatet e testit unit, utPLSQL ndërtan një raport të vogël. Në të shohim rezultatin për çdo kontroll të caktuar dhe rezultatin e përgjithshëm të ekzekutimit të testit unit.
6 rregulla për testet automatikë
Para se të fillojmë krijimin e një sistemi të ri të testimeve automatike për sistemin e besnikërisë, së bashku me menaxhimin ne përcaktuam parimet, të cilave testet tona të ardhshme automatike duhet t'u përmbahen.
- Testet automatike duhet të jenë efektive dhe të sjellin dobi. Ne kemi zhvillues të shkëlqyer, të cilët patjetër duhet të përmenden, sepse ndonjë prej tyre do ta shohë këtë raport dhe ata shkruajnë një kod të shkëlqyer. Por edhe kodi i tyre i shkëlqyer nuk është perfekt dhe ka përmbajtur, përmban dhe do të përmbajë gabime. Testet automatike duhet t'i gjejnë këto gabime. Nëse kjo nuk ndodh, atëherë ose ne po shkruajmë teste automatikë të dobëta, ose kemi arritur në një zonë të vdekur, e cila në thelb nuk po zhvillohet. Në të dy rastet, ne po bëjmë diçka të gabuar dhe qasja jonë është thjesht pa kuptim.
- Testet automatike duhet tĂ« pĂ«rdoren. ĂshtĂ« e pafrytshme tĂ« shpenzosh shumĂ« kohĂ« dhe energji nĂ« zhvillimin e njĂ« produkti tĂ« softuerit, ta vendosĂ«sh atĂ« nĂ« njĂ« repo dhe ta harrosh. Testet duhet tĂ« ekzekutohen dhe sa mĂ« rregullisht tĂ« jetĂ« e mundur.
- Testet automatike duhet të funksionojnë në mënyrë stabile. Pavarësisht nga koha e ditës, ambienti i ekzekutimit dhe cilatdo konfigurime të tjera të sistemit, ekzekutimet e testeve duhet të japin të njëjtin rezultat. Zakonisht, kjo sigurohet nga fakti që testet automatike punojnë me të dhëna testuese të veçanta me cilësime të vendosura të sistemit.
- Testet automatike duhet të punojnë me një shpejtësi të pranueshme për projektin tuaj. Ky kohë përcaktohet individualisht për secilin sistem. Disa mund të lejojnë të punojnë gjatë gjithë ditës, ndersa për disa është kritike të përfundojnë brenda disa sekondash. Cilat kanë qenë normat e shpejtësisë që 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ë heqim dorë nga kontrollimi i ndonjë funksionaliteti thjesht sepse ne nuk e kemi bërë kështu më parë ose për ndonjë bindje tjetër. utPLSQL nuk vendos asnjë kufizim për zhvillimin, dhe Oracle në thelb lejon realizimin e gjërave të ndryshme. Shumica e detyrave ka një zgjidhje, pyetja është vetëm për kohën dhe përpjekjet e shpenzuara.
- Implementimi. Ne kemi disa ambientet ku nevojitet ekzekutimi i testeve. Në secilin nga këto ambiente mund të përditësohet një dump me të dhëna në çdo moment. Duhet të drejtohet projekti me teste automatike në një mënyrë që të ketë mundësi për ta instaluar plotësisht ose pjesërisht pa dhimbje.
Dhe në postimin e dytë në disa ditë do t'ju tregoj se çfarë kemi bërë dhe cilat rezultate kemi arritur.
Burimi: habr.com
