{"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 Datenbanksystemen \u2013 so machen wir das bei Sportmaster, 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 eine Situation vor. Sie stehen vor der Aufgabe, eine neue Funktionalit\u00e4t zu entwickeln. Sie haben die Arbeiten Ihrer Vorg\u00e4nger vorliegen. Angenommen, Sie haben keine moralischen Verpflichtungen, wie w\u00fcrden Sie handeln?<\/p>\n

In den meisten F\u00e4llen geraten alle alten Arbeiten in Vergessenheit und alles beginnt von vorne. Niemand mag es, sich in fremden Codes zurechtzufinden, und wenn Sie Zeit haben, warum nicht ein eigenes System entwickeln? Dies ist ein typischer Ansatz und er ist in vielerlei Hinsicht richtig. Doch in unserem Projekt haben wir es anders gemacht. Wir haben die Erfahrungen aus den Unit-Tests mit utPLSQL unserer Vorg\u00e4nger als Grundlage f\u00fcr das zuk\u00fcnftige automatisierte Testssystem verwendet und sind dann in mehreren parallelen Richtungen weitergearbeitet.
\n<\/a><\/noindex><\/p>\n

    \n
  1. Wiederherstellung alter Unit-Tests.<\/b> Unter Wiederherstellung verstehen wir die Anpassung der Tests an den bestehenden 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 wir mit automatisierten Tests abdecken. <\/b>Wir m\u00fcssen entweder diese Informationen im Hinterkopf behalten oder Schlussfolgerungen auf der Grundlage des Codes der automatisierten Tests ziehen. Daher haben wir entschieden, ein Verzeichnis zu erstellen. Jedem automatisierten Test haben wir einen eindeutigen Mnemonik-Code zugewiesen, eine Beschreibung erstellt und die Einstellungen dokumentiert (z. B. unter welchen Bedingungen er ausgef\u00fchrt werden sollte oder was geschehen sollte, wenn der Test fehlgeschlagen ist). Im Grunde haben wir die Metadaten der automatisierten Tests ausgef\u00fcllt und diese Metadaten in die Standardtabellen des utPLSQL-Schemas eingef\u00fcgt.<\/li>\n
  3. Definition der Expansionsstrategie, d.h. Auswahl der Funktionalit\u00e4ten, die von automatisierten Tests \u00fcberpr\u00fcft werden sollen.<\/b> Wir haben uns entschieden, auf drei Aspekte zu achten: neue Systemanpassungen, Vorf\u00e4lle aus der Produktion und wichtige Prozesse des Systems. Auf diese Weise entwickeln wir uns parallel zum Release weiter, gew\u00e4hrleisten eine h\u00f6here Qualit\u00e4t und erweitern gleichzeitig den Umfang des Regressionstests, um die Zuverl\u00e4ssigkeit des Systems an kritischen Stellen sicherzustellen. Der erste Engpass war der Prozess der Verteilung von Rabatten und Boni im Warenkorb.<\/li>\n
  4. Selbstverst\u00e4ndlich haben wir uns der Entwicklung neuer automatisierter Tests gewidmet. <\/b>Eine der ersten Release-Aufgaben bestand darin, die Leistung vordefinierter Auswahlproben des Loyalit\u00e4tssystems zu bewerten. In unserem Projekt gibt es einen Block festgelegter SQL-Anfragen, die Kunden anhand bestimmter Kriterien filtern. Beispielsweise k\u00f6nnen wir eine Liste aller Kunden abrufen, deren letzter Einkauf in einer bestimmten Stadt stattgefunden hat, oder eine Liste von Kunden, deren durchschnittlicher Einkaufswert \u00fcber einem bestimmten Betrag liegt. Mit den entwickelten automatisierten Tests haben wir die vordefinierten Auswahlproben \u00fcberpr\u00fcft, die Referenzparameter der Leistung festgelegt und zus\u00e4tzlich Lasttests durchgef\u00fchrt.<\/li>\n
  5. Die Arbeit mit automatisierten Tests sollte benutzerfreundlich sein.<\/b>Am h\u00e4ufigsten werden zwei Aktionen durchgef\u00fchrt: das Starten der automatisierten Tests und das Erstellen von Testdaten. Daher haben wir in unserem System zwei unterst\u00fctzende Module implementiert: das Modulanlaufmodul und das Datengenerierungsmodul.\n

    Das Startmodul wird als eine universelle Prozedur mit einem Eingabetextparameter bereitgestellt. Als Parameter k\u00f6nnen der Mnemonik-Code des Autotests, der Name des Pakets, der Name des Tests, die Konfiguration des Autotests oder ein reserviertes Schl\u00fcsselwort \u00fcbergeben werden. Die Prozedur w\u00e4hlt alle Autotests aus, die die Bedingungen erf\u00fcllen, und startet sie.<\/p>\n

    Das Datengenerierungsmodul wird in Form eines Pakets bereitgestellt, in dem f\u00fcr jedes Objekt des zu testenden Systems (Datenbanktabelle) 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 mit einem Fingertipp erm\u00f6glicht. Zu diesem Zweck wurden Vorlagen f\u00fcr die zu erstellenden Daten erstellt. Beispielsweise kann ein Kunde bestimmten Alters mit einer Testtelefonnummer und einem abgeschlossenen Kauf erstellt werden.<\/li>\n

  6. Autotests 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 dem ein Bericht \u00fcber die Ergebnisse erstellt und an das gesamte Entwicklungsteam \u00fcber die Unternehmens-E-Mail versendet wird. Nach der Wiederherstellung der alten automatisierten Tests und der Erstellung neuer Tests betrug die Gesamtdauer 30 Minuten. Diese Leistungsf\u00e4higkeit fand allgemeine Zustimmung, da der Start au\u00dferhalb der Arbeitszeiten stattfand.\n

    F\u00fcr die Optimierung der Geschwindigkeit war jedoch Arbeit erforderlich. Die Aktualisierung des Loyalit\u00e4tsprogramms im Produktionssystem erfolgt nachts. Im Rahmen eines der Releases mussten nachts dringende \u00c4nderungen vorgenommen werden. Das halbst\u00fcndige Warten auf die Ergebnisse der automatisierten Tests um drei Uhr morgens machte den Verantwortlichen f\u00fcr das Release nicht gl\u00fccklich (herzliche Gr\u00fc\u00dfe an Alexey Vasyukov!), und am n\u00e4chsten Morgen fielen viele wohlwollende Worte in Richtung unseres Systems. Letztendlich wurde ein Zeitrahmen von 5 Minuten f\u00fcr die Arbeit festgelegt.<\/p>\n

    Um die Leistung zu steigern, haben wir zwei Methoden angewendet: Die automatisierten Tests werden nun in drei parallelen Str\u00f6men ausgef\u00fchrt, was aufgrund der Architektur unseres Loyalit\u00e4tsystems sehr praktisch ist. Au\u00dferdem haben wir uns von der Methode distanziert, bei der der automatisierte Test keine eigenen Testdaten erstellt, sondern versucht, geeignete Daten im System zu finden. Nach den \u00c4nderungen hat sich die Gesamtlaufzeit auf 3-4 Minuten reduziert.<\/li>\n

  7. Das Projekt mit den automatisierten Tests muss auf verschiedenen St\u00e4nden einsatzbereit sein.<\/b> Anfangs haben wir versucht, eigene Batchdateien zu erstellen, aber es wurde schnell klar, dass eine ma\u00dfgeschneiderte automatisierte Installation ein Albtraum ist. Deshalb haben wir uns nach industriellen L\u00f6sungen umgesehen. Da in diesem Projekt sehr viel Code vorhanden ist (insbesondere speichern wir den Code der automatisierten Tests) und nur sehr wenig Daten (die Hauptdaten sind Metadaten zu den automatisierten Tests) vorhanden sind, gestaltete sich die Integration von Liquibase in das Projekt als sehr einfach.\n

    Dies ist eine datenbankunabh\u00e4ngige, Open-Source-Bibliothek zur Verfolgung, Verwaltung und Anwendung von Datenbankschema\u00e4nderungen. Sie wird \u00fcber die Kommandozeile oder Frameworks wie Apache Maven gesteuert. Das Prinzip von Liquibase ist recht einfach. Wir haben ein strukturiertes Projekt, das aus \u00c4nderungen oder Skripten besteht, die auf den Zielserver angewendet werden m\u00fcssen, sowie Steuerdateien, die festlegen, 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 ein \u00c4nderungsprotokoll 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 unsere System\u00e4nderungen problemlos auf jede Umgebung anwenden. Automatisierte Tests werden jetzt in Test- und Produktionsumgebungen sowie in Containern (pers\u00f6nlichen Umgebungen der Entwickler) durchgef\u00fchrt.<\/li>\n<\/ol>\n

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

      \n
    1. Nat\u00fcrlich sind wir in erster Linie \u00fcberzeugt, dass wir begonnen haben, qualitativ hochwertigere Software zu entwickeln. Automatisierte Tests werden t\u00e4glich durchgef\u00fchrt und finden bei jeder Ver\u00f6ffentlichung Dutzende von Fehlern. Einige dieser Fehler stehen lediglich indirekt in Verbindung mit den Funktionen, die wir tats\u00e4chlich \u00e4ndern wollten. Es bestehen gro\u00dfe Zweifel, dass diese Fehler durch manuelles Testen gefunden wurden. <\/li>\n
    2. Das Team hat das Vertrauen gewonnen, dass bestimmte Funktionen korrekt arbeiten... Dies betrifft vor allem unsere kritischen Prozesse. Zum Beispiel hatten wir in den letzten sechs Monaten keine Probleme mit der Verteilung von Rabatten und Boni im Checkout, trotz regelm\u00e4\u00dfiger \u00c4nderungen, w\u00e4hrend in fr\u00fcheren Perioden immer wieder Fehler auftraten.<\/li>\n
    3. Wir konnten die Anzahl der Testiterationen reduzieren. Da automatisierte Tests f\u00fcr neue Funktionen geschrieben werden, erh\u00e4lt unser Analyse- und Testteam Code von h\u00f6herer Qualit\u00e4t, da dieser bereits gepr\u00fcft wurde.<\/li>\n
    4. Ein Teil der Ergebnisse der automatisierten Tests wird von den Entwicklern genutzt. Zum Beispiel werden Testdaten in Containern mithilfe eines Moduls zur Objekterstellung erstellt.<\/li>\n
    5. Es ist wichtig, dass wir eine \"Akzeptanz\" des automatisierten Testsystems seitens der Entwickler erreicht haben. Es besteht ein Verst\u00e4ndnis daf\u00fcr, dass dies wichtig und n\u00fctzlich ist. Aber aus eigener Erfahrung kann ich sagen, dass dem nicht immer so ist. Automatisierte Tests m\u00fcssen geschrieben, unterst\u00fctzt und weiterentwickelt sowie die Ergebnisse analysiert werden. Oftmals rechtfertigen diese zeitlichen Aufwendungen einfach nicht den Aufwand. Es ist viel einfacher, in die Produktion zu gehen und dort die Probleme zu kl\u00e4ren. Bei uns stehen die Entwickler Schlange und bitten darum, ihre Funktionalit\u00e4ten durch automatisierte Tests abzudecken.<\/li>\n<\/ol>\n

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

      \n\"Unit-Tests
      \n
      \nLassen Sie uns \u00fcber die Entwicklungspl\u00e4ne f\u00fcr das Projekt zur automatisierten Testung sprechen.<\/p>\n

      Solange das Loyalit\u00e4tsprogramm von Sportmaster besteht und sich weiterentwickelt, k\u00f6nnen auch die automatisierten Tests praktisch endlos weiterentwickelt werden. Daher besteht die Hauptentwicklungsausrichtung darin, den Abdeckungsbereich zu erweitern.<\/p>\n

      Mit der steigenden Anzahl an automatisierten Tests wird die Gesamtzeit f\u00fcr ihre Ausf\u00fchrung stetig zunehmen, und wir m\u00fcssen erneut die Frage der Leistungsf\u00e4higkeit aufgreifen. Wahrscheinlich wird die L\u00f6sung in der Erh\u00f6hung der Anzahl der parallelen Threads liegen.<\/p>\n

      Es gibt jedoch offensichtliche Entwicklungsm\u00f6glichkeiten. Wenn wir \u00fcber etwas weniger Triviales sprechen, heben wir Folgendes hervor:<\/p>\n

        \n
      1. Aktuell erfolgt die Verwaltung von automatisierten Tests auf der Ebene der Datenbankmanagementsysteme, d.h. es sind Kenntnisse in PL\/SQL erforderlich, um erfolgreich zu arbeiten. Bei Bedarf kann die Systemverwaltung (zum Beispiel das Ausf\u00fchren von Jobs oder das Erstellen von Metadaten) in ein Admin-Tool ausgelagert werden, wie zum Beispiel Jenkins oder etwas \u00c4hnliches.<\/li>\n
      2. Alle sch\u00e4tzen quantitative und qualitative Kennzahlen. F\u00fcr automatisiertes Testen ist diese universelle Kennzahl die Code Coverage oder die Metrik der Codeabdeckung. Mit dieser Kennzahl k\u00f6nnen wir bestimmen, welcher Prozentsatz des Codes unseres getesteten Systems durch automatisierte Tests 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

        Unser automatisiertes Testsystem ist etwas \u00fcber ein Jahr alt, und vielleicht ist jetzt der ideale Zeitpunkt, um die Abdeckung zu bewerten. In meinem vorherigen Projekt (nicht bei Sportmaster) war es \u00e4hnlich. Ein Jahr nach der Einf\u00fchrung der automatisierten Tests hat das Management die Aufgabe gestellt zu beurteilen, wie viel Prozent des Codes wir abdecken. Bei \u00fcber 1 % Abdeckung w\u00e4re das Management erfreut gewesen. Wir, die Entwickler, erwarteten ein Ergebnis von etwa 10 %. Nachdem wir die Codeabdeckung eingerichtet und gemessen hatten, erhielten wir 20 %. \u00dcbergl\u00fccklich gingen wir zur Pr\u00e4mie, aber wo wir hingegangen sind und was dann geschah, ist eine ganz andere Geschichte.<\/li>\n

      3. Automatisierte Tests k\u00f6nnen die bereitgestellten Webdienste \u00fcberpr\u00fcfen. Oracle erm\u00f6glicht dies durchaus, und wir werden viele Probleme nicht mehr antreffen. <\/li>\n
      4. Und nat\u00fcrlich kann unser automatisiertes Testsystem auch in einem anderen Projekt angewendet werden. Die L\u00f6sung, die wir entwickelt haben, ist universell und ben\u00f6tigt lediglich die Nutzung von Oracle. Ich habe geh\u00f6rt, dass es in anderen Projekten von Sportmaster Interesse an automatisierten Tests gibt, und m\u00f6glicherweise werden wir uns dorthin begeben.<\/li>\n<\/ol>\n

        <\/p>\n

        Fazit<\/h2>\n

        \nLassen Sie uns zusammenfassen. Bei dem Loyalty-Programm des Sportmasters haben wir ein automatisiertes Testsystem implementiert. Die Basis daf\u00fcr bildet die L\u00f6sung utPLSQL von Steven Feuerstein. Rund um utPLSQL befinden sich der Code der automatisierten Tests sowie unterst\u00fctzende selbstgeschriebene Module: ein Startmodul, ein Daten Generierungsmodul und weitere. Die automatisierten Tests laufen t\u00e4glich und, was am wichtigsten ist, sie funktionieren und bringen Nutzen. Wir sind \u00fcberzeugt, dass wir begonnen haben, Software von h\u00f6herer Qualit\u00e4t auszuliefern. Dabei ist die entwickelte L\u00f6sung universell und kann problemlos in jedem Projekt eingesetzt werden, in dem automatisiertes Testen auf Oracle-Datenbanken erforderlich ist.<\/p>\n

        P.S. Dieser Artikel ist nicht sehr konkret ausgefallen: Er enth\u00e4lt viel Text und fast keine technischen Beispiele. Wenn das Thema grunds\u00e4tzlich von Interesse ist, sind wir bereit, es fortzusetzen und mit weiteren Informationen zur\u00fcckzukehren, in denen wir erl\u00e4utern, was sich in den vergangenen sechs Monaten ver\u00e4ndert hat, und Beispiele f\u00fcr den Code anf\u00fchren.<\/p>\n

        Bitte hinterlassen Sie Kommentare, wenn es Punkte gibt, auf die wir in Zukunft besonders eingehen sollten, oder Fragen, die erkl\u00e4rt werden m\u00fcssen.<\/i><\/p>\n

        Nur registrierte Benutzer k\u00f6nnen an der Umfrage teilnehmen. Bitte melden Sie sich an.<\/a><\/noindex>Sind Sie an Contour interessiert?<\/p>\n

        Sollten wir weiter dar\u00fcber schreiben?<\/h2>\n