Hej, Habr!
Jag heter Maxim Ponomarenko och jag Àr utvecklare pÄ Sportmaster. Jag har 10 Ärs erfarenhet inom IT-branschen. Jag inledde min karriÀr inom manuell testning och gick sedan över till databasutveckling. Under de senaste 4 Ären, genom att samla pÄ mig kunskaper frÄn bÄde testning och utveckling, har jag arbetat med automatisering av tester pÄ databashanterar nivÄ.
Jag har varit en del av Sportmaster-teamet i lite mer Àn ett Är och pÄ ett av de större projekten arbetar jag med utvecklingen av automatiserade tester. I april presenterade jag tillsammans med kollegor frÄn Sportmaster Lab pÄ en konferens i Krasnodar, mitt föredrag hette "Enhetstester i databashanterare", och nu vill jag dela det med er. Det kommer att bli mycket text, sÄ jag har bestÀmt mig för att dela upp föredraget 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 gÄ mer i detalj pÄ vÄrt system för enhetstestning och resultaten av dess tillÀmpning.
Först lite trÄkig teori. Vad Àr automatiserad testning? Det Àr testning som genomförs med hjÀlp av programvaror, och i dagens IT-vÀrld anvÀnds det alltmer vid mjukvaruutveckling. Detta beror pÄ att företag vÀxer, deras informationssystem vÀxer, och dÀrmed ökar ocksÄ mÀngden funktionalitet som mÄste testas. Att genomföra manuell testning blir allt mer kostsamt.
Jag arbetade pÄ ett stort företag vars releaser kommer ut varannan mÄnad. Under en hel mÄnad spenderades tid pÄ att ett tiotal testare manuellt kontrollerade funktionaliteten. Genom att införa automatisering med ett litet team av utvecklare lyckades vi pÄ ett och ett halvt Är minska testtiden till 2 veckor. Vi har inte bara ökat hastigheten pÄ testningen utan Àven förbÀttrat dess kvalitet. Automatiserade tester körs regelbundet och de genomför alltid hela kursen av inbyggda kontroller, det vill sÀga vi eliminerar den mÀnskliga faktorn.
I modern IT Àr det typiskt att utvecklaren förvÀntas kunna skriva inte bara produktens kod, utan ocksÄ enhetstester som testar den koden.
Men vad gör man om ditt system huvudsakligen baseras pÄ serverlogik? Det finns ingen universallösning eller bÀsta metoder pÄ marknaden. Företag löser oftast detta problem genom att skapa egna skrÀddarsydda testsystem. SÄ hÀr skapades vÄrt egna skrÀddarsydda automatiserade testsystem i vÄrt projekt, och jag kommer att berÀtta om det i min presentation.
Testar lojalitet
Först ska vi prata om projektet dÀr vi implementerade ett automatiserat testsystem. VÄrt projekt Àr ett lojalitetssystem för Sportmaster (för övrigt har vi redan skrivit om det i ).
Om ditt företag Àr tillrÀckligt stort kommer ditt lojalitetssystem att ha tre standardegenskaper:
- Ditt system kommer att vara högbelastat
- Ditt system kommer att innehÄlla komplexa berÀkningsprocesser
- Ditt system kommer att revideras aktivt.
LÄt oss gÄ i ordning... Tillsammans, om vi ser pÄ alla varumÀrken under Sportmaster, har vi mer Àn 1000 butiker i Ryssland, Ukraina, Kina, Kazakstan och Vitryssland. I dessa butiker genomförs cirka 300 000 köp varje dag. Det betyder att vÄrt system fÄr 3-4 kvitton varje sekund. Naturligtvis Àr vÄrt lojalitetssystem högbelastat. Eftersom det anvÀnds aktivt mÄste vi erbjuda de högsta kvalitetsstandarderna, för varje fel i mjukvaran innebÀr stora ekonomiska, rykte- och andra förluster.
Samtidigt arbetar mer Àn hundra olika kampanjer pÄ Sportmaster. Kampanjerna Àr mycket varierande: det finns produktkampanjer, kampanjer kopplade till veckodagar, de kan vara knutna till specifika butiker, kampanjer baserade pÄ köpbelopp, samt antalet produkter. Kort sagt, en hel del. Kunder har bonusar och rabattkoder som anvÀnds vid köp. Allt detta leder till att berÀkningen av varje bestÀllning Àr en ganska betydande uppgift.
Algoritmen som hanterar orderbehandling Àr verkligen fruktansvÀrd och komplex. Och varje Àndring i denna algoritm Àr ganska riskfylld. Det verkar som om Àven de mest ytligt obetydliga Àndringarna kan leda till ganska oförutsÀgbara effekter. Just sÄdana komplexa berÀkningsprocesser, sÀrskilt de som implementerar kritisk funktionalitet, Àr det bÀsta kandidatet för automatisering. Att manuellt kontrollera tiotals likartade fall Àr mycket tidskrÀvande. Och eftersom ingÄngspunkten i processen förblir oförÀndrad kan man en gÄng beskriva den, sÄ kan man ganska snabbt stÀmpla automatiska tester och vara sÀker pÄ att funktionaliteten fungerar.
Eftersom vÄrt system anvÀnds aktivt, kommer verksamheten att förvÀnta sig nÄgot nytt av er, att hÄlla jÀmna steg med tiden och vara kundorienterad. I vÄrt lojalitetssystem slÀpps versioner varannan mÄnad. Det innebÀr att vi behöver genomföra en fullstÀndig regression av hela systemet varannan mÄnad. Dessutom, som i all modern IT, gÄr utvecklingen inte direkt frÄn utvecklaren till produktion. Den föds pÄ utvecklarens kontur, passerar sedan successivt testmiljön, release-miljön, acceptans och hamnar först dÀrefter i produktion. à tminstone pÄ test- och releasekonturerna behöver vi genomföra en fullstÀndig regression av hela systemet.
De beskrivna egenskaperna Àr standard för i stort sett vilket lojalitetssystem som helst. LÄt oss prata om sÀrdragen i vÄrt projekt.
Tekniskt sett Àr 90% av logiken i vÄrt lojalitetssystem serverbaserad och implementerad i Oracle. Det finns en klient som Àr utvecklad i Delphi, som utför funktionen som ARM-administratör. Det finns ocksÄ exponerade webbtjÀnster för externa applikationer (till exempel webbplatsen). DÀrför Àr det ganska logiskt att om vi ska implementera ett system för automatiserad testning, sÄ kommer vi att göra det pÄ Oracle.
Lojalitetsprogrammet pÄ Sportmaster har funnits i över 7 Är och skapades av enskilda utvecklare⊠Det genomsnittliga antalet utvecklare i vÄrt projekt under dessa 7 Är har varit 3-4 personer. Men under det senaste Äret har vÄrt team vÀxt kraftigt, och nu arbetar 10 personer med projektet. Det innebÀr att nya personer kommer in i projektet som inte Àr bekanta med standarduppgifter, processer och arkitektur. Det finns en ökad risk för att vi kan missa fel.
Projektet kÀnnetecknas av avsaknaden av dedikerade testare som anstÀllda. Testning sker sjÀlvklart, men det Àr analytiker som ansvarar för testning utöver sina andra huvuduppgifter: att kommunicera med affÀrskunder, anvÀndare, arbeta igenom kravspecifikationerna etc. Trots att testningen genomförs pÄ ett mycket kvalitativt sÀtt (sÀrskilt relevant att nÀmna eftersom nÄgon av analytikerna kan komma att se denna rapport) Àr effektiviteten av specialisering och fokus pÄ en enda uppgift fortfarande oslagbar.
Med allt detta i Ätanke verkar idén om att automatisera testningen i projektet vara en mycket logisk lösning för att förbÀttra kvaliteten pÄ den levererade produkten och minska utvecklingstiderna. Under olika faser av lojalitetssystemets existens har individuella utvecklare gjort anstrÀngningar för att tÀcka sin kod med enhetstester. Det har i allmÀnhet varit en ganska splittrad process dÀr varje person anvÀnt sin egen arkitektur och metoder. Gemensamma resultat för enhetstesterna har varit: testerna utvecklades, anvÀndes under en tid, lagrades i en versionskontroll för filer, men efter en tid slutade de att köras och glömdes bort. Detta skedde frÀmst eftersom testerna var mer kopplade till den specifika utföraren snarare Àn projektet.
Uppdraget kommer frÄn utPLSQL
Vet du nÄgot om Steven Feuerstein?
Det Àr en smart kille som har Àgnat en stor del av sin karriÀr Ät arbete med Oracle och PL/SQL, och han har skrivit en ganska stor mÀngd arbeten om detta Àmne. En av hans kÀnda böcker heter just "Oracle PL/SQL. För proffs". Det var Steven som utvecklade lösningen utPLSQL, eller som det förklaras, Unit Testing framework för Oracle PL/SQL. Lösningen utPLSQL skapades 2016, men det pÄgÄr fortfarande aktivt arbete med den och nya versioner slÀpps. Vid tiden för presentationen daterades den senaste versionen den 24 mars 2019.
Vad Àr detta? Det Àr ett separat öppen kÀllkod-projekt. Det vÀger nÄgra megabyte, inklusive exempel och dokumentation. Det bestÄr fysiskt av ett separat schema i ORACLE-databasen med ett set av paket och tabeller för att organisera enhetstestning. Installationen tar nÄgra sekunder. En utmÀrkande egenskap hos utPLSQL Àr enkelheten i anvÀndningen.
Ăvergripande sett Ă€r utPLSQL en mekanism för att köra enhetstester, dĂ€r enhetstestet definieras som vanliga Oracle-paketprocedurer vars organisation följer vissa regler. Förutom att köra, lagrar utPLSQL en logg över alla dina testkörningar, och det finns ocksĂ„ ett internt rapportsystem.
LÄt oss titta pÄ ett exempel pÄ hur koden för en enhetstest som implementerats med denna metod ser ut.
SÄ, pÄ skÀrmen visas koden för en typisk paketspecifikation med enhetstester. Vilka Àr de obligatoriska kraven? Paketet mÄste ha prefixet "utp_". Detsamma gÀller för alla procedurer som har tester. I paketet mÄste det finnas tvÄ standardprocedurer: "utp_setup" och "utp_teardown". Den första proceduren anropas vid omstart av varje enhetstest, den andra efter körningen.
"utp_setup" förbereder vanligtvis vÄrt system för att köra enhetstestet, till exempel genom att skapa testdata. "utp_teardown" Ä sin sida ÄterstÀller allt till ursprungliga instÀllningar och nollstÀller resultaten av körningen.
HÀr Àr ett exempel pÄ det enklaste enhetstestet som kontrollerar normaliseringen av det angivna telefonnumret för kunden till den standard som gÀller för vÄrt lojalitetssystem. Det finns inga obligatoriska standarder för hur man skriver procedurer med enhetstester. Vanligtvis utförs anrop av en metod i det testade systemet och resultatet som returneras av den metoden jÀmförs med en referens. Det Àr viktigt att jÀmförelsen mellan referensresultatet och det erhÄllna sker via standard metoder i utPLSQL.
Det kan finnas vilket som helst antal kontroller i enhetstestet. Som vi ser i exemplet gör vi fyra sekventiella anrop till den testade metoden för normalisering av telefonnumret och efter varje anrop utvÀrderar vi resultatet. Vid utvecklingen av enhetstestet bör vi beakta att det finns kontroller som inte pÄverkar systemet, medan andra krÀver att man ÄtergÄr till systemets ursprungliga tillstÄnd.
Till exempel, i det presenterade enhetstestet formaterar vi bara det ingÄende telefonnumret, vilket inte pÄverkar lojalitetssystemet pÄ nÄgot sÀtt.
Men om vi skriver enhetstester för metoden att skapa en ny klient, kommer det att skapas en ny klient i systemet efter varje kontroll, vilket kan pÄverka den efterföljande körningen av testet.
SÄ hÀr körs enhetstester. Det finns tvÄ tillÄtna sÀtt att köra: 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. UtifrÄn resultaten av enhetstestet bygger utPLSQL en liten rapport. I den kan vi se resultatet för varje specifik kontroll samt det totala resultatet av enhetstestet.
6 regler för automatiserade tester
Innan vi började skapa ett nytt system för automatiserad testning av lojalitetssystemet, definierade vi tillsammans med ledningen de principer som vÄra framtida automatiserade tester skulle följa.
- Automatiserade tester mÄste vara effektiva och ge fördelar. Vi har fantastiska utvecklare som förtjÀnar att nÀmnas, eftersom nÄgon av dem förmodligen kommer att se denna presentation, och de skriver utmÀrkt kod. Men Àven deras utmÀrkta kod Àr inte perfekt och har, har och kommer att ha buggar. Automatiserade tester mÄste hitta dessa buggar. Om de inte gör det, sÄ skriver vi antingen dÄliga automatiserade tester eller sÄ har vi hamnat i ett dödlÀge som i princip inte vidareutvecklas. I bÄda fallen gör vi nÄgot fel, och vÄr metod Àr helt meningslös.
- Automatiserade tester mÄste anvÀndas. Det Àr meningslöst att spendera massor av tid och energi pÄ att utveckla en programvara, skapa dess repository och sedan glömma bort det. Tester mÄste köras, och de mÄste köras sÄ regelbundet som möjligt.
- Automatiserade tester mÄste fungera stabilt. Oavsett tid pÄ dygnet, testbÀnk och andra systeminstÀllningar, bör testkörningarna alltid ge samma resultat. Detta sÀkerstÀlls vanligtvis av att automatiserade tester arbetar med speciella testdata med fasta systeminstÀllningar.
- Automatiserade tester mÄste arbeta med en hastighet som Àr acceptabel för ditt projekt. Denna tid bestÀms individuellt för varje system. Vissa kan tillÄta sig att arbeta hela dagen, medan andra mÄste klara det pÄ sekunder. Vilka hastighetsnormer vi har uppnÄtt i vÄrt projekt kommer jag att berÀtta mer om senare.
- Utvecklingen av automatiserade tester mÄste vara flexibel. Det Àr oönskat att avstÄ frÄn att testa nÄgon funktion bara för att vi inte har gjort det tidigare eller av andra övertygelser. utPLSQL lÀgger inga begrÀnsningar pÄ utvecklingen, och Oracle tillÄter i princip att genomföra en mÀngd olika saker. De flesta uppgifter har en lösning; frÄgan Àr bara tid och den anstrÀngning som krÀvs.
- Distribuerbarhet. Vi har flera testbÀnkar dÀr tester behöver köras. PÄ varje testbÀnk kan en databas dumpas och uppdateras nÀr som helst. Projektet med automatiserade tester mÄste drivas pÄ ett sÀtt som möjliggör smÀrtfri installation, helt eller delvis.
I det andra inlÀgget om nÄgra dagar kommer jag att berÀtta om vad vi har gjort och vilka resultat vi har uppnÄtt.
KĂ€lla: habr.com
