Fases do Processo de Teste

Fase 1: Teste na Fonte de Dados

No processo de teste, são fornecidos como entrada o esquema do banco de dados (tabelas relacionais) utilizado pelo sistema de vendas e os dados da fonte de dados.

Ao receber as instâncias de dados, a ferramenta que avalia a qualidade nos dados gera automaticamente instâncias de dados com alterações (chamadas de instâncias de dados alternativas) de acordo com as classes de defeito pré-definidas. Essas instâncias de dados são geradas a partir dos 10 primeiros registros de cada tabela da fonte de dados original, considerando 100% dos atributos de cada tabela quando possível, ou seja, o defeito de cada classe foi aplicado para todos os atributos de determinada tabela quando viável a sua aplicação, pois a aplicação das alterações relacionadas às classes de defeito depende das restrições e definições associadas aos atributos das tabelas.

Os dados com defeitos são inseridos no banco de dados teste que contém uma réplica do esquema de dados da fonte de dados a fim de verificar se o mesmo irá aceitá- los ou não. Esse teste de validação verifica se os dados seguem regras estabelecidas pelo

esquema, caso não siga, e após verificação do testador, significa que existem restrições ausentes ou incorretas no esquema dos dados para a fonte de dados em teste. O resultado desse processo foi analisado a fim de verificar quais valores aceitos e quais valores rejeitados revelaram de fato defeitos no esquema de dados da fonte de dados e, consequentemente, possíveis defeitos nos dados das fontes de dados de acordo com a especificação correta dos dados.

A Tabela 5.1 apresenta exemplos de instâncias de dados alternativas inseridas no banco de dados teste da fonte de dados.

Tabela 5.1 Exemplos dos Defeitos inseridos para as Classes de Defeito nos Dados da Fonte de Dados

Classes de Defeitos nos Dados

Dado Original Exemplos de Instâncias de Dados Alternativas Geradas

Caracteres de Espaço em Branco Incorretos [ 'Ana Luiza'] [ 'Celular LG'] [ ' Ana Luiza'] [ ' Celular LG'] Codificação Incorreta [ 'Ana Luiza']

[ 'Celular LG']

[ 'Nan Yhvmn'] [ 'Pryhyne YT'] Dados Contraditórios [ 'Ana Luiza']

[ 'Celular LG']

[ 'A. Luiza'] [ 'Celular GL'] Duplicado [ 'Ana Luiza']

[ 'Celular LG']

['Ana Luiza'] [ 'Celular LG'] Falta de Dados Corretos [' 49644705637']

[ '861.6745']

['99999999999'] ['999.9999'] Fora do Domínio [ 'Ana Luiza']

[ 'Celular LG']

[4299.0) ['2015-07-08']

Nulos [ 'Ana Luiza'] [ 'Celular LG']

[ NULL] [ NULL] Tamanho Incorreto [ 'Ana Luiza']

[ 'Celular LG'] ('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa') ('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa')

Transposição de Palavras [ 'Ana Luiza'] [ 'Celular LG']

[ 'Luiza Ana'] [ 'LG Celular‟] Valores Embutidos [ 'Ana Luiza']

[ 'Maria Assis']

[„Presidente Ana Luiza'] ['Senhora Maria Assis']

Fase 2: Teste no ETL

Nessa fase de teste foram utilizados 10 comandos de manipulação SQL utilizados no processo ETL do DW e que correspondem às regras das classes de defeitos no ETL. Para a execução desta fase foi considerada uma Base de Dados de Teste (BDT) contendo as tabelas relacionais e os dados copiados do banco de dados original sem nenhuma alteração/redução dos dados.

Os operadores de mutação SQL são executados somente se for possível a sua aplicabilidade aos comandos selecionados, pois existem alguns operadores de mutação SQL que não se aplicam a determinadas consultas, como por exemplo, o operador de mutação JOI, que realiza troca de join nas consultas e, portanto, somente pode ser aplicado em consultas que possuem JOIN.

Os operadores de mutação SQL utilizados nesse estudo de caso foram: SEL (SELECT), ROR (substituição de operador relacional), LCR (substituição de operador lógico), tNmTb (troca de nome de tabela), tNmRole (troca de nome de role), iRole (inserção de role), rRole (retirada de role), tPoAt (troca de posição de atributo), iAtr (inserção de atributo), rAtr (retirada de atributo), tPoVr (troca de posição de valor), tAt (troca de atributo), tVr (troca de valor), ABS (inserção de valor absoluto), UOI (inserção de operador unário), IRC (substituição de coluna), NLI/NLO (nulos na entrada de dados).

Após a execução das consultas mutantes nas instâncias da base de dados, a ferramenta realiza uma análise automática do resultado das consultas avaliando se os mutantes ficaram mortos ou vivos. Para isso, a ferramenta realiza uma comparação entre os resultados gerados pela execução da consulta original e os resultados gerados pela consulta mutante. No caso do resultado da consulta ser diferente do resultado da consulta original considera-se mutante “Morto”. No caso dos resultados dessas consultas serem iguais, considera-se mutante “Vivo” e no caso de mutantes vivos o testador deverá analisar se o mutante é equivalente ou não, caso não seja equivalente, ou seja, o mutante continuou “Vivo”, o testador decide se deve ou não continuar os testes, sempre levando em consideração o escore de mutação alcançado para o teste.

A quantificação dos resultados dos testes é avaliada por meio do escore de mutação gerado para cada caso de teste executado no estudo de caso. Quanto mais próximo de 1 melhor o conjunto de casos de teste utilizado para revelar os defeitos. Os resultados serão apresentados e discutidos posteriormente na seção Resultados.

Fase 3: Teste no DW

Nesta fase do processo de teste proposto, são fornecidos como entrada o esquema do banco de dados do DW utilizado no sistema de vendas e os dados do DW.

Após receber as instâncias de dados, a ferramenta de qualidade de dados gerou as instâncias de dados com as alterações (instâncias de dados alternativas) de acordo com as classes de defeito pré-definidas. Essas instâncias de dados também foram geradas a partir dos 10 primeiros registros de cada tabela do DW, considerando 100% dos atributos de cada tabela, quando possível, conforme explicado anteriormente.

Os dados com defeitos são inseridos no banco de dados teste que contém uma réplica do esquema de dados do DW a fim de verificar se o mesmo irá aceitá-los ou não. Esse teste de validação verifica se os dados seguem regras estabelecidas pelo esquema, caso não siga, e após verificação do testador, significa que existem restrições ausentes ou incorretas no esquema dos dados para a fonte de dados em teste. O resultado desse processo foi analisado a fim de verificar quais valores aceitos e quais valores rejeitados revelaram de fato defeitos no esquema de dados do DW e assim possíveis defeitos nos dados do DW de acordo com a especificação correta dos dados.