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

Hej Habr!

Emri im është Maxim Ponomarenko dhe unë jam një zhvillues në Sportmaster. Kam 10 vjet eksperience ne fushen e IT. Ai filloi karrierën e tij në testimin manual, më pas kaloi në zhvillimin e bazës së të dhënave. Për 4 vitet e fundit, duke grumbulluar njohuritë e marra në testim dhe zhvillim, kam automatizuar testimin në nivel DBMS.

Unë kam qenë në ekipin e Sportmaster për pak më shumë se një vit dhe jam duke zhvilluar testimin e automatizuar në një nga projektet kryesore. Në prill, djemtë nga Sportmaster Lab dhe unë folëm në një konferencë në Krasnodar, raporti im quhej "Testet e njësisë në një DBMS" dhe tani dua ta ndaj me ju. Do të ketë shumë tekste, ndaj vendosa ta ndaj raportin në dy postime. Në të parën, do të flasim për autotestet dhe testimin në përgjithësi, dhe në të dytën, do të ndalem më në detaje në sistemin tonë të testimit të njësive dhe rezultatet e aplikimit të tij.

Së pari, një teori pak e mërzitshme. Çfarë është testimi i automatizuar? Ky është testim që kryhet duke përdorur softuer, dhe në IT moderne përdoret gjithnjë e më shumë në zhvillimin e softuerit. Kjo për faktin se kompanitë po rriten, sistemet e tyre të informacionit po rriten dhe, në përputhje me rrethanat, sasia e funksionalitetit që duhet të testohet po rritet. Kryerja e testimit manual po bëhet gjithnjë e më e shtrenjtë.

Kam punuar për një kompani të madhe, botimet e së cilës dalin çdo dy muaj. Në të njëjtën kohë, një muaj i tërë u shpenzua për të pasur një duzinë testues që kontrollonin manualisht funksionalitetin. Falë zbatimit të automatizimit nga një ekip i vogël zhvilluesish, ne mundëm të reduktonim kohën e testimit në 2 javë në një vit e gjysmë. Ne jo vetëm kemi rritur shpejtësinë e testimit, por edhe kemi përmirësuar cilësinë e tij. Testet e automatizuara lëshohen rregullisht dhe ato kryejnë gjithmonë të gjithë rrjedhën e kontrolleve të përfshira në to, domethënë përjashtojmë faktorin njerëzor.

IT-ja moderne karakterizohet nga fakti se një zhvilluesi mund t'i kërkohet jo vetëm të shkruajë kodin e produktit, por edhe të shkruajë teste njësie që kontrollojnë këtë kod.

Por, çka nëse sistemi juaj bazohet kryesisht në logjikën e serverit? Nuk ka zgjidhje universale apo praktika më të mira në treg. Si rregull, kompanitë e zgjidhin këtë problem duke krijuar sistemin e tyre të testimit të shkruar vetë. Ky është sistemi ynë i automatizuar i testimit i vetë-shkruar që është krijuar në projektin tonë dhe unë do të flas për të në raportin tim.

Testimi i besnikërisë

Së pari, le të flasim për projektin ku vendosëm një sistem të automatizuar testimi. Projekti ynë është sistemi i besnikërisë Sportmaster (nga rruga, ne kemi shkruar tashmë për të në këtë postim).

Nëse kompania juaj është mjaft e madhe, atëherë sistemi juaj i besnikërisë do të ketë tre veti standarde:

• Sistemi juaj do të jetë shumë i ngarkuar
• Sistemi juaj do të përmbajë procese komplekse kompjuterike
• Sistemi juaj do të përmirësohet në mënyrë aktive.

Le të ecim me radhë... Në total, nëse marrim parasysh të gjitha markat e Sportmaster, atëherë kemi më shumë se 1000 dyqane në Rusi, Ukrainë, Kinë, Kazakistan dhe Bjellorusi. Çdo ditë në këto dyqane bëhen rreth 300 mijë blerje. Kjo do të thotë, çdo sekondë 000-3 kontrolle hyjnë në sistemin tonë. Natyrisht, sistemi ynë i besnikërisë është shumë i ngarkuar. Dhe meqenëse përdoret në mënyrë aktive, ne duhet të ofrojmë standardet më të larta të cilësisë së tij, sepse çdo gabim në softuer nënkupton humbje të mëdha monetare, reputacioni dhe të tjera.

Në të njëjtën kohë, Sportmaster drejton më shumë se njëqind promovime të ndryshme. Ka një sërë promovimesh: ka promovime produktesh, ka nga ato të dedikuara për ditën e javës, ka nga ato të lidhura me një dyqan specifik, ka promovime për shumën e faturës, ka për numrin e mallrave. Në përgjithësi, jo keq. Klientët kanë bonuse dhe kode promocionale që përdoren kur bëjnë blerje. E gjithë kjo çon në faktin se llogaritja e çdo porosie është një detyrë shumë jo e parëndësishme.

Algoritmi që zbaton përpunimin e porosive është vërtet i tmerrshëm dhe i ndërlikuar. Dhe çdo ndryshim në këtë algoritëm është mjaft i rrezikshëm. Dukej se ndryshimet më të parëndësishme në dukje mund të çonin në efekte mjaft të paparashikueshme. Por janë pikërisht proceset e tilla komplekse kompjuterike, veçanërisht ato që zbatojnë funksione kritike, që janë kandidatët më të mirë për automatizim. Kontrollimi me dorë i dhjetëra rasteve të ngjashme kërkon shumë kohë. Dhe meqenëse pika e hyrjes në proces është e pandryshuar, pasi e keni përshkruar një herë, mund të krijoni shpejt teste automatike dhe të jeni të sigurt se funksionaliteti do të funksionojë.

Meqenëse sistemi ynë përdoret në mënyrë aktive, biznesi do të dëshirojë diçka të re nga ju, do të jetojë me kohën dhe do të jetë i orientuar nga klientët. Në sistemin tonë të besnikërisë, publikimet dalin çdo dy muaj. Kjo do të thotë që çdo dy muaj duhet të bëjmë një regresion të plotë të të gjithë sistemit. Në të njëjtën kohë, natyrisht, si në çdo IT moderne, zhvillimi nuk shkon menjëherë nga zhvilluesi në prodhim. Fillon në qarkun e zhvilluesit, pastaj kalon në mënyrë të njëpasnjëshme nëpër bankën e provës, lëshohet, pranohet dhe vetëm atëherë përfundon në prodhim. Së paku, në qarqet e testimit dhe lëshimit, ne duhet të kryejmë një regresion të plotë të të gjithë sistemit.

Karakteristikat 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ë bazohet në server dhe zbatohet në Oracle. Ekziston një klient i ekspozuar në Delphi, i cili kryen funksionin e një administratori të automatizuar të vendit të punës. Ka shërbime të ekspozuara në internet për aplikacione të jashtme (për shembull një faqe interneti). Prandaj, është shumë logjike që nëse vendosim një sistem testimi të automatizuar, do ta bëjmë atë në Oracle.

Sistemi i besnikërisë në Sportmaster ekziston për më shumë se 7 vjet dhe është krijuar nga zhvillues të vetëm... Numri mesatar i zhvilluesve në projektin tonë gjatë këtyre 7 viteve ishte 3-4 persona. Por gjatë vitit të kaluar, ekipi ynë është rritur ndjeshëm dhe tani janë 10 persona që punojnë në projekt. Kjo do të thotë, njerëzit vijnë në projekt që nuk janë të njohur me detyrat, proceset dhe arkitekturën tipike. Dhe ka një rrezik në rritje që të humbasim gabimet.

Projekti karakterizohet nga mungesa e testuesve të dedikuar si njësi stafi. Ka, sigurisht, testime, por testimi kryhet nga analistë, përveç përgjegjësive të tjera kryesore të tyre: komunikimi me klientët e biznesit, përdoruesit, zhvillimi i kërkesave të sistemit, etj. etj... Përkundër faktit se testimi kryhet me cilësi shumë të lartë (kjo është veçanërisht e përshtatshme për t'u përmendur, pasi disa nga analistët mund të bien në sy të këtij raporti), efektiviteti i specializimit dhe përqendrimit në një gjë nuk është anuluar. .

Duke marrë parasysh të gjitha sa më sipër, për të përmirësuar cilësinë e produktit të dorëzuar dhe për të zvogëluar kohën e zhvillimit, ideja e automatizimit të testimit në një projekt duket shumë logjike. Dhe në faza të ndryshme të ekzistencës së sistemit të besnikërisë, zhvilluesit individualë bënë përpjekje për të mbuluar kodin e tyre me teste njësie. Në përgjithësi, ishte një proces mjaft i shkëputur, ku secili përdorte arkitekturën dhe metodat e veta. Rezultatet përfundimtare ishin të zakonshme për testet e njësive: testet u zhvilluan, u përdorën për ca kohë, u ruajtën në një ruajtje të versionit të skedarëve, por në një moment ato ndaluan së funksionuari dhe u harruan. Para së gjithash, kjo për faktin se testet ishin të lidhura më shumë me një interpretues specifik, dhe jo me projektin.

utPLSQL vjen në shpëtim

A dini ndonjë gjë për Stephen Feuerstein?

Ky është një djalë i zgjuar që i kushtoi një pjesë të gjatë të karrierës së tij punës me Oracle dhe PL/SQL, dhe ka shkruar një numër mjaft të madh veprash mbi këtë temë. Një nga librat e tij të famshëm quhet: “Oracle PL/SQL. Për profesionistët”. Ishte Stephen ai që zhvilloi zgjidhjen utPLSQL, ose, siç qëndron ajo, kornizën e testimit të njësisë për Oracle PL/SQL. Zgjidhja utPLSQL u krijua në vitin 2016, por vazhdon të punohet në mënyrë aktive dhe lëshohen versione të reja. Në kohën e raportimit, versioni më i fundit daton në 24 Mars 2019.
Çfarë është ajo. Ky është një projekt i veçantë me burim të hapur. Ai peshon disa megabajt, duke përfshirë shembuj dhe dokumentacion. Fizikisht, është një skemë e veçantë në bazën e të dhënave ORACLE me një grup paketash dhe tabelash për organizimin e testimit të njësive. Instalimi zgjat disa sekonda. Një tipar dallues i utPLSQL është lehtësia e përdorimit të tij.
Globalisht, utPLSQL është një mekanizëm për ekzekutimin e testeve të njësive, ku një test njësi kuptohet si procedura e zakonshme e grupit të Oracle, organizimi i të cilave ndjek rregulla të caktuara. Përveç nisjes, utPLSQL ruan një regjistër të të gjitha testeve tuaja, dhe gjithashtu ka një sistem të brendshëm raportimi.

Le të shohim një shembull se si duket kodi i testit të njësisë, i zbatuar duke përdorur këtë teknikë.

Pra, ekrani tregon kodin për një specifikim tipik të paketës me testet e njësisë. Cilat janë kërkesat e detyrueshme? Paketa duhet të jetë e prefiksuar me "utp_". Të gjitha procedurat me teste duhet të kenë saktësisht të njëjtin prefiks. Paketa duhet të përmbajë dy procedura standarde: "utp_setup" dhe "utp_teardown". Procedura e parë thirret duke rifilluar çdo test njësie, e dyta - pas nisjes.

"utp_setup", si rregull, përgatit sistemin tonë për të ekzekutuar një test njësie, për shembull, duke krijuar të dhëna testimi. "utp_teardown" - përkundrazi, gjithçka kthehet në cilësimet origjinale dhe rivendos rezultatet e nisjes.

Këtu është një shembull i testit më të thjeshtë të njësisë që kontrollon normalizimin e numrit të telefonit të futur të klientit në formularin standard për sistemin tonë të besnikërisë. Nuk ka standarde të detyrueshme për mënyrën e shkrimit të procedurave me testet e njësive. Si rregull, një thirrje i bëhet një metode të sistemit në provë dhe rezultati i kthyer nga kjo metodë krahasohet me atë të referencës. Është e rëndësishme që krahasimi i rezultatit të referencës dhe atij të marrë të bëhet përmes metodave standarde utPLSQL.

Një test njësi mund të ketë çdo numër kontrollesh. Siç mund të shihet nga shembulli, ne bëjmë katër thirrje të njëpasnjëshme në metodën e testuar për të normalizuar numrin e telefonit dhe për të vlerësuar rezultatin pas çdo telefonate. Kur zhvilloni një test të njësisë, duhet të keni parasysh se ka kontrolle që nuk ndikojnë në asnjë mënyrë në sistemin, dhe pas disa duhet të ktheheni në gjendjen origjinale të sistemit.
Për shembull, në testin e paraqitur të njësisë ne thjesht formatojmë numrin e telefonit hyrës, i cili nuk ndikon në asnjë mënyrë në sistemin e besnikërisë.

Dhe nëse shkruajmë teste njësie duke përdorur metodën e krijimit të një klienti të ri, atëherë pas çdo testi do të krijohet një klient i ri në sistem, i cili mund të ndikojë në nisjen e mëvonshme të testit.

Kështu kryhen testet e njësisë. Ekzistojnë dy opsione të mundshme të nisjes: ekzekutimi i të gjitha testeve të njësisë nga një paketë specifike ose ekzekutimi i një testi specifik njësi në një paketë specifike.

Kështu duket një shembull i një sistemi raportimi të brendshëm. Bazuar në rezultatet e testit të njësisë, utPLSQL ndërton një raport të vogël. Në të shohim rezultatin për çdo kontroll specifik dhe rezultatin e përgjithshëm të testit të njësisë.

6 rregullat e autotesteve

Para fillimit të krijimit të një sistemi të ri për testimin e automatizuar të sistemit të besnikërisë, së bashku me menaxhmentin, ne përcaktuam parimet me të cilat duhet të përputhen testet tona të automatizuara të ardhshme.

1. Autotestet duhet të jenë efektive dhe duhet të jenë të dobishme. Ne kemi zhvillues të mrekullueshëm, të cilët patjetër duhet të përmenden, sepse disa prej tyre ndoshta do ta shohin këtë raport dhe ata shkruajnë kode të mrekullueshme. Por edhe kodi i tyre i mrekullueshëm nuk është i përsosur dhe ka, ka dhe do të vazhdojë të përmbajë gabime. Kërkohen autoteste për të gjetur këto gabime. Nëse nuk është kështu, atëherë ose po shkruajmë autoteste të këqija, ose kemi ardhur në një zonë të vdekur që në parim nuk po zhvillohet. Në të dyja rastet, ne po bëjmë diçka të gabuar dhe qasja jonë thjesht nuk ka kuptim.
2. Duhet të përdoren autoteste. Nuk ka kuptim të shpenzoni shumë kohë dhe përpjekje për të shkruar një produkt softuer, ta vendosni në një depo dhe ta harroni atë. Testet duhet të kryhen dhe të kryhen sa më rregullisht të jetë e mundur.
3. Autotestet duhet të funksionojnë në mënyrë të qëndrueshme. Pavarësisht nga koha e ditës, mbështetja e nisjes dhe cilësimet e tjera të sistemit, testet duhet të çojnë në të njëjtin rezultat. Si rregull, kjo sigurohet nga fakti që autotestet funksionojnë me të dhëna speciale të testimit me cilësime fikse të sistemit.
4. Autotestet duhet të funksionojnë me një shpejtësi të pranueshme për projektin tuaj. Kjo kohë përcaktohet individualisht për secilin sistem. Disa njerëz mund të përballojnë të punojnë gjatë gjithë ditës, ndërsa të tjerë e shohin të rëndësishme ta bëjnë atë në sekonda. Unë do t'ju tregoj pak më vonë se cilat standarde shpejtësie kemi arritur në projektin tonë.
5. Zhvillimi i autotestit duhet të jetë fleksibël. Nuk këshillohet të refuzoni të provoni ndonjë funksionalitet thjesht sepse nuk e kemi bërë më parë ose për ndonjë arsye tjetër. utPLSQL nuk vendos asnjë kufizim në zhvillim, dhe Oracle, në parim, ju lejon të zbatoni një sërë gjërash. Shumica e problemeve kanë një zgjidhje, është vetëm çështje kohe dhe përpjekjeje.
6. Zbatueshmëria. Ne kemi disa stenda ku duhet të bëjmë teste. Në çdo stendë, një depo e të dhënave mund të përditësohet në çdo kohë. Është e nevojshme të kryhet një projekt me teste automatike në mënyrë të tillë që të mund të kryeni pa dhimbje instalimin e tij të plotë ose të pjesshëm.

Dhe në postimin e dytë brenda dy ditësh do t'ju tregoj se çfarë bëmë dhe çfarë rezultatesh arritëm.

Burimi: www.habr.com