Unit-Tests in DBMS – so machen wir das bei Sportmaster, Teil eins

Hallo, Habr!

Mein Name ist Maksim Ponomarenko und ich bin Entwickler bei Sportmaster. Ich habe 10 Jahre Erfahrung in der IT-Branche. Meine Karriere begann im Bereich manuelles Testen, bevor ich zur Datenbankentwicklung wechselte. In den letzten 4 Jahren setze ich das Wissen, das ich im Testen und Entwickeln gesammelt habe, zur Automatisierung von Tests auf Datenbankebene ein.

Ich bin seit etwas mehr als einem Jahr im Team von Sportmaster und arbeite an einem großen Projekt, in dem ich automatisierte Tests entwickle. Im April haben wir mit den Kollegen aus Sportmaster Lab auf einer Konferenz in Krasnodar einen Vortrag gehalten, mein Thema lautete „Unit-Tests in der Datenbank“. Jetzt möchte ich diesen Vortrag mit Ihnen teilen. Es wird viel Text geben, daher habe ich beschlossen, den Vortrag auf zwei Beiträge aufzuteilen. Im ersten Teil sprechen wir über automatisierte Tests und Testen im Allgemeinen, und im zweiten Teil werde ich genauer auf unser Unit-Test-System und die Ergebnisse seiner Anwendung eingehen.

Zunächst einige theoretische Grundlagen. Was ist automatisiertes Testen? Dabei handelt es sich um Testprozesse, die mit Software-Werkzeugen durchgeführt werden und im modernen IT-Umfeld zunehmend bei der Softwareentwicklung eingesetzt werden. Das liegt daran, dass Unternehmen wachsen, ihre Informationssysteme sich ausdehnen und dementsprechend die Anzahl der Funktionen, die getestet werden müssen, steigt. Manuelles Testen wird daher immer aufwändiger.

Ich habe in einem großen Unternehmen gearbeitet, dessen Releases alle zwei Monate veröffentlicht werden. Ein ganzer Monat wurde darauf verwendet, dass ein Dutzend Tester den Funktionsumfang manuell überprüften. Durch die Implementierung von Automatisierung in einem kleinen Entwicklerteam gelang es uns, die Testzeit innerhalb von anderthalb Jahren auf 2 Wochen zu verkürzen. Wir haben nicht nur die Geschwindigkeit des Testens erhöht, sondern auch die Qualität verbessert. Automatisierte Tests werden regelmäßig durchgeführt und durchlaufen immer alle vorgesehenen Überprüfungen, wodurch wir den menschlichen Faktor ausschließen.

Moderne IT-Fachkräfte müssen nicht nur Produktcode schreiben, sondern auch Unit-Tests, die diesen Code überprüfen.

Was aber, wenn Ihre Systeme überwiegend auf serverseitiger Logik basieren? Es gibt keine universelle Lösung oder Best Practices auf dem Markt. In der Regel lösen Unternehmen dieses Problem, indem sie ein eigenes, maßgeschneidertes Testsysteem entwickeln. 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

Lassen Sie uns mit dem Projekt beginnen, 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 standardisierte Eigenschaften aufweisen:

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

Lass uns der Reihe nach vorgehen... Insgesamt haben wir, wenn wir alle Marken von Sportmaster betrachten, über 1.000 Geschäfte in Russland, der Ukraine, China, Kasachstan und Weißrussland. In diesen Geschäften werden täglich etwa 300.000 Käufe getätigt. Das bedeutet, dass jede Sekunde 3-4 Belege in unser System gelangen. Natürlich ist unser Loyalitätssystem stark belastet. Da es intensiv genutzt wird, sind wir verpflichtet, die höchsten Qualitätsstandards bereitzustellen, denn jeder Fehler in der Software hat große finanzielle, reputationsbezogene und andere Verluste zur Folge.

Gleichzeitig laufen bei Sportmaster über einhundert verschiedene Aktionen. Die Aktionen sind sehr vielfältig: Es gibt Produktaktionen, solche, die an bestimmte Wochentage gebunden sind, sowie solche, die an ein bestimmtes Geschäft geknüpft sind, und Aktionen, die sich auf den Bestellwert oder die Anzahl der Produkte beziehen. Kurz gesagt, es ist beeindruckend. Die Kunden haben Boni und nutzen Promo-Codes bei ihren Einkäufen. All dies führt dazu, dass die Abrechnung jeder Bestellung eine durchaus anspruchsvolle Aufgabe darstellt.

Der Algorithmus, der die Auftragsverarbeitung implementiert, ist wirklich komplex und problematisch. Jede Änderung an diesem Algorithmus ist eine riskante Angelegenheit. Selbst scheinbar geringfügige Anpassungen können zu unvorhersehbaren Ergebnissen führen. Solche komplexen Berechnungsprozesse, die zudem kritische Funktionen realisieren, sind ideal für die Automatisierung. Manuell Dutzende von ähnlichen Fällen zu überprüfen, kostet viel Zeit. Da der Einstiegspunkt im Prozess unverändert bleibt, genügt es, ihn einmal zu beschreiben, um schnell automatisierte Tests zu erstellen und sicherzustellen, dass die Funktionalität einwandfrei arbeitet.

Da unser System aktiv genutzt wird, erwartet das Geschäft von Ihnen ständige Neuerungen, um mit der Zeit Schritt zu halten und kundenorientiert zu sein. In unserem Loyalitätsprogramm erscheinen alle zwei Monate neue Releases. Das bedeutet, dass wir alle zwei Monate einen vollständigen Regressionstest des gesamten Systems durchführen müssen. Wie in jeder modernen IT-Umgebung geht die Entwicklung nicht direkt vom Entwickler in die Produktion. Der Prozess beginnt im Entwickler-Kontourn, durchläuft dann nacheinander die Test-, Release- und Abnahmeumgebung und landet schließlich in der Produktion. Mindestens in den Test- und Release-Konturen müssen wir einen vollständigen Regressionstest des gesamten Systems durchführen.

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

Die technische Logik unseres Loyalitätssystems basiert zu 90 % auf Servertechnologie und wurde auf Oracle implementiert. Es gibt einen Delphi-Client, der die Funktion eines Administrationsarbeitsplatzes erfüllt. Zudem stehen Web-Services für externe Anwendungen (wie zum Beispiel die Website) zur Verfügung. Daher ist es nur logisch, dass wir, wenn wir ein automatisiertes Testsystem aufbauen, dies auf Oracle realisieren werden.

Das Loyalitätssystem bei Sportmaster existiert seit über 7 Jahren und wurde von einzelnen Entwicklern geschaffen. Die durchschnittliche Anzahl der Entwickler in unserem Projekt lag während dieser 7 Jahre bei 3-4 Personen. Im letzten Jahr hat sich unser Team jedoch stark vergrößert, und nun arbeiten 10 Personen an dem Projekt. Das bedeutet, dass neue Mitglieder ins Team kommen, die mit den typischen Aufgaben, Prozessen und der Architektur nicht vertraut sind. Dadurch besteht ein erhöhtes Risiko, dass wir Fehler übersehen.

Für das Projekt ist charakteristisch, dass es keine dedizierten Tester als feste Mitarbeiter gibt. Es findet zwar Testing statt, doch diese Aufgabe wird von den Analysten neben ihren weiteren Hauptaufgaben übernommen: Sie kommunizieren mit den Geschäftsauftraggebern, den Nutzern und arbeiten an den Anforderungen des Systems usw. Obwohl das Testing sehr qualitativ durchgeführt wird (dieser Hinweis ist besonders relevant, da es einem der Analysten, der diesen Bericht sieht, auffallen könnte), ist die Effizienz von Spezialisierung und Fokussierung auf eine einzige Tätigkeit nicht zu unterschätzen.

Unter Berücksichtigung all dieser Punkte erscheint die Idee, das Testen im Projekt zu automatisieren, um die Qualität des Endprodukts zu verbessern und die Entwicklungszeiten zu verkürzen, äußerst logisch. In verschiedenen Phasen der Loyalitätssystem-Entwicklung haben einzelne Entwickler versucht, ihren Code mit Unit-Tests abzudecken. Dieser Prozess war insgesamt recht fragmentiert, da jeder seine eigene Architektur und Methoden verwendete. Gemeinsam bei den Unit-Tests waren die endgültigen Ergebnisse: Tests wurden entwickelt, eine Zeit lang verwendet, in einem Versionsspeicher abgelegt, aber irgendwann wurden sie nicht mehr ausgeführt und gerieten in Vergessenheit. Dies geschah in erster Linie, weil die Tests mehr an den jeweiligen Entwickler als an das Projekt gebunden waren.

Hier kommt utPLSQL ins Spiel.

Wissen Sie etwas über Steven Feuerstein?

Das ist ein kluger Mann, der einen Großteil seiner Karriere der Arbeit mit Oracle und PL/SQL gewidmet hat und zu diesem Thema eine beachtliche Anzahl von Arbeiten verfasst hat. Ein bekanntes Buch von ihm trägt den Titel: „Oracle PL/SQL. Für Profis“. Steven ist der Entwickler der Lösung utPLSQL, die für Unit Testing Framework für Oracle PL/SQL steht. Die Lösung utPLSQL wurde 2016 ins Leben gerufen, wird aber weiterhin aktiv weiterentwickelt und es erscheinen neue Versionen. Zum Zeitpunkt des Vortrags war die letzte Version vom 24. März 2019.
Was ist das genau? 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 einer Sammlung von Paketen und Tabellen zur Organisation von Unit-Tests. Die Installation dauert nur wenige Sekunden. Ein herausragendes Merkmal von utPLSQL ist die Einfachheit der Handhabung.
Weltweit betrachtet ist utPLSQL ein Mechanismus zum Ausführen von Unit-Tests, wobei unter einem Unit-Test die üblichen Oracle-Paketprozeduren verstanden werden, deren Organisation bestimmten Regeln entspricht. Neben der Ausführung speichert utPLSQL ein Protokoll aller Ihrer Testdurchläufe und verfügt über ein internes Berichtssystem.

Lassen Sie uns anhand eines Beispiels anschauen, wie der Code eines Unit-Tests aussieht, der nach dieser Methode umgesetzt wurde.

Auf dem Bildschirm sehen Sie den Code einer typischen Paket-Spezifikation mit Unit-Tests. Welche Anforderungen sind verpflichtend? Das Paket muss das Präfix „utp_“ tragen. Alle Testprozeduren müssen ebenfalls das gleiche Präfix haben. 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 danach.

Die Prozedur „utp_setup“ bereitet in der Regel unser System für die Ausführung des Unit-Tests vor, zum Beispiel durch das Erstellen von Testdaten. „utp_teardown“ hingegen stellt alles auf die ursprünglichen Einstellungen zurück und löscht die Ergebnisse des Durchlaufs.

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

Im 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 das Ergebnis nach jedem Aufruf. Bei der Entwicklung des Unit-Tests muss berücksichtigt werden, dass es Überprüfungen gibt, die die Systemintegrität nicht beeinflussen, und dass nach bestimmten Überprüfungen zum ursprünglichen Zustand des Systems zurückgerollt werden muss.
Zum Beispiel formatieren wir im präsentierten Unit-Test einfach die eingehende Telefonnummer, was sich nicht auf das Loyalitätssystem auswirkt.

Wenn wir Unit-Tests für die Methode zur Erstellung eines neuen Kunden schreiben, wird nach jeder Überprüfung ein neuer Kunde im System angelegt, was den nachfolgenden Testlauf beeinflussen kann.

So werden Unit-Tests gestartet. Es sind zwei Ausführungsvarianten zulässig: 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. Basierend auf den Ergebnissen des Unit-Tests erstellt utPLSQL einen kleinen Bericht. Darin sehen wir das Ergebnis jeder spezifischen Überprüfung sowie das Gesamtergebnis der Ausführung des Unit-Tests.

6 Regeln für automatisierte Tests

Bevor wir mit der Erstellung eines neuen Systems für automatisierte Tests des Loyalitätssystems beginnen, haben wir gemeinsam mit der Geschäftsführung die Prinzipien festgelegt, die unsere zukünftigen automatisierten Tests erfüllen müssen.

1. Automatisierte Tests müssen effektiv sein und einen Mehrwert bieten. Wir haben großartige Entwickler, die unbedingt erwähnt werden sollten, denn einige von ihnen werden diesen Bericht sicherlich lesen, und sie schreiben hervorragenden Code. Doch selbst ihr hervorragender Code ist nicht perfekt und enthält, enthält und wird Fehler enthalten. Automatisierte Tests müssen diese Fehler finden. Wenn das nicht der Fall ist, schreiben wir entweder schlechte automatisierte Tests oder wir befinden uns im Toten Winkel, 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, viel Zeit und Mühe in die Erstellung eines Softwareprodukts zu investieren, es in ein Repository zu legen und es dann zu vergessen. Tests sollten ausgeführt werden, und zwar so regelmäßig wie möglich.
3. Automatisierte Tests müssen stabil laufen. Unabhängig von der Tageszeit, der Testumgebung und anderen Systemeinstellungen sollten die Testläufe immer zum gleichen Ergebnis führen. In der Regel wird dies dadurch gewährleistet, dass automatisierte Tests mit speziellen Testdaten arbeiten, die mit fixen Systemeinstellungen konfiguriert sind.
4. Automatisierte Tests müssen mit einer für Ihr Projekt akzeptablen Geschwindigkeit arbeiten. Diese Zeit wird individuell für jedes System festgelegt. Einige können den ganzen Tag arbeiten, während es für andere entscheidend ist, in Sekundenbruchteilen abzuschließen. Welche Leistungsstandards wir in unserem Projekt erreicht haben, werde ich Ihnen später erklären.
5. Die Entwicklung automatisierter Tests sollte flexibel sein. Es ist nicht ratsam, die Überprüfung von Funktionen aufzugeben, nur weil wir das bisher noch nicht gemacht haben oder aus anderen Überzeugungen. utPLSQL setzt keine Beschränkungen für die Entwicklung, und Oracle erlaubt grundsätzlich die Umsetzung vielfältiger Lösungen. Die meisten Aufgaben haben Lösungen, wobei die Frage nur die Zeit und den Aufwand betrifft.
6. Bereitstellbarkeit. Wir haben mehrere Stände, an denen Tests gestartet werden müssen. An jedem dieser Stände kann jederzeit ein Daten-Dump aktualisiert werden. Es ist notwendig, ein Projekt mit automatisierten Tests so zu führen, dass eine vollständige oder teilweise Installation problemlos durchgeführt werden kann.

In einem zweiten Beitrag in ein paar Tagen werde ich darüber berichten, was wir gemacht haben und welche Ergebnisse wir erzielt haben.

Quelle: habr.com