Test ETL - Guide rapide

Les données d'un système Data Warehouse sont chargées avec un outil ETL (Extraire, Transformer, Charger). Comme son nom l'indique, il effectue les trois opérations suivantes -

Extrait les données de votre système transactionnel qui peut être une base de données Oracle, Microsoft ou toute autre base de données relationnelle,
Transforme les données en effectuant des opérations de nettoyage des données, puis
Charge les données dans l'entrepôt de données OLAP.

Vous pouvez également extraire des données de fichiers plats tels que des feuilles de calcul et des fichiers CSV à l'aide d'un outil ETL et les charger dans un entrepôt de données OLAP pour l'analyse des données et la création de rapports. Prenons un exemple pour mieux le comprendre.

Exemple

Supposons qu'il existe une entreprise de fabrication ayant plusieurs départements tels que les ventes, les ressources humaines, la gestion des matériaux, EWM, etc. Tous ces départements ont des bases de données séparées qu'ils utilisent pour maintenir les informations sur leur travail et chaque base de données a une technologie, un paysage, un tableau noms, colonnes, etc. Désormais, si l'entreprise souhaite analyser des données historiques et générer des rapports, toutes les données de ces sources de données doivent être extraites et chargées dans un entrepôt de données pour les enregistrer pour un travail analytique.

Un outil ETL extrait les données de toutes ces sources de données hétérogènes, transforme les données (comme appliquer des calculs, joindre des champs, des clés, supprimer des champs de données incorrects, etc.) et les charger dans un entrepôt de données. Plus tard, vous pouvez utiliser divers outils de Business Intelligence (BI) pour générer des rapports, des tableaux de bord et des visualisations significatifs à l'aide de ces données.

Différence entre ETL et BI Tools

Un outil ETL est utilisé pour extraire des données de différentes sources de données, transformer les données et les charger dans un système DW; Cependant, un outil BI est utilisé pour générer des rapports interactifs et ad hoc pour les utilisateurs finaux, un tableau de bord pour la haute direction, des visualisations de données pour les réunions mensuelles, trimestrielles et annuelles du conseil.

Les outils ETL les plus courants incluent - SAP BO Data Services (BODS), Informatica - Power Center, Microsoft - SSIS, Oracle Data Integrator ODI, Talend Open Studio, Clover ETL Open source, etc.

Certains outils BI populaires incluent: SAP Business Objects, SAP Lumira, IBM Cognos, JasperSoft, Microsoft BI Platform, Tableau, Oracle Business Intelligence Enterprise Edition, etc.

Processus ETL

Examinons maintenant un peu plus en détail les étapes clés d'une procédure ETL -

Extraire les données

Il s'agit d'extraire les données de différentes sources de données hétérogènes. L'extraction de données à partir d'un système transactionnel varie selon les exigences et l'outil ETL utilisé. Cela se fait normalement en exécutant des tâches planifiées en dehors des heures de bureau, comme l'exécution de tâches la nuit ou le week-end.

Transformer les données

Il s'agit de transformer les données dans un format approprié qui peut être facilement chargé dans un système DW. La transformation des données implique l'application de calculs, de jointures et la définition de clés primaires et étrangères sur les données. Par exemple, si vous voulez% du revenu total qui n'est pas dans la base de données, vous appliquerez la formule% dans la transformation et chargerez les données. De même, si vous avez le prénom et le nom des utilisateurs dans différentes colonnes, vous pouvez appliquer une opération de concaténation avant de charger les données. Certaines données ne nécessitent aucune transformation; ces données sont appeléesdirect move ou pass through data.

La transformation des données implique également la correction des données et le nettoyage des données, la suppression des données incorrectes, la formation incomplète des données et la correction des erreurs de données. Il inclut également l'intégrité des données et le formatage des données incompatibles avant de les charger dans un système DW.

Chargement des données dans un système DW

Cela implique le chargement des données dans un système DW pour des rapports analytiques et des informations. Le système cible peut être un simple fichier plat délimité ou un entrepôt de données.

Fonction de l'outil ETL

Un entrepôt de données basé sur des outils ETL utilise une zone de transit, une intégration de données et des couches d'accès pour exécuter ses fonctions. C'est normalement une architecture à 3 couches.

Staging Layer - La couche intermédiaire ou la base de données intermédiaire est utilisée pour stocker les données extraites de différents systèmes de données source.
Data Integration Layer - La couche d'intégration transforme les données de la couche intermédiaire et déplace les données vers une base de données, où les données sont organisées en groupes hiérarchiques, souvent appelés dimensions, et dans facts et aggregate facts. La combinaison de tableaux de faits et de dimensions dans un système DW est appeléeschema.
Access Layer - La couche d'accès est utilisée par les utilisateurs finaux pour récupérer les données pour des rapports analytiques et des informations.

L'illustration suivante montre comment les trois couches interagissent les unes avec les autres.

Les tests ETL sont effectués avant le transfert des données dans un système d'entrepôt de données de production. Il est parfois également appelétable balancing ou production reconciliation. Il est différent des tests de bases de données en termes de sa portée et des étapes à suivre pour y parvenir.

Le principal objectif des tests ETL est d'identifier et d'atténuer les défauts de données et les erreurs générales qui se produisent avant le traitement des données pour les rapports analytiques.

Test ETL - Tâches à effectuer

Voici une liste des tâches courantes impliquées dans les tests ETL -

Comprendre les données à utiliser pour le reporting
Examiner le modèle de données
Mappage de la source vers la cible
Vérification des données sur les données sources
Paquets et validation de schéma
Vérification des données dans le système cible
Vérification des calculs de transformation de données et des règles d'agrégation
Exemple de comparaison de données entre la source et le système cible
Contrôle de l'intégrité et de la qualité des données dans le système cible
Test de performance sur les données

Les tests ETL et les tests de bases de données impliquent la validation des données, mais ils ne sont pas les mêmes. Les tests ETL sont normalement effectués sur des données dans un système d'entrepôt de données, tandis que les tests de bases de données sont généralement effectués sur des systèmes transactionnels où les données proviennent de différentes applications dans la base de données transactionnelle.

Ici, nous avons mis en évidence les principales différences entre les tests ETL et les tests de bases de données.

Test ETL

Les tests ETL impliquent les opérations suivantes -

Validation du mouvement des données de la source vers le système cible.
Vérification du nombre de données dans le système source et cible.
Vérification de l'extraction et de la transformation des données selon les besoins et les attentes.
Vérifier si les relations de table - jointures et clés - sont conservées pendant la transformation.

Les outils de test ETL courants comprennent QuerySurge, Informatica, etc.

Test de base de données

Les tests de base de données mettent davantage l'accent sur l'exactitude des données, l'exactitude des données et les valeurs valides. Il implique les opérations suivantes -

Vérifier si les clés primaires et étrangères sont conservées.
Vérifier si les colonnes d'une table ont des valeurs de données valides.
Vérification de l'exactitude des données dans les colonnes. Example - La colonne Nombre de mois ne doit pas avoir une valeur supérieure à 12.
Vérification des données manquantes dans les colonnes. Vérifiez s'il existe des colonnes nulles qui devraient avoir une valeur valide.

Les outils de test de base de données courants incluent Selenium, QTP, etc.

Le tableau suivant présente les principales fonctionnalités des tests de base de données et ETL et leur comparaison -

Fonction	Test de base de données	Test ETL
Objectif principal	Validation et intégration des données	Extraction, transformation et chargement de données pour le reporting BI
Système applicable	Système transactionnel où se déroule le flux commercial	Système contenant des données historiques et non dans un environnement de flux commercial
Outils communs	QTP, sélénium, etc.	QuerySurge, Informatica, etc.
Besoin commercial	Il est utilisé pour intégrer les données de plusieurs applications, impact sévère.	Il est utilisé pour les rapports analytiques, les informations et les prévisions.
La modélisation	Méthode ER	Multidimensionnel
Type de base de données	Il est normalement utilisé dans les systèmes OLTP	Il est appliqué aux systèmes OLAP
Type de données	Données normalisées avec plus de jointures	Données dé-normalisées avec moins de jointures, plus d'index et d'agrégations.

La catégorisation des tests ETL est effectuée en fonction des objectifs des tests et des rapports. Les catégories de tests varient selon les normes de l'organisation et cela dépend également des exigences du client. En règle générale, les tests ETL sont classés en fonction des points suivants -

Source to Target Count Testing - Il s'agit de faire correspondre le nombre d'enregistrements dans les systèmes source et cible.
Source to Target Data Testing- Il s'agit de la validation des données entre les systèmes source et cible. Cela implique également l'intégration des données et la vérification des valeurs de seuil et la vérification des données en double dans le système cible.
Data Mapping or Transformation Testing- Il confirme la cartographie des objets dans les systèmes source et cible. Cela implique également de vérifier la fonctionnalité des données dans le système cible.
End-User Testing- Il s'agit de générer des rapports pour les utilisateurs finaux afin de vérifier si les données dans les rapports sont conformes aux attentes. Cela implique de trouver des écarts dans les rapports et de vérifier les données dans le système cible pour la validation des rapports.
Retesting - Il s'agit de corriger les bogues et les défauts dans les données du système cible et d'exécuter à nouveau les rapports pour la validation des données.
System Integration Testing- Il s'agit de tester tous les systèmes individuels, puis de combiner les résultats pour trouver s'il y a des écarts. Il existe trois approches qui peuvent être utilisées pour effectuer cela: de haut en bas, de bas en haut et hybride.

Sur la base de la structure d'un système Data Warehouse, les tests ETL (quel que soit l'outil utilisé) peuvent être divisés dans les catégories suivantes:

Test du nouveau système DW

Dans ce type de test, un nouveau système DW est construit et vérifié. Les entrées de données proviennent des clients / utilisateurs finaux et également de différentes sources de données et un nouvel entrepôt de données est créé. Plus tard, les données sont vérifiées dans le nouveau système à l'aide d'outils ETL.

Test de migration

Lors des tests de migration, les clients disposent d'un entrepôt de données et d'un ETL existants, mais ils recherchent un nouvel outil ETL pour améliorer l'efficacité. Cela implique la migration des données du système existant à l'aide d'un nouvel outil ETL.

Test de changement

Dans les tests de changement, de nouvelles données sont ajoutées à partir de différentes sources de données à un système existant. Les clients peuvent également modifier les règles existantes pour ETL ou une nouvelle règle peut également être ajoutée.

Test de rapport

Le test de rapport implique la création de rapports pour la validation des données. Les rapports sont le résultat final de tout système DW. Les rapports sont testés en fonction de leur mise en page, des données du rapport et des valeurs calculées.

Les tests ETL sont différents des tests de bases de données ou de tout autre test conventionnel. On peut avoir à faire face à différents types de défis lors de l'exécution des tests ETL. Nous avons énuméré ici quelques défis courants -

Perte de données pendant le processus ETL.
Données incorrectes, incomplètes ou dupliquées.
Le système DW contient des données historiques, de sorte que le volume de données est trop important et extrêmement complexe pour effectuer des tests ETL dans le système cible.
Les testeurs ETL ne sont généralement pas autorisés à consulter les horaires de travail dans l'outil ETL. Ils ont à peine accès aux outils de reporting BI pour voir la présentation finale des rapports et des données à l'intérieur des rapports.
Difficile à générer et à créer des cas de test, car le volume de données est trop élevé et complexe.
Les testeurs ETL n'ont généralement aucune idée des exigences de rapport des utilisateurs finaux et du flux commercial des informations.
Les tests ETL impliquent divers concepts SQL complexes pour la validation des données dans le système cible.
Parfois, les testeurs ne reçoivent pas les informations de mappage source-cible.
Un environnement de test instable retarde le développement et le test d'un processus.

Un testeur ETL est principalement responsable de la validation des sources de données, de l'extraction des données, de l'application de la logique de transformation et du chargement des données dans les tables cibles.

Les principales responsabilités d'un testeur ETL sont énumérées ci-dessous.

Vérifiez les tables dans le système source

Il implique les opérations suivantes -

Vérification du compte
Réconcilier les enregistrements avec les données source
Vérification du type de données
Assurez-vous qu'aucune donnée de spam n'est chargée
Supprimer les données en double
Vérifiez que toutes les clés sont en place

Appliquer la logique de transformation

La logique de transformation est appliquée avant le chargement des données. Il implique les opérations suivantes -

Vérification de la validation du seuil de données, par exemple, la valeur d'âge ne doit pas être supérieure à 100.
Contrôle du nombre d'enregistrements, avant et après l'application de la logique de transformation.
Validation du flux de données de la zone de transit vers les tables intermédiaires.
Vérification de la clé de substitution.

Chargement des données

Les données sont chargées de la zone de transit vers le système cible. Il implique les opérations suivantes -

Contrôle du nombre d'enregistrements de la table intermédiaire vers le système cible.
Assurez-vous que les données du champ clé ne sont pas manquantes ou nulles.
Vérifiez si les valeurs agrégées et les mesures calculées sont chargées dans les tables de faits.
Vérifiez les vues de modélisation en fonction des tables cibles.
Vérifiez si CDC a été appliqué sur la table de charge incrémentielle.
Vérification des données dans la table de dimension et vérification de la table d'historique.
Vérifiez les rapports BI en fonction du fait et de la table de dimension chargés et selon les résultats attendus.

Test des outils ETL

Les testeurs ETL sont également tenus de tester les outils et les cas de test. Il implique les opérations suivantes -

Tester l'outil ETL et ses fonctions
Tester le système ETL Data Warehouse
Créez, concevez et exécutez les plans de test et les cas de test.
Testez les transferts de données de fichiers plats.

Il est important que vous définissiez la bonne technique de test ETL avant de démarrer le processus de test. Vous devez accepter l'acceptation de toutes les parties prenantes et vous assurer qu'une technique correcte est sélectionnée pour effectuer les tests ETL. Cette technique doit être bien connue de l'équipe de test et celle-ci doit connaître les étapes du processus de test.

Il existe différents types de techniques de test qui peuvent être utilisées. Dans ce chapitre, nous aborderons brièvement les techniques de test.

Test de validation de la production

Pour effectuer des rapports analytiques et des analyses, les données de votre production doivent être correctes. Ce test est effectué sur les données transférées vers le système de production. Cela implique la validation des données dans le système de production et leur comparaison avec les données source.

Test de comptage source-cible

Ce type de test est effectué lorsque le testeur a moins de temps pour effectuer l'opération de test. Il s'agit de vérifier le nombre de données dans les systèmes source et cible. Cela n'implique pas de vérifier les valeurs des données dans le système cible. Cela n'implique pas non plus si les données sont dans l'ordre croissant ou décroissant après le mappage des données.

Test des données source-cible

Dans ce type de test, un testeur valide les valeurs de données de la source vers le système cible. Il vérifie les valeurs de données dans le système source et les valeurs correspondantes dans le système cible après la transformation. Ce type de test prend du temps et est normalement effectué dans les projets financiers et bancaires.

Intégration des données / Test de validation des valeurs de seuil

Dans ce type de test, un testeur valide la plage de données. Toutes les valeurs de seuil dans le système cible sont vérifiées si elles correspondent au résultat attendu. Cela implique également l'intégration des données dans le système cible à partir de plusieurs systèmes sources après transformation et chargement.

Example - L'attribut Âge ne doit pas avoir une valeur supérieure à 100. Dans la colonne de date JJ / MM / AA, le champ du mois ne doit pas avoir une valeur supérieure à 12.

Test de migration d'application

Les tests de migration d'application sont normalement effectués automatiquement lorsque vous passez d'une ancienne application à un nouveau système d'application. Ces tests permettent de gagner beaucoup de temps. Il vérifie si les données extraites d'une ancienne application sont identiques à celles du nouveau système d'application.

Vérification des données et test des contraintes

Cela comprend l'exécution de diverses vérifications telles que la vérification du type de données, la vérification de la longueur des données et la vérification de l'index. Ici, un ingénieur de test exécute les scénarios suivants: clé primaire, clé étrangère, NOT NULL, NULL et UNIQUE.

Test de vérification des données en double

Ce test implique la vérification des données en double dans le système cible. Lorsqu'il y a une énorme quantité de données dans le système cible, il est possible qu'il y ait des données en double dans le système de production qui peuvent entraîner des données incorrectes dans les rapports analytiques.

Les valeurs en double peuvent être vérifiées avec une instruction SQL comme -

Select Cust_Id, Cust_NAME, Quantity, COUNT (*) 
FROM Customer
GROUP BY Cust_Id, Cust_NAME, Quantity HAVING COUNT (*) >1;

Des données en double apparaissent dans le système cible pour les raisons suivantes -

Si aucune clé primaire n'est définie, des valeurs en double peuvent apparaître.
En raison d'une cartographie incorrecte ou de problèmes environnementaux.
Erreurs manuelles lors du transfert des données de la source vers le système cible.

Test de transformation des données

Le test de transformation des données n'est pas effectué en exécutant une seule instruction SQL. Cela prend du temps et implique l'exécution de plusieurs requêtes SQL pour chaque ligne afin de vérifier les règles de transformation. Le testeur doit exécuter des requêtes SQL pour chaque ligne, puis comparer la sortie avec les données cibles.

Test de la qualité des données

Les tests de qualité des données impliquent la vérification du nombre, la vérification de la date, la vérification du zéro, la vérification de la précision, etc. Syntax Test pour signaler des caractères non valides, un ordre incorrect des majuscules / minuscules, etc. et Reference Tests pour vérifier si les données sont conformes au modèle de données.

Test incrémental

Des tests incrémentiels sont effectués pour vérifier si les instructions Insertion et Mise à jour sont exécutées conformément au résultat attendu. Ce test est effectué étape par étape avec les anciennes et les nouvelles données.

Les tests de régression

Lorsque nous modifions les règles de transformation et d'agrégation des données pour ajouter de nouvelles fonctionnalités qui aident également le testeur à trouver de nouvelles erreurs, cela s'appelle Test de régression. Les bogues dans les données qui proviennent des tests de régression sont appelés régression.

Nouveau test

Lorsque vous exécutez les tests après avoir corrigé les codes, cela s'appelle un nouveau test.

Test d'intégration de système

Les tests d'intégration de système consistent à tester les composants d'un système individuellement et à intégrer ultérieurement les modules. Une intégration système peut être réalisée de trois manières: descendante, ascendante et hybride.

Test de navigation

Le test de navigation est également connu sous le nom de test du frontal du système. Cela implique des tests du point de vue de l'utilisateur final en vérifiant tous les aspects du rapport frontal - comprend des données dans divers champs, des calculs et des agrégats, etc.

Les tests ETL couvrent toutes les étapes impliquées dans un cycle de vie ETL. Cela commence par la compréhension des exigences de l'entreprise jusqu'à la génération d'un rapport de synthèse.

Les étapes courantes du cycle de vie des tests ETL sont répertoriées ci-dessous:

Comprendre l'exigence métier.
Validation du besoin métier.
L'estimation de test est utilisée pour fournir le temps estimé pour exécuter les cas de test et pour terminer le rapport de synthèse.
La planification des tests consiste à trouver la technique de test basée sur les entrées selon les besoins de l'entreprise.
Création de scénarios de test et de cas de test.
Une fois que les cas de test sont prêts et approuvés, l'étape suivante consiste à effectuer un contrôle de pré-exécution.
Exécutez tous les cas de test.
La dernière étape consiste à générer un rapport de synthèse complet et à déposer un processus de clôture.

Les scénarios de test ETL sont utilisés pour valider un processus de test ETL. Le tableau suivant explique certains des scénarios et cas de test les plus courants utilisés par les testeurs ETL.

Scénarios de test	Cas de test
Validation de la structure	Il s'agit de valider la structure de la table source et cible selon le document de mappage. Le type de données doit être validé dans les systèmes source et cible. La longueur des types de données dans le système source et dans le système cible doit être la même. Les types de champs de données et leur format doivent être identiques dans le système source et dans le système cible. Validation des noms de colonne dans le système cible.
Validation du document de mappage	Il s'agit de valider le document cartographique pour s'assurer que toutes les informations ont été fournies. Le document de mappage doit avoir un journal des modifications, conserver les types de données, la longueur, les règles de transformation, etc.
Valider les contraintes	Il s'agit de valider les contraintes et de s'assurer qu'elles sont appliquées sur les tables attendues.
Contrôle de cohérence des données	Il s'agit de vérifier l'utilisation abusive des contraintes d'intégrité comme la clé étrangère. La longueur et le type de données d'un attribut peuvent varier dans différentes tables, bien que leur définition reste la même au niveau de la couche sémantique.
Validation de l'exhaustivité des données	Cela implique de vérifier si toutes les données sont chargées sur le système cible à partir du système source. Comptage du nombre d'enregistrements dans les systèmes source et cible. Analyse de la valeur limite. Validation des valeurs uniques des clés primaires.
Validation de l'exactitude des données	Il s'agit de valider les valeurs des données dans le système cible. Des données mal orthographiées ou inexactes se trouvent dans le tableau. Les données Null, Not Unique sont stockées lorsque vous désactivez la contrainte d'intégrité au moment de l'importation.
Validation de la transformation des données	Cela implique la création d'une feuille de calcul de scénarios pour les valeurs d'entrée et les résultats attendus, puis la validation avec les utilisateurs finaux. Validation de la relation parent-enfant dans les données en créant des scénarios. Utilisation du profilage des données pour comparer la plage de valeurs dans chaque champ. Valider si les types de données dans l'entrepôt sont identiques à ceux mentionnés dans le modèle de données.
Validation de la qualité des données	Cela implique la vérification du numéro, la vérification de la date, la vérification de la précision, la vérification des données, la vérification nulle, etc. Example - Le format de date doit être le même pour toutes les valeurs.
Validation nulle	Cela implique de vérifier les valeurs Null où Not Null est mentionné pour ce champ.
Validation en double	Cela implique la validation des valeurs en double dans le système cible lorsque les données proviennent de plusieurs colonnes du système source. Validation des clés primaires et d'autres colonnes s'il y a des valeurs en double selon les besoins de l'entreprise.
Contrôle de validation de la date	Champ de date de validation pour diverses actions effectuées dans le processus ETL. Cas de test courants pour effectuer la validation de date - From_Date ne doit pas être supérieur à To_Date Le format des valeurs de date doit être approprié. Les valeurs de date ne doivent avoir aucune valeur indésirable ni aucune valeur nulle
Validation complète des données sans requête	Il s'agit de valider l'ensemble de données complet dans les tables source et cible à l'aide d'une requête moins. Vous devez effectuer les deux source minus target et target minus source. Si la requête moins renvoie une valeur, cela doit être considéré comme des lignes incompatibles. Vous devez faire correspondre les lignes de la source et de la cible en utilisant le Intersect déclaration. Le nombre renvoyé par Intersect doit correspondre aux nombres individuels des tables source et cible. Si la requête moins ne renvoie aucune ligne et que le nombre d'intersection est inférieur au nombre source ou au nombre de tables cible, alors la table contient des lignes en double.
Autres scénarios de test	D'autres scénarios de test peuvent consister à vérifier que le processus d'extraction n'a pas extrait les données en double du système source. L'équipe de test maintiendra une liste d'instructions SQL exécutées pour valider qu'aucune donnée en double n'a été extraite des systèmes source.
Nettoyage des données	Les données indésirables doivent être supprimées avant de charger les données dans la zone de préparation.

Le réglage des performances ETL est utilisé pour s'assurer qu'un système ETL peut gérer une charge attendue de plusieurs utilisateurs et transactions. Le réglage des performances implique généralement une charge de travail côté serveur sur le système ETL. Il est utilisé pour tester la réponse du serveur dans un environnement multi-utilisateur et pour trouver les goulots d'étranglement. Ceux-ci peuvent être trouvés dans les systèmes source et cible, le mappage des systèmes, la configuration comme les propriétés de gestion de session, etc.

Comment effectuer le réglage des performances des tests ETL?

Suivez les étapes ci-dessous pour effectuer le réglage des performances des tests ETL -

Step 1 - Trouvez la charge qui est transformée en production.
Step 2 - Créez de nouvelles données de cette même charge ou déplacez les données de production vers votre serveur de performance local.
Step 3 - Désactivez l'ETL jusqu'à ce que vous ayez généré la charge requise.
Step 4 - Prendre le décompte des données nécessaires dans les tables de la base de données.
Step 5- Notez la dernière exécution d'ETL et activez l'ETL, afin qu'il subisse suffisamment de stress pour transformer la totalité de la charge créée. Exécuter
Step 6 - Une fois que l'ETL a terminé son exécution, prenez le décompte des données créées.

Indicateurs de performance clés

Découvrez le temps total nécessaire pour transformer la charge.
Découvrez si le temps d'exécution s'est amélioré ou diminué.
Vérifiez que la totalité de la charge attendue a été extraite et transférée.

Le but des tests ETL est d'obtenir des données crédibles. La crédibilité des données peut être atteinte en rendant le cycle de test plus efficace.

Une stratégie de test complète consiste à mettre en place un cycle de test efficace. La stratégie de test doit couvrir la planification des tests pour chaque étape du processus ETL, chaque fois que les données sont déplacées et indiquer les responsabilités de chaque partie prenante, par exemple les analystes commerciaux, l'équipe d'infrastructure, l'équipe d'assurance qualité, les administrateurs de base de données, les développeurs et les utilisateurs professionnels.

Pour garantir la disponibilité des tests sous tous les aspects, les domaines clés sur lesquels une stratégie de test doit se concentrer sont:

Portée des tests - Décrivez les techniques de test et les types à utiliser.
Configuration de l'environnement de test.
Tester la disponibilité des données - Il est recommandé d'avoir des données de type production couvrant tous les besoins critiques de l'entreprise.
Critères de qualité des données et d'acceptation des performances.

Dans les tests ETL, la précision des données est utilisée pour garantir que les données sont chargées avec précision dans le système cible conformément aux attentes. Les étapes clés de la précision des données sont les suivantes:

Comparaison des valeurs

La comparaison des valeurs implique la comparaison des données dans le système source et cible avec une transformation minimale ou nulle. Cela peut être fait à l'aide de divers outils de test ETL, par exemple, Source Qualifier Transformation dans Informatica.

Certaines transformations d'expression peuvent également être effectuées dans les tests d'exactitude des données. Différents opérateurs d'ensemble peuvent être utilisés dans les instructions SQL pour vérifier l'exactitude des données dans les systèmes source et cible. Les opérateurs courants sont les opérateurs Moins et Intersection. Les résultats de ces opérateurs peuvent être considérés comme un écart de valeur dans la cible et le système source.

Vérifier les colonnes de données critiques

Les colonnes de données critiques peuvent être vérifiées en comparant des valeurs distinctes dans les systèmes source et cible. Voici un exemple de requête qui peut être utilisé pour vérifier les colonnes de données critiques -

SELECT cust_name, Order_Id, city, count(*) FROM customer 
GROUP BY cust_name, Order_Id, city;

La vérification des métadonnées implique la validation de la structure de la table source et cible dans le document de mappage. Le document de mappage contient des détails sur les colonnes source et cible, les règles de transformation des données et les types de données, tous les champs qui définissent la structure des tables dans les systèmes source et cible.

Vérification de la longueur des données

La longueur du type de données de la colonne cible doit être égale ou supérieure au type de données de la colonne source. Prenons un exemple. Supposons que vous ayez les prénoms et les noms de famille dans la table source et que la longueur des données pour chacun d'entre eux soit définie sur 50 caractères. Ensuite, la longueur de données cible pour la colonne de nom complet dans le système cible doit être au minimum de 100 ou plus.

Vérification du type de données

La vérification du type de données implique de vérifier la source et le type de données cible et de s'assurer qu'ils sont identiques. Il est possible que le type de données cible soit différent des données source après une transformation. Par conséquent, il est également nécessaire de vérifier les règles de transformation.

Vérification des contraintes / index

La vérification des contraintes consiste à vérifier les valeurs d'index et les contraintes conformément au document de spécification de conception. Toutes les colonnes qui ne peuvent pas avoir de valeurs Null doivent avoir la contrainte Not Null. Les colonnes de clés primaires sont indexées selon le document de conception.

Effectuer des transformations de données est un peu complexe, car il ne peut pas être réalisé en écrivant une seule requête SQL, puis en comparant la sortie avec la cible. Pour la transformation des données de test ETL, vous devrez peut-être écrire plusieurs requêtes SQL pour chaque ligne afin de vérifier les règles de transformation.

Pour commencer, assurez-vous que les données source sont suffisantes pour tester toutes les règles de transformation. La clé pour réussir un test ETL pour les transformations de données est de sélectionner les exemples de données corrects et suffisants dans le système source pour appliquer les règles de transformation.

Les étapes clés de la transformation des données de test ETL sont répertoriées ci-dessous:

La première étape consiste à créer une liste de scénarios de données d'entrée et les résultats attendus et à les valider avec le client professionnel. Il s'agit d'une bonne approche pour la collecte des exigences lors de la conception et pourrait également être utilisée dans le cadre des tests.
L'étape suivante consiste à créer les données de test contenant tous les scénarios. Utilisez un développeur ETL pour automatiser l'ensemble du processus de remplissage des ensembles de données avec la feuille de calcul de scénario pour permettre la polyvalence et la mobilité, car les scénarios sont susceptibles de changer.
Ensuite, utilisez les résultats du profilage des données pour comparer la plage et la soumission des valeurs dans chaque champ entre les données cible et source.
Validez le traitement précis des champs générés par ETL, par exemple les clés de substitution.
La validation des types de données dans l'entrepôt est la même que celle spécifiée dans le modèle de données ou la conception.
Créez des scénarios de données entre les tables qui testent l'intégrité référentielle.
Validez les relations parent-enfant dans les données.
La dernière étape consiste à effectuer lookup transformation. Votre requête de recherche doit être directe sans aucune agrégation et ne doit renvoyer qu'une seule valeur par table source. Vous pouvez rejoindre directement la table de recherche dans le qualificatif source comme dans le test précédent. Si ce n'est pas le cas, écrivez une requête joignant la table de recherche avec la table principale de la source et comparez les données dans les colonnes correspondantes de la cible.

La vérification de la qualité des données pendant les tests ETL implique la réalisation de contrôles de qualité sur les données chargées dans le système cible. Il comprend les tests suivants -

Vérification du numéro

Le format de nombre doit être le même dans le système cible. Par exemple, dans le système source, le format de numérotation des colonnes estx.30, mais si la cible est uniquement 30, alors il doit charger sans préfixer x. dans le numéro de colonne cible.

Vérification de la date

Le format de date doit être cohérent dans les systèmes source et cible. Par exemple, il doit être le même pour tous les enregistrements. Le format standard est: aaaa-mm-jj.

Contrôle de précision

La valeur de précision doit s'afficher comme prévu dans la table cible. Par exemple, dans la table source, la valeur est 15,2323422, mais dans la table cible, elle doit s'afficher sous la forme 15,23 ou un tour de 15.

Vérification des données

Il s'agit de vérifier les données conformément aux exigences de l'entreprise. Les enregistrements qui ne répondent pas à certains critères doivent être filtrés.

Example - Seuls les enregistrements dont date_id> = 2015 et Account_Id! = '001' doivent se charger dans la table cible.

Vérification nulle

Certaines colonnes doivent avoir Null selon l'exigence et les valeurs possibles pour ce champ.

Example - La colonne Date de fin doit afficher Null à moins que et jusqu'à ce que sa colonne de statut Actif soit «T» ou «Décédé».

Autres contrôles

Les vérifications courantes telles que From_Date ne doivent pas être supérieures à To_Date.

La vérification de l'exhaustivité des données est effectuée pour vérifier que les données du système cible sont conformes aux attentes après le chargement.

Les tests courants qui peuvent être effectués pour cela sont les suivants -

Vérification des fonctions d'agrégation (sum, max, min, count),
Vérifier et valider les décomptes et les données réelles entre la source et la cible pour des colonnes sans transformations ou avec des transformations simples.

Validation du comptage

Comparez le nombre d'enregistrements dans les tables source et cible. Cela peut être fait en écrivant les requêtes suivantes -

SELECT count (1) FROM employee; 
SELECT count (1) FROM emp_dim;

Validation du profil de données

Il s'agit de vérifier les fonctions d'agrégation telles que count, sum et max dans les tables source et cible (fait ou dimension).

Validation du profil de données de colonne

Il s'agit de comparer les valeurs distinctes et le nombre de lignes pour chaque valeur distincte.

SELECT city, count(*) FROM employee GROUP BY city; 
SELECT city_id, count(*) FROM emp_dim GROUP BY city_id;

Validation des données en double

Il s'agit de valider la clé primaire et la clé unique dans une colonne ou dans une combinaison de colonnes qui doivent être uniques selon les besoins de l'entreprise. Vous pouvez utiliser la requête suivante pour effectuer la validation des données en double -

SELECT first_name, last_name, date_of_joining, count (1) FROM employee
GROUP BY first_name, last_name HAVING count(1)>1;

La récupération de sauvegarde pour un système est prévue pour garantir que le système est restauré dès que possible après une panne et que les opérations sont reprises le plus tôt possible sans perdre aucune donnée importante.

Les tests de récupération ETL Backup sont utilisés pour garantir que le système de l'entrepôt de données récupère avec succès du matériel, des logiciels ou d'une panne de réseau avec perte de données.

Un plan de sauvegarde approprié doit être préparé pour garantir une disponibilité maximale du système. Les systèmes de sauvegarde doivent pouvoir restaurer facilement et reprendre le système défaillant sans aucune perte de données.

Test ETL La récupération de sauvegarde implique d'exposer l'application ou le système DW à des conditions extrêmes pour tout composant matériel, panne de logiciel, etc. L'étape suivante consiste à s'assurer que le processus de récupération est lancé, que la vérification du système est effectuée et que la récupération des données est réalisée.

Les tests ETL sont principalement effectués à l'aide de scripts SQL et en rassemblant les données dans des feuilles de calcul. Cette approche pour effectuer des tests ETL est très lente et longue, sujette aux erreurs et est effectuée sur des échantillons de données.

Défi technique dans les tests ETL manuels

Votre équipe de test ETL écrit des requêtes SQL pour tester les données dans un système d'entrepôt et doit les exécuter manuellement à l'aide d'un éditeur SQL, puis placer les données dans une feuille de calcul Excel et les comparer manuellement. Ce processus est long, gourmand en ressources et inefficace.

Il existe différents outils disponibles sur le marché pour automatiser ce processus. Les outils de test ETL les plus courants sont QuerySurge et Informatica Data Validation.

QuerySurge

QuerySurge est une solution de test de données conçue pour tester le Big Data, les entrepôts de données et le processus ETL. Il peut automatiser l'ensemble du processus pour vous et s'intégrer parfaitement à votre stratégie DevOps.

Les principales fonctionnalités de QuerySurge sont les suivantes:

Il dispose d'assistants de requête pour créer des tests QueryPairs rapidement et facilement sans que l'utilisateur n'ait à écrire de code SQL.
Il dispose d'une bibliothèque de conception avec des extraits de requête réutilisables. Vous pouvez également créer des QueryPairs personnalisés.
Il peut comparer les données des fichiers source et des magasins de données à l'entrepôt de données cible ou au magasin Big Data.
Il peut comparer des millions de lignes et de colonnes de données en quelques minutes.
Il permet à l'utilisateur de planifier des tests pour exécuter (1) immédiatement, (2) n'importe quelle date / heure, ou (3) automatiquement après la fin d'un événement.
Il peut produire des rapports informatifs, afficher les mises à jour et envoyer automatiquement les résultats par e-mail à votre équipe.

Pour automatiser l'ensemble du processus, votre outil ETL doit démarrer QuerySurge via l'API de ligne de commande une fois que le logiciel ETL a terminé son processus de chargement.

QuerySurge s'exécutera automatiquement et sans surveillance, exécutant tous les tests, puis envoyant un e-mail à tous les membres de l'équipe avec les résultats.

Tout comme QuerySurge, Informatica Data Validation fournit un outil de test ETL qui vous aide à accélérer et à automatiser le processus de test ETL dans l'environnement de développement et de production. Il vous permet de fournir une couverture de test complète, répétable et vérifiable en moins de temps. Il ne nécessite aucune compétence en programmation!

Pour tester un système d'entrepôt de données ou une application BI, il faut avoir une approche centrée sur les données. Les meilleures pratiques de test ETL aident à minimiser le coût et le temps de réalisation des tests. Il améliore la qualité des données à charger sur le système cible qui génère des tableaux de bord et des rapports de haute qualité pour les utilisateurs finaux.

Nous avons répertorié ici quelques bonnes pratiques à suivre pour les tests ETL -

Analyser les données

Il est extrêmement important d'analyser les données pour comprendre les exigences afin de mettre en place un modèle de données correct. Passer du temps à comprendre les exigences et disposer d'un modèle de données correct pour le système cible peut réduire les défis ETL. Il est également important d'étudier les systèmes sources, la qualité des données et de créer des règles de validation de données correctes pour les modules ETL. Une stratégie ETL doit être formulée sur la base de la structure de données des systèmes source et cible.

Corriger les mauvaises données dans le système source

Les utilisateurs finaux sont normalement conscients des problèmes de données, mais ils ne savent pas comment les résoudre. Il est important de trouver ces erreurs et de les corriger avant qu'elles n'atteignent le système ETL. Une façon courante de résoudre ce problème est au moment de l'exécution ETL, mais la meilleure pratique consiste à trouver les erreurs dans le système source et à prendre des mesures pour les corriger au niveau du système source.

Trouver un outil ETL compatible

L'une des meilleures pratiques ETL courantes consiste à sélectionner un outil qui est le plus compatible avec les systèmes source et cible. La capacité de l'outil ETL à générer des scripts SQL pour les systèmes source et cible peut réduire le temps de traitement et les ressources. Il permet de traiter la transformation n'importe où dans l'environnement qui est le plus approprié.

Surveiller les travaux ETL

Une autre bonne pratique lors de la mise en œuvre ETL est la planification, l'audit et la surveillance des travaux ETL pour garantir que les charges sont effectuées conformément aux attentes.

Intégrer des données incrémentielles

Parfois, les tables de l'entrepôt de données sont plus volumineuses et il n'est pas possible de les actualiser à chaque cycle ETL. Les charges incrémentielles garantissent que seuls les enregistrements modifiés depuis la dernière mise à jour sont introduits dans le processus ETL et cela a un impact énorme sur l'évolutivité et le temps nécessaire pour actualiser le système.

Normalement, les systèmes source n'ont pas d'horodatage ou de clé primaire pour identifier facilement les modifications. De tels problèmes peuvent être très coûteux s'ils sont identifiés aux étapes ultérieures du projet. L'une des meilleures pratiques ETL consiste à couvrir ces aspects dans l'étude initiale du système source. Ces connaissances aident l'équipe ETL à identifier les problèmes de capture de données modifiés et à déterminer la stratégie la plus appropriée.

Évolutivité

Il est recommandé de s'assurer que la solution ETL proposée est évolutive. Au moment de la mise en œuvre, il faut s'assurer que la solution ETL est évolutive avec les besoins de l'entreprise et sa croissance potentielle à l'avenir.

↰ Previous page