Usando Técnicas de Mineração de Repositórios Software …...Centro de Ciências Exatas e da...

Universidade Federal do Rio Grande do NorteCentro de Ciências Exatas e da Terra

Departamento de Informática e Matemática AplicadaBacharelado em Ciência da Computação

Usando Técnicas de Mineração de RepositóriosSoftware 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 deSoftware para Apoiar a Automação de Testes de

Software

Monografia de Graduação apresentada aoDepartamento de Informática e MatemáticaAplicada do Centro de Ciências Exatas e daTerra da Universidade Federal do Rio Grandedo Norte como requisito parcial para a ob-tenção do grau de Bacharel em Ciência daComputação.

Orientador(a)

Uirá Kulesza-Doutorado

Universidade Federal do Rio Grande do Norte – UFRNDepartamento de Informática e Matemática Aplicada – DIMAp

Natal-RN

Junho 2019

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á KuleszaOrientador(a)

Departamento de Informática e Matemática Aplicada – DIMApUniversidade Federal do Rio Grande do Norte – UFRN

Dr. Roberta de Souza CoelhoExaminador

Departamento de Informática e Matemática Aplicada – DIMApUniversidade Federal do Rio Grande do Norte – UFRN

Dr. Felipe Alves Pereira PintoExaminador

Diretoria Acadêmica de Ciências – DIACInstituto Federal de Educação, Ciência e Tecnologia do Rio

Grande do Norte – IFRN

Natal-RN, 13 Junho 2019.

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"

José Augusto

Usando Técnicas de Mineração de Repositórios deSoftware 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 toSupport 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).

Keywords : software testing, test automation, software repository mining.

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

1 Tabela com os melhores candidatos a serem automatizados . . . . . . . . p. 38

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

UFRN – Universidade Federal do Rio Grande do Norte

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

T - Conjunto de todos os testes

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

de produção. . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

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

Apêndice A -- Tabela de candidatos a automação p. 48

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.

– Determinar a similaridade entre os logs de testes manuais e automatizados.

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 especificaçã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 facilidade 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 TED :

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.

O processo da fase (i) do PerfMiner usa o código-fonte do sistema e as suítes de

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, quantNos

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∗,

quantNos ∈ N

grupo ∈ String∗}

(3.2)

Dado um conjunto fictício M ′ = {m2,m3,m4,m5,m6} tal que M ′ ⊂ 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 doslogs de testesduplicados

Logs de testes manuais Logs de testes automatizados

Similaridade doslogs de testes

Logs manuais sem similaridadeLogs manuais com similaridade

Logs manuais únicos Logs automatizados únicos

Cruzamentode informações URLs mais acessadasURLs 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(TMx , TA

y ) = 1−TED(TM

x , TAy )

TMx .quantNos+ TA

y .quantNos(3.3)

A equação 3.3 utiliza da função TED : TM × TA → N que calcula a Tree Edit

Distance entre duas árvores (logs de testes). O algoritmo padrão do TED 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 TMx e TA

y , é possível determinar a maior similaridade entre elas

sendo TED(TMx , TA

y ) = 0, que significa que as árvores TMx e TA

y são exatamente iguais

e nenhuma operação é necessária para transformar uma na outra. A menor similaridade

é denotado por TED(TMx , TA

y ) = TMx .quantNos + TA

y .quantNos, que representa excluir

todos os nós de TMx e inserir todos os nós de TA

y ou excluir todos os nós de TAy e inserir

todos os nós de TMx .

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.

As determinações obtidas pelo algoritmo possibilitam dividir o conjunto de saída em

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 similaridade 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 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 relevantes1.799

Logs desprezados58.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 Acessos19.514 EmitirGRUPagamentoMultasBibliotecaMBean 1.816 3.831 2.217.86038.885 TermoAutorizacaoPublicacaoMBean 1.816 587 285.5318.186 SolicitarReservaMaterialBibliotecaMBean 1.816 434 250.8697.629 JustificativaAusenciaCICMBean 1.748 3.831 2.217.86022.568 SolicitacaoEmprestimoEntreBibliotecasMBean 1.554 3.831 2.217.86034.521 SolicitacaoAgendamentoMBean 1.400 434 250.86924.691 SolicitacaoReposicaoAvaliacaoMBean 1.298 3.831 2.217.86020.721 MonitoriaMBean 1.202 2 49036.199 CargaHorariaPIDMBean 852 434 250.86940.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.

Os resultados encontrados neste capitulo serão divulgados com a SINFO para que

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 automatizado é 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 Conferenceand 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 deSoftware Magazine, v. 1, n. 3, p. 54–57, 2008.

BILLE, P. A survey on tree edit distance and related problems. Theoretical computerscience, 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 eferramentas. 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 extremeprogramming environment. In: ADDISON-WESLEY BOSTON MA. Proceedings ofthe 2nd International Conference on eXtreme Programming and Flexible Processes inSoftware Engineering. [S.l.], 2001. p. 114–117.

GAROUSI, V.; MÄNTYLÄ, M. V. When and what to automate in software testing? amulti-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. ACMTransactions 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 evolvingsoftware systems. Tese (Doutorado) — Universidade Federal do Rio Grande do Norte,2015.

PRESSMAN, R.; MAXIM, B. Engenharia de Software-8a Edição. [S.l.]: McGraw HillBrasil, 2016.

SILVA, L. M. PerfMiner Visualizer: uma ferramenta para análise da evolução doatributo de qualidade de desempenho em sistemas de software. Dissertação (Projetode 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>.

48

APÊNDICE A -- Tabela de candidatos aautomação

Este apêndice apresenta a tabela com o ranqueamento dos cem testes manuais únicos

relevantes mais significantes para o processo de automação. Por uma questão de espaço,

os nomes completos dos testes manuais foram retirados por não acomodar-se no conteúdo

do arquivo, entretanto os índices caracterizam melhor unicamente os testes no banco de

dados do Perfminer do que seus respectivos nomes.

ID Nome do teste simplificado Execuções Erros Acessos

19514 EmitirGRUPagamentoMultasBibliotecaMBean 1816 3831 2217860

38885 TermoAutorizacaoPublicacaoMBean 1816 587 285531

8186 SolicitarReservaMaterialBibliotecaMBean 1816 434 250869

7629 JustificativaAusenciaCICMBean 1748 3831 2217860

22568 SolicitacaoEmprestimoEntreBibliotecasMBean 1554 3831 2217860

34521 SolicitacaoAgendamentoMBean 1400 434 250869

24691 SolicitacaoReposicaoAvaliacaoMBean 1298 3831 2217860

20721 MonitoriaMBean 1202 2 490

36199 CargaHorariaPIDMBean 852 434 250869

40231 SituacaoTurmaMBean 717 11 24339

32763 ConsolidarTurmaMBean 459 434 250869

3387 AcessoAuditoriaMBean 380 316 158356

47565 HorarioTurmaMBean 369 4 3000

24393 CursoResidenciaMBean 339 1 5004

3553 BuscarComunidadeVirtualMBean 335 434 250869

370 DestrancarProgramaMBean 329 587 285531

3568 InteresseAvaliarMBean 315 434 250869

3369 RequisicoesBloqueioMBean 307 316 158356

366 ForumCursoMBean 278 587 285531

49


22615 PortalDocenteMBean 268 434 250869

382 RegistroValidacaoEmailDiscenteMBean 263 587 285531

48836 PortalDiscenteMBean 260 225 1094147

31847 ForumMedioMBean 259 434 250869

3379 OpcoesContratoMBean 250 316 158356

3467 MensagemForumMBean 249 316 158356

12877 AreaTematicaMBean 240 43 4732

34512 DetalhesSiteMBean 222 434 250869


3566 SolicitacaoTurmaMBean 208 434 250869

5014 AcessoMeioAmbienteMBean 197 6 6253

8760 RelPendentesSupInfraMBean 197 6 6253

5003 UnidadeMBean 193 316 158356

3796 PermissaoAvaMBean 186 434 250869

42410 SugestaoSolicitacaoTurmaMBean 185 434 250869

3354 PortalCoordenadorGraduacaoMBean 178 4 33741

3798 ConfiguracoesAvaMBean 169 434 250869

3038 AvaliadorCICMBean 166 434 250869

19129 NotificacaoAcademicaDiscenteMBean 158 3831 2217860

24190 iniciarBusca 153 434 250869

1562 EleicaoMBean 150 3831 2217860

9089 TipoAtividadeExtensaoMBean 144 275 36686

18507 SolicitacaoEnsinoIndividualMBean 142 4 33741

19610 SolicitacaoReposicaoAvaliacaoMBean 128 3831 2217860

36298 popularBuscaGeral 119 1 5004

53657 PortalDiscenteBetaMBean 113 225 1094147

40211 EspecializacaoTurmaMBean 104 4 10679


23490 RelatorioDiscentesEmRegimeObservacaoMBean 96 86 123119

38633 validacaoCpfDiscente 94 225 1094147

2151 ForumMBean 91 3831 2217860

16211 RelatorioMatInfMBean 91 2 1995

42847 EmailInstitucinalMBean 86 3831 2217860


50


24159 SolicitacaoAlteracaoExpressaoMBean 83 434 250869

24266 CursoResidenciaMBean 83 434 250869

7255 ReqEditorasNaoCadastradasMBean 77 2 1995

8970 TrancamentoMatriculaMBean 76 587 285531

3380 ObraMBean 74 316 158356

52431 buscarGeral 70 11 24339

44326 BuscaTurmaMBean 69 1 5004

43768 iniciarRelatorioAnalitico 68 434 250869

24703 MonitoriaMBean 66 3831 2217860


3547 istarAcoesPendentesRelatorios 64 8 10632


3373 SupInfraMBean 60 316 158356

3381 ContratoMBean 58 316 158356

6068 ConvenioAcademicoMBean 56 1 5004

3800 MenuTurmaMBean 55 434 250869

5847 TurmaVirtualMBean 55 434 250869

24 PortalPublicoMBean 55 10 312750

25 ConsultaPublicaEditalMBean 55 10 312750

26 ConsultaPublicaProcessoMBean 55 10 312750

27 ConsultaPublicaDocumentoMBean 55 10 312750

28 NoticiaPortalMBean 55 10 312750

4696 BuscaUnidadeMBean 55 10 312750

33376 alterarPeriodoNaoFlexivel 55 1 2108

15788 AutorizacaoRequisicaoBibliotecaMBean 54 2 1995

28064 iniciar 53 434 250869

3272 OrcamentoMBean 53 1 9869

6112 MatriculaGraduacaoMBean 53 1 5004

34784 SolicitacaoServicoDocumentoMBean 52 434 250869

18187 RelatorioTitulosEditoraMBean 52 2 1995

20431 RelatorioLivroInternacionalMBean 52 2 1995

3365 RelatorioDespesasUnidadesMBean 51 316 158356

3384 EmissaoNadaConstaCautelaMBean 50 316 158356

3388 PedidoInformacaoMBean 50 316 158356

51


3389 BuscaPedidoInformacaoMBean 50 316 158356

3392 ComprasCompartilhadasMBean 50 316 158356

32641 HomologacaoBolsasMBean 50 3 14925

18472 ConsultaPublicaTelefonesMBean 49 10 312750

58118 RelatorioNotificaoEmpresaMBean 49 6 6253

22577 InteresseAvaliarMBean 48 3831 2217860


34410 selecionarUnidadeBusca 45 63 161

3356 AtendimentoAlunoMBean 45 4 33741

4375 RecebeTermoResponsabilidadeMBean 43 316 158356

6837 ProtocoloMBean 42 316 158356

3846 MaterialMBean 41 316 158356

4915 DemandarMaterialCompraMBean 41 316 158356

Usando Técnicas de Mineração de Repositórios Software …...Centro de Ciências Exatas e da...

Documents

Transcript of Usando Técnicas de Mineração de Repositórios Software …...Centro de Ciências Exatas e da...