Hei Habr!
Nimeni on Maxim Ponomarenko ja olen kehittäjä Sportmasterilla. Minulla on 10 vuoden kokemus IT-alalta. Hän aloitti uransa manuaalisessa testauksessa, jonka jälkeen hän siirtyi tietokantakehitykseen. Viimeiset 4 vuotta olen testauksesta ja kehityksestä saatua tietoa kerryttänyt automatisoinut testausta DBMS-tasolla.
Olen ollut Sportmaster-tiimissä reilun vuoden ja kehitän automatisoitua testausta yhdessä isoimmista projekteista. Huhtikuussa Sportmaster Labin kaverit ja minä puhuimme konferenssissa Krasnodarissa. Raporttini oli nimeltään "Yksikkötestit DBMS:ssä", ja nyt haluan jakaa sen kanssasi. Tekstiä tulee olemaan paljon, joten päätin jakaa raportin kahteen viestiin. Ensimmäisessä puhumme autotesteistä ja testauksesta yleensä, ja toisessa käsittelen tarkemmin yksikkötestausjärjestelmäämme ja sen soveltamisen tuloksia.
Ensinnäkin vähän tylsä teoria. Mitä on automaattinen testaus? Tämä on ohjelmistojen avulla suoritettavaa testausta, jota nykyaikaisessa IT:ssä käytetään yhä enemmän ohjelmistokehityksessä. Tämä johtuu siitä, että yritykset kasvavat, niiden tietojärjestelmät kasvavat ja vastaavasti testattavan toiminnallisuuden määrä kasvaa. Manuaalisten testausten tekeminen on yhä kalliimpaa.
Työskentelin suuressa yrityksessä, jonka julkaisut ilmestyvät kahden kuukauden välein. Samaan aikaan kului kokonainen kuukausi siihen, että kymmenkunta testaajaa tarkastaa toimivuuden manuaalisesti. Pienen kehittäjäryhmän automaation käyttöönoton ansiosta pystyimme lyhentämään testausajan 2 viikkoon puolessatoista vuodessa. Emme ole vain lisänneet testausta, vaan myös parantaneet sen laatua. Automaattiset testit käynnistetään säännöllisesti ja ne suorittavat aina koko niihin sisältyvän tarkastuksen, eli jätämme pois inhimillisen tekijän.
Nykyaikaiselle IT:lle on ominaista se, että kehittäjää voidaan vaatia paitsi tuotekoodin kirjoittamiseen, myös yksikkötestien kirjoittamiseen, jotka tarkistavat tämän koodin.
Mutta entä jos järjestelmäsi perustuu ensisijaisesti palvelinlogiikkaan? Markkinoilla ei ole universaalia ratkaisua tai parhaita käytäntöjä. Yleensä yritykset ratkaisevat tämän ongelman luomalla oman itsekirjoitetun testausjärjestelmän. Tämä on oma itse kirjoitettu automatisoitu testausjärjestelmämme, joka on luotu projektissamme ja kerron siitä raportissani.
Testaa uskollisuutta
Puhutaanpa ensin projektista, jossa otimme käyttöön automaattisen testausjärjestelmän. Projektimme on Sportmaster-uskollisuusjärjestelmä (muuten, kirjoitimme siitä jo vuonna ).
Jos yrityksesi on tarpeeksi suuri, kanta-asiakasjärjestelmälläsi on kolme vakioominaisuutta:
- Järjestelmäsi on erittäin kuormitettu
- Järjestelmäsi sisältää monimutkaisia laskentaprosesseja
- Järjestelmääsi parannetaan aktiivisesti.
Mennään järjestyksessä... Yhteensä, jos huomioidaan kaikki Sportmaster-merkit, niin meillä on yli 1000 myymälää Venäjällä, Ukrainassa, Kiinassa, Kazakstanissa ja Valko-Venäjällä. Näissä myymälöissä tehdään päivittäin noin 300 000 ostosta. Eli joka toinen 3-4 tarkastusta tulee järjestelmäämme. Luonnollisesti kanta-asiakasjärjestelmämme on erittäin kuormitettu. Ja koska sitä käytetään aktiivisesti, meidän on tarjottava sen korkeimmat laatuvaatimukset, koska kaikki ohjelmiston virheet merkitsevät suuria raha-, maine- ja muita menetyksiä.
Samaan aikaan Sportmasterilla on yli sata erilaista kampanjaa. Kampanjoita on monenlaisia: on tuotetarjouksia, on viikonpäivälle omistettuja, on tiettyyn kauppaan sidottuja, on tarjouksia kuitin summalle, on tavaroiden lukumäärälle. Yleisesti ottaen ei paha. Asiakkailla on bonuksia ja tarjouskoodeja, joita käytetään ostoksia tehdessään. Kaikki tämä johtaa siihen, että minkä tahansa tilauksen laskeminen on erittäin ei-triviaali tehtävä.
Algoritmi, joka toteuttaa tilausten käsittelyn, on todella kauhea ja monimutkainen. Ja kaikki muutokset tähän algoritmiin ovat melko riskialttiita. Näytti siltä, että kaikkein merkityksettömimmätkin muutokset voisivat johtaa varsin arvaamattomiin seurauksiin. Mutta juuri tällaiset monimutkaiset laskentaprosessit, erityisesti kriittisiä toimintoja toteuttavat, ovat parhaita automaatioehdokkaita. Kymmenien samankaltaisten tapausten tarkistaminen käsin on erittäin aikaa vievää. Ja koska prosessin aloituskohta on muuttumaton, voit kuvata sen kerran, voit nopeasti luoda automaattisia testejä ja olla varma, että toiminnallisuus toimii.
Koska järjestelmämme on aktiivisessa käytössä, yritys haluaa sinulta jotain uutta, elää ajan kanssa ja on asiakaslähtöistä. Kanta-asiakasjärjestelmässämme julkaisut ilmestyvät kahden kuukauden välein. Tämä tarkoittaa, että kahden kuukauden välein meidän on suoritettava koko järjestelmän täydellinen regressio. Samaan aikaan, kuten missä tahansa nykyaikaisessa IT:ssä, kehitys ei luonnollisesti siirry heti kehittäjältä tuotantoon. Se syntyy kehittäjän piiriltä, kulkee sitten peräkkäin testipenkin läpi, vapautetaan, hyväksytään ja vasta sitten päätyy tuotantoon. Testaus- ja vapautuspiireissä meidän on vähintään suoritettava koko järjestelmän täydellinen regressio.
Kuvatut ominaisuudet ovat vakiona lähes kaikissa kanta-asiakasjärjestelmissä. Puhutaanpa projektimme ominaisuuksista.
Teknisesti 90 % kanta-asiakasjärjestelmämme logiikasta on palvelinpohjaista ja toteutettu Oraclessa. Delphissä on esillä asiakas, joka suorittaa automatisoidun työpaikan ylläpitäjän tehtävää. Ulkoisille sovelluksille (esimerkiksi verkkosivustolle) on esillä verkkopalveluita. Siksi on hyvin loogista, että jos otamme käyttöön automatisoidun testausjärjestelmän, teemme sen Oraclessa.
Sportmasterin kanta-asiakasjärjestelmä on ollut olemassa yli 7 vuotta ja sen ovat luoneet yksittäiset kehittäjät... Keskimääräinen kehittäjien määrä projektissamme näiden 7 vuoden aikana oli 3-4 henkilöä. Mutta viimeisen vuoden aikana tiimimme on kasvanut merkittävästi, ja nyt projektissa työskentelee 10 henkilöä. Eli projektiin tulee ihmisiä, jotka eivät tunne tyypillisiä tehtäviä, prosesseja ja arkkitehtuuria. Ja on lisääntynyt riski, että jäämme huomaamatta virheitä.
Hankkeelle on ominaista, että henkilöstöyksikköinä ei ole erityisiä testaajia. Testausta toki on, mutta testaamista tekevät analyytikot muiden päätehtäviensä lisäksi: kommunikointi yritysasiakkaiden, käyttäjien kanssa, järjestelmävaatimusten kehittäminen jne. jne... Huolimatta siitä, että testaus tehdään erittäin laadukkaasti (tämä on erityisen sopivaa mainita, koska jotkut analyytikot saattavat jäädä tämän raportin silmään), erikoistumisen ja yhteen asiaan keskittymisen tehokkuutta ei ole peruutettu .
Kaikki edellä mainitut asiat huomioon ottaen, toimitetun tuotteen laadun parantamiseksi ja kehitysajan lyhentämiseksi, ajatus projektin testauksen automatisoinnista vaikuttaa erittäin loogiselta. Ja kanta-asiakasjärjestelmän olemassaolon eri vaiheissa yksittäiset kehittäjät pyrkivät peittämään koodinsa yksikkötesteillä. Kaiken kaikkiaan se oli melko hajanainen prosessi, jossa jokainen käytti omaa arkkitehtuuriaan ja menetelmiään. Lopputulokset olivat yhteisiä yksikkötesteille: testejä kehitettiin, käytettiin jonkin aikaa, tallennettiin versioidulle tiedostovarasolle, mutta jossain vaiheessa ne lakkasivat toimimasta ja unohdettiin. Ensinnäkin tämä johtui siitä, että testit sidottiin enemmän tiettyyn esiintyjään, eivät projektiin.
utPLSQL tulee apuun
Tiedätkö mitään Stephen Feuersteinista?
Tämä on älykäs kaveri, joka omisti pitkän osan urastaan Oraclen ja PL/SQL:n kanssa työskentelemiseen ja on kirjoittanut melkoisen määrän teoksia tästä aiheesta. Yksi hänen kuuluisista kirjoistaan on nimeltään "Oracle PL/SQL. Ammattilaisille." Stephen kehitti utPLSQL-ratkaisun tai, kuten se tarkoittaa, Unit Testing -kehyksen Oracle PL/SQL:lle. utPLSQL-ratkaisu luotiin vuonna 2016, mutta sen parissa työskennellään edelleen aktiivisesti ja uusia versioita julkaistaan. Raportointihetkellä viimeisin versio on 24.
Mikä se on. Tämä on erillinen avoimen lähdekoodin projekti. Se painaa pari megatavua sisältäen esimerkit ja asiakirjat. Fyysisesti se on erillinen skeema ORACLE-tietokannassa, jossa on joukko paketteja ja taulukoita yksikkötestauksen järjestämiseen. Asennus kestää muutaman sekunnin. utPLSQL:n erottuva piirre on sen helppokäyttöisyys.
Globaalisti utPLSQL on yksikkötestien suorittamisen mekanismi, jossa yksikkötestillä tarkoitetaan tavallisia Oraclen eräproseduureja, joiden organisointi noudattaa tiettyjä sääntöjä. Käynnistyksen lisäksi utPLSQL tallentaa lokin kaikista testiajoistasi, ja sillä on myös sisäinen raportointijärjestelmä.
Katsotaanpa esimerkkiä siitä, miltä tällä tekniikalla toteutettu yksikkötestikoodi näyttää.
Joten näytöllä näkyy koodi tyypilliselle pakettimäärittelylle yksikkötesteillä. Mitkä ovat pakolliset vaatimukset? Paketin etuliitteenä on oltava "utp_". Kaikilla testeillä varustetuilla toimenpiteillä on oltava täsmälleen sama etuliite. Paketin tulee sisältää kaksi vakiomenettelyä: "utp_setup" ja "utp_teardown". Ensimmäinen toimenpide kutsutaan käynnistämällä jokainen yksikkötesti uudelleen, toinen - käynnistämisen jälkeen.
"utp_setup" yleensä valmistelee järjestelmämme suorittamaan yksikkötestin, esimerkiksi luomaan testitietoja. "utp_teardown" - päinvastoin, kaikki palaa alkuperäisiin asetuksiin ja nollaa käynnistystulokset.
Tässä on esimerkki yksinkertaisimmasta yksikkötestistä, joka tarkistaa syötetyn asiakkaan puhelinnumeron normalisoitumisen kanta-asiakasjärjestelmämme vakiolomakkeeseen. Ei ole olemassa pakollisia standardeja menettelytapojen kirjoittamiselle yksikkötesteillä. Pääsääntöisesti kutsutaan testattavan järjestelmän menetelmä ja tämän menetelmän palauttamaa tulosta verrataan referenssiin. On tärkeää, että vertailutuloksen ja saadun tuloksen vertailu tapahtuu tavallisilla utPLSQL-menetelmillä.
Yksikkötestissä voi olla mikä tahansa määrä tarkistuksia. Kuten esimerkistä voidaan nähdä, soitamme neljä peräkkäistä puhelua testattuun menetelmään normalisoidaksemme puhelinnumeron ja arvioidaksemme tuloksen jokaisen puhelun jälkeen. Yksikkötestiä kehitettäessä tulee ottaa huomioon, että on olemassa tarkistuksia, jotka eivät vaikuta järjestelmään millään tavalla ja joidenkin jälkeen on palattava järjestelmän alkuperäiseen tilaan.
Esitetyssä yksikkötestissä esimerkiksi muotoilemme yksinkertaisesti syötetyn puhelinnumeron, mikä ei vaikuta kanta-asiakasjärjestelmään millään tavalla.
Ja jos kirjoitamme yksikkötestejä uuden asiakkaan luomismenetelmällä, jokaisen testin jälkeen järjestelmään luodaan uusi asiakas, joka voi vaikuttaa testin myöhempään käynnistämiseen.
Näin ajetaan yksikkötestejä. Käynnistysvaihtoehtoja on kaksi: kaikkien yksikkötestien suorittaminen tietystä paketista tai tietyn yksikkötestin suorittaminen tietyssä paketissa.
Tältä näyttää esimerkki sisäisestä raportointijärjestelmästä. Yksikkötestin tulosten perusteella utPLSQL rakentaa pienen raportin. Siinä näemme kunkin yksittäisen tarkastuksen tuloksen ja yksikkötestin kokonaistuloksen.
6 automaattitestien sääntöä
Ennen uuden järjestelmän luomista kanta-asiakasjärjestelmän automatisoituun testaukseen määritimme yhdessä johdon kanssa periaatteet, joita tulevissa automatisoiduissa testeissämme tulee noudattaa.
- Automaattisten testien on oltava tehokkaita ja hyödyllisiä. Meillä on upeita kehittäjiä, jotka on ehdottomasti mainittava, koska jotkut heistä todennäköisesti näkevät tämän raportin ja he kirjoittavat upeaa koodia. Mutta edes heidän upea koodinsa ei ole täydellinen ja sisältää, sisältää ja tulee edelleen sisältämään virheitä. Automaattiset testit vaaditaan näiden virheiden löytämiseksi. Jos näin ei ole, joko kirjoitamme huonoja automaattitestejä tai olemme tulleet kuolleelle alueelle, jota periaatteessa ei kehitetä. Molemmissa tapauksissa teemme jotain väärin, eikä lähestymistapamme yksinkertaisesti ole järkevä.
- Automaattitestejä tulee käyttää. Ei ole järkevää käyttää paljon aikaa ja vaivaa ohjelmistotuotteen kirjoittamiseen, sijoittamiseen arkistoon ja unohtamiseen. Testit tulee suorittaa ja suorittaa mahdollisimman säännöllisesti.
- Automaattisten testien pitäisi toimia vakaasti. Kellonajasta, laukaisutelineestä ja muista järjestelmäasetuksista riippumatta testiajojen pitäisi johtaa samaan tulokseen. Pääsääntöisesti tämä varmistetaan sillä, että automaattiset testit toimivat erityisten testitietojen kanssa, joissa on kiinteät järjestelmäasetukset.
- Automaattisten testien tulisi toimia projektillesi hyväksyttävällä nopeudella. Tämä aika määräytyy jokaiselle järjestelmälle erikseen. Joillakin ihmisillä on varaa työskennellä koko päivän, kun taas toisten mielestä on tärkeää tehdä se sekunneissa. Kerron teille vähän myöhemmin, mitkä nopeusstandardit saavutimme projektissamme.
- Automaattisen testin kehityksen tulee olla joustavaa. Ei ole suositeltavaa kieltäytyä testaamasta mitään toimintoja vain siksi, että emme ole tehneet sitä aiemmin tai jostain muusta syystä. utPLSQL ei rajoita kehitystä, ja Oracle mahdollistaa periaatteessa monenlaisten asioiden toteuttamisen. Useimpiin ongelmiin on ratkaisu, se on vain ajan ja vaivan kysymys.
- Käyttöönotto. Meillä on useita osastoja, joissa meidän on suoritettava testejä. Jokaisessa osastossa datavedos voidaan päivittää milloin tahansa. Projekti on suoritettava automaattisilla testeillä siten, että voit suorittaa sen täydellisen tai osittaisen asennuksen kivuttomasti.
Ja toisessa postauksessa parin päivän päästä kerron mitä teimme ja mitä tuloksia saavutimme.
Lähde: will.com