Unit-Tests in Datenbanksystemen — wie wir es bei Sportmaster machen, Teil eins

Hallo, Habra!

Mein Name ist Maxim Ponomarenko und ich bin Entwickler bei Sportmaster. Ich habe 10 Jahre Erfahrung im IT-Bereich. Ich begann meine Karriere im Bereich der manuellen Tests und wechselte dann zur Datenbankentwicklung. In den letzten 4 Jahren, in denen ich Wissen aus dem Testen und der Entwicklung gesammelt habe, beschäftige ich mich mit der Automatisierung von Tests auf Ebene des DBMS.

Ich bin seit etwas mehr als einem Jahr im Team von Sportmaster und arbeite an einem größeren Projekt, in dem ich die Entwicklung automatisierter Tests leite. Im April haben wir mit den Jungs von Sportmaster Lab auf einer Konferenz in Krasnodar gesprochen, mein Vortrag hatte den Titel „Unit-Tests im DBMS“, und jetzt möchte ich ihn mit Ihnen teilen. Es wird viel Text geben, daher habe ich beschlossen, den Vortrag in zwei Posts aufzuteilen. Im ersten werden wir über Automatisierungstests und Testing im Allgemeinen sprechen, und im zweiten werde ich näher auf unser System der Unit-Tests und die Ergebnisse seiner Anwendung eingehen.

Zunächst ein wenig trockene Theorie. Was ist automatisiertes Testen? Das ist Testen, das mit Software-Tools durchgeführt wird, und in der modernen IT wird es immer häufiger bei der Softwareentwicklung eingesetzt. Das hängt damit zusammen, dass Unternehmen wachsen, ihre Informationssysteme wachsen und dementsprechend auch die Anzahl der Funktionen, die getestet werden müssen, zunimmt. Es wird immer schwieriger, manuelle Tests durchzuführen.

Ich habe in einem großen Unternehmen gearbeitet, dessen Releases alle zwei Monate erscheinen. Dabei wurde ein ganzer Monat dafür aufgewendet, dass ein Dutzend Tester den Funktionsumfang manuell überprüften. Durch die Implementierung von Automatisierung mit einem kleinen Team von Entwicklern konnten wir die Testzeit in anderthalb Jahren auf 2 Wochen verkürzen. Wir haben nicht nur die Geschwindigkeit des Testens erhöht, sondern auch dessen Qualität verbessert. Automatisierte Tests werden regelmäßig ausgeführt und führen stets alle in ihnen festgelegten Prüfungen durch, das heißt, wir schließen den menschlichen Faktor aus.

Für die moderne IT ist charakteristisch, dass von einem Entwickler nicht nur erwartet wird, Produktcode zu schreiben, sondern auch Unit-Tests, die diesen Code überprüfen.

Was ist jedoch zu tun, wenn Ihr System hauptsächlich auf Serverlogik basiert? Es gibt keine universelle Lösung oder Best Practices auf dem Markt. In der Regel lösen Unternehmen dieses Problem, indem sie ihr eigenes maßgeschneidertes Testsystem erstellen. Ein solches maßgeschneidertes automatisiertes Testsystem wurde in unserem Projekt entwickelt, und darüber werde ich in meinem Vortrag berichten.

Wir testen die Loyalität

Zunächst sprechen wir über das Projekt, in dem wir das automatisierte Testsystem implementiert haben. Unser Projekt ist das Loyalitätssystem von Sportmaster (übrigens haben wir bereits darüber geschrieben in diesem Beitrag).

Wenn Ihr Unternehmen groß genug ist, wird Ihr Loyalitätssystem drei Standardmerkmale aufweisen:

• Ihr System wird hochgradig belastet sein
• Ihr System wird komplexe Berechnungsprozesse enthalten
• Ihr System wird aktiv weiterentwickelt werden.

Fangen wir der Reihe nach an… Insgesamt, wenn man alle Marken von Sportmaster betrachtet, haben wir in Russland, der Ukraine, China, Kasachstan und Weißrussland über 1000 Geschäfte. In diesen Geschäften werden täglich etwa 300.000 Käufe getätigt. Das bedeutet, jede Sekunde gelangen 3-4 Quittungen in unser System. Natürlich ist unser Loyalitätssystem hochgradig belastet. Und da es aktiv genutzt wird, müssen wir die höchsten Qualitätsstandards sicherstellen, denn jeder Fehler in der Software führt zu erheblichen finanziellen, reputativen und anderen Verlusten.

Gleichzeitig sind bei Sportmaster mehr als hundert verschiedene Aktionen aktiv. Die Aktionen sind sehr unterschiedlich: es gibt Produktaktionen, solche, die an bestimmten Wochentagen stattfinden, spezifisch an Geschäfte gebundene Aktionen, sowie Aktionen, die an den Bestellbetrag oder die Anzahl der Produkte gekoppelt sind. Insgesamt ist das ziemlich komplex. Kunden haben Boni und Promocodes, die sie beim Einkaufen verwenden. All dies führt dazu, dass die Abrechnung jeder Bestellung eine recht anspruchsvolle Aufgabe ist.

Der Algorithmus, der die Auftragsbearbeitung implementiert, ist wirklich schrecklich und kompliziert. Jede Änderung an diesem Algorithmus ist eine recht riskante Angelegenheit. Es stellte sich heraus, dass selbst die äußerlich unbedeutendsten Änderungen zu ziemlich unvorhersehbaren Ergebnissen führen können. Gerade solche komplexen Berechnungsprozesse, die zudem kritische Funktionen implementieren, sind die besten Kandidaten für die Automatisierung. Die manuelle Überprüfung dutzender identischer Fälle ist zeitaufwendig. Da der Einstiegspunkt in den Prozess unverändert bleibt, kann man, einmal beschrieben, recht schnell automatische Tests generieren und sich auf die Funktionalität verlassen.

Da unser System aktiv genutzt wird, wird das Geschäft von Ihnen etwas Neues verlangen, um mit der Zeit Schritt zu halten und kundenorientiert zu sein. In unserem Treueprogramm erscheinen alle zwei Monate Releases. Das bedeutet, dass wir alle zwei Monate einen vollständigen Regressionstest des gesamten Systems durchführen müssen. Zumal, wie in jeder modernen IT, die Entwicklung nicht sofort vom Entwickler in die Produktion gelangt. Sie entsteht zunächst in der Entwicklungsumgebung, durchläuft dann nacheinander die Testumgebung, die Release-Umgebung, die Abnahme und gelangt erst dann in die Produktion. Mindestens in der Test- und Release-Umgebung müssen wir einen vollständigen Regressionstest des gesamten Systems durchführen.

Die beschriebenen Eigenschaften sind standardmäßig für nahezu jedes Treueprogramm. Lassen Sie uns über die Besonderheiten unseres Projekts sprechen.

Technologisch liegt die Logik unseres Treueprogramms zu 90% auf Serverseite und ist in Oracle implementiert. Es gibt einen Client auf Delphi, der die Funktion des Administrator-Arbeitsplatzes ausführt. Es gibt auch Webdienste für externe Anwendungen (zum Beispiel die Website). Daher ist es durchaus logisch, dass wir, wenn wir ein automatisiertes Testsystem aufbauen, dies in Oracle tun werden.

Das Loyalitätssystem bei Sportmaster existiert seit über 7 Jahren und wurde von einzelnen Entwicklern erstellt… Im Durchschnitt waren während dieser 7 Jahre 3-4 Entwickler an unserem Projekt beteiligt. Aber im letzten Jahr hat sich unser Team erheblich vergrößert, und jetzt arbeiten 10 Personen an dem Projekt. Das bedeutet, dass neue Leute hinzukommen, die mit typischen Aufgaben, Prozessen und der Architektur nicht vertraut sind. Und es besteht ein erhöhtes Risiko, dass wir Fehler übersehen werden.

Das Projekt zeichnet sich durch das Fehlen von dedizierten Testern als feste Mitarbeiter aus. Tests finden zwar statt, aber diese werden von Analysten durchgeführt, zusätzlich zu ihren anderen Hauptaufgaben: dem Kontakt mit den Geschäftskunden, den Nutzern, der Ausarbeitung von Systemanforderungen usw. Trotz der Tatsache, dass die Tests sehr qualitativ durchgeführt werden (das sollte besonders erwähnt werden, da möglicherweise einige Analysten diesen Bericht lesen), bleibt die Effizienz der Spezialisierung und Konzentration auf ein einziges Thema unbestreitbar.

Angesichts des Vorangegangenen erscheint die Idee der Automatisierung von Tests im Projekt als sehr logisch, um die Qualität des gelieferten Produkts zu erhöhen und die Entwicklungszeiten zu verkürzen. In verschiedenen Phasen der Existenz des Loyalitätssystems haben einzelne Entwickler versucht, ihren Code mit Unit-Tests abzudecken. Dies war insgesamt ein recht zersplitterter Prozess, bei dem jeder seine eigene Architektur und Methoden verwendete. Gemeinsam für die Unit-Tests waren die Endergebnisse: Die Tests wurden entwickelt, eine Zeit lang genutzt, in ein Versionsspeicher abgelegt, aber irgendwann hörten sie auf, ausgeführt zu werden, und wurden vergessen. Dies geschah in erster Linie, weil die Tests mehr an einen bestimmten Entwickler als an das Projekt gebunden waren.

Hier kommt utPLSQL ins Spiel

Wissen Sie etwas über Steven Feuerstein?

Dies ist ein kluger Kerl, der einen großen Teil seiner Karriere der Arbeit mit Oracle und PL/SQL gewidmet hat und zu diesem Thema eine beträchtliche Anzahl von Arbeiten verfasst hat. Ein bekanntes Buch von ihm heißt: „Oracle PL/SQL. Für Profis“. Steven ist der Entwickler der Lösung utPLSQL, was ausgeschrieben das Unit Testing Framework für Oracle PL/SQL bedeutet. Die Lösung utPLSQL wurde 2016 entwickelt, wird jedoch weiterhin aktiv bearbeitet und neue Versionen werden herausgebracht. Zum Zeitpunkt des Vortrags war die letzte Version vom 24. März 2019.
Was ist das eigentlich? Es handelt sich um ein separates Open-Source-Projekt. Es hat ein paar Megabyte, einschließlich Beispiele und Dokumentation. Physisch stellt es ein separates Schema in der ORACLE-Datenbank dar, mit einem Satz von Paketen und Tabellen zur Organisation von Unit-Tests. Die Installation dauert nur wenige Sekunden. Ein herausragendes Merkmal von utPLSQL ist die Benutzerfreundlichkeit.
Im Großen und Ganzen stellt utPLSQL einen Mechanismus zum Ausführen von Unit-Tests dar, wobei unter einem Unit-Test normale Oracle-Paketprozeduren verstanden werden, deren Organisation bestimmten Regeln entspricht. Neben der Ausführung speichert utPLSQL ein Protokoll aller Ihrer Testdurchläufe und bietet ein internes Berichtssystem.

Lassen Sie uns am Beispiel sehen, wie der Code eines Unit-Tests aussieht, der nach dieser Methode implementiert ist.

So, auf dem Bildschirm sehen wir den Code einer typischen Paket-Spezifikation mit Unit-Tests. Welche obligatorischen Anforderungen gibt es? Das Paket muss mit dem Präfix „utp_“ beginnen. Genau der gleiche Präfix sollte auch für alle Testprozeduren verwendet werden. Im Paket müssen unbedingt zwei Standardprozeduren vorhanden sein: „utp_setup“ und „utp_teardown“. Die erste Prozedur wird vor jedem Unit-Test aufgerufen, die zweite nach der Ausführung.

„utp_setup“ bereitet in der Regel unser System auf die Ausführung des Unit-Tests vor, indem sie beispielsweise Testdaten erstellt. „utp_teardown“ hingegen stellt alles auf die Ausgangseinstellungen zurück und setzt die Ergebnisse der Ausführung zurück.

Hier ist ein Beispiel für den einfachsten Unit-Test, der die Normalisierung der eingegebenen Telefonnummer des Kunden auf das für unser Loyalitätssystem standardisierte Format überprüft. Es gibt keine verbindlichen Standards dafür, wie Verfahren mit Unit-Tests geschrieben werden sollten. In der Regel wird eine Methode des zu testenden Systems aufgerufen und das Ergebnis, das von dieser Methode zurückgegeben wird, mit einem Referenzwert verglichen. Wichtig ist, dass der Vergleich zwischen dem Referenzwert und dem erhaltenen Ergebnis durch die standardmäßigen utPLSQL-Methoden erfolgt.

In einem Unit-Test kann es beliebig viele Überprüfungen geben. Wie im Beispiel zu sehen ist, führen wir vier aufeinanderfolgende Aufrufe der getesteten Methode zur Normalisierung der Telefonnummer durch und bewerten nach jedem Aufruf das Ergebnis. Bei der Entwicklung des Unit-Tests muss berücksichtigt werden, dass es Überprüfungen gibt, die keinen Einfluss auf das System haben, während nach anderen zurück zum ursprünglichen Zustand des Systems gewechselt werden muss.
Zum Beispiel formatieren wir im vorgestellten Unit-Test einfach die eingegebene Telefonnummer, was sich in keiner Weise auf das Loyalitätssystem auswirkt.

Wenn wir jedoch Unit-Tests für die Methode zur Erstellung eines neuen Kunden schreiben, wird nach jeder Überprüfung ein neuer Kunde im System erstellt, was die nachfolgende Ausführung des Tests beeinflussen kann.

So werden Unit-Tests ausgeführt. Es gibt zwei zulässige Ausführungsvarianten: die Ausführung aller Unit-Tests aus einem bestimmten Paket oder die Ausführung eines bestimmten Unit-Tests in einem bestimmten Paket.

So sieht ein Beispiel für ein internes Berichtssystem aus. Auf Grundlage der Ergebnisse des Unit-Tests erstellt utPLSQL einen kleinen Bericht. In diesem sehen wir das Ergebnis jeder spezifischen Überprüfung und das Gesamtergebnis der Ausführung des Unit-Tests.

6 Regeln für automatisierte Tests

Bevor wir mit der Erstellung eines neuen automatisierten Testsystems für das Loyalitätssystem beginnen, haben wir gemeinsam mit der Geschäftsführung die Prinzipien festgelegt, denen unsere zukünftigen automatisierten Tests entsprechen müssen.

1. Automatisierte Tests müssen effektiv sein und Nutzen bringen. Wir haben großartige Entwickler, über die man unbedingt sprechen muss, da einige von ihnen wahrscheinlich diesen Bericht sehen werden, und sie schreiben hervorragenden Code. Doch selbst ihr hervorragender Code ist nicht perfekt und enthielt, enthält und wird Fehler beinhalten. Automatisierte Tests müssen diese Fehler finden. Wenn dem nicht so ist, dann schreiben wir entweder schlechte Tests oder wir sind in einem toten Bereich, der grundsätzlich nicht weiterentwickelt wird. In beiden Fällen machen wir etwas falsch und unser Ansatz ist einfach sinnlos.
2. Automatisierte Tests müssen verwendet werden. Es ist sinnlos, eine Menge Zeit und Mühe in die Erstellung eines Softwareprodukts zu investieren, das Repository zusammenzustellen und es dann zu vergessen. Tests sollten durchgeführt werden, und zwar so regelmäßig wie möglich.
3. Automatisierte Tests müssen stabil arbeiten. Unabhängig von der Tageszeit, dem Teststand und anderen Systemkonfigurationen sollten die Testergebnisse immer gleich sein. In der Regel wird dies sichergestellt, indem automatisierte Tests mit speziellen Testdaten und festen Systemeinstellungen arbeiten.
4. Automatisierte Tests müssen mit einer für Ihr Projekt akzeptablen Geschwindigkeit arbeiten. Diese Zeit wird individuell für jedes System festgelegt. Manche können es sich leisten, den ganzen Tag zu arbeiten, während andere unbedingt in Sekundenfrist fertig werden müssen. Welche Geschwindigkeitsnormen wir in unserem Projekt erreicht haben, werde ich später erläutern.
5. Die Entwicklung automatisierter Tests sollte flexibel sein. Es ist unerwünscht, auf die Überprüfung bestimmter Funktionen zu verzichten, nur weil wir dies bisher nicht gemacht haben oder aus anderen Überzeugungen. utPLSQL setzt keine Einschränkungen bei der Entwicklung, und Oracle erlaubt grundsätzlich die Umsetzung der unterschiedlichsten Dinge. Die meisten Probleme haben eine Lösung, es ist nur eine Frage der Zeit und des Aufwands.
6. Deployability. Wir haben mehrere Stände, an denen Tests durchgeführt werden müssen. An jedem dieser Stände kann zu jeder Zeit ein Daten-Dump aktualisiert werden. Projekte mit automatisierten Tests müssen so geführt werden, dass eine vollständige oder teilweise Installation ohne Probleme möglich ist.

In dem nächsten Beitrag in ein paar Tagen werde ich erzählen, was wir gemacht haben und welche Ergebnisse wir erzielt haben.

Quelle: habr.com