🥇Unit-Tests in der Datenbank – wie wir das im Sportmeister machen, Teil zwei

Der erste Teil — hier.

Stellen Sie sich eine Situation vor. Sie stehen vor der Aufgabe, eine neue Funktionalität zu entwickeln. Sie haben die Arbeiten Ihrer Vorgänger vorliegen. Angenommen, Sie haben keine moralischen Verpflichtungen, wie würden Sie handeln?

In den meisten Fällen 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änger als Grundlage für das zukünftige automatisierte Testssystem verwendet und sind dann in mehreren parallelen Richtungen weitergearbeitet.

Wiederherstellung alter Unit-Tests. Unter Wiederherstellung verstehen wir die Anpassung der Tests an den bestehenden Zustand des Loyalitätssystems und die Anpassung der Tests an die Standards von utPLSQL.
Lösung des Problems des Verständnisses, welche Methoden und Prozesse wir mit automatisierten Tests abdecken. Wir müssen 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ührt werden sollte oder was geschehen sollte, wenn der Test fehlgeschlagen ist). Im Grunde haben wir die Metadaten der automatisierten Tests ausgefüllt und diese Metadaten in die Standardtabellen des utPLSQL-Schemas eingefügt.
Definition der Expansionsstrategie, d.h. Auswahl der Funktionalitäten, die von automatisierten Tests überprüft werden sollen. Wir haben uns entschieden, auf drei Aspekte zu achten: neue Systemanpassungen, Vorfälle aus der Produktion und wichtige Prozesse des Systems. Auf diese Weise entwickeln wir uns parallel zum Release weiter, gewährleisten eine höhere Qualität und erweitern gleichzeitig den Umfang des Regressionstests, um die Zuverlässigkeit des Systems an kritischen Stellen sicherzustellen. Der erste Engpass war der Prozess der Verteilung von Rabatten und Boni im Warenkorb.
Selbstverständlich haben wir uns der Entwicklung neuer automatisierter Tests gewidmet. Eine der ersten Release-Aufgaben bestand darin, die Leistung vordefinierter Auswahlproben des Loyalitätssystems zu bewerten. In unserem Projekt gibt es einen Block festgelegter SQL-Anfragen, die Kunden anhand bestimmter Kriterien filtern. Beispielsweise können wir eine Liste aller Kunden abrufen, deren letzter Einkauf in einer bestimmten Stadt stattgefunden hat, oder eine Liste von Kunden, deren durchschnittlicher Einkaufswert über einem bestimmten Betrag liegt. Mit den entwickelten automatisierten Tests haben wir die vordefinierten Auswahlproben überprüft, die Referenzparameter der Leistung festgelegt und zusätzlich Lasttests durchgeführt.
Die Arbeit mit automatisierten Tests sollte benutzerfreundlich sein.Am häufigsten werden zwei Aktionen durchgeführt: das Starten der automatisierten Tests und das Erstellen von Testdaten. Daher haben wir in unserem System zwei unterstützende Module implementiert: das Modulanlaufmodul und das Datengenerierungsmodul.
Das Startmodul wird als eine universelle Prozedur mit einem Eingabetextparameter bereitgestellt. Als Parameter können der Mnemonik-Code des Autotests, der Name des Pakets, der Name des Tests, die Konfiguration des Autotests oder ein reserviertes Schlüsselwort übergeben werden. Die Prozedur wählt alle Autotests aus, die die Bedingungen erfüllen, und startet sie.
Das Datengenerierungsmodul wird in Form eines Pakets bereitgestellt, in dem für jedes Objekt des zu testenden Systems (Datenbanktabelle) eine spezielle Prozedur erstellt wurde, die dort Daten einfügt. In dieser Prozedur sind die Standardwerte maximal ausgefüllt, was die Erstellung von Objekten buchstäblich mit einem Fingertipp ermöglicht. Zu diesem Zweck wurden Vorlagen für die zu erstellenden Daten erstellt. Beispielsweise kann ein Kunde bestimmten Alters mit einer Testtelefonnummer und einem abgeschlossenen Kauf erstellt werden.
Autotests sollten in einer für Ihr System akzeptablen Zeit gestartet und ausgeführt werden. Daher wurde ein täglicher nächtlicher Start organisiert, nach dem ein Bericht über die Ergebnisse erstellt und an das gesamte Entwicklungsteam über 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ähigkeit fand allgemeine Zustimmung, da der Start außerhalb der Arbeitszeiten stattfand.
Für die Optimierung der Geschwindigkeit war jedoch Arbeit erforderlich. Die Aktualisierung des Loyalitätsprogramms im Produktionssystem erfolgt nachts. Im Rahmen eines der Releases mussten nachts dringende Änderungen vorgenommen werden. Das halbstündige Warten auf die Ergebnisse der automatisierten Tests um drei Uhr morgens machte den Verantwortlichen für das Release nicht glücklich (herzliche Grüße an Alexey Vasyukov!), und am nächsten Morgen fielen viele wohlwollende Worte in Richtung unseres Systems. Letztendlich wurde ein Zeitrahmen von 5 Minuten für die Arbeit festgelegt.
Um die Leistung zu steigern, haben wir zwei Methoden angewendet: Die automatisierten Tests werden nun in drei parallelen Strömen ausgeführt, was aufgrund der Architektur unseres Loyalitätsystems sehr praktisch ist. Außerdem 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 Änderungen hat sich die Gesamtlaufzeit auf 3-4 Minuten reduziert.
Das Projekt mit den automatisierten Tests muss auf verschiedenen Ständen einsatzbereit sein. Anfangs haben wir versucht, eigene Batchdateien zu erstellen, aber es wurde schnell klar, dass eine maßgeschneiderte automatisierte Installation ein Albtraum ist. Deshalb haben wir uns nach industriellen Lösungen 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.
Dies ist eine datenbankunabhängige, Open-Source-Bibliothek zur Verfolgung, Verwaltung und Anwendung von Datenbankschemaänderungen. Sie wird über die Kommandozeile oder Frameworks wie Apache Maven gesteuert. Das Prinzip von Liquibase ist recht einfach. Wir haben ein strukturiertes Projekt, das aus Änderungen oder Skripten besteht, die auf den Zielserver angewendet werden müssen, sowie Steuerdateien, die festlegen, in welcher Reihenfolge und mit welchen Parametern diese Änderungen installiert werden sollen.
Auf der Ebene der Datenbank wird eine spezielle Tabelle erstellt, in der Liquibase ein Änderungsprotokoll speichert. Jede Änderung hat einen berechneten Hash, der jedes Mal zwischen dem Projekt und dem Zustand in der Datenbank verglichen wird. Dank Liquibase können wir unsere Systemänderungen problemlos auf jede Umgebung anwenden. Automatisierte Tests werden jetzt in Test- und Produktionsumgebungen sowie in Containern (persönlichen Umgebungen der Entwickler) durchgeführt.

Lassen Sie uns also über die Ergebnisse der Anwendung unseres Unit-Testsystems sprechen.

Natürlich sind wir in erster Linie überzeugt, dass wir begonnen haben, qualitativ hochwertigere Software zu entwickeln. Automatisierte Tests werden täglich durchgeführt und finden bei jeder Veröffentlichung Dutzende von Fehlern. Einige dieser Fehler stehen lediglich indirekt in Verbindung mit den Funktionen, die wir tatsächlich ändern wollten. Es bestehen große Zweifel, dass diese Fehler durch manuelles Testen gefunden wurden.
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äßiger Änderungen, während in früheren Perioden immer wieder Fehler auftraten.
Wir konnten die Anzahl der Testiterationen reduzieren. Da automatisierte Tests für neue Funktionen geschrieben werden, erhält unser Analyse- und Testteam Code von höherer Qualität, da dieser bereits geprüft wurde.
Ein Teil der Ergebnisse der automatisierten Tests wird von den Entwicklern genutzt. Zum Beispiel werden Testdaten in Containern mithilfe eines Moduls zur Objekterstellung erstellt.
Es ist wichtig, dass wir eine "Akzeptanz" des automatisierten Testsystems seitens der Entwickler erreicht haben. Es besteht ein Verständnis dafür, dass dies wichtig und nützlich ist. Aber aus eigener Erfahrung kann ich sagen, dass dem nicht immer so ist. Automatisierte Tests müssen geschrieben, unterstützt 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ären. Bei uns stehen die Entwickler Schlange und bitten darum, ihre Funktionalitäten durch automatisierte Tests abzudecken.

Was kommt als Nächstes

Lassen Sie uns über die Entwicklungspläne für das Projekt zur automatisierten Testung sprechen.

Solange das Loyalitätsprogramm von Sportmaster besteht und sich weiterentwickelt, können auch die automatisierten Tests praktisch endlos weiterentwickelt werden. Daher besteht die Hauptentwicklungsausrichtung darin, den Abdeckungsbereich zu erweitern.

Mit der steigenden Anzahl an automatisierten Tests wird die Gesamtzeit für ihre Ausführung stetig zunehmen, und wir müssen erneut die Frage der Leistungsfähigkeit aufgreifen. Wahrscheinlich wird die Lösung in der Erhöhung der Anzahl der parallelen Threads liegen.

Es gibt jedoch offensichtliche Entwicklungsmöglichkeiten. Wenn wir über etwas weniger Triviales sprechen, heben wir Folgendes hervor:

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ühren von Jobs oder das Erstellen von Metadaten) in ein Admin-Tool ausgelagert werden, wie zum Beispiel Jenkins oder etwas Ähnliches.
Alle schätzen quantitative und qualitative Kennzahlen. Für automatisiertes Testen ist diese universelle Kennzahl die Code Coverage oder die Metrik der Codeabdeckung. Mit dieser Kennzahl können wir bestimmen, welcher Prozentsatz des Codes unseres getesteten Systems durch automatisierte Tests abgedeckt wird. Seit Version 12.2 bietet Oracle Möglichkeiten zur Berechnung dieser Metrik an und empfiehlt die Verwendung des Standardpakets DBMS_PLSQL_CODE_COVERAGE.
Unser automatisiertes Testsystem ist etwas über ein Jahr alt, und vielleicht ist jetzt der ideale Zeitpunkt, um die Abdeckung zu bewerten. In meinem vorherigen Projekt (nicht bei Sportmaster) war es ähnlich. Ein Jahr nach der Einführung der automatisierten Tests hat das Management die Aufgabe gestellt zu beurteilen, wie viel Prozent des Codes wir abdecken. Bei über 1 % Abdeckung wäre das Management erfreut gewesen. Wir, die Entwickler, erwarteten ein Ergebnis von etwa 10 %. Nachdem wir die Codeabdeckung eingerichtet und gemessen hatten, erhielten wir 20 %. Überglücklich gingen wir zur Prämie, aber wo wir hingegangen sind und was dann geschah, ist eine ganz andere Geschichte.
Automatisierte Tests können die bereitgestellten Webdienste überprüfen. Oracle ermöglicht dies durchaus, und wir werden viele Probleme nicht mehr antreffen.
Und natürlich kann unser automatisiertes Testsystem auch in einem anderen Projekt angewendet werden. Die Lösung, die wir entwickelt haben, ist universell und benötigt lediglich die Nutzung von Oracle. Ich habe gehört, dass es in anderen Projekten von Sportmaster Interesse an automatisierten Tests gibt, und möglicherweise werden wir uns dorthin begeben.

Fazit

Lassen Sie uns zusammenfassen. Bei dem Loyalty-Programm des Sportmasters haben wir ein automatisiertes Testsystem implementiert. Die Basis dafür bildet die Lösung utPLSQL von Steven Feuerstein. Rund um utPLSQL befinden sich der Code der automatisierten Tests sowie unterstützende selbstgeschriebene Module: ein Startmodul, ein Daten Generierungsmodul und weitere. Die automatisierten Tests laufen täglich und, was am wichtigsten ist, sie funktionieren und bringen Nutzen. Wir sind überzeugt, dass wir begonnen haben, Software von höherer Qualität auszuliefern. Dabei ist die entwickelte Lösung universell und kann problemlos in jedem Projekt eingesetzt werden, in dem automatisiertes Testen auf Oracle-Datenbanken erforderlich ist.

P.S. Dieser Artikel ist nicht sehr konkret ausgefallen: Er enthält viel Text und fast keine technischen Beispiele. Wenn das Thema grundsätzlich von Interesse ist, sind wir bereit, es fortzusetzen und mit weiteren Informationen zurückzukehren, in denen wir erläutern, was sich in den vergangenen sechs Monaten verändert hat, und Beispiele für den Code anführen.

Bitte hinterlassen Sie Kommentare, wenn es Punkte gibt, auf die wir in Zukunft besonders eingehen sollten, oder Fragen, die erklärt werden müssen.

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte melden Sie sich an.Sind Sie an Contour interessiert?