Menu

Testes de validação de dados para ETL e projetos de migração de dados

  • Principal
  • Outro
  • Testes de validação de dados para ETL e projetos de migração de dados

data validation tests

Experimente Nosso Instrumento Para Eliminar Problemas

como abrir um arquivo json

Este tutorial descreve ETL e projetos de migração de dados e abrange verificações ou testes de validação de dados para ETL / projetos de migração de dados para melhorar a qualidade dos dados:

Este artigo é para testadores de software que estão trabalhando em projetos de ETL ou migração de dados e estão interessados ​​em focar seus testes apenas nos aspectos de qualidade de dados. Esses tipos de projetos têm um grande volume de dados que são armazenados no armazenamento de origem e, em seguida, são operados por alguma lógica presente no software e movidos para o armazenamento de destino.

Os testes de validação de dados garantem que os dados presentes nos sistemas de destino finais sejam válidos, precisos, de acordo com os requisitos de negócios e adequados para uso no sistema de produção ao vivo.

Validação de dados para ETL e projetos de migração de dados

O número de aspectos de qualidade de dados que podem ser testados é enorme e a lista abaixo fornece uma introdução a esse tópico.

O que você aprenderá:

O que é validação de dados?

Data de validade

Em termos simples, a Validação de Dados é o ato de validar o fato de que os dados movidos como parte do ETL ou tarefas de migração de dados são consistentes, precisos e completos nos sistemas ativos de produção de destino para atender aos requisitos de negócios.

Exemplo: O endereço de um aluno na tabela Aluno tinha 2.000 caracteres no sistema de origem. A validação de dados verifica se o mesmo valor reside no sistema de destino. Ele verifica se os dados foram truncados ou se certos caracteres especiais foram removidos.

Neste artigo, discutiremos muitas dessas verificações de validação de dados. Como testadores para ETL ou projetos de migração de dados, ele agrega um valor tremendo se descobrirmos problemas de qualidade de dados que podem ser propagados para os sistemas de destino e interromper todos os processos de negócios.

Por que validar dados para projetos ETL?

Em projetos ETL, os dados são extraídos da origem, trabalhados aplicando alguma lógica no software, transformados e carregados no armazenamento de destino. Em muitos casos, a transformação é feita para alterar os dados de origem para um formato mais utilizável para os requisitos de negócios.

Aqui, a validação de dados é necessária para confirmar se os dados carregados no sistema de destino são completos, precisos e não há perda de dados ou discrepâncias.

sistema de destino e fonte

Exemplo: Um aplicativo de e-commerce tem trabalhos de ETL escolhendo todos os OrdersIds contra cada CustomerID da tabela de Pedidos que soma o TotalDollarsSpend pelo Cliente e carrega em uma nova tabela CustomerValue, marcando cada CustomerRating como clientes de alto / médio / baixo valor com base em algum algoritmo complexo.

O teste de validação de dados simples é ver se a CustomerRating está calculada corretamente.

Outro teste é verificar se o TotalDollarSpend foi calculado corretamente, sem defeitos no arredondamento dos valores ou estouros de valor máximo.

Por que validar dados para projetos de migração de dados?

Em projetos de migração de dados, os grandes volumes de dados armazenados no armazenamento de origem são migrados para diferentes armazenamentos de destino por vários motivos, como atualização de infraestrutura, tecnologia obsoleta, otimização, etc. Por exemplo, as empresas podem migrar seu enorme data warehouse de sistemas legados para soluções mais novas e robustas no AWS ou Azure.

O motivo principal para tais projetos é mover os dados do sistema de origem para um sistema de destino, de forma que os dados no destino sejam altamente utilizáveis ​​sem qualquer interrupção ou impacto negativo para os negócios.

Aqui, novamente, a validação de dados é necessária para confirmar se os dados na origem são os mesmos no destino após o movimento.

Exemplo: Suponha que para o aplicativo de e-commerce, a tabela Pedidos que tinha 200 milhões de linhas foi migrada para o sistema de destino no Azure. O teste de validação de dados simples é verificar se todas as 200 milhões de linhas de dados estão disponíveis no sistema de destino.

Outro teste pode ser confirmar se os formatos de data correspondem entre o sistema de origem e o sistema de destino.

Existem vários aspectos que os testadores podem testar em projetos como testes funcionais, testes de desempenho, testes de segurança, testes de infra, testes E2E, testes de regressão, etc.

Leitura Recomendada => Teste de migração de dados , Tutorial de teste de armazenamento de dados de teste ETL

Neste artigo, veremos apenas o aspecto dos dados dos testes para projetos de ETL e migração.

Folha de mapeamento de dados

Para começar, crie uma folha de mapeamento de dados para seu projeto de dados. O mapeamento de dados é o processo de correspondência de entidades entre as tabelas de origem e destino. Comece documentando todas as tabelas e suas entidades no sistema de origem em uma planilha. Agora documente os valores correspondentes para cada uma dessas linhas que devem corresponder nas tabelas de destino. Anote as regras de transformação em uma coluna separada, se houver.

As folhas de mapeamento de dados contêm muitas informações coletadas de modelos de dados fornecidos por Data Architects. Inicialmente, os testadores podem criar uma versão simplificada e adicionar mais informações à medida que avançam. Veja o exemplo de folha de mapeamento de dados abaixo- mesa dos pais

Baixe um modelo de Folha de mapeamento de dados simplificada

Testes de Validação de Dados

# 1) Uniformidade de dados

Testes de uniformidade de dados são conduzidos para verificar se o valor real da entidade tem a correspondência exata em diferentes locais. Temos dois tipos de testes possíveis aqui:

(i) Verificações dentro do mesmo esquema:

  • A entidade de dados pode existir em duas tabelas dentro do mesmo esquema (sistema de origem ou sistema de destino)
  • Exemplo: Como você pode ver na imagem abaixo, ProductID está presente na tabela OrderDetails e Products. Faça uma verificação de correspondência exata para ProductId presente em OrderDetails vs tabela de produtos.

Folha de Mapeamento de Dados Simplificada 1

(ii) Verificações em esquemas:

  • A entidade de dados pode ser migrada como está para o esquema de destino, ou seja, está presente no sistema de origem, bem como no sistema de destino
  • Exemplo: Como você pode ver na imagem acima, ProductID está presente na tabela Produtos no sistema de origem e na tabela Produtos no sistema de destino. Faça uma verificação de correspondência exata para ProductId na tabela Produtos no sistema de origem para ProductId na tabela Produtos no sistema de destino.

Observação: É melhor destacar (código de cor) entidades de dados correspondentes na planilha de Mapeamento de dados para referência rápida.

# 2) Presença da Entidade

Neste tipo de teste, precisamos validar se todas as entidades (tabelas e campos) são correspondidas entre a origem e o destino. Existem duas possibilidades, uma entidade pode estar presente ou ausente de acordo com o design do Modelo de Dados.

(eu) Valide se todas as tabelas (e colunas), que têm uma presença correspondente na origem e no destino, correspondem. Extraímos uma lista de todas as tabelas (e colunas) e fazemos uma comparação de texto. Este teste de integridade funciona apenas se os mesmos nomes de entidade forem usados.

Às vezes, nomes de tabela diferentes são usados ​​e, portanto, uma comparação direta pode não funcionar. Podemos ter que mapear essas informações na planilha de mapeamento de dados e validá-la para falhas.

Outra possibilidade é a ausência de dados. Existem casos em que o modelo de dados requer que uma tabela no sistema de origem (ou coluna) não tenha uma presença correspondente no sistema de destino (ou vice-versa). Faça testes para validar isso.

  • Exemplo: Como você pode ver na imagem abaixo, a Tabela CustDemográfica está presente no sistema de destino e não no sistema de origem.
  • O campo CustomerType na tabela Clientes possui dados apenas no sistema de origem e não no sistema de destino.

dardo (precisão de dados)

# 3) Precisão de dados

Como o nome sugere, validamos se os dados são logicamente precisos. Existem duas categorias para este tipo de teste. Com isso, o testador pode detectar os problemas de qualidade de dados até mesmo no sistema de origem.

Integridade de dados

(imagem fonte )

Observação: Execute este teste no sistema de destino e verifique se há defeitos no sistema de origem.

(i) Tipo não numérico: Sob esta classificação, verificamos a precisão do conteúdo não numérico. Exemplos são e-mails, códigos PIN, telefone em um formato válido.

(ii) Análise de domínio: Nesse tipo de teste, selecionamos domínios de dados e validamos os erros. Existem três agrupamentos para isso:

  • Com base no valor: Aqui, criamos uma lista de valores que podem ocorrer para um campo (coluna na tabela). Em seguida, valide se os valores da coluna são um subconjunto de nossa lista.
    • Exemplo: Verifique se a coluna Sexo contém M ou F.
  • Com base no intervalo: Aqui, definimos o intervalo mínimo e máximo para valores de dados válidos para uma coluna, com base no raciocínio lógico ou comercial. Em seguida, validamos se os valores da coluna estão dentro desse intervalo.
    • Exemplo: 0 a 120 para idade.
  • Arquivo de Referência : Aqui o sistema usa um arquivo de validade externo.
    • Exemplo: Os códigos de país são válidos, eles escolhem o valor correto do arquivo de referência, os códigos de país são iguais entre o controle de qualidade e o ambiente de produção? Se o arquivo de referência teve um código de país atualizado, ele está corretamente atualizado no DB?

# 4) Validação de metadados

Na validação de metadados, validamos se as definições de tipo de dados Tabela e Coluna para o destino foram projetadas corretamente e, uma vez projetadas, são executadas de acordo com as especificações de design do modelo de dados.

Existem dois agrupamentos aqui:

(i) Projeto de metadados: A primeira verificação é para validar se o modelo de dados foi projetado corretamente de acordo com os requisitos de negócios para as tabelas de destino. Os arquitetos de dados podem migrar entidades de esquema ou fazer modificações ao projetar o sistema de destino.

A próxima verificação deve ser para validar se os scripts corretos foram criados usando os modelos de dados.

Para cada categoria abaixo, primeiro verificamos se os metadados definidos para o sistema de destino atendem aos requisitos do negócio e, em segundo lugar, se as tabelas e definições de campo foram criadas com precisão.

Algumas das verificações de metadados são fornecidas abaixo:

  • Verificação do tipo de dados: Exemplo: As vendas totais funcionarão corretamente com o tipo decimal (8, 16 ou 20 bytes) ou duplo?
  • Verificação de comprimento de dados : Exemplo: O comprimento dos dados para o campo Endereço será suficiente com 500 caracteres? Pode ser o caso em que a migração de dados é feita à medida que uma nova geografia é adicionada à empresa. Os endereços da nova geografia podem ter um formato excessivamente longo e manter o comprimento original pode causar erros em um caso de uso.
  • Verificação do índice: Exemplo: Existe indexação feita para a coluna OrderId no sistema de destino? E se uma fusão de empresas acontecer, exigindo a migração de dados e a tabela Pedidos crescer 100 vezes no sistema de destino?
  • Verificação de metadados em ambientes: Sob esta verificação, verifique se os metadados correspondem entre o teste de controle de qualidade e o ambiente de produção. Os testes podem passar no ambiente de controle de qualidade, mas falhar em outros ambientes.

(ii) Mudança Delta: Esses testes descobrem defeitos que surgem quando o projeto está em andamento e no meio do caminho, há alterações nos metadados do sistema de origem e não foram implementados nos sistemas de destino.

Exemplo: O novo campo CSI (Índice de Satisfação do Cliente) foi adicionado à tabela do Cliente na origem, mas falhou ao ser feito no sistema de destino.

# 5) Integridade de dados

Aqui, validamos principalmente as restrições de integridade como chave estrangeira, referência de chave primária, única, padrão, etc.

mesa dos pais

(imagem fonte )

Para chaves estrangeiras, precisamos verificar se há registros órfãos na tabela filho onde a chave estrangeira usada não está presente na tabela pai.

Verificação de integridade de dados

Exemplo: A tabela de clientes tem CustomerID, que é uma chave primária. A tabela de pedidos tem CustomerID como uma chave estrangeira. A tabela de pedidos pode ter um CustomerID que não está na tabela de clientes. Precisamos ter testes para descobrir tais violações de restrição de integridade. A tabela de mapeamento de dados fornecerá clareza sobre quais tabelas têm essas restrições.

Observação: Execute este teste no sistema de destino e verifique se há defeitos no sistema de origem.

# 6) Completude de dados

Esses são testes de integridade que descobrem registros ausentes ou contagens de linhas entre a tabela de origem e a de destino e podem ser executados com frequência depois de automatizados.

Existem dois tipos de testes:

(i) Contagem de registros: Aqui, comparamos a contagem total de registros para tabelas correspondentes entre o sistema de origem e o sistema de destino. Esta é uma verificação de integridade rápida para verificar a pós-execução do ETL ou trabalho de migração. Temos um defeito se as contagens não coincidirem.

Às vezes, há registros rejeitados durante a execução do trabalho. Alguns deles podem ser válidos. Mas, como testador, defendemos isso.

(ii) Perfil de dados da coluna: Esse tipo de teste de sanidade é valioso quando a contagem de registros é enorme. Aqui, criamos conjuntos lógicos de dados que reduzem a contagem de registros e, em seguida, fazemos uma comparação entre a origem e o destino.

  • Sempre que possível, filtre todos os valores únicos em uma coluna, por exemplo, ProductID pode estar ocorrendo várias vezes na tabela OrderDetails. Escolha uma lista exclusiva para ProductID nas tabelas de destino e de origem e valide. Isso reduz bastante o número de contagens de registros e acelera os testes de sanidade.
  • Como os testes acima, também podemos escolher todas as colunas principais e verificar se os KPI's (comprimento mínimo, máximo, médio, máximo ou mínimo, etc.) correspondem entre a tabela de destino e de origem. Exemplo: Pegue os valores médio, mínimo e máximo da coluna Preço em OrderDetails e compare esses valores entre as tabelas de destino e de origem para incompatibilidades.
  • Outra verificação pode ser feita para valores nulos. Escolha colunas importantes e filtre uma lista de linhas em que a coluna contém valores nulos. Compare essas linhas entre os sistemas de destino e de origem para a incompatibilidade.

Linhas do tempo

# 7) Transformação de dados

Esses testes constituem os testes principais do projeto. Revise o documento de requisitos para entender os requisitos de transformação. Prepare dados de teste nos sistemas de origem para refletir diferentes cenários de transformação. Eles têm uma grande variedade de testes e devem ser abordados em detalhes nos tópicos de teste ETL.

Abaixo está uma lista concisa de testes abrangidos por este:

(i) Transformação:

  • Exemplo: O código ETL pode ter lógica para rejeitar dados inválidos. Verifique isso em relação aos requisitos.
  • O código ETL também pode conter lógica para gerar automaticamente certas chaves, como chaves substitutas. Precisamos ter testes para verificar a exatidão (técnica e lógica) destes.
  • Valide a exatidão da união ou divisão dos valores dos campos após a conclusão de um ETL ou trabalho de migração.
  • Faça testes para verificar verificações de integridade referencial. Por exemplo, um tipo de defeito poderia ser ProductId usado na tabela Pedidos não está presente na tabela pai Produtos. Faça um teste para verificar como os registros órfãos se comportam durante um trabalho ETL.
  • Às vezes, os dados ausentes são inseridos usando o código ETL. Verifique se eles estão corretos.
  • Os scripts de ETL ou de migração às vezes têm lógica para corrigir dados. Verifique se a correção de dados funciona.
  • Verifique se os dados inválidos / rejeitados / errados são relatados aos usuários.
  • Crie uma planilha de cenários de dados de entrada e resultados esperados e valide-os com o cliente empresarial.

(ii) Casos extremos: Verifique se a lógica de transformação é válida nos limites.

  • Exemplo: O que acontece quando TotalSales com um valor de 1 trilhão é executado por meio de um trabalho ETL? Os casos de ponta a ponta funcionam? Identifique os campos que podem ter valores potencialmente grandes e execute testes com esses valores. Eles devem incluir valores numéricos e não numéricos.
  • Para campos de data, incluindo todo o intervalo de datas esperado - anos bissextos, 28/29 dias para fevereiro. 30, 31 dias para outros meses.

# 8) Exclusividade ou duplicação de dados

Nesse tipo de teste, identifique as colunas que devem ter valores exclusivos de acordo com o modelo de dados. Além disso, leve em consideração a lógica de negócios para eliminar esses dados. Execute testes para verificar se eles são exclusivos no sistema. Em seguida, execute testes para identificar as duplicatas reais.

  • Exemplo: Filtre os dados duplicados e verifique se são autênticos. Por exemplo, O registro dependente do empregado contém os mesmos dados irmãos duas vezes.
  • O número de telefone do usuário deve ser único no sistema (requisito comercial).
  • O requisito de negócios diz que uma combinação de ProductID e ProductName na tabela Produtos deve ser exclusiva, pois ProductName pode ser duplicado.

# 9) Obrigatório

Nesse tipo de teste, identifique todos os campos marcados como Obrigatórios e valide se os campos obrigatórios possuem valores. Se houver valores padrão associados a um campo no BD, verifique se ele foi preenchido corretamente quando os dados não estão lá.

  • Exemplo: Se BillDate não for inserido, CurrentDate é BillDate.

# 10) Oportunidade

Sempre documente os testes que verificam se você está trabalhando com dados dos prazos acordados.

  • Exemplo: ProductDiscount foi atualizado 15 dias atrás e o domínio de negócios declara que o ProductDiscount muda a cada sete dias. Isso significa que seus testes não estão sendo feitos com os valores de desconto corretos.
  • Um relatório de análise preditiva para o índice de satisfação do cliente deveria funcionar com os dados da última semana, que foi uma semana de promoção de vendas no Walmart. Mas o trabalho ETL foi projetado para ser executado com uma frequência de 15 dias. Este é um defeito importante que os testadores podem descobrir.

# 11) Dados Nulos

Nesse tipo de teste, focamos na validade dos dados nulos e na verificação de que a coluna importante não pode ser nula.

  • Exemplo: Filtre todos os dados nulos e valide se nulo é permitido.
  • Se houver colunas importantes para decisões de negócios, certifique-se de que nulos não estejam presentes.

# 12) Verificação de alcance

A entidade de dados onde os intervalos fazem sentido comercial devem ser testados.

  • Exemplo: A quantidade do pedido por fatura não pode ser superior a 5K na categoria de software.
  • A idade não deve ser superior a 120.

# 13) Regras de negócios

Documente quaisquer requisitos de negócios para campos e execute testes para os mesmos.

  • Exemplo: Recursos com idade inferior a 20 anos não são elegíveis. As verificações de validação de dados são necessárias se esta regra for aplicada aos dados.
  • A data de rescisão deve ser nula se o status de Funcionário Ativo for Verdadeiro / Falecido.
  • Os dados FROM devem ser menores que a data TO.
  • Os valores de compra no nível do item somam os valores no nível do pedido

# 14) Funções de agregação

Funções agregadas são construídas na funcionalidade do banco de dados. Documente todos os agregados no sistema de origem e verifique se o uso do agregado fornece os mesmos valores no sistema de destino (soma, máximo, mínimo, contagem).

Muitas vezes, as ferramentas no sistema de origem são diferentes do sistema de destino. Verifique se ambas as ferramentas executam funções agregadas da mesma maneira.

# 15) Truncamento e arredondamento de dados

Nestes tipos de testes, identificamos campos com lógica de truncamento e arredondamento relativos ao negócio. Em seguida, documentamos e aprovamos a lógica de truncamento e arredondamento com os proprietários do produto e os testamos com dados representativos da produção.

# 16) Testes de codificação

Valide se há valores codificados no sistema de origem e verifique se os dados foram preenchidos corretamente após o ETL ou a tarefa de migração de dados no sistema de destino.

  • Exemplo: Os caracteres de byte duplo para FirstName em chinês foram aceitos no sistema de origem que foi codificado. Verifique o comportamento deste campo quando movido para o sistema de destino.
  • O campo Senha foi codificado e migrado. Certifique-se de que funcionam bem após a migração.

# 17) Testes de regressão

Este é um conceito básico de teste em que os testadores executam todos os seus conjuntos de casos de teste críticos gerados usando a lista de verificação acima postando uma mudança no sistema de origem ou destino.

Conclusão

Portanto, vimos que a validação de dados é uma área interessante a ser explorada para projetos com muitos dados e forma os testes mais importantes. A folha de mapeamento de dados é um artefato crítico que os testadores devem manter para obter sucesso com esses testes. Eles podem manter várias versões com realces de cores para formar entradas para qualquer um dos testes acima.

programas que podem editar arquivos pdf

Deve-se ter cuidado para manter as alterações delta entre as versões.

Solicitamos aos leitores que compartilhem outras áreas do teste que encontraram durante seu trabalho para beneficiar a comunidade de testadores.

Leitura recomendada

^