- Arbeiten mit Dashboards und Diagrammen
- Arbeiten mit Prozessdiagrammen
- Anzeigen oder Ausblenden des Menüs
- Kontextinformationen
- Ursachenanalyse
- Senden von Automatisierungsideen zum UiPath Automation Hub
- Filter
- Simulation des Automatisierungspotenzials
- Tags
- Fälligkeitsdaten
- Vergleichen
- Exportieren
- Auslösen einer Automatisierung über eine Prozess-App
- Starten eines Task Mining-Projekts über Process Mining
- Hochladen von Daten
- Abrufen der Anmeldeinformationen für Azure Blob Storage
- Laden von Daten mit DataUploader
- Systemanforderungen
- Konfigurieren des DataBridgeAgent
- Hinzufügen eines benutzerdefinierten Connectors zu DataBridgeAgent
- Verwenden von DataBridgeAgent mit dem SAP Connector für den Purchase-to-Pay Discovery Accelerator
- Verwenden von DataBridgeAgent mit dem SAP Connector für den Order-to-Cash Discovery Accelerator
- Optimieren einer App
- Planen von Datenausführungen
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
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
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 |
---|---|
|
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. |
|
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
).
- Wenn eine Kombination von Pflichtfeldern eindeutige Werte haben soll, sollte die Kombination der Felder getestet werden (verwenden
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
).
- Wenn eine Kombination von Pflichtfeldern eindeutige Werte haben soll, sollte die Kombination der Felder getestet werden (verwenden
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 |
|
Events |
Hinweis: Test mit Schweregrad = Warnung.
|
Ereignisprotokolle |
Hinweis: Test mit Schweregrad = Warnung.
|
Geschäftslogik |
|
* 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
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 .