Hei Habr!
Jeg heter Maxim Ponomarenko og er utvikler hos Sportmaster. Jeg har 10 års erfaring innen IT-feltet. Han startet sin karriere innen manuell testing, og gikk deretter over til databaseutvikling. De siste 4 årene har jeg akkumulert kunnskap fra testing og utvikling, og har automatisert testing på DBMS-nivå.
Jeg har vært på Sportmaster-teamet i litt over et år og utvikler automatisert testing på et av de store prosjektene. I april snakket gutta fra Sportmaster Lab og jeg på en konferanse i Krasnodar, rapporten min ble kalt "Enhetstester i et DBMS", og nå vil jeg dele den med dere. Det blir mye tekst, så jeg bestemte meg for å dele rapporten i to innlegg. I den første vil vi snakke om autotester og testing generelt, og i den andre vil jeg dvele mer detaljert på vårt enhetstestsystem og resultatene av dets anvendelse.
Først en litt kjedelig teori. Hva er automatisert testing? Dette er testing som utføres ved hjelp av programvare, og i moderne IT brukes det i økende grad i programvareutvikling. Dette skyldes det faktum at bedrifter vokser, informasjonssystemene deres vokser, og følgelig øker mengden funksjonalitet som må testes. Å gjennomføre manuell testing blir dyrere og dyrere.
Jeg jobbet for et stort selskap hvis utgivelser kommer ut annenhver måned. Samtidig ble det brukt en hel måned på å la et titalls testere manuelt sjekke funksjonaliteten. Takket være implementeringen av automatisering av et lite team av utviklere, klarte vi å redusere testtiden til 2 uker på halvannet år. Vi har ikke bare økt testhastigheten, men også forbedret kvaliteten. Automatiserte tester lanseres regelmessig, og de utfører alltid hele kontrollforløpet som er inkludert i dem, det vil si at vi ekskluderer den menneskelige faktoren.
Moderne IT kjennetegnes ved at en utvikler kan bli pålagt å ikke bare skrive produktkode, men også skrive enhetstester som sjekker denne koden.
Men hva om systemet ditt primært er basert på serverlogikk? Det finnes ingen universell løsning eller beste praksis på markedet. Som regel løser bedrifter dette problemet ved å lage sitt eget selvskrevne testsystem. Dette er vårt eget selvskrevne automatiserte testsystem som ble opprettet på prosjektet vårt, og jeg vil snakke om det i rapporten min.
Tester lojalitet
La oss først snakke om prosjektet der vi implementerte et automatisert testsystem. Prosjektet vårt er Sportmaster-lojalitetssystemet (forresten, vi har allerede skrevet om det i ).
Hvis bedriften din er stor nok, vil lojalitetssystemet ditt ha tre standardegenskaper:
- Systemet ditt vil være svært belastet
- Systemet ditt vil inneholde komplekse databehandlingsprosesser
- Systemet ditt vil bli aktivt forbedret.
La oss gå i orden... Totalt, hvis vi vurderer alle Sportmaster-merker, så har vi mer enn 1000 butikker i Russland, Ukraina, Kina, Kasakhstan og Hviterussland. Rundt 300 000 kjøp gjøres i disse butikkene hver dag. Det vil si at hver andre 3-4 kontroller kommer inn i systemet vårt. Naturligvis er vårt lojalitetssystem svært belastet. Og siden den brukes aktivt, må vi levere de høyeste standardene for kvaliteten, fordi enhver feil i programvaren betyr store økonomiske tap, omdømme og andre tap.
Samtidig kjører Sportmaster mer enn hundre forskjellige kampanjer. Det er en rekke kampanjer: det er produktkampanjer, det er de som er dedikert til ukedagen, det er de som er knyttet til en spesifikk butikk, det er kampanjer for kvitteringsbeløpet, det er for antall varer. Generelt sett ikke dårlig. Kunder har bonuser og kampanjekoder som brukes ved kjøp. Alt dette fører til det faktum at å beregne en hvilken som helst rekkefølge er en veldig ikke-triviell oppgave.
Algoritmen som implementerer ordrebehandling er virkelig forferdelig og komplisert. Og eventuelle endringer i denne algoritmen er ganske risikable. Det så ut til at de mest tilsynelatende ubetydelige endringene kunne føre til ganske uforutsigbare effekter. Men det er nettopp slike komplekse databehandlingsprosesser, spesielt de som implementerer kritisk funksjonalitet, som er de beste kandidatene for automatisering. Å sjekke dusinvis av lignende saker for hånd er svært tidkrevende. Og siden inngangspunktet til prosessen er uendret, etter å ha beskrevet det en gang, kan du raskt lage automatiske tester og være trygg på at funksjonaliteten vil fungere.
Siden systemet vårt brukes aktivt, vil virksomheten ønske deg noe nytt, leve med tiden og være kundeorientert. I vårt lojalitetssystem kommer utgivelser ut annenhver måned. Det betyr at vi annenhver måned må gjennomføre en fullstendig regresjon av hele systemet. Samtidig går naturligvis ikke utviklingen umiddelbart fra utvikler til produksjon, som i enhver moderne IT. Den har sin opprinnelse på utviklerens krets, passerer deretter suksessivt gjennom testbenken, utgivelsen, aksept, og først da ender den i produksjon. På et minimum, på test- og utgivelseskretsene, må vi utføre en fullstendig regresjon av hele systemet.
De beskrevne egenskapene er standard for nesten alle lojalitetssystem. La oss snakke om funksjonene til prosjektet vårt.
Teknologisk er 90 % av logikken til lojalitetssystemet vårt serverbasert og implementert på Oracle. Det er en klient eksponert i Delphi, som utfører funksjonen til en automatisert arbeidsplassadministrator. Det finnes eksponerte webtjenester for eksterne applikasjoner (for eksempel et nettsted). Derfor er det veldig logisk at hvis vi distribuerer et automatisert testsystem, vil vi gjøre det på Oracle.
Lojalitetssystemet i Sportmaster har eksistert i mer enn 7 år og ble opprettet av enkeltutviklere... Gjennomsnittlig antall utviklere på prosjektet vårt i løpet av disse 7 årene var 3-4 personer. Men det siste året har teamet vårt vokst betydelig, og nå er det 10 personer som jobber med prosjektet. Det vil si at folk kommer til prosjektet som ikke er kjent med typiske oppgaver, prosesser og arkitektur. Og det er økt risiko for at vi går glipp av feil.
Prosjektet er preget av fravær av dedikerte testere som stabsenheter. Det er selvfølgelig testing, men testing utføres av analytikere, i tillegg til deres andre hovedoppgaver: å kommunisere med bedriftskunder, brukere, utvikle systemkrav osv. osv... Til tross for det faktum at testing utføres av meget høy kvalitet (dette er spesielt passende å nevne, siden noen av analytikerne kan få øye på denne rapporten), er effektiviteten av spesialisering og konsentrasjon om én ting ikke blitt kansellert .
Med tanke på alt det ovennevnte, for å forbedre kvaliteten på det leverte produktet og redusere utviklingstiden, virker ideen om å automatisere testing på et prosjekt veldig logisk. Og på forskjellige stadier av lojalitetssystemets eksistens forsøkte individuelle utviklere å dekke koden deres med enhetstester. Totalt sett var det en ganske usammenhengende prosess, der alle brukte sin egen arkitektur og metoder. De endelige resultatene var felles for enhetstester: tester ble utviklet, brukt i noen tid, lagret i en versjonert fillagring, men på et tidspunkt sluttet de å kjøre og ble glemt. For det første skyldtes dette at testene var mer knyttet til en spesifikk utøver, og ikke til prosjektet.
utPLSQL kommer til unnsetning
Vet du noe om Stephen Feuerstein?
Dette er en smart fyr som viet en lang del av karrieren sin til å jobbe med Oracle og PL/SQL, og har skrevet et ganske stort antall arbeider om dette emnet. En av hans kjente bøker heter: «Oracle PL/SQL. For profesjonelle." Det var Stephen som utviklet utPLSQL-løsningen, eller, som det står for, Unit Testing framework for Oracle PL/SQL. UtPLSQL-løsningen ble laget i 2016, men det jobbes aktivt med den og nye versjoner slippes. På rapporteringstidspunktet går den siste versjonen tilbake til 24. mars 2019.
Hva er det. Dette er et eget åpen kildekode-prosjekt. Den veier et par megabyte, inkludert eksempler og dokumentasjon. Fysisk er det et eget skjema i ORACLE-databasen med et sett med pakker og tabeller for organisering av enhetstesting. Installasjonen tar noen sekunder. Et særtrekk ved utPLSQL er dens brukervennlighet.
Globalt er utPLSQL en mekanisme for å kjøre enhetstester, hvor en enhetstest forstås som vanlige Oracle batchprosedyrer, hvis organisering følger visse regler. I tillegg til lansering, lagrer utPLSQL en logg over alle testkjøringene dine, og har også et internt rapporteringssystem.
La oss se på et eksempel på hvordan enhetstestkoden ser ut, implementert ved hjelp av denne teknikken.
Så, skjermen viser koden for en typisk pakkespesifikasjon med enhetstester. Hva er de obligatoriske kravene? Pakken må ha "utp_" foran. Alle prosedyrer med tester skal ha nøyaktig samme prefiks. Pakken må inneholde to standardprosedyrer: "utp_setup" og "utp_teardown". Den første prosedyren kalles ved å starte hver enhetstest på nytt, den andre - etter lansering.
"utp_setup", som regel, forbereder systemet vårt til å kjøre en enhetstest, for eksempel ved å lage testdata. "utp_teardown" - tvert imot, alt går tilbake til de opprinnelige innstillingene og tilbakestiller lanseringsresultatene.
Her er et eksempel på den enkleste enhetstesten som kontrollerer normaliseringen av det oppgitte kundetelefonnummeret til standardskjemaet for vårt lojalitetssystem. Det er ingen obligatoriske standarder for hvordan man skriver prosedyrer med enhetstester. Som regel ringes det til en metode for systemet som testes, og resultatet som returneres av denne metoden sammenlignes med referansen. Det er viktig at sammenligningen av referanseresultatet og det oppnådde skjer gjennom standard utPLSQL-metoder.
En enhetstest kan ha et hvilket som helst antall kontroller. Som det fremgår av eksempelet, foretar vi fire påfølgende samtaler til den testede metoden for å normalisere telefonnummeret og evaluere resultatet etter hver samtale. Når du utvikler en enhetstest, må du ta hensyn til at det er kontroller som ikke påvirker systemet på noen måte, og etter noen må du rulle tilbake til den opprinnelige tilstanden til systemet.
For eksempel, i den presenterte enhetstesten formaterer vi ganske enkelt inndatanummeret, som ikke påvirker lojalitetssystemet på noen måte.
Og hvis vi skriver enhetstester ved å bruke metoden for å opprette en ny klient, vil det etter hver test bli opprettet en ny klient i systemet, noe som kan påvirke den påfølgende lanseringen av testen.
Slik kjøres enhetstester. Det er to mulige lanseringsalternativer: kjøre alle enhetstester fra en spesifikk pakke eller kjøre en spesifikk enhetstest i en spesifikk pakke.
Slik ser et eksempel på et internt rapporteringssystem ut. Basert på resultatene av enhetstesten, bygger utPLSQL en liten rapport. I den ser vi resultatet for hver spesifikk kontroll og det samlede resultatet av enhetstesten.
6 regler for autotester
Før vi begynte å lage et nytt system for automatisert testing av lojalitetssystemet, bestemte vi sammen med ledelsen hvilke prinsipper våre fremtidige automatiserte tester skulle følge.
- Autotester må være effektive og må være nyttige. Vi har fantastiske utviklere, som definitivt må nevnes, for noen av dem vil nok se denne rapporten, og de skriver fantastisk kode. Men selv deres fantastiske kode er ikke perfekt og har, har og vil fortsette å inneholde feil. Autotester kreves for å finne disse feilene. Hvis dette ikke er tilfelle, så skriver vi enten dårlige autotester, eller så har vi kommet til et dødt område som i prinsippet ikke bygges ut. I begge tilfeller gjør vi noe galt, og vår tilnærming gir rett og slett ikke mening.
- Autotester bør brukes. Det gir ingen mening å bruke mye tid og krefter på å skrive et programvareprodukt, legge det i et depot og glemme det. Tester bør kjøres, og kjøres så regelmessig som mulig.
- Autotester skal fungere stabilt. Uavhengig av tid på døgnet, lanseringsstativ og andre systeminnstillinger, bør testkjøringer føre til samme resultat. Som regel sikres dette ved at autotester fungerer med spesielle testdata med faste systeminnstillinger.
- Autotester skal fungere med en hastighet som er akseptabel for prosjektet ditt. Denne tiden bestemmes individuelt for hvert system. Noen mennesker har råd til å jobbe hele dagen, mens andre synes det er viktig å gjøre det på sekunder. Jeg vil fortelle deg litt senere hvilke hastighetsstandarder vi oppnådde i prosjektet vårt.
- Autotestutvikling bør være fleksibel. Det er ikke tilrådelig å nekte å teste noen funksjonalitet bare fordi vi ikke har gjort det før eller av en annen grunn. utPLSQL legger ingen begrensninger på utvikling, og Oracle lar deg i prinsippet implementere en rekke ting. De fleste problemer har en løsning, det er bare et spørsmål om tid og krefter.
- Distribuerbarhet. Vi har flere stands der vi må kjøre tester. Ved hver stand kan en datadump oppdateres når som helst. Det er nødvendig å gjennomføre et prosjekt med automatiske tester på en slik måte at du smertefritt kan utføre hele eller delvise installasjonen.
Og i det andre innlegget om et par dager vil jeg fortelle deg hva vi gjorde og hvilke resultater vi oppnådde.
Kilde: www.habr.com