Menu

Tests de validation des données pour les projets ETL et de migration de données

  • Principal
  • Autre
  • Tests de validation des données pour les projets ETL et de migration de données

data validation tests

Essayez Notre Instrument Pour Éliminer Les Problèmes

Ce didacticiel décrit les projets ETL et de migration de données et couvre les contrôles de validation des données ou les tests pour les projets ETL / migration de données pour une meilleure qualité des données:

Cet article s'adresse aux testeurs de logiciels qui travaillent sur des projets ETL ou de migration de données et qui souhaitent concentrer leurs tests uniquement sur les aspects de la qualité des données. Ces types de projets ont un énorme volume de données qui sont stockées sur le stockage source, puis sont exploitées par une logique présente dans le logiciel et sont déplacées vers le stockage cible.

Les tests de validation des données garantissent que les données présentes dans les systèmes cibles finaux sont valides, exactes, conformément aux exigences de l'entreprise et utilisables dans le système de production en direct.

Validation des données pour les projets ETL et de migration de données

Le nombre d'aspects de la qualité des données qui peuvent être testés est énorme et cette liste ci-dessous donne une introduction à ce sujet.

Ce que vous apprendrez:

Qu'est-ce que la validation des données?

La validation des données

En termes simples, la validation des données consiste à valider le fait que les données déplacées dans le cadre des tâches ETL ou de migration de données sont cohérentes, précises et complètes dans les systèmes de production en direct cibles pour répondre aux besoins de l'entreprise.

Exemple: L'adresse d'un étudiant dans la table Student était de 2000 caractères dans le système source. La validation des données vérifie si exactement la même valeur réside dans le système cible. Il vérifie si les données ont été tronquées ou si certains caractères spéciaux sont supprimés.

Dans cet article, nous aborderons plusieurs de ces contrôles de validation des données. En tant que testeurs pour des projets ETL ou de migration de données, cela ajoute une valeur considérable si nous découvrons des problèmes de qualité des données susceptibles de se propager aux systèmes cibles et de perturber l'ensemble des processus métier.

Pourquoi valider les données pour les projets ETL?

Dans les projets ETL, les données sont extraites de la source, traitées en appliquant une logique dans le logiciel, transformées, puis chargées dans le stockage cible. Dans de nombreux cas, la transformation est effectuée pour changer les données source dans un format plus utilisable pour les besoins de l'entreprise.

Ici, la validation des données est requise pour confirmer que les données chargées dans le système cible sont complètes, exactes et qu'il n'y a pas de perte ou de divergence de données.

système cible et source

Exemple: Une application de commerce électronique a des tâches ETL sélectionnant tous les OrdersIds par rapport à chaque CustomerID de la table Orders qui résume le TotalDollarsSpend par le client, et le charge dans une nouvelle table CustomerValue, marquant chaque CustomerRating en tant que clients de valeur élevée / moyenne / faible sur un algorithme complexe.

Un simple test de validation des données consiste à vérifier que le CustomerRating est correctement calculé.

Un autre test consiste à vérifier que le TotalDollarSpend est correctement calculé sans aucun défaut d'arrondi des valeurs ou de dépassement de valeur maximale.

Pourquoi valider les données pour les projets de migration de données?

Dans les projets de migration de données, les énormes volumes de données stockés dans le stockage source sont migrés vers différents stockage cible pour plusieurs raisons telles que la mise à niveau de l'infrastructure, la technologie obsolète, l'optimisation, etc. Par exemple, les entreprises peuvent migrer leur immense entrepôt de données des systèmes hérités vers des solutions plus récentes et plus robustes sur AWS ou Azure.

Le motif principal de tels projets est de déplacer les données du système source vers un système cible de telle sorte que les données de la cible soient hautement utilisables sans aucune interruption ou impact négatif pour l'entreprise.

Là encore, la validation des données est nécessaire pour confirmer que les données sur la source sont les mêmes dans la cible après le mouvement.

Exemple: Supposons que pour l'application de commerce électronique, la table Orders qui contenait 200 millions de lignes a été migrée vers le système cible sur Azure. Un simple test de validation des données consiste à vérifier que les 200 millions de lignes de données sont disponibles dans le système cible.

Un autre test pourrait être de confirmer que les formats de date correspondent entre le système source et cible.

Les testeurs peuvent tester divers aspects dans de tels projets tels que les tests fonctionnels, les tests de performance, les tests de sécurité, les tests infra, les tests E2E, les tests de régression, etc.

Lecture recommandée => Test de migration de données , Didacticiel de test de l'entrepôt de données de test ETL

Dans cet article, nous examinerons uniquement l'aspect des données des tests pour les projets ETL & Migration.

Feuille de correspondance des données

Pour commencer, créez une feuille de mappage de données pour votre projet de données. Le mappage de données est le processus de mise en correspondance des entités entre les tables source et cible. Commencez par documenter toutes les tables et leurs entités dans le système source dans une feuille de calcul. Maintenant, documentez les valeurs correspondantes pour chacune de ces lignes qui devraient correspondre dans les tables cible. Notez les règles de transformation dans une colonne distincte, le cas échéant.

Les feuilles de mappage de données contiennent de nombreuses informations issues de modèles de données fournis par Data Architects. Au départ, les testeurs pouvaient créer une version simplifiée et ajouter plus d'informations au fur et à mesure. Voir l'exemple de feuille de mappage de données ci-dessous- table parent

Télécharger un modèle depuis Feuille de correspondance des données simplifiée

Tests de validation des données

# 1) Uniformité des données

Des tests d'uniformité des données sont effectués pour vérifier que la valeur réelle de l'entité correspond exactement à différents endroits. Nous avons deux types de tests possibles ici:

(i) Contrôles dans le même schéma:

  • L'entité de données peut exister dans deux tables au sein du même schéma (système source ou système cible)
  • Exemple: Comme vous pouvez le voir dans l'image ci-dessous, ProductID est présent dans le tableau OrderDetails and Products. Effectuez une vérification de correspondance exacte pour ProductId présent dans le tableau OrderDetails vs Products.

Feuille de correspondance des données simplifiée1

(ii) Vérifications à travers les schémas:

  • L'entité de données peut être migrée telle quelle dans le schéma cible, c'est-à-dire qu'elle est présente dans le système source ainsi que dans le système cible
  • Exemple: Comme vous pouvez le voir dans l'image ci-dessus, ProductID est présent dans la table Products dans le système source et dans la table Products dans le système cible. Effectuez une vérification de correspondance exacte pour ProductId dans la table Products du système source avec ProductId dans la table Products dans le système cible.

Noter: Il est préférable de mettre en évidence (code couleur) les entités de données correspondantes dans la feuille de mappage de données pour une référence rapide.

# 2) Présence d'entité

Dans ce type de test, nous devons valider que toutes les entités (tables et champs) correspondent entre la source et la cible. Il y a deux possibilités, une entité peut être présente ou absente selon la conception du modèle de données.

(je) Vérifiez que toutes les tables (et colonnes), qui ont une présence correspondante à la fois dans la source et dans la cible, correspondent. Nous tirons une liste de toutes les tables (et colonnes) et faisons une comparaison de texte. Ce test de cohérence fonctionne uniquement si les mêmes noms d'entité sont utilisés partout.

Parfois, différents noms de table sont utilisés et, par conséquent, une comparaison directe peut ne pas fonctionner. Nous devrons peut-être mapper ces informations dans la feuille de mappage de données et la valider pour les échecs.

Une autre possibilité est l'absence de données. Il y a des cas où le modèle de données exige qu'une table du système source (ou de la colonne) n'ait pas une présence correspondante dans le système cible (ou vice versa). Faites des tests pour valider cela.

  • Exemple: Comme vous pouvez le voir dans l'image ci-dessous, CustDemographic Table est présent dans le système cible et non dans le système source.
  • Le champ CustomerType de la table Clients contient des données uniquement dans le système source et non dans le système cible.

fléchette (précision des données)

# 3) Précision des données

Comme son nom l'indique, nous validons si les données sont logiquement exactes. Il existe deux catégories pour ce type de test. Avec cela, le testeur peut détecter les problèmes de qualité des données, même dans le système source.

Intégrité des données

(image la source )

Noter: Exécutez ce test dans le système cible et revérifiez dans le système source tout défaut.

(i) Type non numérique: Dans le cadre de cette classification, nous vérifions l'exactitude du contenu non numérique. Exemples sont des e-mails, des codes PIN, un téléphone dans un format valide.

(ii) Analyse de domaine: Dans ce type de test, nous sélectionnons des domaines de données et validons les erreurs. Il existe trois groupes pour cela:

  • Basé sur la valeur: Ici, nous créons une liste de valeurs pouvant apparaître pour un champ (colonne dans le tableau). Validez ensuite si les valeurs de colonne sont un sous-ensemble de notre liste.
    • Exemple: Vérifiez si la colonne Sexe contient M ou F.
  • Basé sur la gamme: Ici, nous définissons des plages minimale et maximale pour les valeurs de données valides pour une colonne, en fonction d'un raisonnement logique ou commercial. Nous validons ensuite si les valeurs des colonnes se situent dans cette plage.
    • Exemple: 0 à 120 pour l'âge.
  • Fichier de référence : Ici, le système utilise un fichier de validité externe.
    • Exemple: Les codes de pays sont-ils valides, choisissent-ils la bonne valeur dans le fichier de référence, les codes de pays sont-ils identiques entre le contrôle qualité et l'environnement de production? Si le fichier de référence avait un code de pays mis à jour, est-il correctement mis à jour dans DB?

# 4) Validation des métadonnées

Dans la validation des métadonnées, nous validons que les définitions de type de données Table et Colonne pour la cible sont correctement conçues et qu'une fois conçues, elles sont exécutées conformément aux spécifications de conception du modèle de données.

Il y a deux groupes ici:

différence entre les tests du système et les tests d'acceptation des utilisateurs

(i) Conception des métadonnées: La première vérification consiste à valider que le modèle de données est correctement conçu conformément aux exigences métier des tables cibles. Les architectes de données peuvent migrer des entités de schéma ou apporter des modifications lorsqu'ils conçoivent le système cible.

La prochaine vérification devrait être de valider que les bons scripts ont été créés à l'aide des modèles de données.

Pour chaque catégorie ci-dessous, nous vérifions d'abord si les métadonnées définies pour le système cible répondent aux exigences métier et, dans un second temps, si les tables et les définitions de champs ont été créées avec précision.

Quelques-uns des contrôles de métadonnées sont donnés ci-dessous:

  • Vérification du type de données: Exemple: Total Sales fonctionnera-t-il correctement avec le type Décimal (8, 16 ou 20 octets) ou Double?
  • Vérification de la longueur des données : Exemple: La longueur des données pour le champ Adresse sera-t-elle suffisante avec 500 caractères? Il peut s'agir d'un cas où la migration des données est effectuée au fur et à mesure que la nouvelle géographie est ajoutée à l'entreprise. Les adresses de la nouvelle géographie peuvent avoir un format extrêmement long et s'en tenir à la longueur d'origine peut entraîner une erreur dans un cas d'utilisation.
  • Vérification d'index: Exemple: Une indexation est-elle effectuée pour la colonne OrderId dans le système cible? Que se passe-t-il si une fusion d'entreprises a eu lieu, nécessitant une migration de données et que la table des commandes augmente 100 fois en taille dans le système cible?
  • Vérification des métadonnées dans tous les environnements: Sous cette vérification, vérifiez que les métadonnées correspondent entre le test QA et l'environnement de production. Les tests peuvent réussir dans l'environnement de contrôle qualité mais échouer dans d'autres environnements.

(ii) Changement de delta: Ces tests découvrent les défauts qui surviennent lorsque le projet est en cours et à mi-chemin, des modifications sont apportées aux métadonnées du système source et n’ont pas été implémentées dans les systèmes cibles.

Exemple: Le nouveau champ CSI (Customer Satisfaction Index) a été ajouté à la table Customer dans la source mais n'a pas pu être transmis au système cible.

# 5) Intégrité des données

Ici, nous validons principalement les contraintes d'intégrité comme la clé étrangère, la référence de clé primaire, unique, par défaut, etc.

table parent

(image la source )

Pour les clés étrangères, nous devons vérifier s'il existe des enregistrements orphelins dans la table enfant où la clé étrangère utilisée n'est pas présente dans la table parent.

Vérification de l

Exemple: La table Clients a CustomerID qui est une clé primaire. La table Orders a CustomerID comme clé étrangère. La table des commandes peut avoir un CustomerID qui ne figure pas dans la table des clients. Nous avons besoin de tests pour découvrir de telles violations des contraintes d'intégrité. Le tableau de mappage de données vous donnera des précisions sur les tables qui ont ces contraintes.

Noter: Exécutez ce test dans le système cible et revérifiez dans le système source s'il y a des défauts.

# 6) Exhaustivité des données

Il s'agit de tests de cohérence qui découvrent le nombre d'enregistrements ou de lignes manquants entre la table source et la table cible et peuvent être exécutés fréquemment une fois automatisés.

Il existe deux types de tests:

(i) Nombre d'enregistrements: Ici, nous comparons le nombre total d'enregistrements pour les tables correspondantes entre le système source et cible. Il s'agit d'une vérification rapide de l'intégrité pour vérifier la post-exécution du travail ETL ou de migration. Nous avons un défaut si les nombres ne correspondent pas.

Parfois, il y a des enregistrements rejetés pendant l'exécution du travail. Certains d'entre eux peuvent être valides. Mais en tant que testeur, nous en faisons un exemple.

(ii) Profilage des données de colonne: Ce type de test de bon sens est utile lorsque le nombre d'enregistrements est énorme. Ici, nous créons des ensembles logiques de données qui réduisent le nombre d'enregistrements, puis effectuons une comparaison entre la source et la cible.

  • Lorsque cela est possible, filtrez toutes les valeurs uniques dans une colonne, par exemple, ProductID peut se produire plusieurs fois dans la table OrderDetails. Choisissez une liste unique pour ProductID dans les tables cible et source et validez. Cela réduit considérablement le nombre d'enregistrements et accélère les tests de cohérence.
  • Comme les tests ci-dessus, nous pouvons également sélectionner toutes les colonnes principales et vérifier si les KPI (longueur minimale, maximale, moyenne, maximale ou minimale, etc.) correspondent entre la cible et la table source. Exemple: Prenez les valeurs moyennes, minimales et maximales de la colonne Price dans OrderDetails et comparez ces valeurs entre les tables cible et source pour les incohérences.
  • Une autre vérification peut être effectuée pour les valeurs Null. Choisissez les colonnes importantes et filtrez une liste de lignes où la colonne contient des valeurs Null. Comparez ces lignes entre les systèmes cible et source pour la non-concordance.

Délais

# 7) Transformation des données

Ces tests constituent les tests de base du projet. Passez en revue le document d'exigences pour comprendre les exigences de transformation. Préparez les données de test dans les systèmes source pour refléter différents scénarios de transformation. Celles-ci comportent une multitude de tests et doivent être couvertes en détail dans les rubriques de test ETL.

Voici une liste concise des tests couverts par ceci:

(i) Transformation:

  • Exemple: Le code ETL peut avoir une logique pour rejeter les données non valides. Vérifiez-les par rapport aux exigences.
  • Le code ETL peut également contenir une logique pour générer automatiquement certaines clés telles que des clés de substitution. Nous avons besoin de tests pour vérifier l'exactitude (technique et logique) de ceux-ci.
  • Validez l'exactitude de la jointure ou de la division des valeurs de champ après l'exécution d'un travail ETL ou de migration.
  • Faites des tests pour vérifier les contrôles d'intégrité référentielle. Par exemple, Un type de défaut peut être ProductId utilisé dans la table Orders n'est pas présent dans la table parent Products. Faites un test pour vérifier le comportement des enregistrements orphelins pendant un travail ETL.
  • Parfois, les données manquantes sont insérées à l'aide du code ETL. Vérifiez l'exactitude de ceux-ci.
  • Les scripts ETL ou de migration ont parfois une logique pour corriger les données. Vérifiez que la correction des données fonctionne.
  • Vérifiez si des données non valides / rejetées / erronées sont signalées aux utilisateurs.
  • Créez une feuille de calcul de scénarios de données d'entrée et de résultats attendus et validez-les avec le client professionnel.

(ii) Cas de bord: Vérifiez que la logique de transformation tient bon aux limites.

  • Exemple: Que se passe-t-il lorsque TotalSales d'une valeur de 1 billion est exécuté via un travail ETL? Les cas de bout en bout fonctionnent-ils? Identifiez les champs qui peuvent potentiellement avoir de grandes valeurs et exécutez des tests avec ces grandes valeurs. Ils doivent inclure des valeurs numériques et non numériques.
  • Pour les champs de date, y compris toute la plage de dates attendues - années bissextiles, 28/29 jours pour février. 30, 31 jours pour les autres mois.

# 8) Unicité ou duplication des données

Dans ce type de test, identifiez les colonnes qui doivent avoir des valeurs uniques selon le modèle de données. Tenez également compte de la logique métier pour éliminer ces données. Exécutez des tests pour vérifier s'ils sont uniques dans le système. Exécutez ensuite des tests pour identifier les doublons réels.

  • Exemple: Filtrez les données en double et vérifiez si elles sont authentiques. Par exemple, L'enregistrement dépendant de l'employé contient deux fois les mêmes données sur les frères et sœurs.
  • Le numéro de téléphone de l'utilisateur doit être unique dans le système (exigence métier).
  • L'exigence métier indique qu'une combinaison de ProductID et ProductName dans la table Products doit être unique car ProductName peut être dupliqué.

# 9) Obligatoire

Dans ce type de test, identifiez tous les champs marqués comme obligatoires et validez si les champs obligatoires ont des valeurs. S'il existe des valeurs par défaut associées à un champ dans la base de données, vérifiez s'il est correctement rempli lorsque les données n'y sont pas.

  • Exemple: Si BillDate n'est pas entré, CurrentDate est le BillDate.

# 10) Actualité

Documentez toujours les tests qui vérifient que vous travaillez avec des données provenant des délais convenus.

  • Exemple: ProductDiscount a été mis à jour il y a 15 jours et le domaine d'activité indique que ProductDiscount est modifié tous les sept jours. Cela signifie que vos tests ne sont pas effectués avec les bonnes valeurs de remise.
  • Un rapport d'analyse prédictive pour l'indice de satisfaction client était censé fonctionner avec les dernières données d'une semaine, qui était une semaine de promotion des ventes chez Walmart. Mais le travail ETL a été conçu pour s'exécuter à une fréquence de 15 jours. Il s'agit d'un défaut majeur que les testeurs peuvent découvrir.

# 11) Données nulles

Dans ce type de test, nous nous concentrons sur la validité des données nulles et la vérification que la colonne importante ne peut pas être nulle.

  • Exemple: Filtrez toutes les données nulles et validez si nul est autorisé.
  • S'il existe des colonnes importantes pour les décisions commerciales, assurez-vous que les valeurs nulles ne sont pas présentes.

# 12) Vérification de la plage

L'entité de données où les plages ont un sens commercial doit être testée.

  • Exemple: La quantité commandée par facture ne peut pas dépasser 5K dans la catégorie logiciel.
  • L'âge ne doit pas dépasser 120 ans.

# 13) Règles commerciales

Documentez toutes les exigences commerciales pour les champs et exécutez des tests pour ceux-ci.

  • Exemple: Les ressources âgées de moins de 20 ans ne sont pas éligibles. Des contrôles de validation des données sont nécessaires si cette règle est appliquée aux données.
  • La date de résiliation doit être nulle si le statut Employé actif est Vrai / Décédé.
  • Les données FROM doivent être inférieures à la date TO.
  • Les montants des achats au niveau des articles s’additionnent-ils aux montants au niveau de la commande

# 14) Fonctions d'agrégation

Les fonctions d'agrégation sont intégrées à la fonctionnalité de la base de données. Documentez tous les agrégats dans le système source et vérifiez si l'utilisation agrégée donne les mêmes valeurs dans le système cible (somme, max, min, nombre).

Très souvent, les outils du système source sont différents du système cible. Vérifiez si les deux outils exécutent les fonctions d'agrégation de la même manière.

# 15) Troncature et arrondissement des données

Dans ces types de tests, nous identifions des champs avec une logique de troncature et d'arrondi concernant l'entreprise. Nous documentons ensuite et approuvons la logique de troncature et d'arrondi avec les propriétaires de produits et les testons avec des données représentatives de la production.

# 16) Tests d'encodage

Validez s'il existe des valeurs codées dans le système source et vérifiez si les données sont correctement renseignées après la tâche ETL ou de migration de données dans le système cible.

  • Exemple: Les caractères à deux octets pour FirstName en chinois ont été acceptés dans le système source qui a été codé. Vérifiez le comportement de ce champ lorsqu'il est déplacé vers le système cible.
  • Le champ Mot de passe a été codé et migré. Assurez-vous qu'ils fonctionnent correctement après la migration.

# 17) Tests de régression

Il s'agit d'un concept de test de base dans lequel les testeurs exécutent toute leur suite de cas de test critique générée à l'aide de la liste de contrôle ci-dessus et publie une modification du système source ou cible.

Conclusion

Ainsi, nous avons vu que la validation des données est un domaine intéressant à explorer pour les projets gourmands en données et constitue les tests les plus importants. La feuille de mappage de données est un artefact critique que les testeurs doivent maintenir pour réussir ces tests. Ils peuvent conserver plusieurs versions avec des surbrillances de couleur pour former des entrées pour l'un des tests ci-dessus.

Des précautions doivent être prises pour conserver les modifications delta entre les versions.

Nous demandons aux lecteurs de partager d'autres domaines du test qu'ils ont rencontrés au cours de leur travail au profit de la communauté des testeurs.

lecture recommandée

^