Wenn Sie die Pflege Ihrer Oracle BRM (Billing and Revenue Management) einige Zeit lang konfiguriert haben, werden Sie feststellen, dass die Anzahl der konfigurierten Einheiten immer weiter wächst. Es ist sehr wahrscheinlich, dass Sie inzwischen auch einige Anpassungen entwickelt und zusätzliche Lösungen integriert haben. Die Entwicklung Ihrer Umgebung führt zu einer komplexen Ansammlung von miteinander verflochtenen Objekten. Es kommt der Punkt, an dem Sie oder Ihr Kunde beschließen, etwas zu ändern. Die neue Funktion mag auf den ersten Blick einfach zu entwickeln sein. Die Wahrheit ist jedoch, dass sie sehr wahrscheinlich mit einer bestehenden Funktion kollidiert oder die Aktualisierung einer bestehenden Konfiguration erfordert. Was als einfache Änderung erschien, wirkt sich dann auf das gesamte System aus. Solche Ereignisse lassen sich manchmal nur schwer vermeiden, aber wenn Sie darauf vorbereitet sind, können Sie sich eine Menge Ärger ersparen. Funktionale Testszenarien und die Vielseitigkeit von Tests können den Ausschlag geben.
Inhaltsverzeichnis
Kontinuierlicher Entwicklungsfluss
Hier bei Tridens haben wir einen kontinuierlichen Entwicklungsfluss eingerichtet. Alle unsere BRM-Konfigurationen, Anpassungen und anderen integrierten Komponenten sind ordnungsgemäß versioniert und werden über ein verteiltes Versionskontrollsystem (Git) verfolgt. Dank dieser Praxis können unsere Entwickler jederzeit die erforderlichen Komponentenversionen auschecken und mit ihrer Arbeit beginnen. Bis zu diesem Punkt ist alles in Ordnung, aber wie gehen wir mit der Möglichkeit um, dass neue Funktionen den aktuellen Build beschädigen?
Wir haben einen Bereitstellungs- und Testablauf eingerichtet, der die Remote-Repositories unserer Quellen verfolgt. Jedes Mal, wenn ein Entwickler einige Änderungen an die Versionskontrolle überträgt, wird der Testprozess eingeleitet. Der Bereitstellungsablauf erstellt Docker-Images für alle relevanten Komponenten mit ihren neuesten Versionen in einer lokalen (oder entfernten) Umgebung, und es werden automatische Tests ausgeführt, um sicherzustellen, dass der Build stabil ist. Nur wenn die Tests erfolgreich sind, können wir die neuen Versionen für die Produktion freigeben. Mit diesem Prozess stellen wir sicher, dass neue Funktionen nahtlos mit den bestehenden zusammenarbeiten. Die ausgeführten Tests sind Teil des Oracle BRM TestToolkit, das wir entwickelt haben. Das BRM TestToolkit verfügt über vordefinierte Schritte und Szenarien mit Klebecode im Hintergrund. Die Schritte sind sehr anschaulich und benutzerfreundlich, so dass unsere Entwickler oder jeder andere Benutzer schnell neue Testszenarien schreiben können. Ein Beispiel für Testszenarien finden Sie in der Abbildung unten.
BRM TestToolkit für automatisierte Tests
Was als einfache Testszenarien für Kontoeröffnungen und Produktkäufe begann, stellt heute den Hauptrahmen unseres BRM TestToolkits dar. Um das zu verdeutlichen, haben wir jetzt mehrere verschiedene Testfälle und Fringe-Case-Szenarien, um eine maximale Abdeckung der implementierten Funktionen zu gewährleisten. Automatisierte Tests ermöglichen es unseren Entwicklern, sich auf die eigentliche Aufgabe zu konzentrieren und nicht Unmengen an Zeit für manuelle Tests aufzuwenden. Natürlich kommt es manchmal vor, dass wir eine neue Funktion entwickeln, die noch nicht durch Testszenarien abgedeckt ist. In solchen Fällen werden Testschrittdefinitionen und ihr Hintergrundcode als Teil dieser Funktion implementiert - damit sie auch in Zukunft verwendet werden können.
Das TestToolkit kann mit verschiedenen Komponenten kommunizieren, so dass schnelle Anpassungen auch für andere Systeme möglich sind. Wir verwenden auch überarbeitete Versionen unseres BRM TestToolkits für unsere anderen Komponenten. Eine der neuesten Funktionen, die wir hinzugefügt haben, ist die Modularität, bei der Entwickler verschiedene Testszenarien als Teile einer Gruppe kennzeichnen können. Jede Gruppe verfügt dann über eigene Skripte und eine eigene Logik, so dass, falls gewünscht, nur eine bestimmte Anzahl von Tests gleichzeitig und parallel ausgeführt werden kann. Die Modularität ermöglicht es uns außerdem, Tests für Prepaid-Bewertungen von Tests für Postpaid-Bewertungen oder Tests für Zusatzkäufe von sonstigen Käufen zu trennen. Sie sehen den Testablauf in der Abbildung unten.
Abdeckung der Testszenarien
Das BRM TestToolkit kommuniziert mit unserer API, die wir zur Vereinfachung komplexerer Vorgänge in Oracle BRM integriert haben. Das TestToolkit kann auch mit der BRM RestBridge, unsere BRM-Wrapper-Lösung, die die Kommunikation mit BRM erleichtert, indem sie die Verwendung des JSON- oder XML-Formats über eine REST-API ermöglicht. Die Testschrittdefinitionen unterstützen unter anderem die folgenden Operationen:
- Erstellung und Verwaltung von Konten
- Kauf von Geschäften und andere Geschäftsvorgänge
- Abrufen und Prüfen der Waage
- Verkehr erzeugen - Nutzungsereignisse
- API-Aufrufe
- CDR-Abfall
- Echtzeit-Verkehrstools (Durchmesser-Protokoll)
- Überprüfung der Bewertung
- Das BRM TestToolkit vergleicht verschiedene Nutzungsereignisse und Käufe mit erwarteten Werten
- Jeder Plan oder jedes Produkt kann seinen eigenen Satz von Bewertungsdateien haben, was die Vielseitigkeit bei komplexen Produktkonfigurationen gewährleistet.
Durch die Zusammenstellung der benutzerfreundlichen Testschritte kann jeder Entwickler die Szenarien für die zu entwickelnde Funktion schreiben. In vielen Fällen entscheiden sich unsere Entwickler dafür, die Testszenarien im Voraus zu erstellen - vor der Entwicklung der Funktion. Die Vorbereitung der Szenarien im Voraus folgt dem Muster der verhaltensgesteuerten Entwicklung (Behaviour Driven Development, BDD). BDD bedeutet im Wesentlichen, dass die Szenarien den Entwicklungsablauf vorgeben und im Voraus existieren sollten. Diese Szenarien beschreiben, wie sich das System verhalten soll, und die Entwickler müssen neue Funktionen so entwickeln, dass sie zu diesen Szenarien passen. Wir können jedes Test-Szenario separat ausführen, was zu einem Bericht in einem bestimmten Format führt. Unten sehen Sie ein Beispiel für einen HTML-Bericht.
Berichterstattung
Wenn das System die Testszenarien als Teil eines neuen Entwicklungs-Builds ausführt, führt es diese normalerweise in vollem Umfang aus - einschließlich aller Tests. Dies kann von Umgebung zu Umgebung einige Zeit in Anspruch nehmen, liefert Ihnen aber ein umfassendes Bild davon, wie sich die neue Funktion auf andere bestehende Implementierungen ausgewirkt haben könnte. Wir können die Build-Stabilität anhand des Testberichts beurteilen, den das BRM TestToolkit am Ende eines Testlaufs erstellt. Testberichte enthalten Details für jedes Testszenario, bieten aber auch einige Statistiken und Analysen über alle Tests im Allgemeinen. Wir können diese Analyse verwenden, um Unterschiede zwischen Builds zu finden und um sicherzustellen, dass ein Build korrekt funktioniert. Sehen Sie unten ein Beispiel für einen Bericht.
Fazit
Mit der richtigen Testlösung können Sie eine Menge Zeit sparen und unnötige Fehler vermeiden. Wenn Sie also mit den in diesem Artikel erwähnten Schwierigkeiten zu kämpfen haben oder wenn Sie sich für unser Testing BRM Toolkit interessieren, können Sie uns gerne kontaktieren. Wir werden Ihnen gerne mehr über unsere Lösung erzählen und einen optimalen Plan ausarbeiten, wie Sie Ihren Einsatz- und Testablauf verbessern können.
