Menu

Tutoriel complet de test Hadoop | Guide de test du Big Data

  • Principal
  • Autre
  • Tutoriel complet de test Hadoop | Guide de test du Big Data

comprehensive hadoop testing tutorial big data testing guide

Essayez Notre Instrument Pour Éliminer Les Problèmes

Ce didacticiel explique les principes de base, les types de test, les plans, l'environnement requis, le processus de test, la validation et les vérifications pour les tests Hadoop et BigData:

Dans ce tutoriel, nous verrons l'introduction de base à Hadoop et BigData Testing, comme quand et où les tests entreront en scène et ce que nous devons tester dans le cadre de Hadoop Testing.

Nous aborderons également en détail les sujets suivants:

  • Rôles et responsabilités des tests Hadoop
  • Approche de test pour les tests Hadoop / BigData

=> Cliquez ici pour voir de A à Z des didacticiels de formation BigData ici.

Introduction aux tests BigData et Hadoop

Ce que vous apprendrez:

Stockage et traitement des données dans Hadoop

Pour effectuer ces processus sur le système Hadoop, nous disposons de la main-d'œuvre classée en quatre sections.

  • Administrateurs Hadoop sont responsables de la configuration de l'environnement et disposent des droits d'administration pour accéder aux systèmes Hadoop.
  • Développeurs Hadoop développer les programmes concernant l'extraction, le stockage et le traitement des données de différents emplacements vers des emplacements centralisés.
  • Testeurs Hadoop pour valider et vérifier les données avant de tirer depuis différents emplacements et après l'extraction à l'emplacement centralisé ainsi que la validation et la vérification sont effectuées lors du chargement des données dans l'environnement client.
  • Analystes Hadoop fonctionnent lorsque le chargement des données est terminé et lorsque les données atteignent l'entrepôt à l'emplacement du client. Ils utilisent ces données pour la génération de rapports et de tableaux de bord. Les analystes effectuent l'analyse des données pour la croissance et le développement des affaires.

Nous savons que Hadoop n'est pas un système unique; il contient plusieurs systèmes et machines. Les données sont divisées et stockées sur plusieurs machines et si nous voulons y accéder à nouveau, nous devons les combiner et les extraire dans des rapports, etc.

Le développeur est responsable de l'écriture de programmes en JAVA et Python pour extraire les données et les stocker.

L'autre travail d'un développeur est de traiter les données. Il existe deux couches de Hadoop, l'une est pour le stockage, c'est-à-dire Hadoop HDFS et une autre pour le traitement, c'est-à-dire Hadoop MapReduce.

Le stockage signifie que toutes les données que nous avons dans la source sont simplement stockées / insérées dans le système. Le traitement signifie que nous devons le diviser en plusieurs machines, puis le combiner et l'envoyer au client.

Ainsi, le stockage et le traitement sont effectués par des scripts de programmation, et le développeur est responsable de l'écriture des scripts.

Outre la programmation, l'autre méthode pour stocker et traiter les données dans Hadoop utilise des applications de base de données telles que Hive, Impala, HBase, etc. Ces outils ne nécessitent aucune connaissance en programmation.

Tests BigData et Hadoop

Une fois le stockage et le traitement effectués par le développeur, les données sont destinées à la génération de rapports. Avant cela, nous devons vérifier l'exactitude des données traitées et vérifier si les données sont correctement chargées et traitées correctement ou non.

Ainsi, le programme et / ou les scripts créés par un développeur doivent être vérifiés par le testeur Hadoop ou BigData. Le testeur doit connaître la programmation de base comme Mapper, Hive, Pig Scripts, etc. pour vérifier les scripts et exécuter les commandes.

Ainsi, avant de tester, les testeurs ont besoin de savoir ce que tous les programmes et scripts fonctionnent, comment écrire le code et ensuite réfléchir à la façon de les tester. Les tests peuvent être effectués manuellement ou à l'aide d'outils d'automatisation.

Hadoop propose différents types de tests tels que les tests unitaires, les tests de régression, les tests système et les tests de performances, etc. Ce sont donc les types de tests courants que nous utilisons dans nos tests normaux ainsi que dans les tests Hadoop et BigData.

Nous avons le même type de terminologies de test comme la stratégie de test, les scénarios de test et les cas de test, etc. dans Hadoop et BigData Testing. Seul l'environnement est différent et il existe différents types de techniques que nous utilisons pour tester le BigData et le système Hadoop car ici nous devons tester les données et non l'application.

Comment tester le BigData et tout ce qu'il faut tester dans BigData?

Pour les tests BigData, nous devons avoir des plans et des stratégies.

Nous devons donc considérer les points suivants:

  • Quelle est la stratégie ou le plan de test pour le BigData?
  • Quels types d'approches de test sont appliqués aux BigData?
  • Quel est l'environnement requis?
  • Comment valider et vérifier les BigData?
  • Quels sont les outils utilisés dans les tests BigData?

Essayons d’obtenir les réponses à toutes les questions ci-dessus.

Quelle est la stratégie ou le plan pour tester les BigData?

Le test BigData signifie la vérification et la validation des données tout en les stockant et en les traitant dans l'entrepôt de données.

Lors du test de BigData, nous devons tester le volume et la variété des données extraites de différentes bases de données et chargées ainsi que traitées sur Data Warehouse ou Hadoop System, ces tests font l'objet de tests fonctionnels.

Nous devons tester la vitesse des données téléchargées à partir de diverses bases de données et téléchargées sur le système Hadoop, qui fait partie des tests de performance.

Ainsi, en tant que plan ou stratégie, nous devons nous concentrer sur les tests fonctionnels et de performance des tests BigData.

Dans BigData Testing, le testeur doit vérifier le traitement d'une énorme quantité de données à l'aide du matériel de base et des composants relatifs. Par conséquent, la qualité des données joue également un rôle important dans les tests de BigData. Il est essentiel de vérifier et de valider la qualité des données.

Types de test pour les tests BigData

Dans la section précédente, nous avons vu que les tests fonctionnels et les tests de performances jouent un rôle essentiel dans les tests BigData, mis à part cela en tant que testeur BigData, nous devons faire quelques types de tests supplémentaires comme les tests de bases de données ainsi que les tests architecturaux.

Ces types de tests sont également aussi importants que les tests fonctionnels et de performance.

# 1) Essais architecturaux

Ces tests sont effectués pour s'assurer que le traitement des données est correct et répond aux exigences. En fait, le système Hadoop traite d'énormes volumes de données et est très complet en ressources.

Si l'architecture est incorrecte, cela peut dégrader les performances, ce qui peut entraîner une interruption du traitement des données et une perte de données.

# 2) Test de base de données

Ici, la validation du processus entre en jeu et nous devons valider les données de diverses bases de données, c'est-à-dire que nous devons nous assurer que les données extraites des bases de données sources ou des bases de données locales doivent être correctes et appropriées.

De plus, nous devons vérifier que les données disponibles dans les bases de données source correspondent aux données saisies dans Hadoop System.

Test de la base de données

De même, nous devons valider si les données dans Hadoop System sont correctes et correctes après le traitement ou dire après la transformation et être chargées dans l'environnement du client avec une validation et une vérification appropriées.

Dans le cadre des tests de base de données, nous devons passer par le CRUEL opérations i.e. Créer les données dans les bases de données locales puis Récupérer les données et nous devons les rechercher et elles doivent être disponibles dans la base de données avant et après le chargement dans l’entrepôt de données et de l’entrepôt de données vers l’environnement du client.

Vérification de tout Actualisé Données à chaque étape du stockage ou du chargement et du traitement des données. Suppression de toute donnée corrompue ou de toute donnée dupliquée et nulle.

# 3) Test de performance

Dans le cadre des tests de performance, nous devons vérifier la vitesse de chargement et de traitement des données, c'est-à-dire comme l'IOPS (Input Output Per Second).

Besoin de vérifier la vitesse de saisie des données ou des données en tant qu’entrée de diverses bases de données vers l’entrepôt de données ou le système Hadoop et depuis le système Hadoop ou l’entrepôt de données vers l’environnement du client.

Doit également vérifier la vitesse des données provenant de diverses bases de données et de l'entrepôt de données en tant que sortie. C'est ce que nous appelons entrée-sortie par seconde ou IOPS.

En dehors de cela, un autre aspect consiste à vérifier les performances de l’absorption et de la distribution des données, ainsi que la vitesse à laquelle les données sont consommées par l’entrepôt de données à partir de diverses bases de données et par le système client du système Hadoop.

En tant que testeur, nous devons également vérifier les performances de la distribution des données, telles que la vitesse de distribution des données vers divers fichiers disponibles dans le système Hadoop ou dans l'entrepôt de données. De même, le même processus se produit lors de la distribution des données aux systèmes clients.

Le système Hadoop ou l'entrepôt de données se compose de plusieurs composants, un testeur doit donc vérifier les performances de tous ces composants comme les tâches MapReduce, l'insertion et la consommation de données, le temps de réponse des requêtes et leurs performances ainsi que les performances de la recherche. opérations. Tous ces éléments sont inclus dans les tests de performance.

# 4) Test fonctionnel

Le test fonctionnel contient le test de tous les sous-composants, programmes et scripts, outils utilisés pour effectuer les opérations de stockage ou de chargement et de traitement, etc.

Pour un testeur, ce sont les quatre types et étapes importants par lesquels les données doivent être filtrées afin que le client obtienne les données parfaites et sans erreur.

Outils pour les tests BigData Hadoop

Il existe différents outils utilisés pour tester BigData:

  • Système de fichiers de distribution HDFS Hadoop pour stocker les BigData.
  • HDFS Map Reduce pour le traitement des BigData.
  • Pour NoSQL ou HQL Cassandra DB, ZooKeeper et HBase, etc.
  • Outils de serveur basés sur le cloud comme EC2.

Environnements et paramètres de test

Pour tout type de test, le testeur a besoin des paramètres et de l'environnement appropriés.

Voici la liste des exigences:

  1. Type de données et d'application à tester.
  2. Le stockage et le traitement nécessitent un grand espace pour une énorme quantité de données.
  3. Distribution correcte des fichiers sur tous les DataNodes dans l'ensemble du cluster.
  4. Lors du traitement des données, l'utilisation du matériel doit être minimale.
  5. Programmes et scripts exécutables selon les exigences de l'application.

Rôles et responsabilités des tests Hadoop

En tant que testeur Hadoop, nous sommes responsables de la compréhension des exigences, de la préparation des estimations de test, de la planification des cas de test, de l'obtention de données de test pour tester certains cas de test, de la création du banc de test, de l'exécution des plans de test, du reporting et du nouveau test des défauts.

De plus, nous devons être responsables du rapport de l'état quotidien et de l'achèvement des tests.

Rôles et responsabilités des tests Hadoop

La première chose dont nous allons discuter est la Stratégie de test . Une fois que nous avons une solution proposée à notre problème, nous devons aller de l'avant et planifier ou élaborer une stratégie de notre plan de test, nous pouvons discuter de la stratégie d'automatisation que nous pouvons utiliser là-dedans, du plan concernant le calendrier des tests qui dépend de nos dates de livraison, ainsi que nous peut discuter de la planification des ressources.

La stratégie d'automatisation est quelque chose qui va nous aider à réduire les efforts manuels nécessaires pour tester le produit. Le calendrier des tests est important car il garantira la livraison rapide du produit.

La planification des ressources sera cruciale car nous devons planifier le nombre d'heures de travail dont nous avons besoin pour nos tests et la quantité de ressources Hadoop nécessaires pour exécuter notre planification des tests.

Une fois que nous avons défini notre stratégie de test, nous devons continuer et créer les plans de développement de test qui incluent la création de plans de test, la création de scripts de test, ce qui nous aidera à automatiser nos tests et à identifier également certaines données de test qui seront utilisées dans les plans de test. et nous aide à exécuter ces plans de test.

Une fois que nous avons terminé le développement de tests qui comprend la création de plans de test, de scripts de test et de données de test, nous allons de l'avant et commençons à exécuter ces plans de test.

Lorsque nous exécutons les plans de test, il peut y avoir certains scénarios dans lesquels la sortie réelle n'est pas celle attendue, et ces choses sont appelées des défauts. Chaque fois qu'il y a un défaut, nous devons également tester ces défauts et nous devons créer et maintenir les matrices pour ceux-ci.

Toutes ces choses entrent dans la catégorie suivante qui est Gestion des défauts .

Qu'est-ce que la gestion des défauts?

La gestion des défauts comprend le suivi des bogues, la correction des bogues et la vérification des bogues. Chaque fois qu'un plan de test est exécuté sur l'un des produits que nous avons et dès qu'un bogue particulier est identifié ou qu'un défaut est identifié, ce défaut doit être signalé au développeur ou attribué au développeur.

Ainsi, le développeur peut l'examiner et commencer à y travailler. En tant que testeur, nous devons suivre la progression du bogue et savoir si le bogue a été corrigé. Si le bogue a été corrigé comme signalé, nous devons continuer et le tester à nouveau et vérifier s'il est résolu.

Une fois que tous les bogues sont corrigés, fermés et vérifiés, nous devons continuer et livrer un produit testé OKAY. Mais avant de livrer le produit, nous devons nous assurer que l'UAT (User Acceptance Testing) est terminé avec succès.

Nous nous assurons que les tests d'installation et la vérification des exigences sont effectués correctement, c'est-à-dire que le produit qui est livré au client ou à un utilisateur final est conforme aux exigences mentionnées dans le document sur les exigences logicielles.

Les étapes dont nous avons discuté sont basées sur l'imagination, qu'il s'agisse de l'un des scénarios de test ou de l'une des approches de test que nous allons utiliser pour ces étapes ou de dire ces phrases pour tester notre produit et fournir le résultat final, qui est un OKAY Produit testé.

Allons-y, discutons de cela en détail et corrélons-le avec les tests Hadoop.

Nous savons que Hadoop est quelque chose qui est utilisé pour le traitement par lots et nous savons également qu'ETL est l'un des domaines où Hadoop est beaucoup utilisé. ETL signifie Extraction Transformation and Loading . Nous discuterons de ces processus en détail lorsque nous discuterons du plan de test et de la stratégie de test en tant que point de vue du test Hadoop.

Conformément au diagramme mentionné ci-dessous, nous supposons simplement que nous avons quatre sources de données différentes. Système opérationnel, CRM ( Gestion de la relation client ) et ERP ( Progiciel de Gestion Intégré ) est le SGBDR ou disons le système de gestion de base de données relationnelle que nous avons et nous avons également un certain nombre de fichiers plats qui peuvent être des journaux, des fichiers, des enregistrements ou quoi que ce soit en ce qui concerne nos sources de données.

Nous pourrions utiliser Sqoop ou Flume ou tout autre produit particulier pour obtenir les données, les enregistrements ou autre en tant que sources de données. Nous pouvons utiliser ces outils pour obtenir les données des sources de données dans mon répertoire de préparation qui est la première phase de notre processus appelée Extraction.

Une fois les données contenues dans le répertoire de transfert qui se trouve être en réalité HDFS (Hadoop Distribution File System), nous utiliserons en particulier le langage de script tel que PIG pour Transformer ces données. Cette Transformation sera selon les données que nous avons.

Une fois que les données sont transformées en conséquence en utilisant la technologie de script dont nous disposons, nous serons Chargement ces données dans l'entrepôt de données. À partir de l'entrepôt de données, ces données seront utilisées pour l'analyse OLAP, la création de rapports et l'exploration de données ou pour l'analyse.

Allons-y et discutons de toutes les phases que nous pouvons utiliser pour les tests Hadoop.

La première phase sera la phase d'extraction. Ici, nous allons obtenir les données de nos bases de données sources ou de fichiers plats, et dans ce cas, nous pouvons vérifier que toutes les données ont été copiées avec succès et correctement de la source vers le répertoire intermédiaire.

Il peut inclure, vérifier le nombre d'enregistrements, le type d'enregistrements et le type des champs, etc.

Une fois ces données copiées dans le répertoire intermédiaire, nous allons lancer la deuxième phase qui est la transformation. Ici, nous aurons une logique métier qui agira sur les données copiées à partir des systèmes sources et créera ou transformera réellement les données en la logique métier requise.

La transformation peut inclure le tri des données, le filtrage des données, la jonction des données de deux sources de données différentes et certaines autres opérations.

Une fois les données transformées, nous irons de l'avant et aurons des plans de test prêts et nous vérifierons si nous obtenons la sortie comme prévu, et toute la sortie que nous obtenons correspond au résultat attendu et les types de données, les valeurs de champ et les gammes, etc. sont quelque chose qui se met en place.

Une fois que c'est correct, nous pouvons continuer et charger les données dans l'entrepôt de données.

Dans la phase de chargement, nous vérifions en fait si le nombre d'enregistrements de la scène et le nombre d'enregistrements dans l'entrepôt de données sont synchronisés, ils peuvent ne pas être similaires, mais ils sont censés être synchronisés. Nous voyons également si le type de données qui a été transformé est synchronisé.

Publiez que nous utiliserons ces données pour l'analyse OLAP, le reporting et l'exploration de données, qui est la dernière couche de notre produit et dans ce cas, nous pouvons avoir des plans de test ultérieurs ou nous pouvons dire que les plans de test disponibles pour toutes ces couches.

Chaque fois que nous obtenons des données de la source vers la destination, nous devons toujours nous assurer que seules les personnes authentifiées ont un accès autorisé aux données.

Authentification

Authentification

Autorisation

Autorisation

Que voulons-nous dire par ces deux termes?

Pour comprendre cela, mettons les choses en perspective à partir du diagramme ETL.

ETL

Comme indiqué dans le diagramme ci-dessus, nous obtenons nos données à partir de moteurs SGBDR source et de fichiers plats dans HDFS, et cette phase est appelée extraction.

Parlons de l'authentification d'une manière particulière, certaines entreprises ont des données restreintes par leur nature, ce type de données est appelé données PII selon les normes américaines.

PII signifie Informations personnelles identifiables, toute information telle que la date de naissance, le SSN, le numéro de portable, l'adresse e-mail et l'adresse de la maison, etc. relèvent toutes des PII. Ceci est limité et ne peut pas être partagé avec tout le monde.

Les données ne doivent être partagées qu'avec les personnes qui en ont le plus besoin et celles qui en ont besoin pour un traitement réel. La mise en place de cette vérification et de la première ligne de défense s'appelle l'authentification.

Par exemple, nous utilisons un ordinateur portable et Windows y est installé, nous pourrions avoir un compte utilisateur créé sur notre système d'exploitation Windows et là, nous appliquions un mot de passe.

De cette façon, seule la personne qui possède les informations d'identification pour ce compte utilisateur particulier peut se connecter au système et c'est ainsi que nous allons protéger nos données contre le vol ou l'accès inutile. L'autre couche est l'autorisation.

Exemple, nous avons deux comptes utilisateur différents sur notre système d'exploitation Windows, un compte utilisateur est le nôtre et un autre peut être le compte utilisateur invité. L'administrateur (WE) a le droit d'effectuer toutes sortes d'opérations, comme l'installation et la désinstallation du logiciel, la création d'un nouveau fichier et la suppression de fichiers existants, etc.

Alors que d'un autre côté, les utilisateurs invités peuvent ne pas avoir tout ce type d'accès. L'invité dispose d'une authentification pour se connecter au système, mais n'a pas l'autorité de supprimer ou de créer les fichiers et l'installation ainsi que la désinstallation de l'un des logiciels du système et du système respectivement.

Cependant, le compte d'utilisateur invité, en raison de son authentification, a le droit de lire les fichiers créés et d'utiliser le logiciel déjà installé.

C'est ainsi que l'authentification et l'autorisation sont testées, dans ce cas, quelles que soient les données disponibles dans HDFS ou l'un des systèmes de fichiers dont nous avons besoin pour vérifier l'authentification et l'autorisation des données.

Approche de test pour les tests Hadoop / BigData

Approche de test

L'approche de test est commune pour tous les types de tests, non seulement parce qu'il s'agit de tests BigData ou Hadoop lorsque nous passons aux tests manuels normaux ou aux tests d'automatisation ou aux tests de sécurité, aux tests de performance également, donc tout type de test suit la même approche.

Conditions

Dans le cadre de l'approche de test, nous devons commencer par Conditions , L'exigence est une chose de base, de nos jours dans le processus Agile, nous l'avons appelé comme des histoires et des épopées. Epic n'est rien d'autre qu'une exigence plus importante alors que les histoires sont des exigences plus petites.

L'exigence contient essentiellement quels sont tous les modèles de données, cibles, sources ainsi que le type de transformations que nous devons appliquer, quel type d'outils nous devons utiliser? Tous ces types de détails seront disponibles sur les exigences.

Il s'agit essentiellement de l'exigence du client ou des exigences du client. Sur la base de cette exigence, nous commencerons notre processus de test.

Estimation

Une autre partie d'une approche est Estimation , Combien de temps nous devons prendre pour que toute l'activité soit réalisée dans le cadre des tests. Nous faisons la planification des tests, la préparation des scénarios de test, la préparation des cas de test et l'exécution de ceux-ci ainsi que nous trouverons les défauts et les signalerons et préparerons également des rapports de test.

Toutes ces activités prendront du temps, donc combien de temps nous avons besoin pour terminer toutes ces activités et cela s'appelle essentiellement une estimation. Nous devons donner une estimation approximative à la direction.

Planification des tests

Planification des tests n'est rien d'autre que la description des processus, ce qu'il faut tester, ce qu'il ne faut pas tester, quelle est la portée des tests, quels sont les calendriers, combien de ressources sont nécessaires, les exigences matérielles et logicielles et quels sont les délais ainsi que les cycles de test seront utilisés, quels sont les niveaux de test requis, etc.

Pendant la planification du test, ils effectueront certaines allocations de ressources au projet et quels sont les différents modèles que nous avons, combien de ressources sont nécessaires et quel type d'ensembles de compétences sont nécessaires, etc. toutes ces choses et tous ces aspects seront inclus dans le test. Phase de planification.

La plupart du temps, les personnes au niveau de la direction ou de la direction feront la planification des tests.

Scénarios de test et cas de test

Une fois que nous avons terminé la planification des tests, nous devons nous préparer Scénarios de test et cas de test , en particulier pour les tests Big Data, nous avons besoin de quelques documents avec le document d'exigence. Avec ce document d'exigence, de quoi avons-nous tous besoin?

Nous avons besoin du Document d'exigence qui contient les besoins du client, avec cela, nous avons besoin du Document d'entrée c'est à dire. Modèles de données. Modèle de données dans le sens que sont les schémas de la base de données, quelles sont les tables et quelles sont les relations, toutes ces données seront disponibles dans les modèles de données.

Aussi, nous avons le Documents de mappage , Documents de mappage pour Par exemple. dans les bases de données relationnelles, nous avons quelques tables et après avoir chargé les données via ETL dans l'entrepôt de données dans HDFS, que devons-nous faire tout le mappage? c'est-à-dire le type de données de mappage.

comment créer une liste d'objets en java

Par exemple, si nous avons une table client dans HDFS, alors dans HDFS nous avons une table CUSTOMER_TARGET ou la même table peut également être dans HIVE.

Cartographie des données

Dans cette table client, nous avons certaines colonnes et dans la table CUSTOMER TARGET, nous avons certaines colonnes comme indiqué dans le diagramme. Nous avons vidé les données de la table client dans la table cible client, c'est-à-dire de la source à la cible.

Ensuite, nous devons vérifier le mappage exact comme les données présentes dans la table source qui sont la colonne 1 et la ligne 1 de la table client et la considère comme C1R1 et les mêmes données doivent être mappées dans C1R1 de la table CUSTOMER TARGET. Cela s'appelle essentiellement Mapping.

Comment saurons-nous quels sont tous les mappages que nous devons vérifier? Ainsi, ces mappages seront présents dans le document de mappage. Dans le document de mappage, le client donnera toutes sortes de mappages.

De plus, nous avons exigé un Document de conception , Document de conception requis à la fois pour l'équipe de développement et pour l'équipe d'assurance qualité, car dans le document de conception le client fournira, quel type de tâches Map Reduce il va implémenter et quel type de tâches MapReduce prend des entrées et quel type de MapReduce Jobs donne des sorties.

De même, si nous avons HIVE ou PIG, quels sont tous les UDF que le client a créés ainsi que toutes les entrées qu'ils prendront et quel type de sortie ils produiront, etc.

Pour préparer des scénarios de test et des cas de test, nous devons avoir tous ces documents à portée de main:

  • Document d'exigence
  • Modèle de données
  • Document de cartographie
  • Document de conception

Celles-ci peuvent varier d'une organisation à une autre, et il n'y a pas de règle impérative selon laquelle nous devons avoir tous ces documents. Parfois, nous avons tous les documents et parfois nous n'avons que deux ou trois documents ou parfois nous devons également nous fier à un seul document, qui dépend de la complexité du projet, des calendriers de l'entreprise, etc.

Avis sur les scénarios de test et les cas de test

Nous devons effectuer un examen des scénarios de test et des cas de test parce que d'une manière ou d'une autre, nous oublions ou nous manquons certains cas de test parce que tout le monde ne peut pas penser à toutes les choses possibles qui peuvent être faites avec les exigences, dans de telles conditions, nous devons prendre l'aide d'outils tiers ou de quelqu'un d'autre.

Ainsi, chaque fois que nous préparons des documents ou effectuons quelque chose, nous avons besoin de quelqu'un pour examiner les éléments de la même équipe, comme des développeurs, des testeurs. Ils donneront des suggestions appropriées pour inclure quelque chose de plus ou suggéreront également de mettre à jour ou de modifier les scénarios de test et les cas de test.

Ils fournissent tous les commentaires et sur cette base, nous mettrons à jour nos scénarios de test et nos cas de test, ainsi que plusieurs versions du document que nous devons publier dans toute l'équipe jusqu'à ce que le document soit entièrement mis à jour conformément aux exigences.

Exécution des tests

Une fois le document prêt, nous obtiendrons l'approbation de l'équipe supérieure pour démarrer le processus d'exécution qui s'appelle essentiellement Exécution de cas de test.

Si nous voulons exécuter nos scénarios de test pendant l'exécution, nous devons vérifier que le développeur doit envoyer les informations, s'il s'agit de tests fonctionnels normaux ou de certains autres tests ou tests d'automatisation, nous avons besoin d'une construction. Mais, ici du point de vue Hadoop ou BigData Testing, le développeur fournira des Jobs MapReduce.

Fichiers HDFS - quels que soient les fichiers copiés dans HDFS, ces informations sont nécessaires pour vérifier les privilèges, les scripts HIVE qui ont été créés par les développeurs pour vérifier les données dans la table HIVE et nous avons également besoin des UDF HIVE qui ont été développés par les développeurs, PIG Scripts et UDF PIG.

Ce sont toutes les choses que nous devons obtenir des développeurs. Avant d'aller pour l'exécution, nous devrions avoir toutes ces choses.

Pour les tâches MapReduce, ils fourniront des fichiers JAR et dans le cadre du HDFS, ils ont déjà chargé les données dans HDFS et les fichiers devraient être prêts et les scripts HIVE pour valider les données dans les tables HIVE. Quels que soient les UDF qu'ils ont mis en œuvre, ils seront disponibles dans les UDF HIVE. Nous exigeons la même chose pour les scripts PIG et les UDF.

Rapports et suivi des défauts

Une fois que nous exécutons nos cas de test, nous trouvons des défauts, certains attendus et d'autres réels ne sont pas égaux aux résultats attendus, nous devons donc les énumérer et les fournir à l'équipe de développement pour résolution, et cela s'appelle essentiellement le rapport de défauts.

Supposons que si nous trouvons un défaut dans le Job MapReduce, nous le signalerons au développeur et il recréera à nouveau le Job MapReduce et effectuera quelques modifications au niveau du code, puis à nouveau, il fournira le dernier Job MapReduce, que nous devons tester. .

Il s'agit d'un processus continu, une fois le travail testé et réussi, nous devons à nouveau le tester et le signaler au développeur, puis obtenir le prochain pour le test. C'est ainsi que se déroule l'activité de rapport et de suivi des défauts.

Rapports d'essai

Une fois que nous avons terminé avec tout le processus de test et que les défauts ont été fermés, nous devons créer nos rapports de test. Les rapports de test sont tout ce que nous avons fait pour terminer le processus de test jusqu'à présent. Toute la planification, l'écriture et les exécutions de cas de test, les résultats obtenus, etc. tout est documenté ensemble sous forme de rapports de test.

Nous devons envoyer ces rapports sur une base quotidienne ou hebdomadaire ou selon les besoins du client. De nos jours, les organisations utilisent le modèle AGILE, donc chaque rapport d'état doit être mis à jour pendant les Scrums quotidiens.

Conclusion

Dans ce didacticiel, nous avons parcouru:

  • La stratégie ou le plan de test du BigData.
  • Environnement requis pour les tests BigData.
  • Validation et vérifications BigData.
  • Outils utilisés pour tester le BigData.

Nous avons également appris sur -

  • Comment la stratégie de test, le développement de test, les exécutions de test, la gestion des défauts et la livraison fonctionnent dans les rôles et responsabilités dans le cadre des tests Hadoop.
  • Approche de test pour les tests Hadoop / BigData qui comprend la collecte des exigences, l'estimation, la planification des tests, la création de scénarios de test et de cas de test ainsi que les révisions.
  • Nous avons également appris à connaître l'exécution des tests, le rapport et le suivi des défauts et le rapport de test.

Nous espérons que ce didacticiel de test BigData vous a été utile!

=> Consultez TOUS les didacticiels BigData ici.

lecture recommandée

^