{"id":37666,"date":"2019-10-31T22:18:55","date_gmt":"2019-10-31T19:18:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya\/"},"modified":"2019-10-31T22:18:55","modified_gmt":"2019-10-31T19:18:55","slug":"unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","title":{"rendered":"Enhedstest i DBMS \u2014 hvordan vi g\u00f8r det hos Sportmaster, del to","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

F\u00f8rste del \u2014 her<\/a><\/noindex>.<\/i><\/p>\n

\"Enhedstest<\/a><\/noindex><\/p>\n

Forestil dig situationen. Du st\u00e5r over for opgaven at udvikle ny funktionalitet. Du har nogle materialer fra dine forg\u00e6ngere. Hvis vi antager, at du ikke har nogen moralske forpligtelser, hvordan ville du s\u00e5 handle?<\/p>\n

Ofte bliver alle gamle materialer glemt, og alt begynder forfra. Ingen elsker at rode i andres kode, og hvis tiden er til det, hvorfor s\u00e5 ikke bruge den p\u00e5 at skabe sit eget system? Dette er en typisk tilgang og i mange tilf\u00e6lde en korrekt en. Men i vores projekt gjorde vi det anderledes. Vi lagde grundlaget for det fremtidige automatiserede testsystem p\u00e5 materialer fra unit-tests i utPLSQL fra vores forg\u00e6ngere, og derefter gik vi i gang med at arbejde i flere parallelle retninger.
\n<\/a><\/noindex><\/p>\n

    \n
  1. Genskabelse af gamle unit-tests.<\/b> Med genskabelse menes tilpasning af testene til den nuv\u00e6rende tilstand af loyalitetssystemet og tilpasning af testene til standarderne for utPLSQL. <\/li>\n
  2. L\u00f8sningen p\u00e5 problemet med forst\u00e5elsen af, hvilke metoder og processer der er d\u00e6kket af automatiserede tests. <\/b>Man skal enten holde denne information i hovedet eller drage konklusioner baseret direkte p\u00e5 koden til de automatiserede tests. Derfor besluttede vi at danne et katalog. Hver automatiseret test fik tildelt en unik mnemonic kode, vi dannede en beskrivelse og dokumenterede indstillingerne (for eksempel, under hvilke betingelser den skal k\u00f8res, eller hvad der skal ske, hvis testens k\u00f8rsel mislykkes). I bund og grund udfyldte vi metadata om de automatiserede tests og placerede disse metadata i standardtabellerne i utPLSQL-schemaet.<\/li>\n
  3. Definition af udvidelsesstrategi, dvs. valg af funktionalitet, der skal testes af automatiserede tests.<\/b> Vi besluttede at fokusere p\u00e5 tre ting: de nye forbedringer af systemet, h\u00e6ndelser fra produktionen og de centrale processer i systemet. P\u00e5 den m\u00e5de udvikler vi os parallelt med udgivelsen, sikrer h\u00f8jere kvalitet i den, samtidig med at vi udvider omfanget af regressionstests og sikrer systemets p\u00e5lidelighed p\u00e5 kritiske omr\u00e5der. Det f\u00f8rste s\u00e5danne flaskehals var processen til fordeling af rabatter og bonusser p\u00e5 kvitteringen.<\/li>\n
  4. Naturligvis tog vi fat p\u00e5 at udvikle nye automatiserede tests. <\/b>En af de f\u00f8rste opgaver efter udgivelsen var at vurdere ydeevnen af de foruddefinerede udtr\u00e6k i lojalitetssystemet. I vores projekt er der en sektion med faste SQL-foresp\u00f8rgsler, der udv\u00e6lger kunder baseret p\u00e5 specifikationer. For eksempel at f\u00e5 en liste over alle kunder, hvis seneste k\u00f8b var i en bestemt by, eller en liste over kunder, hvis gennemsnitlige k\u00f8b er over en bestemt v\u00e6rdi. Efter at have skrevet automatiserede tests, kontrollerede vi de foruddefinerede udtr\u00e6k, fastsatte referenceparametre for ydeevnen, og vi fik desuden mulighed for belastningstestning.<\/li>\n
  5. Arbejdet med automatiserede tests skal v\u00e6re brugervenligt<\/b>. De to mest udf\u00f8rte handlinger er: at starte automatiserede tests og oprette testdata. Derfor blev der oprettet to hj\u00e6lpemoduler i vores system: et startmodul og et datagenereringsmodul.\n

    Startmodulet er udformet som en universel procedure med en enkelt tekstparameter som input. Som parameter kan man angive mnemonic-koden for den automatiserede test, navnet p\u00e5 pakken, navnet p\u00e5 testen, indstillingerne for den automatiserede test eller et reserveret n\u00f8gleord. Proceduren udv\u00e6lger og starter alle automatiserede tests, der opfylder betingelserne.<\/p>\n

    Datagenereringsmodulet er pr\u00e6senteret i form af en pakke, hvor der for hvert objekt i det testede system (tabel i databasen) er oprettet en s\u00e6rlig procedure, der inds\u00e6tter data der. I denne procedure er de standardv\u00e6rdier maksimalt udfyldt, hvilket muligg\u00f8r oprettelsen af objekter bogstaveligt talt med et fingerknips. For brugervenlighed er der blevet oprettet skabeloner til de oprettede data. For eksempel at oprette en kunde af en bestemt alder med et testtelefonnummer og et gennemf\u00f8rt k\u00f8b.<\/li>\n

  6. Automatiske tests skal startes og fungere inden for acceptabel tid for dit system. <\/b>Derfor blev der arrangeret et dagligt natk\u00f8rsel, hvis resultater danner en rapport, der sendes til hele udviklingsteamet via virksomhedens e-mail. Efter at have genoprettet gamle automatiserede tests og oprettet nye, var den samlede k\u00f8retid 30 minutter. En s\u00e5dan ydeevne tilfredsstillede alle, da k\u00f8rslen fandt sted uden for arbejdstiden.\n

    Men m\u00e5tte arbejde p\u00e5 at optimere hastigheden. Opdateringen af loyalitetssystemet finder sted om natten. Under et af frigivelserne m\u00e5tte der laves hurtige \u00e6ndringer om natten. Den halvtime lange ventetid p\u00e5 resultaterne fra autotests i tre om natten gjorde ikke den ansvarlige for udgivelsen glad (et varmt hej til Alexey Vasyukov!), men n\u00e6ste morgen blev der sagt mange p\u00e6ne ord om vores system. Resultatet var, at der blev fastsat en 5-minutters norm for arbejdet.<\/p>\n

    For at \u00f8ge ydeevnen anvendte vi to metoder: autotests blev k\u00f8rt i tre parallelle processer, hvilket er meget praktisk p\u00e5 grund af arkitekturen i vores loyalitetssystem. Vi har ogs\u00e5 opgivet tilgangen, hvor autotests ikke laver testdata til sig selv, men fors\u00f8ger at finde noget passende i systemet. Efter \u00e6ndringerne blev den samlede behandlingstid reduceret til 3-4 minutter.<\/li>\n

  7. Projektet med autotests skal kunne implementeres p\u00e5 forskellige milj\u00f8er.<\/b> I starten var der fors\u00f8g p\u00e5 at skrive egne batch-filer, men det blev klart, at en skr\u00e6ddersyet automatiseret installation var en komplet katastrofe, og vi tiltrak os opm\u00e6rksomhed mod industrielle l\u00f8sninger. Da projektet indeholder meget kode (f\u00f8rst og fremmest opbevarer vi koden til autotests) og meget lidt data (de vigtigste data er metadata om autotests), var det meget enkelt at implementere Liquibase i projektet.\n

    Det er et databasen-uafh\u00e6ngigt biblioteksprogram med \u00e5ben kilde, der bruges til at spore, administrere og anvende \u00e6ndringer i databaseskemaer. Det styres via kommandolinjen eller rammer som Apache Maven. Princippet for Liquibase er ret enkelt. Vi har et projekt, der er organiseret p\u00e5 en bestemt m\u00e5de, som best\u00e5r af \u00e6ndringer eller scripts, der skal anvendes p\u00e5 den m\u00e5lserver, samt styringsfiler, der definerer, i hvilken r\u00e6kkef\u00f8lge og med hvilke parametre de \u00e6ndringer skal anvendes. <\/p>\n

    P\u00e5 databasesystemniveau oprettes der et specielt tabel, hvor Liquibase opbevarer loggen over \u00e6ndringer. Hver \u00e6ndring har en beregnet hash, som konstant sammenlignes mellem projektet og tilstanden i databasen. Takket v\u00e6re Liquibase kan vi let anvende \u00e6ndringer i vores system p\u00e5 enhver kontur. Automatisk testk\u00f8rsel foreg\u00e5r nu p\u00e5 test- og produktionskonturer samt p\u00e5 containere (personlige konturer for udviklere).<\/li>\n<\/ol>\n

    \"Enhedstest
    \n
    \nLad os tale om resultaterne af anvendelsen af vores enhedstestsystem. <\/p>\n

      \n
    1. Selvf\u00f8lgelig er vi f\u00f8rst og fremmest overbeviste om, at vi er begyndt at udvikle mere kvalitetsbevidst software. Automatisk test k\u00f8res dagligt og ved hver release finder den dusinvis af fejl. Desuden er nogle af disse fejl kun indirekte relateret til den funktionalitet, vi faktisk \u00f8nskede at \u00e6ndre. Der er store tvivl om, at disse fejl ville v\u00e6re blevet fundet ved manuel testning. <\/li>\n
    2. Teamet har f\u00e5et selvtillid til, at den specifikke funktionalitet fungerer korrekt... Dette g\u00e6lder is\u00e6r vores kritiske processer. For eksempel har vi i l\u00f8bet af det sidste halve \u00e5r ikke haft problemer med distribution af rabatter og bonusser i kvitteringen, p\u00e5 trods af \u00e6ndringer ved hver release, selvom der i tidligere perioder med j\u00e6vne mellemrum opstod fejl.<\/li>\n
    3. Vi har form\u00e5et at reducere antallet af testiterations. Takket v\u00e6re at de automatiske tests skrives for den nye funktionalitet, modtager analytikerne og testerne kode af h\u00f8jere kvalitet, da det allerede er blevet testet.<\/li>\n
    4. Nogle af resultaterne fra automatiseret testning anvendes af udviklerne. For eksempel oprettes testdata p\u00e5 containere ved hj\u00e6lp af en modul til objektgenerering.<\/li>\n
    5. Det er vigtigt, at vi har f\u00e5et accept af systemet for automatiseret testning fra udviklerne. Der er en forst\u00e5else for, at det er vigtigt og nyttigt. Men ud fra min egen erfaring kan jeg sige, at dette slet ikke er tilf\u00e6ldet. Automatiske tests skal skrives, de skal vedligeholdes og udvikles, resultaterne skal analyseres, og ofte er disse tidsinvesteringer simpelthen ikke det v\u00e6rd. Det er langt nemmere at g\u00e5 til produktionen og h\u00e5ndtere problemerne der. Vores udviklere st\u00e5r i k\u00f8 og beder om at f\u00e5 deres funktionalitet d\u00e6kket af automatiserede tests.<\/li>\n<\/ol>\n

      vil v\u00e6re udsolgt<\/h2>\n

      \n\"Enhedstest
      \n
      \nLad os tale om udviklingsplanerne for projektet for automatiseret testning.<\/p>\n

      Uden tvivl, s\u00e5 l\u00e6nge Sportmaster's loyalitetsprogram er aktivt og forts\u00e6tter med at udvikle sig, kan vi n\u00e6sten uendeligt videreudvikle autotests. Derfor er den prim\u00e6re udviklingsretning at udvide d\u00e6kningen.<\/p>\n

      Efterh\u00e5nden som antallet af autotests stiger, vil den samlede k\u00f8retid ogs\u00e5 stigende, og vi m\u00e5 igen vende tilbage til sp\u00f8rgsm\u00e5let om ydeevne. Sandsynligvis vil l\u00f8sningen v\u00e6re at \u00f8ge antallet af parallelle tr\u00e5de.<\/p>\n

      Men det er \u00e5benlyse udviklingsveje. Hvis vi skal tale om noget mere utraditionelt, s\u00e5 fremh\u00e6ver vi f\u00f8lgende:<\/p>\n

        \n
      1. I \u00f8jeblikket h\u00e5ndteres autotests p\u00e5 niveauet for databasesystemet, dvs. der kr\u00e6ves kendskab til PL\/SQL for at arbejde succesfuldt. Efter behov kan administrationen af systemet (f.eks. udf\u00f8relse af k\u00f8rsel eller oprettelse af metadata) outsources til et admin-panel, som f.eks. Jenkins eller noget lignende.<\/li>\n
      2. Alle elsker kvantitative og kvalitative m\u00e5linger. For automatiseret test er en s\u00e5dan universel m\u00e5ling Code Coverage eller kode d\u00e6kke metrics. Ved hj\u00e6lp af denne m\u00e5ling kan vi bestemme, hvilken procentdel af koden i vores testede system d\u00e6kkes af autotests. Fra version 12.2 tilbyder Oracle muligheder for beregning af denne m\u00e5ling og anbefaler at bruge standardpakken DBMS_PLSQL_CODE_COVERAGE.\n

        Vores autotestsystem er lidt over et \u00e5r gammelt, og m\u00e5ske er det nu det rette tidspunkt at vurdere d\u00e6kningen. I mit tidligere projekt (som ikke var Sportmaster) viste det sig at v\u00e6re tilf\u00e6ldet. Et \u00e5r efter arbejdet med autotests satte ledelsen opgaven med at vurdere, hvor stor en del af koden vi d\u00e6kker. Ved en d\u00e6kning p\u00e5 over 1% ville ledelsen v\u00e6re tilfreds. Vi, udviklerne, forventede et resultat p\u00e5 omkring 10%. Vi tilknyttede code coverage, m\u00e5lte og fik 20%. I gl\u00e6den skyndte vi os for at f\u00e5 en bonus, men hvordan vi fik den og hvor vi gik hen senere, er en helt anden historie.<\/li>\n

      3. Autotests kan kontrollere de udstillede webtjenester. Oracle giver os helt klart mulighed for at g\u00f8re dette, og vi vil ikke l\u00e6ngere st\u00f8de p\u00e5 en r\u00e6kke problemer. <\/li>\n
      4. Og selvf\u00f8lgelig kan vores automatiserede testsystem anvendes i et andet projekt. Den l\u00f8sning, vi har udviklet, er universel og kr\u00e6ver kun brugen af Oracle. Jeg har h\u00f8rt, at der er interesse for automatiseret testning i andre projekter hos Sportmaster, og m\u00e5ske skal vi tage over til dem.<\/li>\n<\/ol>\n

        <\/p>\n

        Konklusioner<\/h2>\n

        \nLad os opsummere. I projektet med loyalitetssystemet i Sportmaster har vi form\u00e5et at implementere et automatiseret testsystem. Grundlaget for det er l\u00f8sningen utPLSQL fra Steven Feuerstein. Omkring utPLSQL er koden til autostests og hj\u00e6lpemodulerne: startmodul, datagenereringsmodul og andre. Autotests k\u00f8res dagligt, og vigtigst af alt, de fungerer og giver v\u00e6rdi. Vi er overbeviste om, at vi er begyndt at levere software af h\u00f8jere kvalitet. Den l\u00f8sning, vi har udviklet, er universel og kan frit anvendes i ethvert projekt, hvor der er behov for at organisere automatiseret testning p\u00e5 Oracle DB.<\/p>\n

        P.S. Denne artikel blev ikke s\u00e6rlig konkret: der er meget tekst og n\u00e6sten ingen tekniske eksempler. Hvis emnet overordnet set er interessant, er vi klar til at forts\u00e6tte og vende tilbage med et opslag, hvor vi fort\u00e6ller, hvad der er \u00e6ndret i de seneste seks m\u00e5neder og medbringer kodeeksempler.<\/p>\n

        Skriv kommentarer, hvis der er punkter, vi skal fokusere p\u00e5 i fremtiden, eller sp\u00f8rgsm\u00e5l, der kr\u00e6ver uddybning.<\/i><\/p>\n

        Kun registrerede brugere kan deltage i unders\u00f8gelsen. Log ind<\/a><\/noindex>, please.<\/p>\n

        Skal vi skrive videre om dette?<\/h2>\n