1. Introdução
Testes automatizados se fundamentam no uso de ferramentas para controlar a execução de testes de software. Através da aplicação de estratégias, o objetivo é basicamente utilizar um software que testará o seu programa por você.
É possível considerar que a principal característica na automatização de testes é permitir que os testes sejam repetidos várias vezes, sendo mais fácil encontrar novos erros através da repetição e da simulação de cenários específicos.
Nos ambientes de Business Intelligence (Data Warehouse e Data Mart) e Big Data a quantidade de dados é muito grande, muitas vezes tratando de milhares ou milhões de registros, e algumas vezes chegando a bilhões de linhas de dados.
Os testes típicos em projetos de BI giram em torno de dados estruturados e do uso de SQL para realizar o teste. No caso do Big Data, a automatização trata especificamente dos dados estruturados, ou seja, no formato de tabelas.Estes testes visam avaliar se os dados no ambiente de origem (sistemas transacionais) estão emconformidade com os dados no ambiente de destino (Data Warehouse / Data Lake)após terem recebidos as devidas transformações no processo de ETL (Extração,Transformação e Carga, do Inglês Extraction, Transformation and Load)
De acordo com os autores do livro “Testando o Data Warehouse”, Doug Vucevic e Wayne Yaddow, alguns dos principais desafios para avaliarem testes de Data Warehouse são:
•Completude dos Dados
•Transformação dos Dados
•Qualidade dos Dados
•Teste de Regressão
A única maneira de realizar esses testes em um período razoável, que irá comparar grandes volumes de dados, é automatizando os testes.
Ainda segundo os autores, 2 métodos são utilizados para realizar os testes em ambientes de BI e Big Data:
•O método nº 1 para comparar os dados da origem e do destino é a Amostragem ,também conhecido como “Stare e compare” (Olhar fixamente e comparar). É uma tentativa de verificar os dados copiados em planilhas do Excel através da visualização dos dados. Normalmente, menos de 10% é verificado e o relatório gerado sobre o processo de avaliação é manual.
•O método nº 2 é a consultas MINUS (MENOS). Nela o analista de teste subtrai conjuntos de dados um do outro e analisa as linhas restantes, se houver diferença entende-se que é um erro. Este processo pode ser ineficiente além de não produzir trilha de auditoria ou relatório.
Ambos os métodos requerem programação SQL.
Há ainda o desafio de realizar testes nos relatórios de Business Intelligence/Big Data. A abordagem típica é validar os dados nos relatórios. Muitos relatórios de BI utilizam Flash e outras tecnologias que criam problemas para a automação de teste tradicional. E a maioria das ferramentas de BI manipula os dados de origem, o que torna ainda mais difícil o teste manual.
2. Projeto Piloto
Para avaliar a eficácia de uma das ferramentas de automatização de testes para projetos de BI e Big Data disponível no mercado, foi realizado um projeto piloto com dados de um projeto de Business Intelligence.
Os testes envolveram comparações entre bases do Business Intelligence (no SGBDInformix) com as bases transacionais (nos SGBDs MySQL e PostGreSQL), com arquivos CSV disponibilizados pelas áreas de negócio, e com relatórios gerados na ferramenta OLAP MicroStrategy.
Nas figuras abaixo serão apresentadas alguns dos testes executados.
Inicialmente, foi realizada uma consulta na base de origem para obter dados do projeto de Business Intelligence. Durante todo o projeto piloto optou-se por não utilizar o Wizard (Assistente de criação de consultas através de interface gráfica com seleção das tabelas, campos e relacionamentos através do uso do mouse, sem necessidade de digitar códigos SQL).
O resultado foi uma base de 797.040 registros na área de Staging da ferramenta para uso nas comparações.
Em seguida foi criada uma consulta utilizando a base da Staging e outra consulta utilizando a base do BI. E realizada a comparação entre elas.
Verificou-se uma diferença de 4.219 registros entre a origem e o destino. Sendo ainda que dentre os registros que estavam nas duas bases, 5 deles tiveram diferença nos campos que não fazem parte da chave primária. Desta forma, é possível saber quais registros estão em uma base e não estão na outra e em quais campos há diferença de dados.
Esta diferença denunciou que havia um problema no processo ETL que gerava mais dados que o correto por causa de um relacionamento incorreto entre as tabelas envolvidas nas cargas.
Assim, o processo de ETL pôde ser alterado e em seguida o teste ser reexecutado sem a necessidade de nenhum esforço, visto que o processo de teste na ferramenta já estava pronto desde a primeira rodada de testes e bastava simplesmente agendar a sua execução ou executá-lo manualmente.
Para finalizar, foi realizado um teste entre a base do BI e o metadados OLAP da ferramenta MicroStrategy.
A comparação é realizada através do ID alfa numérico de 33 posições do relatório no meta dados do MicroStrategy. Inicialmente cria-se um relatório com os mesmos atributos da consulta SQL e obtém-se o ID do mesmo. Em seguida, cria-se uma consulta apontando para o ID deste relatório.
A ferramenta realiza as duas consultas e compara todos os atributos.Após a execução do teste, observou-se que não havia diferença entre o quantitativo de registros e nem entre os valores dos atributos.Isto garante que o meta dados OLAP está correspondendo com o esperado.
3. Conclusões
Os objetivos do projeto piloto, os quais envolviam a verificação da carga no ambiente de Business Intelligence comparada com os dados no ambiente de origem e com o relatório OLAP na ferramenta MicroStrategy,foram alcançados utilizando os testes disponíveis na ferramenta.
Foi possível verificar que o processo de automatização de testes pode ser realizado,e com isto,ao final de cada processo ETL o mesmo pode ser validado diretamente pelo agendamento detestes na ferramenta.
Uma outra vantagem encontrada foi a possibilidade de realizar testes contra o meta dados da ferramenta OLAP MicroStrategy. Isto impede que possíveis erros na construção do projeto OLAP que podem gerar relatórios inconsistentes passem despercebidos quando a base do BI estiver corretamente carregada.
É importante citar que a inclusão do processo de automatização de testes na criação do projeto de BI incrementa em cerca de 15% o seu tempo de desenvolvimento.
No entanto, a garantia de executar um processo com qualidade,conforme é definido no modelo DevOps, evita o gasto de tempo durante a homologação do projeto e em correções pós entrega, e torna o processo muito mais confiável.
Além disto o Product Owner tem menos trabalho para realizar as validações das entregas e estas entregas com qualidade trazem mais crédito à equipe de desenvolvimento.
Apesar de o projeto piloto não ter utilizado bases com milhões de registros,verificou-se que a ferramenta de automatização de testes funciona perfeitamente para grandes quantidades de dados, devendo,naturalmente, a infraestrutura de hardware ser corretamente dimensionada para atender um volume maior de dados.
Gostou do artigo? Acesse outros conteúdos do Semantix Lab e continue aprendendo muito mais!
