Test ETL - Scénarios

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.