{"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\/de\/blog\/administrirovanie\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","title":{"rendered":"Unit-Tests in DBMS \u2013 wie wir das im Sportmaster machen, Teil zwei","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Der erste Teil \u2014 hier<\/a><\/noindex>.<\/i><\/p>\n

\"Unit-Tests<\/a><\/noindex><\/p>\n

Stellen Sie sich die Situation vor. Sie stehen vor der Aufgabe, eine neue Funktionalit\u00e4t zu entwickeln. Sie haben Material von Ihren Vorg\u00e4ngern. Angenommen, Sie haben keine moralischen Verpflichtungen, wie w\u00fcrden Sie handeln?<\/p>\n

Meistens geraten alle alten Entwicklungen in Vergessenheit und alles beginnt von neuem. Niemand mag es, sich in fremdem Code zu verlieren, und wenn man Zeit hat, warum nicht ein eigenes System schaffen? Dies ist ein typischer Ansatz und in vielerlei Hinsicht richtig. Aber in unserem Projekt haben wir es anders gemacht. Wir haben das Fundament f\u00fcr das zuk\u00fcnftige System automatischer Tests auf den Grundlagen der Unit-Tests auf utPLSQL von unseren Vorg\u00e4ngern aufgebaut und dann in mehreren parallelen Richtungen gearbeitet.
\n<\/a><\/noindex><\/p>\n

    \n
  1. Wiederherstellung alter Unit-Tests.<\/b> Unter Wiederherstellung verstehen wir die Anpassung der Tests an den aktuellen Zustand des Loyalit\u00e4tssystems und die Anpassung der Tests an die Standards von utPLSQL. <\/li>\n
  2. L\u00f6sung des Problems des Verst\u00e4ndnisses, welche Methoden und Prozesse durch automatisierte Tests abgedeckt sind. <\/b>Wir m\u00fcssen entweder diese Informationen im Kopf behalten oder Schlussfolgerungen basierend auf dem Code der automatisierten Tests ziehen. Daher haben wir beschlossen, ein Verzeichnis zu erstellen. Jeder automatisierte Test erhielt einen einzigartigen Mnemonik-Code, wir formulierten eine Beschreibung und hielten die Einstellungen fest (zum Beispiel unter welchen Bedingungen er gestartet werden soll oder was passieren sollte, wenn der Test fehlgeschlagen ist). Im Wesentlichen haben wir Metadaten \u00fcber die automatisierten Tests gesammelt und diese Metadaten in die Standardtabellen des utPLSQL-Schemas eingef\u00fcgt.<\/li>\n
  3. Definition der Erweiterungsstrategie, d.h. Auswahl der Funktionalit\u00e4t, die durch automatisierte Tests \u00fcberpr\u00fcft werden soll.<\/b> Wir haben beschlossen, uns auf drei Dinge zu konzentrieren: neue Erweiterungen des Systems, Vorf\u00e4lle aus der Produktion und Schl\u00fcsselprozesse des Systems. Auf diese Weise entwickeln wir uns parallel mit dem Release weiter, gew\u00e4hrleisten eine h\u00f6here Qualit\u00e4t und erweitern gleichzeitig das Regressionsvolumen und sichern die Zuverl\u00e4ssigkeit des Systems an kritischen Stellen. Der erste Engpass war der Prozess der Verteilung von Rabatten und Boni auf den Beleg.<\/li>\n
  4. Nat\u00fcrlich haben wir uns mit der Entwicklung neuer automatisierter Tests besch\u00e4ftigt. <\/b>Eine der ersten Release-Aufgaben bestand in der Bewertung der Leistung vordefinierter Abfragen des Loyalit\u00e4tssystems. In unserem Projekt gibt es einen Block fest definierter SQL-Abfragen, die Kunden nach bestimmten Kriterien ausw\u00e4hlen. Zum Beispiel eine Liste aller Kunden zu erhalten, deren letzter Einkauf in einer bestimmten Stadt erfolgt ist, oder eine Liste von Kunden, deren durchschnittlicher Einkaufswert \u00fcber einem bestimmten Betrag liegt. Nachdem wir automatische Tests geschrieben hatten, haben wir die vordefinierten Abfragen \u00fcberpr\u00fcft, die Referenzparameter der Leistung festgehalten, und zudem unser Lasttestverfahren eingef\u00fchrt.<\/li>\n
  5. Die Arbeit mit automatischen Tests sollte benutzerfreundlich sein.<\/b>Am h\u00e4ufigsten werden zwei Aktionen durchgef\u00fchrt: das Starten automatischer Tests und das Erstellen von Testdaten. So wurden in unserem System zwei Hilfsmodulen geschaffen: ein Startmodul und ein Datenmodul.\n

    Das Startmodul wird als eine universelle Prozedur mit einem Texteingabeparameter dargestellt. Als Parameter kann der Mnemonik-Code des automatischen Tests, der Paketname, der Name des Tests, die Konfiguration des automatischen Tests oder ein reserviertes Schl\u00fcsselwort \u00fcbergeben werden. Die Prozedur w\u00e4hlt und startet alle automatischen Tests, die die Bedingungen erf\u00fcllen.<\/p>\n

    Das Datenmodul wird in Form eines Pakets dargestellt, in dem f\u00fcr jedes Objekt des zu testenden Systems (Tabelle in der DB) eine spezielle Prozedur erstellt wurde, die dort Daten einf\u00fcgt. In dieser Prozedur sind die Standardwerte maximal ausgef\u00fcllt, was die Erstellung von Objekten buchst\u00e4blich auf Knopfdruck erm\u00f6glicht. F\u00fcr die Benutzerfreundlichkeit wurden Vorlagen f\u00fcr die zu erstellenden Daten erstellt. Zum Beispiel, einen Kunden bestimmten Alters mit einer Testtelefonnummer und einem get\u00e4tigten Einkauf zu erstellen.<\/li>\n

  6. Automatische Tests sollten in einer f\u00fcr Ihr System akzeptablen Zeit gestartet und ausgef\u00fchrt werden. <\/b>Daher wurde ein t\u00e4glicher n\u00e4chtlicher Start organisiert, nach dessen Ergebnis ein Bericht \u00fcber die Ergebnisse erstellt und an das gesamte Entwicklungsteam \u00fcber die Unternehmens-E-Mail versendet wird. Nach der Wiederherstellung alter automatischer Tests und der Erstellung neuer hatte die Gesamtdauer 30 Minuten betragen. Diese Leistung war f\u00fcr alle akzeptabel, da der Start au\u00dferhalb der Arbeitszeiten stattfand.\n

    Aber die Optimierung der Geschwindigkeit erforderte einige Arbeit. Das Update des Loyalit\u00e4tssystems im Produktionsumfeld erfolgt nachts. Im Rahmen eines der Releases mussten wir nachts kurzfristig \u00c4nderungen vornehmen. Eine halbe Stunde Warten auf die Ergebnisse der automatisierten Tests um drei Uhr morgens machte die verantwortliche Person f\u00fcr das Release nicht gl\u00fccklich (liebe Gr\u00fc\u00dfe an Alexey Vasyukov!), und am n\u00e4chsten Morgen wurden viele warme Worte in Richtung unseres Systems ausgesprochen. Letztendlich wurde eine Norm von f\u00fcnf Minuten f\u00fcr die Bearbeitung festgelegt.<\/p>\n

    Zur Beschleunigung der Leistung haben wir zwei Methoden verwendet: Die automatisierten Tests laufen nun in drei parallelen Streams, was aufgrund der Architektur unseres Loyalit\u00e4tssystems sehr praktisch ist. Au\u00dferdem haben wir auf den Ansatz verzichtet, dass der automatisierte Test keine Testdaten f\u00fcr sich selbst erstellt, sondern versucht, etwas Passendes im System zu finden. Nach den \u00c4nderungen wurde die Gesamtdauer auf 3-4 Minuten reduziert.<\/li>\n

  7. Das Projekt mit den automatisierten Tests muss auf verschiedenen St\u00e4nden einsatzbereit sein.<\/b> Zu Beginn gab es Versuche, eigene Batch-Skripte zu schreiben, aber es wurde klar, dass die selbstgeschriebene automatisierte Installation ein v\u00f6lliger Albtraum war, und wir w\u00e4hlten stattdessen industrielle L\u00f6sungen. Da im Projekt sehr viel direkt Code vorhanden ist (vor allem speichern wir den Code der automatisierten Tests) und nur sehr wenige Daten vorhanden sind (die Hauptdaten sind Metadaten \u00fcber die automatisierten Tests), erwies sich die Implementierung von Liquibase im Projekt als sehr einfach.\n

    Dies ist eine datenbankunabh\u00e4ngige Open-Source-Bibliothek zum Verfolgen, Verwalten und Anwenden von \u00c4nderungen am Datenbankschema. Sie wird \u00fcber die Kommandozeile oder Frameworks wie Apache Maven verwaltet. Das Prinzip von Liquibase ist ziemlich einfach. Wir haben ein nach bestimmten Kriterien organisiertes Projekt, das aus \u00c4nderungen oder Skripten besteht, die auf den Zielserver angewendet werden m\u00fcssen, sowie Steuerdateien, die definieren, in welcher Reihenfolge und mit welchen Parametern diese \u00c4nderungen installiert werden sollen. <\/p>\n

    Auf der Ebene der Datenbank wird eine spezielle Tabelle erstellt, in der Liquibase die \u00c4nderungsprotokolle speichert. Jede \u00c4nderung hat einen berechneten Hash, der jedes Mal zwischen dem Projekt und dem Zustand in der Datenbank verglichen wird. Dank Liquibase k\u00f6nnen wir \u00c4nderungen an unserem System problemlos in jede Umgebung \u00fcbernehmen. Die automatisierten Tests werden derzeit in Test- und Release-Umgebungen sowie in Containern (pers\u00f6nliche Entwicklungsumgebungen) gestartet.<\/li>\n<\/ol>\n

    \"Unit-Tests
    \n
    \nLassen Sie uns also \u00fcber die Ergebnisse der Anwendung unseres Unit-Test-Systems sprechen. <\/p>\n

      \n
    1. Zun\u00e4chst einmal sind wir \u00fcberzeugt, dass wir mit der Entwicklung qualitativ hochwertigerer Software begonnen haben. Die automatisierten Tests werden t\u00e4glich durchgef\u00fchrt und finden bei jeder Ver\u00f6ffentlichung Dutzende von Fehlern. Dabei stehen einige dieser Fehler nur indirekt im Zusammenhang mit der Funktionalit\u00e4t, die wir tats\u00e4chlich \u00e4ndern wollten. Es bestehen gro\u00dfe Zweifel, dass diese Fehler durch manuelle Tests entdeckt wurden. <\/li>\n
    2. Das Team hat das Vertrauen gewonnen, dass spezifische Funktionen korrekt arbeiten\u2026 Dies betrifft insbesondere unsere kritischen Prozesse. Zum Beispiel hatten wir in den letzten sechs Monaten keine Probleme mit der Verteilung von Rabatten und Boni auf Rechnungen, trotz regelm\u00e4\u00dfiger \u00c4nderungen in jeder Ver\u00f6ffentlichung, w\u00e4hrend wir in fr\u00fcheren Zeitr\u00e4umen mit gewissen Fehlern konfrontiert waren.<\/li>\n
    3. Es ist uns gelungen, die Anzahl der Testiterations zu reduzieren. Da die automatisierten Tests f\u00fcr neue Funktionen geschrieben werden, erhalten die Analysten und gleichzeitig Tester Code von h\u00f6herer Qualit\u00e4t, da dieser bereits \u00fcberpr\u00fcft wurde.<\/li>\n
    4. Ein Teil der Entwicklungen im Bereich der automatisierten Tests wird von den Entwicklern genutzt. Zum Beispiel werden Testdaten in Containern mithilfe des Moduls zur Objekterzeugung erstellt.<\/li>\n
    5. Es ist wichtig zu erw\u00e4hnen, dass sich eine Akzeptanz des automatisierten Testsystems seitens der Entwickler entwickelt hat. Es besteht das Verst\u00e4ndnis, dass dies wichtig und n\u00fctzlich ist. Aus eigener Erfahrung kann ich jedoch sagen, dass dies bei weitem nicht so ist. Automatisierte Tests m\u00fcssen geschrieben, gewartet und weiterentwickelt werden; die Ergebnisse m\u00fcssen analysiert werden, und oft sind diese zeitlichen Aufw\u00e4nde einfach nicht gerechtfertigt. Es ist viel einfacher, in der Produktion nach Problemen zu suchen. Bei uns stellen sich jedoch die Entwickler in eine Schlange und bitten darum, ihre Funktionalit\u00e4t durch automatisierte Tests abdecken zu lassen.<\/li>\n<\/ol>\n

      Was kommt als n\u00e4chstes<\/h2>\n

      \n\"Unit-Tests
      \n
      \nLassen Sie uns \u00fcber die Pl\u00e4ne zur Weiterentwicklung des Projekts zur automatisierten Testung sprechen.<\/p>\n

      Nat\u00fcrlich kann das Testautomatisierungssystem von Sportmaster, solange es lebt und sich weiterentwickelt, nahezu endlos weiterentwickelt werden. Daher ist die Hauptentwicklungsrichtung die Erweiterung des Testabdeckungsbereichs.<\/p>\n

      Mit zunehmender Anzahl an Testautomatisierungen wird die Gesamtzeit f\u00fcr deren Ausf\u00fchrung konstant steigen, und wir werden erneut auf das Thema Performance zur\u00fcckkommen m\u00fcssen. Wahrscheinlich wird die L\u00f6sung in der Erh\u00f6hung der Anzahl paralleler Threads liegen.<\/p>\n

      Aber das sind offensichtliche Entwicklungsm\u00f6glichkeiten. Wenn wir \u00fcber etwas weniger Triviales sprechen, heben wir Folgendes hervor:<\/p>\n

        \n
      1. Zurzeit erfolgt das Management der Testautomatisierungen auf der Ebene der Datenbankverwaltungssysteme, d.h. es sind PL\/SQL-Kenntnisse erforderlich, um erfolgreich zu arbeiten. Bei Bedarf kann das Systemmanagement (z.B. das Ausf\u00fchren von Tests oder das Erstellen von Metadaten) in ein Administrations-Tool ausgelagert werden, indem man Jenkins oder etwas \u00c4hnliches verwendet.<\/li>\n
      2. Alle lieben quantitative und qualitative Kennzahlen. F\u00fcr automatisierte Tests ist eine solche universelle Kennzahl die Code Coverage oder die Metrik der Codeabdeckung. Mithilfe dieser Kennzahl k\u00f6nnen wir bestimmen, welcher Prozentsatz des Codes unseres zu testenden Systems durch Testautomatisierungen abgedeckt wird. Seit Version 12.2 bietet Oracle M\u00f6glichkeiten zur Berechnung dieser Metrik an und empfiehlt die Verwendung des Standardpakets DBMS_PLSQL_CODE_COVERAGE.\n

        Unseres Testautomatisierungssystems ist etwas mehr als ein Jahr alt und vielleicht ist jetzt der beste Zeitpunkt f\u00fcr eine Einsch\u00e4tzung der Abdeckung. In meinem vorherigen Projekt (wobei es sich nicht um Sportmaster handelt) war das ebenfalls der Fall. Ein Jahr nach dem Beginn der Arbeit an den Testautomatisierungen gab die Gesch\u00e4ftsf\u00fchrung den Auftrag, den Prozentsatz des abgedeckten Codes zu bewerten. Bei \u00fcber 1% Abdeckung w\u00e4re die Gesch\u00e4ftsf\u00fchrung zufrieden gewesen. Wir Entwickler erwarteten jedoch ein Ergebnis von etwa 10%. Wir haben die Code Coverage integriert, gemessen und kamen auf 20%. In unserer Freude sind wir zur Pr\u00e4mie gegangen, aber wie wir das gemacht haben und wohin wir danach gegangen sind, ist eine ganz andere Geschichte.<\/li>\n

      3. Testautomatisierungen k\u00f6nnen die bereitgestellten Webdienste \u00fcberpr\u00fcfen. Oracle erlaubt dies durchaus, und wir werden nicht mehr mit einer Reihe von Problemen konfrontiert. <\/li>\n
      4. Und nat\u00fcrlich kann unser automatisiertes Testsystem auch in einem anderen Projekt angewendet werden. Die L\u00f6sung, die wir gefunden haben, ist universell und erfordert lediglich die Nutzung von Oracle. Ich habe geh\u00f6rt, dass es in anderen Projekten von Sportmaster Interesse an automatisiertem Testen gibt und m\u00f6glicherweise werden wir dorthin gehen.<\/li>\n<\/ol>\n

        <\/p>\n

        Das DBMS Tarantool ist ein attraktives, zukunftstr\u00e4chtiges Produkt zur Erstellung von hochbelasteten Anwendungen.<\/h2>\n

        \nLassen Sie uns zusammenfassen. In dem Projekt zur Kundenbindung bei Sportmaster ist es uns gelungen, ein automatisiertes Testsystem zu implementieren. Die Basis daf\u00fcr bildet die utPLSQL-L\u00f6sung von Steven Feuerstein. Rund um utPLSQL sind der Code der automatisierten Tests und die unterst\u00fctzenden selbstgeschriebenen Module angeordnet: das Startmodul, das Modul zur Datengenerierung und andere. Die automatisierten Tests werden t\u00e4glich ausgef\u00fchrt und, was am wichtigsten ist, sie funktionieren und bringen Nutzen. Wir sind \u00fcberzeugt, dass wir begonnen haben, Software von h\u00f6herer Qualit\u00e4t zu ver\u00f6ffentlichen. Dabei ist die erhaltene L\u00f6sung universell und kann problemlos in jedem Projekt verwendet werden, in dem automatisiertes Testen auf Oracle-Datenbanken ben\u00f6tigt wird.<\/p>\n

        P.S. Dieser Artikel ist nicht sehr konkret geworden: Es gibt viel Text und praktisch keine technischen Beispiele. Wenn das Thema global interessant ist, sind wir bereit, es fortzusetzen und mit weiteren Informationen zur\u00fcckzukehren, in denen wir erl\u00e4utern, was sich in den letzten sechs Monaten ge\u00e4ndert hat und Beispiele f\u00fcr Code bringen.<\/p>\n

        Schreiben Sie Kommentare, wenn es Punkte gibt, die in Zukunft hervorgehoben werden sollten, oder Fragen, die beantwortet werden m\u00fcssen.<\/i><\/p>\n

        Nur registrierte Benutzer k\u00f6nnen an der Umfrage teilnehmen. Bitte einloggen<\/a><\/noindex>.<\/p>\n

        Schreiben wir weiter dar\u00fcber?<\/h2>\n