Luciano Soares de Souza

Transcrição

1 Seleção de Casos de Teste com Restrição de Custo de Execução utilizando Otimização por Enxame de Partículas Por Luciano Soares de Souza Dissertação de Mestrado Universidade Federal de Pernambuco RECIFE, Fevereiro/2011

2 Universidade Federal de Pernambuco Centro de Informática Pós-graduação em Ciência da Computação Luciano Soares de Souza Seleção de Casos de Teste com Restrição de Custo de Execução utilizando Otimização por Enxame de Partículas Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação. Orientador: Flávia de Almeida Barros Co-Orientador: Ricardo Bastos Cavalcante Prudêncio RECIFE, Fevereiro/2011

3 Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 Souza, Luciano Soares de Seleção de casos de teste com restrição de custo de execução utilizando otimização por enxame de partículas / Luciano Soares de Souza - Recife: O Autor, xii, 75 folhas : il., fig., tab. Orientador: Flávia de Almeida Barros. Dissertação (mestrado) Universidade Federal de Pernambuco. CIn. Ciência da Computação, Inclui bibliografia. 1. Engenharia de software. 2. Inteligência artificial. 3. Testes de software. I. Barros, Flávia de Almeida (orientadora). II. Título CDD (22. ed.) MEI

4

5 Eu dedico este trabalho: - A Deus por sempre me acompanhar e me guiar. - À minha família pelo suporte, apoio e compreensão. - Aos meus professores pela formação. - Aos meus amigos pela companhia.

6 Agradecimentos Aos meus orientadores Flávia de Almeida Barros e Ricardo Bastos Cavalcante Prudêncio, pela amizade, pelos conselhos, pela paciência e pela compreensão. Agradeço muito por tudo que fizeram por mim. Ao Centro de Informática da UFPE por ter proporcionado as condições de realização deste trabalho. Ao Grupo de Pesquisa e ao Projeto BTC-Motorola, onde todo este meu trabalho começou e o início de minha carreira acadêmica. Ao professor Paulo Borba pelas orientações na fase embrionária deste trabalho. Ao professor Eduardo Aranha pelo trabalho que utilizei como base e pelas explicações referentes ao seu modelo de estimativa. Aos colegas Leandro Nascimento e Hugo Nascimento que começaram a empreender as bases deste trabalho comigo. Aos amigos Bruna Campos, Cassiano Henrique e Caroline que sempre me deram força e incentivo para ingressar no mestrado. Às amigas Michelle Silva e Laís Neves pela ajuda sempre prestada. Aos meus amigos Washigton Azevedo e Rebecca Linhares, pela companhia durante o mestrado. Aos meu amigos de Montes Claros, por fazerem parte de minha vida. E por último, mas não menos importante, tenho um agradecimento especial a fazer à meus avós, à minha mãe e aos meus irmãos que me proporcionaram condições (de todos os tipos) para que eu pudesse realizar mais esse empreendimento em minha vida. iv

7 Não basta ensinar ao homem uma especialidade, porque se tornará assim uma máquina utilizável, mas não uma personalidade. É necessário que adquira um sentimento, um senso prático daquilo que vale a pena ser empreendido, daquilo que é belo, do que é moralmente correto. A não ser assim, ele se assemelhará, com seus conhecimentos profissionais, mais a um cão ensinado do que a uma criatura harmoniosamente desenvolvida. Deve aprender a compreender as motivações dos homens, suas quimeras e suas angústias, para determinar com exatidão seu lugar preciso em relação a seus próximos e à comunidade. ALBERT EINSTEIN (Físico Alemão)

8 Resumo Seleção automática de casos de teste (CTs) é uma tarefa importante para melhora da eficiência das atividades de Testes de Software. Essa tarefa pode ser tratada como um problema de otimização, cujo objetivo é encontrar um subconjunto de CTs que maximizem um dado critério de teste. No nosso trabalho, o critério de testes é a cobertura de requisitos funcionais formalmente especificados, e, além dele, o custo (esforço de execução) também é levado em consideração no processo de seleção. Mesmo sendo um aspecto importante, o esforço de execução ainda é negligenciado por outros trabalhos na área de seleção automática de CTs. Nesse trabalho, utilizamos o algoritmo conhecido como como Otimização por Enxame de Partículas (Particle Swarm Optimization - PSO), ainda não investigado na resolução desse tipo de problema, para criação de uma ferramenta de seleção automática de CTs. Nela, o esforço de execução é utilizado como um limiar no processo de seleção, onde, dada uma suíte de testes, busca-se selecionar um subconjunto de casos de testes que não ultrapassem esse limiar e que maximizem a cobertura de requisitos funcionais. Para tanto, o esforço de execução foi considerado uma restrição ao problema de otimização e a cobertura de requisitos como a função de fitness. Nessa ferramenta, sete módulos (que implementavam outras técnicas de busca), foram desenvolvidos e seus desempenhos comparados através de experimentos onde foi possível oberservar o bom desempenho do PSO se comparado às outras técnicas. Palavras-chave: seleção automática de casos de teste, otimização por enxame de partículas, testes de software, esforço de execução, otimização com restrições vi

9 Abstract Automatic Test Case selection is an important task to improve the efficiency of Software Testing. This task is commonly treated as an optimization problem, whose aim is to find a subset of test cases (TC) which maximizes the coverage of the software requirements. In this work, we propose the use of Particle Swarm Optimization (PSO) to treat the problem of TC selection. PSO is a promising optimization approach which was not yet investigated for this problem. In our work, PSO was used not only to maximize coverage of requirements, but also to consider the cost (execution effort) of the selected TCs. For this, we developed a constrained PSO algorithm in which execution effort was treated as a constraint in the search, whereas the requirements coverage is used as the fitness function. We highlight that, although execution effort is an important aspect in the test process, it is generally neglected by the previous work that adopted search techniques for TC selection. In experiments performed in different test suites, PSO obtained good results when compared to other search techniques. Keywords: test case selection, particle swarm optimization, software testing, execution effort, constrained optimization vii

10 Sumário Lista de Figuras Lista de Tabelas x xii 1 Introdução Motivação e Relevância Solução Proposta Organização do Documento Testes de Software Abordagens de Teste Abordagem Funcional ou Caixa Preta Abordagem Estrutural ou Caixa Branca Fases de Teste Testes de Unidade Testes de Integração Testes de Sistema Testes de Aceitação Seleção de Casos de Teste Critérios de Seleção de Casos de Teste Test and Requirements Generation Tool - TaRGeT Funcionamento Test Execution Effort Estimation Tool Modelo de estimativa de pontos de execução Transformação em Medida de Tempo Considerações finais Meta-Heurísticas Problemas com Restrições Busca Gulosa Forward Selection Backward Elimination Hill Climbing Otimização por Enxame de Partículas viii

11 3.4.1 A Base do PSO Global Best PSO Local Best PSO Critérios de Parada do PSO Limite de Velocidade Peso de Inércia PSO Binário PSO com Restrições Considerações finais Execution Effort Selector Plugin: Seleção de Casos de Teste por Esforço de Execução Visão Geral Formulação do Problema Módulos Módulo Forward Selection Módulo Backward Elimination Módulo Hill Climbing Módulo Binary Constraint Particle Swarm Optimization - BCPSO Módulo BCPSO-FS Módulo BCPSO-Hill Módulo Randômico Considerações Finais Estudo de Caso e Resultados Experimentais Estudo de Caso Suite Suite Experimentos Resultados dos Experimentos Considerações Finais Conclusões Resumo das Contribuições Trabalhos Futuros Referências Bibliográficas 71 ix

12 Lista de Figuras 2.1 Modelo V Testes de Unidade Caso de Uso Escrito em Linguagem Natural Modelo LTS Estimando o esforço de uma suíte Associando os pontos de execução a um caso de teste Usando os pontos de execução e a produtividade para calcular o esforço Processo de busca do Forward Selection Espaço de Busca do Forward Selection Processo de busca do Backward Elimination Espaço de Busca do Backward Elimination Topologia em Estrela Topologia em Anel Fluxo do Processo do Execution Effort Selector Plugin Representação de uma solução Relação entre esforço e requisitos da suíte Relação entre esforço e requisitos da suíte Evolução do fitness Suíte 1-75% Esforço Total Boxplot fitness Suíte 1-75% Esforço Total Intervalos de Confiança Suíte 1-75% Esforço Total Evolução do fitness Suíte 1-50% Esforço Total Boxplot fitness Suíte 1-50% Esforço Total Intervalos de Confiança Suíte 1-50% Esforço Total Evolução do fitness Suíte 1-25% Esforço Total Boxplot fitness Suíte 1-25% Esforço Total Intervalos de Confiança Suíte 1-25% Esforço Total Evolução do fitness Suíte 1-05% Esforço Total Boxplot fitness Suíte 1-05% Esforço Total Intervalos de Confiança Suíte 1-05% Esforço Total Evolução do fitness Suíte 2-75% Esforço Total Boxplot fitness Suíte 2-75% Esforço Total Intervalos de Confiança Suíte 2-75% Esforço Total x

13 5.18 Evolução do fitness Suíte 2-50% Esforço Total Boxplot fitness Suíte 2-50% Esforço Total Intervalos de Confiança Suíte 2-50% Esforço Total Evolução do fitness Suíte 2-25% Esforço Total Boxplot fitness Suíte 2-25% Esforço Total Intervalos de Confiança Suíte 2-25% Esforço Total Evolução do fitness Suíte 2-05% Esforço Total Boxplot fitness Suíte 2-05% Esforço Total Intervalos de Confiança Suíte 2-05% Esforço Total xi

14 Lista de Tabelas 5.1 Resultados Suite 1-75% esforço Resultados Suite 1-50% esforço Resultados Suite 1-25% esforço Resultados Suite 1-05% esforço Resultados Suite 2-75% esforço Resultados Suite 2-50% esforço Resultados Suite 2-25% esforço Resultados Suite 2-05% esforço xii

15 1 Introdução Comece fazendo o que é necessário, depois o que é possível, e de repente, você estará fazendo impossível. SÃO FRANCCISCO DE ASSIS Em mercados competitivos, companhias que desenvolvem produtos de má qualidade podem, rapidamente, perder seus clientes. De forma a evitar isso, as companhias devem garantir que a qualidade dos seus produtos estejam de acordo com as expectativas de seus clientes. O teste de software é uma atividade normalmente realizada visando aumentar a qualidade de um produto de software, consistindo em tentar detectar falhas no software através de sua execução (Jorgensen, 2008). Testes são de fundamental importância dentro do ciclo de vida de qualquer produto de software, desde os pequenos até os grandes. Normalmente, a necessidade por testes aumenta junto com o tamanho do produto e o nível de confiabilidade requerida, embora o tempo disponível para os testes, geralmente, seja limitado. De acordo com Beizer (1984), o processo de testes é caro e demorado, chegando a consumir cerca de 50% dos custos totais envolvidos no desenvolvimento do software. Em vista disso, métodos e técnicas capazes de agilizar esse processo são necessários, de formar a reduzir os custos, o esforço e o tempo de teste, possibilitando um aumento na qualidade do produto. A criação de casos de testes que sejam efetivos é um dos grandes desafios das estratégias de testes de software atualmente utilizadas na indústria. O que se deseja é que os recursos disponíveis sejam utilizados de forma otimizada, comprometendo o mínimo 1

16 1.1. MOTIVAÇÃO E RELEVÂNCIA possível o orçamento destinado à produção daquele produto de software (Cartaxo et al., 2008b). O restante deste capítulo apresenta a justificativa deste trabalho, seguida pela solução proposta para o problema e as contribuições da pesquisa aqui relatada. Por fim, teremos uma breve apresentação da organização deste documento. 1.1 Motivação e Relevância O processo de criação de testes de software geralmente depende de especialistas humanos, que são responsáveis por criar uma suíte de testes de forma a melhor exercitar o código sob teste de forma efetiva, contudo dentro dos limites de tempo disponíveis na empresa. Esse processo é considerado custoso, tanto por necessitar de um especialista humano, quanto pelo fato de ser manual - além de ser passível de erro, pelas mesmas razões anteriores. Sendo assim, uma das estratégias para aperfeiçoar o processo de criação de casos de teste é utilizar ferramentas que gerem suítes de teste a partir de uma especificação do software. Alguns exemplos de ferramentas são a TaRGeT (Nogueira et al., 2007), o Autolink (Feijs et al., 2002) e LTSBT (Cartaxo et al., 2008a). Ainda que estas ferramentas colaborem para processo de geração de caso de testes, elas introduzem um problema, pois normalmente o número de casos de teste das suítes geradas é muito grande, dificultando, assim, o seu gerenciamento. Contudo, não são apenas as suítes geradas automaticamente que apresentam um grande número de casos de teste. O processo manual de criação, ou geração, também pode produzir suítes grandes, a fim de se testar o software de forma mais efetiva. Assim sendo, independentemente da abordagem utilizada na criação das suítes de teste (manual ou automática), as suítes geradas são, em geral, muito longas, a fim de cobrir todas as funcionalidades do software em teste. Por conseguinte, teste de software é sempre um processo caro (custoso), uma vez que a execução de uma suíte de testes completa gasta muito tempo. A geração de testes que podem ser rodados automaticamente pode reduzir o tempo de execução de uma suíte, mas em geral as duas formar de execução (manual e automática) são combinadas, pois nem sempre é possível criar scripts de teste automáticos por restrições tecnológicas ou porque se necessita de um feedback do usuário. Mesmo num cenário onde é possível execução automática de todos os testes de uma suíte, o tempo de execução pode ser longo, portanto uma seleção também poderia ser aplicada nesse caso. Os testes funcionais são um dos tipos de teste de software que consomem mais 2

17 1.1. MOTIVAÇÃO E RELEVÂNCIA recursos. Estes, geralmente, buscam prover uma cobertura total das funcionalidades do software, requerendo assim suítes de teste longas. Entretanto, devido aos altos custos de execução (usualmente manual) associados, sempre há a necessidade de selecionar um conjunto menor de testes a serem realizados. Diante disso, essa área foi identificada como um campo de pesquisa importante, que busca encontrar um conjunto mínimo de casos de teste que seja efetivo - sob algum aspecto - para testar o software. Um aspecto relevante de efetividade dos testes é a cobertura dos requisitos especificados para o software sendo testado. Uma das peculiaridades observadas pelos pesquisadores na área foi a de que uma suíte pode conter mais casos de teste do que o necessário para cobrir todos os requisitos especificados. Observou-se que, geralmente, há uma redundância na cobertura dos requisitos, redundância essa difícil de detectar de forma manual quando a suíte é muito grande. Sendo assim, é desejável que se desenvolvam técnicas para detectar e eliminar essas redundâncias de cobertura de requisitos, de forma a obter-se um subconjunto de casos de teste que possua a mesma cobertura da suíte original. A seleção de um subconjunto apropriado de casos de teste de uma suíte não é uma tarefa trivial. Tradicionalmente, essa seleção pode ser baseada numa diversidade grande de critérios (muitas vezes heurísticos). Alguns critérios utilizados incluem partição em classes de equivalência, cobertura de código (blocos, decisões, caminhos) (Feijs et al., 2002), cobertura de requisitos especificados (funcionais ou não-funcionais) (Harold et al., 1993; Souza et al., 2010), similaridade de caminhos (Cartaxo et al., 2008b), relações de definição e uso (def-use) (Harold et al., 1993), dentre outros. Nesse contexto, o problema de seleção de casos de teste pode ser definido em termos de um processo de otimização, pelo qual se busca encontrar um subconjunto de casos de teste que atenda a um determinado critério, dentro de um grande número de possibilidades. Essa é uma atividade de natureza complexa, sendo praticamente impossível determinar uma solução ótima (ou quase ótima) quando essa tarefa é realizada manualmente. Assim, heurísticas automáticas podem ser uma boa opção para realizar esta tarefa. Assim, este problema pode ser formulado como um problema de otimização no qual se tenta realizar a seleção de casos de teste otimizando-se algum critério. Contudo, muitas vezes, o atendimento de apenas um critério de seleção não é suficiente. No mundo real, deseja-se que vários critérios de seleção sejam otimizados simultaneamente, de forma a fornecer uma solução aceitável para cada um desses critérios, caracterizando, assim, este problema como um problema de otimização multi-critério (Yoo and Harman, 2007). De fato, pesquisas que utilizam métodos de busca e otimização em Engenharia de Software 3

18 1.2. SOLUÇÃO PROPOSTA têm se mostrado muito promissoras (Harman, 2007). 1.2 Solução Proposta Este trabalho de mestrado investigou o uso de meta-heurísticas para a seleção de casos de teste, com foco específico em otimização com restrições. O critério a ser otimizado foi a cobertura de requisitos dos testes selecionados, e a restrição aplicada foi o esforço de execução estimado dos casos de teste da suíte original. Após um detalhado estudo do estado da arte em meta-heurísticas, optou-se por utilizar a técnica estocástica de Otimização por Enxame de Partículas (do inglês, Particle Swarm Optimization - PSO) (Kennedy et al., 1995), que tem obtido resultados promissores em problemas de otimização com restrição. O algoritmo PSO tem sido citado na literatura relacionada como um algoritmo promissor, freqüentemente, apresentando melhor desempenho que algoritmos tradicionais, como os algoritmos genéticos (Yoo and Harman, 2007). O PSO é um algoritmo populacional que modela o comportamento de um bando de pássaros. Os indivíduos, referidos como partículas, estão agrupados em um enxame. Cada partícula representa uma solução candidata ao problema de otimização, e essas partículas "voam"através de um espaço de busca multidimensional, ajustando sua posição de acordo com sua própria experiência e a experiência de sua vizinhança. O desempenho de cada partícula é mensurado de acordo com sua função objetivo (função esta relacionada ao problema que se deseja resolver) (Engelbrecht, 2007). Como prova de conceito, foi desenvolvido um plugin que implementa um algoritmo baseado no PSO para seleção automática de casos de teste levando em consideração a cobertura de requisito do teste e uma medida de esforço de execução estimada pela ferramenta Test Execution Effort Estimation Tool (Aranha et al., 2008). Esse plugin foi integrado à ferramenta TaRGeT 1 (Nogueira et al., 2007), para geração automática de casos de teste a partir de especificações de casos de uso do sistema sob teste. Durante o trabalho, nós investigamos o uso do PSO aplicado ao problema de seleção de casos de teste e podemos citar algumas contribuições. Primeiro, na medida de nosso conhecimento, o PSO não foi ainda investigado no contexto de seleção de CTs. Além disso, nós consideramos a medida de esforço de execução dos CTs formulando um problema de otimização com restrições. E, também, implementamos sete técnicas metaheurísticas para lidar com esta tarefa. Por fim, criamos estudos de caso e relizamos 1 TaRGeT - Test and Requirements Generation Tool 4

19 1.3. ORGANIZAÇÃO DO DOCUMENTO experimentos comparativos para determinar qual técnicas apresenta melhores resultados. Em adição às contribuições supracitadas, gostaríamos de mencionar que foi produzido um artigo científico, apresentando o trabalho desenvolvido no âmbito da pesquisa aqui relatada (Souza et al., 2010). Tal artigo foi publicado nos anais da conferência SEKE Organização do Documento Este documento conta com mais cinco capítulos, além desta introdução, sendo eles: O capítulo 2 apresenta os conceitos relacionados à testes de software, enfatizando os aspectos referente ao problema de seleção de casos de teste; O capítulo 3 mostra as técnicas meta-heurísticas utilizadas no desenvolvimento deste trabalho; O detalhes de implementação dos módulos presentes no Execution Effort Selector Plugin são apresentados no capítulo 4; Os estudos de casos e resultados experimentais são apresentados no capítulo 5; O capítulo 6 apresenta as conclusões deste trabalho e possíveis trabalhos futuros. 2 SEKE - International Conference on Software Engineering and Knowledge Engineering 5

20 2 Testes de Software O que sabemos é uma gota, o que ignoramos é um oceano. ISAAC NEWTON (Físico e matemático inglês) Como já dito, a atividade de teste é essencial na engenharia de software. Em termos simples, seu objetivo é observar a execução de um produto de software, de forma a validar se ele se comporta como especificado, bem como identificar falhas potenciais. As atividades de teste são largamente utilizadas como forma de garantir a qualidade dos produtos, pois ao analisar execução do software, pode-se observar seu comportamento de forma realista (Bertolino, 2007). Assim, durante o desenvolvimento de um software, uma suíte de testes é desenvolvida, de forma a possibilitar a realização de testes do software, assim como verificar se ele funciona de forma correta (como especificado pelo usuário). Esse processo de geração de suítes de testes pode ser feito de forma manual (por um especialista) ou automática (utilizando-se uma ferramenta de geração de CTs). Em ambos os casos, esse processo geralmente se baseia numa dada especificação do software a ser testado (Burguillo-Rial et al., 2002). Na literatura, encontramos ferramentas de geração automática de casos de teste que utilizam modelos de especificação como, por exemplo, casos de uso escritos em linguagem natural (Nogueira et al., 2007), ou Labeled Trasition System (LTS) anotados (Cartaxo et al., 2008a). Durante o processo de teste de software, é possível observar-se que o número de CTs sempre aumenta com o decorrer do tempo, pois funcionalidades são modificadas ou adicionadas ao produto, levando à adição de novos CTs às suítes existentes. Isso faz com que as suítes de testes sejam, normalmente, grandes, dificultando assim o processo de 6

21 2.1. ABORDAGENS DE TESTE gerenciamento das mesmas. A fim de se garantir a qualidade do produto de software, o ideal seria executar todos os casos de teste presentes na suíte gerada. Contudo, devido ao extenso tamanho dessas suítes, geralmente não há recursos suficientes para isso. Portanto, é necessário selecionar um subconjunto de casos de teste que se adéqüe aos recursos disponíveis para execução. Esse processo de seleção geralmente acontece durante a fase de planejamento dos testes, e busca selecionar os CTs que tenham maiores chances de encontrar falhas no software. Nas próximas seções são abordadas as abordagens (2.1) e as fases (2.2) de teste mais utilizadas. A seguir, o conceito de seleção de casos de teste (2.3) é apresentado. Posteriormente, a ferramenta de geração de casos de teste, TaRGet (2.4), e a ferramenta de estimativa de esforço de execução, Test Execution Effort Estimation Tool (2.5), são explicadas. Por fim, algumas considerações finais encerram este capítulo (2.6). 2.1 Abordagens de Teste As abordagens de teste definem quais aspectos e requisitos do software serão avaliados, e a profundidade da análise a ser realizada. Nesta seção, as duas abordagens de teste mais utilizadas na indústria de software serão apresentadas: teste funcional, ou caixa preta (2.1.1); e teste estrutural ou caixa branca (2.1.2). Elas podem ser aplicadas a qualquer tipo de software, separadamente ou em conjunto, sendo essa uma escolha feita durante o planejamento dos testes. Este trabalho de mestrado teve como foco os testes funcionais Abordagem Funcional ou Caixa Preta Uma especificação funcional é uma descrição do comportamento esperado do software. Seja qual for o formato, formal ou informal, ela é a fonte de informação mais importante para a elaboração dos testes. Os casos de teste derivados a partir dessas especificações são chamados de testes funcionais (Pezzè and Young, 2008). De acordo com Myers (2004), teste funcional é o processo de tentar descobrir discrepâncias entre o software e sua especificação inicial, através de sua execução. Essa especificação deve ser uma descrição precisa do comportamento do software, do ponto de vista do usuário final. Essa abordagem pode ser aplicada em qualquer fase de teste (seção 2.2), sendo mais comum nas duas últimas fases. Além disso, como é baseada em especificações, ela se torna independente da linguagem de programação utilizada. Geralmente, são utilizadas algumas técnicas para derivação de casos de teste a partir de uma especificação do software. As técnicas mais conhecidas são (Myers, 2004): 7

22 2.1. ABORDAGENS DE TESTE Particionamento em Classes de Equivalência, Análise de Valores de Fronteira e Grafo Causa-Efeito. Uma vez que utilizar todas as possíveis entradas para testar um programa é impossível (Myers, 2004), utiliza-se a técnica de particionamento em classes de equivalência. O conjunto de entradas é dividido em classes (domínios), onde considera-se que uma entrada que pertence a uma determinada classe seja equivalente (no que se refere à capacidade de encontrar uma falha) às outras da mesma classe. Essas classes são utilizadas para se derivar os casos de teste. O método de análise de valores de fronteira leva em consideração que, é maior a possibilidade de se detectar uma falha utilizando-se valores de fronteira dos domínios (classes) das entradas. Assim, os valores escolhidos são aqueles que se encontram exatamente na fronteira, e também imediatamente abaixo e acima da fronteira. O grafo causa-efeito cria uma estrutura visual a partir do qual se pode analisar qual o efeito da combinação das mais diversas causas (entradas). A partir disso, os casos de teste são derivados. Apesar das vantagens de se utilizar teste funcional, este tipo de teste não garante que determinadas partes essenciais do software serão testadas. Além disso, essa abordagem é totalmente dependente das especificações do produto. Assim, se as especificações não foram bem produzidas, a tarefa de se derivar testes funcionais não será bem sucedida. A seção apresenta a abordagem de teste estrutural, que pode ser utilizada em complemento à abordagem funcional Abordagem Estrutural ou Caixa Branca A abordagem de teste estrutural permite examinar a estrutura interna do software. Nela, os testes são derivados a partir de uma análise na estrutura lógica do software (Myers, 2004). O objetivo aqui é que cada linha do programa seja executada pelo menos uma vez. Contudo, essa não é uma tarefa fácil de ser sempre atingida. Assim, durante o planejamento de testes, é definido um percentual de cobertura de código a ser atingido. Para Pezzè and Young (2008), a estrutura do software em si é uma valiosa fonte de informação para selecionar casos de teste e determinar se um conjunto de casos de teste é suficientemente rigoroso, i.e., se ele apresenta uma boa cobertura de código - quanto mais o código é coberto por casos de teste, mais se espera encontrar potenciais falhas. Essa abordagem é fortemente recomendada de ser realizada nas fases de teste de unidade e integração (explicadas na seção a seguir), sob responsabilidade dos desenvolvedores. 8

23 2.2. FASES DE TESTE Para Pressman (2004), através dos testes estruturais, pode-se por exemplo, garantir que todos os caminhos independentes do código sejam exercitados pelo menos uma vez, exercitar todas as decisões lógicas com valores "verdadeiro"e "falso", executar todos os ciclos nos seus limites e dentro de seus intervalos, e exercitar as estruturas de dados internas para garantir sua validade. Existe ainda a abordagem conhecida como "teste híbrido", ou teste caixa cinza, que consiste na derivação de casos de teste a partir da combinação de especificações funcionais do software juntamente com a estrutura do código. 2.2 Fases de Teste As atividades de teste de software podem ser realizadas durante todo o processo de desenvolvimento do software, e não apenas após suas construção. Ou seja, os testes podem ser planejados, criados e executados em momentos diversos do ciclo de desenvolvimento. Para tanto, essa atividade é divida em fases, de modo que cada uma se preocupa com um aspecto diferente do software, como pode ser visto figura 2.1. Figura 2.1 Modelo V (Spillner, 2002) A seguir, são apresentadas, de forma sucinta, as principais fases de testes de software. 9

24 2.2. FASES DE TESTE Testes de Unidade Testes de Unidade, ou testes unitários, buscam testar as unidades de código fonte, de forma a determinar se elas estão adequadas, através da comparação do comportamento atual com o comportamento definido durante o projeto detalhado do software (IEEE, 1987). Esses testes são criados, normalmente, pelos programadores, e idealmente cada caso de teste é independente dos outros (2.2). Figura 2.2 Testes de Unidade (Pressman, 2004) Com os testes de unidade, podem-se encontrar falhas no software em estágios iniciais do ciclo de desenvolvimento do software. O procedimento padrão é criar casos de teste para todas as funções e métodos do software. Eles são importantes também no controle de mudanças, pois identificam, em menor granularidade, que partes do código uma mudança pode ter afetado. Após as unidades terem sido testadas, os testes de integração (2.2.2) são facilitados, pois assume-se que as unidades estejam certas e a falha, caso ocorra, foi decorrente da integração entre as unidades (anteriormente testadas) Testes de Integração Testes de Integração verificam se a integração (comunicação) entre as unidades já testadas se deu de forma correta. Podem-se usar tanto abordagens funcionais (2.1.1) quanto estruturais (2.1.2) para se executar testes de integração. 10

25 2.2. FASES DE TESTE As estratégias de criação de testes de integração mais comuns são: Big Bang, na qual todas as unidades são testadas de uma vez (em conjunto); e incremental, na qual o software é construído e testado em pequenos incrementos de unidades, possibilitando que os erros sejam mais facilmente isolados e corrigidos (Pressman, 2004). Assim como os testes de unidade, uma grande vantagem deste tipo de teste é identificar, o quanto antes, falhas do software, de forma que as próximas fases possam focar no funcionamento do sistema como um todo Testes de Sistema Testes de sistema são conduzidos num software completo (já integrado), de forma a avaliar a sua conformidade com a especificação feita durante a fase de análise do sistema. A abordagem de teste funcional (2.1.1) é geralmente utilizada durante essa fase. Esses testes são realizados por um time de testadores, que simulam as ações do usuário final ao utilizar o software considerando o seu ambiente. De acordo com Pressman (2004), a principal finalidade dos testes de sistema é exercitar o software por completo, sendo que cada teste tem um objetivo específico, mas sua junção representa as funcionalidades do sistema como um todo. Vários tipos de testes são realizados durante os testes de sistema, sendo que os principais são (Pressman, 2004): 1. Teste de Recuperação - força uma falha no software, de forma a verificar se ele recupera-se apropriadamente; 2. Teste de Segurança - verifica se os mecanismos de proteção do sistema, de fato, o protegem de penetração indevida; 3. Teste de Estresse - executa o sistema de uma maneira a demandar seus recursos de forma excessiva; 4. Teste de Performance - objetiva avaliar o sistema de acordo com algum critério de performance Testes de Aceitação São testes conduzidos por usuários finais do sistema, tendo por objetivo demonstrar a conformidade do software com os requisitos que foram definidos pelo usuário. Essa fase é muito importante, pois permite ao usuário aceitar ou não o software desenvolvido. 11

26 2.3. SELEÇÃO DE CASOS DE TESTE Em geral, são realizados testes alfa e beta durante esta fase, sendo o primeiro normalmente realizado nas instalações do desenvolvedor, e o segundo nas instalações do usuário final (Silva, 2008). 2.3 Seleção de Casos de Teste Um dos aspectos que tornam o processo de testes mais caro é o fato da existência de redundância entre os testes (isto é, CTs diferentes cobrindo os mesmos requisitos de teste). Isso é mais comum em processos de geração automática de CTs. Como conseqüência, as suítes de teste ficam extensas e, por conseguinte, a quantidade de recursos necessários para sua execução aumenta. Identificamos três vertentes de pesquisas que se concentram no controle do tamanho de suítes de testes. São elas (Cartaxo et al., 2009): Redução de Casos de Teste - os casos de teste são selecionados de forma apenas a eliminar os CTs redundantes, mantendo dessa forma a mesma cobertura da suíte original (Zhong et al., 2006; Harold et al., 1993; ying Ma et al., 2005; Chen and Lau, 1998); Seleção de Casos de Teste - um subconjunto de CTs é selecionado de forma a atingir um determinado objetivo, podendo assim não ter a mesma cobertura da suíte original (Rothermel and Harrold, 1997; Yoo and Harman, 2007; Feijs et al., 2002) - ver seção 2.3.1; Priorização de Casos de Teste - os CTs são ordenados objetivando maximizar algum critério de priorização (Walcott et al., 2006; Malishevsky et al., 2006; Elbaum et al., 2002; Wong et al., 1997). A seleção de CTs que, segundo Lin and Huang (2009), é um problema NP-Completo, sendo assim uma tarefa de difícil resolução de maneira determinística. Tendo isso em vista, abordagens de busca heurística são mais adequadas a esses tipos de problema. Alguns exemplos de algoritmos usados nesse contexto são: o algoritmo HGS (Harold et al., 1993), o algoritmo GRE (Chen and Lau, 1998), algoritmos de Busca Gulosa (Greedy Search) (Chvatal, 1979) e Algoritmos Genéticos (Yoo and Harman, 2007). 12

27 2.3. SELEÇÃO DE CASOS DE TESTE Critérios de Seleção de Casos de Teste De acordo com Cartaxo et al. (2009), o objetivo da seleção de casos de teste é selecionar um subconjunto de CTs de uma suíte de testes de forma a atender um dado critério de teste (por exemplo, um tamanho máximo de uma suíte, cobertura mínima desejada, etc), sendo normalmente tratada como um problema de otimização (Lin and Huang, 2009). Neste contexto, é possível o uso de uma técnica de busca objetivando encontrar o subconjunto que melhor atenda o critério escolhido. Entretanto, o subconjunto selecionado pode não ter a mesma cobertura da suíte de teste original. Como exemplo, podemos citar o critério de cobertura de requisitos. Ele é dependente do tipo de teste que será executado. Para testes estruturais, os requisitos são "pedaços"de código do programa (por exemplo blocos e decisões), que devem ser exercitados pelos casos de teste (Feijs et al., 2002; Harold et al., 1993). Já para os testes funcionais, os requisitos são especificações formais do software (Cartaxo et al., 2009). Utilizando-se esse critério é possível estabelecer um valor mínimo de cobertura de forma que os testes serão selecionados visando atender esse valor estabelecido. Embora a maioria dos trabalhos tem como foco a cobertura de requisitos do subconjunto de CTs selecionado, o custo de execução destes também é um fator importante. De acordo com Yoo and Harman (2007), o objetivo de selecionar CTs é o de atingir uma melhor eficiência em termos de custo. Não obstante, poucos trabalhos foram propostos no contexto de seleção de casos de teste levando em consideração seu custo de execução (Yoo and Harman, 2007; Malishevsky et al., 2006). Ainda, esses trabalhos tinham como foco somente os testes estruturais. De fato, é difícil considerar os custos de execução de testes funcionais, desde que é necessário estimar o custo de execução manual dos CTs antes de sua execução (Aranha and Borba, 2007). A medida do esforço de execução pode ser obtida de diversas maneiras como: medir manualmente o esforço (em tempo) necessário para executar casa caso de teste, através de dados históricos obtidos de execuções anteriores ou por alguma técnica que seja capaz de predizer esse valor. Este trabalho usa o modelo de predição de estimativa de esforço desenvolvido por Aranha and Borba (2007, 2008). A próxima seção apresenta a ferramenta TaRGeT, para geração automática de casos de teste a partir de casos de uso. A seguir, na seção 2.5, o modelo de estimativa de esforço de execução é apresentado. 13

28 2.4. TEST AND REQUIREMENTS GENERATION TOOL - TARGET 2.4 Test and Requirements Generation Tool - TaRGeT A Test and Requirements Generation Tool (TaRGeT) (Nogueira et al., 2007) é uma ferramenta de geração automática de casos de teste a partir de cenários de casos de uso escritos em linguagem natural. Ela utiliza uma abordagem sistemática para lidar com requisitos e artefatos de teste de forma integrada. A TaRGet foi desenvolvida pelo grupo de pesquisa do Brazil Test Center (Torres et al., 2007), com o objetivo de melhorar a qualidade do software e reduzir os custos do processo de testes Funcionamento Os possíveis cenários de casos de uso do software, são especificados utilizando linguagem natural em um template que suporta processamento automático. Na figura 2.3, o fluxo principal (Main Flow) é o ato de inserir um contato na agenda de um celular. Um fluxo é descrito através de passos numerados (Step Id), que incluem uma ação do usuário (User Action) e o respectivo estado do sistema (System State), para que a ação possa ser executada. Por fim, também é incluída a respota do sistema (System Response), que é o que se espera que aconteça com o sistema ao se executar a ação do usuário. A TaRGeT permite criar uma matrix de rastreabilidade de requisitos, através da inserção do identificador dos requisitos na campo de System Response, como, também, pode ser visto na 2.3. Através dessa matriz, é possível identificar que requisitos funcionais um determinado teste irá cobrir. A estratégia da TaRGeT para geração de casos de teste consiste em obter um modelo comportamental LTS (Labeled Transistions Systems) a partir dos casos de uso. Então, os casos de teste são gerados utilizando um algoritmo de extração. O algoritmo LTS utiliza as informações do Step Id, como pode ser visto na figura 2.4. Cada caminho do modelo LTS gera um caso de teste. A versão atual da TaRGeT possui alguns filtros de seleção que são utilizados no processo de teste, sendo eles: Filtro de seleção por similaridade: onde os testes são selecionados buscandose elminar aqueles mais similares (reduntantes) entre si no que diz respeito aos caminhos percorridos do caso de uso do qual o caso de teste foi derivado; Filtro de seleção por propósito de teste: onde é possível selecionar os testes de acordo com seu propósito. 14

29 2.4. TEST AND REQUIREMENTS GENERATION TOOL - TARGET Figura 2.3 Caso de Uso Escrito em Linguagem Natural (adaptado de Nogueira et al. (2007)) Figura 2.4 Modelo LTS (adaptado de Nogueira et al. (2007)) 15

30 2.5. TEST EXECUTION EFFORT ESTIMATION TOOL Além desses filtros há oportunidade de criação de outros que ajudariam a reduzir os custos do processo de testes. Por exemplo, a criação de um filtro que permitisse selecionar testes de forma a atender um determinado esforço de execução permitiria aos gerentes de testes um melhor gerenciamento de seus recursos. A ferramenta Test Execution Effort Estimation Tool, apresentada na próxima seção (2.5), permite estimar o esforço de execução de uma dada suíte e poderia ser utilizada na criação desse filtro. 2.5 Test Execution Effort Estimation Tool Esta seção apresenta o modelo de estimativa de esforço de execução criada por Aranha and Borba (2007) implementado na ferramenta Test Execution Effort Estimation Tool (Aranha et al., 2008). Resumidamente, o processo executado pelo modelo de estimativa de esforço observado na figura 2.5 é: 1. Analisar individualmente cada caso de teste da suíte de entrada; 2. Associar a cada caso de teste um número de pontos de execução, que caracteriza o tamanho e a complexidade do teste; 3. Somar todos os pontos de execução dos casos de teste analisados no passo anterior; 4. Estimar o esforço necessário, em uma medida de tempo (horas), para executar a suíte por inteiro utilizando como base a informação do total dos pontos de execução Modelo de estimativa de pontos de execução As informações requeridas pelo modelo para medir um caso de teste são extraídas de sua especificação. Especificações de teste escritas em uma linguagem natural controlada (LNC) são usadas como entrada para o modelo. A gramática e o léxico da LNC são definidos de acordo com o domínio da aplicação. No domínio de aplicações para telefones móveis, um passo de teste presente em sua especificação poderia ser "Vá para a central de mensagens". A lista dos verbos e possíveis argumentos são construídos pela análise de cada passo presente na especificação. Para lidar com o problema de ocorrência de novos verbos e termos, a gramática e o léxico da LNC são armazenados em um banco de dados que pode ser atualizado pelo usuário sempre que necessário. 16

31 2.5. TEST EXECUTION EFFORT ESTIMATION TOOL Figura 2.5 Estimando o esforço de uma suíte (Aranha and Borba, 2007) Cada passo do teste é analisado de acordo com uma lista de características prédefinidas que representam os requisitos funcionais e não-funcionais exercitados quando o passo é executado. Um exemplo de característica pode ser o número de telas navegadas, o número de teclas pressionadas, ou se o passo diz respeito a uma manipulação de arquivos. Cada uma dessas características tem um impacto no tamanho e na complexidade de execução de um teste. Um atributo discreto é usado para representar o nível (baixo, médio e alto) de impacto de uma característica em um teste. Após a análise das características, os pontos de execução são associados a cada passo de acordo com o seu nível, objetivando transformar essa informação qualitativa em um valor quantitativo. Após isso, a soma de todos os pontos de execução associados para cada característica é feita, de forma a permitir o cálculo do número total de pontos de execução de um passo de teste. Finalmente, a soma dos pontos de execução de cada passo dá uma medida do tamanho e da complexidade do teste. Com a soma dos pontos de execução de cada teste, obtém-se o número de pontos de execução da suíte. Esse processo pode ser visto na figura

32 2.5. TEST EXECUTION EFFORT ESTIMATION TOOL Figura 2.6 Associando os pontos de execução a um caso de teste (Aranha and Borba, 2007) Transformação em Medida de Tempo A medida dos pontos de execução dá uma referência do tamanho e da complexidade de um caso de teste ou suíte de teste. Usando dados históricos de produtividade de execução dos testes, e essas informações de medida de pontos de execução, é possível estimar o esforço necessário para executar a suíte. O número de segundos necessário para executar cada ponto de execução é utilizado para calcular o valor de produtividade de execução. Esse cálculo pode ser feito através da medição do tamanho e da complexidade de vários casos de teste (seu tamanho em pontos de execução), coletando também o tempo de execução dos testes, obtidos através de dados históricos ou pelo acompanhamento da execução. A figura 2.7 ilustra que a produtividade de execução é obtida através da divisão do esforço total (tempo medido em segundos) pelo número de pontos de execução. Essa informação é então usada para estimar o esforço de execução de novas suítes de teste pela multiplicação de seu número de pontos de execução pelo valor de produtividade de execução. Essa abordagem assume que as condições do ambiente e a produtividade de execução já se encontram estáveis. Algumas causas podem modificar a produtividade de execução, 18

33 2.6. CONSIDERAÇÕES FINAIS Figura 2.7 Usando os pontos de execução e a produtividade para calcular o esforço (Aranha and Borba, 2007) como mudanças no time de testes, mudanças no ambiente ou testes de novos produtos. Desde que essas causas podem ocasionar mudanças significativas na produtividade, ela deve ser recalculada de forma a refletir a situação atual. Esse modelo de estimativa de esforço de casos de teste foi utilizado no presente trabalho de mestrado como um fator de restrição na seleção dos casos de teste (ver Capítulo 4). 2.6 Considerações finais Neste capítulo, foram apresentados alguns conceitos e aspectos relevantes sobre testes de software, com foco na seleção de casos de teste. Por ser um problema de difícil resolução de forma determinística, a seleção de CTs pode utilizar heurísticas de busca em sua resolução, e alguns exemplos dessas técnicas foram citados. Além disso, duas ferramentas essenciais para este trabalho de mestrado foram apresentadas, a TaRGeT e a Test Execution Effort Estimation Tool. Como será visto no Capítulo 4, este trabalho explorou a oportunidade de se utilizar o esforço de execução no processo de seleção de testes funcionais. O esforço (custo) de execução, estimado pela ferramenta Test Execution Effort Estimation Tool, foi utilizado como um limiar no processo de seleção de casos de testes funcionais, procurando-se também otimizar o cobertura dos 19

34 2.6. CONSIDERAÇÕES FINAIS requisistos funcionais (especificados no modelo de casos de uso da TaRGeT). Esse limiar atua como um fator de restrição durante o processo, pois ele impõe a restrição de que o subconjunto de CTs selecionados, não ultrapassem o dado valor de limiar (definido pelo usuário). O próximo capítulo abordará procedimentos de busca meta-heurística, que podem ser utilizados no problema de seleção de CTs, dando um maior enfoque à técnica conhecida como Otimização por Enxame de Partículas (abordagem principal desenvolvida neste trabalho). 20

35 3 Meta-Heurísticas My mother drew a distinction between achievement and success. She said that achievement is the knowledge that you have studied and worked hard and done the best that is in you. Success is being praised by others, and that is nice, too, but not as important or satisfying. Always aim for achievement and forget about success. HELEN HAYES (Atriz Americana) O termo "heurística"vem do grego heuriskein, que significa "encontrar ou descobrir". Os métodos heurísticos utilizam algum tipo de informação e o adicionam na função a ser otimizada. Estes métodos buscam a otimização operando de uma maneira aleatória orientada. Dentro do conjunto de heurísticas, temos as chamadas meta-heurísticas, que se que são um grupo de algoritmos heurísticos que podem ser aplicados de forma genérica aos mais diversos tipos de problemas. Alguns problemas enfrentados durante o ciclo de vida de um produto de software, nem sempre podem ser resolvidos (ou são resolvidos de maneira inadequada e/ou ineficiente) pelo uso de técnicas tradicionais da Engenharia de Software. Por isso, técnicas de busca meta-heurísticas têm sido aplicadas há um grande número de atividades da engenharia de software, durante todo o ciclo de vida, como a engenharia de requisitos, projeto, planejamento, testes, manutenção, garantia da qualidade, etc (Harman, 2007). Focando a área de testes de software, encontramos exemplos dessas técnicas na resolução dos mais diversos problemas, desde geração de dados para testes (McMinn, 2004), até seleção de casos de teste (Yoo and Harman, 2007). O problema de seleção de casos de teste pode ser modelado como um processo de 21

36 3.1. PROBLEMAS COM RESTRIÇÕES otimização, onde se busca encontrar um subconjunto de casos de teste que atenda a uma determinado critério. Devido ao espaço de busca ser, em geral, muito grande, utiliza-se técnicas de busca meta-heurística de forma a tentar encontar uma solução ótima (ou quase ótima) para o problema. No contexto desse trabalho, essa seleção leva em consideração um limiar de esforço de execução, onde o subconjunto encontrado deve estar abaixo de um dado limite de esforço de execução, informado pelo usuário, ao mesmo tempo que procura otimizar a cobertura de requisitos funcionais. Diante disso, torna-se um problema de otimização com restrição. Nas próximas seções serão mostrados conceitos e técnicas utilizadas neste trabalho. O conceito de problemas de otimização com restrições é dado na seção 3.1. Após isso, técnicas (algoritmos) de busca meta-heurística como Busca Gulosa 3.2, Hill Climbing 3.3 e Otimização por Enxame de Partículas 3.4 são explicados, dando maior ênfase neste último. 3.1 Problemas com Restrições Muitas problemas do mundo real estão sujeitos a restrições. Essas restrigem o espaço de busca de soluções, tornando algumas regiões inviáveis. Os algoritmos de busca têm que ser capazes de encontrar soluções fora dessa região. Isto é, soluções que respeitem todas as restrições aplicadas ao problema. De acordo com Engelbrecht (2007), uma definição matemática do problema de otimização 1 com restrições pode ser dada como: Minimizar f (x), x = (x 1,...,x nx ) Sujeito à g m (x) 0, h m (x) = 0, m = 1,...,n g m = n g + 1,...,n g + n h x j dom ( x j ) onde as funções g m (x) e h m (x) são as restrições de inegualdade e igualdade, respectivamente, e n g e n h representam a quantidade dessas funções. Já dom ( ) x j é o domínio da variável x j. Os seguintes tipos de restrições podem ser encontradas (Engelbrecht, 2007): Restrições de fronteira, que definem limites, inferiores ou superiores no espaço 1 A formulação apresentada é para um problema de minimização, mas é análoga a um problema de maximização 22

37 3.2. BUSCA GULOSA de busca. Restrições de Igualdade, que especificam que a função das variáveis do problema deve igual a uma constante. Restrições de Inegualdade, que especificam que a função das variáveis do problema deve ser menor que ou igual a (ou, maior que ou igual a) uma constante. 3.2 Busca Gulosa Algoritmos de busca gulosa escolhem, a cada passo, o melhor nó aparente (que possui melhor avaliação da função heurística) na "esperança"de encontrar a melhor solução do problema. Dois tipos populares de algoritmos de busca gulosa, que foram utilizados nesse trabalho, são o Forward Selection e Backward Elimination (Kohavi and John, 1997), que serão, brevemente, explicados nas próximas subseções Forward Selection Também conhecido como Sequential Forward Selection, é um procedimento de busca que adiciona novos elementos à solução, um de cada vez, até que essa solução seja adequada ao problema (Webb, 1999). A cada adição de elementos à solução ela é melhorada no que diz respeito ao objetivo. O Forward Selection começa com uma solução vazia e um conjunto de elementos a serem adicionados à solução. A cada passo do algoritmo é avaliada a adição de um elemento do conjunto à solução. Aquele elemento que, adicionado à solução, acrescente maior valor será selecionado nesse passo e retirado do conjunto de elementos. Isso é feito sucessivamente até que: não se tenha mais elementos para adicionar, a adição de elementos não traga nenhuma melhora à solução ou quando a adição de qualquer elemento quebre uma restrição do problema. Na figura 3.1, podemos observar uma exemplificação desse processo, considerando que 0 indica a ausência de um elemento x i na solução e 1 indica a presença do elemento x i. O processo começa com uma solução vazia 0, 0, 0, 0 e adiciona um elemento x i por vez à solução escolhendo aquela que representou maior melhora à solução. Esse processo é repetido sucessivamente até que um critério de parada seja atingido e a melhor solução encontrada pelo algoritmo (circulada) é retornada. Desenhando o espaço de busca, figura 3.2, como uma elipse, podemos observar que a quantidade de estados de busca no meio do algoritmo é maior, mas que o processo de 23

38 3.2. BUSCA GULOSA Figura 3.1 Processo de busca do Forward Selection busca vai refinando a busca até chegar a um ponto (solução). Quando a busca está no início (conjunto vazio), um grande número de estados pode ser avaliado, mas, quando a busca está mais perto do conjunto cheio, a região do espaço de busca avaliada pelo Forward Selection é mais estreito porque muitas elementos já foram adicionados ao conjunto. Figura 3.2 Espaço de Busca do Forward Selection (Gutierrez-Osuna, 2008) A vantagem de se usar essa técnica é que é de simples implementação e apresenta bons resultados na literatura, principalmente quando a solução ótima (ou sub-ótima) tem poucos elementos. Sua principal desvantagem é de não remover elementos que se tornam obsoletos após a adição de outros (Gutierrez-Osuna, 2008). 24

39 3.3. HILL CLIMBING Backward Elimination Também conhecido como Sequential Backward Selection ou Sequential Backward Elimination, é semelhante ao Forward Selection, sendo um procedimento de busca que vai retirando elementos da solução, ao invés de adicionar, até que essa se torne uma solução viável do problema (Webb, 1999). O Backward Elimination, começa com uma solução onde todos os elementos estão presentes. A cada passo, o algoritmo verifica qual elemento, ao ser retirado, melhora a solução e retira esse elemento. Esse processo é repetido até que: não se tenha mais nenhum elemento para eliminar ou a eliminação de um elemento faça com que o conjunto se torne uma solução viável ao problema. Esse processo, também, pode ser visto na figura 3.3. Figura 3.3 Processo de busca do Backward Elimination A figura 3.4, mostra o espaço de busca do algoritmo Backward Elimination, onde podemos observar que no início do processo de busca há mais possibilidade de estados a serem avaliados, mas à medida que vai eliminando elementos do conjunto, o espaço de busca do algoritmo fica mais estreito. O Backward Elimination, também é se simples implementação, tendo melhor performance quando a solução ótima (ou sub-ótima) tem uma grande quantidade de elementos no conjunto, desde que o algoritmo passa maior tempo visitando espaços de busca onde há grande quantidade de elementos no conjunto. Sua maior desvantagem é a inabilidade de reavaliar a utilidade de um elemento, após o mesmo ter sido descartado (Gutierrez-Osuna, 2008). 3.3 Hill Climbing O algoritmo de busca e otimização Hill Climbing, é um simples algoritmo de melhoras sucessivas (em loop) que gradualmente melhora uma dada solução. É dito que ele se move 25

40 3.3. HILL CLIMBING Figura 3.4 Espaço de Busca do Backward Elimination (Gutierrez-Osuna, 2008) continuamente na direção de um valor crescente e quando atinge o "pico"ele termina, pois não consegue encontrar nenhuma solução vizinha com melhor valor (Russell and Norvig, 2003). Dado um problema de minimização (ou maximização), com uma função objetivo f e um espaço de busca F, o algoritmo Hill Climbing, requer que para cada ponto n i F haja uma vizinhança N (n i ) F predefinida. Dado um ponto corrente n i F, o algoritmo pesquisa por um ponto n i+1 va vizinhança N (n i ), tal que f (n i+1 ) < f (n i ) (ou f (n i+1 ) > f (n i ), em caso de maximização). Se tal ponto n i+1 existe, ele se torna a nova solução corrente e o processo é iterado para buscar melhora na vizinhança da nova solução. De forma contrária, n i é considerado como solução ótima daquele problema, pois a partir dele não se consegue chegar em uma solução melhor (Gu, 1992). Apesar de ser um algoritmo simples e com bons resultados, o Hill Climbing, pode ficar "preso"em uma solução sub-ótima em algumas situações (maiores detalhes podem ser encontrados no livro de Russell and Norvig (2003)). Sendo assim, uma estratégia criada para tentar amenizar isso foi a criação do Hill Climbing com reinício aleatório. Toda vez que o algoritmo se encontra em uma daquelas situações, ele reinicia aleatoriamente seu estado em um ponto qualquer do espaço de busca. É como uma série de sucessivas buscas com o Hill Climbing a partir de estados iniciais gerados aleatoriamente. Por fim, tanto o Hill Climbing, o Forward Selection como o Bacward Elimination, são considerados algoritmos de busca local, devido ao fato que a partir do momento que eles 26

41 3.4. OTIMIZAÇÃO POR ENXAME DE PARTÍCULAS se encontram numa região do espaço de busca, são capazes, somente, de refinar a solução, naquele ponto, utilizando apenas pontos daquela vizinhança (local). Já algoritmos que tem capacidade de busca global, apresentam a capacidade de poder refinar uma solução, utilizando uma solução numa região do espaço de busca diferente da atual. Eles são normalmente algoritmos estocásticos, sendo que neste trabalho utilizamos o algoritmo de Otimização por Enxame de Partículas (explicado na próxima seção), como um algoritmo de busca global. 3.4 Otimização por Enxame de Partículas O algoritmo de Otimização por Nuvem de Partículas - PSO (Particle Swarm Optimization) foi criado por Kennedy et al. (1995) e é um algoritmo baseado em população que simula o comportamento social de um bando de pássaros. De acordo com Kennedy et al. (1995), a intenção inicial do conceito de enxame de partículas era o de simular a graciosidade e a coreografia de um bando de pássaros, com o objetivo de descobrir os padrões que governam sua habilidade de voarem de maneira síncrona e repentinamente mudarem de direção conseguindo se reagrupar de maneira ótima. A partir dessa observação, criou-se um algoritmo de busca e otimização simples e eficiente. Os indivíduos, no PSO, são chamados de partículas e "voam"através do espaço de busca, sendo que mudanças de posição neste espaço são baseadas na tendência social dos indivíduos imitarem o sucesso dos outros. Essas mudanças, que ocorrem com uma partícula do enxame, são influenciadas por sua própria experiência e pelo conhecimento obtido em sua vizinhança. Assim, o comportamento de busca de uma partícula também é afetado pelas outras partículas do enxame. De acordo com Engelbrecht (2007), as partículas seguem um comportamento bem simples: emular o sucesso dos indivíduos da vizinhança e seus próprios sucessos. O comportamento coletivo que emerge deste simples comportamento é a descoberta de regiões ótimas em um espaço de busca que pode ser de uma dimensão elevada. A conseqüência de modelar esse comportamento, é que o processo de busca é tal que partículas são estocasticamente atraídas pelas regiões que representam sucesso no espaço de busca. Nas próximas subseções, será definirá a base do algoritmo PSO, assim como e porque se deve limitar o valor de velocidade máxima da partícula. Em seguida, o peso de inércia é introduzido seguido pela explicação do modelo do PSO binário e, também uma estratégia de como se utilizar o PSO em problemas de otimização com restrições. 27

42 3.4. OTIMIZAÇÃO POR ENXAME DE PARTÍCULAS A Base do PSO O PSO mantém um enxame de partículas, onde cada partícula representa uma solução em potencial. Em analogia com paradigmas de computação evolucionária, um enxame é similar a uma população, enquanto uma partícula é similar a um indivíduo. Essas partículas "voam"através do espaço de busca, onde a posição de cada partícula é ajustada de acordo com seu próprio conhecimento e de seus vizinhos. Considerando um problema multidimensional com j = 1,...,n dimensões, seja x i j (t) a posição da partícula i na dimensão j no espaço de busca no instante de tempo t, a posição da partícula é atualizada pela adição de uma velocidade, v i j (t), à posição corrente da partícula: x i j (t + 1) = x i j (t) + v i j (t + 1) 3.1 O vetor de velocidade, v i, direciona o processo de otimização e reflete o conhecimento da partícula e o conhecimento obtido através da vizinhança. O conhecimento adquirido através da partícula representa seu componente cognitivo, sendo proporcional à distância atual da partícula de sua melhor posição (referida como melhor posição pessoal da partícula), encontrada desde o primeiro instante de tempo. O conhecimento adquirido através da vizinhança é referido como o componente social da equação de velocidade e representa a distância atual da partícula da melhor posição encontrada por alguma partícula em sua vizinhança. Inicialmente, foram propostas duas versões do algoritmos PSO, sendo que a diferença entre eles diz respeito à topologia (como é formada a vizinhança das partículas). Esses algoritmos são conhecidos como Global Best PSO e Local Best PSO (Eberhart et al., 2001) Global Best PSO No Global Best PSO, ou gbest PSO, cada partícula é vizinha de todas as outras partículas do enxame, todas elas estão conectadas. Essas conexões refletem a topologia do enxame, sendo que nesse caso a topologia é em estrela, como pode ser visto na figura 3.5. Nesta topologia, o componente social para atualização da partícula reflete a informação obtida de todas as outras partículas do enxame, representando a melhor posição, no espaço de busca, encontrada por todo o enxame, desde o primeiro espaço de tempo, referida como ŷ(t). A equação de atualização da velocidade da partícula no gbest PSO é dada como: 28

43 3.4. OTIMIZAÇÃO POR ENXAME DE PARTÍCULAS Figura 3.5 Topologia em Estrela (Novaes, 2002) v i j (t + 1) = v i j (t) + c 1 r 1 j (t) [ y i j (t) x i j (t) ] + c 2 r 2 j (t) [ ŷ j (t) x i j (t) ] 3.2 onde v i j (t) é a velocidade da partícula i na dimensão j no instante de tempo t, x i j (t) é a posição da partícula i na dimensão j no instante de tempo t, c 1 e c 2 são constantes de aceleração positivas, usadas para quantificar a contribuição dos componentes cognitivo e social respectivamente, e r 1 j,r 2 j U (0,1) são valores aleatórios no intervalo de [0, 1] que introduzem o elemento estocástico do algoritmo (Engelbrecht, 2007). A melhor posição pessoal da partícula i, y i, é a melhor posição visitada pela mesma desde o primeiro instante de tempo. Considerando um problema de minimização 2, a melhor posição pessoal da partícula no próximo instante de tempo, t + i, é calculada como (Engelbrecht, 2007): { y i (t) se f (x i (t + 1)) f (y i (t)) y i (t + 1) = 3.3 x i (t + 1) se f (x i (t + 1)) < f (y i (t)) Assim como nos Algoritmos Genéticos, a função de aptidão (fitness function) mede o quão ótima é a solução, isto é, a função de aptidão quantifica a performance, ou qualidade, de uma partícula (solução). Já a melhor posição global (posição com melhor avaliação da função de fitness, conhecida como gbest, é definida como (Engelbrecht, 2007): 2 basta inverter as inequações para tranformá-la utilizá-la num problema de maximização 29

44 3.4. OTIMIZAÇÃO POR ENXAME DE PARTÍCULAS ŷ(t) {y 0 (t),...,y ns (t)} f (ŷ(t)) = min{ f (y 0 (t)),..., f (y ns (t))} 3.4 onde n s é o número total de partículas do enxame Local Best PSO O Local Best PSO, ou lbest PSO, tem a topologia em forma de anel, como mostrado na figura 3.6. Nela, cada partícula x i é vizinha das partículas x i 1 e x i+1. Por isso, seu componente social tem apenas um conhecimento local do espaço de busca. Figura 3.6 Topologia em Anel (Novaes, 2002) A equação de velocidade 3.5 é diferente do gbest PSO. Nela a contribuição do componente social para a velocidade da partícula é proporcional à distância entre ela e a melhor posição encontrada dentro de sua vizinhança (Engelbrecht, 2007). v i j (t + 1) = v i j (t) + c 1 r 1 j (t) [ y i j (t) x i j (t) ] + c 2 r 2 j (t) [ ŷ i j (t) x i j (t) ] 3.5 onde ŷ i j é a melhor posição encontrada pela vizinhança da partícula i na dimensão j. A melhor posição local ŷ i, isto é, a melhor posição encontrada na vizinhança N i é definida como: ŷ i j (t + 1) { N i f (ŷi j (t + 1) ) = min{ f (x)}, x N i } 3.6 com vizinhança definida como: 30

45 3.4. OTIMIZAÇÃO POR ENXAME DE PARTÍCULAS N i = { } y i nni (t),y i nni +1 (t),...,y i 1 (t),y i (t),y i+1 (t),y i+nni (t) 3.7 para a vizinhança de tamanho n Ni. A melhor posição local também é referida como melhor posição da vizinhança. A vizinhança entre as partículas, no PSO básico 3, é baseada no índice das partículas (e não em sua localização no espaço de busca). Por exemplo, a partícula x 2, tem como vizinhas as partículas x 1 e x 3. Sendo que, as vizinhanças se sobrepõem, fazendo com que assim, haja compartilhamento de informações entre as vizinhanças, o que leva a convergência em um ponto único, num dado momento. O pseudo-código 3.1 do PSO (tanto gbest quanto lbest) é dado na próxima página: Criar e inicializar o enxame; Repita para cada partícula i = 1,...,n faça //melhor posição pessoal Se f (x i ) < f (y i ) então y i = x i fim_se //melhor posição global Se f (y i ) < f (ŷ i ) ŷ i = y i fim_se fim_para para cada partícula i = 1,...,n faça Atualize a velocidade utilizando a equacao 3.5 (lbest) ou 3.2 (gbest) Atualize a posição utilizando a equacao 3.1 fim_para até que critério de para seja atingido Pseudo-Código 3.1: Pseudo-Código do PSO As topologias dizem respeito à forma como é feita a ligação entre as partículas do enxame. Sua escolha tem efeito significativo na forma como a propagação de informações se dará dentro do enxame. No gbest PSO, devido à sua grande interconectividade, a propagação acontece de maneira muito rápida, fazendo com que o enxame tenha convergência mais rápida, mas aumentando, em contrapartida, a probabilidade do algoritmo ficar preso num ótimo local. Já no lbest PSO, a propagação da informação ocorre de 3 PSO em sua versão original 31

46 3.4. OTIMIZAÇÃO POR ENXAME DE PARTÍCULAS maneira mais lenta e gradual, fazendo com que o algoritmo necessite de um maior tempo para convergir. Como ele demora mais pra convergir, as partículas conseguem explorar mais o espaço de busca diminuindo, assim, a probabilidade de ficar preso em um ótimo local se comparado ao anterior (Engelbrecht, 2007) Critérios de Parada do PSO Os critérios de parada dizem respeito ao momento que o algoritmo deve ser finalizado. Deve-se levar em conta que, dependendo do critério de parada e de seus valores, o algoritmo pode, ou não, encontrar resultados satisfatórios. De acordo com van den Bergh and Engelbrecht (2001), os critérios de parada comumente usados são: Número máximo de iterações: se o número de iterações for muito baixo, o algoritmo pode terminar sem que tenha tido tempo suficiente para encontrar uma boa solução, se muito alto, o algoritmo pode continuar executando, mesmo que o enxame tenha convergido. Geralmente, esse critério é utilizado em conjunção outros critérios, sendo sua principal utilidade o fato de forçar uma parada, caso o algoritmo falhe em convergir. Quando uma solução aceitável foi encontrada: nesse caso, assume-se que se tem o conhecimento do valor ótimo, de tal forma que, o algoritmo pode aceitar um valor que seja próximo ao ótimo. Nesse caso, utiliza-se um limiar para que, se a solução for melhor do que o valor ótimo menos esse limiar, então aceita-se essa solução e o algoritmo é finalizado. Quando não há melhora significativa durante um determinado número de iterações: esse critério, determina um valor tal que, se durante certo número de iterações a melhora na solução atual do algoritmo não for maior que certo valor, entende-se que o algoritmo convergiu e não está mais melhorando o resultado, então pode ser parado Limite de Velocidade Um aspecto importante que determina a eficiência e precisão de um algoritmo de otimização é sua capacidade de exploração global e local. Exploração global diz respeito à característica que o algoritmo tem em explorar regiões diferentes do espaço de busca, de forma a procurar a região do ótimo global. Exploração local, pelo contrário, diz respeito 32

47 3.4. OTIMIZAÇÃO POR ENXAME DE PARTÍCULAS à habilidade do algoritmo de concentrar sua busca em torno de uma região promissora do espaço de busca de forma a tentar refinar uma solução ótima candidata (Engelbrecht, 2007). Um bom algoritmo tem que balancear essas características de uma boa forma, sendo que isso é controlado no PSO através da equação de velocidade. Nas versões básicas do PSO a velocidade tem tendência a ir para valores altos, fazendo com que as partículas dêem passos muito grandes no espaço de busca, e por vezes transpassando os limites do mesmo. Para controlar esse comportamento de exploração global, a velocidade pode ser limitada a um valor máximo (Eberhart et al., 1996). Se uma partícula excede a velocidade máxima, então seu valor de velocidade será o valor máximo. Seja V max, j o valor máximo de velocidade na dimensão j, a velocidade da partícula é ajustada antes da atualização da posição, de acordo com: { v i j v i j (t + 1) = (t + 1) se v i j (t + 1) < V max, j 3.8 V max, j se v i j (t + 1) V max, j onde v i j é calculado utilizando-se a equação 3.2 ou 3.5. Valores altos de V max, j facilitam uma exploração global, enquanto valores pequenos, facilitam uma exploração local. Valores muito pequenos podem ocasionar que o enxame não explore suficientemente o espaço de busca e facilmente fique preso num ótimo local, já para valores muito grandes, o enxame terá dificuldade de convergir e de refinar uma solução numa região promissora do espaço de busca (Engelbrecht, 2007) Peso de Inércia O peso de inércia foi introduzido por Shi and Eberhart (1998), para ser um fator escalar associado à velocidade atual da partícula, que funcionasse como um mecanismo de controle da exploração global e local. O peso de inércia, w, governa o quanto a velocidade atual da partícula influenciará na sua nova velocidade. Dessa forma uma nova equação de velocidade é dada por: v i j (t + 1) = wv i j (t) + c 1 r 1 j (t) [ y i j (t) x i j (t) ] + c 2 r 2 j (t) [ ŷ i j (t) x i j (t) ] 3.9 Para obtenção da equação de velocidade original, basta atribuir ao peso de inércia o valor 1 (w = 1). Valores altos de w favorecem uma exploração global, já valores baixos, favorecem uma exploração local. Estudos realizados por Shi and Eberhart (1998), investigaram os efeitos dos valores 33

48 3.4. OTIMIZAÇÃO POR ENXAME DE PARTÍCULAS de w no PSO. Verificaram, em seus resultados, que a escolha do valor de w num intervalo de 0.8 a 1.2 (w [0.8,1.2]) produz bons resultados. No entanto, a melhor performance foi obtida quando se utilizou um valor linearmente decrescente de 0.9 a 0.4, pois permitia às partículas, inicialmente, terem um comportamento de exploração global e explorarem mais o espaço de busca (quando o peso de inércia é maior). E, por fim (quando o peso de inércia é menor), as partículas tem um comportamento de exploração local, refinando mais a busca. Algumas outras abordagens de escolha do valor do peso de inércia, encontradas na literatura são: escolha aleatória (Peng et al., 2000), decréscimo não linear (Peram et al., 2003), fuzzy adaptativo (Shi and Eberhart, 2001), sendo que, o linearmente decrescente é o mais amplamente utilizado PSO Binário Originalmente, o PSO foi desenvolvido para otimização de valores contínuos. Kennedy and Eberhart (1997) publicaram o primeiro trabalho utilizando o PSO para problemas em espaço de busca binário. No PSO binário, as partículas representam posições no espaço de busca binário, onde cada elemento do vetor de posição pode ter o valor 0 ou 1. Formalmente, x i B n x ou x i j {0,1}. A velocidade, no PSO binário, é dada em termos probabilísticos, sendo a mesma interpretada como a probabilidade de mudar um bit de 0 para 1, ou de 1 para 0, quando da atualização da posição das partículas. Normalmente, a velocidade pode assumir valores contínuos, portanto, é necessária uma forma de atualizar a posição das partículas, de modo que os componentes assumam apenas os valores 0 ou 1. sig ( v i j (t) ) 1 = 1 + e v i j(t) 3.10 Pode-se utilizar a função simoidal 3.10, para normalizar valores da velocidade v i dentro do intervalo [0, 1], fazendo que a nova equação de atualização da posição da partícula seja: onde r 3 j U (0,1) x i j (t + 1) = { 1 se r 3 j (t) < sig ( v i j (t + 1) ) 0 o contrário 3.11 Com essa nova equação (3.11), a velocidade é a probabilidade de x i j (t) ser 0 ou 1. Por exemplo, se v i j (t) = 0, então a probabilidade de x i j (t + 1) = 1 é de 50%. Se 34

49 3.5. CONSIDERAÇÕES FINAIS vi j (t) > 0, então a probabilidade de x i j (t + 1) = 1 é maior que 50%, e se vi j (t) < 0, então é a probabilidade de x i j (t + 1) = 1 é menor que 50% PSO com Restrições Hu and Eberhart (2002) desenvolveram uma variação do PSO para lidar com problemas que têm que satisfazer restrições (3.1). Nele, as partículas que representam uma solução, que não satisfaz todas as restrições, não têm influência sobre as outras partículas do enxame. Nessa abordagem, as partículas são inicializadas dentro do espaço de busca factível (que respeita todas as restrições), e a informação da melhor posição pessoal da partícula só é atualizada se uma nova solução, que respeite todas as restrições, for encontrada. Nesse algoritmo é permitido uma partícula mover-se para fora do espaço de busca de soluções factíveis, mas, no fim, ela acabará sendo influenciada a voltar a uma região factível, pois os valores de sua melhor posição pessoal e melhor posição da vizinhança, sempre estarão dentro de um espaço de busca factível. Essa permissão (de mover-se fora da região factível), melhora o comportamento de exploração global do algoritmo, pois ao "voar"dentro de uma região do espaço de busca infactível, a partícula, por ventura, pode acabar encontrando uma nova região factível mais promissora do que a atual. Sendo esse um comportamento interessante, quando o espaço de busca factível é formado por regiões disjuntas. Para que não seja permitido às partículas ficarem muito tempo em regiões infactíveis, depois de certo número de iterações, elas podem ser reparadas e colocadas automaticamente dentro do espaço de busca factível. Outras estratégias, usam de penalidade para as partículas que violam as restrições (Parsopoulos and Vrahatis, 2002; Tandon and Mounayri, 2002) ou convertem o problema em um problema sem restrição langraniano (Laskari et al., 2002; Shi and Krohling, 2002). 3.5 Considerações finais Este capítulo introduziu o fato de que muitos problemas da área de Engenharia de Software podem ser vistos como problemas de otimização, em especial o problema de seleção de casos de teste. Visando solucionar esse problema, o restante do capítulo apresentou algumas técnicas de busca meta-heuristica, e maior detalhes sobre uma conhecida como Otimização por Enxame de Partículas (ou simplesmente PSO), que tem sido muito usada para tentar resolver problemas de otimização, até mesmo os que lidam com restrições. 35

50 3.5. CONSIDERAÇÕES FINAIS As técnicas meta-heurísticas apresentadas nesse capítulo, foram implementadas num plugin chamado Execution Effort Selector Plugin, que realiza a tarefa de seleção automática de casos de teste de software. Maiores detalhes sobre esse plugin são apresentados no próximo capítulo. 36

51 4 Execution Effort Selector Plugin: Seleção de Casos de Teste por Esforço de Execução Everything has its beauty but not everyone sees it. CONFÚCIO (Filósofo chinês) Como visto anteriormente, o processo de testes de software é custoso, sendo comum que na fase de planejamento dos testes, o gerente de teste ter que realizar uma seleção de forma a adequar uma suíte existente aos recursos disponíveis (sejam eles de tempo, pessoas, máquinas, ect). Levando isso em consideração, ferramentas que auxiliem esse processo são extremamente úteis. Um exemplo de ferramenta desse gênero é a TaRGet (seção 2.4), que foi desenvolvida pelo grupo de pesquisa do Brazil Test Center (Torres et al., 2007), como forma de reduzir os custos inerentes ao processo. Esse trabalho desenvolveu o Execution Effort Selector Plugin, que foi adicionado ao conjunto de plugins de seleção da ferramenta TaRGeT. Nesse plugin, é possível que o usuário informe um valor máximo (em minutos) de esforço de execução, que servirá como base para o processo de seleção. Na seção 4.1, a seguir, a visão geral do Execution Effort Selector Plugin é apresentada. Logo após, na seção 4.2, a formulação da representação do problema de seleção de casos de teste baseado no esforço de execução. Os módulos implementados no plugin são apresentados posteriormente, sendo eles: Módulo Forward Selection 4.3.1, Módulo Bacward Elimination 4.3.2, Módulo Hill Climbing 4.3.3, Módulo Binary Constraint 37

52 4.1. VISÃO GERAL Particle Swarm Optimization 4.3.4, Módulo BCPSO-FS 4.3.5, Módulo BCPSO-Hill e Módulo Aleatório Por fim, as considerações finais desse capítulo. 4.1 Visão Geral Após estudo das principais abordagens de seleção de casos de teste, esse trabalho propõe a seleção de casos de teste funcionais baseando-se numa restrição de esforço (custo) de execução de testes e cobertura de requisitos funcionais. Tal forma de seleção não é encontrada na literatura (pelo menos até onde a revisão bibliográfica foi realizada). Esta ferramenta foi desenvolvida em forma de plugin, utilizando a tecnologia Eclipse RCP 1, a mesma adotada pela TaRGeT. A principal vantagem em sua utilização é a possibilidade de permitir a gerente de teste obter uma suíte que se adeque aos recursos de tempo disponíveis para execução de um ciclo de testes. Ao utilizar o Execution Effort Selector Plugin, o usuário deve informar um valor limite (em minutos) para seleção dos casos de teste. Dessa forma, o plugin seleciona os casos de teste, utilizando a estimativa de esforço de execução obtida através da ferramenta Test Execution Effort Estimation Tool (seção 2.5), de forma que o subconjunto selecionado não extrapole esse valor de entrada. Esse processo pode ser visto na figura 4.1. Figura 4.1 Fluxo do Processo do Execution Effort Selector Plugin As etapas desse processo são: (1) usuário informa a TaRGeT o valor limiar de esforço 1 Plataforma da Eclipse, para desenvolvimento de aplicações Rich Client 38

53 4.2. FORMULAÇÃO DO PROBLEMA de execução (2) a TaRGeT envia ao plugin a suíte de testes juntamente com o valor de limiar do usuário (3) o plugin envia ao Test Execution Effort Estimation Tool a suíte para ser estimada (4) o Test Execution Effort Estimation Tool devolve para o plugin a suíte estimada (5) o plugin envia a suíte estimada junto com o valor de limiar para o módulo de seleção (6) o módulo de seleção do plugin devolve uma suíte que não ultrapasse o valor limiar (7) o plugin devolve essa suíte para a TaRGeT. Neste trabalho, foram desenvolvidos sete módulos de seleção diferentes, sendo que para escolher qual deles seria o módulo de seleção a ser utilizado de forma definitiva, foram feitos estudos de casos comparativos (como pode ser visto no capítulo 5). 4.2 Formulação do Problema Como dito na seção 2.3, o problema de seleção de casos de teste é complexo, então técnicas heurísticas (ou meta-heuríticas) automáticas podem ser utilizadas nesse problema. Mas, para se utilizar essa técnicas, primeiro tem que se formular como o problema será tratado. Dada uma suíte de teste T = {T 1,...,T n } com n casos de teste, uma solução pode ser representada como um vetor binário t = (t 1,...,t n ) (figura 4.2), onde t j {0,1} indica a presença (1) ou ausência (0) do caso de teste T j dentro do subconjunto t, onde t T. Figura 4.2 Representação de uma solução Um fato que deve ser ressaltado é que a ordem de execução dos testes pode afetar o custo de execução, mas isso não está sendo levado em consideração neste trabalho, ficando como um possível trabalho futuro. A medida de aptidão (fitness), ou qualidade, de uma solução é a porcentagem de requisitos de T cobertos por t. Formalmente, sendo R = {R 1,...,R k } o conjunto de k requisitos de T e F(T j ) uma função que retorna o subconjunto de requisitos de R cobertos por um caso de teste T j, então a função de aptidão de uma solução t é dada como: Fitness(t) = 100 t j =1{F(T j )} k