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

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

Pirmā daļa - Ŕeit.

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

Iedomājieties situāciju. JÅ«s saskaraties ar uzdevumu izstrādāt jaunu funkcionalitāti. Jums ir attÄ«stÄ«ba no jÅ«su priekÅ”gājējiem. Ja pieņemtu, ka jums nav nekādu morālu pienākumu, ko jÅ«s darÄ«tu?

Visbiežāk visas vecās norises tiek aizmirstas un viss sākas no jauna. Nevienam nepatÄ«k iedziļināties sveŔā kodā, bet, ja ir laiks, kāpēc gan nesākt izveidot savu sistēmu? Tā ir tipiska pieeja, un tā lielākoties ir pareiza. Bet mÅ«su projektā mēs to darÄ«jām nepareizi. Mēs balstÄ«jām nākotnes automātiskās testÄ“Å”anas sistēmu uz utPLSQL vienÄ«bu testu attÄ«stÄ«bu no mÅ«su priekÅ”gājējiem un pēc tam sākām strādāt vairākos paralēlos virzienos.

  1. Veco vienÄ«bu testu atjaunoÅ”ana. AtkopÅ”ana nozÄ«mē testu pielāgoÅ”anu esoÅ”ajam lojalitātes sistēmas stāvoklim un testu pielāgoÅ”anu utPLSQL standartiem.
  2. Problēmas risināŔana ar izpratni par to, kas tieÅ”i, kādas metodes un procesi tiek pārklāti ar autotestiem. Jums vai nu jāsaglabā Ŕī informācija savā galvā, vai arÄ« jāizdara secinājumi, pamatojoties tieÅ”i uz automātiskās pārbaudes kodu. Tāpēc mēs nolēmām izveidot katalogu. Katram automātiskajam testam pieŔķīrām unikālu mnemonisko kodu, izveidojām aprakstu un ierakstÄ«jām iestatÄ«jumus (piemēram, kādos apstākļos tas ir jāpalaiž, vai kas jānotiek, ja testa palaiÅ”ana neizdodas). BÅ«tÄ«bā mēs aizpildÄ«jām automātisko testu metadatus un ievietojām Å”os metadatus standarta utPLSQL shēmu tabulās.
  3. PaplaÅ”ināŔanās stratēģijas definÄ“Å”ana, t.i. funkcionalitātes izvēle, kas ir pakļauta pārbaudei, izmantojot automatizētus testus. Mēs nolēmām pievērst uzmanÄ«bu trim lietām: jauniem sistēmas uzlabojumiem, ražoÅ”anas incidentiem un galvenajiem sistēmas procesiem. Tādējādi attÄ«stāmies paralēli izlaiÅ”anai, nodroÅ”inot tās augstāku kvalitāti, vienlaikus paplaÅ”inot regresijas apjomu un nodroÅ”inot sistēmas uzticamÄ«bu kritiskās vietās. Pirmā Ŕāda vājā vieta bija atlaižu un prēmiju sadale par čeku.
  4. Protams, mēs sākām izstrādāt jaunus autotestus. Viens no pirmajiem izlaiduma uzdevumiem bija iepriekÅ” noteiktu lojalitātes sistēmas paraugu veiktspējas novērtÄ“Å”ana. MÅ«su projektā ir stingri fiksētu SQL vaicājumu bloks, kas atlasa klientus, pamatojoties uz nosacÄ«jumiem. Piemēram, iegÅ«stiet sarakstu ar visiem klientiem, kuru pēdējais pirkums bija konkrētā pilsētā, vai to klientu sarakstu, kuru vidējā pirkuma summa pārsniedz noteiktu vērtÄ«bu. Pēc automātiskās pārbaudes veikÅ”anas mēs pārbaudÄ«jām iepriekÅ” definētus paraugus, reÄ£istrējām etalonuzdevuma parametrus un papildus veicām slodzes testÄ“Å”anu.
  5. Darbam ar automātiskajiem testiem jābÅ«t ērtam. Divas visizplatÄ«tākās darbÄ«bas ir automātiskās pārbaudes palaiÅ”ana un testa datu izveide. Tā mÅ«su sistēmā parādÄ«jās divi palÄ«gmoduļi: palaiÅ”anas modulis un datu Ä£enerÄ“Å”anas modulis.

    PalaiÅ”anas programma tiek attēlota kā viena universāla procedÅ«ra ar vienu teksta ievades parametru. Kā parametru varat nodot automātiskās pārbaudes mnemonisko kodu, pakotnes nosaukumu, testa nosaukumu, automātiskās pārbaudes iestatÄ«jumu vai rezervētu atslēgvārdu. ProcedÅ«ra atlasa un palaiž visus automātiskos testus, kas atbilst nosacÄ«jumiem.

    Datu Ä£enerÄ“Å”anas modulis tiek pasniegts pakotnes veidā, kurā katram pārbaudāmās sistēmas objektam (tabula datu bāzē) ir izveidota speciāla procedÅ«ra, kas tur ievieto datus. Å ajā procedÅ«rā noklusējuma vērtÄ«bas tiek aizpildÄ«tas pēc iespējas vairāk, kas nodroÅ”ina objektu izveidi burtiski ar pirksta klikŔķi. Un lietoÅ”anas ērtÄ«bai tika izveidotas Ä£enerēto datu veidnes. Piemēram, izveidojiet klientu noteiktā vecumā ar testa tālruni un pabeigtu pirkumu.

  6. Automātiskajai pārbaudei ir jāsākas un jāpalaiž jÅ«su sistēmai pieņemamā laikā. Tāpēc tika organizēta ikdienas nakts palaiÅ”ana, pamatojoties uz kuras rezultātiem tiek Ä£enerēta atskaite par rezultātiem un nosÅ«tÄ«ta visai izstrādes komandai ar korporatÄ«vo pastu. Pēc veco autotestu atjaunoÅ”anas un jaunu izveidoÅ”anas kopējais darbÄ«bas laiks bija 30 minÅ«tes. Å is priekÅ”nesums bija piemērots visiem, jo ā€‹ā€‹palaiÅ”ana notika ārpus darba laika.

    Taču bija jāstrādā pie darba ātruma optimizÄ“Å”anas. RažoÅ”anas lojalitātes sistēma tiek atjaunināta naktÄ«. Kā daļu no viena no izlaidumiem mums naktÄ« bija jāveic steidzamas izmaiņas. Autotestu rezultātu gaidÄ«Å”ana pusstundu trijos naktÄ« nesagādāja prieku par atbrÄ«voÅ”anu atbildÄ«go (dedzÄ«gi sveicieni Aleksejam Vasjukovam!), un nākamajā rÄ«tā mÅ«su sistēmai tika teikts daudz laipnu vārdu. Bet rezultātā tika noteikts 5 minÅ«Å”u darba standarts.

    Lai paātrinātu veiktspēju, mēs izmantojām divas metodes: automātiskās pārbaudes sāka darboties trÄ«s paralēlos pavedienos, par laimi tas ir ļoti ērti mÅ«su lojalitātes sistēmas arhitektÅ«ras dēļ. Un mēs atteicāmies no pieejas, kad automātiskais tests pats nerada testa datus, bet mēģina atrast sistēmā kaut ko piemērotu. Pēc izmaiņu veikÅ”anas kopējais darbÄ«bas laiks tika samazināts lÄ«dz 3-4 minÅ«tēm.

  7. Projektu ar automātiskām pārbaudēm vajadzētu bÅ«t iespējai izvietot dažādos stendos. MÅ«su ceļojuma sākumā bija mēģinājumi rakstÄ«t paÅ”i savus pakeÅ”failus, taču kļuva skaidrs, ka paÅ”u rakstÄ«ta automatizēta instalācija ir pilnÄ«gas Å”ausmas, un mēs pievērsāmies industriālajiem risinājumiem. Sakarā ar to, ka projektā ir daudz tieŔā koda (pirmkārt, mēs glabājam autotesta kodu) un ļoti maz datu (galvenie dati ir metadati par autotestiem), Liquibase projektā ievieÅ”ana izrādÄ«jās ļoti vienkārÅ”a.

    Tā ir atvērtā koda, no datu bāzes neatkarÄ«ga bibliotēka datu bāzes shēmu izmaiņu izsekoÅ”anai, pārvaldÄ«bai un ievieÅ”anai. Pārvalda, izmantojot komandrindu vai ietvarus, piemēram, Apache Maven. Liquibase darbÄ«bas princips ir diezgan vienkārÅ”s. Mums ir noteiktā veidā organizēts projekts, kas sastāv no izmaiņām jeb skriptiem, kas jāievieÅ” mērÄ·a serverÄ«, un kontroles failiem, kas nosaka, kādā secÄ«bā un ar kādiem parametriem Ŕīs izmaiņas jāinstalē.

    DBVS lÄ«menÄ« tiek izveidota Ä«paÅ”a tabula, kurā Liquibase saglabā apgāŔanās žurnālu. Katrai izmaiņai ir aprēķināts hash, kas katru reizi tiek salÄ«dzināts starp projektu un stāvokli datu bāzē. Pateicoties Liquibase, mēs varam viegli ieviest izmaiņas mÅ«su sistēmā jebkurā shēmā. Automātiskie testi tagad tiek palaisti testa un izlaiÅ”anas shēmās, kā arÄ« konteineros (izstrādātāju personÄ«gajās shēmās).

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

Tātad, parunāsim par mÅ«su vienÄ«bu testÄ“Å”anas sistēmas izmantoÅ”anas rezultātiem.

  1. Protams, pirmkārt, mēs esam pārliecināti, ka esam sākuÅ”i izstrādāt labāku programmatÅ«ru. Automātiskie testi tiek palaisti katru dienu, un katrā laidienā tiek atrasti desmitiem kļūdu. Turklāt dažas no Ŕīm kļūdām ir tikai netieÅ”i saistÄ«tas ar funkcionalitāti, kuru mēs patieŔām vēlējāmies mainÄ«t. Pastāv nopietnas Å”aubas, ka Ŕīs kļūdas tika atklātas manuāli pārbaudot.
  2. Komanda tagad ir pārliecināta, ka konkrēta funkcionalitāte darbojas pareizi... Pirmkārt, tas attiecas uz mÅ«su kritiskajiem procesiem. Piemēram, pēdējā pusgada laikā mums nav bijuÅ”as problēmas ar atlaižu un prēmiju sadali par čekiem, neskatoties uz izlaiduma izmaiņām, lai gan iepriekŔējos periodos kļūdas notika ar zināmu biežumu.
  3. Mums izdevās samazināt testÄ“Å”anas iterāciju skaitu. Sakarā ar to, ka autotesti tiek rakstÄ«ti jaunai funkcionalitātei, analÄ«tiÄ·i un nepilna laika testētāji saņem augstākas kvalitātes kodu, jo tas jau ir pārbaudÄ«ts.
  4. Dažus automatizētās testÄ“Å”anas uzlabojumus izmanto izstrādātāji. Piemēram, testa dati par konteineriem tiek izveidoti, izmantojot objektu Ä£enerÄ“Å”anas moduli.
  5. SvarÄ«gi, ka esam izstrādājuÅ”i automatizētās testÄ“Å”anas sistēmas ā€œakceptuā€ no izstrādātāju puses. Ir izpratne, ka tas ir svarÄ«gi un noderÄ«gi. Bet no savas pieredzes varu teikt, ka tas nebÅ«t nav tā. Autotesti ir jāraksta, tie ir jāatbalsta un jāattÄ«sta, rezultāti jāanalizē, un bieži vien Ŕīs laika izmaksas vienkārÅ”i nav tā vērtas. Ir daudz vieglāk pāriet uz ražoÅ”anu un tur risināt problēmas. Å eit izstrādātāji stāv rindā un lÅ«dz mÅ«s nodroÅ”ināt viņu funkcionalitāti ar automātiskajiem testiem.

Kas ir nākamais

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

Parunāsim par automatizētās testÄ“Å”anas projekta attÄ«stÄ«bas plāniem.

Protams, kamēr Sportmaster lojalitātes sistēma ir dzÄ«va un turpina attÄ«stÄ«ties, ir iespējams izstrādāt arÄ« autotestus gandrÄ«z bezgalÄ«gi. Tāpēc galvenais attÄ«stÄ«bas virziens ir pārklājuma zonas paplaÅ”ināŔana.

Palielinoties automātisko testu skaitam, to kopējais darbÄ«bas laiks nepārtraukti palielināsies, un mums atkal bÅ«s jāatgriežas pie veiktspējas jautājuma. Visticamāk, risinājums bÅ«s paralēlo pavedienu skaita palielināŔana.

Bet tie ir acÄ«mredzami attÄ«stÄ«bas veidi. Ja mēs runājam par kaut ko nenozÄ«mÄ«gāku, mēs izceļam sekojoÅ”o:

  1. Å obrÄ«d autotesta vadÄ«ba tiek veikta DBVS lÄ«menÄ«, t.i. sekmÄ«gam darbam nepiecieÅ”amas PL/SQL zināŔanas. Ja nepiecieÅ”ams, sistēmas vadÄ«ba (piemēram, palaiÅ”ana vai metadatu izveidoÅ”ana), var izveidot kaut kādu admin paneli, izmantojot Jenkins vai ko lÄ«dzÄ«gu.
  2. Ikvienam patÄ«k kvantitatÄ«vie un kvalitatÄ«vie rādÄ«tāji. Automatizētai testÄ“Å”anai Ŕāds universāls rādÄ«tājs ir Code Coverage jeb koda pārklājuma metrika. Izmantojot Å”o rādÄ«tāju, mēs varam noteikt, cik procentu no mÅ«su pārbaudāmās sistēmas koda sedz automātiskās pārbaudes. Sākot ar versiju 12.2, Oracle nodroÅ”ina iespēju aprēķināt Å”o metriku un piedāvā standarta pakotnes DBMS_PLSQL_CODE_COVERAGE izmantoÅ”anu.

    Mūsu automātiskās pārbaudes sistēma ir tikai nedaudz vairāk nekā gadu veca, un, iespējams, ir pienācis laiks novērtēt mūsu pārklājumu. Manā pēdējā projektā (nevis Sportmaster projektā) tas notika. Gadu pēc darba pie autotestiem vadība izvirzīja uzdevumu novērtēt, cik procentus no koda mēs aptveram. Ja segums būtu lielāks par 1%, vadība būtu apmierināta. Mēs, izstrādātāji, gaidījām aptuveni 10% rezultātu. Mēs uzstādījām koda pārklājumu, izmērījām to un saņēmām 20%. Lai nosvinētu, mēs devāmies pēc balvas, bet kā mums gāja pēc tās un kur devāmies vēlāk, tas ir pavisam cits stāsts.

  3. Automātiskie testi var pārbaudīt atklātos tīmekļa pakalpojumus. Oracle ļauj mums to izdarīt diezgan labi, un mēs vairs nesastapsimies ar vairākām problēmām.
  4. Un, protams, mÅ«su automatizēto testÄ“Å”anas sistēmu var pielietot citam projektam. Saņemtais risinājums ir universāls, un tam ir jāizmanto tikai Oracle. Dzirdēju, ka citi Sportmaster projekti interesējas par automātisko testÄ“Å”anu un, iespējams, arÄ« pie viņiem dosimies.

Atzinumi

Apkoposim. Lojalitātes sistēmas projektā Sportmaster mums izdevās ieviest automatizētu testÄ“Å”anas sistēmu. Tā pamatā ir StÄ«vena Feuersteina utPLSQL risinājums. Ap utPLSQL ir automātiskās pārbaudes kods un paÅ”rakstÄ«ti papildu moduļi: palaiÅ”anas modulis, datu Ä£enerÄ“Å”anas modulis un citi. Automātiskie testi tiek palaisti katru dienu, un, pats galvenais, tie darbojas un ir noderÄ«gi. Mēs esam pārliecināti, ka esam sākuÅ”i izlaist augstākas kvalitātes programmatÅ«ru. Tajā paŔā laikā iegÅ«tais risinājums ir universāls un var tikt brÄ«vi piemērots jebkuram projektam, kur nepiecieÅ”ams organizēt Oracle DBVS automatizētu testÄ“Å”anu.

PS Å is raksts nav Ä«paÅ”i konkrēts: ir daudz teksta un praktiski nav tehnisku piemēru. Ja tēma kopumā ir interesanta, tad esam gatavi to turpināt un atgriezties ar turpinājumu, kurā pastāstÄ«sim, kas ir mainÄ«jies pēdējā pusgada laikā un sniegsim kodu piemērus.

Rakstiet komentārus, ja ir punkti, kas būtu jāuzsver nākotnē, vai jautājumi, kas jāatklāj.

Aptaujā var piedalīties tikai reģistrēti lietotāji. Ielogoties, lūdzu.

Vai rakstīsim par to tālāk?

  • Jā, protams

  • Nē paldies

Nobalsoja 12 lietotāji. 4 lietotāji atturējās.

Avots: www.habr.com

Pievieno komentāru