Comparação de abordagens

mutante, o número da linha de retorno, na coluna linha. Para montar o BDT são utilizadas as linhas inteiras do banco original que as chaves primárias selecionadas identificam.

Os BDTs são montados como view, tabelas virtuais, no Apêndice A estão apresentadas asviewutilizadas nos experimentos do Capítulo5. Portanto, com a utilização de views é possível selecionar dados do BDP para um BDT sem perder a integridade referencial dos dados selecionados. Por exemplo, umaiSQLutiliza três tabelas, o método é utilizado para realizar a seleção de dados nestas tabelas. Nas demais tabelas não é realizado nenhum método de seleção e estas tabelas são montadas inteiras comoview.

4.4 Comparação de abordagens

A Tabela4.3apresenta uma comparação dos trabalhos relacionados encontrados e o Método MutShrinkdestacado em negrito. Foram apresentados os autores dos traba-lhos, o método de redução utilizado por cada autor, o método de avaliação dos testes em ABD e as características de cada método. Em seguida serão detalhadas as características de cada método para comparação com o métodoMutSrhink.

Tabela 4.3:Comparação entre abordagens encontradas

Referências Método de Abordagem de Método de Características otimização otimização Avaliação dos métodos Toledoet al. Seleção de dados Mutação FPC e mutação Mono consulta

MutSrhink

Tuyaet al. Seleção de dados FPC FPC e mutação Multi consulta QASrhink

Monçãoet al. Seleção de dados AG Mutação Mono consulta Rivaet al. Geração de dados FPC FPC e mutação Multi consulta Gupta, Shah Geração de dados Solver CVC3 Mutação Mono consulta e Chandraet al.

Panet al. Geração de dados Mutagen Mutação Mono consulta Sarkaret al. Geração de dados iCosMutate FPC e mutação Mono consulta McCormicket al. Não possui Não possui Mutação Mono Consulta Tsumuraet al. Não possui Não Possui Teste em pares Mono Consulta

O método MutSrhink destacado em negrito, utiliza seleção de dados de teste como método de otimização, e uma abordagem baseada em Análise de Mutação. A avaliação do método é realizada por dois métodos, Análise de Mutação e cobertura FPC.

Este método seleciona dados para instruções de consulta SQL que possuem uma ou mais tabelas em sua estrutura e seleciona um conjunto de dados para cada SQL por vez.

A ferramenta QAShrink possui características semelhantes ao método MutSrhink, ambos lidam com redução em ambientes de dados mais robustos, com instruções SQL com estruturas complexas e grande quantidade de dados armazenados.

Porém, as reduções realizadas pela ferramenta QAShrink podem atender uma ou mais

4.4 Comparação de abordagens 37

SQLs simultâneas, diferente do método MutShrinkque realiza redução para uma instru-ção SQL por vez. Porém, cobertura estrutural FPC em que o método se baseia, seleciona dados com menor capacidade de matar mutantes do que o métodoMutShrink, estes dados serão apresentados no Capítulo5.

Monçãoet.al.utiliza AG para selecionar dados de teste e utilizaram nos experi-mentos apenas instruções sem junção de tabelas, diferente do métodoMutShrink. Os au-tores avaliaram os BDTs gerados utilizando apenas mutação, diferente do método MutSh-rink que avalia com escore de mutação e com cobertura estrutural FPC. O benchmark utilizado pelos autores possuía uma quantidade de dados armazenados inferior ao ben-chmark utilizado nos experimentos do método MutSrhink. Este método assim como o MutSrhinké mono consulta, realiza seleção de dados para uma consulta SQL pode vez.

Diferente do Método MutShrink Riva et al. utiliza geração de dados de teste utilizando uma abordagem baseada em cobertura FPC, esta abordagem gera dados para múltiplas consultas simultaneamente. Este método é avaliado utilizando escore de muta-ção e cobertura FPC assim como o métodoMutShrink.

Os trabalhos de Gupta, Shah e Chandra et al.também aborda a otimização dos testes utilizando geração de dados de teste. O solver é aplicado nas restrições dos mutantes que são gerados manualmente, para gerar dados capazes de revelar defeitos inseridos por estes mutantes. Assim como oMutShrinko método é mono consulta.

Os trabalhos de Panet al. gera dados de teste utilizando a ferramentaMutagen.

Este método gera dados de teste e estado de BD, utilizando as restrições dos mutantes para gerar dados de teste. A avaliação é realizada com escore de mutação de código das aplicações e dos SQLs das aplicações. No métodoMutShrinké realizado o teste em ABD apenas nas SQLs. O método é mono consultaMutagenassim como oMutShrinké mono consulta.

Finalizando abordagens que utilizam geração de dados de teste, o trabalho de Sarkaret al.utiliza mutantes e regras de cobertura que não retornam nenhum resultado e gera dados que possam atender estes mutantes e regras de cobertura. Este método é mono consulta e os dados gerados são avaliados utilizando escore de mutação e cobertura FPC assim como o métodoMutShrink.

Em relação a avaliação de banco de dados os trabalhos de McCormicket al. e Tsumuraet al.diferente dos métodos anteriores não possuem nenhum método de otimi-zação dos testes, realizando apenas a avaliação das bases. No trabalho de McCormick et al. foi utilizado apenas mutação. No trabalho de Tsumura et al. Foi utilizado apenas cobertura estrutural, diferente do método MutShrinkque avaliou as bases reduzidas com abordagens estruturais e de mutação.

4.5 Considerações finais 38

4.5 Considerações finais

Este capítulo apresentou o método de seleção de dados de teste baseado em mutação para testes em instruções de consulta SQL. Foi explicada a utilização de Análise de mutação no método de seleção e cada fase aplicada pelo método de seleção no banco de dados para a realização da seleção dos dados de teste. E foi finalizado o capítulo com a comparação das funcionalidades do método MutShrinkcom os trabalhos apresentados no Capítulo2de trabalhos relacionados.

CAPÍTULO 5

Experimentos

Neste capítulo serão apresentados o ambiente em que foram realizados os expe-rimentos, os parâmetros dos experimentos e da avaliação dos resultados e as perguntas de pesquisa nos quais serão apresentados os resultados do estudo empírico realizado neste trabalho.

5.1 Ambiente

Para realizar os experimentos foi preciso encontrar uma base de dados com tamanho que justificasse o uso da abordagem de seleção dos dados de teste. A partir de algumas bases existentes na literatura e Benchmarks disponíveis para testes, foi selecionado para os experimentos o Benchmark TPC-H [31]. Este Benchmark para suporte a decisão foi escolhido pelo grande volume de dados e instruções com alto grau complexidade. O modelo de dados do BD é apresentado na Figura5.1:

Este banco contém oito tabelas, nation com 25 tuplas,customer com 150.000 tuplas, lineitemcom 6.001.215 tuplas,partsuppcom 800.000 tuplas,partscom 200.000 tuplas, region 5 tuplas, orderscom 1.500.000 tuplas e supplier com 10.000 totalizando 8.511.220 tuplas.

Foram utilizadas 14 Instruções SQL retiradas doBenchmark TPC-H nos expe-rimentos. As instruções utilizadas nos experimentos estão apresentadas no AnexoA. As características das instruções selecionadas são variadas, contendo SQLs uma e com múl-tiplas tabelas, e SQLs com estruturas complexas devido à quantidade de restrições pre-sentes.

Os experimentos utilizam três bases: 1) O banco TPC-H, utilizado como BDP;

2) o banco de experimentos, que armazena dados dos experimentos, as iSQL eSQLSeed e os mutantes de ambas e 3) oBDSeed, que armazena as chaves primárias resultante dos mutantes da SQLSeed. Não foi criado uma base para os BDTs, pois eles são montados comoviews.

5.2 Parâmetros 40

Figura 5.1:Modelo de dados do Banco de Dados TPCH-H

5.2 Parâmetros

O método proposto é dividido em duas fases que possuem parâmetros distintos.

Na primeira fase, foram gerados 4.526 mutantes da SQLSeed, utilizados na seleção de dados de teste. Já na segunda fase os BDTs são formados por filtros que limitam a quantidade de tuplas selecionadas para os BDTs. Foram criados 14 BDTs, um para cada iSQL e seus tamanhos são variados dependendo do filtro utilizado e do resultado dos mutantes daSQLSeed.

Para realizar as mutações das instruções SQL foi utilizada a ferramenta SQL-Mutation [14]. Foram gerados mutantes para três dos quatro operadores, não foi criado nenhum mutante utilizando o operador NL. Estes mutantes não são criados devido a todos os campos das tabelas dobenchmarkpossuírem atributosNOT NULL. Portanto, se não há atributo nulo não é gerado nenhum mutante para este operador.

O BDSeed armazena o resultado dos mutantes das SQLSeed, porém, alguns resultados de mutantes possuem um volume de dados muito grande. Alguns resultados de mutantes de operadores lógicos retornam um volume muito grande de dados repetidos, tornando esta coleta de dados muito demorada.

Portanto, para reduzir a quantidade de dados repetidos e otimizar este processo,

5.3 Avaliação 41

foi estabelecido um limite máximo de dados armazenados por mutante. Assim, foi armazenado no BDSeed as primeiras 1.000.000 tuplas retornadas de cada mutante da SQLSeed. Este valor utilizado na limitação de armazenamento, obteve resultados de escore de mutação com valores bem próximos a do banco original, alcançando valores iguais ao BDP na mairia dos casos.

Porém, em casos do valor deste limite máximo for menor que 1.000.000 de tuplas os resultados de alguns escores de mutação é prejudicado. E em casos em que o valor do limite máximo de dados armazenados é superior a 1.000.000 de tuplas os resultados que não alcançaram o valor do BDP permanecem iguais. Nestes casos, o número de tuplas que precisam de ser armazenadas noBDSeedé muito superior a 1.000.000 de tuplas, tornando este processo muito caro computacionalmente.

A avaliação dos BDTs também possui alguns parâmetros para a AM. O mutante é considerado morto caso seu resultado seja diferente do resultado da aplicação original.

Porém, foi utilizado outro critério para considerar o mutante morto na avaliação por AM. O mutante também foi considerado morto caso ele excedesse o tempo de execução estipulado.

Portanto, este tempo de execução foi definido como o tempo da execução da SQL original, adicionando 60 segundos a este tempo. Desta forma a execução do mutante seria interrompida após este tempo e este mutante é considerado morto porTime Out. Este critério é utilizado para eliminar mutantes com tempo de execução muito superior ao do SQL original.

5.3 Avaliação

A avaliação dos BDTs é realizada por duas métricas, AM e Critério de Cobertura FPC que são explicadas no Capítulo 2. A Tabela 5.1 apresenta o número de mutantes gerados por categoria e o número de regras de cobertura gerados para cadaiSQL.

Foram considerados todos os mutantes da Tabela 5.1 para calcular o escore de mutação. Também foram consideradas todas as regras de cobertura FPC, totalizando 5.255 mutantes e 217 regras de cobertura. As regras de cobertura foram geradas pela ferramentaSQLFPC[35].

Os mutantes gerados para a seleção e para avaliação são semelhantes, pois o método seleciona dados que sejam capazes de revelar os defeitos inseridos nos mutantes.

Porém, a quantidade de mutantes gerados é diferente. Ao comparar o total de mutantes da SQLSeed (4.526 mutantes) e para iSQL (5.225 mutantes), é possível observar que a quantidade de mutantes gerados paraSQLSeedé menor.

Esta quantidade inferior de mutantes gerados para as SQLSeed é devido as diferenças nas estruturas das SQLs. A retirada de agrupamento e ordenação e as alterações