🥇Unit-Tests in Datenbanken — wie wir das bei Sportmaster machen, Teil zwei

Der erste Teil — hier.

Stellen Sie sich die Situation vor. Sie stehen vor der Aufgabe, eine neue Funktionalität zu entwickeln. Sie haben Material von Ihren Vorgängern. Angenommen, Sie haben keine moralischen Verpflichtungen, wie würden Sie handeln?

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ür das zukünftige System automatischer Tests auf den Grundlagen der Unit-Tests auf utPLSQL von unseren Vorgängern aufgebaut und dann in mehreren parallelen Richtungen gearbeitet.

Wiederherstellung alter Unit-Tests. Unter Wiederherstellung verstehen wir die Anpassung der Tests an den aktuellen 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 durch automatisierte Tests abgedeckt sind. Wir müssen 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 über die automatisierten Tests gesammelt und diese Metadaten in die Standardtabellen des utPLSQL-Schemas eingefügt.
Definition der Erweiterungsstrategie, d.h. Auswahl der Funktionalität, die durch automatisierte Tests überprüft werden soll. Wir haben beschlossen, uns auf drei Dinge zu konzentrieren: neue Erweiterungen des Systems, Vorfälle aus der Produktion und Schlüsselprozesse des Systems. Auf diese Weise entwickeln wir uns parallel mit dem Release weiter, gewährleisten eine höhere Qualität und erweitern gleichzeitig das Regressionsvolumen und sichern die Zuverlässigkeit des Systems an kritischen Stellen. Der erste Engpass war der Prozess der Verteilung von Rabatten und Boni auf den Beleg.
Natürlich haben wir uns mit der Entwicklung neuer automatisierter Tests beschäftigt. Eine der ersten Release-Aufgaben bestand in der Bewertung der Leistung vordefinierter Abfragen des Loyalitätssystems. In unserem Projekt gibt es einen Block fest definierter SQL-Abfragen, die Kunden nach bestimmten Kriterien auswählen. 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 über einem bestimmten Betrag liegt. Nachdem wir automatische Tests geschrieben hatten, haben wir die vordefinierten Abfragen überprüft, die Referenzparameter der Leistung festgehalten, und zudem unser Lasttestverfahren eingeführt.
Die Arbeit mit automatischen Tests sollte benutzerfreundlich sein.Am häufigsten werden zwei Aktionen durchgeführt: das Starten automatischer Tests und das Erstellen von Testdaten. So wurden in unserem System zwei Hilfsmodulen geschaffen: ein Startmodul und ein Datenmodul.
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üsselwort übergeben werden. Die Prozedur wählt und startet alle automatischen Tests, die die Bedingungen erfüllen.
Das Datenmodul wird in Form eines Pakets dargestellt, in dem für jedes Objekt des zu testenden Systems (Tabelle in der DB) 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 auf Knopfdruck ermöglicht. Für die Benutzerfreundlichkeit wurden Vorlagen für die zu erstellenden Daten erstellt. Zum Beispiel, einen Kunden bestimmten Alters mit einer Testtelefonnummer und einem getätigten Einkauf zu erstellen.
Automatische Tests sollten in einer für Ihr System akzeptablen Zeit gestartet und ausgeführt werden. Daher wurde ein täglicher nächtlicher Start organisiert, nach dessen Ergebnis ein Bericht über die Ergebnisse erstellt und an das gesamte Entwicklungsteam über 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ür alle akzeptabel, da der Start außerhalb der Arbeitszeiten stattfand.
Aber die Optimierung der Geschwindigkeit erforderte einige Arbeit. Das Update des Loyalitätssystems im Produktionsumfeld erfolgt nachts. Im Rahmen eines der Releases mussten wir nachts kurzfristig Änderungen vornehmen. Eine halbe Stunde Warten auf die Ergebnisse der automatisierten Tests um drei Uhr morgens machte die verantwortliche Person für das Release nicht glücklich (liebe Grüße an Alexey Vasyukov!), und am nächsten Morgen wurden viele warme Worte in Richtung unseres Systems ausgesprochen. Letztendlich wurde eine Norm von fünf Minuten für die Bearbeitung festgelegt.
Zur Beschleunigung der Leistung haben wir zwei Methoden verwendet: Die automatisierten Tests laufen nun in drei parallelen Streams, was aufgrund der Architektur unseres Loyalitätssystems sehr praktisch ist. Außerdem haben wir auf den Ansatz verzichtet, dass der automatisierte Test keine Testdaten für sich selbst erstellt, sondern versucht, etwas Passendes im System zu finden. Nach den Änderungen wurde die Gesamtdauer auf 3-4 Minuten reduziert.
Das Projekt mit den automatisierten Tests muss auf verschiedenen Ständen einsatzbereit sein. Zu Beginn gab es Versuche, eigene Batch-Skripte zu schreiben, aber es wurde klar, dass die selbstgeschriebene automatisierte Installation ein völliger Albtraum war, und wir wählten stattdessen industrielle Lösungen. 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 über die automatisierten Tests), erwies sich die Implementierung von Liquibase im Projekt als sehr einfach.
Dies ist eine datenbankunabhängige Open-Source-Bibliothek zum Verfolgen, Verwalten und Anwenden von Änderungen am Datenbankschema. Sie wird über 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 Änderungen oder Skripten besteht, die auf den Zielserver angewendet werden müssen, sowie Steuerdateien, die definieren, 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 die Änderungsprotokolle 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 Änderungen an unserem System problemlos in jede Umgebung übernehmen. Die automatisierten Tests werden derzeit in Test- und Release-Umgebungen sowie in Containern (persönliche Entwicklungsumgebungen) gestartet.

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

Zunächst einmal sind wir überzeugt, dass wir mit der Entwicklung qualitativ hochwertigerer Software begonnen haben. Die automatisierten Tests werden täglich durchgeführt und finden bei jeder Veröffentlichung Dutzende von Fehlern. Dabei stehen einige dieser Fehler nur indirekt im Zusammenhang mit der Funktionalität, die wir tatsächlich ändern wollten. Es bestehen große Zweifel, dass diese Fehler durch manuelle Tests entdeckt wurden.
Das Team hat das Vertrauen gewonnen, dass spezifische Funktionen korrekt arbeiten… 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äßiger Änderungen in jeder Veröffentlichung, während wir in früheren Zeiträumen mit gewissen Fehlern konfrontiert waren.
Es ist uns gelungen, die Anzahl der Testiterations zu reduzieren. Da die automatisierten Tests für neue Funktionen geschrieben werden, erhalten die Analysten und gleichzeitig Tester Code von höherer Qualität, da dieser bereits überprüft wurde.
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.
Es ist wichtig zu erwähnen, dass sich eine Akzeptanz des automatisierten Testsystems seitens der Entwickler entwickelt hat. Es besteht das Verständnis, dass dies wichtig und nützlich ist. Aus eigener Erfahrung kann ich jedoch sagen, dass dies bei weitem nicht so ist. Automatisierte Tests müssen geschrieben, gewartet und weiterentwickelt werden; die Ergebnisse müssen analysiert werden, und oft sind diese zeitlichen Aufwände 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ät durch automatisierte Tests abdecken zu lassen.

Was kommt als nächstes

Lassen Sie uns über die Pläne zur Weiterentwicklung des Projekts zur automatisierten Testung sprechen.

Natürlich kann das Testautomatisierungssystem von Sportmaster, solange es lebt und sich weiterentwickelt, nahezu endlos weiterentwickelt werden. Daher ist die Hauptentwicklungsrichtung die Erweiterung des Testabdeckungsbereichs.

Mit zunehmender Anzahl an Testautomatisierungen wird die Gesamtzeit für deren Ausführung konstant steigen, und wir werden erneut auf das Thema Performance zurückkommen müssen. Wahrscheinlich wird die Lösung in der Erhöhung der Anzahl paralleler Threads liegen.

Aber das sind offensichtliche Entwicklungsmöglichkeiten. Wenn wir über etwas weniger Triviales sprechen, heben wir Folgendes hervor:

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ühren von Tests oder das Erstellen von Metadaten) in ein Administrations-Tool ausgelagert werden, indem man Jenkins oder etwas Ähnliches verwendet.
Alle lieben quantitative und qualitative Kennzahlen. Für automatisierte Tests ist eine solche universelle Kennzahl die Code Coverage oder die Metrik der Codeabdeckung. Mithilfe dieser Kennzahl können wir bestimmen, welcher Prozentsatz des Codes unseres zu testenden Systems durch Testautomatisierungen 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.
Unseres Testautomatisierungssystems ist etwas mehr als ein Jahr alt und vielleicht ist jetzt der beste Zeitpunkt für eine Einschätzung 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äftsführung den Auftrag, den Prozentsatz des abgedeckten Codes zu bewerten. Bei über 1% Abdeckung wäre die Geschäftsführung 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ämie gegangen, aber wie wir das gemacht haben und wohin wir danach gegangen sind, ist eine ganz andere Geschichte.
Testautomatisierungen können die bereitgestellten Webdienste überprüfen. Oracle erlaubt dies durchaus, und wir werden nicht mehr mit einer Reihe von Problemen konfrontiert.
Und natürlich kann unser automatisiertes Testsystem auch in einem anderen Projekt angewendet werden. Die Lösung, die wir gefunden haben, ist universell und erfordert lediglich die Nutzung von Oracle. Ich habe gehört, dass es in anderen Projekten von Sportmaster Interesse an automatisiertem Testen gibt und möglicherweise werden wir dorthin gehen.

Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.

Lassen Sie uns zusammenfassen. In dem Projekt zur Kundenbindung bei Sportmaster ist es uns gelungen, ein automatisiertes Testsystem zu implementieren. Die Basis dafür bildet die utPLSQL-Lösung von Steven Feuerstein. Rund um utPLSQL sind der Code der automatisierten Tests und die unterstützenden selbstgeschriebenen Module angeordnet: das Startmodul, das Modul zur Datengenerierung und andere. Die automatisierten Tests werden täglich ausgeführt und, was am wichtigsten ist, sie funktionieren und bringen Nutzen. Wir sind überzeugt, dass wir begonnen haben, Software von höherer Qualität zu veröffentlichen. Dabei ist die erhaltene Lösung universell und kann problemlos in jedem Projekt verwendet werden, in dem automatisiertes Testen auf Oracle-Datenbanken benötigt wird.

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ückzukehren, in denen wir erläutern, was sich in den letzten sechs Monaten geändert hat und Beispiele für Code bringen.

Schreiben Sie Kommentare, wenn es Punkte gibt, die in Zukunft hervorgehoben werden sollten, oder Fragen, die beantwortet werden müssen.

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte einloggen.