Unit tests in een DBMS - hoe we het doen in Sportmaster, deel twee

Eerste deel - hier.

Stel je een situatie voor. Je staat voor de taak om nieuwe functionaliteit te ontwikkelen. Je hebt ervaring van je voorgangers. Stel dat u geen morele verplichtingen heeft, wat zou u dan doen?

Meestal worden alle oude ontwikkelingen vergeten en begint alles opnieuw. Niemand graaft graag in de code van iemand anders, en als je tijd hebt, waarom begin je dan niet met het maken van je eigen systeem? Dit is een typische benadering, en in veel opzichten is het juist. Maar in ons project hebben we anders gehandeld. We hebben het toekomstige geautomatiseerde testsysteem gebaseerd op de ontwikkelingen in unit tests op utPLSQL van onze voorgangers, en zijn vervolgens in verschillende parallelle richtingen aan de slag gegaan.

1. Oude eenheidstests herstellen. Herstel betekent aanpassing van tests aan de bestaande status van het loyaliteitssysteem en aanpassing van tests aan utPLSQL-standaarden.
2. Het probleem oplossen met begrip, en wat precies, welke methoden en processen hebben we behandeld met autotests. U moet deze informatie in uw hoofd houden of conclusies trekken die rechtstreeks op de code van autotests zijn gebaseerd. Daarom hebben we besloten om een ​​catalogus te maken. We hebben een unieke geheugensteuncode aan elke autotest toegewezen, een beschrijving gemaakt en de instellingen aangepast (bijvoorbeeld onder welke omstandigheden deze moet worden uitgevoerd of wat er moet gebeuren als de testrun mislukt). In essentie hebben we de metadata over de autotesten ingevuld en deze metadata in de standaardtabellen van het utPLSQL-schema geplaatst.
3. Definitie van expansiestrategie, d.w.z. selectie van functionaliteit die wordt geverifieerd door autotests. We besloten om op drie dingen te letten: nieuwe verbeteringen aan het systeem, incidenten uit de productie en sleutelprocessen van het systeem. We ontwikkelen dus parallel met de release, zorgen voor een hogere kwaliteit, breiden tegelijkertijd de reikwijdte van de regressie uit en zorgen voor de betrouwbaarheid van het systeem op kritieke plaatsen. Het eerste knelpunt was het proces van het uitdelen van kortingen en bonussen per cheque.
4. Uiteraard zijn we begonnen met het ontwikkelen van nieuwe autotesten. Een van de eerste releasetaken was het evalueren van de prestaties van vooraf gedefinieerde voorbeelden van het loyaliteitssysteem. Ons project heeft een blok rigide vaste sql-query's die klanten selecteren op basis van voorwaarden. Krijg bijvoorbeeld een lijst met alle klanten waarvan de laatste aankoop in een bepaalde stad is gedaan, of een lijst met klanten waarvan het gemiddelde aankoopbedrag boven een bepaalde waarde ligt. Nadat we autotests hadden geschreven, controleerden we vooraf gedefinieerde voorbeelden, vaste benchmark-prestatieparameters en bovendien kregen we belastingstests.
5. Werken met autotests zou handig moeten zijn. De twee meest voorkomende acties zijn het uitvoeren van autotests en het genereren van testgegevens. Zo verschenen er twee hulpmodules in ons systeem: de lanceermodule en de datageneratiemodule.

   Het opstartprogramma wordt weergegeven als één generieke procedure met één invoertekstparameter. Als parameter kunt u een autotest-geheugensteuncode, pakketnaam, testnaam, autotest-instelling of een gereserveerd trefwoord doorgeven. De procedure selecteert en voert alle autotests uit die aan de voorwaarden voldoen.

   De module voor het genereren van gegevens wordt gepresenteerd als een pakket, waarin voor elk object van het te testen systeem (een tabel in de database) een speciale procedure is gemaakt die daar gegevens invoegt. In deze procedure worden de standaardwaarden tot het maximum gevuld, wat ervoor zorgt dat objecten letterlijk met een vingerklik kunnen worden gemaakt. En voor gebruiksgemak zijn er sjablonen voor de gegenereerde gegevens gemaakt. Maak bijvoorbeeld een klant van een bepaalde leeftijd aan met een testtelefoon en een afgeronde aankoop.

6. Autotests zouden binnen een redelijke tijd voor uw systeem moeten worden uitgevoerd en uitgevoerd. Daarom werd er een dagelijkse nachtelijke lancering georganiseerd, op basis van de resultaten waarvan een rapport over de resultaten wordt gegenereerd en per corporate mail naar het volledige ontwikkelteam wordt gestuurd. Na het herstellen van oude autotests en het maken van nieuwe was de totale looptijd 30 minuten. Zo'n optreden was voor iedereen geschikt, aangezien de lancering buiten kantooruren plaatsvond.

   Maar we moesten werken aan het optimaliseren van de werksnelheid. Het productieloyaliteitssysteem wordt 's nachts bijgewerkt. Als onderdeel van een van de releases moesten we 's nachts dringend wijzigingen aanbrengen. Een half uur wachten op de resultaten van autotests om drie uur 's ochtends maakte de persoon die verantwoordelijk was voor de vrijlating niet gelukkig (vurige groeten aan Alexei Vasyukov!), En de volgende ochtend werden er veel warme woorden tegen ons systeem gezegd. Maar als resultaat werd een norm van 5 minuten voor werk vastgesteld.

   Om de prestaties te versnellen, hebben we twee methoden gebruikt: we zijn begonnen met het uitvoeren van autotests in drie parallelle threads, omdat dit erg handig is vanwege de architectuur van ons loyaliteitssysteem. En we hebben de aanpak verlaten wanneer de autotest geen testgegevens voor zichzelf maakt, maar probeert iets geschikts in het systeem te vinden. Na het aanbrengen van wijzigingen werd de totale bedrijfstijd teruggebracht tot 3-4 minuten.

7. Een project met autotesten moet op verschillende stands ingezet kunnen worden. Aan het begin van de reis waren er pogingen om onze eigen batchbestanden te schrijven, maar het werd duidelijk dat een zelfgeschreven geautomatiseerde installatie een complete horror is, en we richtten ons op industriële oplossingen. Vanwege het feit dat het project direct veel code bevat (in de eerste plaats slaan we de code van autotests op) en heel weinig gegevens (de belangrijkste gegevens zijn metadata over autotests), bleek het heel gemakkelijk te integreren in de Liquibase-project.

   Het is een open source database-onafhankelijke bibliotheek voor het volgen, beheren en toepassen van wijzigingen in databaseschema's. Beheerd via de opdrachtregel of frameworks zoals Apache Maven. Het werkingsprincipe van Liquibase is vrij eenvoudig. We hebben een project op een bepaalde manier georganiseerd, dat bestaat uit wijzigingen of scripts die naar de doelserver moeten worden gerold, en besturingsbestanden die bepalen in welke volgorde en met welke parameters deze wijzigingen moeten worden geïnstalleerd.

   Op DBMS-niveau wordt een speciale tabel gemaakt waarin Liquibase het rollback-logboek opslaat. Elke wijziging heeft een berekende hash die telkens wordt vergeleken tussen het project en de status in de database. Dankzij Liquibase kunnen we wijzigingen in ons systeem eenvoudig uitrollen naar elk circuit. Autotests worden nu uitgevoerd op test- en release-loops, evenals op containers (persoonlijke loops van ontwikkelaars).

Laten we het hebben over de resultaten van het toepassen van ons unit-testsysteem.

1. Natuurlijk zijn we er in de eerste plaats van overtuigd dat we betere software zijn gaan ontwikkelen. Autotests worden dagelijks uitgevoerd en vinden bij elke release tientallen bugs. Bovendien zijn sommige van deze fouten slechts indirect gerelateerd aan de functionaliteit die we echt wilden veranderen. Er zijn sterke twijfels dat deze fouten zijn gevonden door handmatig testen.
2. Het team heeft er vertrouwen in gekregen dat bepaalde functionaliteiten goed werken... Allereerst gaat het om onze kritische processen. Zo hebben we de afgelopen zes maanden geen problemen gehad met de distributie van kortingen en bonussen per cheque, ondanks de wijzigingen die bij elke release zijn aangebracht, hoewel er in voorgaande perioden met enige regelmaat fouten zijn opgetreden
3. We zijn erin geslaagd om het aantal testiteraties te verminderen. Doordat autotests worden geschreven voor nieuwe functionaliteit, krijgen analisten en parttime testers een code van hogere kwaliteit, omdat het is al geverifieerd.
4. Een deel van de ontwikkelingen van geautomatiseerd testen wordt gebruikt door ontwikkelaars. Testgegevens op containers worden bijvoorbeeld gemaakt met behulp van de module voor het genereren van objecten.
5. Het is belangrijk dat we een "acceptatie" van het geautomatiseerde testsysteem door ontwikkelaars hebben ontwikkeld. Men begrijpt dat dit belangrijk en nuttig is. En uit eigen ervaring kan ik zeggen dat dit verre van het geval is. Autotests moeten worden geschreven, ze moeten worden onderhouden en ontwikkeld, de resultaten moeten worden geanalyseerd, en vaak zijn deze tijdskosten het gewoon niet waard. Het is veel gemakkelijker om naar de productie te gaan en daar problemen op te lossen. In ons land staan ​​ontwikkelaars in de rij en vragen om hun functionaliteit te dekken met autotests.

What's Next

Laten we het hebben over de ontwikkelingsplannen van het geautomatiseerde testproject.

Natuurlijk, zolang het Sportmaster-loyaliteitssysteem leeft en zich blijft ontwikkelen, kunnen autotesten ook bijna eindeloos worden ontwikkeld. Daarom is de belangrijkste ontwikkelingsrichting de uitbreiding van het dekkingsgebied.

Naarmate het aantal autotests toeneemt, zal de totale tijd van hun werk gestaag toenemen en zullen we opnieuw moeten terugkeren naar de kwestie van de prestaties. Hoogstwaarschijnlijk zal de oplossing zijn om het aantal parallelle threads te vergroten.

Maar dit zijn voor de hand liggende manieren van ontwikkeling. Als we het hebben over iets minder triviaals, benadrukken we het volgende:

1. Nu worden autotests beheerd op DBMS-niveau, d.w.z. kennis van PL/SQL is vereist voor succesvol werk. Indien nodig kan het systeembeheer (bijvoorbeeld het opstarten of aanmaken van metadata) worden afgenomen door een soort admin-paneel met behulp van Jenkins of iets dergelijks.
2. Iedereen houdt van kwantitatieve en kwalitatieve indicatoren. Voor automatisch testen is zo'n universele indicator Code Coverage of code coverage metric. Met behulp van deze indicator kunnen we bepalen welk percentage van de code van ons geteste systeem wordt gedekt door autotests. Vanaf versie 12.2 biedt Oracle de mogelijkheid om deze metriek te berekenen en stelt voor om het standaardpakket DBMS_PLSQL_CODE_COVERAGE te gebruiken.

   Ons autotestsysteem is iets meer dan een jaar oud en het is misschien tijd om de dekking te evalueren. In mijn laatste project (een project niet door Sportmaster) gebeurde dit. Een jaar nadat we aan autotests hadden gewerkt, gaf het management de taak om te beoordelen welk percentage van de code we bedekten. Met meer dan 1% dekking zou het management tevreden zijn. Wij, de ontwikkelaars, hadden een resultaat van ongeveer 10% verwacht. We hebben de codedekking verknoeid, gemeten en 20% gekregen. Om dat te vieren gingen we voor de prijs, maar hoe we ervoor gingen en waar we later naar toe gingen is een heel ander verhaal.

3. Autotests kunnen blootgestelde webservices testen. Met Oracle kunt u dit doen en zullen we een aantal problemen niet meer tegenkomen.
4. En natuurlijk kan ons geautomatiseerde testsysteem op een ander project worden toegepast. De oplossing die we hebben ontvangen is universeel en vereist alleen het gebruik van Oracle. Ik heb gehoord dat er interesse is in geautomatiseerd testen bij andere Sportmaster-projecten en misschien gaan we naar hen toe.

Bevindingen

Laten we samenvatten. Op het loyaliteitssysteemproject in Sportmaster zijn we erin geslaagd om een ​​geautomatiseerd testsysteem te implementeren. De basis is de utPLSQL-oplossing van Stephen Feuerstein. Rond utPLSQL bevindt zich de code voor autotests en zelfgeschreven hulpmodules: een launcher, een module voor het genereren van gegevens en andere. Autotests worden dagelijks uitgevoerd en, belangrijker nog, werken en profiteren. We zijn ervan overtuigd dat we begonnen zijn met het uitbrengen van software van hogere kwaliteit. Tegelijkertijd is de resulterende oplossing universeel en kan deze vrij worden toegepast op elk project waar het nodig is om geautomatiseerd testen op het Oracle DBMS te organiseren.

PS Dit artikel bleek niet erg specifiek te zijn: er is veel tekst en praktisch geen technische voorbeelden. Als het onderwerp wereldwijd interessant is, zijn we klaar om ermee door te gaan en komen we terug met een vervolg, waarin we u vertellen wat er de afgelopen zes maanden is veranderd en codevoorbeelden geven.

Schrijf opmerkingen als er punten zijn die in de toekomst moeten worden benadrukt, of vragen die openbaarmaking vereisen.

Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. Inloggen, Alsjeblieft.

Zullen we hier meer over schrijven?

• Ja natuurlijk

• Nee, dank u wel

12 gebruikers hebben gestemd. 4 gebruikers onthielden zich van stemming.

Bron: www.habr.com