Applying genetic algorithms to data selection for sql mutation analysis

No ano de 2013 Monção et al. [34] apresentam uma abordagem para testes de instruções SQL usando Análise de Mutantes juntamente com o emprego de um Algoritmo Genético (AG) para realizar a seleção de dados na formação de BDTs a partir da redução de uma BDP. O objetivo é conseguir, de forma heurística, selecionar um conjunto de dados de uma BDP que consiga ter um bom poder de detecção de defeitos de instruções SQL de uma aplicação.

3.3 Redução de Dados para Análise de Mutantes SQL 49

Os AGs podem ser definidos como uma técnica de busca baseada numa metáfora do processo biológico de evolução. Baseiam-se nos mecanismos de seleção natural e genética para criar/encontrar boas soluções para um problema. Cada solução no AG é considerada como um indivíduo dentro de uma população. Com isso a técnica combina a sobrevivência entre os melhores com uma forma estruturada de troca de informação genética entre indivíduos, para formar uma estrutura heurística de busca.

Para viabilizar a abordagem proposta, foi definido e apresentado no trabalho uma especialização de AG que permitiu tratar um caso de teste (BDT) como uma solução. Além disso foi criado um modelo cromossomial, que é capaz de representar instâncias de banco de dados como indivíduos dentro do contexto de AG. O principal objetivo do modelo é possibilitar a representação de um subconjunto de dados (tabelas e tuplas) que está contido em uma BDP. A partir deste subconjunto é possível instanciar uma BDT para ser usada na Análise de Mutantes.

Para verificar a viabilidade da proposta, os autores realizaram experimentos com o objetivo principal de comparar resultados obtidos usando o AG com os obtidos a partir de métodos aleatórios. Com isso, pretendiam demonstrar os ganhos obtidos com a técnica. A expectativa era que com o AG fossem geradas pequenas BDTs que alcancem resultados (escores) iguais ou melhores do que aqueles encontrados usando toda a BDP. Os mutantes foram gerados usando a ferramenta SQLMutantion [48].

Ao final da primeira bateria de experimentos, os autores puderam comparar para cada instrução SQL, os seguintes valores (resultados) de escore de mutação:

• Score usando toda a BDP;

• Média e Maior score usando BDT de 100 tuplas gerada com o AG; • Média e Maior score usando BDT de 100 tuplas gerada aleatoriamente; • Média e Maior score usando BDT de 10.00 tuplas gerada aleatoriamente;

Para 11 instruções SQL avaliadas, três mostraram escores de mutação similares entre a seleção aleatória (100 tuplas) e a seleção do AG (100 tuplas). Outras três tiveram uma pequena melhora com o AG. Quatro instruções demonstraram um ganho considerável e uma delas conseguiu alcançar com o AG (100 tuplas) um score igual ao score da BDP (100.000 tuplas).

Na tentativa de encontrar melhores resultados, Monção et al. aplicaram mudan- ças consideráveis nos parâmetros do AG e realizaram novos experimentos para 3 ins- truções das 11 utilizadas anteriormente. Os parâmetros utilizados estão apresentados na Tabela 3.6.

Tabela 3.6: Novos parâmetros do Algoritmo Genético usado nos experimentos Parâmetro Valor Gerações 30 Indivíduos 100 Genes 100

Crossover Ponto de corte aleatório Taxa de mutação 3% por gene

Elitismo Os dois melhores indivíduos

O escore de mutação de uma das instruções não sofreu mudança em relação ao escore alcançado pelo primeiro experimento (primeira versão do AG). Já para as outras duas instruções, foram geradas BDTs com escores de mutação melhores que os alcançados anteriormente chegando mais próximos do escore de mutação da BDP.

3.4

Questões Importantes

De modo geral, os trabalhos que foram relacioandos neste capítulo possuem al- gumas características, experiências e conclusões que merecem ser destacadas conside- rando o contexto e objetivos da pesquisa.

No trabalho de Tuya et al. [50] é colocado em destaque a vantagem e a viabili- dade de se usar uma base de dados reduzida para realizar testes em instruções SQL. Os autores afirmam que um simples e pequeno caso de teste muitas vezes é suficiente para simular diferentes situações de dados e com isso conseguir detectar muitos defeitos re- presentados pelos mutantes. Relatam também que existe uma dificuldade e um enorme esforço para a geração manual de casos de testes (dados de teste). Em contrapartida, eles afirmam que usar dados de teste de forma aleatória aumenta o risco de omitir defeitos.

Um possível problema em relação aos experimentos realizados foi levantado por Tuya et al [50]. Segundo eles a ausência de dados reais torna o experimento incerto em re- lação à representatividade de cada consulta, em termos das combinações de características que podem ser encontradas no mundo real, impossibilitando a comparação da aplicabili- dade dos operadores com sistemas reais. Esta afirmação destaca a necessidade de existir um ambiente de teste que seja composto por dados de sistemas reais.

Derezinska [19] destaca sobre a desvantagem do uso de uma base de dados reduzida não apropriada para os experimentos. Afirma também que se fosse usada a base completa muitos mutantes sobreviventes, provavelmente, teriam morrido, porém o custo (tempo de execução) seria muito alto. Reforça a necessidade de realizar reduções que mantenham o mesmo poder de detecção de defeito da base real. Outro ponto levantado

3.5 Considerações Finais 51

como um possível problema é a falta de conclusividade nos resultados principalmente pela baixa quantidade de experimentos realizados.

Um problema previsto por Tuya et al. [47] foi a possível violação de integridade referencial durante o processo de redução. Tuplas selecionadas para formar a BDT podiam fazer referência a tuplas que não foram selecionadas, podendo causar inconsistência no banco de dados sendo criado. Esta situação foi evitada simplesmente incluindo, quando necessário, as tuplas referenciadas pelas tuplas selecionadas. Tuya et al. novamente destacam neste trabalho a importância da base de dados reduzida para uso em testes de aplicações de banco de dados.

Durantes os experimentos, Chixiang Zhou e Phyllis Frankl [51] se depararam com uma situação onde alguns mutantes somente poderiam ser mortos se fossem inseri- dos dados que infringissem restrições de unicidade do esquema do banco de dados (chaves primárias). Como isso não é possível, estes mutantes foram considerados nos experimen- tos como mutantes equivalentes.

Para realizar os experimentos e verificar o desempenho da técnica, Monção et al. [34] tiveram que dedicar um enorme tempo e esforço na criação de todo um ambiente de teste composto pela base de dados de grande volume (BDP), as instruções SQL com seus mutantes e as inúmeras reduções aleatórias para servirem como parâmetros de comparação com os resultados alcançados com a técnica de busca empregada por eles. Esforço semelhante foi necessário também para todas as pesquisas que traba- lharam com seleção/redução de dados no contexto de Análise de Mutantes SQL. Além disso, o desempenho dos resultados encontrados nestes artigos infelizmente não podem ser comparados de forma imparcial entre eles. A comparação das técnicas somente seria possível caso todas utilizassem um mesmo ambiente de teste (BDP e instruções SQL).

A avaliação de todos os trabalhos apresentados neste capítulo nos levou a con- trução da Tabela 3.7 que correlaciona os trabalhos de acordo com algumas características em comum.

3.5

Considerações Finais

Neste capítulo, foram apresentados importantes trabalhos sobre a Análise de Mutantes SQL, envolvendo principalmente a criação dos operadores de mutação e a aplicação da técnica. Também foram detalhados trabalhos que tratam sobre a geração ou redução de dados para construção de bons casos de teste no contexto da Análise de Mutantes SQL.

Tabela 3.7: Correlação entre os Trabalhos Relacionados

Características Trabalhos Relacionados

[10] [11] [19] [23] [34] [43] [44] [47] [48] [50] [51] [38] [42] Propõem operadores de mutação para

instruções SQL

X X X X X X

Realizam experimentos aplicando a técnica de Análise de Mutantes

X X X X X X X X X X