Unit-Tests in einem DBMS – wie wir es in Sportmaster machen, Teil zwei

Erster Teil - hier.

Stellen Sie sich eine Situation vor. Sie stehen vor der Aufgabe, neue Funktionalitäten zu entwickeln. Sie haben Erfahrungen von Ihren Vorgängern. Angenommen, Sie hätten keine moralischen Verpflichtungen, was würden Sie tun?

Meistens werden alle alten Entwicklungen vergessen und alles beginnt von vorne. Niemand gräbt sich gerne in den Code eines anderen ein, und wenn Sie Zeit haben, warum beginnen Sie dann nicht mit der Erstellung Ihres eigenen Systems? Dies ist ein typischer Ansatz und in vielerlei Hinsicht richtig. Aber in unserem Projekt haben wir anders gehandelt. Wir haben das zukünftige automatisierte Testsystem auf den Entwicklungen bei Unit-Tests auf utPLSQL unserer Vorgänger aufgebaut und sind dann in mehrere parallele Richtungen gegangen.

1. Wiederherstellung alter Unit-Tests. Wiederherstellung bedeutet Anpassung der Tests an den aktuellen Stand des Treuesystems und Anpassung der Tests an utPLSQL-Standards.
2. Wir lösen das Problem mit dem Verständnis und was genau, welche Methoden und Prozesse wir mit Autotests abgedeckt haben. Sie müssen diese Informationen entweder im Kopf behalten oder Schlussfolgerungen direkt auf der Grundlage des Autotest-Codes ziehen. Deshalb haben wir uns entschieden, einen Katalog zu erstellen. Wir haben jedem Autotest einen eindeutigen mnemonischen Code zugewiesen, eine Beschreibung erstellt und die Einstellungen festgelegt (z. B. unter welchen Bedingungen er ausgeführt werden soll oder was passieren soll, wenn der Testlauf fehlschlägt). Im Wesentlichen haben wir die Metadaten zu Autotests ausgefüllt und diese Metadaten in den Standardtabellen des utPLSQL-Schemas platziert.
3. Definition der Expansionsstrategie, d.h. Auswahl der Funktionalität, die der Überprüfung durch Autotests unterliegt. Wir haben beschlossen, auf drei Dinge zu achten: neue Verbesserungen am System, Vorfälle aus der Produktion und Schlüsselprozesse des Systems. Daher entwickeln wir parallel zum Release, stellen dessen höhere Qualität sicher, erweitern gleichzeitig den Umfang der Regression und stellen die Zuverlässigkeit des Systems an kritischen Stellen sicher. Der erste derartige Engpass war der Prozess der Verteilung von Rabatten und Boni per Scheck.
4. Natürlich haben wir mit der Entwicklung neuer Autotests begonnen. Eine der ersten Release-Aufgaben bestand darin, die Leistung vordefinierter Muster des Treuesystems zu bewerten. Unser Projekt verfügt über einen Block starr festgelegter SQL-Abfragen, die Clients entsprechend den Bedingungen auswählen. Erhalten Sie beispielsweise eine Liste aller Kunden, deren letzter Einkauf in einer bestimmten Stadt getätigt wurde, oder eine Liste der Kunden, deren durchschnittlicher Einkaufsbetrag über einem bestimmten Wert liegt. Nachdem wir Autotests geschrieben hatten, überprüften wir vordefinierte Beispiele, feste Benchmark-Leistungsparameter und führten zusätzlich Lasttests durch.
5. Die Arbeit mit Autotests sollte bequem sein. Die beiden häufigsten Aktionen sind das Ausführen von Autotests und das Generieren von Testdaten. So entstanden in unserem System zwei Hilfsmodule: das Startmodul und das Datengenerierungsmodul.

   Der Launcher wird als eine generische Prozedur mit einem Eingabetextparameter dargestellt. Als Parameter können Sie einen Autotest-Mnemonikcode, einen Paketnamen, einen Testnamen, eine Autotest-Einstellung oder ein reserviertes Schlüsselwort übergeben. Das Verfahren wählt alle Autotests aus, die die Bedingungen erfüllen, und führt sie aus.

   Das Datengenerierungsmodul wird als Paket dargestellt, in dem für jedes Objekt des zu testenden Systems (eine Tabelle in der Datenbank) eine spezielle Prozedur erstellt wurde, die dort Daten einfügt. Bei diesem Verfahren werden die Standardwerte maximal gefüllt, was die Erstellung von Objekten im wahrsten Sinne des Wortes per Fingerklick gewährleistet. Und zur Vereinfachung der Nutzung wurden Vorlagen für die generierten Daten erstellt. Erstellen Sie beispielsweise einen Kunden eines bestimmten Alters mit einem Testtelefon und einem abgeschlossenen Kauf.

6. Autotests sollten innerhalb einer für Ihr System angemessenen Zeit ausgeführt werden. Daher wurde ein täglicher Nachtstart organisiert, auf dessen Grundlage ein Bericht über die Ergebnisse erstellt und per Firmenpost an das gesamte Entwicklungsteam gesendet wird. Nach dem Wiederherstellen alter Autotests und dem Erstellen neuer Autotests betrug die Gesamtlaufzeit 30 Minuten. Ein solcher Auftritt gefiel allen, da der Start außerhalb der Geschäftszeiten stattfand.

   Aber wir mussten daran arbeiten, die Arbeitsgeschwindigkeit zu optimieren. Das Produktionstreuesystem wird nachts aktualisiert. Im Rahmen eines der Releases mussten wir nachts dringend Änderungen vornehmen. Ein halbstündiges Warten auf die Ergebnisse der Autotests um drei Uhr morgens machte den Verantwortlichen für die Veröffentlichung nicht glücklich (herzliche Grüße an Alexei Vasyukov!), Und am nächsten Morgen wurden viele warme Worte an unser System gerichtet. Als Ergebnis wurde jedoch ein 5-Minuten-Standard für die Arbeit festgelegt.

   Um die Leistung zu beschleunigen, haben wir zwei Methoden verwendet: Wir haben damit begonnen, Autotests in drei parallelen Threads auszuführen, da dies aufgrund der Architektur unseres Treuesystems sehr praktisch ist. Und wir haben den Ansatz aufgegeben, wenn der Autotest keine Testdaten für sich selbst erstellt, sondern versucht, etwas Passendes im System zu finden. Nach Änderungen reduzierte sich die Gesamtbetriebszeit auf 3-4 Minuten.

7. Ein Projekt mit Autotests soll auf verschiedenen Ständen einsetzbar sein. Zu Beginn der Reise gab es Versuche, eigene Batch-Dateien zu schreiben, aber es wurde klar, dass eine selbstgeschriebene automatisierte Installation ein völliger Horror ist, und wir wandten uns industriellen Lösungen zu. Aufgrund der Tatsache, dass das Projekt direkt über viel Code verfügt (zuallererst speichern wir den Code von Autotests) und sehr wenig Daten (die Hauptdaten sind Metadaten zu Autotests), erwies sich die Integration in das Projekt als sehr einfach Liquibase-Projekt.

   Es handelt sich um eine datenbankunabhängige Open-Source-Bibliothek zum Verfolgen, Verwalten und Anwenden von Datenbankschemaänderungen. Verwaltet über die Befehlszeile oder Frameworks wie Apache Maven. Das Funktionsprinzip von Liquibase ist recht einfach. Wir haben ein Projekt, das auf eine bestimmte Art und Weise organisiert ist und aus Änderungen oder Skripten besteht, die auf den Zielserver übertragen werden müssen, sowie aus Steuerdateien, die bestimmen, in welcher Reihenfolge und mit welchen Parametern diese Änderungen installiert werden sollen.

   Auf DBMS-Ebene wird eine spezielle Tabelle erstellt, in der Liquibase das Rollback-Protokoll speichert. Für jede Änderung wird ein Hash berechnet, der jedes Mal zwischen dem Projekt und dem Status in der Datenbank verglichen wird. Dank Liquibase können wir Änderungen an unserem System problemlos auf jede Schaltung übertragen. Autotests werden jetzt auf Test- und Release-Schaltkreisen sowie auf Containern (persönlichen Entwicklerschaltkreisen) durchgeführt.

Sprechen wir also über die Ergebnisse der Anwendung unseres Unit-Testsystems.

1. Natürlich sind wir zunächst davon überzeugt, dass wir mit der Entwicklung besserer Software begonnen haben. Autotests laufen täglich und finden bei jeder Veröffentlichung Dutzende von Fehlern. Darüber hinaus hängen einige dieser Fehler nur indirekt mit der Funktionalität zusammen, die wir eigentlich ändern wollten. Es bestehen starke Zweifel, dass diese Fehler durch manuelle Tests gefunden wurden.
2. Das Team gewann die Gewissheit, dass bestimmte Funktionen korrekt funktionieren... Dies betrifft zunächst einmal unsere kritischen Prozesse. Beispielsweise hatten wir in den letzten sechs Monaten trotz der bei jeder Veröffentlichung vorgenommenen Änderungen keine Probleme mit der Verteilung von Rabatten und Boni per Scheck, obwohl in früheren Zeiträumen häufiger Fehler aufgetreten sind
3. Es ist uns gelungen, die Anzahl der Testiterationen zu reduzieren. Aufgrund der Tatsache, dass Autotests für neue Funktionen geschrieben werden, erhalten Analysten und Teilzeittester einen Code von höherer Qualität, weil es wurde bereits verifiziert.
4. Ein Teil der Entwicklungen des automatisierten Testens wird von Entwicklern genutzt. Testdaten zu Containern werden beispielsweise mit dem Objektgenerierungsmodul erstellt.
5. Es ist wichtig, dass wir eine „Akzeptanz“ des automatisierten Testsystems durch Entwickler entwickelt haben. Es besteht Einigkeit darüber, dass dies wichtig und nützlich ist. Und aus eigener Erfahrung kann ich sagen, dass dies bei weitem nicht der Fall ist. Autotests müssen geschrieben, gewartet und weiterentwickelt, die Ergebnisse analysiert werden, und oft lohnt sich dieser Zeitaufwand einfach nicht. Es ist viel einfacher, in die Produktion zu gehen und dort Probleme zu lösen. In unserem Land stehen Entwickler Schlange und bitten darum, ihre Funktionalität durch Autotests abzudecken.

Was weiter

Lassen Sie uns über die Entwicklungspläne des automatisierten Testprojekts sprechen.

Solange das Sportmaster-Treuesystem existiert und sich weiterentwickelt, können natürlich auch Autotests nahezu endlos weiterentwickelt werden. Daher ist die Hauptrichtung der Entwicklung die Erweiterung des Versorgungsgebiets.

Da die Anzahl der Autotests zunimmt, wird die Gesamtzeit ihrer Arbeit stetig zunehmen, und wir müssen wieder auf die Frage der Leistung zurückkommen. Die Lösung wird höchstwahrscheinlich darin bestehen, die Anzahl der parallelen Threads zu erhöhen.

Aber das sind offensichtliche Entwicklungswege. Wenn wir über etwas Nichttrivialeres sprechen, heben wir Folgendes hervor:

1. Jetzt werden Autotests auf DBMS-Ebene verwaltet, d. h. Für eine erfolgreiche Arbeit sind Kenntnisse in PL/SQL erforderlich. Bei Bedarf kann die Systemverwaltung (z. B. Starten oder Erstellen von Metadaten) von einer Art Admin-Panel mithilfe von Jenkins oder ähnlichem übernommen werden.
2. Jeder liebt quantitative und qualitative Indikatoren. Für automatische Tests ist ein solcher universeller Indikator die Codeabdeckung oder Codeabdeckungsmetrik. Anhand dieses Indikators können wir ermitteln, wie viel Prozent des Codes unseres zu testenden Systems von Autotests abgedeckt wird. Ab Version 12.2 bietet Oracle die Möglichkeit, diese Metrik zu berechnen und empfiehlt die Verwendung des Standardpakets DBMS_PLSQL_CODE_COVERAGE.

   Unser Autotest-System ist etwas mehr als ein Jahr alt und es könnte an der Zeit sein, die Abdeckung zu bewerten. Bei meinem letzten Projekt (einem Projekt, das nicht von Sportmaster stammt) ist dies passiert. Ein Jahr nach der Arbeit an Autotests stellte das Management die Aufgabe, zu beurteilen, wie viel Prozent des Codes wir abdeckten. Bei einer Abdeckung von mehr als 1 % wäre das Management zufrieden. Wir als Entwickler hatten mit einem Ergebnis von etwa 10 % gerechnet. Wir haben die Codeabdeckung vermasselt, sie gemessen und 20 % erreicht. Um dies zu feiern, haben wir uns für die Auszeichnung entschieden, aber wie wir uns dafür entschieden haben und wohin wir später gegangen sind, ist eine ganz andere Geschichte.

3. Autotests können exponierte Webdienste testen. Oracle ermöglicht Ihnen dies und wir werden nicht mehr auf eine Reihe von Problemen stoßen.
4. Und natürlich kann unser automatisiertes Testsystem auf ein anderes Projekt angewendet werden. Die Lösung, die wir erhalten haben, ist universell und erfordert lediglich die Verwendung von Oracle. Ich habe gehört, dass Interesse an automatisierten Tests bei anderen Sportmaster-Projekten besteht, und vielleicht werden wir uns ihnen anschließen.

Befund

Lassen Sie uns rekapitulieren. Beim Treuesystemprojekt in Sportmaster ist es uns gelungen, ein automatisiertes Testsystem zu implementieren. Grundlage ist die utPLSQL-Lösung von Stephen Feuerstein. Um utPLSQL herum befindet sich der Code für Autotests und selbst geschriebene Hilfsmodule: ein Launcher, ein Datengenerierungsmodul und andere. Autotests laufen täglich und, was am wichtigsten ist, funktionieren und nützen. Wir sind davon überzeugt, dass wir damit begonnen haben, Software von höherer Qualität herauszubringen. Gleichzeitig ist die resultierende Lösung universell und kann frei auf jedes Projekt angewendet werden, bei dem automatisierte Tests auf dem Oracle DBMS organisiert werden müssen.

PS Dieser Artikel erwies sich als nicht sehr spezifisch: Er enthält viel Text und praktisch keine technischen Beispiele. Wenn das Thema global interessant ist, sind wir bereit, es fortzusetzen und mit einer Fortsetzung zurückzukehren, in der wir Ihnen erzählen, was sich in den letzten sechs Monaten geändert hat, und Codebeispiele geben.

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

An der Umfrage können nur registrierte Benutzer teilnehmen. Einloggenbitte.

Sollen wir mehr darüber schreiben?

• Ja natürlich

• Nein danke

12 Benutzer haben abgestimmt. 4 Benutzer enthielten sich der Stimme.

Source: habr.com