UMA FERRAMENTA DE ANÁLISE AUTOMATIZADA DE TÉCNICAS DE SELEÇÃO DE TESTES DE REGRESSÃO BASEADA EM MINERAÇÃO DE REPOSITÓRIOS DE SOFTWARE

Transcrição

1 UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CIÊNCIAS EXATAS E DA TERRA DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO UMA FERRAMENTA DE ANÁLISE AUTOMATIZADA DE TÉCNICAS DE SELEÇÃO DE TESTES DE REGRESSÃO BASEADA EM MINERAÇÃO DE REPOSITÓRIOS DE SOFTWARE João Maria Guedes da Cruz Júnior NATAL - RN 2014

2 UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CIÊNCIAS EXATAS E DA TERRA DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO UMA FERRAMENTA DE ANÁLISE AUTOMATIZADA DE TÉCNICAS DE SELEÇÃO DE TESTES DE REGRESSÃO BASEADA EM MINERAÇÃO DE REPOSITÓRIOS DE SOFTWARE João Maria Guedes da Cruz Júnior Dissertação de mestrado apresentada ao Programa de Pós-graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte como requisito para obtenção do grau de Mestre em Sistemas e Computação. Orientador: Prof. Dr. Uirá Kulesza Co-orientador: Prof. Dr. Roberta de Souza Coelho NATAL - RN 2014

3 Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial Centro de Ciências Exatas e da Terra CCET. Cruz Júnior, João Maria Guedes da. Uma ferramenta de análise automatizada de técnicas de seleção de testes de regressão baseada em mineração de repositórios de software / João Maria Guedes da Cruz Júnior. - Natal, f. : il. Orientador: Prof. Dr. Uirá Kulesza. Co-orientadora: Profª. Drª. Roberta de Souza Coelho. Dissertação (Mestrado) Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Programa de Pós-Graduação em Sistemas e Computação. 1. Teste de software Dissertação. 2. Seleção de testes de regressão Dissertação. 3. Diferenciação textual Dissertação. 4. Inclusão Dissertação. 5. Precisão Dissertação. I. Kulesza, Uirá. II. Coelho, Roberta de Souza. III.Título. RN/UF/BSE-CCET CDU:

4 RESUMO O objetivo dos testes de regressão (RT) é reutilizar o conjunto de testes da última versão de um software em sua versão atual, para maximizar o valor dos testes já desenvolvidos e garantir que antigas funcionalidades continuem corretas após as novas modificações. Mesmo com o reuso, é comum que nem todos os testes precisem ser executados novamente e para evitar o desnecessário, é estimulada a utilização de técnicas de seleção dos testes de regressão (RTS), que buscam selecionar dentre todos os testes, apenas aqueles capazes de revelar faltas, isto reduz custos e torna a prática realmente atrativa para as equipes de teste. Diversos estudos recentes avaliam a qualidade da seleção realizadas por técnicas de RTS, identificando qual delas apresenta melhores resultados através de métricas como a inclusão e a precisão. As técnicas de RTS deveriam buscar no sistema sob teste (SUT) por testes que revelem faltas, entretanto, como este é um problema sem solução viável, a alternativa é buscar por testes que revelem as modificações, onde as faltas podem ocorrer. Contudo, tais modificações podem alterar o próprio fluxo de execução dos algoritmos, fazendo com que alguns testes não exercitem mais os mesmos trechos. Neste contexto, esta dissertação de mestrado busca investigar se as modificações realizadas no SUT poderiam afetar a qualidade da seleção dos testes realizada por uma RTS, e se sim, quais características apresentam as modificações que provocaram os erros, levando a RTS a incluir ou excluir testes erroneamente. Para tanto, foi desenvolvida uma ferramenta na linguagem Java para automatizar o cálculo da inclusão e precisão médias alcançadas por uma técnica de RTS para uma dada característica da modificação. A fim de validar a ferramenta, foi conduzido um estudo empírico para avaliar a técnica de RTS Pythia, baseada em diferenciação textual, sobre um sistema de informação web de larga escala, analisando a característica dos tipos das tarefas realizadas para evoluir o SUT. Palavras-chave: Teste de Software; Seleção de Testes de Regressão; Diferenciação Textual; Inclusão; Precisão; Características das Modificações.

5 ABSTRACT The main goal of Regression Test (RT) is to reuse the test suite of the latest version of a software in its current version, in order to maximize the value of the tests already developed and ensure that old features continue working after the new changes. Even with reuse, it is common that not all tests need to be executed again. Because of that, it is encouraged to use Regression Tests Selection (RTS) techniques, which aims to select from all tests, only those that reveal faults, this reduces costs and makes this an interesting practice for the testing teams. Several recent research works evaluate the quality of the selections performed by RTS techniques, identifying which one presents the best results, measured by metrics such as inclusion and precision. The RTS techniques should seek in the System Under Test (SUT) for tests that reveal faults. However, because this is a problem without a viable solution, they alternatively seek for tests that reveal changes, where faults may occur. Nevertheless, these changes may modify the execution flow of the algorithm itself, leading some tests no longer exercise the same stretch. In this context, this dissertation investigates whether changes performed in a SUT would affect the quality of the selection of tests performed by an RTS, if so, which features the changes present which cause errors, leading the RTS to include or exclude tests wrongly. For this purpose, a tool was developed using the Java language to automate the measurement of inclusion and precision averages achieved by a regression test selection technique for a particular feature of change. In order to validate this tool, an empirical study was conducted to evaluate the RTS technique Pythia, based on textual differencing, on a large web information system, analyzing the feature of types of tasks performed to evolve the SUT. Keywords: Software Testing; Regression Tests Selection; Textual Differencing; Inclusion; Precision; Features of Changes.

6 LISTA DE FIGURAS Figura 1. Princípio básico do funcionamento da RTS Quality Figura 2. Conjuntos dos testes e as manipulações necessárias Figura 3. Diagrama de componentes e suas dependências Figura 4. Sequência de execução da RTS Quality Figura 5. Classes do módulo History Miner e suas associações Figura 6. Classes do módulo RTS e suas associações Figura 7. Classes do módulo Instrumentation Data e suas associações Figura 8. Composição e encapsulamento das classes do Instrumentation Data Figura 9. Callgraph dos métodos chamados a partir dos testes da revisão inicial Figura 10. Callgraph dos métodos chamados a partir dos testes da versão final Figura 11. Tipos de tarefas mais frequentes e suas porcentagens Figura 12. Inclusão média alcançada pela RTS Pythia para cada tipo de tarefa Figura 13. Precisão média alcançada pela RTS Pythia para cada tipo de tarefa

7 LISTA DE TABELAS Tabela 1. Diferenças entre a RTS Quality e o framework de (ROTHERMEL, 1996) Tabela 2. Características de uma modificação Tabela 3. Exemplo de sistema: versões e suas tarefas necessárias Tabela 4. Exemplo de commits em um repositório SVN Tabela 5. Dados analisados pela RTS Quality na Fase Tabela 6. Dados analisados pela RTS Quality na Fase Tabela 7. Números obtidos nas Fases 2 e 3 do estudo Tabela 8. Métricas obtidas pela RTS Pythia para o Programa de Exemplo Tabela 9. Principais características das duas versões do SUT Tabela 10. Inclusão e precisão médias por tipo de tarefa Tabela 11. Conjunto dos testes elaborados para a Biblioteca Tabela 12. Métricas de inclusão e precisão de cada tarefas

8 LISTA DE LISTAGENS Listagem 1. XML contendo as informações para acesso a uma base de dados Listagem 2. Script SQL para obter o tipo e o estado de uma tarefa do SIGAA Listagem 3. Script SQL para obter as revisões de uma tarefa do SIGAA Listagem 4. XML contendo a relação das tarefas e suas revisões Listagem 5. Exemplo do XML de configuração dos projetos de um SUT

9 LISTA DE ABREVIATURAS E SIGLAS CFG CMT RT RTM RTP RTS SUT Control Flow Graph Change Management Tool Regression Tests Regression Tests Minimization Regression Tests Prioritization Regression Tests Selection System Under Test

10 SUMÁRIO 1. INTRODUÇÃO Problema Abordado Limitações dos Trabalhos Existentes Objetivos Gerais e Específicos Questão de Pesquisa Organização do Trabalho FUNDAMENTAÇÃO TEÓRICA Teste de Software Testes de Regressão Otimização de Técnicas de RT Técnicas de RTS Técnicas de RTS Baseadas em Diferenciação Textual Instrumentação de Código Análise Comparativa Cálculo das Métricas Características das Modificações RTS QUALITY Arquitetura Geral da Ferramenta Projeto Detalhado da Ferramenta Módulo Executer Módulo History Miner Módulo RTS Regression Test Selection Subsistema TTracker Módulo Test Tracker Módulo Instrumentation Data Módulo File Persistence Instanciação e Funcionamento da Infraestrutura Pontos de Configuração Programa de Exemplo... 46

11 4. ESTUDO EMPÍRICO Objetivos e Questões de Pesquisa Sistema Investigado Métricas Utilizadas Fases do Estudo Fase 1 Obtenção das Tarefas e suas Modificações Fase 2 Análise da Revisão Inicial Fase 3 Análise da Revisão Final Fase 4 Cálculo das Métricas e das Médias Resultados do Estudo Avaliação da Técnica de RTS Pythia Avaliação da Ferramenta RTS Quality Ameaças a Validade do Estudo CONCLUSÕES Contribuições Limitações do Trabalho Trabalhos Futuros Múltiplas Características Sub-Ramo de um Control Flow Graph Generalização das Médias Pontos de Extensão Banco de Dados Comunidade Open Source REFERÊNCIAS ANEXO I ANEXO II... 83

12 1. INTRODUÇÃO Desenvolver sistemas de software tem se tornado uma tarefa cada vez mais difícil, devido ao crescente grau de exigência dos clientes por sistemas personalizados com as necessidades de cada empresa, que sejam mais intuitivos e de fácil utilização, com menor incidência de falhas e que simplifiquem tarefas dispendiosas. Atender tais exigências produz vários impactos ao longo do processo de desenvolvimento, a exemplo disso tem-se o aumento da complexidade das funcionalidades, a demanda por interfaces de usuário mais sofisticadas, a grande quantidade de informações que precisam ser armazenadas, a viabilização do acesso a múltiplos usuários simultâneos, a integração entre diferentes plataformas (web, mobile, desktop, embarcados), a incorporação de controles de permissões e acesso, dentre outros. Esta crescente complexidade impulsiona as equipes a adotarem processos e padrões de desenvolvimento cada vez mais sofisticados e com atividades melhor definidas. Para manter-se à frente da concorrência, as empresas precisam garantir que seus produtos sejam entregues dentro do prazo, e com as características de qualidade e requisitos previamente estabelecidos com os clientes e, para gerenciar este processo, foi criado o conceito de tarefas. Cada tarefa apresenta informações sobre o que deve ser realizado, quem são seus responsáveis, qual é o seu tempo limite e é comum que apresente também um tipo. Os possíveis tipos das tarefas, bem como a classificação de cada tarefa criada, são definidos pela própria equipe de desenvolvimento do sistema, seguindo uma lógica própria. Para gerenciar o andamento de cada tarefa durante o processo de desenvolvimento e manutenção de sistemas, é comum a utilização de ferramentas de gerenciamento de mudanças. A organização do trabalho a ser realizado em tarefas bem definidas, permite que a equipe mantenha o foco nas prioridades de cada etapa do desenvolvimento. De forma a prezar pela qualidade do software, as equipes têm buscado também adotar métodos e técnicas de testes ao longo das diversas fases do 1

13 desenvolvimento, visando exercitar as funcionalidades novas ou modificadas. Incorporar tais métodos e técnicas de teste demanda a ampliação dos investimentos, acarretando um maior consumo de tempo e recursos. É bastante comum que as empresas reduzam ou eliminem estas atividades para evitar exceder o limite dos prazos estipulados. Neste contexto surgem as técnicas de Testes de Regressão (RT Regression Tests), que visam à redução do retrabalho, objetivando reutilizar os testes que já foram implementados nas versões anteriores do sistema. Apesar do reuso trazer vantagens, reexecutar todos os testes pode consumir tempo e recursos excessivos. Surge então à necessidade de otimizar as soluções, garantindo que as novas mudanças não prejudicam o comportamento das funcionalidades preexistentes no sistema. Segundo (YOO e HARMAN, 2012), existem três diferentes formas de otimizar uma técnica de RT, que envolvem a seleção, a priorização e a minimização dos casos de teste. As técnicas de seleção dos testes de regressão (RTS Regression Tests Selection) (ROTHERMEL e HARROLD, 1996) visam selecionar um subconjunto dos testes da versão anterior que sejam capazes de revelar faltas. As técnicas de minimização dos testes de regressão (RTM Regression Tests Minimization) (ROTHERMEL et al, 2002) buscam também reduzir o conjunto final dos casos de teste que serão reexecutados, mas o objetivo é eliminar aqueles que exercitam partes semelhantes do sistema. Por fim, as técnicas de priorização dos testes de regressão (RTP Regression Tests Prioritization) (ROTHERMEL, UNTCH e CHU, 1999) buscam ordenar os casos de teste com base em alguma propriedade desejável, como por exemplo, maximizar a taxa de descoberta de faltas. Independentemente de os testes serem manuais ou automatizados, tais técnicas são importantes quando os testes são muitos, muito longos e/ou quando testes são repetidos várias vezes com entradas diferentes. As técnicas devem ser capazes de reduzir os custos da etapa de testes, otimizando a identificação de faltas e consumindo um tempo inferior ao tempo que seria gasto se todos os testes fossem executados. Executar algumas dezenas de testes em um único 2

14 módulo modificado de um sistema pode ser muito mais interessante que executar algumas centenas de testes em módulos que não foram impactados pelas modificações. Cada tipo de técnica pode ser avaliado com base em métricas bem definidas e que expressem, até certo grau, a qualidade das técnicas, assim como permitem também a comparação do desempenho entre elas. Este trabalho de dissertação focaliza nas técnicas de RTS e suas métricas. (ROTHERMEL, 1996) demonstra que as técnicas de RTS devem apresentar algumas qualidades, buscando serem: inclusivas, precisas, genéricas e eficientes. Ser inclusiva (inclusive) implica em selecionar testes do conjunto original que possam revelar erros em componentes modificados. Ser precisa (precise) consiste em ter a capacidade de identificar testes desnecessários, de tal forma que a exclusão compense o custo da própria técnica. Ser genérica (general) significa ser aplicável aos diversos tipos de programas que sejam alvos de modificações intra ou interprocedurais. Por fim, a técnica deve ser eficiente (efficient), isto é, ter características de tempo e espaço consumidos dentro de padrões razoáveis, que justifiquem sua utilização, comparada a não utilizar técnica alguma. Com base na qualidade de técnica inclusiva, algumas técnicas são ditas seguras (LEUNG e WHITE, 1990; WHITE e LEUNG, 1992; LASKI e SZERMER, 1992; WHITE et al., 1993; AGRAWAL et al., 1993; CHEN, ROSENBLUM e VO, 1994; VOKOLOS e FRANKL, 1997; ROTHERMEL e HARROLD, 1997), o que consiste em garantir a inclusão de 100% dos casos de teste que são capazes de revelar falhas. Ao analisar o conceito de precisão é possível notar que corresponde a qualidade inversa da inclusão, tendo em vista que visa à exclusão dos testes desnecessários Problema Abordado Motivado pela necessidade de otimizar uma RTS, reduzir os grandes custos e tornar sua aplicação mais interessante para as empresas, este trabalho procura identificar o comportamento de uma dada técnica, diante das diferentes características das modificações realizadas em um sistema. 3

15 O código de um sistema que sofreu modificações pode, inesperadamente, ser afetado em partes que não estão diretamente associadas à modificação, o chamado impacto indireto. Uma técnica de RTS bem estruturada deve ser capaz de identificar este impacto e garantir que as partes afetadas também sejam testadas, dada à possibilidade de possuírem faltas. Neste contexto, caso uma técnica de RTS não seja capaz de rastrear o impacto de uma modificação, poderia falhar e apresentar um resultado inseguro ou impreciso dependendo das características das modificações. Este trabalho apresenta uma ferramenta que busca compreender até que ponto os resultados das técnicas de RTS podem ser afetados pelas características das modificações do Sistema Sob Teste (SUT System Under Test) que avaliam. Esta ferramenta pode beneficiar: (i) as equipes de teste, pois teriam parâmetros para orientá-las na escolha da RTS que melhor se aplicará as novas modificações realizadas, com base apenas em um histórico previamente obtido para uma característica das modificações e; (ii) os desenvolvedores de técnicas de RTS, de posse da relação das modificações em que suas técnicas apresentaram os piores resultados poderiam identificar, na característica analisada, a origem das deficiências e planejar novas correções Limitações dos Trabalhos Existentes Os valores das métricas de inclusão e precisão obtidos pelo framework proposto por (ROTHERMEL, 1996), representam a qualidade dos conjuntos de testes selecionados por uma RTS, tais valores permitem fazer comparações entre duas técnicas distintas se ambas as técnicas forem avaliadas em um mesmo SUT. Tais valores não podem ser generalizados, pois nem sempre é possível afirmar que uma técnica terá o mesmo resultado em um sistema diferente. A ferramenta desenvolvida por este trabalho permite associar os valores das métricas a uma característica que esteja presente em todo e qualquer SUT, serão obtidos resultados mais genéricos e livres deste contexto. Ao analisar esta proposta, é possível observar que as modificações podem apresentam diferentes valores para uma mesma característica. As métricas propostas por este trabalho para generalizar a avaliação de uma RTS, baseiam-se nas métricas de inclusão e precisão propostas por Rothermel, mas 4

16 além de calculá-las, é selecionada uma das características presente em todas as modificações, agrupando as modificações com base nos valores que assumirem, de tal forma que modificações com o mesmo valor passaram a fazer parte de um mesmo conjunto. Para cada modificação é calculada a inclusão e a precisão, e para cada conjunto é calculada a média aritmética para as taxas de inclusão e de precisão. Desta forma, é possível analisar como a RTS é afetada pela característica analisada. Outros estudos realizados por (ROTHERMEL e HARROLD, 1996) e por (BISWAS et al., 2011) sobre técnicas de RTS, avaliam o desempenho de tais técnicas e as classificam em técnicas seguras ou não seguras, isto é, capazes de identificar todos os testes necessários para a nova versão ou não, respectivamente. Este trabalho, no entanto, busca avaliar quais características das modificações poderiam afetar a qualidade dos testes selecionados por uma RTS, levando-as a cometer mais erros. Desta forma, busca-se identificar não só os erros, como também suas possíveis origens. O estudo empírico realizados por (FRANKL et al., 2003), se baseia em uma métrica parecida com a precisão proposta por (ROTHERMEL, 1996), entretanto, ela calcula apenas a quantidade de testes que a RTS excluiu, sem verificar se a exclusão foi feita corretamente. Sendo assim, esta métrica não serve ao propósito de analisar a qualidade da seleção realizada pela RTS. A avaliação empírica realizada em (ENGSTRÖM et al., 2008), apenas identifica os diversos trabalhos, autores, tipos de técnicas de RTS, e as diversas métricas utilizadas para avaliá-las, entretanto, não implementa nenhuma ferramenta que analise a qualidade das seleções de uma RTS. O experimento realizado por (VOKOLOS e FRANKL, 1998) apesar de julgar como útil a presença de um histórico que apresente os tipos de modificação realizadas para evoluir o sistema, não os correlaciona com os valores das métricas obtidos pela RTS. Pensando nesta área tão pouco explorada, a abordagem proposta por este trabalho, objetiva não só obter os valores das métricas de inclusão e precisão de uma RTS, dadas duas versões de um mesmo SUT, mas também, relacionar tais valores a uma característica comum a todas as modificações 5

17 realizadas entre as versões analisadas, no intuito de investigar a vulnerabilidade das técnicas diante de diferentes tipos de modificações. Um dilema, comumente enfrentado pela equipe de testes, é o de ter que selecionar uma única técnica de RTS que atenda bem suas necessidades, selecionando corretamente a menor quantidade possível de testes sem excluir aqueles que são realmente necessários. Surge então um problema, nem sempre a RTS selecionada apresenta bons resultados perante qualquer tipo de modificação. Neste contexto, seria bastante útil catalogar o desempenho médio de diferentes técnicas de RTS para cada um dos valores que as modificações podem assumir para uma dada característica, pois permitiria, com uma simples análise de novas modificações, selecionar a técnica que apresente um melhor desempenho. Os próprios desenvolvedores de uma técnica de RTS poderiam utilizar o desempenho médio de suas técnica perante a característica analisada para identificar os valores em que a RTS apresente uma maior deficiência, evidenciando as situações em que a técnica precisa ser melhorada. Todos os estudos realizados com técnicas de RTS estão sempre focados em uma das seguintes áreas: implementar e aperfeiçoar novas técnicas; calcular a qualidade da seleção da técnica; ou comparar o desempenho de diferentes técnicas. Durante nossa revisão literária da área, não foi possível encontrar trabalhos ou ferramentas que se dispunham a estudar as vulnerabilidade de uma dada técnica, ou que tentem identificar características e padrões que ajudem a encontrar as causas que possam levar uma RTS a cometer erros Objetivos Gerais e Específicos Os principais objetivos deste trabalho são: (i) desenvolver uma ferramenta para analisar técnicas de RTS, correlacionando as métricas tradicionais de inclusão e precisão com uma característica das modificações, obtendo a inclusão e precisão médias de cada uma; (ii) instanciar e avaliar a ferramenta em um estudo empírico, que permita validar suas funcionalidades no contexto de um sistema web de larga escala e, considerando a técnica RTS Pythia (VOKOLOS e FRANKL, 1997); e, finalmente, (iii) investigar para quais tipos de tarefas a 6

18 técnica de RTS Pythia é mais apropriada, dado que é considerada segura, atingindo sempre 100% de Inclusão. Este trabalho busca compreender até que ponto os resultados das técnicas de RTS são afetados pelas tarefas do SUT. Para auxiliar neste processo, foi desenvolvida a ferramenta RTS Quality, implementada na linguagem Java. A Figura 1 ilustra o funcionamento da ferramenta que, além da função básica de calcular as métricas de inclusão e precisão propostas por (ROTHERMEL, 1996), tem como principal função a de, com base em técnicas de mineração de repositórios de software, agrupar as modificações realizadas entre duas versões do SUT de acordo com os valores que assumiram para uma dada característica, e obter a inclusão e precisão médias de cada grupo. Estas métricas permitem compreender melhor o efeito que esta característica exerce sobre o funcionamento da RTS. Figura 1. Princípio básico do funcionamento da RTS Quality. Como é possível observar na Figura 1, para funcionar, uma RTS precisa conhecer a versão inicial do SUT, as partes exercitadas pela execução dos testes desta versão e as modificações que foram realizadas entre a versão inicial e a final, com estas informações ela é capaz de selecionar e excluir testes do conjunto de regressão da versão final do SUT. A ferramenta desenvolvida por este trabalho, por sua vez, analisa a própria versão final, executando nela seus testes e identificando quais deles realmente são necessários, dadas as modificações, isto permite calcular os acertos da RTS ao incluir (métrica de inclusão) e excluir (métrica de precisão) os testes para a versão final. Como visto, uma tarefa pode realizar uma ou várias modificações, a RTS Quality, além de 7

19 calcular as métricas básicas, analisa a característica dos tipos das tarefas que cada modificação apresenta. Isso permite calcular a inclusão e a precisão média para cada um destes tipo. Para este trabalho, foi selecionada a característica do tipo da tarefa, pois pode ser obtida facilmente pelos testadores, realizando uma simples consulta de qual tarefa deve ser testada, e verificando qual o seu tipo, ficando a tarefa mais difícil para a RTS Quality, que precisará minerar tal informação na base de dados de um Sistema de Gerenciamento de Mudanças (CMT Change Management Tool), correlacionando as modificações realizadas com as tarefas que tais modificações atendem Questão de Pesquisa O principal objetivo do estudo empírico proposto no Capítulo 4 deste trabalho é validar o funcionamento da ferramenta RTS Quality. Para tanto, o estudo empírico avalia a qualidade das seleções dos testes de regressão realizados pela técnica de RTS Pythia, que é considerada segura. Ao avaliar a Pythia, a RTS Quality deve constatar que a técnica alcança sempre um valor constante e conhecido de 100% de inclusão média, independentemente do tipo da tarefa, o que pode confirmar que a ferramenta conseguiu avaliar a técnica de forma coerente. Desta forma, para o estudo empírico apresentado no Capítulo 4, foi definida a seguinte questão de pesquisa: Questão de Pesquisa 1. Os tipos das tarefas podem afetar a técnica de RTS Pythia? A Pythia foi originalmente proposta por (VOKOLOS e FRANKL, 1997), e utiliza a diferenciação textual para comparar duas versões de um sistema com o intuito de obter o conjunto de modificações realizadas entre elas. Além deste conjunto, ela armazena também as informações de cobertura da execução dos testes da versão inicial do sistema. Ao cruzar essas duas informações, ela é capaz de identificar quais testes cobrem as modificações realizadas, selecionando-os como necessários para testar a versão final do sistema. A Pythia é considerada uma RTS segura, segundo (ROTHERMEL e HARROLD, 1997), por ser capaz de incluir no conjunto de testes selecionados todos os 8

20 testes que exercitam alguma modificação e que consequentemente tem a possibilidade de revelar faltas. A Pythia será descrita com maiores detalhes na Seção A execução do estudo acompanhará a execução de todos os testes em duas versões homologadas de um sistema web de larga escala, denominado Sistema Integrado de Gestão de Atividades Acadêmicas, mais especificamente sobre o módulo da Biblioteca, desenvolvido originalmente na Superintendência de Informática da UFRN, e que atualmente possui diversas versões executando em diferentes instituições federais, estaduais e municipais do Brasil. A RTS Quality permitirá automatizar algumas das etapas do estudo e caso alguma das médias obtidas por ela para a técnica seja inferior a 100% para algum tipo de tarefa, é possível observar o quanto a técnica foi afetada por este tipo, permitindo assim identificar os tipos em que ela é menos recomendada Organização do Trabalho Este documento está organizado na seguinte ordem: O capítulo 2 detalha a fundamentação teórica, apresentando os principais conceitos associados a este trabalho. O capítulo 3 apresenta uma visão geral da ferramenta de análise de testes de regressão, descrevendo seus principais módulos e seus respectivos propósitos. O capítulo 4 apresenta o estudo empírico projetado com o objetivo de validar o funcionamento da RTS Quality ao analisar uma técnica de RTS, descrevendo em detalhes seus objetivos, o sistema investigado, as métricas utilizadas e cada uma das fases seguidas para concluí-lo. Por fim, o capítulo 5 traz as conclusões, apresentando as principais contribuições do trabalho e apresentando as propostas de trabalhos futuros. 9

21 2. FUNDAMENTAÇÃO TEÓRICA Este capítulo apresenta a fundamentação teórica do trabalho. A Seção 2.1 apresenta a área de testes de software no qual o trabalho está inserido. A Seção 2.2 discorre sobre testes de regressão, apresentando as vantagens do reuso. Finalmente, a Seção 2.3 explora as otimizações das técnicas de testes de regressão, incluindo a otimização por seleção, e por fim, descreve a técnica de seleção de testes de regressão por diferenciação textual, explorada neste trabalho Teste de Software Com a evolução da engenharia de software, a harmoniosa interação entre os vários componentes do sistema tornou-se uma necessidade, e as avaliações de software através de testes tem ganhado cada vez mais atenção, no intuito de garantir o nível de qualidade e maturidade dos sistemas. Segundo o National Institute of Standards and Technology (NIST), em 2002, as atividades envolvendo teste e identificação de erros tem consumido de 70 a 80% dos custos associados ao desenvolvimento de sistemas de software. Diversos fatores podem acarretar erros inesperados ao logo do desenvolvimento de um sistema de software, por exemplo: soluções errôneas de conflitos em operações de merge de revisões em um repositório de código, podem potencialmente provocar a perda de correções (WILLIAMS e SPACCO, 2008); erros em um local podem provocar erros em outro, mesmo que indiretamente associados (RYDER e TIP, 2001); o reaparecimento de erros também é bem comum, bastando, para isso, que um desenvolvedor replique um erro que já havia sido corrigido ao tentar realizar novas correções. Portanto, neste contexto sensível do desenvolvimento e da depuração de sistemas, é considerada uma boa prática que, para cada erro encontrado, se implemente um teste de unidade que ateste que o comportamento é realmente o esperado. Desta forma, sempre que houver novas modificações, será possível verificar se novas falhas não foram reintroduzidas. 10

22 Outro fator que motiva a implantação de testes de software desde as fases iniciais no processo de desenvolvimento, é que quanto mais tarde o erro é encontrado, mais caro se torna corrigi-lo. Estudos realizados por (LAZIC e MASTORAKIS, 2008), demonstram que, em uma distribuição típica dos erros, 56% deles são inseridos na fase de requisitos, 27% durante o design, 7% durante a implementação do código. Sem os testes, uma enorme porcentagem de erros poderá se propagar para as fases seguintes, provocando a necessidade de retrabalho, ocupando parte da equipe com tarefas de correção. O aumento da frequência dos testes ajuda a evitar estouro do orçamento e dos prazos previstos e a entrega de um produto com requisitos incompatíveis com os solicitados pelo cliente Testes de Regressão Segundo (HARROLD et al., 2001): Teste de regressão é o processo de validar o software modificado para fornecer confiança de que as partes modificadas do software se comportam como deveriam e que as partes inalteradas do software não foram impropriamente afetadas pelas modificações. Neste contexto, as técnicas de Testes de Regressão (RT Regression Test) visam à redução do retrabalho, estipulando quais testes já implementados nas versões anteriores podem ainda ser reutilizados após as últimas modificações. A vantagem do reuso está em sua capacidade de reduzir custos e de explorar o valor associado a cada teste, fazendo com que deixem de ser de uso instantâneo e passem a ser de uso periódico. Elas constituem importante ferramenta no desenvolvimento dos sistemas atuais, cada vez maiores, mais complexos, envolvendo diversos programadores e engenheiros de software, em momentos e contextos diferentes e que evoluem muito constantemente. Apesar do reuso trazer vantagens, reexecutar todos os testes que ainda são válidos pode consumir tempo e recursos excessivos, por incluírem rotinas redundantes, desnecessárias, ou que não avaliam corretamente funcionalidades implementadas anteriormente. Surge então à necessidade de otimizar as 11

23 soluções, garantindo que as novas mudanças não prejudicam o comportamento das funcionalidades preexistentes no sistema Otimização de Técnicas de RT Segundo (YOO e HARMAN, 2012) existem três áreas principais na otimização de técnicas de RT, que envolvem: a seleção, escolha dos testes relevantes, dado um conjunto de mudanças realizadas; a priorização, ordenação dos testes para maximizar alguma variável desejável; e a minimização, eliminação dos testes redundantes e que exercitam trechos comuns. Este estudo, mostra que inúmeros trabalhos têm desenvolvido formas de maximizar o valor do conjunto de testes em cada uma das áreas, elaborados para diferentes tipos de sistemas, onde 19% delas são avaliadas com SUTs das linguagens C, C++ e C#, 14% com Java e apenas 2% com aplicações web. As técnicas de seleção dos testes de regressão (RTS Regression Tests Selection) (ROTHERMEL e HARROLD, 1996) visam à redução do conjunto final dos casos de teste, selecionando apenas os mais relevantes para que as partes recém-modificadas sejam exercitadas, mantendo assim, apenas testes que possuam a capacidade de revelar falhas. As técnicas de minimização dos testes de regressão (RTM Regression Tests Minimization) (ROTHERMEL et al., 2002) buscam também reduzir o conjunto final dos casos de teste que serão reexecutados, eliminando aqueles que exercitam partes semelhantes do sistema, de tal forma que haja ao menos um caso de teste para cada requisito de teste (componente a ser testado). Finalmente, as técnicas de priorização dos testes de regressão (RTP Regression Tests Prioritization) (ROTHERMEL, 1999) buscam ordenar os casos de teste com base em alguma propriedade desejável, como por exemplo, maximizar a taxa de descoberta de faltas. Diferente da seleção e da minimização, a priorização não reduz o conjunto resultante dos casos de teste, realiza apenas permutações na ordem de execução para atingir o objetivo proposto, permitindo também a interrupção prematura a qualquer momento, com base em algum critério arbitrário. 12

24 Técnicas de RTS Em (ROTHERMEL, 1996) é feita uma análise aprofundada sobre o problema da seleção de testes de regressão, onde ele é subdividido em algumas definições, serão citadas 5 delas. Vale ressaltar que a avaliação de uma RTS ocorre em um contexto diferente daquele onde são utilizadas, para avaliar uma RTS os testes são executados em ambas as versões, inicial e final, para que seja possível verificar se o conjunto dos testes sugeridos pela técnica está corretos e completo. Na nomenclatura adotada nas definições, P representa a versão inicial do SUT analisado e P a versão final, após as modificações. Ocorrências como P(i) ou P (i) representam o resultado obtido pelos programas para a entrada i. Já o termo t, representa um teste pertencente ao conjunto de todos os testes T e cada teste possui um número identificador n, uma entrada i e uma saída especificada S(i), caso seja executado para o P(i), e S (i), caso seja executado para o programa P (i). Definição 1: Dado um teste t = n, i, S(i) T; t é obsoleto para P se e somente se i D(S ) S (i) S(i). Se t não atende a esta definição diz-se que ele é não obsoleto. Na Definição 1 o autor define o conceito de teste obsoleto, teste este cuja entrada fornecida ao programa não pertence ao domínio especificado pelo programa ou cujo resultado especificado para a versão inicial do programa seja diferente do resultado especificado para a versão final do programa. Testes obsoletos não funcionam corretamente na versão final, caso uma RTS o selecione, estaria simplesmente elevando os custos da regressão sem benefício algum. Definição 2: Um teste t = n, i, S(i) T; é capaz de revelar uma falta para P se e somente se obsoleto(t) P (i) S (i). Na Definição 2 fica claro o principal objetivo de um teste de regressão, teste este capaz de revelar faltas. Este tipo é definido como o teste, não obsoleto, cujo resultado da execução da versão final do programa seja diferente do 13

25 resultado especificado para esta versão. Não existe algoritmo que resolva este problema sem antes ter de executar todos os testes, comparando os resultados obtidos com os resultados esperados, este algoritmo seria extremamente dispendioso e iria de encontro com o objetivo das técnicas RTS de reduzir os custos da regressão, além do mais, é extremamente complicado definir com perfeição a especificação de um programa, motivo pelo qual muitas vezes a especificação nem sequer é definida. Definição 3: Um teste t = n, i, S(i) T; é capaz de revelar uma modificação para P e P se e somente se obsoleto(t) P (i) P(i). Para contornar este problema, Rothermel propõe a alternativa da Definição 3, que apresenta o conceito do teste capaz de revelar modificações. Um teste que revela uma modificação é aquele, não obsoleto, cujo resultado da execução da versão final do programa seja diferente do resultado da versão inicial. É possível garantir que se o programa possui faltas, elas foram introduzidas nas novas modificações do sistema e, além do mais, revelar modificações demonstra-se como um problema mais simples do que revelar faltas, pois não depende mais da especificação do programa na versão final, ao invés disso, utiliza apenas a execução da versão final. Até o momento é possível determinar que um programa mudou entre ambas as versões, entretanto, não é possível determinar onde esta modificação ocorreu. Definição 4: Tomando o ET(P(i)) e o ET(P (i)) como rastreamentos de execução. Diz-se que ET(P(i)) e ET(P (i)) são equivalentes, isto é, ET(P(i)) ET(P (i)), se e somente se [Tam(ET(P(i))) = Tam(ET(P (i)))] [[( k)(1 k Tam(ET(P(i))))(Cód(ET(P(i)), k) Cód(ET(P (i)), k))]]. Aprimorando a solução anterior o autor propõe a Definição 4, que conceitua a equivalência entre dois rastreamentos de execução (Execution Traces). Um Execution Trace representa a sequência de linhas de código executadas pelo programa para uma dada entrada. Dois Execution Traces são equivalentes quando apresentam a mesma quantidade de linhas executadas e igualdade de conteúdo para cada linha de código na sequência da execução. 14

26 Dessa forma é possível identificar qual linha foi modificada, caso os Execution Traces não sejam equivalentes, é o que propõe a Definição 6. Definição 6: Um teste t = n, i, S(i) T é capaz de cruzar com uma modificação para P e P se e somente se obsoleto(t) ET(P(i)) ET(P (i)). Nesta última definição é criado o conceito do teste capaz de cruzar com uma modificação, que são aqueles, não obsoletos, cujo Execution Trace da versão inicial não é equivalente ao Execution Trace da versão final. Reunindo todas as definições, é possível concluir que o principal conjunto no qual uma RTS se baseia para selecionar os testes é o conjunto de modificações identificadas entre as versões inicial e final Técnicas de RTS Baseadas em Diferenciação Textual Uma técnica de RTS é dita como baseada em diferenciação textual se houver alguma comparação entre as versões final e inicial do código, no intuito de descobrir quais foram as mudanças realizadas. Caso algum componente que existia na versão inicial, deixe de existir na final, entende-se que este foi excluído, e caso um componente, que não existia na versão inicial, for encontrado na versão final, entender-se que este foi adicionado. Os componentes que permanecerem em ambas as versões podem ainda terem sido modificados internamente, conforme a estruturação da linguagem de programação. Uma classe pode continuar existindo em ambas as versões, mas é preciso garantir que seus métodos continuam idênticos. A granularidade da análise pode variar de técnica para técnica, indo desde a assinatura das classes, dos métodos, ou de seus conteúdos, até os fluxos de controle do algoritmo. Como já foi dito, o estudo apresentado neste trabalho (Capítulo 4) avalia o desempenho da técnica Pythia, proposta originalmente por (VOKOLOS e FRANKL, 1997), cujo funcionamento segue a sequência de passos descritas a seguir, e que atendem as definições propostas por (ROTHERMEL, 1996). 15

27 Primeiramente a técnica Pythia se baseia em alguma instrumentação de código, que permita rastrear quais métodos são executados para cada teste realizado (Definição 4). Este mapeamento funcionará como um histórico de execução dos testes e é a partir dele que a técnica irá propor testes para uma versão futura. Como é fácil de constatar, a técnica exigirá que todos os testes sejam executados em uma versão dita inicial, e só então poderá propor testes de regressão para uma versão futura. Um segundo passo importante para a implementação da técnica é que ela seja capaz de identificar o que mudou entre a versão inicial, onde os testes já foram executados, e a versão final. Esta capacidade fica por conta da sua abordagem de diferenciação textual. Alternativamente ao proposto na definição 3, a técnica basicamente irá analisar cada um dos arquivos de código-fonte que compõem o sistema de software, e para cada um irá identificar quais linhas foram modificadas entre ambas as versões. A Pythia foi originalmente desenvolvida para a Linguagem C, que possui natureza procedural, isto é, permite a implementação de rotinas, sub-rotinas e métodos, assim como na Linguagem Java, na qual foi implementada uma nova versão. Isso posto, faz-se necessário que a técnica descubra não só as linhas que foram modificadas, mas também, os métodos. Para tanto, foi desenvolvida uma estrutura capaz de analisar o código-fonte e determinar: quais são os métodos presentes nos arquivos e em quais linhas eles se iniciam e finalizam. Desta forma, torna-se trivial determinar a quais métodos pertencem as linhas modificadas. Vale observar que linhas novas, isto é, que foram adicionadas, devem ter seu método continente analisado na versão final, onde elas passaram a existir, já as linhas antigas e que foram removidas, existiam apenas na versão inicial, que é de onde se deve obter seu método continente. O terceiro passo dessa técnica consiste em cruzar as informações dos métodos cobertos pelos testes na versão inicial com as informações dos métodos que sofreram modificações entre a versão inicial e final (Definição 6). Através da operação de intersecção dos conjuntos obtem-se a relação dos métodos que são simultaneamente modificados entre as versões e cobertos pelos testes. 16

28 Por fim, com base nos métodos modificados e cobertos, a técnica só precisa rastrear quais foram os testes que cobriram tais métodos, propondo-os como cruciais para os testes da versão final. Como visto anteriormente, a Pythia é dita segura, pois sempre propõe todos os testes que eram realmente necessários para a versão final, o que, entretanto, não a impede que proponha testes desnecessários. Isso faz dela uma técnica imprecisa. Basta que um teste existente na versão inicial e proposto como necessário, demonstre-se obsoleto (Definição 1) na versão final, como a técnica não é capaz de identificar tal obsolescência, acaba por propor erroneamente o teste. Outra possível fonte de erros é a granularidade da análise. Como as modificações são analisadas a nível de método, ignorando as estruturas de controle internas, a técnica pode sugerir um testes que exercita o método, mas não a linha modificada, gerando resultados imprecisos. Alguns analisadores utilizam estruturas de grafos de fluxo de controle mais elaboradas, para analisar a estrutura dos algoritmos, levando em consideração os conceitos de orientação a objetos e todo o fluxo de controle de cada condição do algoritmo. Apesar de serem mais custosos estes analisadores são muito mais precisos, levando em consideração toda a semântica do algoritmo Instrumentação de Código A instrumentação é uma estratégia utilizada para monitorar um dado sistema em execução, coletando informações que sejam úteis para uma dada abordagem. Uma das principais aplicações do AspectJ na instrumentação de código é no rastreamento da execução de programas (PALO, 2002). Sua utilização é bastante comum quando surgem interesses transversais, isto é, quando aspectos de um programa afetam ou são relevantes para outro. No AspectJ, conceituado por (KICZALES, 2001), existem três conceitos principais: os pontos de junção (join points), que possibilitam especificar quais pontos do sistema deveram ser interceptados, bem como suas características; os pontos de corte (pointcuts), que são capazes de reunir diferentes join points 17

29 de acordo com uma lógica estruturada; e por fim os conselhos (advices), que permitem ao desenvolvedor programar uma rotina que será executada em um ponto de junção capturado através da lógica de um ponto de corte. O AspectJ prevê três tipos de advices: o before, que permite executar uma rotina antes que o método interceptado seja executado; o around, que permite a execuc a o de uma rotina antes e depois da execuc a o do método ou mesmo substituir o corpo do método sendo executado e; por fim, o after, que como o próprio termo sugere, permite executar uma rotina após o método interceptado Análise Comparativa A ferramenta RTS Quality se baseia na mesma lógica do framework proposto por (ROTHERMEL, 1996), entretanto, apesar de utilizar duas das mesmas métricas propostas por ele, possui algumas características diferentes, como resume a Tabela 1. Tabela 1. Diferenças entre a RTS Quality e o framework de (ROTHERMEL, 1996). Ferramenta RTS Quality Estrutura inicial: Utiliza apenas o código-fonte de cada versão do sistema; Granularidade da análise: Métodos; Resultados menos precisos, mais rápidos e menos custosos; Identificação das modificações: A diferenciação textual identifica os métodos modificados; Analisa apenas a sintaxe do código modificado; Instrumentação: Captura a assinatura dos métodos executados pelos testes; Cobertura de um teste: Representada pelo conjunto das assinaturas dos métodos chamados durante a execução do teste; Métricas calculadas: Inclusão, precisão, inclusão média e precisão média; Framework de (ROTHERMEL,1996) Estrutura inicial: Gera um CFG para cada versão do sistema; Granularidade da análise: Sub-ramos do CFG; Resultados mais precisos, mais lentos e mais custosos; Identificação das modificações: A comparação entre CFGs identifica os sub-ramos modificados; Analisa tanto a sintaxe quanto a semântica do código modificado; Instrumentação: Identifica os sub-ramos do CFG executados pelos testes; Cobertura de um teste: Representada pela sequência de nós chamados (sub-ramo) durante a execução do teste; Métricas calculadas: Inclusão, precisão, eficiência e generalidade; 18

30 A RTS Quality não realiza nenhuma análise prévia no sistema, deixando para capturar as informações diretamente no código-fonte à medida que este é executado, enquanto o framework, proposto por (ROTHERMEL, 1996), gera um CFG para cada versão do sistema. A ferramenta desenvolvida por este trabalho utiliza a granularidade de métodos para identificar uma modificação, isto é, um método é considerado modificado se pelo menos uma de suas linhas tiver sido modificada, esta unidade de análise pode gerar resultados menos precisos, pois um método pode ser executado por um teste sem, no entanto, ter as linhas modificadas executadas, entretanto, esta unidade de análise permite obter resultados mais rapidamente e consumindo menos recursos computacionais. Já o framework, utiliza a granularidade de sub-ramos do CFG, o que permite saber com exatidão o trecho do programa que foi modificado e/ou exercitado por um teste, o que exige mais tempo e recursos computacionais. A RTS Quality utiliza-se da diferenciação textual para comparar duas versões de um mesmo arquivo de código-fonte e identificar quais linhas estão diferentes. Embora esta abordagem seja capaz de analisar a sintaxe do programa, pode erroneamente sugerir que um método sofreu modificações quando na verdade seu comportando continua inalterado. Isso não acontece com o framework, que realiza uma comparação entre os CFGs de ambas as versões do sistema, sendo capaz de apontar os sub-ramos que introduziram mudanças na semântica do programa, estas sim podem mudar o comportamento do sistema e introduzir novas faltas. A instrumentação tanto da ferramenta quanto do framework analisado, tem o mesmo objetivo de registrar a cobertura de um teste. Na ferramenta, a cobertura de um teste é representada pelo conjunto das assinaturas dos métodos capturadas pela instrumentação durante a execução de um teste, sem repetir as assinaturas, o que reduz a quantidade de dados que precisam ser armazenados. Já no framework, a instrumentação permite acompanhar no CFG a sequência de nós chamados durante a execução do teste, esta sequência de 19

31 nós constitui um sub-ramo do CFG, exigindo mais memória para guardar não só os nós, como a sequência em que ocorrem, mesmo que haja repetições. A RTS Quality finda por calcular duas das métricas também calculadas pelo framework: a inclusão e a precisão. Entretanto, a ferramenta traz duas novas métricas: a inclusão e a precisão médias. Cada uma das médias calculadas representam o resultado médio da inclusão e da precisão obtido pelo conjunto das modificações que apresentaram um mesmo tipo de tarefa que, como sugerido, pode apontar para as origens das deficiências da técnica de RTS utilizada Cálculo das Métricas Para compreender a métrica de inclusão, basta responder a seguinte pergunta: dados os testes da versa o antiga que precisam ser executados novamente na versa o atual, quantos a técnica de RTS conseguiu identificar?. Já para compreender a precisa o, a pergunta que precisa ser respondida é: dados os testes da versão antiga que não precisam ser executados na versão atual, quantos a técnica de RTS conseguiu identificar?. Figura 2. Conjuntos dos testes e as manipulações necessárias. 20

32 Na Figura 2 são apresentados os conjuntos A, B e C, que servem de dados de entrada para que a RTS Quality obtenha os conjuntos T, I e E, utilizados no cálculo das métricas de inclusão e precisão. Cada conjunto pode ser descrito da seguinte forma: (A) contém os testes existentes na versão inicial; (B) contém os testes existentes na versão final; (C) contém os testes que exercitam as modificações da versão final, obtido após a execução de todos os testes de B na versão final e selecionando apenas aqueles que exercutaram alguma modificação; (T) contém todos os testes não obsoletos da versão inicial; (I) contém os testes que a RTS deve incluir na regressão e; (E) contém os testes que a RTS deve excluir da regressão. O problema que uma técnica de RTS deve enfrentar pode ser definido da seguinte forma: a tarefa de identificar testes de regressão implica em selecionar, dentre todos os testes não obsoletos da versão inicial, quais testes exercitam as modificações da versão final. Esta definição desobriga as técnicas de RTS de selecionarem testes novos, que existam apenas na versão final (B), por isso o conjunto de todos os testes não obsoletos (T) não possui testes exclusivos da versão final (B), razão pela qual o conjunto dos testes que exercitam as modificações da versão final (C) foi reduzio ao conjunto dos testes que devem ser incluídos na regressão (I). Para calcular a inclusão (i) de uma tarefa (x), seguindo o que foi proposto por (ROTHERMEL e HARROLD, 1997), é preciso ter em mãos os seguintes conjuntos: a relação dos testes que devem obrigatoriamente ser incluídos na seleção (I) para a tarefa analisada, obtido pela intersecção de A com C; e o conjunto dos testes que a técnica de RTS foi capaz de selecionar (S), também para a tarefa analisada. Desta forma, a porcentagem da correta inclusão de testes no conjunto de regressão, para a tarefa analisada, pode ser obtida através da Equação 1. Equação 1. Cálculo da porcentagem da Inclusão de uma tarefa. i x = S I I 100% 21

33 De forma semelhante à Inclusão, o cálculo da Precisão (p) para uma tarefa (x) também irá analisar os acertos da técnica de RTS, entretanto, serão analisados os testes que ela acertou em excluir do conjunto de regressão. Para tanto, fazem-se necessários os seguintes conjuntos: o conjunto total dos testes pré-existentes e não obsoletos (T); o conjunto dos testes que devem obrigatoriamente ser excluídos do conjunto de regressão (E) para a tarefa analisada; e o conjunto dos testes que a técnica foi capaz de excluir do conjunto de regressão (P) para a tarefa analisada. Os conjunto E e P podem ser obtido a partir de E = T I e de P = T S. Para concluir o cálculo da Precisão computase a Equação 2. Equação 2. Cálculo da porcentagem da Precisão de uma tarefa. p x = P E E 100% 2.7. Características das Modificações Para compreender melhor o impacto que uma modificação exerce sobre uma RTS, é preciso primeiramente compreender a natureza das modificações, conhecer sua granularidade e algumas de suas características. Uma modificação ocorre quando os desenvolvedores tentam remover, corrigir ou aperfeiçoar alguma das funcionalidades de um sistema de software e, como visto, é extremamente difícil prever o impacto que ela causará, pois mesmo ela ocorrendo em uma parte do sistema pode afetar o comportamento de outras partes. Uma RTS precisa identificar todas as partes do sistema que possam apresentar faltas e, como a versão anterior testada é considerada estável, ela busca apenas por locais onde as modificações ocorreram, pois são neles que as faltas podem ocorrer. Caso a RTS não seja capaz de analisar as partes direta e indiretamente impactadas, é provável que cometa erros. Neste contexto, é possível levantar as seguintes dúvidas: (i) o que define o início e o fim de uma modificação? (ii) para uma característica de uma modificação existe algum valor 22

34 que faça a RTS cometer mais erros? E em caso positivo, (iii) que características comuns apresentam as modificações que provocaram o erro da RTS? Uma modificação tem um início e um fim, que determinam quais alterações fazem parte ou não da modificação. A este limite dá-se o nome de unidade de análise, que deve ser escolhida para a análise. Como exemplos de granularidade têm-se: uma linha, um commit no repositório de código, um subramo de um Grafo de Controle de Fluxo (CFG Control Flow Graph), um método, uma classe ou uma tarefa. Tabela 2. Características de uma modificação. Características de uma modificação Tamanho da modificação: Quantidade de linhas, métodos ou classes; Complexidade da modificação: Diferença entre a complexidade antes e depois da modificação; Dono da modificação: O desenvolvedor que a realizou; Tipo da tarefa da modificação: O tipo da tarefa que realizou a modificação; Complexidade ciclomática da modificação: Quantidade de caminhos independentes; Ação da modificação: Adição, modificação ou exclusão; Cada modificação possui ainda um conjunto de características facilmente identificáveis e que podem assumir diferentes valores. A Tabela 2 apresenta algumas destas características, das quais foi selecionado apenas o tipo da tarefa, como explicado mais adiante. Cada valor de cada característica, pode ser facilmente obtido. O tamanho de uma modificação pode ser calculado pela quantidade de linhas, métodos ou classes que foram modificadas. Já a complexidade pode ser calculada pela diferença entre a complexidade antes e depois da modificação. O dono da modificação pode ser obtido através do repositório de código. O tipo da tarefa da modificação pode ser obtido a partir da mineração do banco de dados de uma ferramenta de gerenciamento de mudanças (CMT Data Base). A complexidade 23

35 ciclomática pode ser entendida como a diferença na quantidade de caminhos de execução independentes de um programa, antes e depois de uma modificação. Um programa aqui pode ser representado, por exemplo, por um método ou em um caso de uso, onde ocorreu a modificação. Por fim, a ação de uma modificação pode ser obtida através do repositório de código, verificando se ela adiciona, modifica ou exclui código. Para cada modificação a técnica de RTS utilizada pode sugerir um conjunto de testes que as exercitam, com base nos quais serão calculadas as métricas de inclusão e precisão, que serão apresentadas com mais detalhes na Seção 4.3. Toda via, para compreender o efeito que um valor de uma característica de uma modificação exerce sobre a RTS, as modificações que apresentem características e valores iguais podem ser agrupadas, e entãocalcula-se a média aritmética da inclusão e da precisão para cada valor. Com estas médias, é possível investigar em quais valores é mais frequente que a RTS cometa erros. Este trabalho adotou a característica do tipo da tarefa, com o intuito de investigar o efeito das tarefas sobre qualidade da seleção de testes realizada por uma RTS. É comum encontrar Ferramentas de Gerenciamento de Mudanças (CMT Change Management Tool) sendo utilizadas ao logo de todo o processo de desenvolvimento de um sistema, eles permitem a criação de pequenos processos chamados tarefas, que visam adicionar, modificar, ou remover alguma funcionalidade do sistema de forma organizada, descrevendo em detalhes o que deve ser feito pelos desenvolvedores para cumpri-las. O tipo de cada tarefa distingue a natureza das modificações que serão realizadas e, assim, é possível dizer que estão intimamente associados aos tipos das tarefas das modificações realizadas. 24

36 3. RTS QUALITY Este capítulo apresenta a RTS Quality, uma ferramenta de apoio ao estudo dos impactos que as técnicas de RTS podem sofrer diante dos diferentes tipos de tarefas de cada modificação, que analisam enquanto estimam o conjunto dos testes de regressão necessários a nova versão de um SUT. A Seção 3.1 apresenta uma visão geral da ferramenta, seu propósito, arquitetura e funcionamento. A Seção 3.2 detalha o conjunto de componentes que constituem cada módulo e suas inter-relações. A Seção 3.3 esclarece os procedimento que devem ser seguidos para configurar a ferramenta e fazê-la funcionar. Por fim, a Seção 3.4 apresenta a aplicação da ferramenta a um programa de exemplo, com o objetivo de esclarecer quais são os dados obtidos a cada etapa Arquitetura Geral da Ferramenta A RTS Quality é um plug-in desenvolvido para o Eclipse IDE que tem como objetivo analisar técnicas de seleção de testes de regressão. Ela subdivide-se em 3 módulos, conforme apresentados na Figura 3. São eles: (i) History Miner que é o módulo responsável por obter, entre duas versões de um sistema analisado, a relação das tarefas finalizadas, seus tipos, revisões, bem como o conjunto das modificações realizadas em cada revisão, além também de fazer o checkout dos projetos necessários em cada fase do estudo; (ii) RTS Regression Test Selection que é o responsável por definir uma interface para a ferramenta, possibilitando a implementação de diferentes técnicas de RTS, além também, de acolher a lógica da própria implementação; (iii) Executer é o responsável por coordenar a execução dos diferentes módulos do sistema, dando sequência as fases do estudo que avaliará o desempenho da RTS Além dos módulos principais a RTSQuality possui também 1 subsistema, chamado TTracker. O subsistema TTracker, também desenvolvido por este trabalho, é responsável pela função de instrumentação do sistema sob teste. Ele está subdividido em 3 módulos, que podem ser observados na Figura 3. São eles: (i) 25

37 Test Tracker que é o módulo responsável por rastrear a execução de cada teste, identificando cada um dos métodos chamados por ele; (ii) Instrumentation Data que é o responsável pela estrutura de dados que armazena as informações obtidas pelo Test Tracker e; (iii) File Persistence o responsável por serializar e deserializar os objetos relacionados aos dados do Instrumentation Data persistindo-os e recuperando-os de arquivos. Figura 3. Diagrama de componentes e suas dependências. Na Figura 3, é possível observar também o conjunto das principais bibliotecas externas utilizadas pela ferramenta: (i) Eclipse Platform que possibilita analisar os projetos abertos no eclipse, bem como a implementar o plug-in que faz interface com o usuário; (ii) JUnit que permite que os testes automáticos também tenham sua execução rastreada; (iii) JDBC que implementa os drivers que possibilitam a conexão com as bases de dados da ferramenta de gerenciamento de mudanças (CMT Change Management Tool); (iv) SVNKit que permite consultar informações armazenadas no repositório de código SVN do sistema sob análise e; (v) AspectJ que possibilita a 26

38 implementação da instrumentação que intercepta a execução dos testes, a partir de pontos específicos do sistema. Por fim, é possível observar também os componentes que representam as bases de dados que detêm as informações do sistema sob análise: o (i) CMT Data Base que possui todas as informações relativas as tarefas, descrevendo, para cada uma, as atividades e modificações que devem ser realizadas para seu cumprimento, bem como o andamento de tais modificações; e o (ii) SVN Repository que detém as informações do sistema de controle de versões, contendo os projetos em suas diferentes fases de desenvolvimento, no trunk, nos branches e nas tags Projeto Detalhado da Ferramenta Esta seção apresenta cada um dos componentes que constituem a ferramenta, seus módulos, bibliotecas externas utilizadas durante a implementação, bem como as bases de dados utilizadas pelo sistema sob análise. Observando a Figura 3, é possível identificar o módulo RTSQuality na cor cinza escuro, o módulo do subsistema TTracker na cor preta, os componentes externos na cor cinza claro, e as bases de dados do sistema analisado na cor branca Módulo Executer Este módulo implementa um plug-in utilizando a biblioteca Eclipse Platform e é o responsável por coordenar a execução das funções dos demais módulos, executando-os no momento adequado para o correto sequenciamento das fases do estudo. Cada uma das interações do Executer com classes de outros módulos podem ser observadas na Figura 4, que será explicado a seguir. Antes de iniciar o estudo, o Executer solicita que o usuário defina em arquivos de configuração as informações necessárias para o acesso ao SVN Repository e ao CMT Data Base do sistema analisado. Estas informações são recuperada através do método Executer.loadSVNConfig(...). Outra informação requeridas ao usuário é a especificação dos projetos que compõem o sistema, juntamente com o número das versões inicial e final utilizadas no estudo. Tais 27

39 informações serão recuperadas pelo Executer através do método Executer.loadProjectsManually(). Figura 4. Sequência de execução da RTS Quality. Seguindo a ordem da Figura 4, na Fase 1 do estudo, através do método Executer.obtainTasksModifiedMethods(...), nos passos de 1 a 3, a ferramenta solicita ao History Miner que capture todos os números de tarefas, seus tipos e revisões entre as revisões inicial e final informadas pelo usuário, estas informações são salvas em um XML, para permitir que o estudo possa saltar esta etapa nas próximas execuções. De posse dessas informações, nos passos 4 e 5, o History Miner deve obter também os métodos modificados em cada revisão de cada tarefa, bem como os métodos cujas modificações foram desfeitas durante a revisão. As modificações desfeitas ocorrem quando em uma revisão da tarefa o desenvolvedor realiza alterações, e em outra revisão a desfaz para tentar uma nova abordagem de solução. As modificações desfeitas precisam ser excluídas do conjunto de modificações desta tarefa, caso contrário poderia reunir métodos equivocadamente. Na Fase 2, o Executer, nos passos de 6 a 8, solicita ao History Miner que faça o checkout da revisão inicial do sistema, baixando cada um dos projetos necessários, e incluindo neles a instrumentação do Módulo TTracker, isto é feito através do método Executer.checkoutExecuteDelete(...). Nos passos de 9 a 28

40 12 o Executer é interrompido para que o usuário compile os projetos, rode o sistema e execute cada um dos testes manuais especificados para esta versão. Após estes procedimentos, o Executer retoma o controle e recupera o Instrumentation Data contendo os Execution Traces gerados durante a execução dos testes, adicionando ao Instrumentation Data todos os demais métodos que não foram cobertos pelos testes, chamando o seguinte método: ProjectUtil.setAllUncoveredMethods(...). Em seguida, nos passos de 13 a 15, a RTS escolhida é executada para que selecione quais testes devem e quais não devem ser reexecutados após as modificações de cada tarefa. O conjunto de todos os testes e os conjuntos de inclusão e precisão são salvos em arquivos. Na Fase 3, nos passos 16 e 17, o Executer solicita ao History Miner que faça o checkout da revisão final do sistema, passando o controle, nos passos de 18 a 20, para que o usuário execute os mesmos procedimentos da revisão inicial. Ao finalizar todos os testes programados, o Executer retoma o controle e, nos passos 21 e 22, ele mesmo obtém quais testes eram realmente necessários, como base nos Execution Traces gerados na execução dos testes na revisão final. Então, antes de seguir para a próxima fase, os resultados são salvos em arquivos, através do método FileUtil.saveObjectToFile(...). Na Fase 4, para cada tarefa, nos passos 23 e 24, o Execute calcula as métricas de inclusão, com base nos testes que a técnica de RTS selecionou, e as métricas de precisão, com base nos testes que a RTS excluiu. Tanto a seleção quanto a exclusão da RTS, são comparadas a seleção e a exclusão realizada pelo Executer, para obter a quantidade de acertos. Os cálculos necessários para obtenção das métricas de inclusão e precisão serão posteriormente detalhados na Seção 4.3, e são calculadas através do método Executer.calculateMetricsAndAverages(...). Após calcular as métricas, nos passos 25 e 26, as tarefas são agrupadas com base em seus tipos e, nos passos 27 e 28, para cada tipo é calculada a inclusão e precisão médias, através do método Executer.finalizeAverages(...). 29

41 Módulo History Miner Este módulo foi customizado para atender ao processo de desenvolvimento do SIGAA, onde cada versão validada contém as modificações de um conjunto de tarefas finalizadas, cada tarefa é implementada no trunk do SVN Repository, e quando todas as tarefas que constituem uma versão são finalizadas, as modificações são copiadas uma por uma para o branch de produção, registrando sempre o número da tarefa copiada nos logs. Quando todas as tarefas são copiadas para produção, testadas e validadas, é feita uma cópia para uma nova tag, onde a versão ficará registrada. É possível observar este processo de controle de versões em no exemplo de um sistema fictício apresentado nas Tabelas 3 e 4. A Tabela 3 descreve três diferentes versões de um sistema, discriminando cada uma das tarefas que são requeridas para que o sistema evolua de uma versão para a seguinte. Cada tarefa por sua vez necessitará de uma ou mais revisões no trunk para que seja dada como finalizada, quando todas as tarefas de uma versão forem concluídas, cada modificação realizada será transferida para o branch de produção, onde as modificações serão postas a prova pela equipe de testes e validada pelos projetistas e arquitetos. Ao finalizar a validação, a versão pode então ser copiada para uma tag, recebendo o nome do sistema e o número da versão. Tabela 3. Exemplo de sistema: versões e suas tarefas necessárias. version required tasks 1 1 and and and... A Tabela 4 exemplifica a evolução do sistema através das revisões, cada revisão representa um commit de código submetido ao SVN Repository em seus diferentes diretórios (trunk, branch e tag). Notem que foram necessárias duas revisões (1 e 2) para finalizar a tarefa 1 e mais outra revisão (3) para finalizar a última tarefa necessária à versão 1 do sistema. Neste ponto, as modificações de cada tarefa são copiadas individualmente para o branch de produção nas 30

42 revisões 4 e 5 e, após copiar e validar todas as modificações, uma nova cópia é feita para a tag da versão 1 (revisão 6). A versão da tag geralmente é um número a mais que a revisão do branch, por exemplo as revisões 6 e 5 respectivamente, entretanto, pode acontecer de um outro commit ser realizado depois da validação e antes da cópia do sistema para a tag, como o commit da revisão 13, sendo assim, a forma correta de se obter a revisão no branch que possua código equivalente ao da revisão na tag, é procurando pela última revisão no branch que ocorreu antes da revisão na tag. Tabela 4. Exemplo de commits em um repositório SVN. revisions trunk branch tag commit log 1 changes of task 1 2 changes of task 1 3 changes of task 2 4 copy of changes on trunk 2 task 1 finished 5 copy of changes on trunk 3 task 2 finished 6 copy of branch 5 version 1 finished 7 changes of task 3 8 changes of task 4 9 changes of task 5 10 changes of task 3 11 copy of changes on trunk 8 task 4 finished 12 copy of changes on trunk 10 task 3 finished 13 changes of task 5 14 copy of branch 12 version 2 finished O History Miner funciona da seguinte forma, as versões inicial e final do sistema, informadas pelo usuário ao Executer, estão registradas em duas tags distintas, entretanto, nelas não há registo algum de quais tarefas foram atendidas para que uma versão evoluísse até a outra. Tais informações serão encontradas apenas no branch de produção. Desta forma, é preciso obter, para cada tag, sua revisão correspondente no branch de produção, isto é feito através do método HistoryMiner.getHeadRevision(...). Como a tag é uma cópia no tempo do branch de produção, é possível concluir que a revisão no branch é algum número inferior a revisão da tag, bastando consultar qual foi o último commit no branch antes da cópia, através do método HistoryMiner.getPreviousRevision(...). E assim, o History Miner obtém as revisões inicial e final no branch para cada 31

43 versão do sistema. Vale observar que a revisão inicial corresponde ao sistema antes das modificações, sendo assim, as modificações não serão procuradas nesta revisão, por isso serão analisadas as revisões a partir da subsequente da revisão inicial, para obtê-la é utilizado o método HistoryMiner.getNextRevision(...). Para que o History Miner obtenha as tarefas realizadas entre as revisões, ele consulta todos os logs das operações de commit no branch de produção entre as duas revisões, onde é possível encontrar os números de identificação de cada tarefa, registrados pelos próprios desenvolvedores, através do método HistoryMiner.getTaskNumberFromLogMessage(...). Após recuperar todos os números das tarefas, o History Miner utiliza a biblioteca do JDBC para consultar o CMT Data Base, onde pode encontrar as tarefas válidas a partir de seus identificadores, recuperando, também, outras informações relevantes ao estudo como seus tipos e logs de andamento. É a partir destes logs que serão extraídos os números das revisões no trunk, onde as modificações foram de fato realizadas. O identificador das revisões também são registrados pelos próprios desenvolvedores, à medida que concluem suas tentativas de atender a tarefa. Esta função está disponível através do método HistoryMiner.populateTasksTypeById(...). Como visto, as revisões das modificações se encontram no trunk, desta forma, o History Miner pode consultar tais revisões para obter cada uma das linhas modificadas em cada arquivo de classe Java do sistema, utilizando a operação SVNDiffClient.doDiff(...) do SVNKit. Além das modificações, ele analisa cada classe Java modificada para obter as linhas de início e fim de cada método, assim é possível inferir a quais métodos pertencem cada uma das linhas incluídas, na nova versão da classe, e das excluídas, na versão antiga da classe. Ao analisar todas as revisões de cada tarefa o History Miner obtém a relação dos métodos modificados entre as duas versões, função, esta, implementada pelo método HistoryMiner.getChangedMethodsSignaturesFromProjects(...). Outra operação desempenhada pelo History Miner é a de baixar os projetos com base numa revisão informada pelo Executer, através do método 32

44 HistoryMiner.checkouOrUpdateProjects(...), que por sua vez, ao ser solicitado, executa o método SVNUpdateClient.doCheckout(...) do SVNKit para cada um dos projetos que compõem o sistema. Cada projeto do sistema que deve ser rastreado recebe a instrumentação do TTracker através do método HistoryMiner.configureAspectJ(...), em seguida, todos os projetos são convertidos em projetos eclipse, e posteriormente importado para o Project Explorer do Eclipse, através do método HistoryMiner.importProject(...). A partir deste ponto o usuário é capaz de, utilizando o próprio eclipse para compilar, rodar e executar os testes no sistema. Figura 5. Classes do módulo History Miner e suas associações. 33

45 A seguir serão descritas as associações entre as classes deste módulo conforme apresentadas na Figura 5. A classe SVNConfig recebe do Executer as informações da URL, do usuário e da senha para acesso ao SVN Repository. A classe ChangedAssetsMinerUtil implementa os ativos modificados dos projetos, sendo capazes de fornecer as UpdatedLines, que representam as linhas alteradas de cada classe. O conjunto das UpdatedLines de uma classe constituem uma ClasseUpdates, várias destas, por sua vez, constituem o conjunto de atualizações de um mesmo projeto, o ProjectUpdates. A classe MethodLimitBuilder é capaz de determinar, a partir das classes modificadas, quais são as linhas limite dos métodos, isto é, linhas de início e de fim de cada método, os chamados MethodLimits, que permitem que o UpdatedMethod descubra a quais MethodLimits as UpdatedLines pertencem, consequentemente descobrindo quais foram os métodos modificados Módulo RTS Regression Test Selection Este módulo é inicializado pelo Executer ao criar um objeto da classe pai RegressionTestTechnique, para receber uma instância de uma classe filha que implemente a lógica de uma técnica de RTS. No caso do estudo realizado neste trabalho, a classe filha Pythia implementa a técnica de mesmo nome, descrita na Seção A classe pai possui alguns parâmetros comuns a todas as técnicas de RTS e alguns métodos abstratos, que serão os únicos utilizados pela ferramenta durante o estudo, o que permite que novas técnicas sejam implementadas sem a necessidade de realizar modificações no Executer. A classe filha se encarrega de implementar cada um dos métodos abstratos da classe pai conforme sua própria lógica. Ambas as classes, pai e filha, podem ser observadas na Figura 6. Ainda antes que o Executer rode a RTS, ela poderá precisar receber algumas informações não previstas pela classe pai, mas cruciais a sua execução. Isto é possível através do método RegressionTestTechnique.setConfiguration(...). No caso da Pythia, que se baseia na versão inicial do sistema para inferir os testes necessários à versão 34

46 final, o Executer precisará passar o Instrumentation Data contendo os Execution Traces gerados durante a execução dos testes. Outra informação crucial é a relação dos métodos modificados entre as versões inicial e final, que são enviadas à técnica através do método RegressionTestTechnique.setModifiedMethods(...). Como a RTSQuality utiliza-se da mesma abordagem de busca pelas modificações de que a Pythia faz uso, para evitar redundância a ferramenta obtém o conjunto e o compartilha com a Pythia, caso a RTS utilize uma abordagem de busca pelas modificações diferente da ferramenta, deverá implementar sua própria lógica. Feito isto, o Executer pode chamar o método principal da RTS, o RegressionTestTechnique.executeRegression(), que se encarrega de consultar cada uma das modificações no Instrumentation Data configurado, retornando o conjunto de testes que cobriram os métodos modificados. Figura 6. Classes do módulo RTS e suas associações. Outros dois métodos abstratos presentes na classe pai são o RegressionTestTechnique.getMethodStatePool(...) e o RegressionTestTechnique.getSelectedTestCoverages(), que exigem que a RTS seja capaz de retornar duas informações: os estados dos métodos contidos em sua instância do Instrumentation Data, que descrevem se o método foi 35

47 coberto e/ou modificado durante o processo de evolução entre as duas versões e; o conjunto dos testes selecionados pela técnica. Estas duas informações são importantes para que seja possível a realização dos cálculos das métricas de inclusão e precisão Subsistema TTracker O subsistema TTracker é o módulo responsável por rastrear a execução dos testes, gerando as chamadas Execution Traces, utilizando a estrutura de dados do módulo Instrumentation Data. Ele é capaz de obter e armazenar quatro tipos básicos de informações: a assinatura dos métodos que iniciam a execução dos testes, as entradas que estes métodos recebem por parâmetro, a relação de todos os métodos chamados a partir dos testes e, para cada método chamado, o conjunto dos testes que o exercitaram. Apesar de ser gerada nesta ordem, os Execution Traces são construídos para serem lidos na forma reversa, pois é desejado que, a partir de um método, seja possível identificar quais foram os testes que o exercitaram Módulo Test Tracker Este é o módulo responsável por implementar toda a lógica de captura de informações utilizando o AspectJ. O aspecto implementado possui dois Advices principais, um Before e um After., tornando-os ideais para registrar a execução de testes manuais no sistema, tendo em vista que são os primeiros métodos chamados pelo usuário ao utilizar a interface. Neste trabalho, a instrumentação desenvolvida tem interesse em capturar o fluxo de chamadas de métodos de ação, de classes descritas como Managed Beans, frequentemente utilizados para submeter requisições ao servidor de um sistema Web. Através de um pointcut, os métodos executados são monitorados por um advice before, que captura a assinatura e as entradas que foram passadas ao método, a captura prossegue para cada método subsequentes chamado a partir da ação, obtendo para cada um os mesmos tipos de informações. Quando um método chamado pelo fluxo retorna seu resultado, um advice after se encarrega de capturar sua 36

48 assinatura e verificar se ela corresponde a assinatura do método de ação que iniciou o fluxo de chamadas, em caso afirmativo a captura é finalizada. Esta solução objetiva implementar o que foi proposto na Definição 4 para técnicas de RTS (Seção 2.3.1), que trata das estruturas de rastreamentos da execução (Execution Traces). Incluir esta instrumentação em um sistema web baseado em Managed Beans permite capturar os Execution Traces de cada teste executado manualmente. Os métodos interceptados pelo Advice Before são definidos pelo pointcut beforemanagedbeanaction(), que intercepta um método sempre que classificado como um método de ação pertencente a um Managed Bean, ou como um método chamado a partir de um destes. Para tanto, durante a compilação, o AspectJ introduz a rotina deste Advice antes de todos os métodos que pertençam a uma classe que possua a exceto para construtores e métodos iniciados com get, is ou set, não esquecendo de introduzir a rotina, também, antes de todos os métodos chamados a partir deste, independentemente de sua classificação. A rotina implementada pelo Adivice Before recupera a estrutura de dados do Instrumentation Data e verifica se existe algum Execution Trace aberto através do método TestCoverageMapping.getOpenedTestCoverage(), em caso negativo, uma novo Execution Trace é criado e inserido na estrutura de dados, contendo a assinatura do método e as entradas passadas por parâmetro. Em caso positivo, o método é inserido no Execution Trace já aberto, sendo este inserido também no próprio método, que mantem um conjunto contendo todos os testes que já o exercitaram. Os métodos interceptados pelo Advice After são definidos pelo pointcut aftermanagedbeanaction(), que intercepta apenas os método classificados como de ação pertencente a um Managed Bean, não interceptando os métodos chamados a partir dele. Para tanto, durante a compilação, o AspectJ introduz a rotina deste Advice depois de tais métodos. Este pointcut é utilizado como condição de parada, tendo em vista que os testes serão considerados finalizados quando a ação do Managed Bean também o for. 37

49 A rotina implementada no Adivice After identifica que o método interceptado possuir a mesma assinatura daquele que iniciou o teste, isto feito, fecha o Execution Trace aberto utilizando o método TestCoverageMapping.finishTestCoverage() e persiste a estrutura de dados em um arquivo como método TestCoverageMapping.save(), dando por finalizado o teste. Alternativamente, os pointcuits são capazes de rastrear também os testes automatizados utilizando o JUnit, isso porque eles também buscam por métodos pertencentes a uma classe de testes, isto é, classes que estendam a classe TestCase do framework JUnit 3 ou possua a do JUnit 4. Para utilizar testes automatizados não há necessidade de configurações, pois ambos os modos são utilizados simultaneamente Módulo Instrumentation Data Este módulo possui todas as classes que compõem a estrutura de dados da ferramenta, ela é capaz de armazenar as informações dos Execution Traces de todos os testes, salvando informações sobre métodos, testes, tarefas e revisões envolvidas com o estudo. Cada uma das classes envolvidas com este módulo podem ser observadas na Figura 7 mais adiante, conforme descrito a seguir. A classe TestCoverageMapping é a principal da estrutura de dados do módulo Instrumentation Data, pois reúne todas as informações coletadas pela ferramenta. Ela implementa o padrão Singleton, onde todas as informações estão armazenadas em uma única instância estática da própria classe. Esta instância manipula diferentes tipos de objetos, apresentado a seguir. Um TestCoverage armazena o Execution Trace de um método de ação de um Managed Bean, quando o teste é manual, ou de um método de um TestCase JUnit, quando o teste é automático. Todos as instâncias finalizadas da classe TestCoverage ficam armazenadas em um conjunto chamado testcoverage, já as que ainda estão em construção, ficam dentro de um conjunto chamado testcoveragebuilding. Cada método do Execution Trace é armazenado em um MethodData, que por sua vez são armazenados dentro de 38

50 Figura 7. Classes do módulo Instrumentation Data e suas associações. dois mapeamentos distintos, um chamado methodpool e outro cham ado methodpoolstate, este último correlaciona os métodos do methodpool com o seu estado, isto é, se ele foi modificado ou coberto. Esta informação é armazenada em um MethodState dentro do MethodData. Cada teste é representado por um TestCoverageGroup, que reuni uma ou mais instâncias da classe TestCoverage. Cada execução realizada durante a 39

51 etapa de testes é rastreada e armazenada em um TestCoverage, dentro de um mesmo TestCoverageGroup, até que o usuário informe através da interface, que o teste foi finalizado, assim, as próximas instâncias de TestCoverage farão parte do próximo TestCoverageGroup. Quando os testes são automatizados não é necessário informar quando o teste for finalizado, pois cada TestCoverageGroup será finalizado após a inclusão do primeiro TestCoverage. Para cada novo método de ação executado, o módulo Test Tracker cria uma nova instância da classe TestCoverage, inserindo-a na estrutura de dados através do método TestCoverageMapping.addTestCoverageBuilding(...). Esta instância armazena a assinatura do método que iniciou a ação e todos os métodos que forem chamados a partir dele, os chamados métodos cobertos ou CoveredMethod, utilizando o método chamado TestCoverage.addCoveredMethod(...). O CoveredMethod contém a lista dos parâmetros de entrada passados ao método durante sua execução e também um MethodData, que será único em toda a estrutura de dados, sendo criado uma única vez e recuperado através do mapeamento methodpool nas demais vezes, através do método TestCoverageMapping.findOrCreateMethodData(...). O MethodData armazena a assinatura do método, seu estado de coberto e na o modificado em um MethodState, bem como, adiciona o TestCoverage que o cobriu em sua lista chamada testscoverage, que contém todos os testes que o cobriram até o momento. Esta organização justifica o alto grau de acoplamento entre estas classes TestCoverage, CoveredMethod e MethodData. Após a captura dos testes, as classes MethodData e MethodState são também utilizadas pelo Executer, que inclui na estrutura todos os métodos do sistema que na o foram cobertos pelos testes, definindo seus MethodState como na o coberto e na o modificado, através do método ProjectUtil.setAllUncoveredMethods(...). Em seguida, recupera da lista de tarefas todas as assinaturas dos métodos que foram modificados entre as revisões inicial e final, utilizando o método Executer.getTasksModifiedMethods(), com esta lista, executa o método 40

52 TestCoverageMapping.setModifiedMethods() para alterar o estado de tais métodos da estrutura de dados de na o modificado para modificado. Toda esta organização permite que consultas sejam realizadas, tais como: quais métodos foram modificados?, quais outros foram cobertos por testes?, quais testes cobriram um determinado método?, quais métodos modificados foram cobertos por testes?, ou o mais importante para o módulo RTS, referente a selec a o dos testes, quais testes cobrem métodos modificados?. Tais consultas estão respectivamente disponíveis através dos métodos da classe TestCoverageMapping mostrados a seguir: getmodifiednotcoveredmethods(), getnotmodifiedcoveredmethods(), gettestscoveragebycalledmethod(), getmodifiedcoveredmethods() e gettestscoveragemodifiedmethods(). Para ajudar a compreender a composição e o encapsulamento das classes que compõem a estrutura de dados deste módulo, a Figura 8 foi elaborada, onde as composições das classes são apresentadas. Figura 8. Composição e encapsulamento das classes do Instrumentation Data Módulo File Persistence Este módulo permite salvar objetos serializáveis e textos em arquivo na forma de stream, através dos métodos FileUtil.saveObjectToFile(...) e 41

53 FileUtil.saveTextToFile(...), bem como as operações reversas utilizando os métodos FileUtil.loadObjectFromFile(...) e FileUtil.loadTextFromFile(...). Todas as classes do Instrumentation Data são serializáveis, permitindo persisti-las ao longo do estudo. As informações salvas serão utilizadas posteriormente por outros módulos em diferentes fases do estudo. O Executer salva as tarefas, suas revisões e modificações para que seja possível continuar o estudo sem ter que obtê-las novamente. As técnicas de RTS salvam três conjuntos de testes distintos, um contendo todos os testes, outro contendo todos os testes selecionados por ela, e outro contendo todos os excluídos. O Executer, durante o processo de identificação dos testes que realmente deveriam ter sido incluídos pela técnica, salva seus próprios conjuntos de inclusão e exclusão de testes. Ao finalizar a análise dos testes em ambas as revisões, o Executer recupera todos os conjuntos citados para utilizá-los nos cálculos das métricas Instanciação e Funcionamento da Infraestrutura Para que o estudo seja iniciado, agora que detalhes do funcionamento da RTS Quality foram esclarecidos, resta: implementar uma técnica de RTS e apresentar as características do sistema sob teste (SUT), que serão essenciais para que a ferramenta funcione. Para desenvolver uma técnica de regressão utilizando o módulo RTS, a técnica deve implementar uma nova classe que estenda a classe pai RegressionTestTechnique, como visto na Seção 3.2.3, implementando os métodos exigidos incluindo neles sua própria lógica, sendo implementada no mesmo pacote que a classe pai (br.ufrn.dimap.rtquality.regressiontest). Para que a ferramenta funcione, é preciso que o SUT deve ter implantado o sistema de controle de versões, o SVN Repository e possuir uma ferramenta de gerenciamento de mudanças (CMT). O SVN Repository deve possuir uma grande quantidade de revisões que atendam diferentes tipos de tarefas cadastradas pelos desenvolvedores no CMT Data Base, para reforçar a validade 42

54 dos resultados obtidos no estudo. Ambas as ferramentas devem fornecer acesso às suas bases de dados. Faz-se ainda necessário que a equipe de testes forneça dois conjuntos de informações à RTS Quality, cada um contendo as URLs, os usuários e as senhas para acessar o SVN Repository e a CMT Data Base. Cada uma destes conjuntos deve ser descrito em um arquivos XML dentro do próprio workspace do SUT, em um diretório chamado config. Os arquivos devem se chamar dbinfosvn.xml e dbinfocmt.xml, que seguem a mesma estrutura apresentada na Listagem 1. <dbinfo> <url> <user>username</user> <password>userpassword</password> </dbinfo> Listagem 1. XML contendo as informações para acesso a uma base de dados. SELECT tipo_tarefa.denominacao tipo, status_tarefa.denominacao status FROM iproject.tarefa INNER JOIN iproject.tipo_tarefa ON tarefa.id_tipo_tarefa = tipo_tarefa.id_tipo_tarefa INNER JOIN iproject.status_tarefa ON tarefa.id_status = status_tarefa.id WHERE tarefa.numtarefa =? Listagem 2. Script SQL para obter o tipo e o estado de uma tarefa do SIGAA. SELECT substring(log_tarefa.log, '([Revisão revisão Revisao revisao]+[: ]*[0-9]+)') revisao FROM iproject.log_tarefa INNER JOIN iproject.tarefa ON log_tarefa.id_tarefa = tarefa.id_tarefa INNER JOIN iproject.tipo_tarefa ON tarefa.id_tipo_tarefa = tipo_tarefa.id_tipo_tarefa WHERE tarefa.numtarefa =? AND log_tarefa.log ~ '([Revisão revisão Revisao revisao]+[: ]*[0-9]+)' Listagem 3. Script SQL para obter as revisões de uma tarefa do SIGAA. Para a CMT, será necessário também a elaboração de dois arquivos de scripts SQL, salvos também no diretório config. Os scripts devera o se chamar tasksearch.sql, que conterá um script SQL para recuperar o tipo e o estado 43

55 de uma tarefa a partir de seu número identificador, e revisionsearch.sql, um script SQL para recuperar todas as revisões de uma tarefa, também a partir de seu identificador. Para o SIGAA foram utilizados os scripts SQL tasksearch.sql e revisionsearch.sql apresentados na Listagem 2 e 3, respectivamente. Caso a CMT não permita acessar sua base de dados nem realizar consultas SQL, a equipe de testes deverá obter manualmente as tarefas e suas revisões, ocorridas entre a revisão inicial e final, através das consultas que a interface da CMT disponibilize. Caso seja possível obter as tarefas, suas informações devem ser organizadas em um arquivo XML, dentro do diretório config, chamado tasks.xml, conforme exemplificado na Listagem 4. <list> <br.ufrn.dimap.ttracker.data.task> <id>120986</id> <type>erronegociovalidacao</type> <revisions> <br.ufrn.dimap.ttracker.data.revision> <id>153679</id> </br.ufrn.dimap.ttracker.data.revision> <br.ufrn.dimap.ttracker.data.revision> <id>153680</id> </br.ufrn.dimap.ttracker.data.revision> </revisions> </br.ufrn.dimap.ttracker.data.task> </list> Listagem 4. XML contendo a relação das tarefas e suas revisões. É comum que alguns sistemas possuam mais de um projeto que combinados implementam o SUT completo, além disso, o próprio projeto do TTracker fará parte do próprio SUT, pois contém o código de instrumentação, devendo ser incluído no mesmo workspace. Com isto, é necessário que a equipe de testes gere um arquivo XML chamado projects.xml, contendo a relac a o dos projetos com as informações apresentadas na Listagem 5: o diretório do projeto dentro das estrutura do SVN Repository (projectpath); o nome que o projeto terá dentro do workspace (projectname); se o projeto deve ser rastreado ou não (totrace) e; se o projeto deve ser baixado ou não (tocheckout), caso não já se encontre no diretório do workspace. 44

56 Será necessário que os pesquisadores sejam capazes de compilar os projetos que compõem o SUT, tendo em vista que cada um pode apresentar requisitos divergentes para que seja inicializado, ficando a equipe responsável por configurar o Eclipse IDE com eventuais plug-ins e bibliotecas que se encontrem ausentes. Vale ressaltar que, devido a inclusão dos aspectos em alguns dos projetos, a compilação deve consumir um tempo maior, dependendo da quantidade de Managed Beans e Testes JUnit presentes no SUT, entretanto, como não há interesse em medir o desempenho da técnica no tempo, este consumo pode ser ignorado. Após a compilação os pesquisadores devem configuração de servidores de aplicação, as bases de dados ou quais quer outros componentes necessários para a execução do sistema. Isto feito, será possível dar início ao estudo. <projects> <project> <projectpath>/br.ufrn.dimap.ttracker</projectpath> <projectname>/br.ufrn.dimap.ttracker</projectname> <totrace>false</totrace> <tochekout>false</tocheckout> </project> <project> <projectpath>/br.ufrn.dimap.sample</projectpath> <projectname>/sample</projectname> <totrace>true</totrace> <tochekout>true</tocheckout> </project> </projects> Listagem 5. Exemplo do XML de configuração dos projetos de um SUT Pontos de Configuração A RTS Quality foi pensada para auxiliar no estudo dos impactos causados pelos tipos da tarefas sobre diferentes técnicas de RTS, podendo estas serem utilizada sobre diferentes sistemas, executando tanto testes manuais quanto automatizados. Esta seção tem por objetivo esclarecer quais são as configurações que a ferramenta permite modificar para atender a diferentes técnicas e cenários. 45

57 A primeira configuração que pode ser alterada na ferramenta é a técnica de RTS utilizada. Como visto na Subseção 3.2.3, a RTS Quality foi desenvolvida com o propósito de analisar diferentes técnicas, e por isto, sua implementação só interage com a técnica de RTS através da classe abstrata RegressionTestTechnique, que define todos os métodos que uma RTS deve implementar para que possa ser utilizada pela ferramenta. É através desta classe que a ferramenta passa as informações do SUT em questão para a técnica, e ordena que ela selecione os testes que devem ser incluídos. O segundo ponto de reconfigurável previsto modifica o próprio sistema sob teste (SUT) que será analisado pela RTS. Como visto na Seção 3.3, é possível, através de arquivos de configuração, fornecer o acesso as bases de dados, tanto do repositório de código (dbinfosvn.xml) quanto da ferramenta de gerenciamento de mudanças (dbinfocmt.xml), definir as consultas que devem ser realizadas para obter os tipos das tarefas e os estados (tasksearch.sql) e as revisões (revisionsearch.sql) de cada tarefa e, por fim, definir quais projetos do repositório deverão ser analisados (projects.xml) Programa de Exemplo Para demostrar o funcionamento da RTS Quality como ferramenta de auxílio no processo de execução do estudo e facilitar sua compreensão, foi criado um exemplo didático, representado nas Figuras 9 e 10. Nelas é possível observar as classes de duas revisões do programa de exemplo. Em ambas as figuras é possível observar as classes de teste, na cor preta, as classes cujos métodos são cobertos pelos testes, na cor cinza escuro, e por fim, as classes cujos métodos não são chamados por nenhum ET, na cor branca. A presença de um na assinatura de alguns métodos, marca que alguma modificac ão foi realizada nele entre a revisão inicial e a final. Vale observar que apesar do exemplo ter utilizado testes JUnit, o termo Test foi empregado nas figuras num sentido mais genérico, podendo representar tanto um teste automático quanto um teste manual. Um teste manual é iniciado quando o usuário, através da interface da RTS Quality, clica no bota o Iniciar 46

58 Estudo, clicando no bota o Finalizar Teste a medida que os conclui, este bota o finaliza o teste e iniciando um novo automaticamente. Cada teste executado dispara a rotina de rastreamento, que cria instâncias da classe TestCoverageGroup, que registram cada uma das instâncias da classe TestCoverage, contendo todos os métodos executados a partir de um método de teste ou a partir de um método de ação de um Managed Bean. Para auxiliar o usuário, um Bip é emitido sempre que um método rastreado é finalizado, informando que novas ações já podem ser executadas. Na primeira fase do estudo são identificados, entre as duas revisões do programa de exemplo, os métodos modificados, listados a seguir: Class1.method1*(); Class2.method2*(); Class3.method3*(); Class7.method7*(); Class8.method8*(); Class10.method10*(); Class11.method11*(); Test4.testMethod4*(). Figura 9. Callgraph dos métodos chamados a partir dos testes da revisão inicial. Na Fase 2, de posse da primeira revisão, vista na Figura 9, o usuário executa todos os testes (T), e a instrumentação se encarrega de gerar um Execution Trace para cada um. Em seguida, a RTS Quality obtém os dados apresentados na Tabela 5, que são utilizados para contabilizar o total de métodos (M) da revisão inicial e dentre estes, a quantidade de métodos que foram modificados (MM), cobertos pelos testes (MC) ou modificados e cobertos simultaneamente (MMC). Em seguida, a ferramenta invoca a RTS Pythia para 47

59 que identifique quais testes serão incluídos (TI) e excluídos (TE). Estes resultados podem ser observados na primeira linha da Tabela 7. Esta tabela apresenta os dados obtidos pela ferramenta na mesma ordem que são gerados. Cada teste executado gera um conjunto contendo todos os métodos cobertos por ele. Em seguida a ferramenta analisa, dentre todos os métodos do sistema, quais foram cobertos, não cobertos, modificados e não modificados, gerando um conjunto para cada um dos quatro. Por fim, a RTS Pythia identifica o conjunto contendo todos os testes, aqueles que ela decidiu incluir e o restante que decidiu excluir. Tabela 5. Dados analisados pela RTS Quality na Fase 2. Teste Executado Métodos Cobertos T1.t1() {T1.t1(); C1.m1(); C2.m2(); C7.m7()} T2.t2() {T2.t2(); C4.m4(); C5.m5()} T3.t3() {T3.t3(); C9.m9()} Estado dos Métodos Não Modificado Não Coberto {C6.m6()} Modificado Não Coberto {C3.m3(); C8.m8()} Não Modificado Coberto {T1.t1(); T2.t2(); C5.m5(); T3.t3(); C9.m9()} Modificado Coberto {C1.m1(); C2.m2(); C4.m4(); C7.m7()} Seleções da RTS Pythia Todos os Testes {T1.t1(); T2.t2(); T3.t3()} Inclusão {T1.t1(); T2.t2()} Exclusão {T3.t3()} Na Fase 3, a RTS Quality obtém a revisão final para que o usuário execute todos os testes, para os quais são gerados Execution Traces diferentes dos da revisão inicial, conforme observado na Figura 10. Com base nos Execution Traces e nas modificações, a ferramenta obtém os dados da Tabela 6, que se assemelham aos da Tabela 5, entretanto a identificação e seleção dos testes são feitas pela própria RTS Quality e não pela Pythia. Com base nesses dados, determina os resultados almejados por esta fase, e que são apresentados na segunda linha da Tabela 7. 48

60 Figura 10. Callgraph dos métodos chamados a partir dos testes da versão final. Tabela 6. Dados analisados pela RTS Quality na Fase 3. Teste Executado Métodos Cobertos T1.t1() {T1.t1(); C1.m1(); C3.m3()} T2.t2() {T2.t2(); C4.m4(); C6.m6(); C11.m11()} T3.t3() {T3.t3(); C9.m9()} T4.t4() {T4.t4()} Estado dos Métodos Não Modificado Não Coberto {C5.m5()} Modificado Não Coberto {C2.m2(); C10.m10()} Não Modificado Coberto {T1.t1(); T2.t2(); C6.m6(); T3.t3(); C9.m9()} Modificado Coberto {C1.m1(); C3.m3(); C4.m4(); C11.m11(); T4.t4()} Seleções da RTS Quality Todos os Testes {T1.t1(); T2.t2(); T3.t3(); T4.t4()} Inclusão Antes da Validação {T1.t1(); T2.t2(); T4.t4()} Inclusão Válida {T1.t1(); T2.t2()} Exclusão {T3.t3()} A Tabela 7 sumariza as características básicas do programa de exemplo, juntamente com a quantidade de testes que a RTS Pythia acredita que devem ser executados e com a quantidade de testes que a RTS Quality afirma serem realmente necessários. 49

61 Tabela 7. Números obtidos nas Fases 2 e 3 do estudo. Técnica Revisão M MM MC MMC T TI TE RTS Pythia RTS Quality Na Fase 4, conforme as equações que serão apresentadas na Seção 4.3, são calculadas as métricas de inclusão e precisão que a RTS Pythia alcançou. Tais métricas correspondem as quantidades de testes que a Pythia conseguiu incluir e excluir corretamente, divididas pela quantidade total de testes corretos. Os resultados desta fase são apresentados na Tabela 8. Tabela 8. Métricas obtidas pela RTS Pythia para o Programa de Exemplo. Inclusão Precisão Cálculo das Métricas {T1. t1(); T2. t2()} {T1. t1(); T2. t2()} {T1. t1(); T2. t2()} {T3. t3()} {T3. t3()} {T3. t3()} = 1 1 = 1 = 100% = 2 2 = 1 = 100% Este programa de exemplo demonstra a execução do estudo de forma incompleta, tendo em vista que tal exemplo não possui sistema de gerenciamento de mudanças, e possui apenas duas revisões subsequentes analisadas, sendo inviável obter uma média relevante para os diferentes tipos de tarefas que as modificações podem assumir. O cálculo das médias serão demonstrados na Seção 4.4.4, onde as médias são calculadas para um sistema real. 50

62 4. ESTUDO EMPÍRICO Este capítulo descreve a configuração do estudo empírico para avaliação da técnica de RTS Pythia, baseada em diferença textual. A Seção 4.1, a seguir, apresenta os principais objetivos e questões de pesquisa. A Seção 4.2 apresenta o SUT. A Seção 4.3 descreve cada uma das fases do estudo, e por fim, a Seção 4.4 apresenta detalhes das métricas utilizadas Objetivos e Questões de Pesquisa Os principais objetivos do estudo empírico são: (i) avaliar uma adaptação da técnica de RTS Pythia para a linguagem Java; e (ii) validar o funcionamento da ferramenta RTS Quality. Para tanto, calculam-se as métricas propostas para avaliar a qualidade dos resultados obtidos pela técnicas de RTS Pythia, e assim, responder a questão de pesquisa que guia este estudo: (QP1) Os tipos das tarefas podem afetar a técnica de RTS Pythia?. Para validar a ferramenta RTS Quality ela deve ser capaz de constatar que a taxa de inclusão da Pythia, que é considerada segura, é de 100% para todos os tipos de tarefas Sistema Investigado O ferramenta RTS Quality será aplicada sobre um sistema web de larga escala, denominado Sistema Integrado de Gestão de Atividades Acadêmicas (SIGAA), mais especificamente as versões e , representadas pelas revisões e do branch de produção no SVN Repository do SIGAA. Desenvolvido originalmente na Superintendência de Informática da UFRN (SINFO/UFRN), o SIGAA possui diversas versões executando em diferentes instituições federais, estaduais e municipais do Brasil, sendo responsável por informatizar procedimentos da área acadêmica através dos seus diversos módulos. Dentre estes módulos, o da Biblioteca foi selecionado, que surgiu da necessidade de atender às demandas das bibliotecas da UFRN, tendo por objetivo controlar a chegada de livros, catalogação e empréstimos. 51

63 O Módulo da Biblioteca apresenta os seguintes pré-requisitos que viabilizam o estudo: (i) sua evolução foi toda registrada em repositório de código com controle de versões SVN, o que permite obter o código das diferentes modificações, cada qual associado a uma ou várias tarefas na ferramenta de gerenciamento de mudanças; (ii) o sistema foi implementado utilizando o framework Java Server Faces (JSF) e adota o padrão arquitetural Modelo-Visão- Controlador (MVC Model View Control), que viabiliza o rastreamento da execução das actions (métodos de ação) dos componentes Managed Beans, que representam classes Java que realizam o tratamento das diferentes requisições HTTP submetidas ao sistema, que são alvos de testes de aceitação; (iii) o sistema tem suas modificações gerenciadas por uma ferramenta de gerenciamento de mudanças (CMT), que definiram, para a versão inicial, quais modificações deveriam ser realizadas para que uma nova versão pudesse ser obtida Métricas Utilizadas Este estudo baseia-se nas métricas de qualidade das técnicas de RTS propostas por ROTHERMEL, G. e HARROLD, M. J. (1997): a inclusão e a precisão, cujos cálculos foram apresentados na Seção 2.6. Além destas métricas, é proposto o cálculo da inclusão e da precisão médias, obtidas para cada conjunto de modificações que a RTS analisou. Durante o cálculo das métricas, que serão descritos a seguir, a RTS Quality leva em consideração que cada tarefa corresponde a um conjunto de modificações que conduz a evolução do sistema, sendo assim, não calcula as métricas de todas cada modificação individualmente, mas sim a inclusão e a precisão para cada tarefa, segundo as modificações realizadas por elas. Como um dos objetivos deste estudo é compreender o quanto as modificações podem afetar uma técnica de RTS, levando-a a cometer erros, é preciso correlacionar a quantidade de erros cometidos com os tipos das tarefas das modificações. Como visto, a RTS Quality é capaz de discriminar quais testes a RTS selecionou para cada tarefa. Se as tarefas forem agrupadas de acordo 52

64 com seus tipos, é possível calcular a média aritmética das inclusões e das precisões alcançadas pela RTS para cada tipo de tarefa, e assim, seria possível medir os efeitos que cada tipo exerce sobre ela. Após calcular os valores de inclusão e precisão alcançados pela RTS para cada tarefa, a RTS Quality agrupa as tarefas de acordo com seus tipos (y) e para cada conjunto (T y ) soma todos os valores de inclusão (i x ) deste conjunto, dividindo o resultado pela quantidade de tarefas dentro do conjunto ( T y ), fazendo o mesmo cálculo para os valores de precisão (p x ). Desta forma serão obtidas a inclusão média (M yi ) e a precisão média (M yp ) de cada tipo de tarefa, que em resumo podem ser calculadas utilizando as variações da Equação 3: Equação 3. Cálculo das médias aritmética de inclusão e precisão de um tipo de tarefa. T y M yi = 1 T y i x i=1 T y M yp = 1 T y p x i= Fases do Estudo Para responder as questões de pesquisa propostas, este estudo foi organizado em 4 fases conforme apresentado a seguir: (i) levantamento das tarefas, seus tipos e revisões, identificando as modificações realizadas em cada uma; (ii) checkout, instrumentação, execução dos testes e da RTS Pythia na revisão inicial; (iii) checkout, instrumentação, execução dos testes e da RTS Quality na revisão final; e (iv) cálculo das métricas de cada tarefa e das médias de cada tipo de tarefa Fase 1 Obtenção das Tarefas e suas Modificações Como visto, após realizar a configuração da ferramenta e fornecer acesso as bases de dados do SVN Repository e da CMT Data Base, a RTS Quality é capaz de obter a lista das tarefas, e para cada uma, seu tipo e revisões. Como explicado na Seção 3.2.2, é a equipe de desenvolvimento quem determina o tipo de uma tarefa durante sua criação, cabendo a RTS Quality apenas recuperar 53

65 está informação na base de dados. Para cada revisão pertencente a tarefa são identificadas as modificações que ela traz, isto é feito através da operação de diferenciação textual entre o código-fonte da revisão e de sua antecessora, identificando as linhas diferentes e a quais métodos elas pertenciam (exclusão) ou passaram a pertencer (inclusão ou alteração). Ao finalizar a busca desta fase, restam apenas tarefas com o estado finalizado, que tenham alterado ao menos uma classe Java. Na Figura 11 a seguir, são apresentados os diferentes tipos de tarefa registrados para o Módulo da Biblioteca, a quantidade de vezes que cada tipo ocorreu, juntamente com suas porcentagens de frequência. Verificação; 18 Tarefas; 10,65% Aprimoramento; 23 Tarefas; 13,61% Erro de Execução; 40 Tarefas; 23,67% Erro de Padronização de Visualização; 12 Tarefas 7,10% Erro de Negócio/Validação; 76 Tarefas; 44,97% Figura 11. Tipos de tarefas mais frequentes e suas porcentagens Fase 2 Análise da Revisão Inicial Nesta fase a RTS Quality faz o checkout da revisão inicial do sistema, baixando os projetos necessários, e incluindo neles a instrumentação para o rastreamento da execução dos testes. Feito isto, a ferramenta é interrompida para que o usuário compile, rode o sistema e execute todos os testes manuais, conforme descritos na Tabela 11 do Anexo I. Após estes procedimentos, e de posse dos TestCoverageGroups que reúnem os diversos Execution Traces gerados para os vários testes executados, a ferramenta executa a técnica de RTS Pythia, que obtém a relação das modificações realizadas entre as duas versões do SUT, fazendo em seguida, a intersecção entre os conjuntos do métodos modificados com o dos métodos cobertos pelos testes, identificando aqueles que precisam ser testados. A partir dos métodos restantes a Pythia segue o caminho inverso 54

66 da execução, para encontrar os testes que devem ser incluído, excluindo os demais. A medida que o usuário executa todos os testes (T), a instrumentação gera um Execution Trace para cada um. Em seguida, a RTS Quality obtém a quantidade total de métodos (M), identificado aqueles que foram modificados (MM), cobertos pelos testes (MC) ou modificados e cobertos simultaneamente (MMC). Por fim, a ferramenta executa a RTS Pythia, para que identifique quais testes serão incluídos (TI) e excluídos (TE). Os dados obtidos nesta fase podem ser observados na primeira linha da Tabela 9. Tabela 9. Principais características das duas versões do SUT. Técnica Revisão M MM MC MMC T TI TE RTS Pythia RTS Quality Fase 3 Análise da Revisão Final Da mesma forma que na fase anterior a RTS Quality baixa a última revisão, inclui a instrumentação e tem seu fluxo interrompido para que o usuário realize os mesmos procedimentos, executando os mesmos testes da Tabela 11 do Anexo I, seguindo a mesma ordem. Nesta fase o mesmo procedimento é realizado, mas ao invés da RTS Pythia selecionar os testes, a própria RTS Quality é quem realizará este procedimento, obtendo por conta própria TI e TE. Os valores obtidos nesta fase podem ser observados na segunda linha da Tabela 9, que apresenta as principais características das duas versões do sistema da Biblioteca Fase 4 Cálculo das Métricas e das Médias Na Fase 3 a ferramenta RTS Quality utilizou as informações dos métodos modificados e o código da revisão final para determinar, com 100% de certeza, quais são os testes que existiam na revisão inicial que devem ser executados novamente na revisão final, o que permite avaliar a qualidade da seleção realizada pela Pythia. 55

67 As modificações são agrupadas em tarefas e para cada tarefa a Pythia sugere um conjunto de testes, este conjunto é comparado ao que foi proposto pela RTS Quality, e assim são calculadas as métricas de inclusão e precisão apresentadas na Tabela 12 do Anexo II. As tarefas, por sua vez, são agrupadas de acordo com seus tipos (T y ), e para cada tipo (y), são calculadas as médias aritméticas da inclusão (M yi ) e da precisão (M yp ), conforme explicado na Seção 4.3. Na Tabela 10 são apresentadas a soma das inclusões (Σi x ) e das precisões (Σp x ) de cada tarefa de um mesmo tipo, divididas pela quantidades de tarefas que o tipo possui ( T y ), juntamente como as porcentagens M yi e M yp resultantes. Tabela 10. Inclusão e precisão médias por tipo de tarefa. Tipo da Tarefa Inclusão Média Precisão Média Σi x / T y M yi Σp x / T y M yp Erro de Negócio/Validação 76/76 100% 75,98/76 99,97% Erro de Execução 40/40 100% 40/40 100% Aprimoramento 23/23 100% 22,94/23 99,77% Verificação 18/18 100% 17,98/18 99,89% Erro de Padron. de Visualização 12/12 100% 12/12 100% 4.5. Resultados do Estudo Nesta seção traz os resultados da aplicação estudo, apresentando na Subseção a avaliação da técnica de RTS Pythia aplicada sobre o Módulo da Biblioteca do SIGAA e respondendo a questão de pesquisa (QP1) e na Subseção são apresentados os resultados obtidos na avaliação da ferramenta RTS Quality ao analisar uma técnica de RTS segura Avaliação da Técnica de RTS Pythia Questão de Pesquisa 1. Os tipos das tarefas podem afetar a técnica de RTS Pythia? Com base nos resultados do estudo, é possível concluir que os tipos das tarefas não afetam, pelo menos não diretamente, o desempenho da técnica de RTS Pythia. 56

68 A avaliação da técnica não foi capaz de demonstrar grandes diferenças nas médias calculadas para os 5 diferentes tipos de tarefas encontrados na execução do estudo. A Pythia é considerada segura, sendo assim, é capaz de incluir todos os teste necessário evitando que faltas passem desapercebidas, entretanto, nada a impede de incluir também testes além do necessário, isto é, erros de precisão, o que de fato ocorreu ocasionando um consumo de tempo desnecessário durante a execução dos testes. Após a execução de 55 testes, que cobriram 146 métodos de ação em Managed Beans com coberturas distintas, foi possível observar que todos os 5 tipos analisados pela técnica de RTS Pythia apresentaram inclusão média de 100%, conforme apresentam a Tabela 10 e a Figura 12. Mas foi possível observar pequenas oscilações nos valores de precisão em 3 diferentes tarefas, provocando erros de precisão média em 3 tipos de tarefas, como mostra a Figura 13. Entretanto, com oscilações tão pequenas não é possível afirmar que a Pythia seja inapropriada para estes tipos. Porcentagem de Acerto 200% 100% 0% 100% 100% 100% 100% 100% Erro de Negócio/ Validação Erro de Execução Aprimoramento Verificação Erro de Padron. de Visualização Figura 12. Inclusão média alcançada pela RTS Pythia para cada tipo de tarefa. Porcentagem de Acerto Porcentagem de Erro 100,05% 100,00% 99,95% 0,03% 0,11% 99,90% 99,85% 99,80% 99,75% 99,97% 100% 0,23% 99,89% 100% 99,70% 99,77% 99,65% Erro de Negócio/ Validação Erro de Execução Aprimoramento Verificação Erro de Padron. de Visualização Figura 13. Precisão média alcançada pela RTS Pythia para cada tipo de tarefa. 57