Hoi Habr!
Myn namme is Maxim Ponomarenko en ik bin in ûntwikkelder by Sportmaster. Ik haw 10 jier ûnderfining yn it IT-fjild. Hy begon syn karriêre yn manuele testen, en skeakele doe oer nei databaseûntwikkeling. Foar de lêste 4 jier, it sammeljen fan de kennis opdien yn testen en ûntwikkeling, haw ik testen automatisearre op it DBMS-nivo.
Ik haw krekt mear as in jier yn it Sportmaster-team west en bin it ûntwikkeljen fan automatisearre testen op ien fan 'e grutte projekten. Yn april sprieken de jonges fan Sportmaster Lab en ik op in konferinsje yn Krasnodar, myn rapport waard neamd "Ienheidstests yn in DBMS," en no wol ik it mei jo diele. Der sil in soad tekst wêze, dat ik besleat it rapport op te splitsen yn twa berjochten. Yn 'e earste sille wy prate oer autotests en testen yn' t algemien, en yn 'e twadde sil ik mear detaillearje oer ús ienheidstestsysteem en de resultaten fan har tapassing.
Earst, in bytsje saai teory. Wat is automatisearre testen? Dit is testen dy't wurdt útfierd troch software, en yn moderne IT wurdt it hieltyd mear brûkt yn softwareûntwikkeling. Dit komt troch it feit dat bedriuwen groeie, har ynformaasjesystemen groeie en dêrtroch groeit de hoemannichte funksjonaliteit dy't moat wurde hifke. It útfieren fan hânmjittich testen wurdt hieltyd djoerder.
Ik wurke foar in grut bedriuw wêrfan de releases elke twa moannen útkomme. Tagelyk waard in heule moanne bestege oan it hawwen fan in tsiental testers de funksjonaliteit manuell kontrolearje. Mei tank oan de ymplemintaasje fan automatisearring troch in lyts team fan ûntwikkelders, koenen wy de testtiid ferminderje nei 2 wiken yn in jier en in heal. Wy hawwe net allinich de snelheid fan testen ferhege, mar ek de kwaliteit ferbettere. Automatyske tests wurde regelmjittich lansearre en se fiere altyd de heule rin fan kontrôles út dy't yn har binne, dat is, wy slúte de minsklike faktor út.
Moderne IT wurdt karakterisearre troch it feit dat in ûntwikkelder net allinich ferplicht wurde om produktkoade te skriuwen, mar ek ienheidtests te skriuwen dy't dizze koade kontrolearje.
Mar wat as jo systeem primêr basearre is op serverlogika? D'r is gjin universele oplossing of bêste praktiken op 'e merke. As regel losse bedriuwen dit probleem op troch har eigen selsskreaune testsysteem te meitsjen. Dit is ús eigen selsskreaune automatisearre testsysteem dat is makke op ús projekt en ik sil der oer prate yn myn rapport.
Testing loyaliteit
Litte wy earst prate oer it projekt wêr't wy in automatisearre testsysteem hawwe ynset. Us projekt is it Sportmaster-loyaliteitssysteem (troch de manier, wy hawwe der al oer skreaun yn ).
As jo bedriuw grut genôch is, dan sil jo loyaliteitssysteem trije standert eigenskippen hawwe:
- Jo systeem sil heech laden wurde
- Jo systeem sil komplekse kompjûterprosessen befetsje
- Jo systeem wurdt aktyf ferbettere.
Litte wy yn oarder gean ... Yn totaal, as wy alle Sportmaster-merken beskôgje, dan hawwe wy mear as 1000 winkels yn Ruslân, Oekraïne, Sina, Kazachstan en Wyt-Ruslân. Yn dizze winkels wurde alle dagen sa'n 300 oankeapen dien. Dat is, elke twadde 000-3 kontrôles ynfiere ús systeem. Fansels is ús loyaliteitssysteem heech laden. En om't it aktyf brûkt wurdt, moatte wy de heechste noarmen fan har kwaliteit leverje, om't elke flater yn 'e software grutte monetêre, reputaasje en oare ferlies betsjut.
Tagelyk rint Sportmaster mear as hûndert ferskillende promoasjes. D'r binne in ferskaat oan promoasjes: d'r binne produktpromoasjes, d'r binne dyjingen dy't wijd binne oan 'e dei fan' e wike, d'r binne dyjingen dy't ferbûn binne oan in spesifike winkel, d'r binne promoasjes foar it bedrach fan 'e ûntfangst, d'r binne foar it oantal guod. Yn it algemien, net min. Klanten hawwe bonussen en promoasjekoades dy't wurde brûkt by it meitsjen fan oankeapen. Dit alles liedt ta it feit dat it berekkenjen fan elke bestelling in heul net-triviale taak is.
It algoritme dat oarderferwurking ymplementearret is wirklik ferskriklik en yngewikkeld. En alle wizigingen yn dit algoritme binne frij riskant. It like dat de meast skynber ûnbelangrike feroarings koenen liede ta frij ûnfoarspelbere effekten. Mar krekt sokke komplekse komputerprosessen, benammen dyjingen dy't krityske funksjonaliteit ymplementearje, binne de bêste kandidaten foar automatisearring. It kontrolearjen fan tsientallen ferlykbere gefallen mei de hân is heul tiidslinend. En om't it yngongspunt yn it proses net feroare is, nei't jo it ien kear beskreaun hawwe, kinne jo fluch automatyske testen meitsje en der wis fan wêze dat de funksjonaliteit sil wurkje.
Sûnt ús systeem wurdt aktyf brûkt, it bedriuw wol wat nijs fan jo, libje mei de tiid en wêze klant-rjochte. Yn ús loyaliteitssysteem komme releases elke twa moannen út. Dit betsjut dat wy elke twa moannen in folsleine regression fan it hiele systeem moatte útfiere. Tagelyk, fansels, lykas yn elke moderne IT, giet ûntwikkeling net fuortendaliks fan 'e ûntwikkelder nei produksje. It ûntstiet op it circuit fan 'e ûntwikkelder, giet dan opienfolgjend troch de testbank, frijlitting, akseptaasje, en einiget dan pas yn produksje. Op syn minst, op de test- en release circuits, wy moatte útfiere in folsleine regression fan it hiele systeem.
De beskreaune eigenskippen binne standert foar hast alle loyaliteit systeem. Litte wy prate oer de funksjes fan ús projekt.
Technologysk is 90% fan 'e logika fan ús loyaliteitssysteem server-basearre en ymplementearre op Oracle. D'r is in klant bleatsteld yn Delphi, dy't de funksje fan in automatisearre wurkplakbehearder útfiert. Der binne bleatstelde webtsjinsten foar eksterne applikaasjes (bygelyks in webside). Dêrom is it heul logysk dat as wy in automatisearre testsysteem ynsette, wy it op Oracle sille dwaan.
It loyaliteitssysteem yn Sportmaster bestiet al mear as 7 jier en is makke troch inkele ûntwikkelders ... It gemiddelde oantal ûntwikkelders op ús projekt yn dizze 7 jier wie 3-4 minsken. Mar it ôfrûne jier is ús team flink groeid, en no wurkje d'r 10 minsken oan it projekt. Dat is, minsken komme nei it projekt dy't net bekend binne mei typyske taken, prosessen en arsjitektuer. En d'r is in ferhege risiko dat wy flaters misse.
It projekt wurdt karakterisearre troch it ûntbrekken fan tawijde testers as personielsenheden. D'r is fansels testen, mar testen wurde útfierd troch analysten, neist har oare haadferantwurdlikheden: kommunisearje mei saaklike klanten, brûkers, ûntwikkeljen fan systeemeasken, ensfh. ensfh ... Nettsjinsteande it feit dat testen wurdt útfierd hiel hege kwaliteit (dit is benammen passend om te neamen, sûnt guon fan 'e analysts kinne fange it each fan dit rapport), de effektiviteit fan spesjalisaasje en konsintraasje op ien ding is net annulearre .
Sjoen al it boppesteande, om de kwaliteit fan it levere produkt te ferbetterjen en ûntwikkelingstiid te ferminderjen, liket it idee om testen op in projekt te automatisearjen heul logysk. En yn ferskate stadia fan it bestean fan it loyaliteitssysteem makken yndividuele ûntwikkelders ynspanningen om har koade te dekken mei ienheidstests. Oer it algemien wie it in frij disjoint proses, wêrby't elkenien har eigen arsjitektuer en metoaden brûkte. De definitive resultaten wiene mienskiplik foar ienheidtests: tests waarden ûntwikkele, brûkt foar in skoft, opslein yn in ferzje fan triem opslach, mar op in stuit stoppe se mei rinnen en waarden fergetten. Earst fan alles, dit wie te tankjen oan it feit dat de tests waarden bûn mear oan in spesifike performer, en net oan it projekt.
utPLSQL komt ta de rêding
Witte jo wat oer Stephen Feuerstein?
Dit is in tûke keardel dy't in lang diel fan syn karriêre wijde oan it wurkjen mei Oracle en PL/SQL, en hat nochal in grut oantal wurken oer dit ûnderwerp skreaun. Ien fan syn ferneamde boeken hjit: "Oracle PL/SQL. Foar professionals." It wie Stephen dy't de utPLSQL-oplossing ûntwikkele, of, sa't it stiet foar, Unit Testing framework foar Oracle PL/SQL. De utPLSQL-oplossing is makke yn 2016, mar der wurdt noch aktyf oan wurke en nije ferzjes wurde frijlitten. Op it momint fan rapportaazje datearret de lêste ferzje fan 24 maart 2019.
Wat is it. Dit is in apart iepen boarne projekt. It weaget in pear megabytes, ynklusyf foarbylden en dokumintaasje. Fysiek is it in apart skema yn 'e ORACLE-database mei in set pakketten en tabellen foar it organisearjen fan ienheidstesten. Ynstallaasje duorret in pear sekonden. In ûnderskiedend skaaimerk fan utPLSQL is it gemak fan gebrûk.
Globaal is utPLSQL in meganisme foar it útfieren fan ienheidstests, wêrby't in ienheidstest wurdt begrepen as gewoane Oracle-batchprosedueres, wêrfan de organisaasje bepaalde regels folget. Neist it lansearjen bewarret utPLSQL in logboek fan al jo testrinnen, en hat ek in ynterne rapportaazjesysteem.
Litte wy nei in foarbyld sjen fan hoe't de ienheidstestkoade derút sjocht, ymplementearre mei dizze technyk.
Dat, it skerm toant de koade foar in typyske pakketspesifikaasje mei ienheidstests. Wat binne de ferplichte easken? It pakket moat foarôfgeand wêze mei "utp_". Alle prosedueres mei tests moatte krekt itselde foarheaksel hawwe. It pakket moat twa standertprosedueres befetsje: "utp_setup" en "utp_teardown". De earste proseduere wurdt neamd troch it opnij starte fan elke ienheidstest, de twadde - nei lansearring.
"utp_setup", as regel, taret ús systeem op om in ienheidstest út te fieren, bygelyks it meitsjen fan testgegevens. "utp_teardown" - krekt oarsom, alles komt werom nei de orizjinele ynstellings en reset de startresultaten.
Hjir is in foarbyld fan 'e ienfâldichste ienheidstest dy't de normalisaasje fan it ynfierde telefoannûmer fan klant kontrolearret nei it standertformulier foar ús loyaliteitssysteem. D'r binne gjin ferplichte noarmen oer hoe't jo prosedueres skriuwe mei ienheidstests. As regel wurdt in oprop dien nei in metoade fan it testsysteem, en it resultaat weromjûn troch dizze metoade wurdt fergelike mei de referinsje. It is wichtich dat de fergeliking fan it referinsjeresultaat en it ferkrigen is fia standert utPLSQL-metoaden.
In ienheidstest kin elk oantal kontrôles hawwe. Lykas út it foarbyld kin wurde sjoen, meitsje wy fjouwer opienfolgjende oproppen nei de testmetoade om it tillefoannûmer te normalisearjen en it resultaat nei elke oprop te evaluearjen. By it ûntwikkeljen fan in ienheidstest moatte jo rekken hâlde dat d'r kontrôles binne dy't gjin ynfloed hawwe op it systeem op ien of oare manier, en nei guon moatte jo weromgean nei de oarspronklike steat fan it systeem.
Bygelyks, yn 'e presinteare ienheidstest formatearje wy gewoan it ynfiertillefoannûmer, dat op gjin inkelde manier ynfloed hat op it loyaliteitssysteem.
En as wy ienheidstests skriuwe mei de metoade foar it meitsjen fan in nije klant, dan sil nei elke test in nije klant yn it systeem oanmakke wurde, wat de folgjende start fan 'e test kin beynfloedzje.
Dit is hoe't ienheidstests wurde útfierd. D'r binne twa mooglike startopsjes: it útfieren fan alle ienheidstests út in spesifyk pakket of it útfieren fan in spesifike ienheidstest yn in spesifyk pakket.
Dit is hoe't in foarbyld fan in ynterne rapportaazjesysteem derút sjocht. Op grûn fan 'e resultaten fan' e ienheidstest bout utPLSQL in lyts rapport. Dêryn sjogge wy it resultaat foar elke spesifike kontrôle en it totale resultaat fan 'e ienheidstest.
6 regels fan autotests
Foardat wy begjinne mei it meitsjen fan in nij systeem foar automatisearre testen fan it loyaliteitssysteem, tegearre mei management, hawwe wy de prinsipes bepaald wêrmei ús takomstige automatisearre tests moatte foldwaan.
- Autotests moatte effektyf wêze en moatte nuttich wêze. Wy hawwe prachtige ûntwikkelders, dy't perfoarst neamd wurde moatte, om't guon fan harren dit rapport wierskynlik sille sjen, en se skriuwe prachtige koade. Mar sels harren prachtige koade is net perfekt en hat, hat, en sil bliuwe te befetsje flaters. Autotests binne nedich om dizze flaters te finen. As dit net it gefal is, dan skriuwe wy óf minne autotests, óf binne wy by in deade gebiet kommen dat yn prinsipe net ûntwikkele wurdt. Yn beide gefallen dogge wy wat ferkeard, en ús oanpak hat gewoan gjin sin.
- Autotests moatte brûkt wurde. It hat gjin sin om in protte tiid en muoite te besteegjen oan it skriuwen fan in softwareprodukt, it yn in repository pleatse en it ferjitte. Tests moatte wurde útfierd, en rinne sa regelmjittich mooglik.
- Autotests moatte stabyl wurkje. Nettsjinsteande de tiid fan 'e dei, lansearstand en oare systeemynstellingen, testruns moatte liede ta itselde resultaat. As regel wurdt dit garandearre troch it feit dat autotests wurkje mei spesjale testgegevens mei fêste systeemynstellingen.
- Autotests moatte wurkje mei in snelheid dy't akseptabel is foar jo projekt. Dizze tiid wurdt foar elk systeem yndividueel bepaald. Guon minsken kinne it betelje om de hiele dei te wurkjen, wylst oaren it kritysk fine om it yn sekonden te dwaan. Ik sil jo in bytsje letter fertelle hokker snelheidsnoarmen wy hawwe berikt yn ús projekt.
- Autotestûntwikkeling moat fleksibel wêze. It is net oan te rieden om te wegerjen om alle funksjonaliteit te testen gewoan om't wy it net earder dien hawwe of om ien of oare reden. utPLSQL stelt gjin beheiningen op foar ûntwikkeling, en Oracle lit jo yn prinsipe in ferskaat oan dingen útfiere. De measte problemen hawwe in oplossing, it is gewoan in kwestje fan tiid en muoite.
- Ynsetberens. Wy hawwe ferskate stands wêr't wy tests moatte útfiere. By elke stand kin op elk momint in gegevensdump bywurke wurde. It is needsaaklik om in projekt te fieren mei automatyske tests op sa'n manier dat jo de folsleine of foar in part fan 'e ynstallaasje pynlik kinne útfiere.
En yn 'e twadde post oer in pear dagen sil ik jo fertelle wat wy dien hawwe en hokker resultaten wy hawwe berikt.
Boarne: www.habr.com