Enhetstester i ett DBMS - hur vi gör i Sportmaster, del ett

Hej Habr!

Mitt namn är Maksim Ponomarenko och jag är utvecklare på Sportmaster. Jag har 10 års erfarenhet inom IT-området. Jag började min karriär med manuell testning och bytte sedan till databasutveckling. Under de senaste fyra åren har jag, utifrån mina kunskaper inom testning och utveckling, arbetat med testautomation på DBMS-nivå.

Jag har varit en del av Sportmaster-teamet i drygt ett år och jag utvecklar automatiserad testning på ett av de stora projekten. I april talade jag och killarna från Sportmaster Lab på en konferens i Krasnodar. Min rapport hette "Enhetstester i DBMS", och nu vill jag dela den med er. Det kommer att bli mycket text, så jag bestämde mig för att dela upp rapporten i två inlägg. I det första kommer vi att prata om automatiserade tester och testning i allmänhet, och i det andra kommer jag att fördjupa mig mer i detalj vid vårt enhetstestsystem och resultaten av dess tillämpning.

Först lite tråkig teori. Vad är automatiserad testning? Det är testning som utförs med hjälp av programvaruverktyg, och inom modern IT används det allt oftare i mjukvaruutveckling. Detta beror på att företag växer, deras informationssystem växer och därmed mängden funktionalitet som behöver testas växer. Att genomföra manuell testning blir allt dyrare.

Jag arbetade för ett stort företag som släppte programvara varannan månad. Samtidigt ägnades en hel månad åt ett dussin testare som manuellt kontrollerade funktionaliteten. Tack vare implementeringen av automatisering av ett litet team av utvecklare lyckades vi minska testtiden till två veckor på ett och ett halvt år. Vi ökade inte bara testhastigheten, utan förbättrade också kvaliteten. Automatiska tester lanseras regelbundet och de utför alltid hela kontrollförloppet som ingår i dem, det vill säga vi utesluter den mänskliga faktorn.

Ett karakteristiskt drag för modern IT är att en utvecklare kan vara skyldig att inte bara skriva produktkod, utan också skriva enhetstester som kontrollerar denna kod.

Men tänk om ditt system huvudsakligen är baserat på serverlogik? Det finns ingen universell lösning eller bästa praxis på marknaden. Som regel löser företag detta problem genom att skapa sina egna egenskrivna testsystem. Detta egenskrivna automatiserade testsystem skapades i vårt projekt och jag kommer att prata om det i min rapport.

Testa lojalitet

Låt oss först prata om projektet där vi implementerade ett automatiserat testsystem. Vårt projekt är Sportmasters lojalitetssystem (förresten, vi skrev redan om det i den här posten).

Om ditt företag är tillräckligt stort kommer ditt lojalitetssystem att ha tre standardfunktioner:

• Ditt system kommer att vara högbelastat.
• Ditt system kommer att innehålla komplexa beräkningsprocesser.
• Ditt system kommer att aktivt förbättras.

Låt oss gå i ordning... Totalt sett, om vi betraktar alla Sportmaster-märken, så har vi mer än 1000 butiker i Ryssland, Ukraina, Kina, Kazakstan och Vitryssland. Cirka 300 000 köp görs i dessa butiker varje dag. Det vill säga 3-4 kvitton kommer in i vårt system varje sekund. Naturligtvis är vårt lojalitetssystem högbelastat. Och eftersom det används aktivt måste vi tillhandahålla högsta möjliga kvalitetsstandard, eftersom alla fel i programvaran innebär stora monetära, anseendemässiga och andra förluster.

Det finns fler än hundra olika kampanjer som körs samtidigt på Sportmaster. Kampanjerna är väldigt olika: det finns produktkampanjer, det finns kampanjer knutna till en veckodag, det finns kampanjer knutna till en specifik butik, det finns kampanjer baserade på checkbeloppet, det finns kampanjer baserade på antalet produkter. Generellt sett är det inte svagt. Kunder har bonusar, det finns kampanjkoder som används vid köp. Allt detta leder till att det är en mycket enkel uppgift att beräkna vilken beställning som helst.

Algoritmen som implementerar orderhantering är verkligen fruktansvärd och komplex. Och alla ändringar i denna algoritm är ganska riskabla. De mest till synes obetydliga ändringarna kan leda till ganska oförutsägbara effekter. Men det är just sådana komplexa beräkningsprocesser, särskilt de som implementerar kritisk funktionalitet, som är de bästa kandidaterna för automatisering. Att manuellt kontrollera dussintals liknande fall är mycket dyrt i tidsmässigt avseende. Och eftersom ingångspunkten till processen är oförändrad, kan du, när du väl har beskrivit den, snabbt utplåna automatiska tester och vara säker på funktionaliteten.

Eftersom vårt system används aktivt kommer verksamheten att vilja ha något nytt från dig, leva med tiden och vara kundorienterad. I vårt lojalitetssystem släpps releaser varannan månad. Det innebär att vi varannan månad behöver genomföra en fullständig regression av hela systemet. Samtidigt går utvecklingen naturligtvis, precis som inom all modern IT, inte direkt från utvecklaren till produktion. Den börjar i utvecklarens krets, passerar sedan successivt testställning, release, acceptans och hamnar först sedan i produktion. Åtminstone i test- och releasekretsarna behöver vi genomföra en fullständig regression av hela systemet.

De beskrivna egenskaperna är standard för nästan alla lojalitetssystem. Låt oss prata om funktionerna i vårt projekt.

Tekniskt sett är 90 % av logiken i vårt lojalitetssystem serverbaserad och implementerad i Oracle. Det finns en klient i Delphi som utför funktionen av en ARM-administratör. Det finns webbtjänster för externa applikationer (till exempel en webbplats). Därför är det ganska logiskt att om vi driftsätter ett automatiserat testsystem, så kommer vi att göra det i Oracle.

Lojalitetssystemet i Sportmaster har funnits i mer än 7 år och skapades av enskilda utvecklare... Det genomsnittliga antalet utvecklare i vårt projekt under dessa 7 år var 3-4 personer. Men under det senaste året har vårt team vuxit avsevärt, och nu arbetar 10 personer med projektet. Det vill säga personer som inte är bekanta med typiska uppgifter, processer och arkitektur kommer till projektet. Och det finns en ökad risk att vi missar fel.

Projektet kännetecknas av avsaknaden av dedikerade testare som heltidsenheter. Testning finns naturligtvis, men analytiker utför testning, utöver sina andra huvudsakliga ansvarsområden: att kommunicera med affärskunder, användare, utveckla systemkrav, etc., etc. Trots att testningen genomförs mycket väl (detta är särskilt lämpligt att nämna, eftersom vissa av analytikerna kan stöta på den här rapporten), har effektiviteten av specialisering och koncentration på en sak inte uteblivit.

Med tanke på allt ovanstående, för att förbättra kvaliteten på den levererade produkten och minska utvecklingstiden, verkar idén om automatiserad testning av projektet ganska logisk. Och i olika skeden av lojalitetssystemets existens ansträngde sig enskilda utvecklare för att täcka sin kod med enhetstester. Generellt sett var detta en ganska olikartad process, där alla använde sin egen arkitektur och sina egna metoder. De slutliga resultaten var gemensamma för enhetstester: tester utvecklades, användes under en tid, lagrades i en versionerad fillagring, men vid någon tidpunkt slutade de att köras och glömdes bort. Först och främst hände detta eftersom testerna var mer knutna till en specifik utförare, snarare än ett projekt.

utPLSQL kommer till undsättning

Vet du något om Stephen Feuerstein?

Det här är en smart kille som har ägnat en stor del av sin karriär åt att arbeta med Oracle och PL/SQL, och har skrivit en hel del verk i ämnet. En av hans berömda böcker heter: "Oracle PL/SQL. För proffs." Det var Stephen som utvecklade utPLSQL-lösningen, eller, som det står för, Unit Testing framework för Oracle PL/SQL. utPLSQL-lösningen skapades 2016, men de fortsätter att aktivt arbeta med den och släppa nya versioner. Vid tidpunkten för rapporten är den senaste versionen daterad 24 mars 2019.
Vad är det? Det är ett separat projekt med öppen källkod. Det väger ett par megabyte, inklusive exempel och dokumentation. Fysiskt sett är det ett separat schema i ORACLE-databasen med en uppsättning paket och tabeller för att organisera enhetstestning. Installationen tar några sekunder. Ett utmärkande drag för utPLSQL är dess användarvänlighet.
Globalt sett är utPLSQL en mekanism för att köra enhetstester, där enhetstester förstås som vanliga Oracle-batchprocedurer, vars organisation motsvarar vissa regler. Förutom att köra lagrar utPLSQL en logg över alla dina testkörningar och har även ett internt rapporteringssystem.

Låt oss titta på ett exempel på hur enhetstestkod ser ut när den implementeras med den här metoden.

Så, skärmen visar koden för en typisk specifikation av ett paket med enhetstester. Vilka är de obligatoriska kraven? Paketet måste ha prefixet "utp_". Alla procedurer med tester måste ha exakt samma prefix. Paketet måste nödvändigtvis innehålla två standardprocedurer: "utp_setup" och "utp_teardown". Den första proceduren anropas genom att starta om varje enhetstest, den andra - efter uppstart.

"utp_setup" förbereder vanligtvis vårt system för att köra ett enhetstest, till exempel skapar testdata. "utp_teardown" - tvärtom, återställer allt till de ursprungliga inställningarna och återställer resultaten av uppstarten.

Här är ett exempel på det enklaste enhetstestet, som kontrollerar normaliseringen av det angivna kundens telefonnummer till standardformuläret för vårt lojalitetssystem. Det finns inga obligatoriska standarder för att skriva procedurer med enhetstester. Som regel görs ett anrop till någon metod i systemet som testas, och resultatet som returneras av denna metod jämförs med referensresultatet. Det är viktigt att jämförelsen av referensresultatet och det mottagna resultatet sker med hjälp av standard utPLSQL-metoder.

Ett enhetstest kan ha ett valfritt antal kontroller. Som du kan se i exemplet gör vi fyra på varandra följande anrop till den testade metoden för att normalisera telefonnumret och utvärdera resultatet efter varje anrop. När du utvecklar ett enhetstest måste du ta hänsyn till att det finns kontroller som inte påverkar systemet på något sätt, och efter en viss tid måste du återställa systemets ursprungliga tillstånd.
Till exempel, i det presenterade enhetstestet formaterar vi helt enkelt det inmatade telefonnumret, vilket inte påverkar lojalitetssystemet på något sätt.

Och om vi skriver enhetstester med metoden att skapa en ny klient, så skapas en ny klient i systemet efter varje kontroll, vilket kan påverka den efterföljande lanseringen av testet.

Så här körs enhetstester. Det finns två möjliga körningsalternativ: att köra alla enhetstester från ett specifikt paket, eller att köra ett specifikt enhetstest i ett specifikt paket.

Så här ser ett exempel på ett internt rapporteringssystem ut. Baserat på resultaten från enhetstestet bygger utPLSQL en liten rapport. I den ser vi resultatet för varje specifik kontroll och det övergripande resultatet av enhetstestets körning.

6 regler för autotest

Innan vi började skapa ett nytt automatiserat testsystem för lojalitetssystem, definierade vi tillsammans med ledningen de principer som våra framtida automatiserade tester ska följa.

1. Automatiserade tester måste vara effektiva och användbara. Vi har fantastiska utvecklare, som måste nämnas eftersom några av dem förmodligen kommer att se detta föredrag, och de skriver bra kod. Men även deras bra kod är inte perfekt och har innehållit, innehåller och kommer att innehålla fel. Automatiserade tester måste hitta dessa fel. Om så inte är fallet, så skriver vi antingen dåliga automatiserade tester, eller så har vi kommit in i ett dött område som i princip inte utvecklas. I båda fallen gör vi något fel, och vår metod är helt enkelt meningslös.
2. Autotester bör användas. Det är meningslöst att lägga ner mycket tid och ansträngning på att skriva en mjukvaruprodukt, lägga ihop dess repository och glömma bort det. Tester bör köras, och köras så regelbundet som möjligt.
3. Autotester måste fungera stabilt. Oavsett tid på dygnet, uppskjutningsstället och andra systeminställningar måste testkörningar leda till samma resultat. Som regel säkerställs detta genom att autotester arbetar med speciella testdata med fasta systeminställningar.
4. Autotester bör arbeta med en hastighet som är acceptabel för ditt projekt. Denna tid bestäms individuellt för varje system. Vissa har råd att arbeta hela dagen, medan det för andra är avgörande att få plats på sekunder. Vilka hastighetsstandarder vi uppnådde i vårt projekt kommer jag att berätta lite senare.
5. Utveckling av autotest bör vara flexibel. Det är inte tillrådligt att vägra testa någon funktionalitet bara för att vi inte har gjort det än eller av andra skäl. utPLSQL innebär inga begränsningar för utveckling, och Oracle låter dig implementera en mängd olika saker. De flesta problem har en lösning, det är bara en fråga om tid och ansträngning.
6. Implementeringsbarhet. Vi har flera monter där tester behöver köras. Datadumpen kan uppdateras när som helst på varje monter. Det är nödvändigt att hantera projektet med autotester på ett sådant sätt att det ska vara möjligt att smärtfritt utföra dess fullständiga eller delvisa installation.

Och i det andra inlägget om ett par dagar kommer jag att berätta vad vi gjorde och vilka resultat vi uppnådde.

Källa: will.com