Universidade Federal do Rio Grande do Norte Centro de Ciências Exatas e da Terra
Departamento de Informática e Matemática Aplicada Bacharelado em Ciência da Computação
Usando Técnicas de Mineração de Repositórios
Software para Apoiar a Automação de Testes
de Software
José Gameleira do Rêgo Neto
Natal-RN Junho 2019
José Gameleira do Rêgo Neto
Usando Técnicas de Mineração de Repositórios de
Software para Apoiar a Automação de Testes de
Software
Monografia de Graduação apresentada ao Departamento de Informática e Matemática Aplicada do Centro de Ciências Exatas e da Terra da Universidade Federal do Rio Grande do Norte como requisito parcial para a ob-tenção do grau de Bacharel em Ciência da Computação.
Orientador(a)
Uirá Kulesza-Doutorado
Universidade Federal do Rio Grande do Norte – UFRN Departamento de Informática e Matemática Aplicada – DIMAp
Natal-RN
Monografia de Graduação sob o título Uso de mineração de repositórios para auxiliar na automação de testes do SIGAA apresentada por José Gameleira do Rêgo Neto e aceita pelo Departamento de Informática e Matemática Aplicada do Centro de Ciências Exatas e da Terra da Universidade Federal do Rio Grande do Norte, sendo aprovada por todos os membros da banca examinadora abaixo especificada:
Dr. Uirá Kulesza
Orientador(a)
Departamento de Informática e Matemática Aplicada – DIMAp Universidade Federal do Rio Grande do Norte – UFRN
Dr. Roberta de Souza Coelho
Examinador
Departamento de Informática e Matemática Aplicada – DIMAp Universidade Federal do Rio Grande do Norte – UFRN
Dr. Felipe Alves Pereira Pinto
Examinador
Diretoria Acadêmica de Ciências – DIAC
Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte – IFRN
Homenageio a minha família, orientador, meus amigos e todas as pessoas próximas a mim, com muito carinho e apoio, não mediram esforços para eu chegasse até essa etapa da minha vida.
Agradecimentos
Agradeço a esta universidade, seu corpo docente, direção e administração que opor-tunizaram uma oportunidade de uma formação de grande excelência acadêmica, ética e moral.
Agradeço ao meu orientador pela paciência, disponibilidade e suporte pelo tempo no qual vem me orientando, além de seus ensinamentos que serão de suma importância para minha vida acadêmica e profissional.
Agradeço a minha família, amigos e colegas que me motivaram a nunca desistir e continuar estudando para me tornar um cidadão e acadêmico melhor.
Agradeço, em especial, a minha mãe por sempre me da apoio e ter feito tudo por mim, sendo imprescindível para que eu me formasse.
Agradeço, em especial, o meu pai que sempre batalhou para me dá um futuro acadê-mico diferente do dele. Com muito esforço e garra, ajudei a realizar seu sonho de ver seu filho formado, essa é nossa vitória pai.
E a todos que contribuíram de forma direta ou indireta fizeram parte da minha for-mação, o meu muito obrigado.
"Um novo mundo se abrindo, tudo mudou para mim"
Usando Técnicas de Mineração de Repositórios de
Software para Apoiar a Automação de Testes de
Software
Autor: José Gameleira do Rêgo Neto Orientador(a): Dr. Uirá Kulesza
Resumo
O desenvolvimento de sistemas de software de qualidade exige a aplicação de técnicas de teste de software que buscam minimizar o aparecimento de comportamentos inespera-dos. Em grandes projetos, a tendência é termos uma maior quantidade de testes, sendo desejável a automação de uma parte considerável deles. Em um cenário ideal, todos os testes existentes poderiam ser automatizados, entretanto, normalmente existe um grande custo associado a tal automação. Este trabalho de conclusão de curso tem como obje-tivo utilizar técnicas de mineração de repositórios de software para prover indicadores de quais testes manuais são bons candidatos a serem automatizados. Buscando alcançar tal objetivo, o trabalho utiliza informações relacionadas a similaridade de testes automatiza-dos e manuais, assim como informações de quais funcionalidades de um dado sistema são mais executadas e apresentam mais erros no ambiente de produção. Tais informações são então utilizadas para produzir um ranqueamento de prioridade de testes manuais candi-datos existentes a serem automatizados. A abordagem proposta é demonstrada e aplicada sobre informações e artefatos de testes do Sistema Integrado de Gestão de Atividades Acadêmicas (SIGAA).
Palavras-chave: testes de software, automação de testes, mineração de repositórios de software.
Using Software Repository Mining Techniques to
Support Automation of Software Testing
Autor: José Gameleira do Rêgo Neto Orientador(a): Dr. Uirá Kulesza
Abstract
The development of quality software systems requires the application of software testing techniques that seek to minimize the appearance of unexpected behaviors. In large soft-ware projects, the tendency is to have a high number of tests, and the automation of a considerable part of them is desirable. In an ideal scenario, all existing tests could be automated, however, there is usually a high cost associated with such automation. This dissertation work aims to utilize software repository mining techniques to provide indica-tors of which manual tests are good candidates to be automated. Seeking to achieve such goal, the work uses information related to the similarity of automated and manual tests, as well as information on which features of a given system are most executed and present more errors in the production environment. Such information is then used to produce a priority ranking of existing candidate manual tests to be automated. The proposed appro-ach is demonstrated and applied about informations and test artifacts from the Sistema Integrado de Gestão de Atividades Acadêmicas (SIGAA).
Lista de figuras
1 Relacionamento entre módulos do SIGAA . . . p. 22 2 Fase (i) do PerfMiner . . . p. 23 3 Diagrama de classes parcial do modelo de análise do PerfMiner . . . p. 26 4 Estrutura do atributo raiz de T1 . . . p. 27
5 Estrutura da abordagem realizada . . . p. 28 6 filtro (i) aplicado nos logs de testes manuais . . . p. 35 7 filtro (i) aplicado nos logs de testes automatizados . . . p. 35 8 filtro (ii) aplicado nos logs de testes manuais resultantes do filtro (i) . . . . p. 36 9 Aplicação do filtro (i) e (ii) nos logs dos testes manuais . . . p. 36 10 Resultado da divisão dos logs de testes manuais pela similaridade . . . p. 37 11 Metodologia do estudo . . . p. 43
Lista de tabelas
Lista de abreviaturas e siglas
SIGAA – Sistema Integrado de Gestão de Atividades Acadêmicas
TED – Tree Edit Distance
URL – Uniform Resource Locator
SINFO – Superintedência de Informática
Lista de símbolos
MM - Conjunto de todos os métodos na base manual
MA - Conjunto de todos os métodos na base automatizada
M - Conjunto de todos os métodos das bases
TM - Conjunto de todos os testes na base manual
TA - Conjunto de todos os testes na base automatizada
Sumário
1 Introdução p. 14
1.1 Problema abordado . . . p. 15
1.2 Abordagem proposta . . . p. 16
1.3 Objetivos geral e específicos . . . p. 16
1.4 Organização do trabalho . . . p. 17 2 Fundamentação teórica p. 18 2.1 Testes de software . . . p. 18 2.1.1 Testes manuais . . . p. 19 2.1.2 Testes automatizados . . . p. 19 2.2 Mineração de repositórios . . . p. 20
2.3 Similaridade entre árvores . . . p. 20
2.4 SIGAA . . . p. 21 2.5 PerfMiner . . . p. 22 2.6 Kootenai . . . p. 23 2.7 Considerações finais . . . p. 23 3 Abordagem p. 25 3.1 Conjunto de dados . . . p. 25
3.1.1 Banco de dados do PerfMiner . . . p. 25
3.1.1.1 Definições dos dados usando Conjuntos . . . p. 26
3.1.2 Relatório de URLs mais acessadas e com mais erros no cenário
3.2 Procedimento . . . p. 28
3.2.1 Filtragem dos logs de testes . . . p. 29
3.2.2 Similaridade entre logs de testes . . . p. 29
3.2.3 Cruzamento de informações . . . p. 31
3.2.4 Considerações finais . . . p. 31
4 Estudo de caso p. 33
4.1 Período de tempo dos dados do estudo . . . p. 33
4.2 Conjunto de dados . . . p. 33
4.2.1 Banco de dados do PerfMiner do SIGAA . . . p. 34
4.2.2 Relatório com as URLs mais acessadas e com erros no cenário de
produção do SIGAA . . . p. 34
4.3 Resultados do estudo . . . p. 34
4.3.1 Filtragem dos dados . . . p. 34
4.3.2 Algoritmo de similaridade . . . p. 37 4.3.3 Cruzamento de informações . . . p. 38 4.4 Considerações finais . . . p. 39 5 Considerações finais p. 41 5.1 Principais contribuições . . . p. 41 5.2 Trabalhos relacionados . . . p. 42 5.3 Limitações . . . p. 43 5.4 Trabalhos futuros . . . p. 44 Referências p. 46
14
1
Introdução
O processo de desenvolvimento de softwares de larga escala necessita de uma maior organização e cuidado em relação ao comportamento de seus módulos, precisando de determinadas garantias que cada parte constituinte e a integração funcionem de forma adequada. (SOMMERVILLE, 2011) relata que com a expansão da engenharia de software ao longo dos últimos anos, existe uma contínua busca pela otimização de custo e de qualidade do produto de software. Uma das formas de tentar priorizar a qualidade é realizando-se testes.
Ao desenvolver um software é recomendado testá-lo antes de realmente começar a usufruí-lo, esse passo é necessário para que se tenha uma maior garantia do funcionamento adequado do sistema. Dentre os tipos de testes, os automatizados necessitam de maior prioridade em relação aos manuais.(FINSTERWALDER, 2001) defende que testes que são realizados manualmente, provavelmente não serão executados com frequência. Quando o resultado de um teste é verificado manualmente por inspeção, pode acontecer que os erros sejam negligenciados. Para evitar que isso aconteça, os testes precisam ser automatizados o máximo possível.
Em seu artigo (GAROUSI; MÄNTYLÄ, 2016) relatam que normalmente o primeiro
ins-tinto de adotar a automação de testes é apenas aplicá-lo para fazer o que os testadores humanos estavam fazendo manualmente. No entanto, (BACH, 1999) afirma que a automa-ção não pode substituir completamente o teste manual ou eliminar os custos de pessoal. Reforçando o que foi dito anteriormente, (TAIPALE et al., 2011) dizem que o
estabeleci-mento de testes automatizados pode falhar se a automação do teste não for aplicada no contexto certo e com a abordagem apropriada.
Existe a necessidade de automatizar testes, entretanto não se pode realiza-la sem ter um contexto que demande a sua automação. Caso a automação de testes seja apĺicada corretamente, (GAROUSI; MÄNTYLÄ, 2016) confirmam que ela pode diminuir considera-velmente o custo do teste e aumentar a qualidade do software. A definição de quais testes
15
serão automatizados é necessária para que se tenha os ganhos de qualidade e não haja falha no seu propósito.
1.1
Problema abordado
(BERNARDO; KON, 2008) citam em seu artigo que a abordagem manual e ad hoc leva à ocorrência de diversos problemas (tarefa tediosa, cansativa, atrasos na entrega, dificuldade de manutenção e evolução etc) e deve ser evitada. Como mecanismos alternativos para se garantir a qualidade de um software pode-se utilizar os testes automatizados, sendo uma técnica voltada principalmente para a melhoria da qualidade dos sistemas de software. Eles defendem que a automação de testes dá segurança a equipe de desenvolvimento a realizar mudanças no código de maneira a facilitar a verificação de possíveis novos bugs, adição de funcionalidades e até mesmo a manutenção do sistema. A automação de casos de teste possibilita a criação de testes mais elaborados e complexos, que poderão ser repetidos identicamente inúmeras vezes e a qualquer momento.
Em um cenário ideal, a maior parte dos testes deveriam ser automatizados, entretanto existe um custo associado a automação de testes. Diante disso, uma abordagem que possa determinar quais testes devem ser automatizados pode ajudar a diminuir os problemas associados a uma grande suíte de testes manuais.
Segundo (BERNARDO; KON, 2008) a execução manual de um caso de teste é rápida e efetiva, mas a execução e repetição de um vasto conjunto de testes manualmente é uma tarefa muito dispendiosa e cansativa. É necessário muito esforço para se realizar testes manuais, por isso existe a tendência de que esses testes sejam executados poucas vezes causando erros de regressão. A atividade de testes acaba gerando um ciclo de con-figuração/refatoração e posteriormente execução. A tendência é este ciclo se repetir até que a manutenção do sistema se torne uma tarefa tão custosa que passa a valer a pena reconstruí-lo completamente.
Um sistema que apresente uma proporção maior de testes manuais em relação aos automatizados precisa adotar alguma metodologia para tentar mudar esse fato. Uma forma de diminuir essa diferença seria automatizar testes manuais definidos existentes. Atendendo a esse ponto, segue uma nova problemática: quais seriam os testes a serem automatizados? Uma abordagem que se baseie em métricas deve ser estabelecida para que possa maximizar o ganho em relação ao esforço.
16
1.2
Abordagem proposta
Esse trabalho apresenta uma nova abordagem que busca identificar quais testes ma-nuais existentes no sistema são os melhores candidatos a serem automatizados. O objetivo principal é definir um conjunto de procedimentos que ajudem a escolher os melhores can-didatos a automação, servindo como sugestão de escolha a equipe de desenvolvimento.
A abordagem busca privilegiar a equipe de desenvolvimento da seguinte forma: (i) identificar os melhores testes manuais candidatos a serem automatizados, (ii) obter uma lista de precedência de candidatos, (iii) ter procedimentos que possam gerar resultados atualizados e (iv) obtenção da cobertura de métodos da suíte de testes manuais e auto-matizadas. Com base nisso, a equipe de testes pode planejar de forma mais precisa uma atualização no sistema.
1.3
Objetivos geral e específicos
O objetivo principal deste trabalho de conclusão de curso é identificar bons candi-datos entre os testes manuais que devem ser automatizados, no intuito de identificar o melhor subconjunto de testes manuais a partir das métricas definidas. A abordagem é aplicada no Sistema Integrado de Gestão de Atividades Acadêmicas (SIGAA) auxiliando no aperfeiçoamento da qualidade das suas suítes de testes automatizados. A abordagem pode ser aplicada a outros sistemas caso eles tenham os requisitos mínimos necessários descritos na seção 3.1. No contexto apresentado, os objetivos específicos deste trabalho são:
• Uso de métrica de análise de similaridade entre árvores, a fim de aplicar técnicas de comparação entre estruturas de registros de testes presente neste trabalho.
• Projetar e implementar procedimentos que levem em consideração a base de logs das execuções dos testes manuais e as automatizadas, conjunto com os relatórios contendo as URLs de mais erros e acessos :
– Contar o número de execuções para cada log de teste presente na base de dados do PerfMiner.
– Filtar os logs com baixa relevância.
17
– Cruzar as URLs que apresentem mais erros e acessos com os logs de testes manuais situados no PerfMiner.
• Classificar e ranquear os melhores candidatos de testes manuais (a partir dos logs obtidos) a serem automatizados utilizando os resultados dos algoritmos desenvolvi-dos.
1.4
Organização do trabalho
Este trabalho está organizado como segue: o capítulo 2 apresenta a fundamentação teórica para o entendimento do trabalho, tais como, testes de software e métrica de si-milaridade entre árvores. O capítulo 3 apresenta a abordagem definida, mostrando o que ocorre em cada um dos passos existentes. O capítulo 4 mostra os resultados da aplicação a um sistema web de larga escala, o SIGAA. O capítulo 5 exibe os trabalhos relacionados e as conclusões do trabalho, mostrando as principais contribuições, limitações e os trabalhos futuros.
18
2
Fundamentação teórica
Este capítulo apresenta conceitos importantes para a compreensão deste trabalho. A seção 2.1 explora os conceitos de teste software. A seção 2.2 discorre sobre mineração de repositórios. Na seção 2.3 discorre sobre métricas de similaridade entre árvores. A seção 2.4 apresenta o Sistema Integrado de Gestão de Atividades Acadêmicas (SIGAA) . A seção 2.5 explica a ferramenta PerfMiner. A seção 2.5 mostra a ferramenta Kootenai. Por fim, na seção 2.7 são apresentadas as considerações finais do capítulo.
2.1
Testes de software
No seu livro (DELAMARO; JINO; MALDONADO, 2017) relata que a atividade de cons-trução de software não é uma tarefa simples. Pelo contrário, pode se tornar bastante complexa, dependendo das características e dimensões do sistema. Por isso, está sujeita a diversos tipos de problemas que acabam resultando na obtenção de um produto diferente daquele que se esperava.
Muitos fatores podem acarretar esses problemas, normalmente são erros humanos. Para que tais erros não pendurem, existe a necessidade de verificação da consistência do software, uma garantia que o produto se comporte da maneira esperada. Criar testes pode ser uma alternativa que busque garantir que o sistema se comporte de acordo com a forma previamente determinada.
(PRESSMAN; MAXIM, 2016) definem em seu livro que o teste é um conjunto de ativi-dades que podem ser planejadas com antecedência e executadas sistematicamente. O que indica que a atividade de se testar um software deve apresentar um cuidado e apresentarem periodicidade.
Testes de software podem ser divididos em dois tipo : (i) testes manuais e (ii) testes automatizados. Cada um dos tipos definidos tem seu proposito e devem ser aplicados em determinados contextos da aplicação. Um software deve apresentar um equilíbrio entre
19
automatizados e manuais, caso contrário, ele tenderá a ter uma atividade de testes ineficaz.
2.1.1
Testes manuais
Em seu artigo (LEAL, 2009) define que os testes manuais consistem no desenvolvedor ou até mesmo o próprio usuário final utilizar o sistema a fim de encontrar anomalias no funcionamento do software. É o tipo de teste menos eficiente, pois dificilmente uma pessoa conseguiria testar exaustivamente um sistema de forma que não restassem possibilidades possíveis para falha. Mesmo constatada tal fragilidade em relação à cobertura, testes manuais ainda utilizados pela facilidade de aplicação, já que basta utilizar o sistema como se estivesse em ambiente de produção, simulando algumas entradas e registrando os resultados obtidos.
Portanto os testes manuais são aqueles no qual o testador realiza o passo a passo do fluxo de testes de forma que normalmente é guiada por um roteiro do que deve ser realizado e do comportamento resultante dessas ações. Nesse contexto, os testes manuais são úteis quando se precisa de agilidade na criação do teste e certa subjetividade ou análise de um ser humano nos resultados obtidos, mas não são bastante recomendados em situações onde exista a necessidade de se executar várias vezes um mesmo teste.
2.1.2
Testes automatizados
Em seu livro (BARTIÉ, 2002) define testes automatizados como a utilização de ferra-mentas de testes que possibilitem simular usuários ou atividades humanas de forma a não requerer procedimentos manuais no processo de execução dos testes. O processo de veri-ficação do atendimento ou não a especiveri-ficação é realizado totalmente por uma máquina, sem intervenção do testador durante o decorrer do teste.
Os Métodos ágeis, como o da programação eXtrema (XP) definida por (BECK; AN-DRES, 1999) defendem explicitamente o uso de automação de testes para garantir a qua-lidade dos sistema desenvolvidos. Um teste automatizado apresenta a faciqua-lidade de poder ser executado várias vezes sem apresentar de interação humana no processo, diminuindo o custo associado a ter uma pessoa alocada a executa-lo. Outros ganhos associados são a velocidade de execução, reprodutibilidade exata e possibilidade de execuções paralelas, todos essas vantagens são exposta por (BERNARDO, 2011) na sua dissertação de mestrado.
20
2.2
Mineração de repositórios
Segundo (CAMILO; SILVA, 2009), por meio do seu artigo, desde surgimento dos sistemas computacionais, um dos principais objetivos das organizações tem sido o de armazenar da-dos. Nas últimas décadas essa tendência ficou ainda mais evidente com a queda nos custos para a aquisição de hardware, tornando possível armazenar quantidades cada vez maiores de dados. Novas e mais complexas estruturas de armazenamento foram desenvolvidas, tais como: banco de dados, Data Warehouses, Bibliotecas Virtuais, Web e outras.
O autor ainda relata que por ser interdisciplinar, a mineração de dados apresenta várias definições. Neste trabalho se utiliza a mineração de dados para extrair as principais informações de um banco de dados, portanto a definição de mineração de dados associada a área de banco de dados é a utilizada para esclarecer seu significado. Segundo (CABENA et al., 1997) em seu livro, a mineração de dados associada a área de banco de cados é um campo interdisciplinar que junta técnicas de máquinas de conhecimentos, reconhecimento de padrões, estatísticas, banco de dados e visualização, para conseguir extrair informações de grandes bases de dados.
O artigo de (CAMILO; SILVA, 2009) defende que a mineração de dados é uma das tecnologias mais promissoras existentes. A chamada era da informação fez com que uma grande quantidade de dados sejam armazenados, mas nem toda essa informação é neces-sária, apenas um pequeno subconjunto de informação tende a ser expressivo.
2.3
Similaridade entre árvores
O artigo de (BILLE, 2005) informa que as árvores estão entre as estruturas combinató-rias mais comuns e bem estudadas na ciência da computação. Em particular, o problema de comparar árvores ocorre em diversas áreas, tais como como biologia computacional, bancos de dados de texto estruturados, análise de imagens, provadores automáticos de teoremas e otimização de compiladores.
Segundo (BILLE, 2005) a medida padrão para calcular a similaridade de árvores é a Tree Edit Distance (TED) . O artigo informa que a TED foi aplicada com sucesso em bioinformática (por exemplo, para encontrar similaridades entre estruturas secundárias de RNA, células neuronais ou estruturas de glicano), em análise de imagem, reconhecimento de padrões, reconhecimento de melodia, processamento de linguagem natural, extração de informação e recuperação de documentos, e recebeu atenção considerável da comunidade
21
de banco de dados.
(PAWLIK; AUGSTEN, 2016a) por meio de seu site define TED como uma métrica de comparação entre árvores rotuladas ordenadas na qual é calculada a sequência de custo mínimo das operações de edição de nós que transformam uma árvore em outra. Conside-ramos seguir três operações de edição em árvores ordenadas rotuladas:
• Excluir um nó e conecte seus filhos ao pai mantendo a ordem.
• inserir um nó entre um nó existente e uma subsequência de filhos consecutivos deste nó.
• Renomear um nó.
Existem diversas sequências diferentes que transformam uma árvore em outra. existe a atribuição de um custo a cada operação. O custo de uma sequência de operações é a soma das operações multiplicadas pelos respectivos custos. A sequência de operação que obtiver o menor valor é a escolhida.
(PAWLIK; AUGSTEN, 2015) desenvolveram um algoritmo chamado RTED que com-puta o TED, atualmente esse algoritmo foi descontinuado e (PAWLIK; AUGSTEN, 2016b) desenvolveram o APTED que o substituiu. Este algoritmo é utilizado na função T ED : TM × TA
→ N presente na equação 3.3.
2.4
SIGAA
Por meio de seu site, a (SINFO, 2017) define que o Sistema Integrado de Gestão de Atividades Acadêmicas (SIGAA) é um sistema web que informatiza os procedimentos da área acadêmica através dos módulos de: graduação, pós-graduação (stricto e lato sensu), ensino técnico, ensino médio e infantil, submissão e controle de projetos e bolsistas de pesquisa, submissão e controle de ações de extensão, submissão e controle dos projetos de ensino (monitoria e inovações), registro e relatórios da produção acadêmica dos docentes, atividades de ensino a distância e um ambiente virtual de aprendizado denominado Turma Virtual. Da mesma maneira do SIPAC também disponibiliza portais específicos para: reitoria, professores, alunos, tutores de ensino a distância, coordenações lato sensu, stricto sensu e de graduação e comissões de avaliação (institucional e docente).
Esse sistema é utilizado em diversas universidades federais e institutos federais, dentre eles a Universidade Federal do Rio Grande do Norte (UFRN), Universidade Federal Rural
22
do Semi-árido(UFERSA), Instituto Federal de Alagoas (IFAL) entre outras. A figura 1 mostra o relacionamento entre módulos do sistema.
Figura 1: Relacionamento entre módulos do SIGAA
2.5
PerfMiner
Na sua dissertação de mestrado, (SILVA, 2017) relata por meio de (PINTO, 2015) que a principal funcionalidade do PerfMiner é realizar a análise de desvio de desempenho entre duas versões de um sistema, revelando de maneira automatizada, as potenciais causas para o desvio nos cenários. Para isso, técnicas de análise dinâmica e mineração de repositório são usadas para estabelecer uma abordagem baseada em cenários para a avaliação do atributo de qualidade de desempenho, medido em termos de tempos de execução
A ferramenta PerfMiner apresenta três fases : (i) análise dinâmica, (ii) análise de des-vio e (iii) mineração de repositório. Neste trabalho utiliza-se o banco de dados resultante da análise dinâmica, no qual são armazenados os resultados das árvores de chamadas dos métodos dos testes. Dessa maneira, a base utilizada apresenta um conjunto de testes, po-dendo haver duplicações das informações armazenadas. A figura 2 presente na dissertação de (SILVA, 2017) ilustra a fase (i) do PerfMiner.
23
Figura 2: Fase (i) do PerfMiner
testes para executar uma análise dinâmica que apresenta como resultado um conjunto de cenários. Umas das informações salva nos cenários consiste na árvore de execução de chamadas dos métodos do sistema no qual os testes passaram.
2.6
Kootenai
Kootenai é uma ferramenta web que tem a pretensão de realizar consultas de relatórios de falhas enviados automaticamente para o Elastiseach da SINFO e os agrupa por pilhas de chamadas para identificar arquivos com problemas. Ela ainda permite consultar logs de acessos e erros no cenário de produção, agrupando e gerando o ranqueamento das URLs mais acessadas e com mais erros. A ferramenta está em desenvolvimento não apresentando uma versão final estabelecida.
2.7
Considerações finais
Os conceitos apresentados nesse capítulo são importantes para o entendimento geral do trabalho. Testar um software permitem melhorar a sua qualidade, dentre os tipos, os testes automatizados merecem destaque por permitir uma reprodutividade melhor e pelo menor custo associado, principalmente em relação aos testes manuais.
O PerfMiner utiliza-se de análise de repositórios para atender suas pretensões. A análise dinâmica presente resulta na criação de um banco de dados com as informações dos métodos executados durante os testes. Em relação a mineração de repositório, nem toda a informação armazenada é utilizada apenas as que são relevante a cada contexto. Cabe ao utilizador do dados escolher as melhores informações que possibilitem a extração
24
de informações.
A respeito da similaridade entre árvores, a métrica definida utiliza-se do padrão uti-lizado academicamente com algumas modificações que auxiliam a comparação entre as similaridades de árvores. Ao contrário do algoritmo APTED, a função definida neste tra-balho informa valores entre 0 e 1 ao invés de um número de operações que não é expressivo suficiente na comparação entre valores. Esse fator motivou a criação de uma função que utilizasse o algoritmo APTED e não simplesmente a sua reprodução.
O SIGAA consiste em um sistema de bastante importância para a comunidade acadê-mica, principalmente por apresentar institutos e universidades federais o utilizando. Ele consiste em um grande sistema web que garante uma boa validação para abordagem. A ferramenta Kootenai auxilia a obter os relatórios com as URLs mais acessadas e com mais erros no cenário de produção do SIGAA, essa funcionalidade permitiu o estudo de caso aplicado neste trabalho.
25
3
Abordagem
Este capítulo apresenta a abordagem utilizada. A seção 3.1 mostra os objetivos espe-cíficos da abordagem. As seções 3.2 e 3.3 descrevem o conjunto de dados e procedimento, respectivamente, destacando suas relações, características e funcionamento. Por fim, são reportadas considerações finais sobre o capítulo na seção 3.4
3.1
Conjunto de dados
Esta seção apresenta os dados utilizados nos algoritmos, relatando suas especifidades e as respectivas estruturas de dados necessárias. O conjunto de dados presentes são : (i) banco de dados do PerfMiner e (ii) Relatório de URL s mais acessadas e com mais erros de funcionalidade do sistema que executam no ambiente de produção.
3.1.1
Banco de dados do PerfMiner
A execução do PerfMiner por um determinado período de tempo resulta em uma base de dados com as informações relacionadas as execuções das suítes de testes. Para aplicar a abordagem proposta é necessário utilizar o PerfMiner na suíte de testes manuais e na suíte automatizada, resultando duas bases estruturalmente idênticas, variando apenas as instâncias obtidas. A Figura 3, definida por (SILVA, 2017), mostra uma representação usando dados do PerfMiner.
Segudo (SILVA, 2017), cada teste executado é considerado um Scenario e cada método executado pelo teste como Node. Cada teste apresenta uma árvore n-ária de seus métodos, representando as chamadas de métodos realizadas durante a execução do teste. Uma forma intuitiva de representar os dados obtidos no PerfMiner é utilizando conjuntos. Com finalidade didática, definições foram realizadas usando conjuntos para representar e operar os dados obtidos do PerfMiner. Essas definições são denotados na seção 3.1.1.1 e utilizadas posteriormente na aplicação dos algoritmos propostos.
26
Figura 3: Diagrama de classes parcial do modelo de análise do PerfMiner
3.1.1.1 Definições dos dados usando Conjuntos
Algumas definições foram realizadas utilizando conjuntos para ajudar no entendi-mento e operações de manipulação dos dados. A denotação por conjuntos é possibilitadas pelo fato deles estarem armazenados em um banco de dados relacional.
Tome MM o conjunto geral de todos os métodos presente na base de dados manual e MA o conjunto de todos os métodos presentes na base de dados automatizadas. O conjunto M = MM∪ MA denota o conjunto total de métodos em ambas as bases. Tome
TM o conjunto geral de todos os testes presente na base de dados manual e TA conjunto
de todos os testes presentes na base de dados automatizadas. O conjunto T = TM ∪ TA
denota o conjunto total de testes de ambas as bases.
Definido M , a equação 3.1 define cada elemento Mx ∈ M . Em que nome é o nome do
método e pai é o elemento de M que é pai de Mx.
Mx = {nome ∈ String∗, pai ∈ M } (3.1)
Definido T , o conjunto 3.2 define cada elemento Tx ∈ T . Em que nome é uma string
não vazia com o nome do teste, quantExec o número de execuções de cada teste, raiz re-presenta o primeiro método executado no teste, url a URL de execução do teste, quantN os a quantidade de métodos que o teste executa e grupo um atributo string usado para definir a classe de agrupamento do teste.
27 Tx = {nome ∈ String+, quantExec ∈ N, raiz ∈ M, url ∈ String∗, quantN os ∈ N grupo ∈ String∗} (3.2)
Dado um conjunto fictício M0 = {m2, m3, m4, m5, m6} tal que M0 ⊂ M representa
o conjunto de descendentes de um método m1 ∈ M . A figura 4 mostra visualmente a
estrutura do atributo raiz pertencente T1 ∈ T em que T1.raiz = m1, consistindo da
árvore de chamadas dos métodos executados no teste, respeitando a ordem das chamadas e as relações de parentesco entre os métodos.
m1
m2 m3
m4
m5 m6
Figura 4: Estrutura do atributo raiz de T1
A forma na qual o PerfMiner armazena as informações dos descendentes dos métodos permite que se possa usar a estrutura de dados árvore n-ária para representação e compu-tação de operações. A estrutura de árvore n-ária é utilizada no algoritmo de similaridade proposto para definir o quão um teste é parecido estruturalmente com outro teste.
3.1.2
Relatório de URLs mais acessadas e com mais erros no
ce-nário de produção.
Nos algoritmos propostos é necessário um relatório que tenha no mínimo uma lista com a quantidade e o endereço das URLs mais acessadas e que tiveram mais erros em produção. Tais informações são utilizadas na seção 3.2.3 para definir o ranqueamento
28
dos melhores candidatos dos testes manuais para serem automatizados. A listagem por meio de um JavaScript Object Notation (JSON) é uma boa opção por apresentar uma padronização mas qualquer outra forma de representação que seja determinística também é aceitável.
3.2
Procedimento
O procedimento realizado nesse estudo baseou-se no desenvolvimento de vários al-goritmos que juntos possibilitam escolher o subconjunto dos melhores testes manuais a serem automatizados. Para atingir o objetivo proposto, o procedimento se baseia nos se-guintes passos que são descritos nas subseções a seguir : (i) filtragens dos logs de testes, (ii) similaridade dos logs de testes, (iii) cruzamento de informações. A Figura 5 mostra a esquemática do procedimento geral da abordagem.
Filtragem dos logs de testes
duplicados
Logs de testes manuais Logs de testes automatizados
Similaridade dos logs de testes
Logs manuais sem similaridade Logs manuais com similaridade
Logs manuais únicos Logs automatizados únicos
Cruzamento
de informações URLs mais acessadas URLs com mais erros
Ranqueamento de testes manuais
Figura 5: Estrutura da abordagem realizada
Em azul e com bordas arredondadas estão os dados de entrada para cada passo do procedimento e em laranja estão os passos realizados na abordagem definida. Primeira-mente é realizado a filtragem dos logs duplicados, recebendo como entrada o conjunto de registros de testes manuais e automatizados, o que resulta em dois subconjuntos de logs filtrados. Posteriormente realiza-se uma análise de similaridade entre os manuais e os automatizados retornando o mesmo conjunto de entrada dos manuais atualizado com
29
a informação do log automatizado mais similar para cada um deles. Por último, cruza-se as informações dos registros de testes manuais e as URLs com mais erros e acessos. Ao fim, é oferecido um ranqueamento dos registros de testes manuais que são os melhores candidatos a serem automatizados.
3.2.1
Filtragem dos logs de testes
A fase de filtragem de testes consiste em eliminar registros duplicados e que sejam pouco relevantes para o estudo. Como resultado, essa fase gera um subconjunto de testes únicos adicionado com a informação da quantidade de execuções presentes na base de dados do PerfMiner.
Essa etapa envolve na composição de dois filtros : (i) filtro que retira as duplicadas e conta a quantidade de execuções de cada log de teste e (ii) filtro que retira os testes considerados irrelevantes para o estudo. A retirada de logs de testes duplicados ocorre com a escolha de único log de cada classe de equivalência criada pelo filtro. A determinação da equivalência entre logs de testes é realizada verificando igualdade entre nome e se a estrutura da árvore de chamadas dos métodos são equivalentes, de modo que para cada par de métodos a ser comparados, ambos apresentem o mesmo nome e tenham os mesmos filhos.
O filtro (i) é aplicado tanto na base de registros de testes manuais como dos automati-zados gerando dois conjuntos de saída. Dos conjuntos de saída: o dos manuais aproveitado como entrada do filtro (ii) e o dos automatizados foi utilizado no algoritmo de similari-dade, que é explicado na seção 3.2.2. Após a primeira filtragem, o filtro (ii) exclui os os registros manuais que tenham o número de execuções menor que dois, ou seja que tenha sido executado apenas uma única vez.
3.2.2
Similaridade entre logs de testes
Com os resultados dos filtros definidos na seção 3.2.1, o próximo passo é a quantifica-ção da similaridade entre cada teste manual com cada um dos automatizados. O resultado desse algoritmo será o conjunto de logs de testes manuais de entrada com a informação adicional de qual teste automatizado apresenta maior similaridade (de 0 a 100%) para cada um deles. Caso um log manual tenha similaridade de 0% com todos os testes auto-matizados, ele é classificado como "nenhum similar". Este procedimento define uma das métricas utilizada na seção 3.2.3.
30
A porcentagem significa a proporção do quão parecido são as estruturas do atributo raiz de cada teste entre si. Para determinar o maior valor de similaridade é necessário calcular todas as combinações par-a-par entre os conjuntos de testes (manual x automa-tizado). A quantificação da similaridade entre dois logs de testes é realizada utilizando uma função similaridade : TM × TA → [0, 1]. A equação 3.3 demonstra como a função
similaridade é elaborada : similaridade(TxM, TyA) = 1 − T ED(T M x , TyA) TM x .quantN os + TyA.quantN os (3.3)
A equação 3.3 utiliza da função T ED : TM × TA
→ N que calcula a Tree Edit Distance entre duas árvores (logs de testes). O algoritmo padrão do T ED utiliza-se de três pesos de entrada: (a) renomear um nó, (b) deletar um nó e (c) inserir um nó. Os pesos representam o custo associado a operação. Neste projeto, decidiu-se utilizar apenas operações de inserção e remoção para cálculo do TED, por esse motivo o valor de (a) foi definido como o custo máximo permitido no algoritmo e os pesos de (b) e (c) foram definidos como 1. Ao fazer o custo de remoção tender ao valor máximo, o algoritmo de TED irá calcular a sua métrica usando apenas inserções e remoções.
Dado duas árvores TM
x e TyA, é possível determinar a maior similaridade entre elas
sendo T ED(TxM, TA
y ) = 0, que significa que as árvores TxM e TyA são exatamente iguais
e nenhuma operação é necessária para transformar uma na outra. A menor similaridade é denotado por T ED(TM
x , TyA) = TxM.quantN os + TyA.quantN os, que representa excluir
todos os nós de TM
x e inserir todos os nós de TyA ou excluir todos os nós de TyA e inserir
todos os nós de TxM.
Definiu-se os valores de máximo e mínimo entre o resultado possível do TED para dois testes quaisquer. Por meio deste raciocínio, a função 3.3 mede de forma diretamente proporcional o valor à similaridade, quanto mais próximo de 1 mais parecidos estrutu-ralmente os testes são entre si e quanto mais próximo de zero mais diferentes eles são. Obtido os logs de testes manuais e automatizados, cria-se uma matriz de similaridade, em que cada linha é um log de teste manual, cada coluna é um log de teste automatizado e o valor da célula é a similaridade entre os logs da respectiva linha com o da respectiva coluna. Dessa forma, a definição da maior similaridade do log de teste manual com um dos automatizados ocorre com a análise da linha do respectivo log, em que o maior valor presente na linha evidencia a coluna do teste automatizado mais similar.
31
dois grupos distintos mutualmente excludentes : aqueles que apresentam alguma simila-ridade e aqueles que são totalmente diferentes. O conjunto dos logs de testes manuais totalmente diferente dos de automação serão os melhores candidatos, por essa métrica, a serem automatizados. O fato deles não terem nenhum método contemplado pelo testes automatizados evidencia que sua automação gerará um maior aumento de cobertura de métodos a suíte de testes automatizada. O conjunto de logs de testes manuais que não apresentam nenhuma similaridade ou tenham valor de similaridade baixo com os logs dos testes automatizados serão utilizados no algoritmo da seção 3.2.3.
3.2.3
Cruzamento de informações
Este é o último passo do procedimento realizado, consistindo em utilizar os dados da seção 3.2.2 junto com relatórios com as URLs mais acessadas e com mais erros do sistema. A URL apresenta um conjunto de informações associadas, dentre elas estão : esquema ou protocolo, domínio, porta, caminho, string de busca e fragmento. Num cenário de produ-ção é possível existir mais de um domínio a ser testado, de forma que um mesmo teste pode ser executado para vários domínios, entretanto por mais que haja essa pluralidade, o caminho tende a ser o mesmo por estar diretamente associado aos recursos da aplica-ção. Na comparação entre URLs dos relatórios e dos testes, compara-se apenas se URLs são iguais, desprezando os outros atributos das URLs. O cruzamento dessas informações serve para criar um ranqueamento dos melhores candidatos dos testes manuais a serem automatizados. Testes cuja URL de execução não exista nos relatórios são descartados.
A decisão de qual teste a ser automatizado leva em consideração três critérios nessa respectiva ordem de prioridade e desempate (i) número de execuções, (ii) número de erros e (iii) número de acessos. O conjunto de saída é ordenado de forma decrescente utilizando os critérios definidos e posteriormente, os 10 primeiros testes são selecionados. O subconjunto de 10 elementos selecionados são os considerados de maior prioridade na automação de testes, pelo fato de estarem sendo bastante executados, apresentarem mais erros e acessos em produção.
3.2.4
Considerações finais
A abordagem definida nesta seção descreve o principal funcionamento de toda a esque-mática realizada neste trabalho de conclusão de curso. Dentre as principais funcionalidades e conhecimentos formulados podem se destacar os seguintes:
32
• Função de similaridade: Definição de uma função de similaridade que quantifica o quanto uma árvore é similar a outra utilizando-se da métrica de TED para quanti-ficação entre 0% e 100%.
• Cruzamento de informações: Definição de uma ordem de prioridade de relevância entre grandezas distintas para um mesmo propósito.
A função de similaridade entre duas árvores permite não apenas quantificar o quanto estruturalmente uma árvore é parecida com outra mas também a porcentagem de simi-laridade entre elas. A função permite relacionar a simisimi-laridade ao tamanho das árvores, podendo assim promover comparações entre similaridades de uma forma mais justa do que apenas pela quantidade de operações.
O cruzamento de informações distintas que tem propósitos diferentes permite que vários pontos de vistas de um mesmo dado sejam avaliados. Dessa forma a diversidade de análises possibilita que se tenha uma decisão mais coerente e embasada. Analisar a quantidade de erros e acessos das URLs juntamente com a quantidade execuções de cada teste permite garantir um análise que atende aos locais mais críticos do sistema, tanto do ponto de vista operacional como no ponto de vista do cenário de testes.
33
4
Estudo de caso
Este capítulo apresenta a aplicação da abordagem definida em um sistema web real de larga escala chamado SIGAA desenvolvido pela SINFO da UFRN . A seção 4.1 apresenta informações do intervalo temporal dos dados usados no estudo. Na seção 4.2 é definida o conjunto de dados utilizados em relação a abordagem denotada na seção 3.1. A seção 4.3 mostra os resultados da aplicação de cada procedimento no SIGAA e por último na seção 4.4 são feitas considerações finais sobre o capítulo.
4.1
Período de tempo dos dados do estudo
O SIGAA, pelo menos no período de obtenção da base de dados, fazia uso do PerfMiner e, portanto, o seu banco de dados no período de 12/09/2017 à 31/10/2017 foi utilizado como base nesse estudo. Um relatório com as URLs mais acessadas e com erros do SIGAA em produção foi obtido usando a ferramenta Kootenai, sendo os valores do período de 25/03/2019 à 24/04/2019. Obtido o banco de dados e os relatórios é possível aplicar o conjunto de procedimentos estabelecidos anteriormente e assim obter resultados que mostram quais os melhores candidatos dos testes manuais a serem automatizados.
4.2
Conjunto de dados
Esta seção apresenta os dados do SIGAA aplicado na abordagem definida nesse tra-balho de conclusão de curso. Vale lembrar que para executar os procedimentos existentes é necessário ter-se um banco de dados com os valores populados pelo PerfMiner ou que apresentem a mesma estrutura e um ou mais relatórios que mostrem as URLs mais aces-sadas e com mais erros. Todos os passos foram realizados e seus resultados são divididos com a mesma estrutura definida na abordagem, dentre eles estão : (i) filtragem dos dados, (ii) similaridade entre logs de testes e (iii) ranqueamento de logs de testes.
34
4.2.1
Banco de dados do PerfMiner do SIGAA
A base de dados do PerfMiner do SIGAA apresenta as informações necessárias para utilização dos procedimentos. São necessários dois bancos de dados com os logs das exe-cuções dos testes: (i) manual e (ii) automatizados. A base de dados dos logs de testes manuais do SIGAA coletada apresenta 59.834 registros de execuções, enquanto a base automatizada de logs de testes apresenta 512 registros. Em relação aos métodos presen-tes em cada presen-teste, a base manual possui um conjunto total de 5.260.556 de registros de métodos enquanto que a base automatizada apresenta 1.701 registros. Os testes manu-ais utilizados no SIGAA são testes exploratórios que apresentam um roteiro com uma pequena descrição do que deve-se ser testado. Em relação a seus logs das execuções dos testes, um registro presente no PerfMiner pode conter um caso de teste executado ou uma funcionalidade compartilhada entre diferentes casos de testes.
4.2.2
Relatório com as URLs mais acessadas e com erros no
ce-nário de produção do SIGAA
O uso da ferramenta Kootenai permitiu obter os endereços do sistema que mais sejam acessados e que mais apresentaram erros no cenário de produção dos sistema. Dois rela-tórios foram criados: (i) com as URLs que apresentam mais erros e (ii) com as URLs mais acessadas. O relatório (i) apresenta um conjunto de 927 registros ranqueados de maneira decrescente em relação a quantidade de erros por URL. O relatório (ii) denota de 14.179 registros com os endereços web do sistema que foram mais acessados no período da coleta, organizados de forma decrescente de acordo com a quantidade de acessos.
4.3
Resultados do estudo
No estudo foram aplicados todos os procedimentos descritos na abordagem. Para cada um desses procedimentos são definidos resultados intermediários. Ao término da aplicação do estudo, um conjunto com os 10 melhores candidatos de testes manuais do SIGAA a serem automatizados são apresentados.
4.3.1
Filtragem dos dados
A filtragem dos dados das execuções das suítes de testes manuais e automatizadas do SIGAA foram realizados de acordo com as definições na seção 3.2.1. Como entrada dos
35
testes manuais teve-se um conjunto de 59.834 registros e dos testes automatizados de 512 registros. Primeiramente realizou-se a aplicação do filtro (i) nestas duas bases de dados. A figura 6 mostra o resultado da aplicação do filtro (i) à base de dados dos testes manuais do sistema.
Logs únicos 7.285
Logs duplicados
52.549
Figura 6: filtro (i) aplicado nos logs de testes manuais
O filtro (i) aplicado na base manual do SIGAA excluiu um conjunto de 52.549 registros (87.8%) do conjunto total de registros de entrada e resultou em 7.885 (12.2%) registros a serem utilizados no filtro (ii). Da mesma maneira, utilizou-se o filtro (i) na base dos registros das execuções dos testes automatizados. A figura 7 demonstra o resultado da aplicação do filtro (i) na base de dados automatizada do SIGAA.
Logs únicos
176
Logs duplicados
336
Figura 7: filtro (i) aplicado nos logs de testes automatizados
O filtro (i) aplicado na base automatizada do SIGAA excluiu um conjunto de 336 registros (65.6%) do conjunto total de testes de entrada e resultou em 176 (34.4%) registros
36
a serem utilizados no algoritmo de similaridade. Finalizado o uso do filtro (i), o próximo procedimento é utilizar o filtro (ii) tendo como entrada o resultado do filtro (i) aplicado a base dos logs manuais. A figura 8 mostra o resultado de se aplicar o filtro (ii) na saída do filtro (i) dos manuais, que apresenta 7.285 logs de testes manuais únicos.
Logs únicos relevantes
1.799
Logs únicos não relevantes
5.486
Figura 8: filtro (ii) aplicado nos logs de testes manuais resultantes do filtro (i)
O filtro (ii) aplicado ao resultado do filtro (i) excluiu um conjunto de 5.486 registros (75.3%) do conjunto total de logs de testes de entrada e resultou em 1.799 (24.7%) registros a serem utilizados no algoritmo de similaridade. Houve uma grande filtragem de registros realizadas pelos filtros (i) e (ii), principalmente na base manual. A figura 9 denota a quantidade de registros desprezados (excluídos) pelos filtro (i) e (ii) e os logs únicos relevantes em relação a quantidade total presente na base manual.
Logs únicos relevantes 1.799
Logs desprezados
58.035
Figura 9: Aplicação do filtro (i) e (ii) nos logs dos testes manuais
Da base manual total 58.035 (96,99%) de registros foram desprezados, ou seja, são duplicadas ou são irrelevante para o estudo. Um total de 1.799 (3,01%) logs únicos
relevan-37
tes foram obtidos para a sequência do procedimento. Seguindo a abordagem, o próximo procedimento realizado será a verificação da similaridade entre os 1.799 logs de testes manuais únicos relevantes com os 176 logs de testes automatizados únicos.
4.3.2
Algoritmo de similaridade
Neste procedimento é utilizado os dados obtidos na seção 4.3.1. Para cada log manual único relevante definido (1.799 registros) foi realizado um cruzamento com cada um dos automatizados únicos (176 registros) no intuito de descobrir a relação de similaridade entre os dois conjuntos de dados. Uma matriz de 1799 linhas por 176 colunas foi construída com os valores obtidos ao aplicar a função de similaridade definida na equação 3.3 para o cruzamento de cada log de teste manual com cada log de teste automatizado.
Obtido a tabela com todas as similaridades, houve a tentativa de categorização do registro de teste automatizado mais similar para cada registro de teste manual. Vale lembrar que existe a possibilidade de nenhum log de teste automatizado ser similar a um log de teste manual. Usando o procedimento definido no item 3.2.2, obteve-se toda a classificação dos logs de testes manuais dividindo em dois conjuntos: logs de testes manuais com nenhuma similaridade aos logs de testes automatizados e logs de testes manuais que apresentasse pelo menos um dos logs de testes automatizados similar. A figura 10 mostra a quantidade do conjunto de registros de testes com similaridade e do conjunto de registros de testes sem similaridade do estudo.
Logs com 0% similaridade
1298
Logs com similaridade maior que 0% 501
Figura 10: Resultado da divisão dos logs de testes manuais pela similaridade
Um conjunto com 1.298 (72,15%) de logs de testes manuais não apresentaram ne-nhuma similaridade com os registros dos testes automatizados, enquanto que 501 (27,85%) dos logs de testes manuais apresentaram pelo menos um registro de teste automatizado
38
similar. Os logs de testes sem similaridades são utilizados no algoritmo de cruzamento de informações enquanto os restantes são removidos da próxima análise.
4.3.3
Cruzamento de informações
Nesta seção são realizados os cruzamento das informações conseguidas na seção 4.3.2 (o conjunto de logs de testes manuais sem similaridade) com os relatórios obtidos do uso da ferramenta Kootenai no SIGAA das URLs mais acessadas e que apresentam mais erros. O resultado consiste em um ranqueamento com os 10 principais candidatos a serem automatizados aplicando a abordagem denotada na seção 3.2.3. A tabela 1 lista os 10 lgos de testes manuais mais indicados a serem automatizados em ordem decrescente de relevância.
Tabela 1: Tabela com os melhores candidatos a serem automatizados
ID Nome do registro de teste Execuções Erros Acessos 19.514 EmitirGRUPagamentoMultasBibliotecaMBean 1.816 3.831 2.217.860 38.885 TermoAutorizacaoPublicacaoMBean 1.816 587 285.531 8.186 SolicitarReservaMaterialBibliotecaMBean 1.816 434 250.869 7.629 JustificativaAusenciaCICMBean 1.748 3.831 2.217.860 22.568 SolicitacaoEmprestimoEntreBibliotecasMBean 1.554 3.831 2.217.860 34.521 SolicitacaoAgendamentoMBean 1.400 434 250.869 24.691 SolicitacaoReposicaoAvaliacaoMBean 1.298 3.831 2.217.860 20.721 MonitoriaMBean 1.202 2 490 36.199 CargaHorariaPIDMBean 852 434 250.869 40.231 SituacaoTurmaMBean 717 11 24.339
A tabela apresenta cinco colunas significando: (i) índice único do log de teste na base de dados, (ii) nome simplificado do log de teste, (iii) número de execuções manuais do log de teste obtido, (iv) quantidade de erros presente na URL na qual o teste do log foi executado e (v) o número de acessos da URL do teste do log. Por mais que apresentem um mesmo nome e possam ser o mesmo teste descrito na hora de execução, se as árvores de chamadas dos métodos forem diferentes, o algoritmo de retirada de duplicadas trata-os como dois logs distintos, dessa forma pode-se ter testes reais iguais que sejam tratados de forma distinta pelos procedimentos desenvolvidos. Tal acontecimento não ocorreu na tabela 1 mas existe no A.
A quantidade de redundância e ambiguidade dos nomes dos logs de testes presentes na base de dados do PerfMiner impossibilita que se possa caracterizar unicamente um log de teste por esse atributo, por causa dessa problemática fez-se necessário utilizar o índice
39
único do registro de teste no banco de dados para que outras informações associadas aos testes sejam retornadas caso haja necessidade.
Observando-se a tabela 1, nota-se que existe um conjunto de repetições de números nas colunas de erros e acessos entre diferentes logs de testes, esse fato ocorre por eles poderem ter uma mesma URL de execução. Um conjunto de testes são executados por página, então é previsível que exista vários logs de testes com uma mesma URL.
4.4
Considerações finais
A aplicação da abordagem definida em um sistema Web de grande porte como o SI-GAA permite garantir a reprodutividade dos procedimentos definidos e permite expressar a pertinência de um estudo na automação de testes manuais. A análise dos caminhos das URLs que mais apresentam erros e acessos no cenário de produção auxilia a embasar o ranqueamento e permite determinar testes que sejam executados em locais mais críticos do sistema, em relação as suas falhas como pelo recurso mais utilizado.
Um conjunto de 10 testes manuais foi escolhido, para isso, realizou-se um ranquea-mento de todos testes manuais não similares existentes dos melhores candidatos a auto-mação. A tabela com a classificação ordenada de maneira decrescente de importância com os cem testes mais indicados a serem automatizados pode ser consultada no apêndice A.
O estudo realizado permite identificar os testes mais relevantes da suíte de acordo com as métricas definidas. Neste capítulo dois principais fatos apresentaram destaque:
• Proporção entre logs de testes automatizados e manuais : De acordo com a base analisada, a quantidade de execuções entre as suítes manuais e automatizadas apre-sentam grande disparidade. Valores entre elas são de 59.834 e 512, respectivamente. A proporção é maior que 116:1, sendo um indicativo da pertinência do estudo para o sistema SIGAA.
• Candidatos a serem automatizados : O conjunto de logs de testes recomendados no estudo evidenciaram, além das suas respectivas quantidades de execuções, que seus caminhos de recursos apresentam uma grande quantidade de erros e acessos. Testes manuais que apresentam muitas execuções, estão em locais do sistema com mais erros e mais acessos apresentam ser os melhores a serem automatizados.
40
eles possam melhorar a sua suíte de testes. Acreditando que exista a necessidade de ser aumentar a suíte de testes automatizados do SIGAA, o relatório deste estudo permite um embasamento na decisão dos testes manuais a serem contemplados.
41
5
Considerações finais
Este trabalho desenvolveu uma nova abordagem para auxiliar na decisão de quais testes manuais devem ser automatizados, validada por meio de sua aplicação a um software web de larga escala como o SIGAA. Apresentando um conjunto de passos que podem ser utilizados em outros sistemas webs, necessitando que se tenha o conjunto dos logs das execuções dos testes manuais e automatizadas, junto com os relatórios das URLs mais acessadas e com erros do sistema. Os resultados obtidos foram a própria abordagem, junto com os resultados da aplicação do estudo e, por fim mas não menos relevante, a definição de uma nova métrica de similaridade entre árvores que utiliza como base a métrica TED, com o diferencial de ser mais precisa (permitir quantificar similaridade idependente do tamanho das árvores) na comparação entre similaridades.
O restante deste capítulo está organizado dessa forma: a seção 5.1 mostra as principais contribuições do trabalho, a seção 5.2 relata os trabalhos relacionados, a seção 5.3 expõe as limitações do trabalho e a seção 5.4 apresenta perspectivas para trabalhos futuros e melhorias da abordagem atual.
5.1
Principais contribuições
Este trabalho de conclusão de curso apresentou diversas contribuições principalmente relacionadas a testes de software, dentre elas estão:
• Nova abordagem para escolher testes manuais a serem automatizados para sistemas webs: definição de vários procedimentos que possam determinar quais os melhores testes manuais candidatos a serem automatizados, utilizando-se de cruzamento de métricas que analisam pontos de vista distintos, complementando a validação da metodologia na sua aplicação em um software web de grande porte, o SIGAA.
• Resultado da abordagem aplicada a um software web consolidado: A abordagem aplicada ao SIGAA permitiu a elaboração de uma tabela que lista os melhores
42
candidatos a serem automatizados, podendo servir como base para o momento em que a SINFO desejar adicionar testes a sua suíte automatizada.
• Definição de uma métrica de comparação entre árvore: A função de similaridade define uma nova métrica, entre 0 e 1, representando o quão similar são estrutural-mente duas árvores. A métrica, apesar de utilizar uma versão específica do TED, acaba sendo mais expressiva por permitir identificar a árvore mais similar dentre um conjunto de árvores, independente da quantidade de nós presentes nas árvores comparadas.
5.2
Trabalhos relacionados
Esta seção apresenta os trabalhos relacionados aos conteúdos abordados nesse traba-lho. A maioria dos trabalhos são relacionados com testes mostrando os pontos positivos e negativos da aplicação de automação de testes, comparando-os com os manuais. Alguns deles são sobre ferramentas que utilizam testes manuais e automatizados para calcular métricas. No entanto, nenhuma dessas abordagem lidam com similaridade entre testes ou escolha de quais os melhores candidatos a serem automatizados.
(FERNANDES, 2016) desenvolveu um estudo contendo cinco cenários de teste e cinco dispositivos. Para isso foram executados testes manuais e automatizados, com o objetivo de comparar a sua eficiência. Ao final, foi observado que a execução dos testes automati-zados em paralelo apresentaram uma eficiência de 45,86% no tempo de execução. A figura 11 elaborada pelo autor define a metodologia presente no trabalho.
A metodologia aplicada utilizou-se de um estudo de caso para validar a ideia que testes automatizados apresentam melhor escalabilidade. Nos resultados encontrados, os testes automatizados apresentaram maior tempo de execução que os testes manuais, mas ao realizar um paralelismo nos automatizados o tempo passou a ser muito menor que os testes manuais.
Martins et al (2016) desenvolveram um estudo de caso para a plataforma Flex, sendo esta uma estrutura de aplicativos de software livre altamente produtiva para a criação e manutenção de aplicativos Web. Buscou-se compreender e se quantificar o tempo ne-cessário para se realizar testes manuais em relação a testes automatizados. Ao concluir o estudo, obteve se como tempo total de criação dos testes, criação dos scripts (apenas nos testes automatizados) e tempo de execução dos testes maior para os testes automatizados. Ao se analisar apenas os resultados finais, aparenta que os testes manuais são mais
rápi-43
Figura 11: Metodologia do estudo
dos, em relação ao tempo total, que os respectivos automatizados. Entretanto, o tempo de execução dos manuais foram maiores que os automatizados. Analisando os resultados do estudo, acredita-se que com um maior número de execuções dos testes elaborados, os testes automatizados virão a ter um tempo total menor que os testes manuais.
(LEITNER et al., 2007) implementaram uma ferramenta chamada AutoTest que que
fornece a estratégia "o melhor dos dois mundos": integra os casos de teste dos desenvol-vedores em um processo automatizado de testes sistemáticos por contrato. Isso permite combinar os benefícios de ambas as abordagens, mantendo uma interface simples, e tra-tar os dois tipos de testes de forma unificada: a avaliação dos resultados é a mesma, as medidas de cobertura são adicionadas e os dois tipos de testes podem ser salvos.
5.3
Limitações
Este trabalho apresenta limitações relacionada a diversas partes, deste a abordagem como também em relação aos dados utilizados. Durante o seguimento desta seção são mostrados todas as problemáticas existentes.
Escalabilidade: Os procedimentos realizados pela abordagem necessitam de grande processamento para realizar a primeira parte da abordagem, a filtragem dos dados. Em particular o primeiro filtro necessita de muito tempo de processamento, já que a computa-ção de igualdade entre testes deve ser feita analisando estruturalmente método a método. O algoritmo desenvolvido e utilizado é determinístico mas necessita de muito
processa-44
mento. Para o filtro i em específico, foram utilizados técnicas de concorrência e mapas para agilizar o processo. Mesmo utilizando várias técnicas de otimização quando possível, o tempo de retirar as duplicadas dos dados no estudo realizado foi de aproximadamente 15 horas mesmo utilizando um banco de dados indexado.
PerfMiner: A abordagem foi desenvolvida tendo como entrada o banco de dados da primeira fase do PerfMiner. Esta condição fez com que a abordagem fosse dependente de resultados intermediários da ferramenta, acarretando em um requisito a mais. A necessi-dade de se ter um banco de dados que tenham as informações das árvores de chamadas do método faz com que a abordagem utilizada não possa ser utilizada em qualquer sistema web.
Análise dinâmica: A geração das árvores de chamadas dos métodos do sistema na qual o teste passou, consiste em um procedimento que só permite que seja executado em uma forma determinística, por uma análise dinâmica. Este fato impossibilita que estaticamente se possa ter os dados necessários para realização da abordagem.
Algoritmo APTED: No site de (PAWLIK; AUGSTEN, 2016a), os autores informam que o uso de árvores com tamanho maior de 40.000 pode comprometer o resultado do algoritmo. Eles acreditam que isso possa ocorrer pelo fato deles terem utilizando o tipo float para armazenar os valores de custo das operações.
5.4
Trabalhos futuros
A construção de uma nova abordagem para ranqueamento de testes manuais a serem automatizados abre um conjunto de possibilidades para o uso ou aperfeiçoamento. Segue no decorrer dessa seção, apresenta-se ideias de ferramentas que utilizem da abordagem definida ou aperfeiçoamentos que possa ser realizados no andamento da pesquisa.
Uso de aprendizado de máquina: A desenvolvimento definida utiliza-se de uma análise não incremental, ou seja, caso um grande conjunto de teste manual seja automati-zado ou se adicione um novo teste automatiautomati-zado é necessário executar toda a abordagem novamente para determinar novos melhores candidatos. No intuito de diminuir esse custo, uma proposta futura é utilizar de algoritmos de aprendizagem de máquina para gerar rapidez na determinação de novos candidatos a serem automatizados.
Automação: A obtenção dos dados se dá através da base de dados gerada por uma das etapas do PerfMiner. A configuração do suporte para uso do PefMiner não é automatizada,
45
acarretando em uma momento manual. O uso de instalação do PerfMiner via Maven ou Gradle e uma execução da analise dinâmica em segundo plano no momento dos testes facilitaria o uso da ferramenta no ambiente de produção do sistema.
Customização: Atualmente a abordagem foi desenvolvida para ter como base de obtenção das árvores de chamadas dos métodos do sistema nos testes um banco de dados relacional. Uma mudança para permitir novos formatos de entrada, como arquivos JSON, facilitaria a adoção da abordagem em mais sistemas. A criação de interfaces e classes abstratas pode auxiliar a construção de extratores próprios para uso dos usuários finais ajudaria a validar a estrutura do código e simplificaria a extensão de funcionalidades.
46
Referências
BACH, J. Test automation snake oil. In: Proceedings of the 14th International Conference and Exposition on Testing Computer Software (TCS’99). [S.l.: s.n.], 1999.
BARTIÉ, A. Garantia da qualidade de software. [S.l.]: Gulf Professional Publishing, 2002.
BECK, K.; ANDRES, C. Extreme programming: Embrace change. [S.l.]: Addison-Wesley, 1999.
BERNARDO, P. C. Padrões de testes automatizados. Dissertação (Mestrado) — Universidade de São Paulo, 2011.
BERNARDO, P. C.; KON, F. A importância dos testes automatizados. Engenharia de Software Magazine, v. 1, n. 3, p. 54–57, 2008.
BILLE, P. A survey on tree edit distance and related problems. Theoretical computer science, Elsevier, v. 337, n. 1-3, p. 217–239, 2005.
CABENA, P. et al. Discovering data mining: from concept to implementation. [S.l.]: Prentice Hall PTR New Jersey, 1997.
CAMILO, C. O.; SILVA, J. C. d. Mineração de dados: Conceitos, tarefas, métodos e ferramentas. Universidade Federal de Goiás (UFC), p. 1–29, 2009.
DELAMARO, M.; JINO, M.; MALDONADO, J. Introdução ao teste de software. [S.l.]: Elsevier Brasil, 2017.
FERNANDES, L. R. e A. Uma comparação entre testes manuais e tes-tes automatizados para garantia da qualidade em softwares para disposi-tivos móveis. Revista Eletrônica Argentina-Brasil de Tecnologias da Infor-mação e da Comunicação, v. 1, n. 5, 2016. ISSN 2446-7634. Disponível em: <https://revistas.setrem.com.br/index.php/reabtic/article/view/158>.
FINSTERWALDER, M. Automating acceptance tests for gui applications in an extreme programming environment. In: ADDISON-WESLEY BOSTON MA. Proceedings of the 2nd International Conference on eXtreme Programming and Flexible Processes in Software Engineering. [S.l.], 2001. p. 114–117.
GAROUSI, V.; MÄNTYLÄ, M. V. When and what to automate in software testing? a multi-vocal literature review. Information and Software Technology, Elsevier, v. 76, p. 92–117, 2016.
LEAL, I. Requisitos de metodologias de teste de software para processos ágeis. Universidade Federal de Minas Gerais, Belo Horizonte, 2009.
47
LEITNER, A. et al. Reconciling manual and automated testing: The autotest experience. In: IEEE. 2007 40th Annual Hawaii International Conference on System Sciences (HICSS’07). [S.l.], 2007. p. 261a–261a.
PAWLIK, M.; AUGSTEN, N. Efficient computation of the tree edit distance. ACM Transactions on Database Systems (TODS), ACM, v. 40, n. 1, p. 3, 2015.
PAWLIK, M.; AUGSTEN, N. Compare your trees with ease. 2016. 2016. Disponível em: <http://tree-edit-distance.dbresearch.uni-salzburg.at/>. Acesso em June 3, 2019.
PAWLIK, M.; AUGSTEN, N. Tree edit distance: Robust and memory-efficient. Information Systems, Elsevier, v. 56, p. 157–173, 2016.
PINTO, F. A. P. An automated approach for performance deviation analysis of evolving software systems. Tese (Doutorado) — Universidade Federal do Rio Grande do Norte, 2015.
PRESSMAN, R.; MAXIM, B. Engenharia de Software-8a Edição. [S.l.]: McGraw Hill
Brasil, 2016.
SILVA, L. M. PerfMiner Visualizer: uma ferramenta para análise da evolução do atributo de qualidade de desempenho em sistemas de software. Dissertação (Projeto de Diplomação) — Universidade Federal do Rio Grande do Norte, UFRN, Natal, RN, Brasil, jul. 2017.
SINFO. SIGAA - Sistema Integrado de Gestão de Atividades Acadêmicas. 2017. Jul., 2017. Disponível em: <https://docs.info.ufrn.br/doku.php?id=suporte:sigaa: visao_geral>. Acesso em June 3, 2019.
SOMMERVILLE, I. Engenharia de software, 9a. São Palo, SP, Brasil, 2011.
TAIPALE, O. et al. Trade-off between automated and manual software testing. International Journal of System Assurance Engineering and Management, v. 2, n. 2, p. 114–125, Jun 2011. ISSN 0976-4348. Disponível em: <https://doi.org/10.1007/s13198-011-0065-6>.
