Hej Habr!
Mit navn er Maxim Ponomarenko og jeg er udvikler hos Sportmaster. Jeg har 10 års erfaring indenfor IT-området. Han startede sin karriere inden for manuel test og skiftede derefter til databaseudvikling. I de sidste 4 år har jeg, med akkumulering af viden opnået inden for test og udvikling, automatiseret test på DBMS-niveau.
Jeg har været på Sportmaster-teamet i lidt over et år og er ved at udvikle automatiseret test på et af de store projekter. I april talte gutterne fra Sportmaster Lab og jeg til en konference i Krasnodar, min rapport hed "Enhedstest i et DBMS", og nu vil jeg dele den med jer. Der vil være meget tekst, så jeg besluttede at dele rapporten op i to indlæg. I den første vil vi tale om autotest og test generelt, og i den anden vil jeg dvæle mere detaljeret på vores enhedstestsystem og resultaterne af dets anvendelse.
Først en lidt kedelig teori. Hvad er automatiseret test? Dette er test, der udføres ved hjælp af software, og i moderne IT bruges det i stigende grad i softwareudvikling. Det skyldes, at virksomheder vokser, deres informationssystemer vokser, og derfor vokser mængden af funktionalitet, der skal testes. At udføre manuel test bliver dyrere og dyrere.
Jeg arbejdede for et stort firma, hvis udgivelser udkommer hver anden måned. Samtidig blev der brugt en hel måned på at få en halv snes testere til manuelt at tjekke funktionaliteten. Takket være implementeringen af automatisering af et lille team af udviklere, var vi i stand til at reducere testtiden til 2 uger på halvandet år. Vi har ikke kun øget testhastigheden, men også forbedret kvaliteten. Automatiske test lanceres regelmæssigt, og de udfører altid hele forløbet af kontroller, der er inkluderet i dem, det vil sige, at vi udelukker den menneskelige faktor.
Moderne IT er kendetegnet ved, at en udvikler ikke kun skal skrive produktkode, men også skrive enhedstests, der kontrollerer denne kode.
Men hvad hvis dit system primært er baseret på serverlogik? Der er ingen universel løsning eller bedste praksis på markedet. Som regel løser virksomheder dette problem ved at skabe deres eget selvskrevne testsystem. Dette er vores eget selvskrevne automatiserede testsystem, der blev oprettet på vores projekt, og jeg vil fortælle om det i min rapport.
Test af loyalitet
Lad os først tale om projektet, hvor vi implementerede et automatiseret testsystem. Vores projekt er Sportmaster-loyalitetssystemet (i øvrigt har vi allerede skrevet om det i ).
Hvis din virksomhed er stor nok, vil dit loyalitetssystem have tre standardegenskaber:
- Dit system vil være meget belastet
- Dit system vil indeholde komplekse computerprocesser
- Dit system vil blive aktivt forbedret.
Lad os gå i orden... I alt, hvis vi overvejer alle Sportmaster-mærker, så har vi mere end 1000 butikker i Rusland, Ukraine, Kina, Kasakhstan og Hviderusland. Der foretages omkring 300 indkøb i disse butikker hver dag. Det vil sige, at hver anden 000-3 check kommer ind i vores system. Naturligvis er vores loyalitetssystem meget belastet. Og da det bruges aktivt, skal vi levere de højeste standarder for dets kvalitet, fordi enhver fejl i softwaren betyder store penge-, omdømme- og andre tab.
Samtidig kører Sportmaster mere end hundrede forskellige kampagner. Der er en række kampagner: der er produktkampagner, der er dem, der er dedikeret til ugedagen, der er dem, der er knyttet til en bestemt butik, der er kampagner for mængden af kvitteringen, der er for antallet af varer. Generelt ikke dårligt. Kunder har bonusser og salgsfremmende koder, der bruges ved køb. Alt dette fører til det faktum, at beregning af enhver ordre er en meget ikke-triviel opgave.
Algoritmen, der implementerer ordrebehandling, er virkelig forfærdelig og kompliceret. Og enhver ændring af denne algoritme er ret risikable. Det så ud til, at de mest tilsyneladende ubetydelige ændringer kunne føre til ganske uforudsigelige effekter. Men det er netop sådanne komplekse computerprocesser, især dem, der implementerer kritisk funktionalitet, der er de bedste kandidater til automatisering. Det er meget tidskrævende at kontrollere snesevis af lignende sager i hånden. Og da indgangspunktet i processen er uændret, efter at have beskrevet det én gang, kan du hurtigt oprette automatiske test og være sikker på, at funktionaliteten vil fungere.
Da vores system bruges aktivt, vil virksomheden gerne have noget nyt fra dig, leve med tiden og være kundeorienteret. I vores loyalitetssystem udkommer udgivelser hver anden måned. Det betyder, at vi hver anden måned skal gennemføre en fuldstændig regression af hele systemet. Samtidig går udviklingen naturligvis, som i enhver moderne IT, ikke umiddelbart fra udvikler til produktion. Det stammer fra udviklerens kredsløb, passerer derefter successivt gennem testbænken, frigivelse, accept og ender først derefter i produktion. På test- og frigivelseskredsløbene skal vi som minimum udføre en fuldstændig regression af hele systemet.
De beskrevne egenskaber er standard for næsten ethvert loyalitetssystem. Lad os tale om funktionerne i vores projekt.
Teknologisk er 90 % af logikken i vores loyalitetssystem serverbaseret og implementeret på Oracle. Der er en klient eksponeret i Delphi, som udfører funktionen som en automatiseret arbejdspladsadministrator. Der er eksponerede webtjenester til eksterne applikationer (for eksempel en hjemmeside). Derfor er det meget logisk, at hvis vi implementerer et automatiseret testsystem, vil vi gøre det på Oracle.
Loyalitetssystemet i Sportmaster har eksisteret i mere end 7 år og blev skabt af enkelte udviklere... Det gennemsnitlige antal udviklere på vores projekt i løbet af disse 7 år var 3-4 personer. Men i løbet af det seneste år er vores team vokset markant, og nu er der 10 personer i gang med projektet. Det vil sige, at der kommer folk til projektet, som ikke er fortrolige med typiske opgaver, processer og arkitektur. Og der er en øget risiko for, at vi går glip af fejl.
Projektet er karakteriseret ved fraværet af dedikerede testere som stabsenheder. Der er selvfølgelig test, men test udføres af analytikere, udover deres øvrige hovedansvar: at kommunikere med erhvervskunder, brugere, udvikle systemkrav mv. osv... På trods af at test udføres af meget høj kvalitet (dette er især passende at nævne, da nogle af analytikerne kan få øje på denne rapport), er effektiviteten af specialisering og koncentration på én ting ikke blevet annulleret .
I betragtning af alt ovenstående, for at forbedre kvaliteten af det leverede produkt og reducere udviklingstiden, virker ideen om at automatisere test på et projekt meget logisk. Og på forskellige stadier af loyalitetssystemets eksistens forsøgte individuelle udviklere at dække deres kode med enhedstests. Alt i alt var det en ret usammenhængende proces, hvor alle brugte deres egen arkitektur og metoder. De endelige resultater var fælles for enhedstests: tests blev udviklet, brugt i nogen tid, gemt i et versioneret fillager, men på et tidspunkt holdt de op med at køre og blev glemt. Først og fremmest skyldtes det, at testene i højere grad var knyttet til en specifik performer, og ikke til projektet.
utPLSQL kommer til undsætning
Ved du noget om Stephen Feuerstein?
Dette er en smart fyr, der viede en lang del af sin karriere til at arbejde med Oracle og PL/SQL, og han har skrevet et stort antal værker om dette emne. En af hans berømte bøger hedder: “Oracle PL/SQL. For professionelle." Det var Stephen, der udviklede utPLSQL-løsningen, eller, som det står for, Unit Testing framework for Oracle PL/SQL. UtPLSQL-løsningen blev skabt i 2016, men der arbejdes fortsat aktivt på den og nye versioner frigives. På rapporteringstidspunktet går den seneste version tilbage til den 24. marts 2019.
Hvad er det. Dette er et separat open source-projekt. Den vejer et par megabyte, inklusive eksempler og dokumentation. Fysisk er det et separat skema i ORACLE-databasen med et sæt pakker og tabeller til organisering af enhedstest. Installationen tager et par sekunder. Et karakteristisk træk ved utPLSQL er dens brugervenlighed.
Globalt er utPLSQL en mekanisme til at køre enhedstest, hvor en enhedstest forstås som almindelige Oracle batch-procedurer, hvis tilrettelæggelse følger visse regler. Ud over lancering gemmer utPLSQL en log over alle dine testkørsler og har også et internt rapporteringssystem.
Lad os se på et eksempel på, hvordan enhedstestkoden ser ud, implementeret ved hjælp af denne teknik.
Så skærmen viser koden for en typisk pakkespecifikation med enhedstest. Hvad er de obligatoriske krav? Pakken skal have "utp_" foran. Alle procedurer med test skal have nøjagtig samme præfiks. Pakken skal indeholde to standardprocedurer: "utp_setup" og "utp_teardown". Den første procedure kaldes ved at genstarte hver enhedstest, den anden - efter lanceringen.
"utp_setup" forbereder som regel vores system til at køre en enhedstest, for eksempel ved at oprette testdata. "utp_teardown" - tværtimod vender alt tilbage til de oprindelige indstillinger og nulstiller startresultaterne.
Her er et eksempel på den enkleste enhedstest, der kontrollerer normaliseringen af det indtastede kundetelefonnummer til standardformularen for vores loyalitetssystem. Der er ingen obligatoriske standarder for, hvordan man skriver procedurer med enhedstest. Som regel foretages et opkald til en metode i det system, der testes, og resultatet returneret af denne metode sammenlignes med referencemetoden. Det er vigtigt, at sammenligningen af referenceresultatet og det opnåede sker gennem standard utPLSQL metoder.
En enhedstest kan have et hvilket som helst antal kontroller. Som det fremgår af eksemplet, foretager vi fire på hinanden følgende opkald til den testede metode for at normalisere telefonnummeret og evaluere resultatet efter hvert opkald. Når du udvikler en enhedstest, skal du tage højde for, at der er kontroller, som ikke påvirker systemet på nogen måde, og efter nogle gange skal du rulle tilbage til systemets oprindelige tilstand.
For eksempel formaterer vi i den præsenterede enhedstest simpelthen det indtastede telefonnummer, hvilket ikke påvirker loyalitetssystemet på nogen måde.
Og hvis vi skriver enhedstests ved hjælp af metoden til at oprette en ny klient, så vil der efter hver test blive oprettet en ny klient i systemet, hvilket kan påvirke den efterfølgende lancering af testen.
Sådan køres enhedstests. Der er to mulige startmuligheder: at køre alle enhedstest fra en specifik pakke eller at køre en specifik enhedstest i en specifik pakke.
Sådan ser et eksempel på et internt rapporteringssystem ud. Baseret på resultaterne af enhedstesten opbygger utPLSQL en lille rapport. I den ser vi resultatet for hver specifik kontrol og det samlede resultat af enhedstesten.
6 regler for autotest
Inden vi gik i gang med at lave et nyt system til automatiseret test af loyalitetssystemet, har vi sammen med ledelsen fastlagt de principper, som vores fremtidige automatiserede test skal overholde.
- Autotest skal være effektive og skal være nyttige. Vi har vidunderlige udviklere, som bestemt skal nævnes, for nogle af dem vil sikkert se denne rapport, og de skriver vidunderlig kode. Men selv deres vidunderlige kode er ikke perfekt og har, har og vil fortsat indeholde fejl. Autotest er påkrævet for at finde disse fejl. Hvis det ikke er tilfældet, så skriver vi enten dårlige autotests, eller også er vi kommet til et dødt område, der i princippet ikke er under udvikling. I begge tilfælde gør vi noget forkert, og vores tilgang giver simpelthen ikke mening.
- Autotest skal bruges. Det giver ingen mening at bruge en masse tid og kræfter på at skrive et softwareprodukt, lægge det i et lager og glemme det. Tests bør køres og køres så regelmæssigt som muligt.
- Autotest skal fungere stabilt. Uanset tidspunktet på dagen, startstanden og andre systemindstillinger, bør testkørsler føre til det samme resultat. Dette sikres som udgangspunkt ved, at autotest arbejder med specielle testdata med faste systemindstillinger.
- Autotest bør arbejde med en hastighed, der er acceptabel for dit projekt. Denne tid bestemmes individuelt for hvert system. Nogle mennesker har råd til at arbejde hele dagen, mens andre finder det afgørende at gøre det på få sekunder. Jeg vil fortælle dig lidt senere, hvilke hastighedsstandarder vi opnåede i vores projekt.
- Autotestudvikling skal være fleksibel. Det er ikke tilrådeligt at nægte at teste nogen funktionalitet, blot fordi vi ikke har gjort det før eller af en anden grund. utPLSQL pålægger ingen begrænsninger for udvikling, og Oracle giver dig i princippet mulighed for at implementere en række ting. De fleste problemer har en løsning, det er bare et spørgsmål om tid og kræfter.
- Deployerbarhed. Vi har flere stande, hvor vi skal køre test. Ved hver stand kan et datadump til enhver tid opdateres. Det er nødvendigt at udføre et projekt med automatiske test på en sådan måde, at du smertefrit kan udføre dens hel eller delvis installation.
Og i det andet indlæg om et par dage vil jeg fortælle dig, hvad vi gjorde, og hvilke resultater vi opnåede.
Kilde: www.habr.com