Enhedstest i et DBMS - hvordan gør vi det i Sportmaster, del to

Første del - her.

Forestil dig en situation. Du står over for opgaven med at udvikle ny funktionalitet. Du har erfaring fra dine forgængere. Hvis du antager, at du ikke har nogen moralske forpligtelser, hvad ville du så gøre?

Oftest bliver alle de gamle udviklinger glemt, og alt starter forfra. Ingen kan lide at grave i andres kode, og hvis du har tid, hvorfor så ikke begynde at skabe dit eget system? Dette er en typisk tilgang, og den er i mange henseender korrekt. Men i vores projekt handlede vi anderledes. Vi baserede det fremtidige automatiserede testsystem på udviklingen i enhedstest på utPLSQL fra vores forgængere, og gik derefter i gang i flere parallelle retninger.

1. Gendannelse af gamle enhedstests. Gendannelse betyder tilpasning af tests til loyalitetssystemets eksisterende tilstand og tilpasning af test til utPLSQL-standarder.
2. Løsning af problemet med forståelse, og hvad præcist, hvilke metoder og processer, har vi dækket med autotest. Du skal enten holde denne information i dit hoved eller drage konklusioner baseret direkte på autotestens kode. Derfor besluttede vi at lave et katalog. Vi tildelte en unik mnemonisk kode til hver autotest, oprettede en beskrivelse og rettede indstillingerne (for eksempel under hvilke forhold den skulle køres, eller hvad der skulle ske, hvis testkørslen mislykkedes). I det væsentlige udfyldte vi metadataene om autotestene og placerede disse metadata i standardtabellerne i utPLSQL-skemaet.
3. Definition af ekspansionsstrategi, dvs. valg af funktionalitet, der er underlagt verifikation ved autotest. Vi besluttede at være opmærksomme på tre ting: nye forbedringer af systemet, hændelser fra produktionen og nøgleprocesser i systemet. Således udvikler vi parallelt med udgivelsen, sikrer dens højere kvalitet, udvider samtidig omfanget af regression og sikrer systemets pålidelighed på kritiske steder. Den første sådanne flaskehals var processen med at fordele rabatter og bonusser med check.
4. Naturligvis begyndte vi at udvikle nye autotests. En af de første udgivelsesopgaver var at evaluere ydeevnen af ​​foruddefinerede prøver af loyalitetssystemet. Vores projekt har en blok af stift faste sql-forespørgsler, der udvælger klienter efter betingelser. Få for eksempel en liste over alle kunder, hvis sidste køb var i en bestemt by, eller en liste over kunder, hvis gennemsnitlige købsbeløb er over en bestemt værdi. Efter at have skrevet autotest, tjekkede vi foruddefinerede prøver, faste benchmark-ydeevneparametre, og derudover fik vi belastningstest.
5. Det skal være praktisk at arbejde med autotest. De to mest almindelige handlinger er at køre autotest og generere testdata. Sådan opstod to hjælpemoduler i vores system: startmodulet og datagenereringsmodulet.

   Starteren er repræsenteret som én generisk procedure med én inputtekstparameter. Som en parameter kan du sende en autotest mnemonisk kode, pakkenavn, testnavn, autotestindstilling eller et reserveret nøgleord. Proceduren udvælger og kører alle autotest, der opfylder betingelserne.

   Datagenereringsmodulet præsenteres som en pakke, hvori der for hvert objekt i systemet under test (en tabel i databasen) er oprettet en speciel procedure, der indsætter data der. I denne procedure er standardværdierne udfyldt til det maksimale, hvilket sikrer oprettelsen af ​​objekter bogstaveligt talt med et klik med en finger. Og for at lette brugen blev der oprettet skabeloner til de genererede data. Opret for eksempel en klient i en bestemt alder med en testtelefon og et gennemført køb.

6. Autotest skal køre og køre inden for en rimelig tid for dit system. Derfor blev der tilrettelagt en daglig natlancering, baseret på resultaterne, der genereres en rapport om resultaterne og sendes til hele udviklingsteamet med virksomhedens post. Efter gendannelse af gamle autotest og oprettelse af nye, var den samlede køretid 30 minutter. Sådan en forestilling passede alle, da lanceringen fandt sted i frikvarteret.

   Men vi skulle arbejde på at optimere arbejdshastigheden. Produktionsloyalitetssystemet opdateres om natten. Som en del af en af ​​udgivelserne var vi nødsaget til at lave ændringer om natten. En halv times ventetid på resultaterne af autotests klokken tre om morgenen gjorde ikke den ansvarlige for udgivelsen glad (glødende hilsner til Alexei Vasyukov!), Og næste morgen blev der sagt en masse varme ord til vores system. Men som et resultat blev der sat en 5-minutters standard for arbejde.

   For at fremskynde ydeevnen brugte vi to metoder: Vi begyndte at køre autotests i tre parallelle tråde, da dette er meget praktisk på grund af arkitekturen i vores loyalitetssystem. Og vi forlod tilgangen, når autotesten ikke skaber testdata for sig selv, men forsøger at finde noget passende i systemet. Efter ændringer blev den samlede driftstid reduceret til 3-4 minutter.

7. Et projekt med autotest bør kunne indsættes på forskellige stande. I begyndelsen af ​​rejsen var der forsøg på at skrive vores egne batchfiler, men det blev klart, at en selvskrevet automatiseret installation er en komplet rædsel, og vi vendte os mod industrielle løsninger. På grund af det faktum, at projektet har meget kode direkte (først og fremmest gemmer vi koden for autotest) og meget lidt data (hoveddataene er metadata om autotest), viste det sig at være meget nemt at integrere i Liquibase projekt.

   Det er et open source-databaseuafhængigt bibliotek til sporing, styring og anvendelse af databaseskemaændringer. Administreret via kommandolinje eller rammer som Apache Maven. Funktionsprincippet for Liquibase er ret simpelt. Vi har et projekt organiseret på en bestemt måde, som består af ændringer eller scripts, der skal rulles ind på målserveren, og kontrolfiler, der bestemmer i hvilken rækkefølge og med hvilke parametre disse ændringer skal installeres.

   På DBMS-niveau oprettes en speciel tabel, hvori Liquibase gemmer rollback-loggen. Hver ændring har en beregnet hash, der sammenlignes hver gang mellem projektet og tilstanden i databasen. Takket være Liquibase kan vi nemt udrulle ændringer til vores system til ethvert kredsløb. Autotests køres nu på test- og release-loops, samt på containere (udviklernes personlige loops).

Så lad os tale om resultaterne af at anvende vores enhedstestsystem.

1. Selvfølgelig er vi først og fremmest overbeviste om, at vi begyndte at udvikle bedre software. Autotests kører dagligt og finder snesevis af fejl hver udgivelse. Desuden er nogle af disse fejl kun indirekte relateret til den funktionalitet, som vi virkelig ønskede at ændre. Der er stor tvivl om, at disse fejl blev fundet ved manuel test.
2. Teamet fik tillid til, at specifik funktionalitet fungerer korrekt... Først og fremmest handler det om vores kritiske processer. For eksempel har vi i løbet af de sidste seks måneder ikke haft problemer med fordelingen af ​​rabatter og bonusser med check, på trods af ændringerne foretaget hver udgivelse, selvom der i tidligere perioder opstod fejl med en vis hyppighed
3. Vi formåede at reducere antallet af testiterationer. På grund af det faktum, at autotest er skrevet til ny funktionalitet, får analytikere og deltidstestere en kode af højere kvalitet, pga. det er allerede blevet bekræftet.
4. En del af udviklingen af ​​automatiseret test bruges af udviklere. For eksempel oprettes testdata på containere ved hjælp af objektgenereringsmodulet.
5. Det er vigtigt, at vi har udviklet en "accept" af det automatiserede testsystem af udviklere. Der er en forståelse for, at dette er vigtigt og nyttigt. Og af egen erfaring kan jeg sige, at det langt fra er tilfældet. Autotests skal skrives, de skal vedligeholdes og udvikles, resultaterne analyseres, og ofte er disse tidsomkostninger simpelthen ikke det værd. Det er meget nemmere at gå til produktion og håndtere problemer der. I vores land stiller udviklere op og beder om at dække deres funktionalitet med autotest.

Hvad er næste

Lad os tale om udviklingsplanerne for det automatiserede testprojekt.

Så længe Sportmaster loyalitetssystemet er i live og fortsætter med at udvikle sig, kan autotest naturligvis også udvikles næsten uendeligt. Derfor er den primære udviklingsretning udvidelsen af ​​dækningsområdet.

Efterhånden som antallet af autotest stiger, vil den samlede tid af deres arbejde støt stige, og vi bliver igen nødt til at vende tilbage til spørgsmålet om ydeevne. Mest sandsynligt vil løsningen være at øge antallet af parallelle tråde.

Men det er åbenlyse måder at udvikle sig på. Hvis vi taler om noget mere ikke-trivielt, fremhæver vi følgende:

1. Nu styres autotests på DBMS-niveau, dvs. kendskab til PL/SQL er nødvendig for succesfuldt arbejde. Hvis det er nødvendigt, kan systemstyring (f.eks. lancering eller oprettelse af metadata) tages ud af en form for adminpanel ved hjælp af Jenkins eller noget lignende.
2. Alle elsker kvantitative og kvalitative indikatorer. Til automatisk test er en sådan universel indikator kodedækning eller kodedækningsmetrik. Ved hjælp af denne indikator kan vi bestemme, hvor stor en procentdel af koden på vores system, der testes, der er dækket af autotest. Fra version 12.2 giver Oracle mulighed for at beregne denne metrik og foreslår at bruge standardpakken DBMS_PLSQL_CODE_COVERAGE.

   Vores autotestsystem er lidt over et år gammelt, og det er måske tid til at evaluere dækningen. I mit sidste projekt (et projekt ikke af Sportmaster) skete dette. Et år efter arbejdet med autotest satte ledelsen opgaven med at vurdere, hvor stor en procentdel af koden vi dækkede. Med mere end 1 % dækning ville ledelsen være glad. Vi, udviklerne, forventede et resultat på omkring 10%. Vi skruede op for kodedækningen, målte den, fik 20 %. For at fejre det gik vi efter prisen, men hvordan vi gik efter det, og hvor vi gik hen senere, er en helt anden historie.

3. Autotest kan teste eksponerede webtjenester. Oracle giver dig mulighed for at gøre dette, og vi vil ikke længere støde på en række problemer.
4. Og selvfølgelig kan vores automatiserede testsystem anvendes til et andet projekt. Den løsning, vi modtog, er universel og kræver kun brug af Oracle. Jeg hørte, at der er interesse for automatiseret test på andre Sportmaster-projekter, og måske vil vi gå til dem.

Fund

Lad os opsummere. På loyalitetssystemprojektet i Sportmaster lykkedes det os at implementere et automatiseret testsystem. Dens grundlag er utPLSQL-løsningen fra Stephen Feuerstein. Omkring utPLSQL er koden til autotests og selvskrevne hjælpemoduler: en launcher, et datagenereringsmodul og andre. Autotests kører dagligt og, vigtigst af alt, arbejde og gavn. Vi er overbeviste om, at vi er begyndt at frigive software af højere kvalitet. Samtidig er den resulterende løsning universel og kan frit anvendes på ethvert projekt, hvor det er nødvendigt at organisere automatiseret test på Oracle DBMS.

PS Denne artikel viste sig ikke at være særlig specifik: der er meget tekst og praktisk talt ingen tekniske eksempler. Hvis emnet er globalt interessant, så er vi klar til at fortsætte det og vende tilbage med en fortsættelse, hvor vi fortæller, hvad der har ændret sig det seneste halve år og giver kodeeksempler.

Skriv kommentarer, hvis der er punkter, der bør fremhæves i fremtiden, eller spørgsmål, der kræver afsløring.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, Vær venlig.

Skal vi skrive mere om dette?

• Ja selvfølgelig

• Nej tak

12 brugere stemte. 4 brugere undlod at stemme.

Kilde: www.habr.com