Yksikkötestit DBMS:ssä – miten se tehdään Sportmasterissa, osa kaksi

Ensimmäinen osa - täällä.

Kuvittele tilanne. Sinulla on tehtävänä kehittää uusia toimintoja. Sinulla on kehitystä edeltäjiisi verrattuna. Jos oletamme, että sinulla ei ole moraalisia velvollisuuksia, mitä tekisit?

Useimmiten kaikki vanhat kehitystyöt unohdetaan ja kaikki alkaa alusta. Kukaan ei halua kaivaa jonkun toisen koodiin, mutta jos sinulla on aikaa, miksi et aloittaisi oman järjestelmän luominen? Tämä on tyypillinen lähestymistapa, ja se on pitkälti oikea. Mutta projektissamme teimme sen väärin. Perustimme tulevan automaattisen testausjärjestelmän edeltäjiemme utPLSQL:n yksikkötestien kehitykseen ja menimme sitten töihin useisiin rinnakkaisiin suuntiin.

1. Vanhojen yksikkötestien palauttaminen. Palauttaminen tarkoittaa testien mukauttamista kanta-asiakasjärjestelmän nykyiseen tilaan ja testien mukauttamista utPLSQL-standardeihin.
2. Ongelman ratkaiseminen ymmärtämällä, mitä tarkalleen, mitä menetelmiä ja prosesseja autotesteillä katetaan. Sinun on joko pidettävä nämä tiedot päässäsi tai tehtävä johtopäätökset suoraan automaattisen testikoodin perusteella. Siksi päätimme luoda luettelon. Määritimme jokaiselle automaattitestille yksilöllisen muistikoodin, loimme kuvauksen ja tallensimme asetukset (esimerkiksi millaisissa olosuhteissa se pitäisi käynnistää tai mitä pitäisi tapahtua, jos testikäynnistys epäonnistuu). Pohjimmiltaan täytimme automaattisten testien metatiedot ja sijoitimme metatiedot tavallisiin utPLSQL-skeemataulukoihin.
3. Laajentumisstrategian määritteleminen, ts. toimintojen valinta, jotka tarkistetaan automaattisilla testeillä. Päätimme kiinnittää huomiota kolmeen asiaan: uudet järjestelmäparannukset, tuotantohäiriöt ja keskeiset järjestelmäprosessit. Kehitämme siis julkaisun rinnalla varmistaen sen korkeamman laadun, samalla laajentaen regression kattavuutta ja varmistaen järjestelmän luotettavuuden kriittisissä paikoissa. Ensimmäinen tällainen pullonkaula oli alennusten ja bonusten jakaminen sekillä.
4. Luonnollisesti aloimme kehittää uusia autotestejä. Yksi ensimmäisistä julkaisutehtävistä oli arvioida kanta-asiakasjärjestelmän ennalta määritettyjen näytteiden suorituskykyä. Projektissamme on lohko tiukasti kiinnitettyjä SQL-kyselyitä, jotka valitsevat asiakkaat ehtojen perusteella. Saat esimerkiksi luettelon kaikista asiakkaista, joiden viimeisin ostos teki tietystä kaupungista, tai luettelon asiakkaista, joiden keskimääräinen ostosumma ylittää tietyn arvon. Kirjoitettujen automaattisten testien jälkeen tarkistimme ennalta määritellyt näytteet, kirjasimme benchmark-suorituskykyparametrit ja lisäksi meillä oli kuormitustestaus.
5. Automaattisten testien kanssa työskentelyn pitäisi olla kätevää. Kaksi yleisintä toimintoa ovat automaattisten testien suorittaminen ja testitietojen luominen. Näin järjestelmäämme ilmestyi kaksi apumoduulia: käynnistysmoduuli ja tiedontuotantomoduuli.

   Kantoraketti on esitetty yhtenä yleisenä menettelynä, jossa on yksi tekstinsyöttöparametri. Parametrina voit välittää automaattisen testin muistokoodin, paketin nimen, testin nimen, automaattisen testin asetuksen tai varatun avainsanan. Toimenpide valitsee ja suorittaa kaikki ehdot täyttävät automaattiset testit.

   Tiedon generointimoduuli esitetään pakettina, jossa jokaiselle testattavan järjestelmän objektille (tietokannassa oleva taulukko) on luotu erityinen proseduuri, joka lisää sinne tietoja. Tässä menettelyssä oletusarvot täytetään niin paljon kuin mahdollista, mikä varmistaa objektien luomisen kirjaimellisesti sormen napsautuksella. Ja käytön helpottamiseksi luoduille tiedoille luotiin malleja. Luo esimerkiksi tietyn ikäinen asiakas testipuhelimella ja tehdyllä ostolla.

6. Automaattisten testien tulisi käynnistyä ja suorittaa järjestelmällesi hyväksyttävässä ajassa. Tästä syystä järjestettiin päivittäinen yölanseeraus, jonka tulosten perusteella laaditaan raportti tuloksista ja lähetetään koko kehitystiimille yrityspostina. Vanhojen automaattisten testien palauttamisen ja uusien luomisen jälkeen kokonaiskäyttöaika oli 30 minuuttia. Tämä esitys sopi kaikille, sillä lanseeraus tapahtui työajan ulkopuolella.

   Mutta meidän piti työskennellä optimoidaksemme työn nopeuden. Tuotannossa oleva kanta-asiakasjärjestelmä päivitetään yöllä. Osana yhtä julkaisua jouduimme tekemään kiireellisiä muutoksia yöllä. Puolen tunnin odotus automaattisten testien tuloksiin kello kolmelta aamuyöllä ei ilahduttanut julkaisusta vastuussa olevaa henkilöä (kiihkeät terveiset Aleksei Vasjukoville!), ja seuraavana aamuna järjestelmäämme kohtaan sanottiin paljon ystävällisiä sanoja. Mutta tuloksena syntyi 5 minuutin standardi työlle.

   Suorituksen nopeuttamiseksi käytimme kahta tapaa: automaattiset testit alkoivat suorittaa kolmessa rinnakkaisessa säikeessä, onneksi tämä on erittäin kätevää kanta-asiakasjärjestelmämme arkkitehtuurin vuoksi. Ja hylättiin lähestymistapa, jossa autotesti ei luo itse testidataa, vaan yrittää löytää järjestelmästä jotain sopivaa. Muutosten tekemisen jälkeen kokonaiskäyttöaika lyheni 3-4 minuuttiin.

7. Automaattisten testien projektia pitäisi pystyä toteuttamaan eri osastoilla. Matkamme alussa yritettiin kirjoittaa omia erätiedostoja, mutta kävi selväksi, että itse kirjoitettu automatisoitu asennus oli täyttä kauhua, ja käännyimme kohti teollisia ratkaisuja. Koska projekti sisältää paljon suoraa koodia (ensinkin tallennamme autotestin koodin) ja hyvin vähän dataa (päätieto on metadataa autotesteistä), toteutus Liquibase-projektissa osoittautui hyvin yksinkertaiseksi.

   Se on avoimen lähdekoodin tietokannasta riippumaton kirjasto tietokantaskeeman muutosten seurantaan, hallintaan ja täytäntöönpanoon. Hallitaan komentorivillä tai kehyksillä, kuten Apache Maven. Liquibasen toimintaperiaate on melko yksinkertainen. Meillä on tietyllä tavalla organisoitu projekti, joka koostuu muutoksista tai skripteistä, jotka on rullattava kohdepalvelimelle, ja ohjaustiedostoista, jotka määrittävät missä järjestyksessä ja millä parametreilla nämä muutokset tulee asentaa.

   DBMS-tasolla luodaan erityinen taulukko, johon Liquibase tallentaa rollover-lokin. Jokaisella muutoksella on laskettu hajautusarvo, jota verrataan joka kerta projektin ja tietokannan tilan välillä. Liquibasen ansiosta voimme helposti toteuttaa muutoksia järjestelmäämme mihin tahansa piiriin. Automaattiset testit käynnistetään nyt testi- ja vapautuspiireissä sekä konteissa (kehittäjien henkilökohtaiset piirit).

Puhutaanpa siis yksikkötestausjärjestelmämme käytön tuloksista.

1. Tietenkin ensinnäkin olemme vakuuttuneita siitä, että olemme alkaneet kehittää parempia ohjelmistoja. Automaattiset testit käynnistetään päivittäin ja jokaisesta julkaisusta löytyy kymmeniä virheitä. Lisäksi jotkut näistä virheistä liittyvät vain epäsuorasti toimintoihin, joita todella halusimme muuttaa. On vakavia epäilyksiä siitä, että nämä virheet löydettiin manuaalisella testauksella.
2. Tiimi luottaa nyt siihen, että tietyt toiminnot toimivat oikein... Ensinnäkin tämä koskee kriittisiä prosessejamme. Esimerkiksi viimeisen kuuden kuukauden aikana julkaisumuutoksista huolimatta meillä ei ole ollut ongelmia kuittien alennusten ja bonusten jakamisessa, vaikka aikaisemmilla jaksoilla virheitä esiintyi jonkin verran.
3. Onnistuimme vähentämään testausiteraatioiden määrää. Koska automaattitestit on kirjoitettu uusia toimintoja varten, analyytikot ja osa-aikaiset testaajat saavat laadukkaampaa koodia, koska se on jo tarkastettu.
4. Kehittäjät käyttävät osaa automatisoidun testauksen kehityksestä. Esimerkiksi testidata säilöistä luodaan käyttämällä objektin luontimoduulia.
5. On tärkeää, että olemme kehittäneet automatisoidun testausjärjestelmän "hyväksynnän" kehittäjien puolelta. Ymmärretään, että tämä on tärkeää ja hyödyllistä. Mutta omasta kokemuksestani voin sanoa, että tämä ei ole kaukana siitä. Automaattitestit on kirjoitettava, niitä on tuettava ja kehitettävä, tuloksia on analysoitava, ja usein nämä aikakustannukset eivät yksinkertaisesti ole sen arvoisia. On paljon helpompaa siirtyä tuotantoon ja käsitellä siellä ongelmia. Täällä kehittäjät asettuvat jonoon ja pyytävät meitä peittämään heidän toiminnallisuutensa automaattisilla testeillä.

Mitä seuraavaksi

Puhutaan automatisoidun testausprojektin kehityssuunnitelmista.

Tietysti niin kauan kuin Sportmasterin kanta-asiakasjärjestelmä elää ja kehittyy, on myös mahdollista kehittää autotestejä lähes loputtomasti. Siksi pääasiallinen kehityssuunta on peittoalueen laajentaminen.

Automaattisten testien määrän kasvaessa niiden kokonaiskäyttöaika kasvaa tasaisesti, ja meidän on jälleen palattava suorituskykykysymykseen. Todennäköisesti ratkaisu on lisätä rinnakkaisten lankojen määrää.

Mutta nämä ovat ilmeisiä kehitystapoja. Jos puhumme jostakin ei-triviaalimmasta, korostamme seuraavaa:

1. Tällä hetkellä automaattitestien hallintaa suoritetaan DBMS-tasolla, ts. Onnistunut työ edellyttää PL/SQL:n tuntemusta. Tarvittaessa järjestelmän hallinta (esim. käynnistäminen tai metatietojen luominen), voit luoda jonkinlaisen hallintapaneelin Jenkinsin tai vastaavan avulla.
2. Kaikki rakastavat määrällisiä ja laadullisia indikaattoreita. Automaattista testausta varten tällainen yleinen indikaattori on Code Coverage tai koodin peittometriikka. Tämän indikaattorin avulla voimme määrittää, kuinka suuri prosenttiosuus testattavan järjestelmämme koodista on automaattisten testien kattamia. Versiosta 12.2 alkaen Oracle tarjoaa mahdollisuuden laskea tämä mittari ja tarjoaa standardinmukaisen DBMS_PLSQL_CODE_COVERAGE-paketin käytön.

   Automaattinen testijärjestelmämme on hieman yli vuoden vanha ja nyt on ehkä aika arvioida kattavuuttamme. Viimeisessä projektissani (ei Sportmaster-projektissa) kävi näin. Vuosi autotestien parissa työskentelyn jälkeen johto asetti tehtäväksi arvioida, kuinka monta prosenttia koodista katamme. Jos kattavuus on yli 1%, johto olisi tyytyväinen. Me, kehittäjät, odotimme tulokseksi noin 10 %. Asensimme koodipeiton, mittasimme sen ja saimme 20 %. Juhlan kunniaksi menimme hakemaan palkintoa, mutta miten menimme hakemaan sitä ja minne menimme myöhemmin, on täysin eri tarina.

3. Automaattiset testit voivat tarkistaa esillä olevat verkkopalvelut. Oracle antaa meille mahdollisuuden tehdä tämä melko hyvin, emmekä kohtaa enää useita ongelmia.
4. Ja tietysti automaattista testausjärjestelmäämme voidaan soveltaa toiseen projektiin. Saamamme ratkaisu on universaali ja vaatii vain Oraclen käytön. Kuulin, että muut Sportmaster-projektit ovat kiinnostuneita automaattisesta testauksesta ja ehkä mennään niihin.

Tulokset

Tehdään yhteenveto. Sportmasterin kanta-asiakasjärjestelmäprojektissa onnistuimme ottamaan käyttöön automaattisen testausjärjestelmän. Se perustuu Stephen Feuersteinin utPLSQL-ratkaisuun. utPLSQL:n ympärillä on automaattitestikoodia ja itse kirjoitettuja apumoduuleja: käynnistysmoduuli, tiedontuotantomoduuli ja muut. Automaattitestejä käynnistetään päivittäin, ja mikä tärkeintä, ne toimivat ja ovat hyödyllisiä. Olemme varmoja, että olemme alkaneet julkaista korkealaatuisempia ohjelmistoja. Samaan aikaan tuloksena oleva ratkaisu on universaali ja sitä voidaan soveltaa vapaasti kaikkiin projekteihin, joissa on tarpeen järjestää automaattinen testaus Oracle DBMS:lle.

PS Tämä artikkeli ei ole kovin tarkka: siinä on paljon tekstiä ja käytännössä ei teknisiä esimerkkejä. Jos aihe on yleisesti kiinnostava, niin olemme valmiita jatkamaan sitä ja palaamaan jatkoon, jossa kerromme, mikä on muuttunut viimeisen puolen vuoden aikana ja annamme koodiesimerkkejä.

Kirjoita kommentteja, jos on kohtia, joita tulisi korostaa tulevaisuudessa, tai kysymyksiä, jotka vaativat julkistamista.

Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. Kirjaudu sisään, ole kiltti.

Kirjoitetaanko tästä lisää?

• Kyllä tietysti

• Ei kiitos

12 käyttäjää äänesti. 4 käyttäjää pidättyi äänestämästä.

Lähde: will.com