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
ID Nome do teste simplificado Execuções Erros Acessos
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
37786 CargaHorariaPIDMBean 218 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
33344 SolicitacaoAgendamentoMBean 96 434 250869
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
36205 SolicitacaoEmprestimoEntreBibliotecasMBean 84 434 250869
50
ID Nome do teste simplificado Execuções Erros Acessos
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
411 SolicitacaoAgendamentoMBean 65 9 4971
3547 istarAcoesPendentesRelatorios 64 8 10632
53681 SolicitacaoEmprestimoEntreBibliotecasMBean 60 3831 2217860
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
ID Nome do teste simplificado Execuções Erros Acessos
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
42626 CargaHorariaPIDMBean 45 434 250869
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