Seleção de casos de teste com restrição de custo de execução utilizando otimização por enxame de partículas

Texto

(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 posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao. 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, 2011. xii, 75 folhas : il., fig., tab. Orientador: Flávia de Almeida Barros. Dissertação (mestrado) Universidade Federal Pernambuco. CIn. Ciência da Computação, 2011.. de. Inclui bibliografia. 1. Engenharia de software. 2. Inteligência artificial. 3. Testes de software. I. Barros, Flávia de Almeida (orientadora). II. Título. 005.1. CDD (22. ed.). MEI2011 – 050.

(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. x. Lista de Tabelas. xii. 1. Introdução 1.1 Motivação e Relevância . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Solução Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Organização do Documento . . . . . . . . . . . . . . . . . . . . . . . .. 2. Testes de Software 2.1 Abordagens de Teste . . . . . . . . . . . . . . . . . 2.1.1 Abordagem Funcional ou Caixa Preta . . . . 2.1.2 Abordagem Estrutural ou Caixa Branca . . . 2.2 Fases de Teste . . . . . . . . . . . . . . . . . . . . . 2.2.1 Testes de Unidade . . . . . . . . . . . . . . 2.2.2 Testes de Integração . . . . . . . . . . . . . 2.2.3 Testes de Sistema . . . . . . . . . . . . . . . 2.2.4 Testes de Aceitação . . . . . . . . . . . . . . 2.3 Seleção de Casos de Teste . . . . . . . . . . . . . . 2.3.1 Critérios de Seleção de Casos de Teste . . . . 2.4 Test and Requirements Generation Tool - TaRGeT . . 2.4.1 Funcionamento . . . . . . . . . . . . . . . . 2.5 Test Execution Effort Estimation Tool . . . . . . . . 2.5.1 Modelo de estimativa de pontos de execução 2.5.2 Transformação em Medida de Tempo . . . . 2.6 Considerações finais . . . . . . . . . . . . . . . . .. 3. Meta-Heurísticas 3.1 Problemas com Restrições . . . . . . 3.2 Busca Gulosa . . . . . . . . . . . . . 3.2.1 Forward Selection . . . . . . 3.2.2 Backward Elimination . . . . 3.3 Hill Climbing . . . . . . . . . . . . . 3.4 Otimização por Enxame de Partículas. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. 1 2 4 5. . . . . . . . . . . . . . . . .. 6 7 7 8 9 10 10 11 11 12 13 14 14 16 16 18 19. . . . . . .. 21 22 23 23 25 25 27. viii.

(11) 3.5 4. 5. 6. 3.4.1 A Base do PSO . . . . . . . 3.4.2 Global Best PSO . . . . . . 3.4.3 Local Best PSO . . . . . . . 3.4.4 Critérios de Parada do PSO . 3.4.5 Limite de Velocidade . . . . 3.4.6 Peso de Inércia . . . . . . . 3.4.7 PSO Binário . . . . . . . . 3.4.8 PSO com Restrições . . . . Considerações finais . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 28 28 30 32 32 33 34 35 35. Execution Effort Selector Plugin: Seleção de Casos de Teste por Esforço de Execução 4.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Formulação do Problema . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Módulo Forward Selection . . . . . . . . . . . . . . . . . . . . 4.3.2 Módulo Backward Elimination . . . . . . . . . . . . . . . . . . 4.3.3 Módulo Hill Climbing . . . . . . . . . . . . . . . . . . . . . . 4.3.4 Módulo Binary Constraint Particle Swarm Optimization - BCPSO 4.3.5 Módulo BCPSO-FS . . . . . . . . . . . . . . . . . . . . . . . 4.3.6 Módulo BCPSO-Hill . . . . . . . . . . . . . . . . . . . . . . . 4.3.7 Módulo Randômico . . . . . . . . . . . . . . . . . . . . . . . 4.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . .. 37 38 39 40 41 41 42 42 44 44 45 45. Estudo de Caso e Resultados Experimentais 5.1 Estudo de Caso . . . . . . . . . . . . . 5.1.1 Suite 1 . . . . . . . . . . . . . 5.1.2 Suite 2 . . . . . . . . . . . . . 5.2 Experimentos . . . . . . . . . . . . . . 5.2.1 Resultados dos Experimentos . 5.3 Considerações Finais . . . . . . . . . .. . . . . . .. 46 46 47 48 49 50 68. Conclusões 6.1 Resumo das Contribuições . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 69 69 70. Referências Bibliográficas. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 71. ix.

(12) Lista de Figuras. 2.1 2.2 2.3 2.4 2.5 2.6 2.7. 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. 9 10 15 15 17 18 19. 3.1 3.2 3.3 3.4 3.5 3.6. 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 . . . . . . . . . . . . .. . . . . . .. 24 24 25 26 29 30. 4.1 4.2. Fluxo do Processo do Execution Effort Selector Plugin . . . . . . . . . Representação de uma solução . . . . . . . . . . . . . . . . . . . . . .. 38 39. 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17. Relação entre esforço e requisitos da suíte 1 . . . . Relação entre esforço e requisitos da suíte 2 . . . . 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. 48 49 51 52 52 53 54 54 55 56 56 57 58 58 59 60 60. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. x.

(13) 5.18 5.19 5.20 5.21 5.22 5.23 5.24 5.25 5.26. 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. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 61 62 62 63 64 64 65 66 66. xi.

(14) Lista de Tabelas. 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8. 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. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 51 53 55 57 59 61 63 65. 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 2010 2 .. 1.3. 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.. 2.1.1. 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 2.1.2 apresenta a abordagem de teste estrutural, que pode ser utilizada em complemento à abordagem funcional.. 2.1.2. 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. 2.2.1. 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).. 2.2.2. 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.. 2.2.3. 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.. 2.2.4. 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. 2.3.1. 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.. 2.4.1. 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.. 2.5.1. 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 2.6.. 17.

(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). 2.5.2. 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. Sujeito à. f (x) ,. x = (x1 , . . . , xnx ). gm (x) ≤ 0, m = 1, . . . , ng hm (x) = 0, m = ng + 1, . . . , ng + nh x j ∈ dom x j. onde as funções gm (x) e hm (x) são as restrições de inegualdade e igualdade, respectiva mente, e ng e nh 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 1A. 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.. 3.2.1. 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 xi na solução e 1 indica a presença do elemento xi . O processo começa com uma solução vazia 0, 0, 0, 0 e adiciona um elemento xi 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. 3.2.2. 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 ni ∈ F haja uma vizinhança N (ni ) ⊂ F predefinida. Dado um ponto corrente ni ∈ F, o algoritmo pesquisa por um ponto ni+1 va vizinhança N (ni ), tal que f (ni+1 ) < f (ni ) (ou f (ni+1 ) > f (ni ) , em caso de maximização). Se tal ponto ni+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, ni é 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.