Enhetstester i ett DBMS - så gör vi i Sportmaster, del två

Första delen - här.

Föreställ dig situationen. Du står inför uppgiften att utveckla ny funktionalitet. Du har utvecklingar från dina föregångare. Om vi ​​antar att du inte har några moraliska skyldigheter, vad skulle du göra?

Oftast glöms alla gamla utvecklingar bort och allt börjar om igen. Ingen gillar att gräva i någon annans kod, men om du har tid, varför inte börja skapa ditt eget system? Detta är ett typiskt tillvägagångssätt, och det är i stort sett korrekt. Men i vårt projekt gjorde vi det fel. Vi baserade det framtida automatiska testsystemet på utvecklingen av enhetstester på utPLSQL från våra föregångare och gick sedan till jobbet i flera parallella riktningar.

1. Återställer gamla enhetstester. Återställning innebär anpassning av tester till lojalitetssystemets befintliga tillstånd och anpassning av tester till utPLSQL-standarder.
2. Att lösa ett problem med en förståelse för exakt vad, vilka metoder och processer som täcks med autotester. Du måste antingen ha denna information i huvudet, eller dra slutsatser direkt utifrån autotestkoden. Därför bestämde vi oss för att skapa en katalog. Vi tilldelade en unik mnemonisk kod till varje autotest, skapade en beskrivning och registrerade inställningar (till exempel under vilka förhållanden den ska startas, eller vad som ska hända om teststarten misslyckas). I huvudsak fyllde vi i metadata om autotesterna och placerade dessa metadata i standardutPLSQL-schematabeller.
3. Att definiera expansionsstrategin, dvs. val av funktionalitet som är föremål för verifiering av automatiserade tester. Vi bestämde oss för att uppmärksamma tre saker: nya systemförbättringar, produktionsincidenter och viktiga systemprocesser. Därför utvecklar vi parallellt med releasen, säkerställer dess högre kvalitet, utökar samtidigt omfattningen av regression och säkerställer systemets tillförlitlighet på kritiska platser. Den första sådana flaskhalsen var processen att dela ut rabatter och bonusar på en check.
4. Naturligtvis började vi utveckla nya autotester. En av de första releaseuppgifterna var att utvärdera prestandan för fördefinierade prover av lojalitetssystemet. Vårt projekt har ett block med strikt fixerade SQL-frågor som väljer klienter baserat på villkor. Få till exempel en lista över alla kunder vars senaste köp var i en specifik stad, eller en lista över kunder vars genomsnittliga köpbelopp överstiger ett visst värde. Efter att ha skrivit autotester, kontrollerade vi fördefinierade prover, registrerade prestandaparametrar för benchmark, och dessutom hade vi belastningstester.
5. Att arbeta med autotester ska vara bekvämt. De två vanligaste åtgärderna är att köra autotester och skapa testdata. Så här dök två hjälpmoduler ut i vårt system: en startmodul och en datagenereringsmodul.

   Startprogrammet representeras som en universell procedur med en textinmatningsparameter. Som en parameter kan du skicka autotestmnemonkoden, paketnamnet, testnamnet, autotestinställningen eller ett reserverat nyckelord. Proceduren väljer ut och kör alla autotester som uppfyller villkoren.

   Datagenereringsmodulen presenteras i form av ett paket där det för varje objekt i systemet som testas (en tabell i databasen) har skapats en speciell procedur som infogar data där. I denna procedur fylls standardvärdena så mycket som möjligt, vilket säkerställer att objekt skapas bokstavligen med ett fingerklick. Och för att underlätta användningen skapades mallar för genererad data. Skapa till exempel en klient i en viss ålder med en testtelefon och ett genomfört köp.

6. Autotester bör starta och köras inom en tid som är acceptabel för ditt system. Därför anordnades en daglig nattlansering, baserad på vars resultat en rapport om resultaten genereras och skickas till hela utvecklingsteamet via företagspost. Efter att ha återställt gamla autotester och skapat nya var den totala drifttiden 30 minuter. Denna föreställning passade alla, eftersom lanseringen skedde utanför arbetstid.

   Men vi var tvungna att arbeta med att optimera arbetshastigheten. Lojalitetssystemet i produktionen uppdateras nattetid. Som en del av ett av släppen var vi tvungna att göra akuta förändringar på natten. Att vänta en halvtimme på resultatet av autotesterna klockan tre på morgonen gjorde inte den som ansvarade för frigivningen glad (brinnande hälsningar till Alexey Vasyukov!), och nästa morgon sades många vänliga ord mot vårt system. Men som ett resultat fastställdes en 5-minutersstandard för arbete.

   För att påskynda prestandan använde vi två metoder: autotester började köras i tre parallella trådar, lyckligtvis är detta mycket bekvämt på grund av arkitekturen i vårt lojalitetssystem. Och vi övergav tillvägagångssättet där autotestet inte skapar testdata för sig själv, utan försöker hitta något lämpligt i systemet. Efter ändringarna reducerades den totala drifttiden till 3-4 minuter.

7. Ett projekt med automatiska tester ska kunna sättas in på olika montrar. I början av vår resa gjordes försök att skriva våra egna batchfiler, men det blev tydligt att en självskriven automatiserad installation var fullständig skräck och vi vände oss mot industriella lösningar. På grund av att projektet innehåller mycket direktkod (först och främst lagrar vi autotestkoden) och väldigt lite data (huvuddatan är metadata om autotester) visade sig implementeringen i Liquibase-projektet vara väldigt enkel.

   Det är ett databasoberoende bibliotek med öppen källkod för att spåra, hantera och genomdriva databasschemaändringar. Hanteras via kommandoraden eller ramverk som Apache Maven. Funktionsprincipen för Liquibase är ganska enkel. Vi har ett projekt organiserat på ett visst sätt, som består av ändringar eller skript som måste rullas ut till målservern, och kontrollfiler som bestämmer i vilken sekvens och med vilka parametrar dessa ändringar ska installeras.

   På DBMS-nivå skapas en speciell tabell där Liquibase lagrar överrullningsloggen. Varje ändring har en beräknad hash, som jämförs varje gång mellan projektet och tillståndet i databasen. Tack vare Liquibase kan vi enkelt rulla ut ändringar i vårt system till vilken krets som helst. Autotester lanseras nu på test- och releasekretsar, såväl som på containrar (utvecklarens personliga kretsar).

Så låt oss prata om resultaten av att använda vårt enhetstestsystem.

1. Självklart är vi först och främst övertygade om att vi har börjat utveckla bättre mjukvara. Autotester lanseras dagligen och dussintals fel hittas varje release. Dessutom är några av dessa fel bara indirekt relaterade till den funktionalitet som vi verkligen ville ändra. Det finns allvarliga tvivel om att dessa fel hittades genom manuell testning.
2. Teamet har nu förtroende för att specifik funktionalitet fungerar korrekt... Först och främst handlar det om våra kritiska processer. Till exempel har vi under de senaste sex månaderna inte haft några problem med fördelningen av rabatter och bonusar på kvitton, trots releaseförändringarna, även om fel under tidigare perioder inträffade med viss frekvens
3. Vi lyckades minska antalet testiterationer. På grund av att autotester är skrivna för ny funktionalitet får analytiker och deltidstestare kod av högre kvalitet, eftersom det har redan kontrollerats.
4. En del av utvecklingen inom automatiserad testning används av utvecklare. Till exempel skapas testdata på behållare med hjälp av modulen för objektgenerering.
5. Det är viktigt att vi har utvecklat en "acceptans" av det automatiserade testsystemet från utvecklarnas sida. Det finns en förståelse för att detta är viktigt och användbart. Men av egen erfarenhet kan jag säga att så är långt ifrån fallet. Autotester måste skrivas, de behöver stödjas och utvecklas, resultaten måste analyseras, och ofta är dessa tidskostnader helt enkelt inte värda det. Det är mycket lättare att gå till produktion och hantera problem där. Här ställer utvecklare upp och ber oss täcka deras funktionalitet med autotester.

Vad är nästa

Låt oss prata om utvecklingsplanerna för det automatiserade testprojektet.

Så länge Sportmasters lojalitetssystem lever och fortsätter att utvecklas är det naturligtvis också möjligt att utveckla autotester nästan i det oändliga. Därför är den huvudsakliga utvecklingsriktningen att utöka täckningsområdet.

När antalet autotester ökar kommer deras totala drifttid att öka stadigt och vi måste återgå till frågan om prestanda. Troligtvis blir lösningen att öka antalet parallella trådar.

Men det är självklara utvecklingsvägar. Om vi ​​pratar om något mer icke-trivialt lyfter vi fram följande:

1. För närvarande utförs autotesthantering på DBMS-nivå, d.v.s. kunskaper i PL/SQL krävs för framgångsrikt arbete. Om det behövs, systemhantering (till exempel lansering eller skapande av metadata), kan du skapa någon form av adminpanel med Jenkins eller något liknande.
2. Alla älskar kvantitativa och kvalitativa indikatorer. För automatiserad testning är en sådan universell indikator kodtäckning eller kodtäckningsmått. Med hjälp av denna indikator kan vi bestämma hur stor andel av koden i vårt system som testas som täcks av autotester. Från och med version 12.2 ger Oracle möjligheten att beräkna detta mått och erbjuder användningen av standardpaketet DBMS_PLSQL_CODE_COVERAGE.

   Vårt autotestsystem är drygt ett år gammalt och kanske är det dags att utvärdera vår täckning. I mitt förra projekt (inte ett Sportmaster-projekt) var detta vad som hände. Ett år efter att ha arbetat med autotester satte ledningen i uppdrag att bedöma hur stor andel av koden vi täcker. Med en täckning på mer än 1 % skulle ledningen vara nöjd. Vi, utvecklarna, förväntade oss ett resultat på cirka 10%. Vi installerade kodtäckning, mätte den och fick 20 %. För att fira gick vi för att hämta priset, men hur vi gick för att få det och vart vi gick senare är en helt annan historia.

3. Autotester kan kontrollera exponerade webbtjänster. Oracle tillåter oss att göra detta ganska bra, och vi kommer inte längre att stöta på ett antal problem.
4. Och naturligtvis kan vårt automatiserade testsystem appliceras på ett annat projekt. Lösningen vi fick är universell och kräver endast användning av Oracle. Jag hörde att andra Sportmaster-projekt är intresserade av automatiska tester och kanske kommer vi att gå till dem.

Resultat

Låt oss sammanfatta. På lojalitetssystemprojektet i Sportmaster lyckades vi implementera ett automatiserat testsystem. Den är baserad på utPLSQL-lösningen från Stephen Feuerstein. Runt utPLSQL finns autotestkod och extra självskrivna moduler: startmodul, datagenereringsmodul och andra. Autotester lanseras dagligen och, viktigast av allt, de fungerar och är användbara. Vi är övertygade om att vi har börjat släppa mjukvara av högre kvalitet. Samtidigt är den resulterande lösningen universell och kan fritt appliceras på alla projekt där det är nödvändigt att organisera automatiserad testning på Oracle DBMS.

PS Den här artikeln är inte särskilt specifik: det finns mycket text och praktiskt taget inga tekniska exempel. Om ämnet är allmänt intressant så är vi redo att fortsätta det och återkomma med en fortsättning, där vi kommer att berätta vad som har förändrats under de senaste sex månaderna och ge kodexempel.

Skriv kommentarer om det finns punkter som bör betonas i framtiden, eller frågor som kräver avslöjande.

Endast registrerade användare kan delta i undersökningen. Logga in, Snälla du.

Ska vi skriva mer om detta?

• Åh visst

• Nej tack

12 användare röstade. 4 användare avstod från att rösta.

Källa: will.com