Haai Habr!
My naam is Maxim Ponomarenko en ek is 'n ontwikkelaar by Sportmaster. Ek het 10 jaar ondervinding in die IT veld. Hy het sy loopbaan in handtoetsing begin en toe oorgeskakel na databasisontwikkeling. Vir die afgelope 4 jaar, met die opbou van die kennis wat in toetsing en ontwikkeling opgedoen is, het ek toetsing op die DBMS-vlak outomatiseer.
Ek is al net meer as 'n jaar in die Sportmaster-span en is besig om outomatiese toetse vir een van die groot projekte te ontwikkel. In April het ek en die ouens van Sportmaster Lab by 'n konferensie in Krasnodar gepraat, my verslag is genoem "Eenheidtoetse in 'n DBBS," en nou wil ek dit met julle deel. Daar sal baie teks wees, so ek het besluit om die berig in twee plasings te verdeel. In die eerste sal ons praat oor outotoetse en toetsing in die algemeen, en in die tweede sal ek in meer besonderhede stilstaan by ons eenheidstoetsstelsel en die resultate van die toepassing daarvan.
Eerstens 'n bietjie vervelige teorie. Wat is outomatiese toetsing? Dit is toetsing wat met sagteware uitgevoer word, en in moderne IT word dit toenemend in sagteware-ontwikkeling gebruik. Dit is te wyte aan die feit dat maatskappye groei, hul inligtingstelsels groei en gevolglik groei die hoeveelheid funksionaliteit wat getoets moet word. Om handtoetse uit te voer word al hoe duurder.
Ek het vir 'n groot maatskappy gewerk wie se vrystellings elke twee maande uitkom. Terselfdertyd is 'n hele maand daaraan bestee om 'n dosyn toetsers die funksionaliteit handmatig te laat kontroleer. Danksy die implementering van outomatisering deur 'n klein span ontwikkelaars, kon ons die toetstyd tot 2 weke in 'n jaar en 'n half verminder. Ons het nie net die spoed van toetsing verhoog nie, maar ook die kwaliteit daarvan verbeter. Outomatiese toetse word gereeld van stapel gestuur en hulle voer altyd die hele verloop van tjeks uit wat daarby ingesluit is, dit wil sê, ons sluit die menslike faktor uit.
Moderne IT word gekenmerk deur die feit dat daar dalk van 'n ontwikkelaar vereis word om nie net produkkode te skryf nie, maar ook om eenheidstoetse te skryf wat hierdie kode kontroleer.
Maar wat as u stelsel hoofsaaklik op bedienerlogika gebaseer is? Daar is geen universele oplossing of beste praktyke op die mark nie. As 'n reël los maatskappye hierdie probleem op deur hul eie selfgeskrewe toetsstelsel te skep. Dit is ons eie selfgeskrewe outomatiese toetsstelsel wat op ons projek geskep is en ek sal daaroor in my verslag praat.
Toets lojaliteit
Kom ons praat eers oor die projek waar ons 'n outomatiese toetsstelsel ontplooi het. Ons projek is die Sportmaster-lojaliteitstelsel (terloops, ons het reeds daaroor geskryf in ).
As jou maatskappy groot genoeg is, sal jou lojaliteitstelsel drie standaard eienskappe hê:
- Jou stelsel sal hoogs gelaai wees
- Jou stelsel sal komplekse rekenaarprosesse bevat
- Jou stelsel sal aktief verbeter word.
Kom ons gaan in volgorde... In totaal, as ons alle Sportmaster-handelsmerke in ag neem, dan het ons meer as 1000 winkels in Rusland, Oekraïne, China, Kazakhstan en Wit-Rusland. Sowat 300 000 aankope word elke dag in dié winkels gedoen. Dit wil sê, elke tweede 3-4 tjeks betree ons stelsel. Natuurlik is ons lojaliteitstelsel hoogs gelaai. En aangesien dit aktief gebruik word, moet ons die hoogste standaarde van sy kwaliteit verskaf, want enige fout in die sagteware beteken groot geldelike, reputasie- en ander verliese.
Terselfdertyd hou Sportmaster meer as honderd verskillende promosies. Daar is 'n verskeidenheid promosies: daar is produkpromosies, daar is dié wat aan die dag van die week toegewy is, daar is dié wat aan 'n spesifieke winkel gekoppel is, daar is promosies vir die bedrag van die kwitansie, daar is vir die aantal goedere. Oor die algemeen nie sleg nie. Kliënte het bonusse en promosiekodes wat gebruik word wanneer aankope gedoen word. Dit alles lei daartoe dat die berekening van enige bestelling 'n baie nie-triviale taak is.
Die algoritme wat bestellingsverwerking implementeer, is werklik verskriklik en ingewikkeld. En enige veranderinge aan hierdie algoritme is nogal riskant. Dit het gelyk of die mees oënskynlik onbeduidende veranderinge tot redelik onvoorspelbare effekte kan lei. Maar dit is juis sulke komplekse rekenaarprosesse, veral dié wat kritieke funksionaliteit implementeer, wat die beste kandidate vir outomatisering is. Dit is baie tydrowend om tientalle soortgelyke gevalle met die hand na te gaan. En aangesien die toegangspunt tot die proses onveranderd is, nadat u dit een keer beskryf het, kan u vinnig outomatiese toetse skep en vol vertroue wees dat die funksionaliteit sal werk.
Aangesien ons stelsel aktief gebruik word, sal die besigheid iets nuuts van jou wil hê, met die tyd saamleef en kliëntgerig wees. In ons lojaliteitstelsel kom vrystellings elke twee maande uit. Dit beteken dat ons elke twee maande 'n volledige regressie van die hele stelsel moet uitvoer. Terselfdertyd, natuurlik, soos in enige moderne IT, gaan ontwikkeling nie dadelik van die ontwikkelaar na produksie nie. Dit ontstaan op die ontwikkelaar se kring, gaan dan agtereenvolgens deur die toetsbank, vrystelling, aanvaarding, en beland dan eers in produksie. Op 'n minimum, op die toets- en vrystellingkringe, moet ons 'n volledige regressie van die hele stelsel uitvoer.
Die beskryfde eiendomme is standaard vir byna enige lojaliteitstelsel. Kom ons praat oor die kenmerke van ons projek.
Tegnologies is 90% van die logika van ons lojaliteitstelsel bedienergebaseerd en op Oracle geïmplementeer. Daar is 'n kliënt blootgestel in Delphi, wat die funksie van 'n outomatiese werkplek administrateur verrig. Daar is blootgestelde webdienste vir eksterne toepassings (byvoorbeeld 'n webwerf). Daarom is dit baie logies dat as ons 'n outomatiese toetsstelsel ontplooi, ons dit op Oracle sal doen.
Die lojaliteitstelsel in Sportmaster bestaan al meer as 7 jaar en is geskep deur enkele ontwikkelaars... Die gemiddelde aantal ontwikkelaars op ons projek gedurende hierdie 7 jaar was 3-4 mense. Maar oor die afgelope jaar het ons span aansienlik gegroei, en nou is daar 10 mense wat aan die projek werk. Dit wil sê, mense kom na die projek wat nie vertroud is met tipiese take, prosesse en argitektuur nie. En daar is 'n groter risiko dat ons foute sal mis.
Die projek word gekenmerk deur die afwesigheid van toegewyde toetsers as personeeleenhede. Daar is natuurlik toetsing, maar toetsing word deur ontleders uitgevoer, benewens hul ander hoofverantwoordelikhede: kommunikasie met besigheidskliënte, gebruikers, die ontwikkeling van stelselvereistes, ens. ens... Ten spyte van die feit dat toetsing van baie hoë gehalte uitgevoer word (dit is veral gepas om op te noem, aangesien sommige van die ontleders die oog van hierdie verslag kan vang), is die doeltreffendheid van spesialisasie en konsentrasie op een ding nie gekanselleer nie .
Met inagneming van al die bogenoemde, om die kwaliteit van die gelewerde produk te verbeter en ontwikkelingstyd te verminder, lyk die idee om toetse op 'n projek te outomatiseer baie logies. En in verskillende stadiums van die lojaliteitstelsel se bestaan het individuele ontwikkelaars pogings aangewend om hul kode met eenheidstoetse te dek. Oor die algemeen was dit 'n redelik onsamehangende proses, met almal wat hul eie argitektuur en metodes gebruik het. Die finale resultate was algemeen vir eenheidstoetse: toetse is ontwikkel, gebruik vir 'n geruime tyd, gestoor in 'n weergawe van lêerberging, maar op 'n stadium het hulle opgehou loop en is vergeet. Eerstens was dit te wyte aan die feit dat die toetse meer aan 'n spesifieke presteerder gekoppel was, en nie aan die projek nie.
utPLSQL kom tot die redding
Weet jy iets van Stephen Feuerstein?
Dit is 'n slim ou wat 'n lang deel van sy loopbaan daaraan gewy het om met Oracle en PL/SQL te werk, en het 'n hele aantal werke oor hierdie onderwerp geskryf. Een van sy bekende boeke heet: “Oracle PL/SQL. Vir professionele persone." Dit was Stephen wat die utPLSQL-oplossing ontwikkel het, of, soos dit staan vir, Unit Testing-raamwerk vir Oracle PL/SQL. Die utPLSQL-oplossing is in 2016 geskep, maar daar word steeds aktief daaraan gewerk en nuwe weergawes word vrygestel. Ten tyde van verslagdoening dateer die jongste weergawe terug na 24 Maart 2019.
Wat is dit. Dit is 'n aparte oopbronprojek. Dit weeg 'n paar megagrepe, insluitend voorbeelde en dokumentasie. Fisies is dit 'n aparte skema in die ORACLE-databasis met 'n stel pakkette en tabelle om eenheidstoetse te organiseer. Installasie neem 'n paar sekondes. 'N Kenmerkende kenmerk van utPLSQL is die gebruiksgemak daarvan.
Wêreldwyd is utPLSQL 'n meganisme om eenheidstoetse uit te voer, waar 'n eenheidstoets verstaan word as gewone Oracle-joernaalprosedures, waarvan die organisasie sekere reëls volg. Benewens die bekendstelling, stoor utPLSQL 'n logboek van al jou toetslopies, en het ook 'n interne verslagdoeningstelsel.
Kom ons kyk na 'n voorbeeld van hoe die eenheidstoetskode lyk, geïmplementeer met behulp van hierdie tegniek.
Dus, die skerm wys die kode vir 'n tipiese pakketspesifikasie met eenheidstoetse. Wat is die verpligte vereistes? Die pakkie moet voorafgaan met "utp_". Alle prosedures met toetse moet presies dieselfde voorvoegsel hê. Die pakket moet twee standaardprosedures bevat: "utp_setup" en "utp_teardown". Die eerste prosedure word aangeroep deur elke eenheidstoets weer te begin, die tweede - na bekendstelling.
"utp_setup", as 'n reël, berei ons stelsel voor om 'n eenheidstoets uit te voer, byvoorbeeld om toetsdata te skep. "utp_teardown" - inteendeel, alles keer terug na die oorspronklike instellings en stel die bekendstellingsresultate terug.
Hier is 'n voorbeeld van die eenvoudigste eenheidstoets wat die normalisering van die ingevoerde kliëntfoonnommer na die standaardvorm vir ons lojaliteitstelsel nagaan. Daar is geen verpligte standaarde oor hoe om prosedures met eenheidstoetse te skryf nie. As 'n reël word 'n oproep gemaak na 'n metode van die stelsel wat getoets word, en die resultaat wat deur hierdie metode teruggestuur word, word vergelyk met die verwysing een. Dit is belangrik dat die vergelyking van die verwysingsresultaat en die verkry een deur middel van standaard utPLSQL-metodes geskied.
'n Eenheidstoets kan enige aantal tjeks hê. Soos uit die voorbeeld gesien kan word, maak ons vier opeenvolgende oproepe na die getoetste metode om die telefoonnommer te normaliseer en die resultaat na elke oproep te evalueer. Wanneer jy 'n eenheidstoets ontwikkel, moet jy in ag neem dat daar tjeks is wat nie die stelsel op enige manier beïnvloed nie, en na 'n paar moet jy terugrol na die oorspronklike toestand van die stelsel.
Byvoorbeeld, in die aangebied eenheidstoets formateer ons eenvoudig die invoerfoonnommer, wat geensins die lojaliteitstelsel beïnvloed nie.
En as ons eenheidstoetse skryf met die metode om 'n nuwe kliënt te skep, sal daar na elke toets 'n nuwe kliënt in die stelsel geskep word, wat die daaropvolgende bekendstelling van die toets kan beïnvloed.
Dit is hoe eenheidstoetse uitgevoer word. Daar is twee moontlike bekendstellingsopsies: hardloop alle eenheidstoetse vanaf 'n spesifieke pakket of hardloop 'n spesifieke eenheidstoets in 'n spesifieke pakket.
Dit is hoe 'n voorbeeld van 'n interne verslagdoeningstelsel lyk. Gebaseer op die resultate van die eenheidstoets, bou utPLSQL 'n klein verslag. Daarin sien ons die resultaat vir elke spesifieke tjek en die algehele resultaat van die eenheidstoets.
6 reëls van outotoetse
Voordat ons begin om 'n nuwe stelsel vir outomatiese toetsing van die lojaliteitstelsel te skep, het ons saam met bestuur die beginsels bepaal waaraan ons toekomstige outomatiese toetse moet voldoen.
- Outotoetse moet effektief wees en moet nuttig wees. Ons het wonderlike ontwikkelaars wat beslis genoem moet word, want sommige van hulle sal waarskynlik hierdie verslag sien, en hulle skryf wonderlike kode. Maar selfs hul wonderlike kode is nie perfek nie en het, het en sal aanhou om foute te bevat. Outotoetse word vereis om hierdie foute te vind. As dit nie die geval is nie, dan skryf ons óf slegte outotoetse, óf ons het by 'n dooie area gekom wat in beginsel nie ontwikkel word nie. In albei gevalle doen ons iets verkeerd, en ons benadering maak eenvoudig nie sin nie.
- Outotoetse moet gebruik word. Dit maak geen sin om baie tyd en moeite te spandeer om 'n sagtewareproduk te skryf, dit in 'n bewaarplek te plaas en dit te vergeet nie. Toetse moet uitgevoer word en so gereeld as moontlik uitgevoer word.
- Outotoetse moet stabiel werk. Ongeag die tyd van die dag, lanseerstaander en ander stelselinstellings, moet toetslopies tot dieselfde resultaat lei. As 'n reël word dit verseker deur die feit dat outotoetse werk met spesiale toetsdata met vaste stelselinstellings.
- Outotoetse moet teen 'n spoed werk wat aanvaarbaar is vir jou projek. Hierdie tyd word individueel vir elke stelsel bepaal. Sommige mense kan bekostig om heeldag te werk, terwyl ander dit van kritieke belang vind om dit binne sekondes te doen. Ek sal jou 'n bietjie later vertel watter spoedstandaarde ons in ons projek bereik het.
- Outotoetsontwikkeling moet buigsaam wees. Dit is nie raadsaam om te weier om enige funksionaliteit te toets bloot omdat ons dit nie voorheen gedoen het nie of om een of ander rede. utPLSQL stel geen beperkings op ontwikkeling nie, en Oracle laat jou in beginsel toe om 'n verskeidenheid dinge te implementeer. Die meeste probleme het 'n oplossing, dit is net 'n kwessie van tyd en moeite.
- Ontplooibaarheid. Ons het verskeie staanplekke waar ons toetse moet uitvoer. By elke staanplek kan 'n datastorting enige tyd opgedateer word. Dit is nodig om 'n projek met outomatiese toetse op so 'n manier uit te voer dat u die volledige of gedeeltelike installasie daarvan pynloos kan uitvoer.
En in die tweede pos oor 'n paar dae sal ek jou vertel wat ons gedoen het en watter resultate ons bereik het.
Bron: will.com