Enhetstester i et DBMS – hvordan gjør vi det i Sportmaster, del to

Første del - her.

Forestill deg situasjonen. Du står overfor oppgaven med å utvikle ny funksjonalitet. Du har utviklinger fra dine forgjengere. Hvis vi antar at du ikke har noen moralske forpliktelser, hva ville du gjort?

Oftest blir alle de gamle utviklingene glemt og alt begynner på nytt. Ingen liker å grave i andres kode, men hvis du har tid, hvorfor ikke begynne å lage ditt eget system? Dette er en typisk tilnærming, og den er stort sett riktig. Men i prosjektet vårt gjorde vi det feil. Vi baserte det fremtidige automatiske testsystemet på utviklingen innen enhetstester på utPLSQL fra våre forgjengere, og gikk deretter i gang i flere parallelle retninger.

1. Gjenopprette gamle enhetstester. Gjenoppretting betyr å tilpasse tester til den eksisterende tilstanden til lojalitetssystemet og tilpasse tester til utPLSQL-standarder.
2. Løse et problem med en forståelse av nøyaktig hva, hvilke metoder og prosesser som dekkes med autotester. Du må enten holde denne informasjonen i hodet, eller trekke konklusjoner basert direkte på autotestkoden. Derfor bestemte vi oss for å lage en katalog. Vi tildelte en unik mnemonisk kode til hver autotest, laget en beskrivelse og registrerte innstillinger (for eksempel under hvilke forhold den skal startes, eller hva som skal skje hvis teststarten mislykkes). I hovedsak fylte vi ut metadataene om autotestene og plasserte disse metadataene i standard utPLSQL-skjematabeller.
3. Definere ekspansjonsstrategien, dvs. valg av funksjonalitet som er gjenstand for verifisering av automatiserte tester. Vi bestemte oss for å ta hensyn til tre ting: nye systemforbedringer, produksjonshendelser og viktige systemprosesser. Dermed utvikler vi parallelt med utgivelsen, sikrer dens høyere kvalitet, utvider samtidig omfanget av regresjon og sikrer systemets pålitelighet på kritiske steder. Den første slike flaskehals var prosessen med å dele ut rabatter og bonuser på en sjekk.
4. Naturligvis begynte vi å utvikle nye autotester. En av de første utgivelsesoppgavene var å evaluere ytelsen til forhåndsdefinerte prøver av lojalitetssystemet. Prosjektet vårt har en blokk med stivt faste SQL-spørringer som velger klienter basert på forhold. Få for eksempel en liste over alle kunder hvis siste kjøp var i en bestemt by, eller en liste over kunder hvis gjennomsnittlige kjøpsbeløp er over en viss verdi. Etter å ha skrevet autotester, sjekket vi forhåndsdefinerte prøver, registrerte referanseytelsesparametere, og i tillegg hadde vi belastningstesting.
5. Det skal være praktisk å jobbe med autotester. De to vanligste handlingene er å kjøre autotester og lage testdata. Slik dukket det opp to hjelpemoduler i systemet vårt: en lanseringsmodul og en datagenereringsmodul.

   Startprogrammet er representert som én universell prosedyre med én tekstinndataparameter. Som en parameter kan du sende autotest mnemonisk kode, pakkenavn, testnavn, autotestinnstilling eller et reservert nøkkelord. Prosedyren velger og kjører alle autotester som tilfredsstiller betingelsene.

   Datagenereringsmodulen presenteres i form av en pakke der det for hvert objekt i systemet som testes (en tabell i databasen) er laget en spesiell prosedyre som setter inn data der. I denne prosedyren fylles standardverdiene så mye som mulig, noe som sikrer opprettelsen av objekter bokstavelig talt ved å klikke på en finger. Og for enkel bruk ble det laget maler for de genererte dataene. Lag for eksempel en klient i en viss alder med en testtelefon og et gjennomført kjøp.

6. Autotester bør starte og kjøre på en tid som er akseptabel for systemet ditt. Derfor ble det organisert en daglig nattlansering, basert på resultatene som en rapport om resultatene genereres og sendes til hele utviklingsteamet via bedriftspost. Etter å ha gjenopprettet gamle autotester og opprettet nye, var den totale driftstiden 30 minutter. Denne forestillingen passet alle, siden lanseringen fant sted utenom arbeidstid.

   Men vi måtte jobbe med å optimalisere arbeidshastigheten. Lojalitetssystemet i produksjon oppdateres om natten. Som en del av en av utgivelsene måtte vi gjøre akutte endringer om natten. Å vente en halvtime på resultatene av autotestene klokken tre om morgenen gjorde ikke den ansvarlige for utgivelsen glad (glødende hilsener til Alexey Vasyukov!), og neste morgen ble det sagt mange vennlige ord mot systemet vårt. Men som et resultat ble det etablert en 5-minutters standard for arbeid.

   For å øke ytelsen brukte vi to metoder: autotester begynte å kjøre i tre parallelle tråder, heldigvis er dette veldig praktisk på grunn av arkitekturen til lojalitetssystemet vårt. Og vi forlot tilnærmingen der autotesten ikke lager testdata for seg selv, men prøver å finne noe som passer i systemet. Etter endringene ble den totale driftstiden redusert til 3-4 minutter.

7. Et prosjekt med automatiske tester skal kunne utplasseres på ulike stands. I begynnelsen av reisen vår var det forsøk på å skrive våre egne batchfiler, men det ble klart at en selvskreven automatisert installasjon var full skrekk, og vi vendte oss mot industrielle løsninger. På grunn av det faktum at prosjektet inneholder mye direkte kode (først og fremst lagrer vi autotestkoden) og svært lite data (hoveddataene er metadata om autotester), viste implementeringen i Liquibase-prosjektet seg å være veldig enkel.

   Det er et åpen kildekode, databaseuavhengig bibliotek for sporing, administrasjon og håndheving av databaseskjemaendringer. Administrert via kommandolinjen eller rammeverk som Apache Maven. Prinsippet for drift av Liquibase er ganske enkelt. Vi har et prosjekt organisert på en bestemt måte, som består av endringer eller skript som må rulles ut til målserveren, og kontrollfiler som bestemmer i hvilken rekkefølge og med hvilke parametere disse endringene skal installeres.

   På DBMS-nivå opprettes en spesiell tabell der Liquibase lagrer rollover-loggen. Hver endring har en beregnet hash, som sammenlignes hver gang mellom prosjektet og tilstanden i databasen. Takket være Liquibase kan vi enkelt rulle ut endringer i systemet vårt til enhver krets. Autotester lanseres nå på test- og utgivelseskretser, så vel som på containere (utviklernes personlige kretser).

Så la oss snakke om resultatene av å bruke vårt enhetstestsystem.

1. For det første er vi selvfølgelig overbevist om at vi har begynt å utvikle bedre programvare. Autotester lanseres daglig og dusinvis av feil blir funnet hver utgivelse. Dessuten er noen av disse feilene bare indirekte relatert til funksjonaliteten vi virkelig ønsket å endre. Det er alvorlig tvil om at disse feilene ble funnet ved manuell testing.
2. Teamet har nå tillit til at spesifikk funksjonalitet fungerer som den skal... Først og fremst gjelder dette våre kritiske prosesser. For eksempel har vi de siste seks månedene ikke hatt noen problemer med distribusjon av rabatter og bonuser på kvitteringer, til tross for utgivelsesendringene, selv om det i tidligere perioder oppsto feil med en viss frekvens
3. Vi klarte å redusere antall testiterasjoner. På grunn av det faktum at autotester er skrevet for ny funksjonalitet, får analytikere og deltidstestere kode av høyere kvalitet, fordi det er allerede sjekket.
4. Noen av utviklingen innen automatisert testing brukes av utviklere. For eksempel opprettes testdata på containere ved hjelp av objektgenereringsmodulen.
5. Det er viktig at vi har utviklet en "aksept" av det automatiserte testsystemet fra utviklernes side. Det er en forståelse for at dette er viktig og nyttig. Men av egen erfaring kan jeg si at dette langt fra er tilfelle. Autotester må skrives, de må støttes og utvikles, resultatene må analyseres, og ofte er disse tidskostnadene rett og slett ikke verdt det. Det er mye lettere å gå til produksjon og håndtere problemer der. Her stiller utviklere opp og ber oss dekke funksjonaliteten deres med autotester.

Hva er neste

La oss snakke om utviklingsplanene for det automatiserte testprosjektet.

Selvfølgelig, så lenge Sportmasters lojalitetssystem er i live og fortsetter å utvikle seg, er det også mulig å utvikle autotester nesten uendelig. Derfor er hovedretningen for utvikling å utvide dekningsområdet.

Etter hvert som antallet autotester øker, vil deres totale driftstid øke jevnt, og vi må igjen gå tilbake til spørsmålet om ytelse. Mest sannsynlig vil løsningen være å øke antallet parallelle tråder.

Men dette er åpenbare måter å utvikle seg på. Hvis vi snakker om noe mer ikke-trivielt, fremhever vi følgende:

1. Foreløpig utføres autoteststyring på DBMS-nivå, dvs. kunnskap om PL/SQL er nødvendig for vellykket arbeid. Hvis det er nødvendig, systemadministrasjon (for eksempel lansering eller opprettelse av metadata), kan du lage et slags adminpanel ved å bruke Jenkins eller noe lignende.
2. Alle elsker kvantitative og kvalitative indikatorer. For automatisert testing er en slik universell indikator kodedekning eller kodedekningsberegning. Ved å bruke denne indikatoren kan vi bestemme hvor stor prosentandel av koden til systemet vårt som testes som dekkes av autotester. Fra og med versjon 12.2 gir Oracle muligheten til å beregne denne metrikken og tilbyr bruk av standard DBMS_PLSQL_CODE_COVERAGE-pakken.

   Vårt autotestsystem er litt over ett år gammelt, og kanskje nå er tiden inne for å evaluere dekningen vår. I mitt siste prosjekt (ikke et Sportmaster-prosjekt) var det dette som skjedde. Et år etter å ha jobbet med autotester, satte ledelsen i oppgave å vurdere hvor stor prosentandel av koden vi dekker. Med en dekning på mer enn 1 % ville ledelsen være fornøyd. Vi, utviklerne, forventet et resultat på rundt 10 %. Vi installerte kodedekning, målte den og fikk 20 %. For å feire gikk vi for å hente premien, men hvordan vi gikk for å få den og hvor vi gikk senere er en helt annen historie.

3. Autotester kan sjekke eksponerte webtjenester. Oracle lar oss gjøre dette ganske bra, og vi vil ikke lenger støte på en rekke problemer.
4. Og selvfølgelig kan vårt automatiserte testsystem brukes på et annet prosjekt. Løsningen vi mottok er universell og krever kun bruk av Oracle. Jeg hørte at andre Sportmaster-prosjekter er interessert i automatisk testing, og kanskje vi vil gå til dem.

Funn

La oss oppsummere. På lojalitetssystemprosjektet i Sportmaster klarte vi å implementere et automatisert testsystem. Den er basert på utPLSQL-løsningen fra Stephen Feuerstein. Rundt utPLSQL er det autotestkode og selvskrevne hjelpemoduler: lanseringsmodul, datagenereringsmodul og andre. Autotester lanseres daglig, og viktigst av alt, de fungerer og er nyttige. Vi er sikre på at vi har begynt å gi ut programvare av høyere kvalitet. Samtidig er den resulterende løsningen universell og kan fritt brukes på ethvert prosjekt der det er nødvendig å organisere automatisert testing på Oracle DBMS.

PS Denne artikkelen er ikke veldig spesifikk: det er mye tekst og praktisk talt ingen tekniske eksempler. Hvis emnet er generelt interessant, så er vi klare til å fortsette det og komme tilbake med en fortsettelse, der vi vil fortelle deg hva som har endret seg de siste seks månedene og gi kodeeksempler.

Skriv kommentarer hvis det er punkter som bør vektlegges i fremtiden, eller spørsmål som krever avsløring.

Kun registrerte brukere kan delta i undersøkelsen. Logg inn, vær så snill.

Skal vi skrive mer om dette?

• sikkert

• Nei takk

12 brukere stemte. 4 brukere avsto.

Kilde: www.habr.com