Testet e njësisë në një DBMS - si e bëjmë atë në Sportmaster, pjesa e dytë

Pjesa e pare - këtu.

Imagjinoni situatën. Ju jeni përballur me detyrën e zhvillimit të funksionalitetit të ri. Keni zhvillime nga paraardhësit tuaj. Nëse supozojmë se nuk keni detyrime morale, çfarë do të bënit?

Më shpesh sesa jo, të gjitha zhvillimet e vjetra harrohen dhe gjithçka fillon nga e para. Askujt nuk i pëlqen të gërmojë në kodin e dikujt tjetër, por nëse keni kohë, pse të mos filloni të krijoni sistemin tuaj? Kjo është një qasje tipike, dhe është kryesisht e saktë. Por në projektin tonë e bëmë gabim. Ne e bazuam sistemin e ardhshëm të testimit automatik në zhvillimet në testet e njësive në utPLSQL nga paraardhësit tanë, dhe më pas shkuam në punë në disa drejtime paralele.

1. Rivendosja e testeve të njësisë së vjetër. Rimëkëmbja nënkupton përshtatjen e testeve me gjendjen ekzistuese të sistemit të besnikërisë dhe përshtatjen e testeve me standardet utPLSQL.
2. Zgjidhja e një problemi me të kuptuarit se çfarë saktësisht, cilat metoda dhe procese mbulohen me autoteste. Ju ose duhet ta mbani këtë informacion në kokën tuaj, ose të nxirrni përfundime bazuar drejtpërdrejt në kodin e autotestit. Prandaj, vendosëm të krijojmë një katalog. Ne caktuam një kod unik mnemonik për çdo autotest, krijuam një përshkrim dhe regjistruam cilësime (për shembull, në cilat kushte duhet të lansohet, ose çfarë duhet të ndodhë nëse nisja e testit dështon). Në thelb, ne kemi mbushur meta të dhënat rreth autotesteve dhe i vendosëm ato meta të dhëna në tabelat standarde të skemave utPLSQL.
3. Përcaktimi i strategjisë së zgjerimit, d.m.th. përzgjedhja e funksionalitetit që i nënshtrohet verifikimit me anë të testeve të automatizuara. Ne vendosëm t'i kushtojmë vëmendje tre gjërave: përmirësimeve të reja të sistemit, incidenteve të prodhimit dhe proceseve kryesore të sistemit. Kështu, ne po zhvillojmë paralelisht me lëshimin, duke siguruar cilësi më të lartë të tij, duke zgjeruar njëkohësisht hapësirën e regresionit dhe duke siguruar besueshmërinë e sistemit në vendet kritike. Gryka e parë e tillë e ngushtë ishte procesi i shpërndarjes së zbritjeve dhe bonuseve në një çek.
4. Natyrisht, ne filluam zhvillimin e autotesteve të reja. Një nga detyrat e para të lëshimit ishte vlerësimi i performancës së mostrave të paracaktuara të sistemit të besnikërisë. Projekti ynë ka një bllok pyetjesh SQL të fiksuara në mënyrë rigoroze që zgjedhin klientët në bazë të kushteve. Për shembull, merrni një listë të të gjithë klientëve, blerja e fundit e të cilëve ishte në një qytet të caktuar, ose një listë klientësh, shuma mesatare e blerjes së të cilëve është mbi një vlerë të caktuar. Duke pasur teste automatike të shkruara, ne kontrolluam mostrat e paracaktuara, regjistruam parametrat e performancës standarde, dhe gjithashtu patëm testimin e ngarkesës.
5. Puna me autoteste duhet të jetë e përshtatshme. Dy veprimet më të zakonshme janë ekzekutimi i autotesteve dhe krijimi i të dhënave të testimit. Kështu u shfaqën dy module ndihmëse në sistemin tonë: një modul nisjeje dhe një modul i gjenerimit të të dhënave.

   Lëshuesi përfaqësohet si një procedurë universale me një parametër të futjes së tekstit. Si parametër, mund të kaloni kodin kujtimor të autotestit, emrin e paketës, emrin e testit, cilësimin e autotestit ose një fjalë kyçe të rezervuar. Procedura zgjedh dhe ekzekuton të gjitha autotestet që plotësojnë kushtet.

   Moduli i gjenerimit të të dhënave paraqitet në formën e një pakete në të cilën për secilin objekt të sistemit nën testim (një tabelë në bazën e të dhënave), është krijuar një procedurë e veçantë që fut të dhëna atje. Në këtë procedurë, vlerat e paracaktuara plotësohen sa më shumë që të jetë e mundur, gjë që siguron krijimin e objekteve fjalë për fjalë me një klikim të gishtit. Dhe për lehtësinë e përdorimit, u krijuan shabllone për të dhënat e krijuara. Për shembull, krijoni një klient të një moshe të caktuar me një telefon testues dhe një blerje të përfunduar.

6. Autotestet duhet të fillojnë dhe të ekzekutohen në një kohë që është e pranueshme për sistemin tuaj. Prandaj, u organizua një nisje e përditshme e natës, në bazë të rezultateve të së cilës gjenerohet një raport mbi rezultatet dhe i dërgohet të gjithë ekipit të zhvillimit përmes postës së korporatës. Pas rivendosjes së autotesteve të vjetra dhe krijimit të atyre të reja, koha totale e funksionimit ishte 30 minuta. Kjo performancë u shkonte për shtat të gjithëve, pasi nisja u bë jashtë orarit të punës.

   Por ne duhej të punonim për të optimizuar shpejtësinë e punës. Sistemi i besnikërisë në prodhim përditësohet gjatë natës. Si pjesë e një prej publikimeve, na duhej të bënim ndryshime urgjente gjatë natës. Pritja për gjysmë ore për rezultatet e autotesteve në tre të mëngjesit nuk e bëri të lumtur personin përgjegjës për lirimin (përshëndetje të zjarrta për Alexey Vasyukov!), dhe të nesërmen në mëngjes u thanë shumë fjalë të mira ndaj sistemit tonë. Por si rezultat, u vendos një standard pune 5-minutëshe.

   Për të përshpejtuar performancën, ne përdorëm dy metoda: autotestet filluan të funksionojnë në tre fije paralele, për fat të mirë kjo është shumë e përshtatshme për shkak të arkitekturës së sistemit tonë të besnikërisë. Dhe ne braktisëm qasjen ku autotesti nuk krijon të dhëna testimi për vete, por përpiqet të gjejë diçka të përshtatshme në sistem. Pas bërjes së ndryshimeve, koha totale e funksionimit u reduktua në 3-4 minuta.

7. Një projekt me teste automatike duhet të jetë në gjendje të vendoset në tribuna të ndryshme. Në fillim të udhëtimit tonë, pati përpjekje për të shkruar skedarët tanë të grupit, por u bë e qartë se një instalim i automatizuar i shkruar vetë ishte tmerr i plotë dhe ne u kthyem drejt zgjidhjeve industriale. Për shkak të faktit se projekti përmban shumë kode të drejtpërdrejta (para së gjithash, ne ruajmë kodin e autotestit) dhe shumë pak të dhëna (të dhënat kryesore janë meta të dhënat rreth autotesteve), zbatimi në projektin Liquibase doli të ishte shumë i thjeshtë.

   Është një bibliotekë me burim të hapur, e pavarur nga baza e të dhënave për gjurmimin, menaxhimin dhe zbatimin e ndryshimeve të skemës së bazës së të dhënave. Menaxhohet nëpërmjet linjës së komandës ose kornizave të tilla si Apache Maven. Parimi i funksionimit të Liquibase është mjaft i thjeshtë. Ne kemi një projekt të organizuar në një mënyrë të caktuar, i cili përbëhet nga ndryshime ose skripta që duhet të shpërndahen në serverin e synuar dhe skedarë kontrolli që përcaktojnë se në çfarë sekuence dhe me çfarë parametrash duhet të instalohen këto ndryshime.

   Në nivelin DBMS, krijohet një tabelë e veçantë në të cilën Liquibase ruan regjistrin e rrotullimit. Çdo ndryshim ka një hash të llogaritur, i cili krahasohet çdo herë midis projektit dhe gjendjes në bazën e të dhënave. Falë Liquibase, ne mund të bëjmë lehtësisht ndryshime në sistemin tonë në çdo qark. Autotestet janë nisur tani në qarqet e testimit dhe lëshimit, si dhe në kontejnerë (qarqet personale të zhvilluesve).

Pra, le të flasim për rezultatet e përdorimit të sistemit tonë të testimit të njësisë.

1. Sigurisht, para së gjithash, ne jemi të bindur se kemi filluar të zhvillojmë softuer më të mirë. Autotestet nisen çdo ditë dhe gjenden dhjetëra gabime në çdo version. Për më tepër, disa nga këto gabime lidhen vetëm në mënyrë indirekte me funksionalitetin që ne vërtet donim të ndryshonim. Ka dyshime serioze se këto gabime janë gjetur nga testimi manual.
2. Ekipi tani ka besim se funksionaliteti specifik po funksionon si duhet... Para së gjithash, kjo ka të bëjë me proceset tona kritike. Për shembull, gjatë gjashtë muajve të fundit nuk kemi pasur asnjë problem me shpërndarjen e zbritjeve dhe shpërblimeve në fatura, pavarësisht ndryshimeve të lëshimit, megjithëse në periudhat e mëparshme gabimet kanë ndodhur me një farë frekuencë
3. Ne arritëm të reduktojmë numrin e përsëritjeve të testimit. Për shkak të faktit se autotestet janë shkruar për funksionalitete të reja, analistët dhe testuesit me kohë të pjesshme marrin kod me cilësi më të lartë, sepse tashmë është kontrolluar.
4. Disa nga zhvillimet në testimin e automatizuar përdoren nga zhvilluesit. Për shembull, të dhënat e testimit në kontejnerë krijohen duke përdorur modulin e gjenerimit të objekteve.
5. Është e rëndësishme që ne kemi zhvilluar një "pranim" të sistemit të testimit të automatizuar nga ana e zhvilluesve. Ekziston një kuptim se kjo është e rëndësishme dhe e dobishme. Por nga përvoja ime mund të them se kjo është larg nga rasti. Autotestet duhet të shkruhen, ato duhet të mbështeten dhe zhvillohen, rezultatet duhet të analizohen dhe shpesh këto kosto kohore thjesht nuk ia vlejnë. Është shumë më e lehtë të shkosh në prodhim dhe të përballesh me problemet atje. Këtu, zhvilluesit rreshtohen dhe na kërkojnë të mbulojmë funksionalitetin e tyre me autoteste.

Ç'pritet më tej

Le të flasim për planet e zhvillimit për projektin e testimit të automatizuar.

Sigurisht, për sa kohë që sistemi i besnikërisë së Sportmaster është i gjallë dhe vazhdon të zhvillohet, është gjithashtu e mundur të zhvillohen autoteste pothuajse pafund. Prandaj, drejtimi kryesor i zhvillimit është zgjerimi i zonës së mbulimit.

Me rritjen e numrit të autotesteve, koha totale e funksionimit të tyre do të rritet në mënyrë të qëndrueshme dhe ne do të duhet të kthehemi përsëri te çështja e performancës. Me shumë mundësi, zgjidhja do të jetë rritja e numrit të fijeve paralele.

Por këto janë mënyra të dukshme zhvillimi. Nëse flasim për diçka më jo të parëndësishme, theksojmë sa vijon:

1. Aktualisht, menaxhimi i autotestit kryhet në nivel DBMS, d.m.th. Për punë të suksesshme kërkohet njohja e PL/SQL. Nëse është e nevojshme, menaxhimi i sistemit (për shembull, nisja ose krijimi i meta të dhënave), mund të krijoni një lloj paneli administratori duke përdorur Jenkins ose diçka të ngjashme.
2. Të gjithë i duan treguesit sasiorë dhe cilësorë. Për testimin e automatizuar, një tregues i tillë universal është mbulimi i kodit ose metrika e mbulimit të kodit. Duke përdorur këtë tregues, ne mund të përcaktojmë se sa përqind e kodit të sistemit tonë në testim mbulohet nga autotestet. Duke filluar nga versioni 12.2, Oracle ofron mundësinë për të llogaritur këtë metrikë dhe ofron përdorimin e paketës standarde DBMS_PLSQL_CODE_COVERAGE.

   Sistemi ynë i autotestit është pak më shumë se një vit i vjetër dhe ndoshta tani është koha për të vlerësuar mbulimin tonë. Në projektin tim të fundit (jo një projekt Sportmaster) kjo është ajo që ndodhi. Një vit pasi punoi për autotestet, menaxhmenti vendosi detyrën për të vlerësuar se çfarë përqindje të kodit mbulojmë. Me një mbulim prej më shumë se 1%, menaxhmenti do të ishte i lumtur. Ne, zhvilluesit, prisnim një rezultat prej rreth 10%. Ne instaluam mbulimin e kodit, e matëm atë dhe morëm 20%. Për të festuar, shkuam për të marrë çmimin, por si shkuam për ta marrë atë dhe ku shkuam më vonë është një histori krejtësisht tjetër.

3. Autotestet mund të kontrollojnë shërbimet e ekspozuara të internetit. Oracle na lejon ta bëjmë këtë mjaft mirë dhe nuk do të hasim më një sërë problemesh.
4. Dhe, sigurisht, sistemi ynë i automatizuar i testimit mund të aplikohet në një projekt tjetër. Zgjidhja që kemi marrë është universale dhe kërkon vetëm përdorimin e Oracle. Kam dëgjuar se projekte të tjera Sportmaster janë të interesuar për testimin automatik dhe ndoshta do të shkojmë tek ata.

Gjetjet

Le të përmbledhim. Në projektin e sistemit të besnikërisë në Sportmaster, ne arritëm të implementojmë një sistem testimi të automatizuar. Ai bazohet në zgjidhjen utPLSQL nga Stephen Feuerstein. Rreth utPLSQL ka kod autotest dhe module ndihmëse të vetë-shkruara: moduli i nisjes, moduli i gjenerimit të të dhënave dhe të tjera. Autotestet nisen çdo ditë dhe, më e rëndësishmja, ato funksionojnë dhe janë të dobishme. Ne jemi të sigurt se kemi filluar të lëshojmë softuer me cilësi më të lartë. Në të njëjtën kohë, zgjidhja që rezulton është universale dhe mund të aplikohet lirisht në çdo projekt ku është e nevojshme të organizohet testimi i automatizuar në Oracle DBMS.

PS Ky artikull nuk është shumë specifik: ka shumë tekst dhe praktikisht nuk ka shembuj teknikë. Nëse tema është përgjithësisht interesante, atëherë ne jemi gati ta vazhdojmë dhe të kthehemi me një vazhdim, ku do t'ju tregojmë se çfarë ka ndryshuar gjatë gjashtë muajve të fundit dhe do të ofrojmë shembuj kodesh.

Shkruani komente nëse ka pika që duhet të theksohen në të ardhmen, ose pyetje që kërkojnë zbulim.

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, te lutem

A do të shkruajmë më tej për këtë?

• Po sigurisht

• Jo faleminderit

12 përdorues votuan. 4 përdorues abstenuan.

Burimi: www.habr.com