Menu

Tutorial de teste abrangente do Hadoop | Guia de teste de Big Data

  • Principal
  • Outro
  • Tutorial de teste abrangente do Hadoop | Guia de teste de Big Data

comprehensive hadoop testing tutorial big data testing guide

Experimente Nosso Instrumento Para Eliminar Problemas

Este tutorial explica os fundamentos, tipos de teste, planos, ambiente necessário, processo de teste, validação e verificações para teste de Hadoop e BigData:

Neste tutorial, veremos a introdução básica ao teste Hadoop e BigData, como quando e onde o teste entrará em cena e o que precisamos testar como parte do teste Hadoop.

Também discutiremos os seguintes tópicos em detalhes:

  • Funções e responsabilidades do teste Hadoop
  • Abordagem de teste para teste Hadoop / BigData

=> Verifique aqui para ver A-Z dos tutoriais de treinamento BigData aqui.

Introdução aos testes de BigData e Hadoop

O que você aprenderá:

Armazenamento e processamento de dados no Hadoop

Para realizar esses processos no sistema Hadoop, temos a mão de obra que é categorizada em quatro seções.

  • Administradores Hadoop são responsáveis ​​por configurar o ambiente e têm direitos de administração para acessar os sistemas Hadoop.
  • Hadoop Developers desenvolver os programas relativos à extração, armazenamento e processamento de dados de diferentes locais para locais centralizados.
  • Testadores Hadoop para validar e verificar os dados antes de extrair de locais diferentes e depois de extrair no local centralizado, bem como a validação e verificação é feita durante o carregamento dos dados para o ambiente do cliente.
  • Analistas Hadoop operar quando o carregamento de dados é concluído e quando os dados chegam ao armazém no local do cliente. Eles usam esses dados para geração de relatórios e painéis. Os analistas realizam a análise de dados para crescimento e desenvolvimento de negócios.

Sabemos que o Hadoop não é um sistema único; ele contém vários sistemas e máquinas. Os dados são divididos e armazenados em várias máquinas e, se quisermos acessá-los novamente, precisamos combinar e extrair os dados em relatórios e assim por diante.

O desenvolvedor é responsável por escrever programas em JAVA e Python para extrair os dados e armazená-los.

O outro trabalho de um desenvolvedor é processar os dados. Existem duas camadas de Hadoop, uma é para armazenamento, ou seja, Hadoop HDFS, e outra para processamento, ou seja, Hadoop MapReduce.

Armazenar significa que todos os dados que temos na fonte são armazenados / inseridos no sistema. O processamento significa que precisamos dividi-lo em várias máquinas e, novamente, combiná-lo e enviá-lo ao cliente.

Assim, o Armazenamento e o Processamento são feitos por scripts de programação, sendo o desenvolvedor responsável por escrever os scripts.

Além da programação, o outro método para armazenar e processar os dados no Hadoop é usar aplicativos de banco de dados como Hive, Impala, HBase, etc. Essas ferramentas não precisam de nenhum conhecimento de programação.

Teste de BigData e Hadoop

Uma vez que o armazenamento e o processamento são feitos pelo desenvolvedor, os dados vão para a geração do relatório. Antes disso, precisamos verificar a precisão dos dados processados ​​e verificar se os dados foram carregados com precisão e processados ​​corretamente ou não.

Portanto, o programa e / ou scripts criados por um desenvolvedor precisam ser verificados pelo Hadoop ou BigData Tester. O testador precisa saber programação básica como Mapper, Hive, Pig Scripts, etc. para verificar os scripts e executar os comandos.

Portanto, antes de testar, os testadores precisam saber o que todos os programas e scripts estão funcionando, como escrever o código e então pensar em como testá-los. O teste pode ser feito manualmente ou usando ferramentas de automação.

O Hadoop tem vários tipos de teste, como Teste de Unidade, Teste de Regressão, Teste de Sistema e Teste de Desempenho, etc. Portanto, esses são os tipos de teste comuns que usamos em nossos testes normais, bem como testes Hadoop e BigData.

Temos o mesmo tipo de terminologia de teste, como estratégia de teste, cenários de teste e casos de teste, etc. em Hadoop e BigData Testing. Apenas o ambiente é diferente e existem diferentes tipos de técnicas que usamos para testar o BigData e o Hadoop System porque aqui precisamos testar os dados e não o aplicativo.

Como testar o BigData e o que todas as coisas exigem teste no BigData?

Para o teste de BigData, precisamos ter alguns planos e estratégias.

Portanto, precisamos considerar os seguintes pontos:

  • Qual é a estratégia ou plano de teste para o BigData?
  • Que tipo de abordagem de teste é aplicada ao BigData?
  • Qual é o ambiente necessário?
  • Como validar e verificar o BigData?
  • Quais são as ferramentas usadas no BigData Testing?

Vamos tentar obter as respostas para todas as perguntas acima.

Qual é a estratégia ou plano para testar BigData?

Teste de BigData significa Verificação e Validação de dados ao armazená-los e processá-los no Data Warehouse.

Ao testar BigData, precisamos testar o Volume e a Variedade de dados extraídos de diferentes bancos de dados e carregados, bem como processados ​​no Data Warehouse ou Hadoop System, este teste passa por um teste funcional.

Precisamos testar a velocidade dos dados baixados de vários bancos de dados e carregados no sistema Hadoop, que faz parte do teste de desempenho.

Portanto, como um plano ou estratégia, precisamos nos concentrar nos testes funcionais e também nos testes de desempenho de BigData.

No BigData Testing, o testador deve verificar o processamento de uma grande quantidade de dados usando o Hardware Commodity e componentes relativos. Portanto, a qualidade dos dados também desempenha um papel importante no teste de BigData. É essencial verificar e validar a qualidade dos dados.

Tipos de teste para teste de BigData

Na seção anterior, vimos que o Teste Funcional e o Teste de Desempenho desempenham um papel vital no Teste de BigData. Além disso, como um testador de BigData, precisamos fazer mais alguns tipos de teste, como Teste de Banco de Dados e Teste de Arquitetura.

Esses tipos de teste também são tão importantes quanto o Teste Funcional e de Desempenho.

# 1) Teste de arquitetura

Esse teste é feito para garantir que o processamento dos dados seja adequado e atenda aos requisitos. Na verdade, o sistema Hadoop processa grandes volumes de dados e é altamente abrangente em recursos.

Se a arquitetura for inadequada, ela pode degradar o desempenho devido ao qual o processamento de dados pode ser interrompido e pode ocorrer perda de dados.

# 2) Teste de banco de dados

Aqui, a validação do processo entra em cena e precisamos validar os dados de vários bancos de dados, ou seja, precisamos garantir que os dados buscados nos bancos de dados de origem ou locais devem estar corretos e adequados.

Além disso, precisamos verificar se os dados disponíveis nos bancos de dados de origem correspondem aos dados inseridos no Hadoop System.

Teste de banco de dados

Da mesma forma, precisamos validar se os dados no Sistema Hadoop estão corretos e adequados após o processamento ou digamos após a transformação e serem carregados no ambiente do cliente com validação e verificação adequadas.

Como parte do teste de banco de dados, precisamos passar pelo CRUEL operações, ou seja, Crio os dados em bancos de dados locais, então Recuperar os dados e precisamos pesquisá-los e devem estar disponíveis no banco de dados antes e depois do carregamento no data warehouse e do data warehouse para o ambiente do cliente.

Verificação de qualquer Atualizada Dados em todas as fases de armazenamento ou carregamento e processamento de dados. Exclusão de quaisquer dados corrompidos ou duplicados e dados nulos.

# 3) Teste de desempenho

Como parte do teste de desempenho, precisamos verificar a velocidade de carregamento e processamento dos dados, por exemplo, IOPS (entrada e saída por segundo).

É necessário verificar a velocidade de entrada dos dados ou dados como uma entrada de vários bancos de dados para data warehouse ou sistema Hadoop e do sistema Hadoop ou data warehouse para o ambiente do cliente.

Também deve verificar a velocidade dos dados vindos de vários bancos de dados e do data warehouse como uma saída. Isso é o que chamamos de entrada e saída por segundo ou IOPS.

Além disso, outro aspecto é verificar o desempenho da Absorção de Dados e Distribuição de Dados, e quão rápido os dados são consumidos pelo Data Warehouse de vários Bancos de Dados e pelo Sistema do Cliente do Sistema Hadoop.

Também como Testador, precisamos verificar o desempenho da Distribuição de Dados como, a rapidez com que os dados são distribuídos para vários arquivos disponíveis no Sistema Hadoop ou no Data Warehouse. Da mesma forma, o mesmo processo acontece durante a distribuição de dados para sistemas clientes.

O sistema Hadoop ou o data warehouse consiste em vários componentes, portanto, um testador precisa verificar o desempenho de todos esses componentes, como os trabalhos de MapReduce, inserção e consumo de dados, o tempo de resposta de consultas e seu desempenho, bem como o desempenho da pesquisa operações. Todos estes estão incluídos no Teste de Desempenho.

# 4) Teste Funcional

O Teste Funcional contém o teste de todos os subcomponentes, programas e scripts, ferramentas usadas para realizar as operações de Armazenamento ou Carregamento e Processamento, etc.

Para um testador, esses são os quatro tipos e estágios importantes pelos quais os dados precisam ser filtrados para que o cliente obtenha os dados perfeitos e sem erros.

Ferramentas para teste de BigData Hadoop

Existem várias ferramentas que são usadas para testar BigData:

  • Sistema de arquivos de distribuição HDFS Hadoop para armazenamento de BigData.
  • Redução de mapa HDFS para processamento de BigData.
  • Para NoSQL ou HQL Cassandra DB, ZooKeeper e HBase, etc.
  • Ferramentas de servidor baseadas em nuvem como EC2.

Ambientes de teste e configurações

Para qualquer tipo de teste, o Testador precisa de configurações e ambiente adequados.

A seguir está a lista de requisitos:

  1. Tipo de dado e aplicativo que será testado.
  2. O armazenamento e o processamento requerem um grande espaço para uma grande quantidade de dados.
  3. Distribuição adequada de arquivos em todos os DataNodes gerais do cluster.
  4. Durante o processamento dos dados, a utilização do hardware deve ser mínima.
  5. Programas e scripts executáveis ​​de acordo com os requisitos do aplicativo.

Funções e responsabilidades do teste Hadoop

Como um Hadoop Tester, somos responsáveis ​​por entender os requisitos, preparar as estimativas de teste, planejamento dos casos de teste, obter alguns dados de teste para testar alguns casos de teste, estar envolvidos na criação da bancada de teste, executar os planos de teste, relatar e retestar defeitos.

Além disso, precisamos ser responsáveis ​​pelo Relatório de Status Diário e Conclusão do Teste.

Funções e responsabilidades do teste Hadoop

A primeira coisa que vamos discutir é o Estratégia de Teste . Assim que tivermos uma solução proposta para o nosso problema, precisamos ir em frente e planejar ou criar uma estratégia de nosso plano de teste, podemos discutir a estratégia de automação que podemos usar lá, o plano sobre o cronograma de teste que depende de nossas datas de entrega, também nós pode discutir o planejamento de recursos.

A estratégia de automação é algo que vai nos ajudar a reduzir os esforços manuais necessários para testar o produto. O Cronograma de Teste é importante, pois irá garantir a entrega oportuna do produto.

O planejamento de recursos será crucial, pois precisamos planejar quantas horas de trabalho precisamos em nossos testes e quantos recursos Hadoop são necessários para executar nosso planejamento de teste.

Uma vez que traçamos nossa estratégia de teste, precisamos ir em frente e criar os Planos de Desenvolvimento de Teste que incluem a Criação de Planos de Teste, Criação de Scripts de Teste que nos ajudarão a automatizar nossos testes e também identificar alguns Dados de Teste que serão usados ​​nos Planos de Teste e nos ajuda a executar esses Planos de Teste.

Assim que terminarmos com o Desenvolvimento de Teste que inclui a Criação de Planos de Teste, Scripts de Teste e Dados de Teste, vamos em frente e começamos a executar esses Planos de Teste.

Quando executamos os Planos de Teste, pode haver certos cenários em que a saída real não é a esperada e essas coisas são chamadas de defeitos. Sempre que houver um defeito, precisamos testar esses defeitos também e precisamos criar e manter as matrizes para eles.

Todas essas coisas se enquadram na próxima categoria que é Gestão de Defeitos .

O que é gerenciamento de defeitos?

O gerenciamento de defeitos consiste em rastreamento de bug, correção de bugs e verificação de bug. Sempre que um Plano de Teste é executado em qualquer um dos produtos que temos e assim que um bug específico é identificado ou um defeito é identificado, então esse defeito precisa ser relatado ao desenvolvedor ou atribuído ao desenvolvedor.

Assim, o desenvolvedor pode analisá-lo e começar a trabalhar nele. Como um testador, precisamos acompanhar o progresso do Bug e verificar se o Bug foi corrigido. Se o bug foi corrigido conforme relatado, precisamos prosseguir, testá-lo novamente e verificar se foi resolvido.

Uma vez que todos os bugs tenham sido corrigidos, fechados e verificados, precisamos prosseguir e entregar um produto testado OKAY. Mas antes de entregarmos o produto, devemos ter certeza de que o UAT (Teste de Aceitação do Usuário) foi concluído com sucesso.

Certificamo-nos de que o teste de instalação e a verificação dos requisitos são feitos corretamente, ou seja, o produto que é entregue ao cliente ou usuário final está de acordo com os requisitos mencionados no Documento de Requisitos de Software.

As etapas que discutimos são baseadas na imaginação, seja qualquer um dos cenários de teste ou qualquer uma das abordagens de teste que vamos usar para essas etapas ou diga essas frases para testar nosso produto e entregar o resultado final, que é um OKAY Produto testado.

Vamos prosseguir e discutir isso em detalhes e correlacioná-lo com o teste do Hadoop.

Sabemos que Hadoop é algo que é usado para processamento em lote e também sabemos que ETL é um dos campos onde o Hadoop é muito usado. ETL significa Extraction Transformation and Loading . Discutiremos esses processos em detalhes quando discutirmos o plano de teste e a estratégia de teste como um ponto de vista de teste do Hadoop.

De acordo com o diagrama mencionado abaixo, simplesmente assumimos que temos quatro fontes de dados diferentes. Sistema Operacional, CRM ( Gestão de Relacionamento com o Cliente ) e ERP ( Planejamento de Recursos Empresariais ) é o RDBMS ou, digamos, o Relational DataBase Management System que temos e também temos alguns arquivos planos que podem ser logs, arquivos, registros ou o que quer que seja quanto às nossas fontes de dados.

Podemos estar usando Sqoop ou Flume ou qualquer produto específico para obter os dados, registros ou qualquer outra coisa como minhas fontes de dados. Podemos usar essas ferramentas para obter os dados das fontes de dados em meu diretório de teste, que é a primeira fase do nosso processo chamado Extração.

Uma vez que os dados contidos no diretório temporário, que na verdade são HDFS (Hadoop Distribution File System), usaremos particularmente a linguagem de script, como PIG para Transformar esses dados. Que Transformação será de acordo com os Dados que temos.

Assim que os dados forem transformados de acordo com qualquer tecnologia de script de que dispomos, estaremos Carregando esses dados para o data warehouse. A partir do Data Warehouse, esses dados serão usados ​​para Análise OLAP, Relatórios e Mineração de Dados ou para Análise.

Vamos prosseguir e discutir quais fases podemos usar para o teste do Hadoop.

A primeira fase será a fase de extração. Aqui, vamos obter os dados de nossos bancos de dados de origem ou de arquivos simples e, nesse caso, o que podemos fazer é verificar se todos os dados foram copiados com sucesso e corretamente da origem para o diretório temporário.

Pode incluir, verificar o número de Registros, o tipo de Registros e o tipo de Campos, etc.

Depois que esses dados forem copiados para o Diretório de teste, seguiremos em frente e acionaremos a segunda fase, que é a transformação. Aqui, teremos alguma lógica de negócios que atuará nos dados copiados dos sistemas de origem e realmente criará ou transformará os dados na lógica de negócios necessária.

A transformação pode incluir classificar os dados, filtrar os dados, juntar os dados de duas fontes de dados diferentes e algumas outras operações.

Assim que os dados forem transformados, seguiremos em frente e teremos planos de teste prontos e verificaremos se estamos obtendo a saída conforme o esperado e se todas as saídas que estamos obtendo estão atendendo ao resultado esperado e os tipos de dados, valores de campo e os intervalos, etc. são algo que está caindo no lugar.

Assim que estiver correto, podemos prosseguir e carregar os dados no Data Warehouse.

Na fase de carregamento, estamos verificando se o número de registros do Palco e o número de registros no Data Warehouse estão sincronizados. Eles podem não ser semelhantes, mas devem estar sincronizados. Também vemos se o tipo de dado que foi transformado está sincronizado.

Poste que usaremos esses Dados para Análise OLAP, Relatórios e Mineração de Dados que é a última camada do nosso produto e nesse caso, podemos ter subsequentes ou podemos dizer que os Planos de Teste disponíveis para todas essas camadas.

Sempre que obtemos alguns Dados da Fonte para o destino, sempre precisamos nos certificar de que apenas Pessoas Autenticadas tenham acesso autorizado aos Dados.

Autenticação

Autenticação

Autorização

Autorização

O que queremos dizer com esses dois termos?

Para entender isso, vamos colocar as coisas em perspectiva no Diagrama ETL.

ETL

Conforme o diagrama acima, estamos obtendo nossos dados dos motores RDBMS de origem e dos arquivos simples para o HDFS, e essa fase é chamada de Extração.

Vamos discutir a autenticação de uma maneira particular, existem certas empresas que possuem Dados que são restritos por sua natureza, este tipo de Dados é chamado de Dados PII de acordo com os padrões dos Estados Unidos.

PII apoia Informações de identificação pessoal, quaisquer informações como data de nascimento, SSN, número de celular, endereço de e-mail e endereço residencial, etc., todas se enquadram em PII. Isso é restrito e não pode ser compartilhado com todos.

Os dados devem ser compartilhados apenas com as pessoas que mais precisam deles e com aquelas que precisam dos dados para o processamento real. Ter essa verificação e a primeira linha de defesa em vigor é chamada de autenticação.

Por exemplo, estamos usando um laptop e temos o Windows instalado nele, podemos ter alguma conta de usuário criada em nosso sistema operacional Windows e lá estávamos aplicando uma senha.

Desta forma, apenas a pessoa que possui as Credenciais para esta conta de usuário em particular pode fazer login no Sistema e é assim que iremos proteger nossos Dados contra roubo ou acesso desnecessário. A outra camada é a Autorização.

Exemplo, temos duas contas de usuário diferentes em nosso sistema operacional Windows, uma conta de usuário é nossa e outra pode ser a conta de usuário convidado. O administrador (WE) tem o direito de realizar todos os tipos de operações, como instalação e desinstalação do software, criação de novo arquivo e exclusão de arquivos existentes, etc.

Por outro lado, os usuários convidados podem não ter todo esse tipo de acesso. O convidado tem autenticação para fazer login no sistema, mas não tem autoridade para excluir ou criar os arquivos e instalação, bem como desinstalação de qualquer software no sistema e do sistema, respectivamente.

No entanto, a conta de usuário convidado, por ser autenticada, tem o direito de ler os arquivos criados e usar o software já instalado.

É assim que se testam a Autenticação e a Autorização, neste caso, quaisquer Dados disponíveis no HDFS ou em qualquer um dos sistemas de arquivos que necessitemos verificar para a Autenticação e Autorização de Dados.

Abordagem de teste para Hadoop Testing / BigData Testing

Abordagem de Teste

A Abordagem de Teste é comum para todos os tipos de teste, não apenas porque é BigData ou Teste Hadoop quando vamos para o Teste Manual Normal ou Teste de Automação ou Teste de Segurança, Teste de Desempenho também, portanto, qualquer tipo de Teste segue a mesma abordagem.

Requisitos

Como parte da abordagem de teste, precisamos começar com o Requisitos , Requisito é uma coisa básica, hoje em dia no processo Ágil, chamamos de Histórias e Epopeias. Epic nada mais é do que um requisito maior, enquanto as histórias são requisitos menores.

Requisito basicamente contém o que são todos os Modelos de Dados, Alvos, Fontes, bem como que tipo de Transformações precisamos aplicar, que tipo de ferramentas temos que usar? Todos esses tipos de detalhes estarão disponíveis nos Requisitos.

Este é basicamente o Requisito do Cliente ou Requisitos do Cliente. Com base neste requisito, iniciaremos nosso processo de teste.

Estimativa

Outra parte de uma abordagem é Estimativa , Quanto tempo precisamos levar para que toda a atividade seja realizada como parte do Teste. Fazemos o Planejamento de Testes, preparando os Cenários de Teste, preparação de Casos de Teste e Execução dos mesmos assim como vamos encontrar defeitos e reportá-los e preparar Relatórios de Teste também.

Todas essas atividades levarão algum tempo, portanto, quanto tempo precisamos para concluir todas essas atividades e isso é basicamente chamado de Estimativa. Precisamos dar uma estimativa aproximada para a gestão.

Planejamento de Teste

Planejamento de Teste nada mais é do que a descrição dos processos, o que testar, o que não testar, qual é o escopo do teste, quais são os cronogramas, quantos recursos são necessários, requisitos de hardware e software e quais são os cronogramas, bem como os ciclos de teste serão usados, quais são os níveis de teste que exigimos, etc.

Durante o planejamento de teste, eles farão certa Alocação de recursos para o projeto e quais são os diferentes modelos que temos, quantos recursos são necessários e que tipo de conjuntos de habilidades são necessários, etc. todas essas coisas e aspectos serão incluídos no teste Fase de planejamento.

Na maioria das vezes, o pessoal de nível de liderança ou de gerenciamento fará o Planejamento de Teste.

Cenários de teste e casos de teste

Assim que terminarmos com o planejamento de teste, precisamos nos preparar Cenários de teste e casos de teste , especialmente para teste de Big Data, exigimos alguns documentos junto com o documento de requisitos. Junto com este documento de requisitos, o que todos nós precisamos?

Nós precisamos do Documento de Requisito que contém as necessidades do cliente, junto com isso precisamos do Documento de Entrada ou seja, Modelos de dados. Modelo de Dados no sentido de quais são os Esquemas de Banco de Dados, quais são as tabelas e quais são os relacionamentos todos esses Dados estarão disponíveis nos Modelos de Dados.

Além disso, temos o Documentos de mapeamento , Mapeando documentos para Por exemplo. em bancos de dados relacionais temos algumas tabelas e depois de carregar os dados por meio de ETL no data warehouse no HDFS, o que todos os mapeamentos precisamos fazer? ou seja, tipo de dados de mapeamento.

data de lançamento do fone de ouvido de realidade virtual xbox one

Por exemplo, se tivermos uma tabela do cliente no HDFS, então no HDFS temos uma tabela CUSTOMER_TARGET ou a mesma tabela pode estar no HIVE também.

Mapeamento de Dados

Nesta Tabela do cliente, temos certas colunas e na tabela ALVO DO CLIENTE, temos certas colunas conforme mostrado no diagrama. Despejamos os dados da tabela do cliente para a tabela de destino do cliente, ou seja, da fonte para o destino.

Em seguida, precisamos verificar o mapeamento exato como os dados presentes na Tabela de origem, que é a coluna 1 e linha 1 da tabela do cliente e considera-o como C1R1 e os mesmos dados devem ser mapeados em C1R1 da tabela ALVO DO CLIENTE. Isso é basicamente chamado de mapeamento.

Como saberemos quais são todos os mapeamentos que precisamos verificar? Portanto, esses mapeamentos estarão presentes no documento de mapeamento. No Documento de Mapeamento, o Cliente fornecerá todos os tipos de Mapeamentos.

Além disso, exigimos um Documento de Design , Documento de design necessário para a equipe de desenvolvimento e também para a equipe de QA, porque no documento de design o cliente fornecerá, que tipo de trabalhos de Map Reduce eles irão implementar e que tipo de trabalhos de MapReduce recebem entradas e que tipo de MapReduce Jobs dá resultados.

Da mesma forma, se tivermos HIVE ou PIG, quais são todos os UDFs que o cliente criou, bem como quais são todas as entradas que eles receberão e que tipo de saída eles produzirão, etc.

Para preparar cenários de teste e casos de teste, precisamos ter todos esses documentos em mãos:

  • Documento de Requisito
  • Modelo de dados
  • Documento de Mapeamento
  • Documento de Design

Eles podem variar de uma organização para outra, e não existe uma regra obrigatória de que devemos ter todos esses documentos. Às vezes temos todos os documentos e às vezes temos apenas dois ou três documentos ou às vezes precisamos contar com um documento também, ou seja, até a complexidade do projeto, cronogramas da empresa e tudo.

Críticas sobre cenários de teste e casos de teste

Precisamos realizar uma revisão nos Cenários de Teste e Casos de Teste porque de alguma forma ou em alguns casos esquecemos ou perdemos alguns Casos de Teste porque nem todos podem pensar em todas as coisas possíveis que podem ser feitas com os requisitos, em tais condições que precisamos tomar ajuda de ferramentas de terceiros ou de outra pessoa.

Portanto, sempre que preparamos alguns documentos ou executamos algo, precisamos de alguém para revisar o material da mesma equipe, como Desenvolvedores, Testadores. Eles darão sugestões adequadas para incluir algo mais ou também sugerirão atualizar ou modificar os Cenários de Teste e Casos de Teste.

Eles fornecem todos os comentários e, com base nisso, atualizaremos nossos Cenários de Teste e Casos de Teste e várias versões do documento que precisamos liberar em toda a equipe até que o documento seja totalmente atualizado de acordo com o requisito.

Execução de Teste

Assim que o documento estiver pronto, obteremos a aprovação da equipe superior para iniciar o processo de execução que é basicamente chamado de Execução do Caso de Teste.

Se quisermos executar nossos Casos de Teste durante a execução, precisamos verificar se o Desenvolvedor tem que enviar a informação, se é Teste Funcional normal ou algum outro teste ou Teste de Automação precisamos de um Build. Mas, aqui, do ponto de vista do teste Hadoop ou BigData, o desenvolvedor fornecerá trabalhos de MapReduce.

Arquivos HDFS - quaisquer arquivos que são copiados em HDFS, essas informações de arquivos são necessárias para verificar os privilégios, scripts de HIVE que foram criados pelos desenvolvedores para verificar os dados na tabela HIVE e também precisamos dos UDFs de HIVE que foram desenvolvidos pelos desenvolvedores, PIG Scripts e PIG UDF's.

Essas são todas as coisas que precisamos obter dos desenvolvedores. Antes de ir para a execução, devemos ter todas essas coisas.

Para trabalhos de MapReduce, eles fornecerão alguns arquivos JAR e como parte do HDFS eles já carregaram os dados no HDFS e os arquivos devem estar prontos e os scripts do HIVE para validar os dados nas tabelas HIVE. Quaisquer que sejam as UDFs que eles implementaram, estarão disponíveis nas UDFs do HIVE. Exigimos a mesma coisa para PIG Scripts e UDFs também.

Relatório e rastreamento de defeitos

Depois de executar nossos casos de teste, encontramos alguns defeitos, alguns esperados e alguns reais não são iguais aos resultados esperados, portanto, precisamos listar os mesmos e fornecê-los à equipe de desenvolvimento para resolução, e isso é basicamente chamado de relatório de defeito.

Suponha que se encontrarmos algum defeito no trabalho de MapReduce, então o relataremos ao desenvolvedor e eles recriarão novamente o trabalho de MapReduce e farão algumas modificações no nível de código e, em seguida, fornecerão o trabalho de MapReduce mais recente, que precisamos testar .

Este é um processo contínuo, uma vez que o trabalho é testado e aprovado, precisamos testá-lo novamente e relatá-lo ao desenvolvedor e, em seguida, obter o próximo para teste. É assim que a atividade de Relatório e Rastreamento de Defeitos é realizada.

Relatórios de teste

Assim que terminarmos com todo o processo de teste e os defeitos forem fechados, precisamos criar nossos relatórios de teste. Relatórios de teste é tudo o que fizemos para concluir o processo de teste até agora. Todo o planejamento, escrita e execuções de casos de teste, que saída obtivemos, etc., tudo é documentado em conjunto na forma de Relatórios de Teste.

Precisamos enviar esses relatórios diariamente ou semanalmente ou de acordo com as necessidades do Cliente. Hoje em dia as organizações estão usando o Modelo AGILE, então todo Relatório de Status precisa ser atualizado durante os Daily Scrums.

Conclusão

Neste tutorial, vimos:

  • A estratégia ou plano de teste do BigData.
  • Ambiente necessário para teste de BigData.
  • Validação e verificações de BigData.
  • Ferramentas usadas no teste do BigData.

Também aprendemos sobre -

  • Como a estratégia de teste, o desenvolvimento de teste, as execuções de teste, o gerenciamento de defeitos e a entrega funcionam nas funções e responsabilidades como parte do teste Hadoop.
  • Abordagem de teste para teste Hadoop / BigData que inclui coleta de requisitos, estimativa, planejamento de teste, criação de cenários de teste e casos de teste, juntamente com as revisões.
  • Também conhecemos a execução de testes, relatórios e rastreamento de defeitos e relatórios de testes.

Esperamos que este tutorial de teste de BigData tenha sido útil para você!

=> Verifique TODOS os tutoriais BigData aqui.

Leitura recomendada

^