Menü

Datenvalidierungstests für ETL- und Datenmigrationsprojekte

  • Haupt
  • Andere
  • Datenvalidierungstests für ETL- und Datenmigrationsprojekte

data validation tests

Versuchen Sie Unser Instrument, Um Probleme Zu Beseitigen

Dieses Tutorial beschreibt ETL- und Datenmigrationsprojekte und behandelt Datenvalidierungsprüfungen oder -tests für ETL- / Datenmigrationsprojekte zur Verbesserung der Datenqualität:

Dieser Artikel richtet sich an Softwaretester, die an ETL- oder Datenmigrationsprojekten arbeiten und daran interessiert sind, ihre Tests nur auf die Aspekte der Datenqualität zu konzentrieren. Diese Arten von Projekten haben ein riesiges Datenvolumen, das im Quellspeicher gespeichert wird und dann von einer in der Software vorhandenen Logik bearbeitet und in den Zielspeicher verschoben wird.

Datenvalidierungstests stellen sicher, dass die in den endgültigen Zielsystemen vorhandenen Daten gemäß den Geschäftsanforderungen gültig, genau und für die Verwendung im Live-Produktionssystem geeignet sind.

Datenvalidierung für ETL- und Datenmigrationsprojekte

Die Anzahl der Datenqualitätsaspekte, die getestet werden können, ist riesig. Diese Liste enthält eine Einführung in dieses Thema.

Was du lernen wirst:

Was ist Datenvalidierung?

Datenvalidierung

In einfachen Worten bedeutet Datenvalidierung die Validierung der Tatsache, dass die Daten, die im Rahmen von ETL- oder Datenmigrationsjobs verschoben werden, in den Live-Systemen der Zielproduktion konsistent, genau und vollständig sind, um die Geschäftsanforderungen zu erfüllen.

Beispiel: Die Adresse eines Schülers in der Schülertabelle betrug im Quellsystem 2000 Zeichen. Die Datenvalidierung überprüft, ob genau der gleiche Wert im Zielsystem vorhanden ist. Es wird geprüft, ob die Daten abgeschnitten wurden oder ob bestimmte Sonderzeichen entfernt wurden.

In diesem Artikel werden viele dieser Datenvalidierungsprüfungen erläutert. Als Tester für ETL- oder Datenmigrationsprojekte bietet es einen enormen Mehrwert, wenn wir Probleme mit der Datenqualität aufdecken, die möglicherweise auf die Zielsysteme übertragen werden und die gesamten Geschäftsprozesse stören.

Warum Daten für ETL-Projekte validieren?

In ETL-Projekten werden Daten aus der Quelle extrahiert, durch Anwenden einer Logik in der Software bearbeitet, transformiert und dann in den Zielspeicher geladen. In vielen Fällen wird die Transformation durchgeführt, um die Quelldaten in ein für die Geschäftsanforderungen besser verwendbares Format zu ändern.

Hier ist eine Datenvalidierung erforderlich, um zu bestätigen, dass die in das Zielsystem geladenen Daten vollständig und genau sind und keine Datenverluste oder Diskrepanzen vorliegen.

Ziel- und Quellsystem

Beispiel: Eine E-Commerce-Anwendung verfügt über ETL-Jobs, bei denen alle OrdersIds für jede CustomerID aus der Orders-Tabelle ausgewählt werden, die den TotalDollarsSpend des Kunden zusammenfasst, und in eine neue CustomerValue-Tabelle geladen wird, wobei jede CustomerRating als Kunden mit hohem / mittlerem / niedrigem Wert markiert wird auf einen komplexen Algorithmus.

Durch einen einfachen Datenvalidierungstest wird festgestellt, dass die Kundenbewertung korrekt berechnet wurde.

Ein weiterer Test besteht darin, zu überprüfen, ob der TotalDollarSpend korrekt berechnet wurde, ohne dass Fehler beim Runden der Werte oder beim Überlaufen des Maximalwerts auftreten.

Warum Daten für Datenmigrationsprojekte validieren?

In Datenmigrationsprojekten werden die großen Datenmengen, die im Quellspeicher gespeichert sind, aus verschiedenen Gründen wie Infrastruktur-Upgrade, veraltete Technologie, Optimierung usw. auf einen anderen Zielspeicher migriert. Zum Beispiel, Unternehmen migrieren möglicherweise ihr riesiges Data-Warehouse von Legacy-Systemen auf neuere und robustere Lösungen in AWS oder Azure.

Das Hauptmotiv für solche Projekte besteht darin, Daten aus dem Quellsystem in ein Zielsystem zu verschieben, sodass die Daten im Ziel ohne Unterbrechung oder negative Auswirkungen auf das Geschäft in hohem Maße verwendet werden können.

Auch hier ist eine Datenvalidierung erforderlich, um zu bestätigen, dass die Daten auf der Quelle nach der Bewegung im Ziel identisch sind.

Beispiel: Angenommen, für die E-Commerce-Anwendung wurde die Tabelle 'Bestellungen' mit 200 Millionen Zeilen auf das Zielsystem in Azure migriert. Mit einem einfachen Datenvalidierungstest wird überprüft, ob alle 200 Millionen Datenzeilen im Zielsystem verfügbar sind.

Ein weiterer Test könnte darin bestehen, zu bestätigen, dass die Datumsformate zwischen dem Quell- und dem Zielsystem übereinstimmen.

Es gibt verschiedene Aspekte, die Tester in solchen Projekten testen können, wie Funktionstests, Leistungstests, Sicherheitstests, Infra-Tests, E2E-Tests, Regressionstests usw.

Empfohlene Lektüre => Testen der Datenmigration , Tutorial zum Testen von ETL-Data Warehouse-Tests

In diesem Artikel werden wir uns nur mit dem Datenaspekt von Tests für ETL- und Migrationsprojekte befassen.

Datenzuordnungsblatt

Erstellen Sie zunächst ein Datenzuordnungsblatt für Ihr Datenprojekt. Bei der Datenzuordnung werden Entitäten zwischen der Quell- und der Zieltabelle abgeglichen. Beginnen Sie mit der Dokumentation aller Tabellen und ihrer Entitäten im Quellsystem in einer Tabelle. Dokumentieren Sie nun die entsprechenden Werte für jede dieser Zeilen, von denen erwartet wird, dass sie in den Zieltabellen übereinstimmen. Notieren Sie die Transformationsregeln in einer separaten Spalte, falls vorhanden.

Datenzuordnungsblätter enthalten viele Informationen, die aus Datenmodellen ausgewählt wurden, die von Data Architects bereitgestellt wurden. Anfänglich konnten Tester eine vereinfachte Version erstellen und im weiteren Verlauf weitere Informationen hinzufügen. Siehe das folgende Beispiel für ein Datenzuordnungsblatt. übergeordnete Tabelle

Laden Sie eine Vorlage von herunter Vereinfachtes Datenzuordnungsblatt

Datenvalidierungstests

# 1) Dateneinheitlichkeit

Datengleichmäßigkeitstests werden durchgeführt, um zu überprüfen, ob der tatsächliche Wert der Entität an verschiedenen Stellen genau übereinstimmt. Hier sind zwei Arten von Tests möglich:

(i) Überprüfungen innerhalb desselben Schemas:

  • Die Datenentität kann in zwei Tabellen innerhalb desselben Schemas vorhanden sein (entweder Quellsystem oder Zielsystem).
  • Beispiel: Wie Sie im folgenden Bild sehen können, ist ProductID in der Tabelle OrderDetails and Products enthalten. Führen Sie eine genaue Übereinstimmungsüberprüfung für die in der Tabelle 'OrderDetails vs Products' vorhandene ProductId durch.

Vereinfachtes Datenzuordnungsblatt1

(ii) Überprüfungen über Schemata hinweg:

  • Die Datenentität kann unverändert in das Zielschema migriert werden, d. H. Sie ist sowohl im Quellsystem als auch im Zielsystem vorhanden
  • Beispiel: Wie Sie im obigen Bild sehen können, ist ProductID in der Tabelle Products im Quellsystem und in der Tabelle Products im Zielsystem vorhanden. Führen Sie eine genaue Übereinstimmungsüberprüfung für die Produkt-ID in der Produkttabelle im Quellsystem mit der Produkt-ID in der Produkttabelle im Zielsystem durch.

Hinweis: Es ist am besten, übereinstimmende Datenelemente im Farbzuordnungsblatt (Farbcode) hervorzuheben, um eine schnelle Referenz zu erhalten.

# 2) Entitätspräsenz

Bei dieser Art von Test müssen wir überprüfen, ob alle Entitäten (Tabellen und Felder) zwischen Quelle und Ziel übereinstimmen. Es gibt zwei Möglichkeiten: Eine Entität kann gemäß dem Datenmodelldesign vorhanden sein oder fehlen.

(ich) Überprüfen Sie, ob alle Tabellen (und Spalten) übereinstimmen, die sowohl in der Quelle als auch im Ziel entsprechend vorhanden sind. Wir ziehen eine Liste aller Tabellen (und Spalten) und führen einen Textvergleich durch. Dieser Vernunfttest funktioniert nur, wenn dieselben Entitätsnamen verwendet werden.

Manchmal werden unterschiedliche Tabellennamen verwendet und daher funktioniert ein direkter Vergleich möglicherweise nicht. Möglicherweise müssen wir diese Informationen im Datenzuordnungsblatt zuordnen und auf Fehler überprüfen.

Eine andere Möglichkeit ist das Fehlen von Daten. Es gibt Fälle, in denen das Datenmodell erfordert, dass eine Tabelle im Quellsystem (oder in der Spalte) keine entsprechende Präsenz im Zielsystem aufweist (oder umgekehrt). Lassen Sie Tests durchführen, um dies zu validieren.

  • Beispiel: Wie Sie im folgenden Bild sehen können, ist die CustDemographic-Tabelle im Zielsystem und nicht im Quellsystem vorhanden.
  • Das Feld CustomerType in der Tabelle Kunden enthält nur Daten im Quellsystem und nicht im Zielsystem.

Dart (Datengenauigkeit)

# 3) Datengenauigkeit

Wie der Name schon sagt, überprüfen wir, ob die Daten logisch korrekt sind. Für diese Art von Test gibt es zwei Kategorien. Auf diese Weise kann der Tester die Datenqualitätsprobleme auch im Quellsystem erfassen.

Datenintegrität

(Bild Quelle ))

Hinweis: Führen Sie diesen Test im Zielsystem aus und überprüfen Sie das Quellsystem erneut auf etwaige Fehler.

(i) Nicht numerischer Typ: Unter dieser Klassifizierung überprüfen wir die Richtigkeit des nicht numerischen Inhalts. Beispiele sind E-Mails, PIN-Codes, Telefon in einem gültigen Format.

(ii) Domänenanalyse: Bei dieser Art von Test wählen wir Datendomänen aus und überprüfen sie auf Fehler. Hierfür gibt es drei Gruppierungen:

  • Basierend auf dem Wert: Hier erstellen wir eine Liste von Werten, die für ein Feld auftreten können (Spalte in der Tabelle). Überprüfen Sie dann, ob die Spaltenwerte eine Teilmenge unserer Liste sind.
    • Beispiel: Überprüfen Sie, ob die Spalte Geschlecht entweder M oder F enthält.
  • Basierend auf Reichweite: Hier legen wir den minimalen und maximalen Bereich für gültige Datenwerte für eine Spalte fest, basierend auf logischen oder geschäftlichen Überlegungen. Wir überprüfen dann, ob die Spaltenwerte in diesen Bereich fallen.
    • Beispiel: 0 bis 120 für Alter.
  • Referenzdatei : Hier verwendet das System eine externe Gültigkeitsdatei.
    • Beispiel: Sind Ländercodes gültig, wählen sie den richtigen Wert aus der Referenzdatei aus, sind Ländercodes zwischen Qualitätssicherung und Produktionsumgebung gleich? Wenn in der Referenzdatei ein Ländercode aktualisiert wurde, wird dieser in der Datenbank zu Recht aktualisiert?

# 4) Metadatenvalidierung

Bei der Metadatenvalidierung überprüfen wir, ob die Datentypdefinitionen für Tabellen und Spalten für das Ziel korrekt entworfen wurden und nach dem Entwurf gemäß den Entwurfsspezifikationen des Datenmodells ausgeführt werden.

Hier gibt es zwei Gruppierungen:

wow kostenlos für privaten Server spielen

(i) Metadatenentwurf: Die erste Überprüfung besteht darin, zu überprüfen, ob das Datenmodell gemäß den Geschäftsanforderungen für die Zieltabellen korrekt entworfen wurde. Datenarchitekten können Schemaentitäten migrieren oder Änderungen vornehmen, wenn sie das Zielsystem entwerfen.

Die nächste Überprüfung sollte darin bestehen, zu überprüfen, ob die richtigen Skripte mithilfe der Datenmodelle erstellt wurden.

Für jede der folgenden Kategorien überprüfen wir zunächst, ob die für das Zielsystem definierten Metadaten den Geschäftsanforderungen entsprechen, und zweitens, ob die Tabellen und Felddefinitionen korrekt erstellt wurden.

Einige der Metadatenprüfungen sind nachstehend aufgeführt:

  • Datentypprüfung: Beispiel: Funktioniert Total Sales ordnungsgemäß mit dem Typ Dezimal (8, 16 oder 20 Byte) oder Double?
  • Datenlängenprüfung :: Beispiel: Wird die Datenlänge für das Feld Adresse mit 500 Zeichen ausreichen? Dies kann der Fall sein, wenn die Datenmigration durchgeführt wird, wenn dem Unternehmen neue geografische Daten hinzugefügt werden. Die Adressen der neuen Geografie haben möglicherweise ein außerordentlich langes Format, und das Festhalten an der ursprünglichen Länge kann einen Anwendungsfall fehlerhaft machen.
  • Indexprüfung: Beispiel: Wird für die Spalte OrderId im Zielsystem eine Indizierung durchgeführt? Was ist, wenn eine Fusion von Unternehmen stattgefunden hat, die eine Datenmigration erfordert und die Tabelle 'Bestellungen' im Zielsystem um das 100-fache vergrößert wird?
  • Metadatenprüfung in verschiedenen Umgebungen: Stellen Sie bei dieser Überprüfung sicher, dass die Metadaten zwischen dem QS-Test und der Produktionsumgebung übereinstimmen. Tests werden möglicherweise in der QS-Umgebung bestanden, schlagen jedoch in anderen Umgebungen fehl.

(ii) Deltawechsel: Diese Tests decken Fehler auf, die auftreten, wenn das Projekt läuft, und auf halbem Weg gibt es Änderungen an den Metadaten des Quellsystems, die nicht in Zielsystemen implementiert wurden.

Beispiel: Das neue Feld CSI (Customer Satisfaction Index) wurde der Kundentabelle in der Quelle hinzugefügt, konnte jedoch nicht an das Zielsystem gesendet werden.

# 5) Datenintegrität

Hier validieren wir hauptsächlich die Integritätsbeschränkungen wie Fremdschlüssel, Primärschlüsselreferenz, Eindeutig, Standard usw.

übergeordnete Tabelle

(Bild Quelle ))

Bei Fremdschlüsseln müssen wir prüfen, ob die untergeordnete Tabelle verwaiste Datensätze enthält, in denen der verwendete Fremdschlüssel nicht in der übergeordneten Tabelle vorhanden ist.

Datenvollständigkeitsprüfung

Beispiel: Die Kundentabelle hat die Kunden-ID, die ein Primärschlüssel ist. Die Auftragstabelle hat die Kunden-ID als Fremdschlüssel. Die Auftragstabelle enthält möglicherweise eine Kunden-ID, die nicht in der Kundentabelle enthalten ist. Wir benötigen Tests, um solche Verstöße gegen Integritätsbeschränkungen aufzudecken. Die Datenzuordnungstabelle gibt Ihnen Klarheit darüber, welche Tabellen diese Einschränkungen aufweisen.

Hinweis: Führen Sie diesen Test im Zielsystem aus und überprüfen Sie ihn im Quellsystem erneut, wenn Fehler vorliegen.

# 6) Vollständigkeit der Daten

Hierbei handelt es sich um Vernunftstests, bei denen fehlende Datensatz- oder Zeilenzahlen zwischen Quell- und Zieltabelle aufgedeckt werden und die nach der Automatisierung häufig ausgeführt werden können.

Es gibt zwei Arten von Tests:

(i) Datensatzanzahl: Hier vergleichen wir die Gesamtzahl der Datensätze für übereinstimmende Tabellen zwischen Quell- und Zielsystem. Dies ist eine schnelle Überprüfung der Integrität, um zu überprüfen, ob der ETL- oder Migrationsjob nach dem Ausführen ausgeführt wird. Wir haben einen Defekt, wenn die Zählungen nicht übereinstimmen.

Manchmal werden während des Joblaufs Datensätze abgelehnt. Einige davon sind möglicherweise gültig. Aber als Tester machen wir einen Fall dafür.

(ii) Profilerstellung für Spaltendaten: Diese Art von Vernunfttest ist wertvoll, wenn die Anzahl der Rekorde sehr hoch ist. Hier erstellen wir logische Datensätze, die die Anzahl der Datensätze reduzieren, und führen dann einen Vergleich zwischen Quelle und Ziel durch.

  • Filtern Sie nach Möglichkeit alle eindeutigen Werte in einer Spalte. zum Beispiel, ProductID kann in der OrderDetails-Tabelle mehrmals vorkommen. Wählen Sie eine eindeutige Liste für ProductID aus den Ziel- und Quelltabellen aus und validieren Sie sie. Dies reduziert die Anzahl der Datensatzzählungen erheblich und beschleunigt die Überprüfung der Gesundheit.
  • Wie bei den obigen Tests können wir auch alle wichtigen Spalten auswählen und prüfen, ob die KPIs (minimale, maximale, durchschnittliche, maximale oder minimale Länge usw.) zwischen Ziel- und Quellentabelle übereinstimmen. Beispiel: Nehmen Sie Durchschnitts-, Minimal- und Maximalwerte aus der Spalte Preis in OrderDetails und vergleichen Sie diese Werte zwischen Ziel- und Quellentabellen auf Nichtübereinstimmungen.
  • Eine weitere Überprüfung kann für Nullwerte durchgeführt werden. Wählen Sie wichtige Spalten aus und filtern Sie eine Liste von Zeilen heraus, in denen die Spalte Nullwerte enthält. Vergleichen Sie diese Zeilen zwischen dem Ziel- und dem Quellsystem auf Nichtübereinstimmung.

Zeitleisten

# 7) Datentransformation

Diese Tests bilden die Kerntests des Projekts. Überprüfen Sie das Anforderungsdokument, um die Transformationsanforderungen zu verstehen. Bereiten Sie Testdaten in den Quellsystemen vor, um verschiedene Transformationsszenarien widerzuspiegeln. Diese haben eine Vielzahl von Tests und sollten unter ETL-Testthemen ausführlich behandelt werden.

Nachfolgend finden Sie eine kurze Liste der hier behandelten Tests:

(i) Transformation:

  • Beispiel: ETL-Code verfügt möglicherweise über eine Logik zum Zurückweisen ungültiger Daten. Überprüfen Sie diese anhand der Anforderungen.
  • ETL-Code kann auch Logik enthalten, um bestimmte Schlüssel wie Ersatzschlüssel automatisch zu generieren. Wir benötigen Tests, um die Richtigkeit (technisch und logisch) dieser zu überprüfen.
  • Überprüfen Sie die Richtigkeit des Zusammenfügens oder Teilens von Feldwerten, nachdem ein ETL- oder Migrationsjob ausgeführt wurde.
  • Führen Sie Tests durch, um die Überprüfung der referenziellen Integrität zu überprüfen. Zum Beispiel, Eine Art von Fehler könnte darin bestehen, dass die in der Tabelle 'Bestellungen' verwendete Produkt-ID in der übergeordneten Tabelle 'Produkte' nicht vorhanden ist. Führen Sie einen Test durch, um zu überprüfen, wie sich die verwaisten Datensätze während eines ETL-Jobs verhalten.
  • Manchmal werden fehlende Daten mit dem ETL-Code eingefügt. Überprüfen Sie die Richtigkeit dieser.
  • ETL- oder Migrationsskripte haben manchmal Logik, um Daten zu korrigieren. Überprüfen Sie, ob die Datenkorrektur funktioniert.
  • Überprüfen Sie, ob den Benutzern ungültige / abgelehnte / fehlerhafte Daten gemeldet werden.
  • Erstellen Sie eine Tabelle mit Szenarien mit Eingabedaten und erwarteten Ergebnissen und validieren Sie diese mit dem Geschäftskunden.

(ii) Randfälle: Stellen Sie sicher, dass die Transformationslogik an den Grenzen gültig ist.

  • Beispiel: Was passiert, wenn TotalSales mit einem Wert von 1 Billion einen ETL-Job durchläuft? Funktionieren die End-to-End-Fälle? Identifizieren Sie Felder, die möglicherweise große Werte haben können, und führen Sie Tests mit diesen großen Werten durch. Sie sollten numerische und nicht numerische Werte enthalten.
  • Für Datumsfelder, einschließlich des gesamten erwarteten Datumsbereichs - Schaltjahre, 28/29 Tage für Februar. 30, 31 Tage für andere Monate.

# 8) Eindeutigkeit oder Vervielfältigung von Daten

Identifizieren Sie bei dieser Art von Test Spalten, die gemäß dem Datenmodell eindeutige Werte haben sollten. Berücksichtigen Sie auch die Geschäftslogik, um solche Daten auszusortieren. Führen Sie Tests durch, um zu überprüfen, ob sie im System eindeutig sind. Führen Sie als Nächstes Tests aus, um die tatsächlichen Duplikate zu identifizieren.

  • Beispiel: Filtern Sie nach doppelten Daten und überprüfen Sie, ob diese authentisch sind. Zum Beispiel, Der mitarbeiterabhängige Datensatz enthält zweimal dieselben Geschwisterdaten.
  • Die Telefonnummer des Benutzers sollte im System eindeutig sein (Geschäftsanforderung).
  • Die Geschäftsanforderung besagt, dass eine Kombination aus ProductID und ProductName in der Produkttabelle eindeutig sein sollte, da ProductName dupliziert werden kann.

# 9) Obligatorisch

Identifizieren Sie bei dieser Art von Test alle Felder, die als obligatorisch markiert sind, und überprüfen Sie, ob Pflichtfelder Werte haben. Wenn einem Feld in der Datenbank Standardwerte zugeordnet sind, überprüfen Sie, ob es korrekt ausgefüllt ist, wenn keine Daten vorhanden sind.

  • Beispiel: Wenn BillDate nicht eingegeben wird, ist CurrentDate das BillDate.

# 10) Aktualität

Dokumentieren Sie immer Tests, die bestätigen, dass Sie mit Daten aus den vereinbarten Zeitplänen arbeiten.

  • Beispiel: ProductDiscount wurde vor 15 Tagen aktualisiert und der Status der Geschäftsdomäne ändert sich alle sieben Tage. Dies bedeutet, dass Ihre Tests nicht mit den richtigen Rabattwerten durchgeführt werden.
  • Ein Predictive Analytics-Bericht für den Kundenzufriedenheitsindex sollte mit den Daten der letzten 1 Woche arbeiten, was eine Verkaufsförderungswoche bei Walmart war. Der ETL-Job wurde jedoch für eine Häufigkeit von 15 Tagen ausgelegt. Dies ist ein schwerwiegender Fehler, den Tester aufdecken können.

# 11) Nulldaten

Bei dieser Art von Test konzentrieren wir uns auf die Gültigkeit von Nulldaten und die Überprüfung, dass die wichtige Spalte nicht null sein kann.

  • Beispiel: Filtern Sie alle Nulldaten heraus und überprüfen Sie, ob Null zulässig ist.
  • Wenn wichtige Spalten für Geschäftsentscheidungen vorhanden sind, stellen Sie sicher, dass keine Nullen vorhanden sind.

# 12) Bereichsprüfung

Eine Dateneinheit, in der Bereiche geschäftlich sinnvoll sind, sollte getestet werden.

  • Beispiel: Die Bestellmenge pro Rechnung darf in der Softwarekategorie nicht mehr als 5.000 betragen.
  • Das Alter sollte nicht mehr als 120 Jahre betragen.

# 13) Geschäftsregeln

Dokumentieren Sie alle Geschäftsanforderungen für Felder und führen Sie Tests für diese durch.

  • Beispiel: Ressourcen mit einem Alter von weniger als 20 Jahren sind nicht förderfähig. Datenvalidierungsprüfungen sind erforderlich, wenn diese Regel auf die Daten angewendet wird.
  • Das Kündigungsdatum sollte null sein, wenn der Status 'Mitarbeiter aktiv' 'Wahr / Verstorben' lautet.
  • FROM-Daten sollten kleiner als TO Date sein.
  • Werden Kaufbeträge auf Artikelebene zu Beträgen auf Bestellungsebene summiert?

# 14) Aggregatfunktionen

Aggregatfunktionen sind in die Funktionalität der Datenbank integriert. Dokumentieren Sie alle Aggregate im Quellsystem und überprüfen Sie, ob die Aggregatverwendung im Zielsystem dieselben Werte ergibt (Summe, Max, Min, Anzahl).

Sehr oft unterscheiden sich die Tools auf dem Quellsystem vom Zielsystem. Überprüfen Sie, ob beide Tools Aggregatfunktionen auf dieselbe Weise ausführen.

# 15) Datenkürzung und Rundung

Bei diesen Arten von Tests identifizieren wir Felder mit Kürzungs- und Rundungslogik, die das Geschäft betreffen. Anschließend dokumentieren und unterzeichnen wir die Kürzungs- und Rundungslogik mit den Produktbesitzern und testen sie mit produktionsrepräsentativen Daten.

# 16) Codierungstests

Überprüfen Sie, ob das Quellsystem codierte Werte enthält, und überprüfen Sie, ob die Daten nach dem ETL- oder Datenmigrationsjob in das Zielsystem ordnungsgemäß ausgefüllt sind.

  • Beispiel: Doppelbyte-Zeichen für Vorname auf Chinesisch wurden in dem codierten Quellsystem akzeptiert. Überprüfen Sie das Verhalten dieses Felds beim Verschieben auf das Zielsystem.
  • Das Feld Passwort wurde verschlüsselt und migriert. Stellen Sie sicher, dass sie nach der Migration einwandfrei funktionieren.

# 17) Regressionstests

Dies ist ein grundlegendes Testkonzept, bei dem Tester ihre gesamte kritische Testfallsuite ausführen, die mithilfe der obigen Checkliste generiert wurde, nachdem eine Änderung am Quell- oder Zielsystem vorgenommen wurde.

Fazit

Wir haben also gesehen, dass die Datenvalidierung ein interessanter Bereich für datenintensive Projekte ist und die wichtigsten Tests bildet. Das Datenzuordnungsblatt ist ein kritisches Artefakt, das Tester pflegen müssen, um mit diesen Tests erfolgreich zu sein. Sie können mehrere Versionen mit farbigen Hervorhebungen verwalten, um Eingaben für einen der oben genannten Tests zu bilden.

Es sollte darauf geachtet werden, dass die Deltaänderungen über die Versionen hinweg beibehalten werden.

Wir bitten die Leser, andere Bereiche des Tests zu teilen, auf die sie während ihrer Arbeit gestoßen sind, um der Testergemeinschaft zu helfen.

Literatur-Empfehlungen

^