Vienetų testai DBVS – kaip tai darome „Sportmaster“, antroji dalis

Pirma dalis - čia.

Įsivaizduokite situaciją. Jūs susiduriate su užduotimi sukurti naujas funkcijas. Turite patirties iš savo pirmtakų. Darydami prielaidą, kad neturite moralinių įsipareigojimų, ką darytumėte?

Dažniausiai visi seni įvykiai pamirštami ir viskas prasideda iš naujo. Niekas nemėgsta gilintis į svetimą kodą, o jei turi laiko, kodėl nepradėjus kurti savo sistemos? Tai tipiškas požiūris ir daugeliu atžvilgių teisingas. Tačiau savo projekte elgėmės kitaip. Būsimą automatizuotą testavimo sistemą sukūrėme remdamiesi utPLSQL vienetų testų raida iš mūsų pirmtakų, o tada pradėjome dirbti keliomis lygiagrečiomis kryptimis.

1. Senų vienetų testų atkūrimas. Atkūrimas – tai testų pritaikymas esamai lojalumo sistemos būsenai ir testų pritaikymas utPLSQL standartams.
2. Išspręsdami problemą suprasdami, ką tiksliai, kokiais metodais ir procesais atlikome automatiniais testais. Turite arba saugoti šią informaciją savo galvoje, arba daryti išvadas, remiantis tiesiogiai automatinių testų kodu. Todėl nusprendėme sukurti katalogą. Kiekvienam automatiniam testui priskyrėme unikalų mnemoninį kodą, sukūrėme aprašymą ir pataisėme nustatymus (pavyzdžiui, kokiomis sąlygomis jis turi būti paleistas arba kas turėtų nutikti, jei bandomasis paleidimas nepavyks). Iš esmės užpildėme metaduomenis apie automatinius testus ir patalpinome šiuos metaduomenis į standartines utPLSQL schemos lenteles.
3. Plėtros strategijos apibrėžimas, t.y. funkcijų pasirinkimas, kuris turi būti patikrintas naudojant automatinius testus. Nusprendėme atkreipti dėmesį į tris dalykus: naujus sistemos patobulinimus, incidentus iš gamybos ir pagrindinius sistemos procesus. Taigi plėtojame lygiagrečiai su išleidimu, užtikrindami aukštesnę jo kokybę, kartu plečiant regresijos apimtį ir užtikrinant sistemos patikimumą kritinėse vietose. Pirmoji tokia kliūtis buvo nuolaidų ir premijų skirstymas čekiu.
4. Natūralu, kad pradėjome kurti naujus automatinius testus. Viena iš pirmųjų leidimo užduočių buvo įvertinti iš anksto nustatytų lojalumo sistemos pavyzdžių našumą. Mūsų projekte yra griežtai fiksuotų sql užklausų blokas, kuris parenka klientus pagal sąlygas. Pavyzdžiui, gaukite sąrašą visų klientų, kurių paskutinis pirkinys buvo tam tikrame mieste, arba sąrašą klientų, kurių vidutinė pirkimo suma viršija tam tikrą vertę. Atlikę automatinius testus, patikrinome iš anksto nustatytus pavyzdžius, fiksavome etaloninius veikimo parametrus, papildomai gavome apkrovos testavimą.
5. Darbas su automatiniais testais turėtų būti patogus. Du dažniausiai atliekami veiksmai yra automatinių testų vykdymas ir bandymo duomenų generavimas. Taip mūsų sistemoje atsirado du pagalbiniai moduliai: paleidimo modulis ir duomenų generavimo modulis.

   Paleidimo priemonė pateikiama kaip viena bendra procedūra su vienu įvesties teksto parametru. Kaip parametrą galite perduoti automatinio testo mnemoninį kodą, paketo pavadinimą, testo pavadinimą, automatinio testo nustatymą arba rezervuotą raktinį žodį. Procedūra parenka ir paleidžia visus automatinius testus, kurie atitinka sąlygas.

   Duomenų generavimo modulis pateikiamas kaip paketas, kuriame kiekvienam tiriamos sistemos objektui (lentelė duomenų bazėje) sukurta speciali procedūra, kuri ten įterpia duomenis. Šioje procedūroje numatytosios reikšmės užpildomos maksimaliai, o tai užtikrina objektų kūrimą tiesiogine prasme vienu piršto paspaudimu. O kad būtų lengviau naudoti, buvo sukurti šablonai generuojamiems duomenims. Pavyzdžiui, sukurkite tam tikro amžiaus klientą su bandomuoju telefonu ir užbaigtu pirkiniu.

6. Automatiniai testai turėtų paleisti ir paleisti per jūsų sistemai priimtiną laiką. Todėl buvo organizuojamas kasdieninis naktinis startas, kurio rezultatais remiantis generuojama rezultatų ataskaita ir išsiunčiama visai kūrimo komandai įmonės paštu. Atkūrus senus automatinius testus ir sukūrus naujus, bendras veikimo laikas buvo 30 min. Toks pasirodymas tiko visiems, nes paleidimas vyko ne darbo valandomis.

   Tačiau turėjome stengtis optimizuoti darbo greitį. Gamybos lojalumo sistema atnaujinama naktį. Vieno iš leidimų metu turėjome skubiai atlikti pakeitimus naktį. Pusvalandis laukimas automatinių testų rezultatų trečią ryto nenudžiugino atsakingo už paleidimą žmogaus (arstingi sveikinimai Aleksejui Vasiukovui!), O kitą rytą mūsų sistemai buvo pasakyta daug šiltų žodžių. Bet dėl ​​to buvo nustatytas 5 minučių darbo standartas.

   Norėdami pagreitinti našumą, panaudojome du būdus: pradėjome vykdyti automatinius testus trijose lygiagrečiose gijose, nes tai labai patogu dėl mūsų lojalumo sistemos architektūros. Ir mes atsisakėme požiūrio, kai automatinis testas nesukuria testo duomenų sau, o bando rasti kažką tinkamo sistemoje. Atlikus pakeitimus bendras veikimo laikas sutrumpėjo iki 3-4 minučių.

7. Projektą su automatiniais testais turėtų būti galima įdiegti įvairiuose stenduose. Kelionės pradžioje buvo bandoma rašyti savo paketinius failus, tačiau tapo aišku, kad pačių parašyta automatizuota instaliacija yra visiškas siaubas, ir pasukome pramoninių sprendimų link. Dėl to, kad projekte yra daug kodo tiesiogiai (visų pirma, mes saugome automatinių testų kodą) ir labai mažai duomenų (pagrindiniai duomenys yra metaduomenys apie automatinius testus), jį labai lengva integruoti į Liquibase projektas.

   Tai atvirojo kodo duomenų bazės nepriklausoma biblioteka, skirta stebėti, valdyti ir taikyti duomenų bazės schemų pakeitimus. Valdoma per komandinę eilutę arba sistemas, tokias kaip „Apache Maven“. Liquibase veikimo principas yra gana paprastas. Turime tam tikru būdu organizuotą projektą, kurį sudaro pakeitimai arba scenarijai, kuriuos reikia perkelti į tikslinį serverį, ir valdymo failai, kurie nustato, kokia tvarka ir su kokiais parametrais šie pakeitimai turi būti įdiegti.

   DBVS lygiu sukuriama speciali lentelė, kurioje Liquibase saugo atšaukimo žurnalą. Kiekvienas pakeitimas turi apskaičiuotą maišą, kuri kiekvieną kartą lyginama tarp projekto ir būsenos duomenų bazėje. Liquibase dėka galime lengvai įdiegti sistemos pakeitimus bet kurioje grandinėje. Dabar automatiniai testai vykdomi naudojant testavimo ir išleidimo kilpas, taip pat konteinerius (asmenines kūrėjų kilpas).

Taigi, pakalbėkime apie mūsų vienetų testavimo sistemos taikymo rezultatus.

1. Žinoma, visų pirma esame įsitikinę, kad pradėjome kurti geresnę programinę įrangą. Automatiniai testai vykdomi kasdien ir kiekviename leidime randama daugybė klaidų. Be to, kai kurios iš šių klaidų yra tik netiesiogiai susijusios su funkcionalumu, kurį tikrai norėjome pakeisti. Kyla didelių abejonių, kad šios klaidos buvo rastos atliekant rankinį testavimą.
2. Komanda įgijo pasitikėjimo, kad konkretus funkcionalumas veikia tinkamai... Visų pirma, tai liečia mūsų svarbiausius procesus. Pavyzdžiui, per pastaruosius šešis mėnesius neturėjome problemų dėl nuolaidų ir premijų paskirstymo čekiu, nepaisant kiekvieną kartą atliekamų pakeitimų, nors ankstesniais laikotarpiais klaidų pasitaikydavo gana dažnai.
3. Mums pavyko sumažinti testavimo iteracijų skaičių. Dėl to, kad automatiniai testai yra parašyti naujoms funkcijoms, analitikai ir ne visą darbo dieną dirbantys bandytojai gauna aukštesnės kokybės kodą, nes tai jau patikrinta.
4. Dalį automatinio testavimo patobulinimų naudoja kūrėjai. Pavyzdžiui, bandomieji konteinerių duomenys sukuriami naudojant objektų generavimo modulį.
5. Svarbu, kad sukūrėme kūrėjų automatizuoto testavimo sistemos „priėmimą“. Yra supratimas, kad tai svarbu ir naudinga. Ir iš savo patirties galiu pasakyti, kad taip toli gražu. Autotestus reikia rašyti, juos prižiūrėti ir plėtoti, analizuoti rezultatus, o dažnai šios laiko sąnaudos tiesiog neapsimoka. Daug lengviau eiti į gamybą ir ten spręsti problemas. Mūsų šalyje kūrėjai rikiuojasi į eilę ir prašo savo funkcionalumą padengti automatiniais testais.

Kas toliau?

Pakalbėkime apie automatizuoto testavimo projekto plėtros planus.

Žinoma, kol „Sportmaster“ lojalumo sistema gyvuoja ir toliau vystosi, automatinius testus taip pat galima kurti beveik be galo. Todėl pagrindinė plėtros kryptis yra aprėpties ploto išplėtimas.

Didėjant automatinių testų skaičiui, bendras jų darbo laikas nuolat didės, ir vėl teks grįžti prie atlikimo klausimo. Labiausiai tikėtina, kad sprendimas bus padidinti lygiagrečių gijų skaičių.

Tačiau tai akivaizdūs vystymosi būdai. Jei kalbame apie kažką nereikšmingesnio, pabrėžiame šiuos dalykus:

1. Dabar automatiniai testai valdomi DBVS lygiu, t.y. sėkmingam darbui reikalingos PL/SQL žinios. Jei reikia, sistemos valdymą (pavyzdžiui, metaduomenų paleidimą ar kūrimą) gali pašalinti koks nors administratoriaus skydelis naudojant Jenkins ar kažką panašaus.
2. Kiekvienas mėgsta kiekybinius ir kokybinius rodiklius. Automatiniam testavimui toks universalus indikatorius yra Code Coverage arba kodo aprėpties metrika. Naudodami šį rodiklį galime nustatyti, kiek procentų mūsų testuojamos sistemos kodo yra padengta automatiniais testais. Pradedant nuo 12.2 versijos, „Oracle“ suteikia galimybę apskaičiuoti šią metriką ir siūlo naudoti standartinį DBMS_PLSQL_CODE_COVERAGE paketą.

   Mūsų automatinio testavimo sistema veikia kiek daugiau nei metus ir gali būti laikas įvertinti aprėptį. Mano paskutiniame projekte (projektas ne „Sportmaster“) taip atsitiko. Praėjus metams po darbo su automatiniais testais, vadovybė iškėlė užduotį įvertinti, kiek procentų kodo apėmėme. Jei aprėptis daugiau nei 1%, vadovybė būtų patenkinta. Mes, kūrėjai, tikėjomės rezultato apie 10 proc. Susukome kodo aprėptį, išmatavome, gavome 20 proc. Norėdami pasidžiaugti, važiavome dėl apdovanojimo, bet kaip ir kur ėjome vėliau – visai kita istorija.

3. Automatiniai testai gali išbandyti atviras žiniatinklio paslaugas. „Oracle“ leidžia tai padaryti, ir mes nebesusidursime su daugybe problemų.
4. Ir, žinoma, mūsų automatizuota testavimo sistema gali būti pritaikyta kitam projektui. Sprendimas, kurį gavome, yra universalus ir reikalauja naudoti tik „Oracle“. Girdėjau, kad yra susidomėjimas automatizuotu testavimu kituose „Sportmaster“ projektuose ir, galbūt, eisime į juos.

išvados

Pakartokime. „Sportmaster“ lojalumo sistemos projekte mums pavyko įdiegti automatizuotą testavimo sistemą. Jo pagrindas yra Stepheno Feuersteino utPLSQL sprendimas. Aplink utPLSQL yra automatinių testų ir pagalbinių savarankiškai parašytų modulių kodas: paleidimo priemonė, duomenų generavimo modulis ir kt. Automatiniai testai vykdomi kasdien ir, svarbiausia, veikia ir duoda naudos. Esame įsitikinę, kad pradėjome išleisti aukštesnės kokybės programinę įrangą. Tuo pačiu metu gautas sprendimas yra universalus ir gali būti laisvai pritaikytas bet kokiam projektui, kur reikia organizuoti automatizuotą Oracle DBVS testavimą.

PS Šis straipsnis pasirodė nelabai konkretus: daug teksto, o techninių pavyzdžių praktiškai nėra. Jei tema pasauliniu mastu įdomi, esame pasirengę ją tęsti ir grįžti su tęsiniu, kuriame papasakosime, kas pasikeitė per pastaruosius šešis mėnesius, ir pateiksime kodų pavyzdžių.

Rašykite komentarus, jei yra dalykų, kuriuos reikėtų pabrėžti ateityje, arba klausimų, kuriuos reikia atskleisti.

Apklausoje gali dalyvauti tik registruoti vartotojai. Prisijungti, Prašau.

Ar parašysime plačiau apie tai?

• Taip, žinoma

• Ne, ačiū

Balsavo 12 vartotojų. 4 vartotojai susilaikė.

Šaltinis: www.habr.com