comprehensive hadoop testing tutorial big data testing guide
Este tutorial explica los conceptos básicos, los tipos de prueba, los planes, el entorno requerido, el proceso de prueba, la validación y las verificaciones para las pruebas de Hadoop y BigData:
En este tutorial, veremos la introducción básica a Hadoop y BigData Testing, como cuándo y dónde entrarán en escena las pruebas y qué necesitamos probar como parte de Hadoop Testing.
También discutiremos los siguientes temas en detalle:
- Funciones y responsabilidades de las pruebas de Hadoop
- Enfoque de prueba para pruebas de Hadoop / BigData
=> Consulte aquí para ver los tutoriales de capacitación de la A a la Z de BigData aquí.
Lo que vas a aprender:
- Almacenamiento y procesamiento de datos en Hadoop
- Pruebas de BigData y Hadoop
- ¿Cuál es la estrategia o plan para probar BigData?
- Tipos de prueba para pruebas de BigData
- Herramientas para pruebas de BigData Hadoop
- Prueba de entornos y configuraciones
- Funciones y responsabilidades de las pruebas de Hadoop
- Enfoque de prueba para las pruebas de Hadoop / BigData Testing
- Conclusión
- Lectura recomendada
Almacenamiento y procesamiento de datos en Hadoop
Para realizar estos procesos en el sistema Hadoop, tenemos la mano de obra que se clasifica en cuatro secciones.
- Administradores de Hadoop son responsables de configurar el entorno y tienen los derechos de administración para acceder a los sistemas Hadoop.
- Desarrolladores de Hadoop Desarrollar los programas de extracción, almacenamiento y procesamiento de datos desde diferentes ubicaciones a ubicaciones centralizadas.
- Probadores de Hadoop para validar y verificar los datos antes de extraerlos de diferentes ubicaciones y después de extraerlos en la ubicación centralizada, así como para validar y verificar mientras se cargan los datos en el entorno del cliente.
- Analistas de Hadoop operar cuando se realiza la carga de datos y cuando los datos llegan al almacén en la ubicación del cliente. Usan estos datos para generar informes y paneles. Los analistas realizan el análisis de datos para el crecimiento y el desarrollo empresarial.
Sabemos que Hadoop no es un sistema único; contiene múltiples sistemas y máquinas. Los datos se dividen y almacenan en varias máquinas y, si queremos acceder a ellos de nuevo, necesitamos combinar y extraer los datos en informes y así sucesivamente.
El desarrollador es responsable de escribir programas en JAVA y Python para extraer los datos y almacenarlos.
El otro trabajo de un desarrollador es procesar los datos. Hay dos capas de Hadoop, una es para almacenar, es decir, Hadoop HDFS y otra para procesar, es decir, Hadoop MapReduce.
Almacenar significa que los datos que tenemos en la fuente simplemente se almacenan / insertan en el sistema. El procesamiento significa que debemos dividirlo en varias máquinas y volver a combinarlo y enviarlo al cliente.
Por lo tanto, el almacenamiento y el procesamiento se realizan mediante scripts de programación, y el desarrollador es responsable de escribir los scripts.
Además de la programación, el otro método para almacenar y procesar los datos en Hadoop es usar aplicaciones de base de datos como Hive, Impala, HBase, etc. Estas herramientas no necesitan ningún conocimiento de programación.
Pruebas de BigData y Hadoop
Una vez que el desarrollador realiza el almacenamiento y el procesamiento, los datos pasan a la generación de informes. Antes de eso, debemos verificar la precisión de los datos procesados y verificar si los datos se cargan con precisión y se procesan correctamente o no.
Por lo tanto, el programa y / o los scripts creados por un desarrollador deben ser verificados por Hadoop o BigData Tester. El evaluador necesita conocer la programación básica como Mapper, Hive, Pig Scripts, etc. para verificar los scripts y ejecutar los comandos.
Por lo tanto, antes de realizar la prueba, los evaluadores deben saber qué programas y scripts están funcionando, cómo escribir el código y luego pensar en cómo probarlos. Las pruebas se pueden realizar manualmente o mediante herramientas de automatización.
Hadoop tiene varios tipos de pruebas, como pruebas unitarias, pruebas de regresión, pruebas del sistema y pruebas de rendimiento, etc. Estos son los tipos de pruebas comunes que usamos en nuestras pruebas normales, así como en las pruebas de Hadoop y BigData.
Tenemos el mismo tipo de terminologías de prueba como estrategia de prueba, escenarios de prueba y casos de prueba, etc. en Hadoop y BigData Testing. Solo el entorno es diferente y hay diferentes tipos de técnicas que usamos para probar el sistema BigData y Hadoop porque aquí necesitamos probar los datos y no la aplicación.
¿Cómo probar BigData y qué requieren todas las pruebas en BigData?
Para las pruebas de BigData, necesitamos tener algunos planes y estrategias.
Por lo tanto, debemos considerar los siguientes puntos:
- ¿Cuál es la estrategia o plan de pruebas para BigData?
- ¿Qué tipo de enfoques de prueba se aplican a BigData?
- ¿Qué entorno se requiere?
- ¿Cómo validar y verificar BigData?
- ¿Cuáles son las herramientas utilizadas en BigData Testing?
Intentemos obtener las respuestas a todas las preguntas anteriores.
¿Cuál es la estrategia o plan para probar BigData?
Las pruebas de BigData significa Verificación y Validación de datos mientras se almacenan y procesan en el Almacén de Datos.
Mientras probamos BigData, necesitamos probar el volumen y la variedad de datos extraídos de diferentes bases de datos y cargados y procesados en el almacén de datos o el sistema Hadoop, esta prueba se somete a pruebas funcionales.
Necesitamos probar la velocidad de los datos descargados de varias bases de datos y cargados en el sistema Hadoop, que es parte de las pruebas de rendimiento.
Entonces, como plan o estrategia, debemos concentrarnos en las pruebas funcionales y de rendimiento de las pruebas de BigData.
En BigData Testing, el evaluador tiene que verificar el procesamiento de una gran cantidad de datos utilizando hardware básico y componentes relacionados. Por lo tanto, la calidad de los datos también juega un papel importante en la prueba de BigData. Es fundamental verificar y validar la calidad de los datos.
Tipos de prueba para pruebas de BigData
En la sección anterior, vimos que las pruebas funcionales y las pruebas de rendimiento juegan un papel vital en las pruebas de BigData, además de eso, como probadores de BigData, necesitamos hacer algunos tipos más de pruebas, como las pruebas de bases de datos y las pruebas arquitectónicas.
Estos tipos de pruebas también son tan importantes como las pruebas funcionales y de rendimiento.
# 1) Pruebas arquitectónicas
Esta prueba se realiza para garantizar que el procesamiento de datos sea adecuado y cumpla con los requisitos. En realidad, el sistema Hadoop procesa grandes volúmenes de datos y tiene una gran cantidad de recursos.
Si la arquitectura es incorrecta, puede degradar el rendimiento debido a lo cual el procesamiento de datos puede interrumpirse y puede ocurrir la pérdida de datos.
# 2) Prueba de base de datos
Aquí, la validación del proceso entra en escena y necesitamos validar los datos de varias bases de datos, es decir, debemos asegurarnos de que los datos obtenidos de las bases de datos de origen o las bases de datos locales deben ser correctos y adecuados.
Además, debemos verificar que los datos disponibles en las bases de datos de origen coincidan con los datos ingresados en el sistema Hadoop.
De manera similar, debemos validar si los datos en el sistema Hadoop son correctos y adecuados después del procesamiento o, por ejemplo, después de la transformación y si se cargan en el entorno del cliente con la validación y verificación adecuadas.
Como parte de las pruebas de base de datos, debemos pasar por el CRUEL operaciones, es decir Crear los datos en las bases de datos locales y luego Recuperar los datos y necesitamos buscarlos y deben estar disponibles en la base de datos antes y después de cargarlos en el almacén de datos y desde el almacén de datos al entorno del cliente.
Verificación de cualquier Actualizado Datos en cada etapa del almacenamiento o carga y procesamiento de datos. Eliminación de datos dañados o duplicados y nulos.
# 3) Prueba de rendimiento
Como parte de las pruebas de rendimiento, debemos verificar la velocidad de carga y procesamiento de los datos, es decir, como IOPS (entrada y salida por segundo).
Necesita verificar la velocidad de ingreso de los datos o datos como entrada desde varias bases de datos al almacén de datos o sistema Hadoop y desde el sistema Hadoop o almacén de datos al entorno del cliente.
También debe verificar la velocidad de los datos provenientes de varias bases de datos y del almacén de datos como salida. Esto es lo que llamamos Entrada Salida por segundo o IOPS.
Aparte de eso, otro aspecto es verificar el desempeño de la Absorción y Distribución de Datos, y qué tan rápido los datos son consumidos por el Data Warehouse de varias Bases de Datos y por el Sistema del Cliente del Sistema Hadoop.
También como Tester, debemos verificar el rendimiento de la Distribución de datos, como qué tan rápido se distribuyen los datos a varios archivos disponibles en el sistema Hadoop o en el almacén de datos. De manera similar, ocurre el mismo proceso al distribuir datos a los sistemas cliente.
El sistema Hadoop o el almacén de datos consta de múltiples componentes, por lo que un Tester debe verificar el rendimiento de todos esos componentes como los trabajos de MapReduce, la inserción y el consumo de datos, el tiempo de respuesta de las consultas y su rendimiento, así como el rendimiento de la búsqueda. operaciones. Todos estos están incluidos en Pruebas de rendimiento.
# 4) Prueba funcional
Las pruebas funcionales contienen pruebas de todos los subcomponentes, programas y scripts, herramientas utilizadas para realizar las operaciones de almacenamiento o carga y procesamiento, etc.
Para un Tester, estos son los cuatro tipos y etapas importantes a través de los cuales se deben filtrar los datos para que el cliente obtenga los datos perfectos y sin errores.
Herramientas para pruebas de BigData Hadoop
Hay varias herramientas que se utilizan para probar BigData:
- Sistema de archivos de distribución HDFS Hadoop para almacenar BigData.
- Reducción de mapa HDFS para procesar BigData.
- Para NoSQL o HQL Cassandra DB, ZooKeeper y HBase, etc.
- Herramientas de servidor basadas en la nube como EC2.
Prueba de entornos y configuraciones
Para cualquier tipo de prueba, el Tester necesita una configuración y un entorno adecuados.
A continuación se muestra la lista de requisitos:
- Tipo de datos y aplicación que se va a probar.
- El almacenamiento y el procesamiento requieren un gran espacio para una gran cantidad de datos.
- Distribución adecuada de archivos en todos los DataNodes en general del clúster.
- Al procesar los datos, la utilización del hardware debe ser mínima.
- Programas y secuencias de comandos ejecutables según el requisito de la aplicación.
Funciones y responsabilidades de las pruebas de Hadoop
Como probador de Hadoop, somos responsables de comprender los requisitos, preparar las estimaciones de prueba, planificar los casos de prueba, obtener algunos datos de prueba para probar algunos casos de prueba, participar en la creación del banco de pruebas, ejecutar los planes de prueba, informar y volver a probar los defectos.
Además, debemos ser responsables de los informes de estado diarios y la finalización de la prueba.
Lo primero que vamos a discutir es el Estrategia de prueba . Una vez que tenemos una solución propuesta a nuestro problema, debemos seguir adelante y planificar o crear una estrategia de nuestro plan de prueba, podemos discutir la estrategia de automatización que podemos usar allí, el plan sobre el programa de prueba que depende de nuestras fechas de entrega, también nosotros puede discutir la planificación de recursos.
La estrategia de automatización es algo que nos ayudará a reducir los esfuerzos manuales necesarios para probar el producto. El programa de pruebas es importante ya que garantizará la entrega oportuna del producto.
La planificación de recursos será crucial ya que necesitamos planificar cuántas horas-hombre necesitamos en nuestras pruebas y cuántos recursos de Hadoop se requieren para ejecutar nuestra planificación de pruebas.
Una vez que diseñamos la estrategia de nuestras pruebas, debemos seguir adelante y crear los planes de desarrollo de pruebas que incluyen la creación de planes de prueba, la creación de scripts de prueba que nos ayudarán a automatizar nuestras pruebas y también a identificar algunos datos de prueba que se utilizarán en los planes de prueba. y nos ayuda a ejecutar esos planes de prueba.
Una vez que hayamos terminado con el desarrollo de pruebas que incluye la creación de planes de prueba, scripts de prueba y datos de prueba, continuamos y comenzamos a ejecutar esos planes de prueba.
Cuando ejecutamos los planes de prueba, puede haber ciertos escenarios en los que el resultado real no sea el esperado, y esas cosas se denominan defectos. Siempre que haya un defecto, también debemos probar esos defectos y debemos crear y mantener las matrices para ellos.
Todas estas cosas caen en la siguiente categoría que es Gestión de defectos .
¿Qué es la gestión de defectos?
La gestión de defectos consiste en el seguimiento de errores, la corrección de errores y la verificación de errores. Siempre que se ejecute un plan de prueba contra cualquiera de los productos que tenemos y tan pronto como se identifique un error en particular o se identifique un defecto, ese defecto debe informarse al desarrollador o asignarse al desarrollador.
Para que el desarrollador pueda investigarlo y comenzar a trabajar en él. Como tester, necesitamos rastrear el progreso del error y rastrear si el error se ha corregido. Si el error se ha solucionado como se informó, entonces debemos seguir adelante y volver a probarlo y verificar si está resuelto.
Una vez que todos los errores estén corregidos, cerrados y verificados, debemos seguir adelante y entregar un producto probado OKAY. Pero antes de entregar el producto, debemos asegurarnos de que la UAT (Prueba de aceptación del usuario) se complete con éxito.
Nos aseguramos de que las pruebas de instalación y la verificación de requisitos se realicen correctamente, es decir, el producto que se entrega al cliente o al usuario final cumple con el requisito que se menciona en el Documento de requisitos de software.
Los pasos que hemos discutido se basan en la imaginación, ya sea cualquiera de los escenarios de prueba o cualquiera de los enfoques de prueba que vamos a utilizar para esos pasos o decir esas frases para probar nuestro producto y entregar el resultado final, que es un OKAY Producto probado.
Sigamos adelante y analicemos esto en detalle y correlacionemos con las pruebas de Hadoop.
Sabemos que Hadoop es algo que se usa para el procesamiento por lotes y también sabemos que ETL es uno de los campos donde Hadoop se usa mucho. ETL son las siglas de extracción, transformación y carga . Discutiremos estos procesos en detalle cuando analicemos el plan de prueba y la estrategia de prueba como un punto de vista de prueba de Hadoop.
Según el diagrama que se menciona a continuación, solo asumimos que tenemos cuatro fuentes de datos diferentes. Sistema operativo, CRM ( Gestión de relaciones con el cliente ) y ERP ( Planificación de recursos empresariales ) es el RDBMS o, por ejemplo, el Sistema de gestión de bases de datos relacionales que tenemos y también tenemos algunos archivos planos que pueden ser registros, archivos, registros o lo que sea en cuanto a nuestras fuentes de datos.
Podríamos estar usando Sqoop o Flume o cualquier producto en particular para obtener los datos, registros o lo que sea como mis fuentes de datos. Podemos utilizar estas herramientas para obtener los datos de las fuentes de datos en mi directorio de preparación, que es la primera fase de nuestro proceso llamado Extracción.
Una vez que los datos en el directorio de ensayo que en realidad es HDFS (sistema de archivos de distribución de Hadoop), utilizaremos particularmente el lenguaje de secuencias de comandos como PIG para Transformar esos datos. Ese Transformación será de acuerdo a los Datos que tengamos.
Una vez que los datos se transformen en consecuencia utilizando cualquier tecnología de scripting que tengamos, estaremos Cargando esos datos en el almacén de datos. Desde el almacén de datos, esos datos se utilizarán para análisis OLAP, informes y minería de datos o para análisis.
Sigamos adelante y analicemos qué fases podemos usar para las pruebas de Hadoop.
La primera fase será la fase de extracción. Aquí, vamos a obtener los datos de nuestras bases de datos de origen o de archivos planos, y en ese caso, lo que podemos hacer es verificar que todos los datos se hayan copiado correctamente y con éxito desde el origen al directorio de ensayo.
Puede incluir, verificar el número de Registros, el tipo de Registros y el tipo de Campos, etc.
Una vez que estos datos se copian en el directorio de ensayo, continuaremos y activaremos la segunda fase, que es la transformación. Aquí, tendremos alguna lógica de negocios que actuará sobre los datos copiados de los sistemas de origen y realmente creará o transformará los datos en la lógica de negocios requerida.
La transformación puede incluir ordenar los datos, filtrar los datos, unir los datos de dos fuentes de datos diferentes y algunas otras operaciones.
Una vez que los datos se transforman, seguiremos adelante y tendremos planes de prueba listos y verificaremos si estamos obteniendo la salida como se esperaba, y si toda la salida que estamos obteniendo cumple con el resultado esperado y los tipos de datos, valores de campo y los rangos, etc. son algo que está cayendo en su lugar.
Una vez que sea correcto, podemos continuar y cargar los datos en Data Warehouse.
En la fase de carga, en realidad estamos verificando si el número de registros del escenario y el número de registros en el almacén de datos están sincronizados, es posible que no sean similares, pero se supone que están sincronizados. También vemos si el tipo de datos que se ha transformado está sincronizado.
Publica que usaremos estos Datos para Análisis OLAP, Reportes y Minería de Datos que es la última capa de nuestro producto y en ese caso, podemos tener posteriores o podemos decir que los Planes de Prueba disponibles para todas estas capas.
Siempre que recibamos algunos datos de la fuente en el destino, siempre debemos asegurarnos de que solo las personas autenticadas tengan acceso autorizado a los datos.
Autenticación
Autorización
¿Qué queremos decir con ambos términos?
Para entender esto, veamos las cosas en perspectiva desde el diagrama ETL.
Según el diagrama anterior, estamos obteniendo nuestros datos de los motores RDBMS de origen y de los archivos planos en HDFS, y esa fase se llama Extracción.
Analicemos la autenticación de una manera particular, hay ciertas empresas que tienen datos que están restringidos por su naturaleza, este tipo de datos se denomina datos de identificación personal según los estándares de los Estados Unidos.
PII representa Información de identificación personal, cualquier información como la fecha de nacimiento, el número de seguro social, el número de teléfono móvil, la dirección de correo electrónico y la dirección de la casa, etc., se incluyen en la PII. Esto está restringido y no se puede compartir con todos.
Los Datos deben compartirse solo con las personas que más los necesitan y con aquellos que los necesitan para su procesamiento real. Tener esta verificación y la primera línea de defensa en su lugar se llama Autenticación.
Por ejemplo, estamos usando una computadora portátil y tenemos Windows instalado allí, podríamos tener alguna cuenta de usuario creada en nuestro sistema operativo Windows y allí estábamos aplicando una contraseña.
De esta manera, solo la persona que tiene las Credenciales para esta cuenta de usuario en particular puede iniciar sesión en el Sistema y así es como vamos a proteger nuestros Datos del robo o acceso innecesario. La otra capa es Autorización.
Ejemplo, tenemos dos cuentas de usuario diferentes en nuestro sistema operativo Windows, una cuenta de usuario es la nuestra y otra puede ser la cuenta de usuario invitado. El administrador (NOSOTROS) tiene derecho a realizar todo tipo de operaciones, como instalación y desinstalación del software, Creación de un nuevo archivo y Eliminación de archivos existentes, etc.
Mientras que, por otro lado, los usuarios invitados pueden no tener todo este tipo de acceso. El invitado tiene autenticación para iniciar sesión en el sistema, pero no tiene la autoridad para eliminar o crear los archivos y la instalación, así como la desinstalación de cualquier software en el sistema y del sistema, respectivamente.
Sin embargo, la cuenta de usuario invitado debido a que está autenticada tiene derecho a leer los archivos que se crean y utilizar el software que ya está instalado.
Así es como se prueban la Autenticación y Autorización, en este caso, cualquier Dato disponible en HDFS o cualquiera de los sistemas de archivos que necesitemos verificar para la Autenticación y Autorización de Datos.
Enfoque de prueba para las pruebas de Hadoop / BigData Testing
El enfoque de prueba es común para todo tipo de pruebas, no solo porque se trata de pruebas de BigData o Hadoop cuando pasamos a pruebas manuales normales o pruebas de automatización o pruebas de seguridad, también pruebas de rendimiento, por lo que cualquier tipo de prueba sigue el mismo enfoque.
Requisitos
Como parte del enfoque de prueba, debemos comenzar con el Requisitos El requisito es una cosa básica, hoy en día en el proceso Agile lo llamamos Stories y Epics. Epic no es más que un requisito mayor, mientras que las Historias son requisitos más pequeños.
El requisito básicamente contiene cuáles son todos los modelos de datos, objetivos, fuentes, así como qué tipo de transformaciones necesitamos aplicar, qué tipo de herramientas tenemos que utilizar. Todos estos tipos de detalles estarán disponibles en los Requisitos.
Este es básicamente el requisito del cliente o los requisitos del cliente. Con base en este requisito, comenzaremos nuestro proceso de prueba.
Estimacion
Otra parte de un enfoque es Estimacion , Cuánto tiempo debemos tomar para que toda la actividad se realice como parte de la prueba. Hacemos Planificación de Pruebas, preparación de Escenarios de Prueba, preparación de Casos de Prueba y Ejecución de los mismos, así como encontraremos defectos y reportarlos y preparar Reportes de Pruebas.
Todas estas actividades tomarán algún tiempo, entonces, cuánto tiempo necesitamos para completar todas estas actividades y esto se llama básicamente una estimación. Necesitamos dar una estimación aproximada a la gerencia.
Planificación de pruebas
Planificación de pruebas no es más que la descripción de los procesos, qué probar, qué no probar, cuál es el alcance de las pruebas, cuáles son los horarios, cuántos recursos se requieren, requisitos de hardware y software y cuáles son los plazos, así como los ciclos de prueba. se utilizará, cuáles son los niveles de prueba que requerimos, etc.
Durante la planificación de la prueba, harán cierta asignación de recursos al proyecto y cuáles son los diferentes modelos que tenemos, cuántos recursos se requieren y qué tipo de conjuntos de habilidades se requieren, etc.Todas estas cosas y aspectos se incluirán en la prueba. Fase de planeamiento.
La mayoría de las veces, las personas del nivel de liderazgo o del nivel de gestión harán la planificación de la prueba.
Escenarios de prueba y casos de prueba
Una vez que hayamos terminado con la planificación de la prueba, debemos prepararnos Escenarios de prueba y casos de prueba , especialmente para Big Data Testing, necesitamos algunos documentos junto con el documento de requisitos. Junto con este documento de requisitos, ¿qué necesitamos todos?
Necesitamos el Documento de requisitos que contiene las necesidades del Cliente, junto con esto necesitamos el Documento de entrada es decir Modelos de datos. Modelo de datos en el sentido de qué son los esquemas de bases de datos, qué son las tablas y cuáles son las relaciones, todos estos datos estarán disponibles en los modelos de datos.
Además, tenemos el Mapeo de documentos , Mapeo de documentos para P.ej. en las bases de datos relacionales tenemos algunas tablas y después de cargar los datos a través de ETL en el almacén de datos en HDFS, ¿qué mapeo necesitamos hacer? es decir, mapeo del tipo de datos.
el mejor software espía para teléfonos móviles Android
Por ejemplo, si tenemos una tabla del cliente en HDFS, entonces en HDFS tenemos una tabla CUSTOMER_TARGET o la misma tabla también puede estar en HIVE.
En esta Tabla de clientes, tenemos ciertas columnas y en la Tabla de OBJETIVOS DEL CLIENTE, tenemos ciertas columnas como se muestra en el diagrama. Volcamos los datos de la tabla de clientes a la tabla de OBJETIVO DEL CLIENTE, es decir, de origen a destino.
Luego, debemos verificar el mapeo exacto como los Datos presentes en la Tabla de origen, que es la Columna 1 y la Fila 1 de la Tabla de clientes y la consideramos como C1R1 y los mismos Datos deben mapearse en C1R1 de la Tabla OBJETIVO DEL CLIENTE. Básicamente, esto se llama Mapeo.
¿Cómo sabremos cuáles son todas las asignaciones que necesitamos verificar? Por tanto, estas asignaciones estarán presentes en el documento de asignación. En el Documento de Mapeo, el Cliente dará todo tipo de Mapeos.
Además, hemos requerido un Documento de diseño , Documento de Diseño requerido tanto para el Equipo de Desarrollo como para el Equipo de QA, porque en el Documento de Diseño el Cliente proporcionará, qué tipo de Trabajos de MapReduce van a implementar y qué tipo de Trabajos de MapReduce toma Entradas y qué tipo de MapReduce Jobs da salidas.
De manera similar, si tenemos HIVE o PIG, cuáles son todas las UDF que el Cliente ha creado, así como cuáles son todas las entradas que tomarán y qué tipo de salida producirán, etc.
Para preparar escenarios de prueba y casos de prueba, necesitamos tener todos estos documentos a mano:
- Documento de requisitos
- Modelo de datos
- Documento de mapeo
- Documento de diseño
Estos pueden variar de una organización a otra, y no existe una regla obligatoria de que debamos tener todos estos documentos. A veces tenemos todos los documentos y, a veces, solo tenemos dos o tres documentos o, a veces, también necesitamos confiar en un documento, que depende de la complejidad del proyecto, los horarios de la empresa y todo.
Reseñas sobre escenarios de prueba y casos de prueba
Necesitamos realizar una revisión de los escenarios de prueba y los casos de prueba porque de alguna manera o en algunos casos olvidamos o perdemos algunos casos de prueba porque todos no pueden pensar en todas las cosas posibles que se pueden hacer con los requisitos, en tales condiciones debemos tomar ayuda de herramientas de terceros o de otra persona.
Entonces, cada vez que preparamos algunos documentos o realizamos algo, necesitamos que alguien revise el material del mismo equipo, como desarrolladores, probadores. Darán sugerencias adecuadas para incluir algo más o también sugerirán actualizar o modificar los escenarios de prueba y los casos de prueba.
Proporcionan todos los comentarios y, en base a esto, actualizaremos nuestros Escenarios de prueba y Casos de prueba y varias versiones del documento que necesitamos publicar en todo el equipo hasta que el documento esté completamente actualizado según el requisito.
Ejecución de pruebas
Una vez que el documento esté listo, obtendremos la aprobación del equipo superior para iniciar el proceso de ejecución que básicamente se llama Ejecución de casos de prueba.
Si queremos ejecutar nuestros Casos de Prueba durante la ejecución, debemos verificar que el Desarrollador tiene que enviar la información, si es una Prueba Funcional normal o alguna otra prueba o Prueba de Automatización requerimos una Compilación. Pero, aquí desde el punto de vista de las pruebas de Hadoop o BigData, el desarrollador proporcionará trabajos de MapReduce.
Archivos HDFS: todos los archivos que se copian en HDFS, la información de esos archivos es necesaria para verificar los privilegios, los scripts HIVE que fueron creados por los desarrolladores para verificar los datos en la tabla HIVE y también necesitamos los UDF HIVE que fueron desarrollados por los desarrolladores, PIG Scripts y PIG UDF.
Estas son todas las cosas que necesitamos obtener de los desarrolladores. Antes de ir a la ejecución deberíamos tener todas estas cosas.
Para los trabajos de MapReduce, proporcionarán algunos archivos JAR y, como parte del HDFS, ya han cargado los datos en HDFS y los archivos deben estar listos y los scripts HIVE para validar los datos en las tablas HIVE. Cualesquiera que sean las UDF que hayan implementado, estarán disponibles en las UDF de HIVE. También requerimos lo mismo para los scripts PIG y UDF.
Informes y seguimiento de defectos
Una vez que ejecutamos nuestros casos de prueba, encontramos algunos defectos, algunos esperados y algunos reales no son iguales a los resultados esperados, por lo que debemos enumerar los mismos y proporcionárselos al equipo de desarrollo para su resolución, y esto básicamente se llama Informe de defectos.
Supongamos que si encontramos algún defecto en el trabajo de MapReduce, entonces se lo informaremos al desarrollador y ellos volverán a crear el trabajo de MapReduce y harán algunas modificaciones a nivel de código y luego proporcionarán el último trabajo de MapReduce, que debemos probar. .
Este es un proceso continuo, una vez que el trabajo se prueba y se aprueba, nuevamente necesitamos volver a probarlo e informarlo al Desarrollador y luego obtener el siguiente para probarlo. Así es como se lleva a cabo la actividad de Informes y seguimiento de defectos.
Informes de las pruebas
Una vez que hayamos terminado con todo el proceso de prueba y se hayan cerrado los defectos, debemos crear nuestros informes de prueba. Los informes de prueba son todo lo que hemos hecho para completar el proceso de prueba hasta ahora. Toda la planificación, redacción y ejecución de casos de prueba, qué resultados obtuvimos, etc., todo se documenta en conjunto en forma de informes de prueba.
Necesitamos enviar estos informes diariamente o semanalmente o según las necesidades del Cliente. Hoy en día, las organizaciones están utilizando el modelo AGILE, por lo que cada informe de estado debe actualizarse durante los Scrums diarios.
Conclusión
En este tutorial, analizamos:
- La estrategia o plan de prueba de BigData.
- Entorno necesario para las pruebas de BigData.
- Validación y Verificaciones de BigData.
- Herramientas utilizadas para probar BigData.
También aprendimos sobre -
- Cómo funcionan la estrategia de prueba, el desarrollo de prueba, las ejecuciones de prueba, la gestión de defectos y la entrega en los roles y responsabilidades como parte de Hadoop Testing.
- Enfoque de prueba para pruebas de Hadoop / BigData que incluye recopilación de requisitos, estimación, planificación de pruebas, creación de escenarios de prueba y casos de prueba junto con las revisiones.
- También llegamos a conocer sobre ejecución de pruebas, informes y seguimiento de defectos e informes de pruebas.
¡Esperamos que este tutorial de pruebas de BigData le haya resultado útil!
=> Consulte TODOS los tutoriales de BigData aquí.
Lectura recomendada
- Tutorial de prueba de volumen: ejemplos y herramientas de prueba de volumen
- Cómo realizar pruebas basadas en datos en SoapUI Pro - Tutorial de SoapUI n. ° 14
- Tutorial de pruebas de almacenamiento de datos con ejemplos | Guía de prueba ETL
- Descarga del libro electrónico Testing Primer
- Tutorial de pruebas de almacenamiento de datos de pruebas ETL (una guía completa)
- ¿Qué es Hadoop? Tutorial de Apache Hadoop para principiantes
- Tutorial de pruebas destructivas y no destructivas
- Pruebas funcionales versus pruebas no funcionales