OMrun (Basis)

Framework

OMrun ist ein Framework zur In-Memory-Überprüfung von Daten aus beliebig heterogenen Datenquellen mittels SQL. Die Datenvergleiche werden regelbasiert und automatisiert ausgeführt und allfällige Differenzen auf Feld-Ebene ausgewiesen. Toleranzen und Wertbereiche (Ranges) können einfach erfasst und zugelassen werden. So ist es möglich, neben "harten/scharfen" auch "weiche/unscharfe" Überprüfungen vorzunehmen.

Der Vergleichsprozess findet direkt im Arbeitsspeicher statt, um die Ausführung so performant wie möglich zu gestalten. Wer OMrun effizient nutzen möchte, muss vor allem über SQL-Kenntnisse verfügen, womit sämtliche Tests in OMrun automatisiert werden können.

OMrun Screen Design Test Object Abb. 1: Screen Design Test Object

Testergebnisse welche gegen die definierten Regeln verstossen, werden rot eingefärbt und statistisch erfasst. Die integrierte Fehleranalyse in OMrun hilft die für die Fehlersuche benötigte Zeit drastisch zu reduzieren. Die Ergebnisse können sowohl in OMrun selber, als auch in dem mitgelieferten OMdashboard ausgewertet werden.
Natürlich können alle Resultate auch in MS Excel exportiert und weiterverwendet werden.

Prozess-Engine

OMrun Screen Execute Test Scenario Abb. 2: Screen Execute Test Scenario

OMrun verfügt über eine integrierte Prozess-Engine: Verschiedene Prüfschritte werden zu Szenarien zusammengefasst und manuell oder via Scheduler ausgeführt. OMrun kann als "Master" andere Werkzeuge und Programme aufrufen oder als "Slave" selber aufgerufen werden. Anbindungen an UC4 von Automic, an die Tosca Testsuite, an das HP Application Lifecycle Management (ALM) oder an das HP Quality Center Enterprise (QC) sind problemlos möglich. Sämtliche von OMrun verwaltete Testfälle können in verschiedenen Szenarien wiederverwendet werden. Auf diese Weise können hoch komplexe Verarbeitungen und Prüfschritte automatisiert durchgeführt werden - wir nennen diese Verarbeitung "Scenario of Scenario".

Im Gegensatz zu vielen anderen Werkzeugen fokussiert OMrun auf die Daten als hauptsächliche Prüfobjekte, weil wir der Meinung sind, dass Datenstrukturen in der Regel sehr stabil sind (kleiner Wartungsaufwand) und dass sich grundsätzlich alle Änderungen an einer Software auf die Daten auswirken und deshalb dort feststellbar sind. Das manuelle Erstellen von Testdaten entfällt in vielen Fällen.

Daten-Adaptoren

"You name it - we connect it!"
OMrun klinkt sich mittels verschiedenster vorkonfigurierter Adaptoren in viele bestehende Datenbanksysteme und Dateitypen ein. Weitere Adaptoren können auf Anfrage realisiert werden. Integriert wurden bereits folgende Typen:

Datenbanktypen Dateitypen
Btrieve/Pervasive CSV
IBM (AS400, DB2) Hostfile (positionsorientiert)
Microsoft Access Microsoft Excel
Microsoft SQL Server PDF
MySQL TXT
Oracle XML
Avaloq
SAP/ASE (MDX)
BI / DW / MIS (MDX)
Übersicht Daten-Adaptoren Abb. 3: Übersicht Daten-Adaptoren
OMrun: Screen Environment, Dropdown 'DataType' Abb. 4: Dropdown 'DataType'

Regeln

Anwendungsbeispiel einer Regel Abb. 5: Anwendungsbeispiel einer Regel

Die definierten Regeln und Toleranzen werden aus der IT- oder Businessspezifikation in OMrun abgebildet und gespeichert. Diese werden während des Vergleichs auf die Quellendaten des Systems A angewendet, worauf der erwartete (Soll-)Wert für den Datenabgleich vorausberechnet wird.

Der Vergleich der vorausberechneten Werte mit den zu überprüfenden Werten des Zielsystems (System B) ist dann nur noch ein 1:1-Vergleich. Dieser Lösungsansatz ermöglicht es OMrun, auch sehr grosse Datenmengen extrem performant zu überprüfen. So kann der Zeitaufwand für Integrations- und Regressionstests mit Hilfe der Testautomatisierung mittels OMrun signifikant minimiert werden.

Lösungsansatz

Der Lösungsansatz der regelbasierten Überprüfung hat noch einen weiteren Vorteil: auf diese Weise entdeckt OMrun unter anderem auch den sogenannten "Überhang". OMrun kann ausweisen, wenn im Zielsystem Daten vorhanden sind, die im Quellsystem nicht (mehr) vorkommen ("Datenleichen"). Dies gelingt uns deshalb, weil OMrun alles als "falsch" ausgibt, was nicht durch die definierten Regeln beschrieben ist.

Wenn also ein Wert im Zielsystem vorhanden ist, der nicht erwartet wurde, dann muss entweder eine Regel angepasst oder zusätzlich erfasst werden, um diesen Wert zu "legitimieren" - oder aber es liegt ein tatsächlicher Fehler vor. Mit diesem iterativen Vorgehen wird mit marginalem Zeitaufwand während des Testens eine Art Re-Engineering vorgenommen, was insbesondere bei Systemen mit unvollständiger Dokumentation oft vorkommen kann und einen zusätzlichen Mehrwert bietet. Wir nennen das auch "evolutionäres Testing".

OMrun Erklärfilm für den Anwendungsfall "System-Umstellung"

Alternatives Film-Format: OMrun Erklärfilm im MP4-Format