ProHoster > Blogs > Administrācija > VienÄ«bu testi DBVS ā€” kā mēs to darām programmā Sportmaster, pirmā daļa

VienÄ«bu testi DBVS ā€” kā mēs to darām programmā Sportmaster, pirmā daļa

Čau Habr!

Mani sauc Maksims Ponomarenko, un es esmu Sportmaster izstrādātājs. Man ir 10 gadu pieredze IT jomā. ViņŔ sāka savu karjeru manuālajā testÄ“Å”anā, pēc tam pārgāja uz datu bāzes izstrādi. Pēdējos 4 gadus, uzkrājot testÄ“Å”anā un izstrādē iegÅ«tās zināŔanas, automatizēju testÄ“Å”anu DBVS lÄ«menÄ«.

Esmu Sportmaster komandā tikai nedaudz vairāk kā gadu un izstrādāju automatizētu testÄ“Å”anu vienam no lielākajiem projektiem. AprÄ«lÄ« puiÅ”i no Sportmaster Lab un es runājām konferencē Krasnodarā, mans ziņojums saucās ā€œVienÄ«bu testi DBVSā€, un tagad es vēlos tajā dalÄ«ties ar jums. Teksta bÅ«s daudz, tāpēc es nolēmu ziņojumu sadalÄ«t divos ierakstos. Pirmajā runāsim par automātiskajiem testiem un testÄ“Å”anu kopumā, bet otrajā es sÄ«kāk pakavÄ“Å”os pie mÅ«su vienÄ«bu testÄ“Å”anas sistēmas un tās piemēroÅ”anas rezultātiem.

VienÄ«bu testi DBVS ā€” kā mēs to darām programmā Sportmaster, pirmā daļa

Pirmkārt, nedaudz garlaicÄ«ga teorija. Kas ir automatizētā testÄ“Å”ana? Å Ä« ir testÄ“Å”ana, kas tiek veikta, izmantojot programmatÅ«ru, un mÅ«sdienu IT to arvien vairāk izmanto programmatÅ«ras izstrādē. Tas ir saistÄ«ts ar to, ka uzņēmumi aug, to informācijas sistēmas aug un attiecÄ«gi pieaug arÄ« pārbaudāmās funkcionalitātes apjoms. Manuālas pārbaudes veikÅ”ana kļūst arvien dārgāka.

Es strādāju lielā uzņēmumā, kura izlaidumi iznāk reizi divos mēneÅ”os. Tajā paŔā laikā vesels mēnesis tika pavadÄ«ts, lai desmitiem testētāju manuāli pārbaudÄ«tu funkcionalitāti. Pateicoties automatizācijas ievieÅ”anai, ko veica neliela izstrādātāju komanda, pusotra gada laikā mēs varējām samazināt testÄ“Å”anas laiku lÄ«dz 2 nedēļām. Esam ne tikai palielinājuÅ”i testÄ“Å”anas ātrumu, bet arÄ« uzlabojuÅ”i tās kvalitāti. Automātiskie testi tiek palaisti regulāri, un tie vienmēr veic visu tajos iekļauto pārbaužu kursu, tas ir, mēs izslēdzam cilvēcisko faktoru.

Mūsdienu IT ir raksturīgs ar to, ka izstrādātājam var pieprasīt ne tikai rakstīt produkta kodu, bet arī rakstīt vienības testus, kas pārbauda Ŕo kodu.

Bet ko darÄ«t, ja jÅ«su sistēma galvenokārt balstās uz servera loÄ£iku? TirgÅ« nav universāla risinājuma vai labākās prakses. Parasti uzņēmumi Å”o problēmu risina, izveidojot paÅ”i savu rakstÄ«to testÄ“Å”anas sistēmu. Å Ä« ir mÅ«su paÅ”u rakstÄ«tā automatizētā testÄ“Å”anas sistēma, kas tika izveidota mÅ«su projektā, un es par to runāŔu savā ziņojumā.

VienÄ«bu testi DBVS ā€” kā mēs to darām programmā Sportmaster, pirmā daļa

Lojalitātes pārbaude

Pirmkārt, parunāsim par projektu, kurā mēs izvietojām automatizētu testÄ“Å”anas sistēmu. MÅ«su projekts ir Sportmaster lojalitātes sistēma (starp citu, par to jau rakstÄ«jām Å”o ziņu).

Ja jÅ«su uzņēmums ir pietiekami liels, tad jÅ«su lojalitātes sistēmai bÅ«s trÄ«s standarta Ä«paŔības:

  • JÅ«su sistēma bÅ«s ļoti noslogota
  • JÅ«su sistēmā bÅ«s sarežģīti skaitļoÅ”anas procesi
  • JÅ«su sistēma tiks aktÄ«vi uzlabota.

Ejam kārtÄ«bā... Kopumā, ja ņemam vērā visus Sportmaster zÄ«molus, tad mums ir vairāk nekā 1000 veikalu Krievijā, Ukrainā, Ķīnā, Kazahstānā un Baltkrievijā. Å ajos veikalos katru dienu tiek veikti aptuveni 300 000 pirkumu. Tas nozÄ«mē, ka katra otrā 3-4 pārbaudes nonāk mÅ«su sistēmā. Protams, mÅ«su lojalitātes sistēma ir ļoti noslogota. Un tā kā tā tiek aktÄ«vi izmantota, mums jānodroÅ”ina visaugstākie tās kvalitātes standarti, jo jebkura programmatÅ«ras kļūda nozÄ«mē lielus naudas, reputācijas un citus zaudējumus.

Tajā paŔā laikā Sportmaster rÄ«ko vairāk nekā simts dažādu akciju. Akcijas ir visdažādākās: ir preču akcijas, ir nedēļas dienai veltÄ«tās, ir piesietas konkrētam veikalam, ir akcijas par čeka summu, ir par preču skaitu. Kopumā nav slikti. Klientiem ir bonusi un reklāmas kodi, kas tiek izmantoti, veicot pirkumus. Tas viss noved pie tā, ka jebkura pasÅ«tÄ«juma aprēķināŔana ir ļoti nenozÄ«mÄ«gs uzdevums.

Algoritms, kas Ä«steno pasÅ«tÄ«jumu apstrādi, ir patiesi briesmÄ«gs un sarežģīts. Un jebkuras izmaiņas Å”ajā algoritmā ir diezgan riskantas. Å Ä·ita, ka Ŕķietami nenozÄ«mÄ«gākās izmaiņas var radÄ«t diezgan neparedzamas sekas. Bet tieÅ”i Ŕādi sarežģīti skaitļoÅ”anas procesi, Ä«paÅ”i tie, kas Ä«steno kritisko funkcionalitāti, ir vislabākie automatizācijas kandidāti. Desmitiem lÄ«dzÄ«gu lietu pārbaude ar rokām ir ļoti laikietilpÄ«ga. Un tā kā procesa ieejas punkts nav mainÄ«ts, to vienreiz aprakstot, varat ātri izveidot automātiskos testus un bÅ«t pārliecināti, ka funkcionalitāte darbosies.

Tā kā mÅ«su sistēma tiek aktÄ«vi izmantota, bizness vēlēsies no jums kaut ko jaunu, dzÄ«vos lÄ«dzi laikam un bÅ«s orientēts uz klientu. MÅ«su lojalitātes sistēmā izlaidumi tiek izdoti ik pēc diviem mēneÅ”iem. Tas nozÄ«mē, ka ik pēc diviem mēneÅ”iem mums ir jāveic pilnÄ«ga visas sistēmas regresija. Tajā paŔā laikā, protams, tāpat kā jebkurā modernā IT, izstrāde uzreiz nepāriet no izstrādātāja uz ražoÅ”anu. Tā izcelsme ir izstrādātāja ķēdē, pēc tam secÄ«gi iziet cauri testa stendam, izlaiž, pieņem un tikai pēc tam nonāk ražoÅ”anā. Vismaz pārbaudes un atbrÄ«voÅ”anas shēmās mums ir jāveic pilnÄ«ga visas sistēmas regresija.

AprakstÄ«tās Ä«paŔības ir standarta gandrÄ«z jebkurai lojalitātes sistēmai. Parunāsim par mÅ«su projekta iezÄ«mēm.

TehnoloÄ£iski 90% mÅ«su lojalitātes sistēmas loÄ£ikas ir balstÄ«ta uz serveri un ieviesta Oracle. Delfos ir eksponēts klients, kurÅ” veic automatizētas darba vietas administratora funkciju. Ir pieejami tÄ«mekļa pakalpojumi ārējām lietojumprogrammām (piemēram, vietnei). Tāpēc ir ļoti loÄ£iski, ka, ja mēs izvietosim automatizētu testÄ“Å”anas sistēmu, mēs to darÄ«sim Oracle.

Lojalitātes sistēma Sportmaster pastāv jau vairāk kā 7 gadus un to veidoja atseviŔķi izstrādātāji... Vidējais izstrādātāju skaits mÅ«su projektā Å”ajos 7 gados bija 3-4 cilvēki. Taču pēdējā gada laikā mÅ«su komanda ir ievērojami augusi, un Å”obrÄ«d pie projekta strādā 10 cilvēki. Tas ir, projektā ierodas cilvēki, kuri nav pazÄ«stami ar tipiskiem uzdevumiem, procesiem un arhitektÅ«ru. Un ir paaugstināts risks, ka mēs palaidÄ«sim garām kļūdas.

Projektu raksturo tas, ka nav Ä«paÅ”u testētāju kā personāla vienÄ«bu. Protams, ir arÄ« testÄ“Å”ana, taču testÄ“Å”anu veic analÄ«tiÄ·i papildus citiem saviem galvenajiem pienākumiem: saziņai ar biznesa klientiem, lietotājiem, sistēmas prasÄ«bu izstrādei utt. utt... Neraugoties uz to, ka testÄ“Å”ana tiek veikta ļoti kvalitatÄ«vi (to ir Ä«paÅ”i vērts pieminēt, jo daži analÄ«tiÄ·i var iekrist Å”ajā ziņojumā), specializācijas efektivitāte un koncentrÄ“Å”anās uz vienu lietu nav atcelta .

Ņemot vērā visu iepriekÅ” minēto, lai uzlabotu piegādātā produkta kvalitāti un samazinātu izstrādes laiku, ideja automatizēt projekta testÄ“Å”anu Ŕķiet ļoti loÄ£iska. Un dažādos lojalitātes sistēmas pastāvÄ“Å”anas posmos atseviŔķi izstrādātāji centās pārklāt savu kodu ar vienÄ«bu testiem. Kopumā tas bija diezgan nesavienots process, kurā katrs izmantoja savu arhitektÅ«ru un metodes. GalÄ«gie rezultāti bija kopÄ«gi vienÄ«bu testiem: testi tika izstrādāti, kādu laiku izmantoti, glabāti versiju failu krātuvē, bet kādā brÄ«dÄ« tie pārstāja darboties un tika aizmirsti. Pirmkārt, tas bija saistÄ«ts ar faktu, ka testi vairāk tika piesaistÄ«ti konkrētam izpildÄ«tājam, nevis projektam.

utPLSQL nāk palīgā

VienÄ«bu testi DBVS ā€” kā mēs to darām programmā Sportmaster, pirmā daļa

Vai jūs kaut ko zināt par Stīvenu FeuerŔteinu?

Å is ir gudrs puisis, kurÅ” ilgu savas karjeras daļu veltÄ«jis darbam ar Oracle un PL/SQL, un par Å”o tēmu ir uzrakstÄ«jis diezgan daudz darbu. Viena no viņa slavenajām grāmatām saucas: ā€œOracle PL/SQL. Profesionāļiem." Tas bija StÄ«vens, kurÅ” izstrādāja Oracle PL/SQL utPLSQL risinājumu jeb, kā tas nozÄ«mē, Unit Testing ietvaru. utPLSQL risinājums tika izveidots 2016. gadā, taču pie tā turpina aktÄ«vi strādāt un tiek izdotas jaunas versijas. Pārskata sniegÅ”anas brÄ«dÄ« jaunākā versija ir datēta ar 24. gada 2019. martu.
Kas tas ir. Å is ir atseviŔķs atvērtā koda projekts. Tas sver pāris megabaitus, ieskaitot piemērus un dokumentāciju. Fiziski tā ir atseviŔķa shēma ORACLE datu bāzē ar pakotņu un tabulu komplektu vienÄ«bu testÄ“Å”anas organizÄ“Å”anai. InstalÄ“Å”ana aizņem dažas sekundes. AtŔķirÄ«ga utPLSQL iezÄ«me ir tā lietoÅ”anas vienkārŔība.
Globāli utPLSQL ir vienÄ«bas testu palaiÅ”anas mehānisms, kur vienÄ«bas tests tiek saprasts kā parastas Oracle pakeÅ”u procedÅ«ras, kuru organizÄ“Å”anā tiek ievēroti noteikti noteikumi. Papildus palaiÅ”anai utPLSQL saglabā visu jÅ«su testa darbÄ«bu žurnālu, kā arÄ« tajā ir iekŔēja ziņoÅ”anas sistēma.

ApskatÄ«sim piemēru, kā izskatās vienÄ«bas pārbaudes kods, kas ieviests, izmantojot Å”o paņēmienu.

VienÄ«bu testi DBVS ā€” kā mēs to darām programmā Sportmaster, pirmā daļa

Tātad ekrānā tiek parādÄ«ts tipiskas pakotnes specifikācijas kods ar vienÄ«bu testiem. Kādas ir obligātās prasÄ«bas? Paketes prefiksam jābÅ«t "utp_". Visām procedÅ«rām ar testiem jābÅ«t tieÅ”i tādam paÅ”am prefiksam. Pakotnē jāietver divas standarta procedÅ«ras: ā€œutp_setupā€ un ā€œutp_teardownā€. Pirmā procedÅ«ra tiek izsaukta, restartējot katru vienÄ«bas pārbaudi, otrā - pēc palaiÅ”anas.

ā€œutp_setupā€, kā likums, sagatavo mÅ«su sistēmu, lai palaistu vienÄ«bas testu, piemēram, izveidojot testa datus. ā€œutp_teardownā€ - gluži pretēji, viss atgriežas sākotnējos iestatÄ«jumos un atiestata palaiÅ”anas rezultātus.

Å eit ir piemērs vienkārŔākajai vienÄ«bas pārbaudei, kas pārbauda ievadÄ«tā klienta tālruņa numura normalizÄ“Å”anu mÅ«su lojalitātes sistēmas standarta veidlapā. Nav obligātu standartu, kā rakstÄ«t procedÅ«ras ar vienÄ«bas testiem. Parasti tiek izsaukta pārbaudāmās sistēmas metode, un Ŕīs metodes atgrieztais rezultāts tiek salÄ«dzināts ar atsauces metodi. Ir svarÄ«gi, lai atsauces un iegÅ«tā rezultāta salÄ«dzināŔana notiktu, izmantojot standarta utPLSQL metodes.

Vienības testā var būt neierobežots skaits pārbaužu. Kā redzams no piemēra, mēs veicam četrus secīgus zvanus uz pārbaudīto metodi, lai normalizētu tālruņa numuru un novērtētu rezultātu pēc katra zvana. Izstrādājot vienības testu, ir jāņem vērā, ka ir pārbaudes, kas nekādā veidā neietekmē sistēmu, un pēc dažām jums ir jāatgriežas sākotnējā sistēmas stāvoklī.
Piemēram, prezentētajā vienÄ«bas testā mēs vienkārÅ”i formatējam ievades tālruņa numuru, kas nekādi neietekmē lojalitātes sistēmu.

Un, ja mēs rakstām vienÄ«bas testus, izmantojot jauna klienta izveides metodi, tad pēc katras pārbaudes sistēmā tiks izveidots jauns klients, kas var ietekmēt turpmāko testa palaiÅ”anu.

VienÄ«bu testi DBVS ā€” kā mēs to darām programmā Sportmaster, pirmā daļa

Šādi tiek veikti vienÄ«bu testi. Ir divas iespējamās palaiÅ”anas opcijas: visu vienÄ«bu testu izpilde no noteiktas pakotnes vai noteiktas vienÄ«bas pārbaudes veikÅ”ana noteiktā pakotnē.

VienÄ«bu testi DBVS ā€” kā mēs to darām programmā Sportmaster, pirmā daļa

Šādi izskatās iekŔējās ziņoÅ”anas sistēmas piemērs. Pamatojoties uz vienÄ«bas pārbaudes rezultātiem, utPLSQL izveido nelielu pārskatu. Tajā mēs redzam katras konkrētās pārbaudes rezultātu un kopējo vienÄ«bas testa rezultātu.

6 automātiskās pārbaudes noteikumi

Pirms sākam veidot jaunu lojalitātes sistēmas automatizētās testÄ“Å”anas sistēmu, kopā ar vadÄ«bu noteicām principus, kādiem bÅ«tu jāatbilst mÅ«su turpmākajām automatizētajām pārbaudēm.

VienÄ«bu testi DBVS ā€” kā mēs to darām programmā Sportmaster, pirmā daļa

  1. Automātiskajiem testiem ir jābÅ«t efektÄ«viem un noderÄ«giem. Mums ir brÄ«niŔķīgi izstrādātāji, kuri noteikti ir jāpiemin, jo daži no viņiem, iespējams, redzēs Å”o ziņojumu, un viņi raksta brÄ«niŔķīgu kodu. Bet pat viņu brÄ«niŔķīgais kods nav ideāls, un tajā ir, ir un joprojām bÅ«s kļūdas. Lai atrastu Ŕīs kļūdas, ir jāveic automātiskās pārbaudes. Ja tas tā nav, tad vai nu mēs rakstām sliktus autotestus, vai arÄ« esam nonākuÅ”i miruŔā vietā, kas principā netiek izstrādāta. Abos gadÄ«jumos mēs darām kaut ko nepareizi, un mÅ«su pieejai vienkārÅ”i nav jēgas.
  2. Jāizmanto automātiskās pārbaudes. Nav jēgas tērēt daudz laika un pūļu programmatÅ«ras produkta rakstÄ«Å”anai, ievietot to repozitorijā un aizmirst. Testi ir jāveic un jāveic pēc iespējas regulāri.
  3. Automātiskajiem testiem vajadzētu darboties stabili. NeatkarÄ«gi no diennakts laika, palaiÅ”anas stenda un citiem sistēmas iestatÄ«jumiem, testa braucieniem vajadzētu dot tādu paÅ”u rezultātu. Parasti to nodroÅ”ina fakts, ka automātiskās pārbaudes darbojas ar Ä«paÅ”iem testa datiem ar fiksētiem sistēmas iestatÄ«jumiem.
  4. Automātiskajiem testiem ir jādarbojas jÅ«su projektam pieņemamā ātrumā. Å is laiks tiek noteikts katrai sistēmai individuāli. Daži cilvēki var atļauties strādāt visu dienu, savukārt citi uzskata, ka ir ļoti svarÄ«gi to izdarÄ«t dažu sekunžu laikā. Es jums pastāstÄ«Å”u nedaudz vēlāk, kādus ātruma standartus mēs sasniedzām savā projektā.
  5. Automātiskās pārbaudes izstrādei jābÅ«t elastÄ«gai. Nav ieteicams atteikties no jebkuras funkcionalitātes testÄ“Å”anas tikai tāpēc, ka mēs to iepriekÅ” neesam darÄ«juÅ”i vai kāda cita iemesla dēļ. utPLSQL neuzliek nekādus ierobežojumus attÄ«stÄ«bai, un Oracle principā ļauj ieviest dažādas lietas. Lielākajai daļai problēmu ir risinājums, tas ir tikai laika un pūļu jautājums.
  6. IzvietojamÄ«ba. Mums ir vairāki stendi, kur jāveic testi. Katrā stendā datu izgāztuve var tikt atjaunināta jebkurā laikā. Ir nepiecieÅ”ams veikt projektu ar automātiskām pārbaudēm tā, lai jÅ«s varētu nesāpÄ«gi veikt tā pilnÄ«gu vai daļēju uzstādÄ«Å”anu.

Un otrajā ierakstā pēc pāris dienām pastāstÄ«Å”u, ko mēs darÄ«jām un kādus rezultātus sasniegām.

Avots: www.habr.com

Pievieno komentāru