Tests

Einleitung

Im Transformationsschritt wird die Connectorlogik angewendet, um Daten in ein Format umzuwandeln, das für die Process Mining -App geeignet ist. Diese Transformationen basieren auf Annahmen über Daten. Daher ist es wichtig zu überprüfen, ob diese Annahmen zutreffen. Dazu müssen die folgenden Testtypen implementiert und mit jedem Connector bereitgestellt werden.

• Schuldentests
• Einheitentests

Schuldentests

Dbt bietet Funktionen, mit denen Sie Tests in die Transformationen aufnehmen können, um bestimmte Überprüfungen von Spalten in Ihren Daten durchzuführen. Sie können vorgefertigte Tests anwenden oder eigene Tests implementieren, wenn keine vorgefertigten Tests verfügbar sind. Ausführliche Informationen zu Tests mit dbt finden Sie in der offiziellen dbt-Dokumentation.

Jeder Test ist eine separate SQL-Abfrage. Für einen Test wird die folgende Logik verwendet: Ein Test ist erfolgreich, wenn 0 Datensätze zurückgegeben werden, und ein Test schlägt fehl, wenn mindestens 1 Datensatz zurückgegeben wird. table T hat beispielsweise column_A mit Werten der Länge 3 und 4. Es wird erwartet, dass alle Längen 3 sein sollten, für die der folgende Test geschrieben werden kann:

select column_A
from T
where len(column_A) <> 3

Diese Abfrage gibt alle Datensätze zurück, bei denen die Werte eine Länge von 4 haben, was dazu führt, dass der Test fehlschlägt. Wenn alle Datensätze den Wert 3 gehabt hätten, gibt diese Abfrage 0 Datensätze zurück.

Schweregrad

Nachfolgend finden Sie eine Beschreibung der verschiedenen Schweregrade für Tests.

Ebene	Beschreibung
Error	Falls die Daten falsch sind, können die Daten später nicht visualisiert/analysiert werden oder führen zu falschen Werten. Beispiel: unerwartete Duplizierung von Datensätzen.
Warning	Für den Fall, dass eine beträchtliche Wahrscheinlichkeit falscher Daten besteht, das überprüfte Verhalten jedoch keine strenge Anforderung ist. Werte in einer Spalte entsprechen beispielsweise nicht der erwarteten Anzahl von Zeichen.

Der Schweregrad eines Tests ist standardmäßig auf Error festgelegt.

Arten von Tests

Die folgenden Ebenen können unterschieden werden, auf denen Tests in dbt -Projekten angewendet werden sollten.

• Quelldatentests: Tests an den Rohdaten;
• Eingabetests :Testsder Eingabemodelle;
• Transformationstests: Tests für alle anderen Transformationen nach den Eingabemodellen

Quelldatentests

Quelldatentests sind in der Datei sources.yml definiert. Implementieren Sie Tests, um Folgendes für jede der Quelltabellen zu überprüfen:

• Alle Pflichtfelder haben keine NULL-Werte.

• Pflichtfelder, die eindeutige Werte haben sollten, haben eindeutige Werte.

  • Wenn eine Kombination von Pflichtfeldern eindeutige Werte haben soll, sollte die Kombination der Felder getestet werden (verwenden pm_utils.unique_combination_of_columns ).

Eingabetests

Eingabetests werden in input.yml definiert. Wir überprüfen Folgendes für jede der Eingabetabellen:

• Alle Pflichtfelder haben keine NULL-Werte.

• Pflichtfelder, die eindeutige Werte haben sollten, haben eindeutige Werte.

  • Wenn eine Kombination von Pflichtfeldern eindeutige Werte haben soll, sollte die Kombination der Felder getestet werden (verwenden pm_utils.unique_combination_of_columns ).

Transformationstests

Zwischen dem Laden der Roheingabe und dem Erstellen der endgültigen Tabellen für die Connector-Transformationen finden mehrere Transformationsschritte statt. Viele Dinge können schief gehen. Beispielsweise führt das fälschliche Verknüpfen von Tabellen zu unerwarteten Datensatzzahlen oder doppelten IDs. Daher müssen Tests angewendet werden, um die Richtigkeit dieser Zwischentransformationen zu überprüfen.

Transformationstests werden in den Dateien definiert, deren Name dem Namen des Transformationsschritts entspricht, nämlich entities.yml , events.yml , event_logs.yml und business_logic.yml .

Transformationsschritt	Tests
Entitäten	Entity ID ist eindeutig. Entity ID hat keine Null-Werte.
Events	Pflichtfelder (Entity ID, Activtiy und Event_end) enthalten keine Null-Werte. Die Kombination von Pflichtfeldern ist eindeutig. * Hinweis: Test mit Schweregrad = Warnung. Jede Instanz einer Entität hat nur ein einziges Erstellungsereignis. **
Ereignisprotokolle	Pflichtfelder (Entity ID, Activtiy und Event_end) enthalten keine Null-Werte. Die Kombination von Pflichtfeldern ist eindeutig. * Hinweis: Test mit Schweregrad = Warnung.
Geschäftslogik	Alle Pflichtfelder haben keine NULL-Werte. Pflichtfelder, die eindeutige Werte haben sollten, haben eindeutige Werte. Falls zutreffend, sollte die Datensatzanzahl die gleiche sein wie in einem vorherigen Transformationsschritt (pm_utils.equal_rowcount verwenden). ***

* In general, an event record with the same entity ID, activity, and event end is an indication of a duplication of records. However, there are situations where it is expected behavior. For example, the event end only consists of the date and not the exact time. An event can happen twice that day.

** Beispielsweise kann eine bestimmte Bestellung nur einmal im Ereignisprotokoll erstellt werden. Wenn das Erstellungsereignis zweimal vorhanden ist, würde dies auf eine Duplizierung von Ereignissen hinweisen.

*** Beispielsweise sollte die Anzahl der Datensätze in der Eingabetabelle mit der in der Entitätstabelle übereinstimmen. Datensätze wurden möglicherweise während der Transformationsschritte dupliziert oder fälschlicherweise entfernt. Weitere Informationen zum equal_rowcount -Test finden Sie unter pm-utils .

Zusätzlich zu diesen Tests können Sie weitere Tests hinzufügen, wenn dies einen Mehrwert für Tests auf bestimmtes Verhalten darstellt.

Pm-utils-Paket

UiPath hat das dbt-Paket pm_utils erstellt, das Dienstprogrammfunktionen für Process Mining-dbt-Projekte enthält. Das Paket enthält Funktionen, die in Ihren dbt-Tests verwendet werden können. Verwenden Sie beim Testen von „Nicht Null“ und der Eindeutigkeit von Feldern die pm-utils-Versionen dieser Tests anstelle der standardmäßigen.

Einheitentests

Es gibt Situationen, in denen komplizierte Transformationen angewendet werden, die durch Ausführen von dbt -Tests für einige Spalten nicht ordnungsgemäß getestet werden können. Zum Beispiel Transformationen, um die Währungsumrechnung auf Beträge anzuwenden. Es reicht nicht aus, zu überprüfen, ob die ausgegebenen Daten einen Betrag in der richtigen Währung enthalten. Für diese Art von Situationen werden Komponententests eingesetzt.

Ein Komponententest wird durch die folgenden Parameter definiert.

• Der Satz der auszuführenden Transformationen.
• Die Eingabedaten, für die diese Transformationen ausgeführt werden sollen.
• Die erwartete Ausgabe dieser Transformationen basierend auf den Eingabedaten.

Für jede dieser Testinstanzen ist es wichtig, dass die verschiedenen Situationen, die bei der Transformation berücksichtigt werden müssen, in den Eingabedaten vorhanden sind. Indem ein Satz vollständiger Situationen für die Eingabedaten vorhanden ist, kann das Verhalten der Transformationen überprüft werden.

Beispiel

Nachfolgend finden Sie ein Beispiel für eine einfache Transformation.

select 
  case
    when X >= 100
    then TRUE
    else FALSE
  end as "Is_this_a_big_number"
from T

In dieser Transformation besteht eine Abhängigkeit vom Wert von X. Daher ist es wichtig, alle Werte von X aufzulisten, die sicherstellen könnten, dass die Transformation anders ist. In diesem Beispiel benötigen Sie einen Wert, der kleiner als 100 ist, den Wert 100 selbst, einen Wert, der größer als 100 ist, und es empfiehlt sich, auch den Wert NULL und einen negativen Wert zu berücksichtigen. Die Werte 1 , 100 , 1000 , -1 und NULL reichen aus.

Schließlich müssen Sie die erwartete Ausgabe für jeden dieser Eingabewerte bereitstellen. In dieser Situation erwarten wir FALSE , TRUE , TRUE , FALSE , NULL als Ausgabe.

Wenn der Komponententest ausgeführt wird, wird die Transformation auf den angegebenen Eingabesatz angewendet und die Ausgabe wird mit dem Satz der gelieferten Ausgabe verglichen. Wenn das Ergebnis gleich ist, ist der Test erfolgreich. In allen anderen Situationen schlägt der Test fehl.

Erforderliche Komponententests

Wenn eine der folgenden Situationen innerhalb der Transformationen des Connectors auftritt, wird erwartet, dass ein Komponententest bereitgestellt wird:

• Transformationen enthalten Logik zum Anwenden der Währungsumrechnung.

Die folgenden Situationen gelten nur für TemplateOne -Connectors. Jede Situation bezieht sich auf eine bestimmte Transformation oder einen Satz von Transformationen, die vorhanden sein müssen:

• Die Transformation der Entitätsbeziehungen .
• Die Ereignisprotokollumwandlung .
• Die Tag- Transformationen.

• Die Transformationen für Fälligkeitsdaten .

Hinweis: Wenn Ihr spezifischer Connector mehr Transformationen enthält, bei denen ein Komponententest einen Mehrwert bietet, wird dringend empfohlen, diese Tests hinzuzufügen. Dies kann auch den Validierungsprozess für den Connector beschleunigen.