Der erste Teil ist hier .
Stellen Sie sich die Situation vor. Sie stehen vor der Aufgabe, neue Funktionen zu entwickeln. Sie haben Entwicklungen von Ihren Vorgängern. Was würden Sie tun, wenn Sie keine moralischen Verpflichtungen haben?
Meistens werden alle alten Errungenschaften vergessen und alles beginnt von vorne. Niemand mag es, in den Code eines anderen zu graben, und wenn Sie Zeit haben, warum nicht mit der Erstellung Ihres eigenen Systems beginnen? Dies ist ein typischer Ansatz, der weitgehend korrekt ist. Aber in unserem Projekt haben wir falsch gemacht. Wir haben den Grundstein für das zukünftige automatisierte Testsystem gelegt, das auf Unit-Tests auf utPLSQL unserer Vorgänger basiert, und sind dann in mehrere parallele Richtungen gegangen.
- Stellen Sie alte Komponententests wieder her. Wiederherstellung bezieht sich auf die Anpassung von Tests an den vorhandenen Status des Loyalitätssystems und die Anpassung von Tests an utPLSQL-Standards.
- Die Lösung des Problems mit dem Verständnis und was genau, welche Methoden und Prozesse werden wir durch Autotests abgedeckt. Sie müssen diese Informationen entweder berücksichtigen oder anhand des Autotest-Codes selbst Schlussfolgerungen ziehen. Aus diesem Grund haben wir uns entschlossen, einen Katalog zu erstellen. Wir haben jedem Autotest einen eindeutigen Mnemonikcode zugewiesen, eine Beschreibung erstellt und die Einstellungen festgelegt (z. B. unter welchen Bedingungen er gestartet werden soll oder was passieren soll, wenn der Test fehlschlägt). Im Wesentlichen haben wir die Metadaten zu Autotests ausgefüllt und diese Metadaten in die Standard-utPLSQL-Schematabellen eingefügt.
- Definieren einer Expansionsstrategie, d.h. Auswahl der Funktionen, die durch Autotests überprüft werden sollen. Wir haben uns entschlossen, drei Dinge zu beachten: neue Systemverbesserungen, Produktionsvorfälle und wichtige Systemprozesse. Daher entwickeln wir parallel zur Veröffentlichung eine höhere Qualität, erweitern gleichzeitig das Regressionsvolumen und stellen die Zuverlässigkeit des Systems an kritischen Stellen sicher. Der erste derartige Engpass war die Verteilung von Rabatten und Boni auf einen Scheck.
- Natürlich haben wir begonnen, neue Autotests zu entwickeln. Eine der ersten Release-Aufgaben bestand darin, die Leistung vordefinierter Stichproben des Loyalitätssystems zu bewerten. In unserem Projekt gibt es einen Block fest festgelegter SQL-Abfragen, die Clients gemäß den Bedingungen auswählen. Sie können beispielsweise eine Liste aller Kunden abrufen, deren letzter Kauf in einer bestimmten Stadt getätigt wurde, oder eine Liste der Kunden, deren durchschnittlicher Kaufbetrag über einem bestimmten Wert liegt. Nachdem wir Autotests geschrieben hatten, überprüften wir die vordefinierten Beispiele, legten die Referenzleistungsparameter fest und führten zusätzlich Lasttests durch.
- Die Arbeit mit Autotests sollte bequem sein . Am häufigsten werden zwei Aktionen ausgeführt: Ausführen von Autotests und Erstellen von Testdaten. In unserem System erschienen also zwei Hilfsmodule: das Startmodul und das Datengenerierungsmodul.
Der Launcher wird als einzelne universelle Prozedur mit einem Eingabetextparameter dargestellt. Als Parameter können Sie den Mnemonikcode für den Autotest, den Paketnamen, den Testnamen, die Autotesteinstellung oder ein reserviertes Schlüsselwort übergeben. Die Prozedur wählt alle Autotests aus und führt sie aus, die die Bedingungen erfüllen.
Das Datengenerierungsmodul wird in Form eines Pakets dargestellt, in dem für jedes Objekt des zu testenden Systems (Tabelle in der Datenbank) eine spezielle Prozedur erstellt wird, die dort Daten einfügt. Bei diesem Verfahren werden die Standardwerte so weit wie möglich gefüllt, wodurch die Erstellung von Objekten per Fingerklick sichergestellt wird. Zur Vereinfachung der Verwendung wurden Vorlagen für die generierten Daten erstellt. Erstellen Sie beispielsweise einen Kunden eines bestimmten Alters mit einem Testtelefon und einem perfekten Kauf. - Autotests sollten zu einem für Ihr System akzeptablen Zeitpunkt ausgeführt werden. Aus diesem Grund wurde ein täglicher nächtlicher Start organisiert, dessen Ergebnisse einen Bericht über die Ergebnisse erstellen und per Unternehmenspost an das gesamte Entwicklungsteam senden. Nach dem Wiederherstellen alter und dem Erstellen neuer Autotests betrug die Gesamtbetriebszeit 30 Minuten. Eine solche Leistung war für alle geeignet, da der Start nach Stunden erfolgte.
Aber ich musste daran arbeiten, die Arbeitsgeschwindigkeit zu optimieren. Die Aktualisierung des Loyalitätssystems für die Produktion erfolgt nachts. Im Rahmen einer der Veröffentlichungen musste ich nachts dringend Änderungen vornehmen. Das halbstündige Warten auf die Ergebnisse der Autotests um drei Uhr morgens machte die für die Veröffentlichung verantwortliche Person nicht glücklich (feurige Grüße an Alexei Vasyukov!), Und am nächsten Morgen wurden viele freundliche Worte zu unserem System gesagt. Basierend auf den Ergebnissen wurde jedoch ein 5-Minuten-Arbeitsstandard festgelegt.
Um die Leistung zu beschleunigen, haben wir zwei Methoden verwendet: Autotests wurden in drei parallelen Threads ausgeführt, was aufgrund der Architektur unseres Loyalitätssystems 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 den Änderungen wurde die Gesamtbetriebszeit auf 3-4 Minuten reduziert. - Das Projekt mit automatischen Tests sollte an verschiedenen Ständen eingesetzt werden können. 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 war, und wir wandten uns industriellen Lösungen zu. Aufgrund der Tatsache, dass das Projekt viel direkten Code enthält (zunächst speichern wir den Code für Autotests) und sehr wenig Daten (die Hauptdaten sind Metadaten zu Autotests), stellte sich heraus, dass es sehr einfach ist, Liquibase in das Projekt einzuführen.
Es ist eine datenbankunabhängige Open Source-Bibliothek zum Verfolgen, Verwalten und Anwenden von Datenbankschemaänderungen. Verwaltet über Befehlszeile oder Frameworks wie Apache Maven. Das Funktionsprinzip von Liquibase ist recht einfach. Wir haben ein auf bestimmte Weise organisiertes Projekt, das aus Änderungen oder Skripten besteht, die auf den Zielserver übertragen werden müssen, und 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 Ausführungsprotokoll speichert. Jede Änderung hat einen berechneten Hash, der jedes Mal zwischen dem Projekt und dem Status in der Datenbank verglichen wird. Dank Liquibase können wir unsere Systemänderungen problemlos auf jeden Schaltkreis übertragen. Autotests werden jetzt in Test- und Release-Schleifen sowie in Containern (persönlichen Schleifen von Entwicklern) ausgeführt.
Lassen Sie uns also über die Ergebnisse der Anwendung unseres Unit-Test-Systems sprechen.
- Zunächst sind wir natürlich davon überzeugt, dass wir begonnen haben, bessere Software zu entwickeln. Autotests werden täglich ausgeführt und finden jedes Jahr Dutzende von Fehlern. Darüber hinaus hängen einige dieser Fehler nur indirekt mit der Funktionalität zusammen, die wir wirklich ändern wollten. Es gibt große Zweifel, dass diese Fehler durch manuelle Tests gefunden wurden.
- Das Team hat das Vertrauen gewonnen, dass die spezifische Funktionalität korrekt funktioniert ... Zunächst geht es um unsere kritischen Prozesse. Zum Beispiel hatten wir in den letzten sechs Monaten trotz der Änderungen in den Veröffentlichungen keine Probleme mit der Verteilung von Rabatten und Boni auf den Scheck, obwohl in den vorherigen Perioden in einigen Intervallen Fehler aufgetreten sind
- Wir konnten die Anzahl der Testiterationen reduzieren. Aufgrund der Tatsache, dass Autotests für neue Funktionen geschrieben wurden, erhalten Analytics- und Teilzeit-Tester Code mit höherer Qualität, weil Es wurde bereits verifiziert.
- Ein Teil der Entwicklungen des automatisierten Testens wird von Entwicklern verwendet. Beispielsweise werden Testdaten für Container mithilfe des Objekterzeugungsmoduls erstellt.
- Es ist wichtig, dass wir die „Einführung“ eines Systems automatisierter Tests durch Entwickler entwickelt haben. Es besteht Verständnis dafür, dass dies wichtig und nützlich ist. Und aus eigener Erfahrung kann ich sagen, dass dies weit davon entfernt ist. Autotests müssen geschrieben, gepflegt und weiterentwickelt werden, die Ergebnisse müssen analysiert werden, und oft sind diese Zeitkosten einfach nicht wert. Es ist viel einfacher, in die Produktion zu gehen und dort Probleme zu lösen. Bei uns stellen sich Entwickler an und bitten darum, ihre Funktionalität durch automatische Tests abzudecken.
Was weiter
Lassen Sie uns über die Entwicklungspläne für das automatisierte Testprojekt sprechen.
Während das Loyalitätssystem von Sportmaster noch am Leben ist und sich weiterentwickelt, ist es natürlich auch möglich, Selbsttests fast endlos zu entwickeln. Daher ist die Hauptentwicklungsrichtung die Erweiterung des Versorgungsgebiets.
Mit zunehmender Anzahl von Autotests wird die Gesamtzeit ihrer Arbeit stetig zunehmen, und wir müssen erneut auf das Thema Produktivität zurückkommen. Die Lösung besteht höchstwahrscheinlich darin, die Anzahl der parallelen Threads zu erhöhen.
Dies sind jedoch offensichtliche Entwicklungspfade. Wenn wir über etwas nicht Triviales sprechen, heben wir Folgendes hervor:
- Derzeit werden Autotests auf DBMS-Ebene verwaltet, d. H. Sie benötigen PL / SQL-Kenntnisse, um erfolgreich zu arbeiten. Wenn nötig, steuern Sie das System (z. B. Starten oder Erstellen von Metadaten). Mit Jenkins oder ähnlichem können Sie eine Art Admin-Panel erstellen.
- Jeder liebt quantitative und qualitative Indikatoren. Für automatisierte Tests ist eine solche universelle Metrik Code Coverage oder Code Coverage Metrics. Mit diesem Indikator können wir bestimmen, wie viel Prozent des Codes unseres Testsystems von Autotests abgedeckt werden. Ab Version 12.2 bietet Oracle die Möglichkeit, diese Metrik zu berechnen, und schlägt die Verwendung des Standardpakets DBMS_PLSQL_CODE_COVERAGE vor.
Unser Autotest-System ist etwas mehr als ein Jahr alt, und vielleicht ist es jetzt an der Zeit, die Abdeckung zu bewerten. In meinem letzten Projekt (ein Projekt, das nicht von Sportmaster stammt) ist es passiert. Ein Jahr nach der Arbeit an Autotests hat sich das Management zum Ziel gesetzt, zu bewerten, wie viel Prozent des Codes wir abdecken. Mit einer Abdeckung von mehr als 1% würde sich das Management freuen. Wir, die Entwickler, haben ein Ergebnis von ca. 10% erwartet. Die gemessene Codeabdeckung für Schrauben ergab 20%. Um zu feiern, haben wir uns einen Preis geholt, aber wie wir uns dafür entschieden haben und wohin wir später gingen, ist eine ganz andere Geschichte. - Automatische Tests können die exponierten Webdienste überprüfen. Mit Oracle können Sie dies tun, und wir werden nicht mehr auf eine Reihe von Problemen stoßen.
- Und natürlich kann unser automatisiertes Testsystem auf ein anderes Projekt angewendet werden. Unsere Lösung ist universell und erfordert nur die Verwendung von Oracle. Ich habe gehört, dass bei anderen Projekten von Sportmaster ein Interesse an automatischen Tests besteht und wir vielleicht zu ihnen gehen werden.
Schlussfolgerungen
Fassen wir zusammen. Für das Projekt, das Loyalitätssystem in Sportmaster, ist es uns gelungen, ein automatisiertes Testsystem zu implementieren. Grundlage ist die utPLSQL-Lösung von Stephen Feuerstein. Um utPLSQL herum gibt es den Autotest-Code und zusätzliche selbstgeschriebene Module: Startmodul, Datengenerierungsmodul und andere. Autotests werden täglich ausgeführt und funktionieren vor allem und bringen Vorteile. Wir sind überzeugt, dass wir begonnen haben, qualitativ hochwertigere Software herauszubringen. Gleichzeitig ist die resultierende Lösung universell und kann frei auf jedes Projekt angewendet werden, bei dem automatisierte Tests unter Oracle DBMS organisiert werden müssen.
PS Dieser Artikel ist nicht sehr spezifisch: Es gibt viel Text und fast keine technischen Beispiele. Wenn das Thema global interessant ist, können wir es fortsetzen und mit einer Fortsetzung zurückkehren, in der wir Ihnen mitteilen, was sich in den letzten sechs Monaten geändert hat, und Codebeispiele geben.
Schreiben Sie Kommentare, wenn es Punkte gibt, auf die es sich lohnt, sich in Zukunft zu konzentrieren, oder wenn Fragen offengelegt werden müssen.