Tests de Business Intelligence (BI) avec des cas de test

Par : Thomas Hamilton Thomas Hamilton
Hours Le kit de préparation mis à jour

⚡ Résumé intelligent

Les tests de veille stratégique vérifient les données intermédiaires, le processus ETL et les rapports de veille stratégique sur lesquels reposent les décisions. Ils confirment que les données circulent correctement de la source vers la cible et que chaque chiffre affiché dans un rapport est fiable.

  • 🧪 Trois couches : Les données intermédiaires, la transformation ETL et le rapport final nécessitent chacun leurs propres scénarios de test.
  • (I.e. Objectif ETL : Vérifier la carteping, les types de données, la génération de clés, les règles de transformation et l'absence de troncature ou de duplication.
  • (I.e. Sujet du rapport : Vérifiez la mise en forme, la précision décimale, la gestion des valeurs vides et le comportement de la recherche.
  • (I.e. Réconciliation: Le nombre de lignes entre la source, la zone de transit et la cible doit correspondre une fois les règles de filtrage appliquées.
  • ⚠️ L'ordre compte : Un défaut dans la phase de préparation entraîne des défaillances à chaque étape ultérieure ; il faut donc tester le pipeline séquentiellement.
  • (I.e. But ultime: La crédibilité des données est essentielle pour qu'une décision commerciale prise sur la base d'un rapport repose sur des chiffres précis.
En savoir plus

Tests de veille stratégique (BI)

Qu’est-ce que les tests BI ?

Business Intelligence (BI de) L'informatique décisionnelle (BI) est le processus de collecte, de nettoyage, d'analyse, d'intégration et de partage des données afin d'en extraire des informations exploitables favorisant la croissance de l'entreprise. Les tests de BI vérifient les données de préparation, le processus ETL et les rapports de BI, et s'assurent de la bonne implémentation. Ils garantissent la fiabilité des données et l'exactitude des informations issues du processus de BI.

Vous pouvez en savoir plus sur ETL/Business Intelligence dans ce tutoriel

Le processus de test BI

Les tests de BI suivent la structure même du pipeline de données. Chaque étape doit être validée avant que la suivante ne soit testée, car un défaut en amont se manifeste par une fausse alerte en aval.

  1. Analyse des besoins : Déterminez les questions métier auxquelles les rapports doivent répondre et les systèmes sources qui contiennent les données. Toute ambiguïté à ce stade rendra le rapport impossible à tester ultérieurement.
  2. Validation des données sources : Analysez la source : nombre de lignes, types de données, taux de valeurs nulles et doublons. Il est impossible de valider une transformation par rapport à une source non mesurée.
  3. Validation de la mise en scène : Confirmer l'extracL'opération s'est déroulée sans problème, les comptes de rapprochement correspondant à la source après application des règles de filtrage.
  4. Tests ETL et de transformation : Vérifiez chaque carteping et les règles métier, y compris les colonnes dérivées, les agrégations et la génération de clés de substitution.
  5. Entrepôt de données et les tests de cubes. Vérifiez l'intégrité des tables de dimensions et de faits, la gestion des dimensions à évolution lente et la précision de l'agrégation à chaque niveau de la hiérarchie.
  6. Tests de rapports et de tableaux de bord : Comparez les chiffres du rapport avec ceux de l'entrepôt de données, puis avec ceux de la source, et vérifiez les filtres, les analyses approfondies et les rôles de sécurité.
  7. Tests de performance et de régression : Mesurez la durée de la fenêtre de chargement et signalez le temps de réponse, puis relancez la suite après chaque modification du pipeline.

La réconciliation est la pierre angulaire de tout le processus : À chaque étape, le nombre et la somme des chiffres clés doivent être tracIl est possible de remonter à la source. Un rapport qui semble correct mais qui ne peut être corroboré n'est pas testé, il est seulement examiné.

Types de tests de BI

Les scénarios présentés dans ce tutoriel se répartissent en six catégories reconnues. Les nommer permet d'établir un plan de test exhaustif, et non seulement des aspects faciles à vérifier.

Type Ce que cela valide Technique typique
Complétude des données Tous les disques attendus sont arrivés Rapprochement du nombre de lignes entre la source et la cible
Transformation de données Les règles métier ont été correctement appliquées. Comparer les résultats transformés aux valeurs attendues calculées manuellement
Qualité des données Les valeurs sont valides, uniques et comprises dans la plage indiquée. Vérifications des valeurs nulles, des doublons, du format et de l'intégrité référentielle
Tests de métadonnées Les types de données, les longueurs et les contraintes correspondent aux spécifications Comparaison des schémas entre la source et la cible
Test du rapport Les chiffres, la mise en forme et les analyses approfondies sont corrects. Vérifiez que le résultat du rapport correspond bien à la requête de l'entrepôt de données.
Tests de sécurité Les utilisateurs ne voient que les données auxquelles leur rôle leur donne accès. Exécuter des rapports identiques avec des identifiants de rôle différents

Le choix de Outil de BI Cela influe sur la manière dont chaque type est exécuté, mais pas sur les types nécessaires. Les tests de sécurité sont les plus souvent négligés et les plus coûteux à ignorer, car une faille de sécurité au niveau des lignes expose des données à travers les unités opérationnelles sans produire d'erreur visible.

ARTICLES LIÉS

Cas de test et scénarios de test BI

Les scénarios ci-dessous s'appliquent à presque tous les projets de BI. Regroupez-les selon l'étape du pipeline qu'ils valident et exécutez-les dans cet ordre, car un défaut lors de la validation entraînera des échecs à chaque étape ultérieure.

scénarios de tests de vérification ETL

  • Vérifier que les données sont correctement mappées de la source au système cible
  • Vérifiez que toutes les tables et leurs champs sont copiés de la source vers la cible
  • Vérifiez que les clés configurées pour être générées automatiquement sont créées correctement dans le système cible
  • Vérifiez que les champs nuls ne sont pas renseignés
  • Vérifier que les données ne sont ni tronquées ni tronquées
  • Vérifiez que le type et le format des données dans le système cible sont comme prévu
  • Vérifiez qu'il n'y a pas de duplicité de données dans le système cible
  • Vérifier que les transformations sont appliquées correctement
  • Vérifier que la précision des données dans les champs numériques est exacte
  • Vérifier que la gestion des exceptions est robuste

Scénarios de test de données de préparation

  • Vérification de rapprochement : le nombre d'enregistrements entre les tables STG (stade) et les tables cibles est le même après l'application des règles de filtrage
  • Insérer un enregistrement qui n'est pas chargé dans la table cible pour une combinaison de touches donnée
  • Renvoi des enregistrements déjà présents dans les tables cibles et vérification qu'ils ne sont pas chargés deux fois.
  • Mettre à jour un enregistrement pour une clé lorsque les colonnes de valeurs ont changé lors du chargement du jour_02
  • Supprimer logiquement les enregistrements dans les tables cibles
  • Valeurs chargées par les tables de processus
  • Valeurs chargées par les tables de référence

scénarios de test de chargement de données

  • Vérifiez si les bases de données cible et source sont bien connectées et s'il n'y a pas de problèmes d'accès.
  • Pour un chargement complet, cochez l’option tronquée et assurez-vous qu’elle fonctionne correctement.
  • Pendant le chargement des données, vérifiez les performances de la session
  • Vérifiez les erreurs non fatales.
  • Vérifiez que vous pouvez faire échouer la tâche parent appelante si la tâche enfant échoue.
  • Vérifiez que les journaux sont mis à jour
  • Vérifier la carteping et workflow les paramètres sont configurés avec précision
  • Vérifiez que le nombre de tables dans les systèmes source et cible est le même
  • Comparez les attributs des tables d'étape à ceux des tables cibles. Ils devraient être assortis.

Scénarios de test de rapports BI

  • Afficher la date et l'heure
  • Précision décimale pour les chiffres clés
  • Dans une page donnée afficher le nombre de lignes et de colonnes
  • Caractéristiques gratuites dans le rapport
  • Affichage des valeurs manquantes pour les caractéristiques et les chiffres clés
  • Que la recherche par caractéristique fonctionne sur une clé, sur du texte ou sur les deux, comme spécifié
  • La prise en compte de la casse dans la recherche textuelle et sa conformité aux exigences

Défis liés aux tests de BI

  • Volume de données. Les entrepôts de données contiennent des centaines de millions d'enregistrements, rendant toute comparaison exhaustive impossible. Les tests reposent sur les totaux de rapprochement ainsi que sur un échantillonnage ciblé des enregistrements limites et à haut risque.
  • Sources hétérogènes. Un seul entrepôt de données peut provenir de bases de données relationnelles, de fichiers plats, d'API et de systèmes existants, chacun avec son propre encodage, format de date et convention de valeur nulle.
  • Aucun défaut visible. Une erreur dans un rapport ne constitue pas une faute. Elle révèle simplement une mauvaise décision, ce qui fait du rapprochement la seule méthode de détection fiable.
  • Sources en constante évolution. Une modification de schéma dans un système en amont interrompt silencieusement une cartepingLes tests de métadonnées doivent être effectués régulièrement, et pas seulement au moment de la mise en production.
  • Dimensions évoluant lentement. L'exactitude historique exige qu'un enregistrement valable l'année dernière indique toujours la valeur de l'année dernière, ce qui est difficile à vérifier et facile à mal interpréter.
  • Parité environnementale. Les environnements de test contiennent rarement des données à l'échelle de la production, de sorte que les problèmes de fenêtres de chargement et de performances des requêtes n'apparaissent qu'après la mise en production.

Le point commun est que les défauts de BI sont silencieux. Chaque mesure d'atténuation décrite ci-dessus fonctionne en créant un signal là où le système lui-même n'en produit aucun.

FAQ

Les tests ETL vérifient que les données sont correctement déplacées et transformées de la source vers la cible. Les tests BI sont plus larges : ils incluent la validation ETL ainsi que l’entrepôt de données, les cubes et les rapports réellement utilisés par l’entreprise.

Privilégier la réconciliation à la comparaison ligne par ligne. Faire correspondre les décomptes et les totaux de contrôle entre les étapes, puis échantillonner les valeurs limites, les valeurs nulles, les doublons et les règles métier présentant le risque le plus élevé.

Parce qu'elles ne produisent aucune erreur. Un chiffre erroné s'affiche exactement comme un chiffre correct ; le défaut n'apparaît donc que lorsqu'on remet en question le nombre, souvent longtemps après qu'une décision a été prise à son sujet.

Les outils d'IA analysent les données sources et cibles afin de détecter automatiquement les anomalies, les dérives et les changements de schéma, et de signaler les enregistrements dont les valeurs s'écartent des distributions apprises avant la publication d'un rapport.

Oui. L'IA peut déduire des contrôles de complétude, d'unicité et de référentiel à partir d'un schéma et proposer des tests de transformation à partir d'une carte.ping Documents. Validez chaque règle par rapport aux spécifications métier avant de l'exécuter.

Résumez cet article avec :