Your SlideShare is downloading. ×
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Métricas para estimativa de esforço em projetos de teste de software
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Métricas para estimativa de esforço em projetos de teste de software

4,886

Published on

Atualmente não existe uma técnica-padrão para estimativa de esforço em projetos de teste de software. Existem, no entanto, muitas propostas com abordagens diferenciadas, mas que ainda não alcançaram a …

Atualmente não existe uma técnica-padrão para estimativa de esforço em projetos de teste de software. Existem, no entanto, muitas propostas com abordagens diferenciadas, mas que ainda não alcançaram a precisão esperada para realizar estimativa de forma confiável em qualquer contexto de desenvolvimento de software.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,886
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
180
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. UNIVERSIDADE DO GRANDE RIO PROF. JOSÉ DE SOUZA HERDY ESCOLA DE CIÊNCIA E TECNOLOGIA BACHARELADO EM SISTEMAS DE INFORMAÇÃO Samanta Cicília de Barros Souza Métricas para Estimativa de Esforço em Projetos de Teste de Software Duque de Caxias 2012
  • 2. UNIVERSIDADE DO GRANDE RIO PROF. JOSÉ DE SOUZA HERDY ESCOLA DE CIÊNCIA E TECNOLOGIA BACHARELADO EM SISTEMAS DE INFORMAÇÃO Samanta Cicília de Barros Souza Métricas para Estimativa de Esforço em Projetos de Teste de Software Projeto Final de Curso apresentado à Universidade do Grande Rio “Prof. José de Souza Herdy” (UNIGRANRIO) como parte dos requisitos para conclusão do curso de Bacharelado em Sistemas de Informação. Orientador: Prof. Thiago Silva de Souza Duque de Caxias 2012
  • 3. Métricas para Estimativa de Esforço em Projetos de Teste de Software Samanta Cicília de Barros Souza - 5304880 Projeto Final de Curso apresentado à Universidade do Grande Rio “Prof. José de Souza Herdy” (UNIGRANRIO) como parte dos requisitos para conclusão do curso de Bacharelado em Sistemas de Informação Banca Examinadora: 1. Orientador e Presidente: Prof. Thiago Silva de Souza 2. Membro externo: pesquisadora da Coppe/UFRJ Talita Vieira Ribeiro Duque de Caxias 2012
  • 4. Samanta Cicília de Barros Souza Métricas para Estimativa de Esforço em Projetos de Teste de Software, Duque de Caxias, 2012 XVI, 125 p. 29,7 cm. (Escola de Ciência e Tecnologia, 2012) Projeto de Final de Curso - Universidade do Grande Rio, Escola de Ciência e Tecnologia. 1. Engenharia de Software 2. Teste de Software 3. Métricas de Estimativa de Esforço I. EIN/UNIGRANRIO II. Título (série)
  • 5. Aos meus pais.
  • 6. AGRADECIMENTOS Em primeiro lugar a Deus, sem o qual nada disso seria possível, agradeço pela força e pela graça concedida e pela oportunidade de alcançar meus sonhos. Aos meus pais, Gezilene e Paulo, que sempre me apoiaram e confiaram nas minhas escolhas. Pessoas que nos momentos mais difíceis sempre estiveram do meu lado, me dando forças e não me deixando desistir. Obrigada por dedicar a vida de vocês a me fazer feliz. Aos amigos conquistados na faculdade que viveram comigo esse momento e também apoiaram e compartilharam alegrias e dificuldades, mas sempre ajudando uns aos outros. A todos os professores com os quais tive a grande honra de estudar, em especial ao Prof. Thiago Souza, que como orientador teve muita competência, paciência e amizade, posso afirmar que tive a grande felicidade de contar com um dos melhores orientadores do Curso de Sistemas de Informação. A minha família em geral que sempre acreditou em mim e me deu forças. Aos colegas de trabalho que de alguma forma sempre procuraram contribuir com o que eu precisava. Agradeço também ao meu amigo Josenildo Amorim, que começou esse trabalho comigo, mas infelizmente não pôde dar continuidade. Meu muito obrigada a todos vocês!
  • 7. “If you have an apple and I have an apple and we exchange these apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas.” George Bernard Shaw
  • 8. RESUMO Planejar e programar as atividades de teste a serem realizadas é um fator fundamental para garantir a qualidade de um software, possibilitando alocação de recursos e tempo de forma consistente para essas atividades. A maioria das empresas utiliza apenas experiência para estimar o esforço a ser gasto em teste de software, já que as técnicas existentes são complexas demais para serem executadas frequentemente, demandando muitas vezes um tempo que poderia ser gasto na execução dos testes. Diante disso, foi realizada uma comparação entre algumas dessas técnicas e um estudo experimental aplicando-as e avaliando sua precisão de acordo com o valor gasto para testar o sistema desse experimento. Foram utilizadas as técnicas Análise de Pontos de Teste, Método Ponderado de Nageswaran, Análise de Pontos por Caso de Teste e Estimativa baseada em Especificação de Requisito Funcional e Eficiência Acumulada. Este projeto, portanto, apresenta algumas técnicas existentes na literatura acadêmica e no mercado, assim como um survey com respostas de profissionais de teste de algumas partes do mundo sobre a forma que eles estimam o esforço de teste, um protocolo de quasi-Revisão Sistemática e uma prova de conceito aplicando as técnicas descritas. A maioria das técnicas, no entanto, ainda se encontra em fase de estudos e não apresenta precisão aceitável. Palavras-chave: engenharia de software, teste de software, métricas de estimativa.
  • 9. SUMÁRIO 1 - Introdução .................................................................................................................. 17 1.1 - Motivação ..................................................................................................................... 17 1.2 - Problema ...................................................................................................................... 17 1.3 - Hipótese........................................................................................................................ 18 1.4 - Objetivos e Escopo do Trabalho ................................................................................... 18 1.5 - Organização do Trabalho.............................................................................................. 18 2 - Métricas para Estimativa de Esforço em Projetos de Teste de Software ....................... 19 2.1 - Métricas para Estimativa de Esforço ............................................................................ 19 2.2 - Análise de Pontos de Teste (APT) ................................................................................. 19 2.3 - Estimativa a partir de Bases Históricas de Projetos de Teste ...................................... 26 2.4 - Análise de Pontos por Caso de Teste ........................................................................... 27 2.5 - Estimativa de Capers Jones .......................................................................................... 30 2.6 - Estimativa baseada na Regra 40-20-40 ........................................................................ 30 2.7 - Estimativa Método Ad-Hoc........................................................................................... 30 2.8 - Estimativa por Pontos de Execução ............................................................................. 30 2.9 - Estimativa baseada em Especificação de Requisito Funcional e Eficiência Acumulada .............................................................................................................................................. 33 2.10 - Estimativa Método Ponderado de Nageswaran ........................................................ 35 3 - Protocolo de quasi-Revisão Sistemática ...................................................................... 37 3.1 - Cenário de Investigação Principal ................................................................................ 37 3.2 - Protocolo de Busca ....................................................................................................... 38 3.2.1 - Foco de Interesse .................................................................................................. 38 3.2.2 - Qualidade e Amplitude da Questão ...................................................................... 38 3.3 - Seleção de Fontes ......................................................................................................... 40
  • 10. 3.3.1 - Definição de Critérios para seleção de fontes....................................................... 40 3.3.2 - Idioma das fontes .................................................................................................. 40 3.3.3 - Identificação das Fontes ........................................................................................ 40 3.4 - Seleção dos Estudos ..................................................................................................... 42 3.4.1 - Definição dos estudos ........................................................................................... 42 3.5 - Resultados da pré-execução......................................................................................... 44 3.6 - Estratégia para Extração da Informação ...................................................................... 45 3.7 - Critérios para Avaliação da Qualidade dos Artigos ...................................................... 45 3.8 - Execução ....................................................................................................................... 45 4 - Survey ........................................................................................................................ 48 4.1 - Definição de Survey ...................................................................................................... 48 4.2 - Questionários ............................................................................................................... 48 4.3 - Resultados .................................................................................................................... 49 5 - Prova de Conceito ....................................................................................................... 54 5.1 - Informações da Prova de Conceito .............................................................................. 54 5.2 - Estimativas de Esforço Total do Projeto de Teste ........................................................ 56 5.2.1 - Análise de Pontos de Teste ................................................................................... 56 5.2.2 - Estimativa Método Ponderado de Nageswaran ................................................... 59 5.3 - Estimativas de Esforço Parcial do Projeto de Teste ..................................................... 60 5.3.1 - Análise de Pontos por Caso de Teste (TCP) ........................................................... 60 5.3.2 - Estimativa baseada em Especificação de Requisito Funcional e Eficiência Acumulada ........................................................................................................................ 61 5.4 - Considerações sobre as medições................................................................................ 61 6 - Conclusão ................................................................................................................... 64 6.1 - Considerações Finais .................................................................................................... 64 6.2 - Contribuições................................................................................................................ 64
  • 11. 6.3 - Trabalhos Futuros ......................................................................................................... 65 Referências Bibliográficas ................................................................................................ 66 Apêndice I – Modelo de Formulário de Extração .............................................................. 68 Apêndice II – Artigos do protocolo de quasi-Revisão Sistemática...................................... 70 Apêndice III – Regras de Negócio Sistema Escola .............................................................. 86 Apêndice VI – Descrição dos Casos de Uso ....................................................................... 88 Apêndice V – Casos de Teste do Sistema Escola................................................................ 94 Apêndice VI – Evidências de Teste executados com sucesso ........................................... 106 Apêndice VII – Evidências de Teste reprovados .............................................................. 115 Apêndice VIII – Análise de Pontos de Teste (técnica original) ......................................... 123 Apêndice IX – Análise de Pontos de Teste (planilha SERPRO) .......................................... 124 Apêndice X – Análise de Pontos de Teste (ferramenta de APT) ....................................... 125
  • 12. LISTA DE FIGURAS Figura 1: Visão Geral da Técnica de Análise de Pontos de Teste (VEENENDAAL, 1999) ......... 20 Figura 2: Visão Geral do Modelo de Estimativa de Pontos de Execução (ARANHA, 2007). .... 31 Figura 3: Atribuindo os pontos de execução para cada passo do caso de teste (ARANHA, 2007). ...................................................................................................................... 32 Figura 4: Estimativa do esforço em homens/hora (ARANHA, 2007). ................................... 33 Figura 5: Diagrama do processo do protocolo de quasi-Revisão Sistemática ....................... 44 Figura 6: Gráfico dos períodos em que os artigos foram publicados ................................... 47 Figura 7: Questionário em português ................................................................................ 48 Figura 8: Questionário em inglês ...................................................................................... 49 Figura 9: Porcentagem de utilização das métricas (no Brasil).............................................. 50 Figura 10: Porcentagem de utilização das métricas (outras partes do mundo) .................... 51 Figura 11: Porcentagem de utilização das métricas (Brasil e outras partes do mundo)......... 51 Figura 12: Empresas que estimam esforço para teste por país ........................................... 52 Figura 13: Técnicas utilizadas por país ............................................................................... 52 Figura 14: Casos de Uso Sistema Escola............................................................................. 54 Figura 15: Características de cada função do Domínio Sistema Escola. ............................... 57 Figura 16: Homens/hora totais de teste. ........................................................................... 59 Figura 17: Medição em Pontos por Caso de Teste. ............................................................. 60 Figura 18: Medição em Especificação de Requisito Funcional e Eficiência Acumulada. ........ 61
  • 13. LISTA DE TABELAS Tabela 1: Peso da importância das funcionalidades para o usuário. 21 Tabela 2: Peso da intensidade de uso das funções. 21 Tabela 3: Peso da interface das funções. 21 Tabela 4: Peso da complexidade das condições. 22 Tabela 5: Peso das Características Explícitas. 23 Tabela 6: Ferramentas de Teste. 24 Tabela 7: Testes de precedência. 24 Tabela 8: Documentação de Teste. 24 Tabela 9: Ambiente de Desenvolvimento. 25 Tabela 10: Ambiente de Teste. 25 Tabela 11: Testware. 25 Tabela 12: Tamanho da Equipe de Teste. 26 Tabela 13: Ferramentas de Gerência de Teste. 26 Tabela 14: Descrição do Nível de Complexidade das Pré-condições (traduzido). 27 Tabela 15: Descrição do Nível de Complexidade dos Dados de Teste (traduzido). 28 Tabela 16: Pesos das pré-condições e dados de teste segundo a complexidade (traduzido). 28 Tabela 17: Pesos dos Tipos de Teste (traduzido). 30 Tabela 18: Pesos dos Tipos de Atores (traduzido). 35 Tabela 19: Classificação dos fatores de ambiente (traduzido). 36 Tabela 20: Máquinas de busca utilizadas no protocolo de quasi-Revisão Sistemática. 41 Tabela 21: Tabela com os resultados da pré-execução do protocolo de quasi-Revisão Sistemática. 44 Tabela 22: Tabela com os resultados da execução do protocolo de quasi-Revisão Sistemática pelo primeiro pesquisador. 45 Tabela 23: Tabela com os resultados da execução do protocolo de quasi-Revisão Sistemática pelo segundo pesquisador. 46 Tabela 24: Tabela com os resultados da execução do protocolo de quasi-Revisão Sistemática. 46 Tabela 25: Tempo gasto para realizar cada atividade de Teste. 55 Tabela 26: Estimativa do Domínio Sistema Escola em Pontos de Função. 56
  • 14. Tabela 27: Tempo gasto para realizar cada atividade de Teste segundo APT. 57 Tabela 28: Tempo gasto para realizar cada atividade de Teste segundo APT (planilha SERPRO). Tabela 29: Descrição dos Fatores Técnicos de Ambiente. 58 59
  • 15. LISTA DE ABREVIATURAS E SIGLAS 1. AIE – Arquivo de Interface Externa. 2. ALI – Arquivo Lógico Interno. 3. APT – Análise de Pontos de Teste. 4. APF – Análise de Pontos de Função. 5. C – Complexidade. 6. CE – Características Explícitas. 7. CET - Ciclo de Execução. 8. CF - Fator de Conversão. 9. CI – Características Implícitas. 10. Df – Função dependente. 11. E - Fatores de ambiente. 12. EA - Média Aritmética de Esforço do ciclo. 13. EE – Entrada Externa. 14. Erms - Média da raíz quadrada do erro médio. 15. FG - ferramentas de gerência. 16. FTA - Fatores técnicos de ambiente. 17. HTP - Horas de Teste Primárias. 18. I – Interface. 19. IPC - Índice de planejamento e controle. 20. N - Cenário de caso de uso normal. 21. Ntc - Número de casos de teste do ciclo. 22. PCT – Pontos por caso de teste. 23. PCTA – Pontos por caso de teste ajustados. 24. PCTNA - Pontos por caso de teste não ajustados. 25. PCUA – Pontos por caso de uso ajustados.
  • 16. 26. PCUNA – Pontos por caso de uso não ajustados. 27. PE - Pontos de Execução. 28. Pe - Peso do fluxo de exceção. 29. PF – Pontos de função. 30. Pi – Peso do tipo de teste. 31. Pn - Peso do fluxo normal. 32. PT – Pontos de teste. 33. Pt - Peso total do caso de teste. 34. Qd – Características de Qualidade Dinâmica. 35. Qi - Pontos de Teste Estáticos. 36. Qt - Qualificação da equipe de teste. 37. r - Erro relativo. 38. S - Número de passos de teste. 39. SE – Saída Externa. 40. SERPRO – Serviço Federal de Processamento de Dados. 41. TCP – Ponto por caso de teste. 42. TE - Tamanho da equipe de teste. 43. THT - Total de horas de teste. 44. TPf – Total de pontos de teste dinâmicos. 45. U – Uniformidade. 46. Ue – Importância do usuário. 47. UTCP – Pontos por caso de teste não ajustados. 48. UUCW - Pontos de caso de uso não ajustados. 49. Uy – Intensidade de uso. 50. WEa - Média Aritmética Ponderada.
  • 17. 17 1 -Introdução Este capítulo está dividido em cinco seções. A seção 1.1 apresenta a motivação para realização deste trabalho. A seção 1.2 descreve o problema a ser tratado nesta pesquisa. A seção 1.3 disserta sobre a hipótese levantada para a resolução do problema. A seção 1.4 mostra os objetivos e o escopo deste trabalho. Por fim, a seção 1.5 descreve a estrutura pela qual este trabalho está organizado. 1.1 -Motivação O maior desafio das chamadas Fábricas de Software é entregar um produto funcional, com qualidade e dentro de prazos pré-estabelecidos com os clientes. Entretanto, como pode ser observado no mercado, muitas fábricas de software ainda deixam de lado as atividades referentes ao controle e à garantia da qualidade, concentrando seus esforços apenas em atividades de construção do software. Este tipo de comportamento muitas vezes é impulsionado por orçamentos e prazos escassos. A disciplina de Teste de Software é uma dessas atividades frequentemente deixadas de lado, mas que, com o passar do tempo, tem se tornado independente e importante no escopo do desenvolvimento de software, exigindo assim planejamento e estimativas mais específicas, com o objetivo de melhorar a precisão das estimativas envolvendo esforço, custo e tempo que essa atividade costuma demandar. Atualmente não existe uma técnica-padrão para estimativa de esforço em projetos de teste de software. Existem, no entanto, muitas propostas com abordagens diferenciadas, mas que ainda não alcançaram a precisão esperada para realizar estimativa de forma confiável em qualquer contexto de desenvolvimento de software. 1.2 - Problema Este trabalho visa resolver a seguinte questão: como estimar esforço de projeto de teste de software?
  • 18. 18 1.3 -Hipótese Através de uma prova de conceito realizada sobre uma aplicação CRUD é possível caracterizar o nível de precisão das principais técnicas para estimativa de esforço em projetos de Teste de Software disponíveis. 1.4 - Objetivos e Escopo do Trabalho Caracterizar o nível de precisão das técnicas de estimativa de esforço em projetos de teste de software existentes. Tal objetivo pode ser subdividido nos seguintes objetivos específicos: Analisar as técnicas de estimativa de esforço em projetos de Teste de Software existentes no mercado e na literatura técnica; Demonstrar através de estudo experimental a precisão de algumas técnicas existentes; Avaliar os pontos fortes e fracos das técnicas. 1.5 -Organização do Trabalho Este trabalho está organizado em seis capítulos. O capítulo 1 mostrou a introdução do trabalho, ressaltando a sua motivação e seus objetivos. No capítulo 2 são apresentadas algumas métricas para estimativa de esforço em projetos de teste software. Já no capítulo 3 é apresentado um protocolo de quasi-Revisão Sistemática a respeito de técnicas de estimativa de esforço em projetos de teste de software existentes na literatura. No capítulo 4 é apresentado um survey realizado com profissionais de teste do Brasil e de alguns outros países sobre quais técnicas de estimativa costumam utilizar. No capítulo 5 é apresentado uma prova de conceito de algumas técnicas descritas no capítulo 2. No capítulo 6 são apresentadas as conclusões do projeto. Finalmente, é apresentada a lista de referências bibliográficas utilizadas.
  • 19. 19 2 - Métricas para Estimativa de Esforço em Projetos de Teste de Software Este capítulo está dividido em dez seções. A seção 2.1 apresenta um resumo sobre métricas de estimativa de esforço. A seção 2.2 descreve a técnica Análise de Pontos de Teste, a sessão 2.3 descreve a Estimativa a partir de Bases Históricas de Projetos de Teste, a sessão 2.4 descreve a Análise de Pontos por Caso de Teste, a sessão 2.5 descreve a Estimativa de Capers Jones, a sessão 2.6 descreve a Estimativa baseada na Regra 40-20-40, a sessão 2.7 descreve a Estimativa Método Ad-Hoc, a sessão 2.8 descreve a Estimativa por Pontos de Execução, a sessão 2.9 descreve a Estimativa baseada em Especificação de Requisito Funcional e Eficiência Acumulada e por fim, a sessão 2.10 descreve a Estimativa Método Ponderado de Nageswaran. 2.1 -Métricas para Estimativa de Esforço Seguindo o exemplo das estimativas realizadas nas fases do desenvolvimento de um Projeto de Software, também nos Projetos de Teste existem problemas quanto estimar da forma mais precisa possível o esforço, tempo e custo que será demandado para a realização dessa atividade. O Teste de Software é uma atividade que impacta todas as outras atividades do processo de desenvolvimento de software e que custa caro. Sendo estimado junto com as etapas de Iniciação, Elaboração e Construção, o teste não detinha a atenção devida e, consequentemente, ficava com prazo apertado. Existem no mercado e na literatura algumas técnicas específicas para estimar o esforço em Projetos de Teste que serão descritas nas seções a seguir. 2.2 -Análise de Pontos de Teste (APT) Conforme pode ser visto em Veenendaal e Dekkers (1999), a técnica é baseada na Análise de Pontos de Função (APF) e utiliza como base o tamanho da funcionalidade. É uma técnica que não cobre os testes de alto nível, sendo aplicada aos testes unitários e de integração. A Figura 1 apresenta uma visão geral da técnica.
  • 20. 20 Figura 1: Visão Geral da Técnica de Análise de Pontos de Teste (VEENENDAAL, 1999) Essa técnica é baseada em três elementos que determinam a medição, o tamanho do sistema a ser testado, a estratégia de teste e a produtividade. O volume de trabalho em pontos de teste (PT) é determinado pelo primeiro e segundo elementos. A estimativa em horas é resultado da multiplicação do número de pontos de teste pela produtividade. Conforme a fórmula abaixo, onde THT é o total de horas de teste, HTP são as horas primárias de teste e IPC são os índices de controle e planejamento. Para obter os pontos de teste (PT), devem-se calcular os pontos de teste dinâmicos (TPf) e estáticos (Qi). Os pontos de teste dinâmicos são baseados nas funcionalidades individuais do sistema medidas em pontos de função (PF). Baseiam-se também nas funções dependentes (Df) e na qualidade dos requisitos relacionados com as características de qualidade a serem testadas dinamicamente (Qd). As funções dependentes (Df) são aquelas que estão relacionadas com as funções medidas em PF, em cada uma dessas funções é necessário medir alguns fatores, são eles: Importância do usuário (Ue): o quanto aquela funcionalidade é importante para o usuário;
  • 21. 21 Intensidade de uso (Uy): utilização daquela função por intervalo de tempo; Interface (I): quantidade de arquivos utilizados ou atualizados por aquela função; Complexidade (C): quantidade de comandos de condição; Uniformidade (U): nível de reutilização do material de teste; Para cada um desses fatores existe um peso atribuído. Os pesos sobre a importância do usuário, a intensidade de uso das funções, a interface das funções e a complexidade estão representados, respectivamente na Tabela 1, Tabela 2, Tabela 3 e Tabela 4. Importância do Usuário Peso Descrição Baixa 3 A importância dessa função com relação às outras é baixa Normal 6 A importância dessa função com relação às outras é normal Alta 12 A importância dessa função com relação às outras é alta Tabela 1: Peso da importância das funcionalidades para o usuário. Intensidade de Uso Peso Descrição Baixa 2 A função é executada algumas vezes por dia/semana Normal 4 A função é executada muitas vezes por dia Alta 8 A função é usada continuamente ao longo do dia Tabela 2: Peso da intensidade de uso das funções. Interface Peso Descrição Baixa 2 O grau de interface associado com a função é baixa. Média 4 O grau de interface associado com a função é normal. Alta 8 O grau de interface associado com a função é alta. Tabela 3: Peso da interface das funções. Complexidade Peso Descrição
  • 22. 22 Baixa 3 A função não contem mais que 5 condições. Normal 6 A função contem entre 6 e 11 condições. Alta 12 A função contem mais que 11 condições. Tabela 4: Peso da complexidade das condições. Para a uniformidade, o valor varia entre 0,6 e 1, onde o limite inferior indica que o material de teste pode ser reutilizado e o limite superior indica o contrário. O valor total das funções dependentes é a soma dos fatores importância do usuário, intensidade de uso, interface e complexidade, divididos por 20, vezes a uniformidade, conforme a fórmula: As características de qualidade dinâmicas (Qd) se referem na forma em que a qualidade dos requisitos pode afetar a qualidade dos testes. Elas se dividem em características explícitas (CE) – funcionalidade, performance, segurança e aderência e características implícitas (CI) – utilizadas sempre que houver indicadores para as características explícitas; As características explícitas (CE) apresentam dois tipos de peso, um referente à sua importância no resultado do teste e outra de mensuração da própria característica. Quanto à mensuração própria de cada característica, tem-se: Funcionalidade – 0,75 Performance – 0,10 Segurança – 0,05 Aderência – 0,10 Para os pesos referentes à importância da qualidade dos requisitos para o resultado dos testes, a Tabela 5 os representa:
  • 23. 23 Peso Descrição 0 A qualidade dos requisitos não é importante para o resultado dos testes. 3 A qualidade dos requisitos não é importante, mas precisa ser considerada para o resultado dos testes. 4 A qualidade dos requisitos tem importância de nível médio para o resultado dos testes. 5 A qualidade dos requisitos é muito importante para o resultado dos testes. 6 A qualidade dos requisitos é extremamente importante para o resultado dos testes. Tabela 5: Peso das Características Explícitas. O cálculo do resultado das características explícitas é a soma dos pesos multiplicados pelo valor atribuído a cada característica. Já as características implícitas (CI) são calculadas através de quantas características explícitas tem indicador estabelecido vezes 0,02. Os pontos de teste dinâmicos (TPf) no total são a multiplicação dos pontos de função vezes as funções dependentes vezes as características de qualidade dinâmicas, ou seja: Os pontos de teste estáticos (Qi) levam em consideração se são utilizados checklists para avaliar as características dinâmicas, para cada um é adicionado 16. De posse desses dois valores, obtemos o número total de pontos de teste, que é o somatório dos pontos de teste dinâmicos das funções individuais acrescido dos PFs do sistema (o menor valor atribuído é 500), multiplicado pelos pontos de teste estáticos divididos por 500: As horas de teste primárias são baseadas na qualificação da equipe de teste e ambiente de testes (medido de acordo com características: ferramentas de teste, testes de precedência, documentação de teste, ambiente de desenvolvimento, ambiente de teste e testware). A qualificação da equipe de teste varia de 0,7 a 2, quanto mais experiente e qualificada, menor será esse valor. Já o ambiente de teste deve ser medido seguindo
  • 24. 24 algumas regras que seguem nas tabelas abaixo, a Tabela 6 sobre as ferramentas de teste, a Tabela 7 sobre os testes de precedência, a Tabela 8 sobre a documentação de teste, a Tabela 9 sobre o ambiente de desenvolvimento, a Tabela 10 sobre o ambiente de teste e a Tabela 11 sobre o testware: Peso Descrição 1 Existência de uma ferramenta de automação para especificação e execução dos testes. 2 Existência de uma ferramenta de automação para especificação ou execução dos testes. 4 Não existe ferramenta de automação de teste. Tabela 6: Ferramentas de Teste. Peso Descrição 2 Existência de um plano de teste onde a equipe está familiarizada com os casos de teste e os resultados dos testes 4 Existência de um plano para o teste precedente 8 Não existe um plano para o teste. Tabela 7: Testes de precedência. Peso Descrição 3 Durante o desenvolvimento do sistema são utilizados padrões de documentação e templates. Acontecem revisões periódicas na documentação. 6 Durante o desenvolvimento do sistema são utilizados padrões de documentação e templates. Não há verificação formal. 12 Não é utilizado nenhum padrão e nenhum template para confecção de documentos. Tabela 8: Documentação de Teste. Peso 2 Descrição Sistema desenvolvido em uma linguagem de 4ª geração, integrada a um sistema de gerenciamento de banco de dados.
  • 25. 25 4 Sistema desenvolvido com uma combinação de linguagens de 3ª e 4ª gerações. 8 Sistema desenvolvido em uma linguagem de 3ª geração. Tabela 9: Ambiente de Desenvolvimento. Peso Descrição 1 O ambiente de teste já foi usado inúmeras vezes. 2 O ambiente de teste é similar ao que já vinha sendo usado. 4 O ambiente de teste é completamente novo e experimental. Tabela 10: Ambiente de Teste. Peso Descrição 1 Existem materiais de teste que poderão ser reutilizados, como bases de teste, casos de teste, etc. 2 Existem apenas tabelas e bases de dados disponíveis para reutilização. 4 Não existe testware disponível. Tabela 11: Testware. Depois de atribuídos os pesos, o número de pontos de teste é multiplicado pelos fatores de ambiente e qualificação da equipe de teste. A fórmula das horas de teste primárias, sendo E = soma dos fatores de ambiente/21 é a seguinte: O total de horas de teste (THT) é baseado no índice de planejamento e controle (IPC), que leva em consideração o tamanho da equipe de teste (TE) e ferramentas de gerência de teste (FG). O tamanho da equipe de teste é dado pela Tabela 12:
  • 26. 26 Peso Descrição 3 Não mais que 4 pessoas. 6 Entre 5 e 10 pessoas. 12 Mais que 10 pessoas. Tabela 12: Tamanho da Equipe de Teste. As ferramentas de gerência de testes (FG) se referem às ferramentas que são utilizadas para a fase de testes e classificadas segundo a Tabela 13: Peso Descrição 2 São utilizadas ferramentas de registro de tempo, gerência de testes, de defeitos e de configuração. 4 Apenas uma das ferramentas citadas acima é utilizada. 8 Não é utilizada nenhuma ferramenta. Tabela 13: Ferramentas de Gerência de Teste. O cálculo do índice de planejamento e controle (IPC) é dado pela seguinte fórmula: O total de horas de teste (THT) é dado pela fórmula: . 2.3 -Estimativa a partir de Bases Históricas de Projetos de Teste É uma técnica baseada no histórico de projetos anteriores, sendo os requisitos do negócio, a base para estimativa. Para que essa técnica ofereça o máximo de precisão possível, é necessário que os dados históricos sejam registrados de forma organizada e metódica.
  • 27. 27 2.4 - Análise de Pontos por Caso de Teste Segundo Nguyen, Pham e Lam (2009), a Análise de Pontos por Caso de Teste é uma técnica que utiliza casos de teste como entrada para fornecer a estimativa do esforço a ser gasto para executar esses casos de testes, gerando a pontuação de casos de teste. Para técnica a complexidade dos casos de teste está baseada em quatro fatores: checkpoints, pré-condições, dados de teste e tipo do caso de teste. Esses elementos são divididos em dois grupos, os três primeiros determinam a grandeza do caso de teste e o último normaliza a complexidade dos diferentes tipos de teste existentes. O escopo desse método abrange os testes que são executados manualmente, como testes de aceite, não cobrindo testes que envolvem a utilização de scripts, como os testes unitários. Para calcular pontos de caso de teste (PCT), primeiro deve-se encontrar a complexidade de cada caso de teste, através dos ckeckpoints, que são os resultados esperados após a execução de um caso de teste. Para cada checkpoint temos 1 ponto. Todo caso de teste apresenta pré-condições para sua execução, que podem afetar no esforço empregado durante essa execução. Para atribuir a classificação, que é dada em níveis, referente às pré-condições, tem-se a Tabela 14: Nível de Complexidade Descrição Nenhum A pré-condição não é aplicável ou importante para executar o caso de teste. Ou, a pré-condição é apenas reutilizada a partir do caso de teste anterior para continuar o caso de teste atual. Baixo A condição para a execução do caso de teste está disponível, com algumas modificações simples requeridas. Ou, algumas simples configurações de passos são necessárias. Médio Alguma preparação explícita é necessária para executar o caso de teste. A condição para execução é disponível, com algumas alterações necessárias. Ou, algumas configurações adicionais de passos são necessárias. Alto Hardware pesado e / ou configurações de software são necessários para executar o caso de teste. Tabela 14: Descrição do Nível de Complexidade das Pré-condições (traduzido).
  • 28. 28 O próximo passo é atribuir a classificação referente aos dados que são necessários para execução dos casos de teste, que podem ser gerados no momento da execução ou ser reaproveitados de outros casos de teste. A Tabela 15 apresenta a classificação referente aos dados de teste. Nível de Complexidade Descrição Nenhum Nenhuma preparação de dados de teste é necessária. Baixo Simples dados são necessários e podem ser criados durante o tempo de execução do caso de teste. Ou, no caso de teste usa uma versão ligeiramente modificada de dados de teste existentes e requer pouco ou nenhum esforço para modificar os dados de teste. Médio Os dados de teste são deliberadamente preparados com antecedência com um esforço extra para garantir a sua integridade, integralidade e consistência. Alto Os dados de teste são preparados com antecedência com um esforço considerável para garantir a sua integridade, integralidade e consistência. Isso poderia incluir o uso de ferramentas de apoio para gerar dados e um banco de dados para armazenar e gerenciar dados de teste. Scripts podem ser necessários para gerar dados de teste. Tabela 15: Descrição do Nível de Complexidade dos Dados de Teste (traduzido). Para cada um desses níveis de complexidade descritos nas tabelas acima, existe um número de pontos de caso de teste relacionados, segundo a Tabela 16. Nível de Complexidade Número de TCP por précondição Número de TCP por dados Nenhum 0 0 Baixo 1 1 Médio 3 3 Alto 5 6 Tabela 16: Pesos das pré-condições e dados de teste segundo a complexidade (traduzido). Somando-se os pontos referentes aos checkpoints, as pré-condições e os dados de teste, encontra-se os pontos por caso de teste não ajustados (PCTNA).
  • 29. 29 Como os diferentes tipos de teste apresentam complexidades diferentes, a técnica apresenta um fator de ajuste a partir desses tipos. A fórmula para se encontrar os pontos por caso de teste ajustados (PCTA) é a seguinte: Nessa fórmula, os pontos por caso de teste não ajustados vezes o peso referente ao tipo de teste, retorna os pontos por caso de teste ajustados para um caso de teste. A Tabela 17 mostra os pesos referentes ao tipo de teste. Tipo de teste Descrição Peso Interface de usuário e testes funcionais Interface de usuário e testes funcionais é considerada de referência. 1 API API de teste verifica a exatidão das interfaces na prestação de serviços 1,22 Banco de Dados Testar a precisão de scripts de banco de dados, integridade de dados e / ou migração de dados. 1,36 Segurança Testando o quão bem o sistema lida com ataques de hackers, não autorizadas e acessos não autenticados. 1,39 Instalação Teste de completo, parcial, atualização ou instalar / 1,09 desinstalar processos de software. Rede Testando as comunicações entre as entidades através de redes. 1,27 Algoritmo e computação Verificando algoritmos e cálculos projetados e implementados no sistema. 1,38 Teste de Usabilidade Testando a simpatia, facilidade de uso, e os atributos de usabilidade outros do sistema. 1,12 Desempenho (manual) Verificar se o sistema atende aos requisitos de desempenho, assumindo que o teste é feito manualmente. 1,12 Performance (manual) Verificar se o sistema atende aos requisitos de desempenho, assumindo que o teste é feito manualmente. 1,33 Teste de Recuperação Teste de recuperação verifica a precisão do processo de recuperação para se recuperar de falhas no sistema e outros erros. 1,07 Compatibilidade Testando se o software é compatível com outros elementos de um sistema com o qual ele deve 1,01
  • 30. 30 operar, por exemplo, navegadores, sistemas operacionais ou hardware. Tabela 17: Pesos dos Tipos de Teste (traduzido). Depois de encontrado o valor total dos pontos por caso de teste, é utilizada uma estimativa baseada na experiência dos testadores para descobrir quanto minutos um testador leva para executar um ponto de caso de teste e, assim, atribuir a estimativa para os demais casos de teste de um projeto. 2.5 -Estimativa de Capers Jones Segundo Lopes e Nelson (2008) é uma estimativa que se utiliza de uma fórmula para estimar os casos de teste a partir dos pontos de função, tendo assim, sua precisão variável de acordo com a precisão dos pontos de função. 2.6 -Estimativa baseada na Regra 40-20-40 Segundo Lopes e Nelson (2008) é uma regra bem simples, baseada numa constante que determina 40 % de esforço para análise e projeto, 20% para codificação e os outros 40% para teste, se aproximando muito da realidade dos projetos, porém essa técnica não leva em conta fatores como cobertura e complexidade. 2.7 -Estimativa Método Ad-Hoc Ad-hoc, expressão latina, tem tradução literal por “para isto” ou “para esta finalidade”. Nessa técnica de medição, o gestor define um tempo sobre o qual o teste será executado. 2.8 -Estimativa por Pontos de Execução Conforme é demonstrado em Aranha e Borba (2007), o principal objetivo dessa técnica de estimativa é que ela possa ser aplicada a qualquer conjunto de testes funcionais.
  • 31. 31 A entrada do modelo é uma suíte de testes e a saída uma estimativa em homens/hora para que essa suíte possa ser executada. Considera-se que as especificações dos casos de teste estão escritas de forma padronizada. Na Figura 2 é apresentada a visão geral da técnica: Figura 2: Visão Geral do Modelo de Estimativa de Pontos de Execução (ARANHA, 2007). Conforme especificado na figura do modelo, a técnica consiste em analisar cada caso de teste da suíte, atribuindo um valor em pontos de execução (PE), para depois somá-los obtendo os pontos de execução totais daquela suíte, que é o esforço para executá-la e transformá-los em homens/hora. Cada passo de um caso de teste deve ser analisado individualmente como demonstrado na Figura 3.
  • 32. 32 Figura 3: Atribuindo os pontos de execução para cada passo do caso de teste (ARANHA, 2007). Cada um dos passos é analisado comparando-se com uma lista de características relevantes que podem impactar no tamanho e na complexidade de execução do mesmo. O impacto é avaliado usando uma escala de baixo, médio e alto. Feito isto, são atribuídos pontos de execução para cada característica, a soma dos pontos de execução de todas as características retorna o total de pontos de execução daquele passo de teste, consequentemente a soma de todos os passos retorna o total de pontos de execução daquele caso de teste. A técnica sugere que a lista de características assim como os níveis de influência e pesos devem ser avaliados através de estudos empíricos para garantir a precisão do resultado final. Depois de ter os pontos de execução basta encontrar o esforço em homens/hora.
  • 33. 33 Figura 4: Estimativa do esforço em homens/hora (ARANHA, 2007). Como pode ser visto na Figura 4, dados históricos são utilizados para encontrar um fator de conversão (CF) que é o somatório do esforço das suítes dividido pelo somatório dos pontos de execução, retornando quanto tempo é gasto para testar um ponto de execução. Em seguida, multiplica-se o fator de conversão pelos pontos de execução da suíte que se deseja estimar. 2.9 -Estimativa baseada em Especificação de Requisito Funcional e Eficiência Acumulada É uma técnica que estima o esforço para execução de testes funcionais, especialmente para pequenas equipes de teste, sem automação e pouca documentação, conforme pode ser visto em Guerreiro e Abreu (2009). Cobre, portanto, apenas a execução manual de teste. Para chegar a essa técnica foram usados dados de Base Histórica da execução de testes de uma equipe ao longo de alguns anos. Essa medição utiliza o conceito de eficiência acumulada, onde quanto mais o testador é familiarizado com o sistema, menos tempo ele leva para executar os casos de teste. A execução dos casos de teste é divida em Ciclos de Execução (CETs), é possível que quanto mais tempo dure o ciclo, mais a equipe de teste fica eficiente. O procedimento de estimativa leva em consideração essa premissa, de que o esforço gasto na primeira CET pode ser utilizado para estimar o esforço das CETs posteriores.
  • 34. 34 No primeiro ciclo de execução, é feito um registro da média de passos de teste executados por minuto em cada dia do ciclo e do número de casos de teste executados naquele ciclo (Ntc). No final desse primeiro ciclo, deve-se calcular a média aritmética de esforço do ciclo, que é o somatório do esforço de todos os dias da CET, dividido pelo número de dias total, segundo a fórmula: Essa fórmula retorna o número médio de passos por minuto daquela CET. Também deve ser calculado o erro médio, conforme pode ser visto em Triola (2011), em passos/minuto. Em seguida deve-se obter a média aritmética ponderada (WEa) e a média da raíz quadrada do erro médio (Erms), considerando que essa é a primeira iteração da técnica, esses dois valores são semelhantes à média aritmética e ao erro médio, respectivamente. O próximo passo é calcular o erro relativo (r), que serve como um complemento ao esforço final, prevendo um pouco mais de tempo para evitar problemas. O erro relativo tem a fórmula: Deve-se ter disponível nesse passo, uma estimativa de números de passos de teste a ser executados na próxima CET, que é chamado de S. O esforço final a ser empregado na próxima CET é dado pela seguinte fórmula, gerando uma medição em minutos: É importante observar que nas próximas iterações da técnica a WEa e o Erms devem ser calculados considerando os valores anteriores. A WEa é o somatório dos passos/minuto das interações anteriores vezes o número de casos de teste e dividido pela soma dos números de casos de teste, conforme a fórmula:
  • 35. 35 Já o Erms é dado pela seguinte fórmula, sendo n o número de CETs até o momento: O conhecimento prévio do número de casos de teste a ser executado é de extrema importância. A técnica não possui um comportamento regular caso existam mudanças significativas nos times de teste entre as CETs, ou mesmo mudanças de características e tipo de software. 2.10 -Estimativa Método Ponderado de Nageswaran É uma técnica de estimativa baseada em casos de uso, que pode ser calculada no início do ciclo de vida, assim que os casos de uso estiverem prontos. Segundo Almeida, Abreu e Moraes (2009), um cenário de fluxo normal leva mais tempo para ser executado que um fluxo de exceção. O peso do caso de uso varia de acordo com a quantidade de cenários, a partir de dados históricos, obteve-se que o tempo para projetar e implementar um cenário normal é 2,5 vezes maior do que um cenário de exceção (peso normal = 1; peso exceção=0,4). O primeiro passo é identificar os atores do caso de uso e atribuir um peso conforme segue na Tabela 18: Tipo de ator Descrição Peso Simples Interação com o sistema através de interface gráfica. 1 Médio Gerenciamento de dados e protocolos 2 Complexo APIs ou interações de baixo-nível 3 Tabela 18: Pesos dos Tipos de Atores (traduzido). Cada caso de uso possui cenários de validação e exceção, para obter o peso do caso de uso, deve-se multiplicar a quantidade de cenários de validação por 1 mais a quantidade de cenários de exceção multiplicados por 0,4, conforme a fórmula: Os pontos de caso de uso não ajustados (PCUNA) são a soma do peso dos atores e o peso do caso de uso.
  • 36. 36 O ajuste dos pontos de caso de uso se dá pela inclusão de fatores de ambiente, que são relevantes para o escopo do caso de uso medido, como ferramentas, ambiente de desenvolvimento, ambiente de teste, reutilização do testware e características de segurança. Obtemos primeiro o FTA (fatores técnicos do ambiente) através do somatório de todos os fatores que influenciam o teste, multiplicando por 0 se o fator não está disponível ou 5 se está disponível, com o peso da sua importância conforme é dado pela Tabela 19: Nomenclatura Descrição Peso Inócuo Não deve ser levado em conta nos testes 0 Dispensável Não é importante ter esse fator 1 Desejável Os testes seriam melhores se esse fator estivesse disponível 2 Necessário É importante ter esse fator 3 Essencial É primordial para o teste 4 Tabela 19: Classificação dos fatores de ambiente (traduzido). Finalmente os pontos por caso de uso ajustados (PCUA) são conseguidos através da seguinte fórmula: O esforço final é calculado, baseado em fatores históricos, assumindo que 3 horas são necessárias para planejar, escrever e executar 1 ponto de caso de uso, é o fator de conversão que assume que o processo de teste é automatizado e controlado, do contrário, o fator assumido deve ser 7,5. A fórmula do esforço a seguinte: A técnica sugere que sejam incluídos mais 5% pela complexidade do projeto e 5% para o gerenciamento do projeto, ou seja, mais 10% do esforço encontrado.
  • 37. 37 3 -Protocolo de quasi-Revisão Sistemática Este capítulo está dividido em oito seções. A seção 3.1 descreve o cenário de investigação principal do protocolo de quasi-Revisão Sistemática. A seção 3.2 apresenta o protocolo de busca e está dividida nas subseções 3.2.1 que descreve o foco de interesse e 3.2.2 apresenta qualidade e amplitude da questão. A seção 3.3 trata da seleção de fontes e está dividida nas subseções 3.3.1 que descreve a definição de critérios para seleção de fontes, 3.3.2 que apresenta o idioma das fontes e 3.3.3 que traz a identificação das fontes. A seção 3.4 cuida da seleção dos estudos e está dividida na subseção 3.4.1 responsável pela definição dos estudos. A seção 3.5 apresenta os resultados da pré-execução, a seção 3.6 trata da estratégia para extração da informação, a seção 3.7 traz os critérios para avaliação da qualidade dos artigos e por fim, a seção 3.8 representa a execução. 3.1 -Cenário de Investigação Principal Atualmente no mercado não há técnicas de estimativa de esforço adotadas como padrão para teste de software, existem muitas pesquisas e literaturas com abordagens diferenciadas, mas que ainda não alcançaram a precisão esperada para realizar estimativa de forma confiável. Existe ainda uma diferença entre estimar o esforço apenas para execução dos casos de teste e para toda a fase de teste (planejamento, construção dos casos de teste, execução dos casos de teste). A maioria dos profissionais em teste de software utilizam uma base histórica ou a experiência do testador para estimar o esforço na execução de casos de teste. Esse tipo de estimativa depende de muitos fatores subjetivos. Por exemplo, uma base histórica pode ter outliers, ou seja, valores que se distanciam muito da realidade. Um caso de teste pode ser executado em mais ou menos tempo dependendo do conhecimento do testador sobre aquele caso de teste. Outro exemplo seria a forma de armazenamento dessas informações, um testador pode estar passando mal em determinado dia e levar mais tempo para realizar uma tarefa do que levaria se estivesse bem disposto, e se estes dados forem utilizados para realizar estimativas, é provável que o resultado não seja confiável.
  • 38. 38 Essas variações podem afetar o resultado da estimativa e causar problemas de cronograma e alocação de recursos. Por esse motivo, existem técnicas sendo avaliadas e melhoradas para proporcionar uma estimativa mais objetiva. Para ter um gerenciamento mais eficiente da etapa de teste de software é necessário estimar o quanto de esforço deverá ser empregado. 3.2 -Protocolo de Busca O protocolo de revisão sistemática inicial é baseado em Biolchini et al., 2005. É utilizada a abordagem PICO (Pai et al., 2004) para estruturar e organizar a string de busca. Esta abordagem separa a questão em quatro partes: População (Population), Intervenção (Intervention), Comparação (Comparison) e Saída (Outcome). Devido ao objetivo do estudo não é possível aplicar nenhuma comparação. Portanto, é possível classificar esta revisão como quasi-revisão sistemática (Travassos et al, 2008). 3.2.1 -Foco de Interesse O objetivo deste estudo é caracterizar as técnicas de estimativa de esforço em projetos de teste de software utilizadas em projetos de desenvolvimento e disponíveis na literatura técnica. 3.2.2 -Qualidade e Amplitude da Questão - Problema: dada a importância do teste de software no escopo de desenvolvimento, é imprescindível saber estimar o esforço que será gasto nessa etapa para alocar corretamente os recursos necessários e não ter problemas futuros em orçamento e pessoal, fato que muitas vezes é responsável por produtos sendo colocados em produção sem terem sido testados devidamente por conta de prazos. - Questões: Questão Principal: Quais técnicas de estimativa de esforço em projetos de teste de software têm sido descritas na literatura técnica? Quais são suas principais características? Questão Secundária: Quais são suas principais características?
  • 39. 39 - Criação String de busca: As palavras chave que compõem a string de busca foram baseada nos artigos de controle encontrados através de uma busca ad-hoc. Estes artigos foram importantes para entender os termos utilizados pelos autores e forneceram um parâmetro para a criação da string de busca. Ao realizar a extração das palavras chaves dos artigos de controle pôde-se perceber que alguns artigos estavam indexados de forma inconsistente nas máquinas de busca, pois as palavras chaves impressas no artigo não correspondiam com as palavras chaves indexadas pelas máquinas de busca. Portanto, foi realizado um trabalho no sentido de extrair as palavras chaves pelas quais as máquinas de busca estavam indexando os artigos. Os seguintes artigos de controle foram utilizados: Zhu, Xiaochun, et al., Estimate Test Execution Effort at an early Stage: An Empirical Study, IEEE Journal, Cyberworlds, 2008 International Conference on, 2008. Aranha, E., Borba, P., Test Effort Estimation Models Based on Test Specifications, IEEE Journal on Selected Areas in Communications, Testing: Academic and Industrial Conference Practice and Research Techniques MUTATION, 2007. TAICPART-MUTATION 2007, 2007. de Almeida, E.R.C., de Abreu, B.T., Moraes, R., An Alternative Approach to Test Effort Estimation Based on Use Cases, IEEE Journal, Software Testing Verification and Validation, 2009. ICST '09. International Conference on, 2009. Silva, D., de Abreu, B.T., Jino, M., A Simple Approach for Estimation of Execution Effort of Functional Test Cases, IEEE Journal , Software Testing Verification and Validation, 2009. ICST '09. International Conference on, 2009. - População: Projetos e processos de software Palavras Chave: o software application, software development, software project, software product, software process, software system, software measurement, software approach, software management, software metrics; - Intervenção: Questão Principal: Teste de software
  • 40. 40 Palavras Chave o software testing, testing requirements, testing process, program testing, reliability requirements, testing the software, testing procedure, application testing, system testing, program testing;; - Comparação: Nenhuma - Saída: Estimativas de esforço para projetos de teste de software. Palavras Chave: o test effort estimation, estimating software testing efforts, test estimation effort techniques, test execution effort estimation, estimation of software testing efforts, test automation effort estimation, test execution effort estimation models, estimating test effort, execution effort of a test, estimate the required effort to test, estimate the effort to execute the tests, test effort metrics; - Efeito: Identificar estimativas de esforço para projetos de teste de software. - Aplicação: Tornar a estimativa de esforço em projetos de teste de software mais eficiente. - Projeto Experimental: Nenhum método estatístico será aplicado. 3.3 -Seleção de Fontes 3.3.1 -Definição de Critérios para seleção de fontes Artigos disponíveis na web através de máquinas de busca que permitam a pesquisa de strings no abstract, título e palavra chave. 3.3.2 -Idioma das fontes Inglês. 3.3.3 -Identificação das Fontes - Método de pesquisa das fontes: busca no abstract, título e palavras chaves através das máquinas de busca disponíveis.
  • 41. 41 String de busca: ("software application" OR "software development" OR "software project" OR "software product" OR "software process" OR "software system" OR "software measurement" OR "software approach" OR “software management” OR “software metrics”) AND ("software testing" OR "testing requirements" OR "testing process" OR "program testing" OR "reliability requirements" OR "testing ate software" OR "testing procedure" OR "application testing" OR "system testing" OR "program testing") AND ("best effort estimation" OR "estimating software testing efforts" OR "best effort estimation techniques" OR "test execution effort estimation" OR "estimation of software testing efforts" OR "test automation effort estimation" OR "test execution effort estimation models" OR "estimating best effort" OR "execution effort of e test" OR "estimate time required effort to test" OR "estimate the effort to execute the tests" OR “test effort metrics”) - Máquinas de busca: Nome Link Scopus http://www.scopus.com/ IeeeXplore http://ieeexplore.ieee.org/ Tabela 20: Máquinas de busca utilizadas no protocolo de quasi-Revisão Sistemática. String de busca Scopus: TITLE-ABS-KEY("software application" OR "software development" OR "software project" OR "software product" OR "software process" OR "software system" OR "software measurement" OR "software approach" OR “software management” OR “software metrics”) AND ("software testing" OR "testing requirements" OR "testing process" OR "program testing" OR "reliability requirements" OR "testing ate software" OR "testing procedure" OR "application testing" OR "system testing" OR "program testing") AND ("best effort estimation" OR "estimating software testing efforts" OR "best effort estimation techniques" OR "test execution effort estimation" OR "estimation of software testing efforts" OR "test automation effort estimation" OR "test execution effort estimation models" OR "estimating best effort" OR "execution effort of e test" OR "estimate time
  • 42. 42 required effort to test" OR "estimate the effort to execute the tests" OR “test effort metrics”) String de busca IEEE: ("software application" OR "software development" OR "software project" OR "software product" OR "software process" OR "software system" OR "software measurement" OR "software approach" OR “software management” OR “software metrics”) AND ("software testing" OR "testing requirements" OR "testing process" OR "program testing" OR "reliability requirements" OR "testing ate software" OR "testing procedure" OR "application testing" OR "system testing" OR "program testing") AND ("best effort estimation" OR "estimating software testing efforts" OR "best effort estimation techniques" OR "test execution effort estimation" OR "estimation of software testing efforts" OR "test automation effort estimation" OR "test execution effort estimation models" OR "estimating best effort" OR "execution effort of e test" OR "estimate time required effort to test" OR "estimate the effort to execute the tests" OR “test effort metrics”) 3.4 -Seleção dos Estudos 3.4.1 -Definição dos estudos - Definição dos critérios de inclusão e exclusão: Critérios de inclusão: o Tratar de testes de software; e o Descrever técnicas de estimativa de esforço para testes de software; e o Apresentar alguma demonstração (estudos de caso ou experimentos) para as técnicas de estimativa de esforço propostas; e o Apresentar referência bibliográfica que caracterize o critério apresentado caso não seja de autoria. Critérios de exclusão: o Artigos que não tratam de técnicas de estimativa de esforço para testes de software; ou o Artigos que não estejam disponíveis por meio digital; ou
  • 43. 43 o Artigos publicados em idiomas diferentes do inglês; - Procedimento para seleção de artigos A seleção dos artigos será realizada por dois pesquisadores: Pesquisador A e Pesquisador B (grande experiência). O Pesquisador A realizará a leitura do título e abstract de todos os documentos retornados pelas máquinas de busca. Os artigos serão classificados com os seguintes status: o Incluído: documentos que tratam de alguma forma de técnicas de estimativa de esforço em projetos de teste de software; o Excluído: documentos que não tratam de técnicas de estimativa de esforço em projetos de teste de software; o Dúvida: documentos em que o pesquisador teve dúvida se tratam de alguma forma de técnicas de estimativa de esforço em projetos de teste de software; O Pesquisador B irá realizar a leitura do título e abstract dos documentos que foram classificados com o status Dúvida e irá reclassificar estes documentos como Incluído ou Excluído; O Pesquisador A realiza a leitura de todos os documentos classificados como Incluídos e os classifica como: o Incluído: documentos que atendam os critérios de inclusão e não atendam aos critérios de exclusão. Esses artigos vão ter suas informações extraídas; o Excluído: documentos que não atendam os critérios de inclusão ou que atendam aos critérios de exclusão; O mesmo processo pode ser representado pelo seguinte diagrama, Figura 5:
  • 44. 44 Figura 5: Diagrama do processo do protocolo de quasi-Revisão Sistemática 3.5 -Resultados da pré-execução A Tabela 21 mostra os resultados da pré-execução. Máquina de Busca Número de artigos encontrados Controles Scopus 14 2 IeeeXplore 478 4 Total Bruto 492 - Duplicados 8 - Total 484 4 Tabela 21: Tabela com os resultados da pré-execução do protocolo de quasi-Revisão Sistemática.
  • 45. 45 3.6 -Estratégia para Extração da Informação Para cada artigo selecionado as informações contidas no Apêndice I – Modelo de Formulário de Extração devem ser extraídas com a ajuda da ferramenta JabRef Reference Manager. 3.7 -Critérios para Avaliação da Qualidade dos Artigos Os critérios a seguir serão utilizados para avaliar a qualidade dos artigos selecionados. O objetivo é identificar os artigos que possuem uma relação maior com o tema que está sendo investigado e, com isto, terão maior confiabilidade no resultado final. A. O artigo apresenta alguma prova de conceito? (1 pt) B. O artigo caracteriza o software em que o critério pode ser aplicado? (2 pt) C. O artigo utiliza metodologia e linguagem que facilita o entendimento (2 pt) D. O artigo utiliza terminologia adequada? (1 pt) 3.8 -Execução Data de Execução: 14/10/2011 Após o primeiro pesquisador avaliar os artigos seguindo os critérios de inclusão e exclusão o resultado obtido foi o demonstrado na Tabela 22: Status Quantidade Incluído 9 Dúvidas 7 Excluídos 464 Controles 4 Total 484 Tabela 22: Tabela com os resultados da execução do protocolo de quasi-Revisão Sistemática pelo primeiro pesquisador.
  • 46. 46 Como houve 7 artigos classificados com o status Dúvida um segundo pesquisador foi envolvido. Após a avaliação do segundo pesquisador o seguinte resultado foi obtido, Tabela 23: Status Quantidade Incluídos 15 Excluídos 465 Controles 4 Total 484 Tabela 23: Tabela com os resultados da execução do protocolo de quasi-Revisão Sistemática pelo segundo pesquisador. Ao longo da do processo de leitura dos artigos, alguns artigos foram desconsiderados, pois não atendiam aos critérios de inclusão/exclusão. O resultado final é representado na Tabela 24. Status Quantidade Leitura+Controle 19 Duplicado 5 Total 14 Tabela 24: Tabela com os resultados da execução do protocolo de quasi-Revisão Sistemática. Uma divisão por ano dos artigos que foram incluídos também foi realizada para verificar em que período houve mais interesse em pesquisa por estimativa de esforço em projetos de testes de software. A Figura 6 representa o resultado encontrado:
  • 47. 47 Figura 6: Gráfico dos períodos em que os artigos foram publicados Em cada um dos artigos encontrados, pelo menos uma métrica era proposta. Foram encontradas 15 métricas de estimativa de esforço para teste de software. Em alguns casos, algumas métricas propostas eram variações de outras. Por exemplo, Método de Nageswaran e Método Ponderado de Nageswaran cuja diferença está no tratamento dado aos fluxos do caso de uso, onde os fluxos normais tem um peso maior que os fluxos de exceção. Neste caso, foram consideradas 2 variações do critério. Assim, foram encontradas um total de 4 variações. Portanto, caso as variações sejam consideradas, podese dizer que foram encontradas 19 maneiras diferentes para estimar esforço para teste de software. No Apêndice II se encontram os artigos provenientes da quasi-Revisão Sistemática e se respectivo status, Incluído ou Excluído.
  • 48. 48 4 -Survey Este capítulo está dividido em três seções. A seção 4.1 trata da definição de survey. A seção 4.2 apresenta os questionários utilizados nesse survey. Já a seção 4.3 trata dos resultados encontrados. 4.1 -Definição de Survey Um survey, segundo Mafra e Travassos (2006), é “uma investigação usada em retrospecto”, ou seja, uma pesquisa realizada após determinada tecnologia ser utilizada para avaliar seus resultados, ou como dizem os próprios autores, o survey permite capturar um “retrato instantâneo” da situação. Para esse projeto, foi realizado um survey para saber como os profissionais de teste estimam o tempo a ser gasto com testes em um projeto. 4.2 -Questionários Em um primeiro momento foi feito um questionário, conforme a Figura 7, em português e lançado no Grupo DFTeste do Yahoo Grupos. Figura 7: Questionário em português
  • 49. 49 O questionário, basicamente, pergunta se a empresa estima esforço de teste e qual métrica utiliza para isso. Esse questionário teve 48 respostas de profissionais do Brasil, entre 26 de junho e 15 de outubro de 2012. Outro questionário em inglês foi elaborado e divulgado nos grupos de Teste do Linkedin, visando abranger mais profissionais e em diferentes países, Figura 8. Figura 8: Questionário em inglês A única diferença entre eles foi a inclusão da pergunta para identificar o país. Esse questionário teve 52 respostas entre 15 de agosto de 2012 e 24 de outubro de 2012. 4.3 -Resultados Tabulando os dados da pesquisa realizada no grupo de testes DFTeste com profissionais brasileiros, chegou-se a conclusão de que, nessa amostra de 48 testadores, aproximadamente 69% estimam esforço para teste de software, sendo a divisão por métricas a seguinte: 57,58 % utilizam a experiência do testador; 24,24 % utilizam dados históricos;
  • 50. 50 9,09 % utilizam outra métrica; 3,03 % utilizam Análise por pontos de teste; 6,06 % utilizam Pontos de Execução; 0,00 % utilizam Pontos por Caso de Teste conforme pode ser visto na Figura 9. Figura 9: Porcentagem de utilização das métricas (no Brasil) Dos profissionais que responderam utilizar outro tipo de técnica, foram citadas: 50% do tempo utilizado para fazer a matriz de regras (começamos agora, é um chute). Depois iremos utilizar base histórica; Baseada na complexidade do caso de uso; Quanto aos resultados da pesquisa em inglês realizada nos grupos de teste do Linkedin, foi chegada à conclusão que, dessa amostra de dados, de 52 testadores, aproximadamente 84% estimam esforço. Desses, a distribuição entre as técnicas é a seguinte: 53,49% utilizam a experiência do testador; 25,58% utilizam dados históricos; 9,30% utilizam Pontos por Caso de Teste; 4,65% utilizam Pontos de Execução; 4.65% utilizam Análise por pontos de teste 2,33% utilizam outra métrica, conforme pode ser visto na Figura 10.
  • 51. 51 Figura 10: Porcentagem de utilização das métricas (outras partes do mundo) Na Figura 12 pode-se obervar os resultados encontrados no mundo, incluindo o Brasil. Figura 11: Porcentagem de utilização das métricas (Brasil e outras partes do mundo) Dos profissionais que responderam utilizar outro tipo de técnica, foi citada a técnica WBS por um profissional da Índia.
  • 52. 52 Outros resultados importantes também foram: a quantidade de pessoas que estima teste por país, conforme a Figura 12 e as técnicas utilizadas por país também, conforme a Figura 13, todos os resultados baseados nessa amostra. Figura 12: Empresas que estimam esforço para teste por país Figura 13: Técnicas utilizadas por país Pode-se observar que grande parte da amostra estima esforço para disciplina de teste de software utilizando, principalmente, a experiência do testador e a base histórica de dados da empresa.
  • 53. 53 A justificativa dos profissionais que responderam esse survey para o fato de que as métricas de estimativa ainda são pouco utilizadas reside na dificuldade de se obter todas as variáveis e pela complexidade de aplicação das mesmas.
  • 54. 54 5 -Prova de Conceito Este capítulo está dividido em quatro seções. A seção 5.1 descreve as informações do Sistema utilizado na prova de conceito. A seção 5.2 apresenta as técnicas que realizam estimativas para todo o projeto de teste e está dividida nas subseções 5.2.1, Análise por Pontos de Teste e 5.2.3, Estimativa Método Ponderado de Nageswaran. A seção 5.3 trata das Estimativas de Esforço Parcial do Projeto de Teste e está dividida nas subseções 5.3.1, Análise de Pontos por Caso de Teste (TCP) e 5.3.2, Estimativa baseada em Especificação de Requisito Funcional e Eficiência Acumulada. Por último, a seção 5.4 traz as conclusões da aplicação de cada técnica nessa prova de conceito. 5.1 -Informações da Prova de Conceito Algumas técnicas foram aplicadas utilizando um domínio de um Sistema Escola. A Figura 14 representa os casos de uso desse domínio. No Apêndice III têm-se as Regras de Negócio do domínio, no Apêndice VI a Descrição dos Casos de Uso Efetuar Login e Manter Alunos, no Apêndice V os Casos de Teste derivados desses casos de uso, no Apêndice VI as Evidências de execução dos testes realizados com sucesso e no Apêndice VII os testes que falharam. Figura 14: Casos de Uso Sistema Escola A prova de conceito foi realizada em cima de um domínio CRUD de um sistema Escola que possui os casos de uso Efetuar Login e Manter Alunos.
  • 55. 55 A fins de comparar o resultado gasto para testar esse domínio, efetivamente, e o valor que cada estimativa fornece, toda a fase de teste foi realizada e o tempo registrado, como segue na Tabela 25: Tarefa Tempo gasto (minutos) Plano de Testes 30 Elaborar Casos de Teste 50 Executar os Casos de Teste 20 Reportar os erros/Gerar evidências 30 Elaborar Relatórios sucesso/erro 23 Total 153 Tabela 25: Tempo gasto para realizar cada atividade de Teste. Foram gastos 153 minutos que equivalem a 2 horas e 30 minutos de 1 analista de teste para executar todos os processos que envolvem a fase de teste, ou seja 2,5 homens/hora. Algumas técnicas, como a estimativa a partir de Bases Históricas, Ad-Hoc e Pontos de Execução não foram aplicadas porque dependem de um conhecimento prévio das médias históricas de execução de casos de teste de uma equipe, informações que não se econtram disponíveis nesse experimento. As estimativas foram divididas entre aquelas que estimam o esforço total do projeto de teste, desde a fase de planejamento até o report de erros, e as que estimam apenas o esforço de execução de casos de teste.
  • 56. 56 5.2 -Estimativas de Esforço Total do Projeto de Teste 5.2.1 -Análise de Pontos de Teste Para simular a medição em pontos de teste, em primeiro lugar, o domínio Sistema Escola foi medido em pontos de função, conforme pode ser observado na Tabela 26. # Processo Elementar ou Grupo de Dados Tipo 1 Arquivo Aluno 2 Depois da Melhoria TD AR/TR Complex. PF ALI 9 1 Baixa 7 Inserir EE 13 1 Baixa 3 3 Alterar EE 5 1 Baixa 3 4 Excluir EE 1 1 Baixa 3 5 Listar CE 7 1 Baixa 3 6 Logar EE 3 1 Baixa 3 7 Desconectar EE 1 1 Baixa 3 8 Total 25 Tabela 26: Estimativa do Domínio Sistema Escola em Pontos de Função. Nesse caso o tipo de contagem é um Projeto de Desenvolvimento cujo escopo abrange as funcionalidades de Logar e Deslogar, do caso de uso Efetuar Login; e Inserir, Alterar, Excluir e Listar um aluno, do caso de uso Manter Alunos. Para aplicação dessa abordagem foram utilizados 3 meios de cálculo. Um utilizando uma planilha montada a partir da técnica descrita em Veenendaal e Dekkers (1999), outra utilizando uma planilha gerada pelo Serviço Federal de Processamento de Dados (SERPRO) e a ferramenta APT disponibilizada pela Comunidade de Testadores. As características comuns utilizadas foram as seguintes, a equipe de teste é muito experiente, não existe ferramenta de automação para especificação e execução dos testes, a
  • 57. 57 equipe está familiarizada com os testes, são seguidos padrões e templates e realizadas revisões, as linguagens utilizadas são de 3ª e 4ª gerações, o ambiente de teste já foi utilizado inúmeras vezes e existem materiais de teste que podem ser reutilizados. A equipe de teste possui 1 técnico e não são utilizadas ferramentas de registro de tempo, gerência de testes, gerência de defeitos e de configuração. Na Figura 15 têm-se as características de cada função específica. Figura 15: Características de cada função do Domínio Sistema Escola. A medição realizada pela planilha que utiliza a descrição da técnica original encontrou 3 horas e 32minutos para preparação, especificação, execução e conclusão dos testes, conforme pode ser visto no Apêndice VIII, sendo que esse tempo ficou dividido da seguinte maneira, descrita na Tabela 27: Tarefa Tempo estimado (horas) Preparação - 10% 0,3 Especificação - 40% 1,3 Executar Testes - 45% 1,5 Conclusão - 5% 0,2 Preparação - 10% 0,3 Total 3,3 Tabela 27: Tempo gasto para realizar cada atividade de Teste segundo APT.
  • 58. 58 A planilha utilizada no SERPRO estimou 4 horas de teste, resultado que tem a disparidade quanto à primeira medição explicada pelos pesos que são dados as características de performance e segurança, a performance tem peso 0.05 ao invés de 0.1 e segurança tem peso 0.1 ao invés de 0.05, como ocorre na técnica original, considerando assim que segurança tem importância maior que performance e também por incluir ao valor original uma porcentagem referente à etapa de Revisão. Os detalhes podem ser observados no Apêndice IX, o tempo total foi dividido da seguinte maneira como na Tabela 28: Tarefa Tempo estimado (horas) Planejar Testes - 10% 0,3 Projetar e Implementar Testes - 15% 0,5 Projetar e Implementar Testes - 20% 0,7 Executar Testes - 45% 1,5 Avaliar Resultados - 10% 0,3 Horas de Revisão Revisão dos Artefatos de Planejamento - 20% do planejamento 0,1 Revisão dos Artefatos de Projeto - 40% do projeto 0,1 Revisão dos Artefatos de Projeto - 40% da implementação 0,2 Revisão dos Artefatos de Avaliação - 20% da avaliação 0,3 4 Total Tabela 28: Tempo gasto para realizar cada atividade de Teste segundo APT (planilha SERPRO). O terceiro mecanismo utilizado retornou 47 minutos de teste, apresentando um afastamento maior dos valores citados acima, fato explicado pela forma que a ferramenta calcula o número de pontos de teste dinâmicos sem levar em consideração os pontos de função específicos de cada funcionalidade medida. O Apêndice X demonstra o resultado da ferramenta.
  • 59. 59 Na estimativa em homens/hora, temos que na planilha baseada na técnica original são necessários 3,3 homens/hora, na planilha do SERPRO, 4 homens/hora e na ferramenta de APT 0,78 homens/hora. 5.2.2 -Estimativa Método Ponderado de Nageswaran No domínio do Sistema Escola, o ator interage com o sistema através de uma interface gráfica. Dos 9 cenários identificados, 6 são de fluxo comum e 3 de exceção. Os fatores técnicos de ambiente podem ser observados na Tabela 29. Fator Ambiente de Teste Disponibilidade Totalmente Disponível Documentação Totalmente de Teste Disponível Classificação Valor da Disponibilidade Valor da Classificação É primordial 5 4 É importante 5 3 Tabela 29: Descrição dos Fatores Técnicos de Ambiente. A Figura 16 demonstra que a estimativa retornou 61,5 homens/hora de teste, assumindo que 7,5 horas são necessárias para planejar, escrever e executar 1 ponto de caso de uso devido ao processo não ser automatizado. Figura 16: Homens/hora totais de teste.
  • 60. 60 5.3 -Estimativas de Esforço Parcial do Projeto de Teste Para as estimativas de execução de casos de teste, é necessário que já exista uma descrição de Casos de Teste, que constam no Apêndice III. 5.3.1 -Análise de Pontos por Caso de Teste (TCP) Figura 17: Medição em Pontos por Caso de Teste. Conforme pode ser observado na Figura 17, para cada caso de teste se tem um ou mais resultados esperados, que são os checkpoints. Na coluna de pré-condições têm-se os níveis de complexidade referentes aos casos de teste e simples dados são necessários e podem ser criados durante o tempo de execução do caso de teste. Foi considerada a medição para um teste funcional e que são necessários 0,2 minutos para executar 1 ponto de caso de teste, já que, historicamente, levou-se 20 minutos para executar 24 casos de teste - 0,8 min para cada um e que 1 caso de teste tem 4,04 pontos. Segundo essa técnica são necessários 19,4 minutos para executar essa suíte de casos de teste, ou seja, 0,32 homens/hora.
  • 61. 61 5.3.2 -Estimativa baseada em Especificação de Requisito Funcional e Eficiência Acumulada Figura 18: Medição em Especificação de Requisito Funcional e Eficiência Acumulada. Conforme pode ser visto na Figura 18, para essa estimativa, os 24 casos de teste foram divididos em 2 ciclos, o primeiro com 4 casos de teste e o segundo com 20. No primeiro ciclo de execução, foi simulada uma média de passos de teste por minuto, sendo no primeiro dia de 2 passo/minuto (Ef(d)1 = 2) e no segundo dia de 4 passos/minuto (Ef(d)2 = 4), tendo sido executados 4 casos de teste nesse ciclo. A média aritmética do esforço desse ciclo foi de 3 passos/minuto e o erro médio de 1,5 passos/minuto. Como é a primeira iteração do ciclo, a média aritmética ponderada e a raiz média quadrada do erro médio são semelhantes à média aritmética e ao erro médio. O erro relativo encontrado foi de 1,9% e no ciclo 2 serão executados 93 passos. O esforço final encontrado para executar o ciclo 2 é de 31min 58 seg. Como no primeiro ciclo foram gastos 5 minutos, o tempo total de execução dos casos de teste é de 36 minutos e 58 segundos, ou seja, 0,61 homens/hora. 5.4 -Considerações sobre as medições As técnicas utilizadas para mensurar toda a atividade de teste apresentaram estimativas que superaram o valor real de esforço empregado em cerca de 1 hora, as diferenciações encontradas se devem ao fato de que as diferentes formas de medição
  • 62. 62 utilizadas levam em consideração que determinada característica tem peso maior que outra, como foi o caso da medição utilizando a planilha do SERPRO, que estimou 4 homens/hora, e a Planilha da técnica original, que estimou 3,3 homens/hora. Além disso, a planilha utilizada pelo SERPRO inclui ao valor original uma porcentagem referente à etapa de Revisão. Já a ferramenta APT, disponibilizada pela Comunidade Testadores, estimou 0,78 homens/hora devido às diferenças que sua implementação apresenta em relação à técnica original, a ferramenta calcula o número de pontos de teste dinâmicos sem levar em consideração os pontos de função específicos de cada funcionalidade medida. O Método Ponderado de Nageswaran apresentou grande disparidade em relação às outras técnicas, segundo ela seriam necessários 70 homens/hora para testar esse domínio CRUD, quando o real gasto foi de 2,5 homens/hora. Essa extrema diferenciação deve-se ao fato de que poucos fatores são levados em consideração, nesse caso apenas ambiente e documentação de teste, e que a técnica afirma que são necessárias 7,5 horas para testar cada ponto de caso de uso quando a execução é manual, valor que pode variar de acordo com a experiência do testador e não poderia ser fixado. Já as técnicas que estimam o esforço de execução dos casos de teste dependem da descrição dos casos de teste e se baseiam em dados históricos de execuções anteriores para realizar a estimativa dos seguintes. A Análise de Pontos por Caso de Teste seriam necessários 0,32 homens/hora para executar os 24 casos de teste em questão, lembrando que essa técnica se baseia na experiência do testador para encontrar quantos minutos ele gasta para executar 1 TCP, tendo assim variação de estimativa dependendo do testador/equipe. Na Estimativa baseada em Especificação de Requisito Funcional e Eficiência Acumulada os casos de teste são divididos em ciclos. O primeiro ciclo é utilizado como base histórica para os demais. Segundo ela, para executar os casos de teste 5 a 24 serão necessários aproximadamente 31 minutos, levando em consideração a base histórica, o primeiro ciclo, com os casos de teste 1 a 4 levou 5 minutos para ser executado, toda suíte seria estimada em aproximadamente 36 minutos, que são 0,61 homens/hora. Comparando os valores que realmente foram gastos para executar o teste nesse experimento, que foi de 0,33 homens/hora, pode-se observar que a Análise de Pontos por
  • 63. 63 Caso de Teste foi a que mais se aproximou do valor real. Já a Estimativa baseada em Especificação de Requisito Funcional e Eficiência Acumulada apresentou o dobro do esforço real, o que pode ser atribuído ao fato de que a técnica não leva em consideração fatores como o tipo de teste e os dados de teste por exemplo. De todas as técnicas apresentadas a que mais se aproximou do esforço real foi a Análise de Pontos por Caso de Teste, quando se trata da execução, e a Planilha da técnica original de APT.
  • 64. 64 6 - Conclusão Este capítulo está dividido em três seções. A seção 6.1 apresenta as considerações finais, a seção 6.2 apresenta as contribuições e, finalmente, a seção 6.3 sugere trabalhos futuros. 6.1 -Considerações Finais Esse projeto apresentou algumas técnicas existentes na literatura acadêmica e utilizadas no mercado para estimar o esforço a ser gasto em projetos de teste de software. Algumas ainda se encontram em experimentação e outras já são conhecidas dos profissionais de teste, porém atualmente não se considera um padrão para realizar a estimativa, visto a complexidade de coleta das variáveis utilizadas e da aplicação das próprias estimativas. Através do survey realizado com profissionais de algumas partes do mundo, pode-se observar que a maioria utiliza a experiência em testes passados para estimar o esforço de atividades de teste futuras. Além das métricas descritas no projeto, pode-se observar através do protocolo de quasi-Revisão Sistemática que existem estudos na área visando conseguir uma precisão maior para a estimativa através de diversos tipos de tecnologia e aplicações, como por exemplo, Inteligência Artificial. Por fim, os resultados da prova de conceito mostraram que a técnica Análise de Pontos por Caso de Teste, utilizada para estimar apenas a fase de execução dos casos de teste, apresentou um valor bem próximo do real, já que quanto menor for o escopo da estimativa, menos variáveis são envolvidas e as chances de acerto maiores. Já as técnicas que estimam esforço para todo o projeto de teste, dado o grande número de variáveis que muitas vezes são difíceis de quantificar, como a experiência do testador, por exemplo, a disparidade encontrada é maior. 6.2 -Contribuições Esse trabalho trouxe um exemplo prático de utilização de diferentes métricas de estimativa de esforço para projetos de teste de software através da prova de conceito,
  • 65. 65 demonstrando algumas técnicas e suas aplicações e disparidades na estimativa de esforço, além de trazer, no protocolo de quasi-Revisão Sistemática, uma lista de artigos com várias outras técnicas que se encontram em fase de estudos. Além disso, foi possível identificar e comunicar a Comunidade Testadores sobre a diferença encontrada na implementação da Ferramenta APT em relação à técnica original. 6.3 -Trabalhos Futuros Como pôde ser observado através do protocolo de quasi-Revisão Sistemática, existem diversas técnicas para estimar o esforço gasto em teste de software sendo estudadas, e através da prova de conceito ficou claro que essas estimativas podem não ser suficientemente precisas. Como trabalhos futuros pode-se apresentar um experimento in vivo utilizando as técnicas citadas nesse projeto assim como as outras técnicas presentes na quasi-Revisão Sistemática e propor melhorias para tornar as estimativas mais consistentes.
  • 66. Referências Bibliográficas AGAPITO, R. Ferramenta de APT. Testadores, 2012. Disponivel em: <http://www.testadores.com/index.php/web-links/40-programas/365-analise-de-pontosde-teste-v104>. Acesso em: 10 mar. 2012. ARANHA, E.; BORBA, P. Empirical Studies of Test Execution Effort Estimation Based on Test Characteristics and Risk Factors, 2007. Disponivel em: <http://toritama.cin.ufpe.br/twiki/pub/SPG/SoftwareEstimationModels/idoese2007aranha_final.pdf>. Acesso em: 22 abr. 2012. BIOLCHINI, J. et al. Systematic Review in Software Engineering. COPPE/UFRJ. Rio de Janeiro, p. 30. 2005. GUERREIRO, D. E. S.; T., B. D. A. A Simple Approach for Estimation of Execution Effort of Functional Test Cases. IEE Computer Society, 2009. Disponivel em: <http://www.computer.org/portal/web/csdl/doi/10.1109/ICST.2009.47>. Acesso em: 22 abr. 2012. JABREF Reference Manager. JabRef. Disponivel em: <http://jabref.sourceforge.net/>. Acesso em: 01 out. 2012. LAGARES, V.; ELIZA, R. Estimativa X Teste de Software: Como uma estimativa pode ajudar no gerenciamento do Teste de Software. Java Magazine, n. 92, p. 58-66, 2011. LOPES, F. A.; NELSON, M. A. V. nálise das Técnicas de Estimativas de Esforço para o Processo de Teste de Software, 2008. Disponivel em: <http://ebts2008.cesar.org.br/artigos/EBTS2008Analise_das_Tecnicas_Estimativas_de_Esfor co.pdf. Acessado em: 13/09/2011>. Acesso em: 13 set. 2011. MAFRA, S. N.; TRAVASSOS, G. H. Estudos Primários e Secundários apoiando a busca por Evidência em Engenharia de Software. COPPE/UFRJ. Rio de Janeiro, p. 32. 2066. NGUYEN, V.; PHAM, V.; LAM, V. Test Case Point Analysis: An Approach to Estimating Software Testing Size, 2009. Disponivel em: <http://www- scf.usc.edu/~nguyenvu/papers/TR-TCPA-01-2012.pdf>. Acesso em: 10 abr. 2012.
  • 67. PAI, M. M.; M, G. Systematic Reviews and meta-analyses: An illustrated, step-by-step guide. The National Medical Journal of India. [S.l.]. 2004. R. C., É. D. A.; MORAES, R.; T., B. D. A. An Alternative Approach to Test Effort Estimation Based on Use Cases. IEEE Explorer, 2009. Disponivel em: <http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4815360&url=http%3A%2F%2Fiee explore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4815360>. Acesso em: 22 abr. 2012. TRAVASSOS, G. H. et al. An Environmente to Support Large Scale Experimentation in Software Engineering. 13th IEEE International Conference on Engineering of Complex Computer Systems. Belfast: IEEE. 2008. p. 193-202. TRIOLA, M. F. Introdução A Estatística. 10ª Edição. ed. São Paulo: LTC, 2011. VEENENDAAL, E. V.; DEKKERS, T. Test point analysis: a method for test estimation, 1999. Disponivel em: <http://www.vietnamesetestingboard.org/zbxe/?document_srl=22272>. Acesso em: 15 maio 2012.
  • 68. Apêndice I – Modelo de Formulário de Extração Informações Gerais Título Título do artigo. Autores Lista dos autores Ano de Publicação O ano que o artigo foi publicado Fonte de Publicação Nome da Conferência, Periódico ou Revista que o artigo foi publicado. Resumo O resumo completo do artigo. Avaliação Status Se o artigo foi Incluído ou Excluído Critério de Exclusão Se o artigo foi excluído, informar por qual critério de exclusão. Estudos Empíricos Contexto da Avaliçao Empírica O que? O objeto de estudo. Quem? Os participantes envolvidos no estudo. Onde? O local onde o estudo é realizado. Quando? A situação temporal em que o estudo seja realizado. Por quê? Razões para a execução do estudo. Tipo do Estudo Empírico Tipo da Avaliação Empírica O tipo de estudo empírico utilizado para propor as métricas de estimativa de esforço em teste de software. As opções são: prova de conceito, estudo de caso, survey e experimento controlado.
  • 69. Design Experimental Número de Participantes Total de participantes envolvidos no estudo. Número de Grupos Total de número de grupos em que os participantes foram separados. Número de Participantes em cada Número de participantes por grupo Grupo Fator e Tratamento Número e descrição dos fatores e tratamentos. Design do Estudo Descrição sobre a organização dos assuntos e os tratamentos do estudo. Resultados de Estudo Hipóteses Hipóteses nulas do estudo. Descrição sobre ameaças à validade do estudo. Resultados Estatíscos Avaliações Empíricas das Para cada hipótese e tratamentos envolvidos, os resultados da avaliação estatística devem ser descritos. Ameaças à Validade Descrição sobre ameaças à validade do estudo. Atributos das Métricas Variáveis da métrica A lista das variáveis que a métrica utiliza e, correspondentemente, propriedades. Descrição das Variáveis A descrição de cada variável utilizada na métrica.
  • 70. Apêndice II – Artigos do protocolo de quasi-Revisão Sistemática Título A discrete software reliability growth model with testing effort A metric suite for early estimation of software testing effort using requirement engineering document and its validation Status A Simple Approach for Estimation of Execution Effort of Functional Test Cases A Multi-objective Particle Swarm Optimization for Test Case Selection Based on Functional Requirements Coverage and Execution Effort Incluído An experience-based approach for test execution effort estimation An Alternative Approach to Test Effort Estimation Based on Use Cases Estimate test execution effort at an early stage: An empirical study An Estimation Model for Test Execution Effort Optimal software release using time and cost benefits via fuzzy multi-criteria and fault tolerance Incluído Software testing sizing in incremental development: A case study An Experience-Based Approach for Test Execution Effort Estimation Machine learning methods and asymmetric cost function to estimate execution effort of software testing Incluído The COTECOMO: COnstractive Test Effort COst MOdel On estimating testing effort needed to assure field quality in software development Measuring Program Similarity: Experiments with SPEC CPU Benchmark Suites Enhancement of Bug Tracking Tools; the Debugger Multidimentional size measure for design of component-based software system A method for a priori implementation effort estimation for hardware design The personal software process: experiences from Denmark On the Accuracy of Spectrum-based Fault Localization Practical change impact analysis based on static program slicing for industrial software systems Automating Function Points analysis based on functional and non functional requirements text Path-based error coverage prediction Estimating the Cost of Developing Customizations to Packaged Application Software Using Service Oriented Architecture Incluído Incluído Incluído Incluído Incluído Incluído Incluído Incluído Incluído Incluído Incluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído A GP effort estimation model utilizing line of code and methodology for NASA software projects Excluído
  • 71. Measuring and Enhancing Prediction Capabilities of Vulnerability Discovery Models for Apache and IIS HTTP Servers Excluído Software effort estimation by tuning COOCMO model parameters using differential evolution Excluído Standard multispectral environment and effects model (STMEEM) Test effort estimation-particle swarm optimization based approach Quantitative Quality Assurance Approach On the false path problem in hard real-time programs Performance Evaluation of Windowing Approach on Effort Estimation by Analogy Benefits of a TPS virtual layer Release planning under fuzzy effort constraints COTS Integrations: Effort Estimation Best Practices Test Effort Estimation Models Based on Test Specifications Test blueprint: an effective visual support for test coverage State Estimation Simulation for the Design of an Optimal On-Line Solution Applying Test-First and Parallel Processing Techniques to ERP Data Conversion Parameter tuning of evolutionary algorithm by Meta-EAs for WCET analysis The role of modeling in the performance testing of e-commerce applications Using Evolutionary Testing to Find Test Scenarios for Hard to Reproduce Faults Measures of testability as a basis for quality assurance Reliability-growth analysis for an Ada-coding process TUPUX: An Estimation Tool for Incremental Software Development Projects Single event upset test structures for digital CMOS application specific integrated circuits Tightly-coupled image-aided inertial relative navigation using Statistical Predictive Rendering (SPR) techniques and a priori world Models Does ""Depth"" Really Matter? On the Role of Model Refinement for Testing and Reliability Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Comparing fault-proneness estimation models MedIGrid: a medical imaging application for computational Grids A Constructive RBF Neural Network for Estimating the Probability of Defects in Software Modules Excluído Predicting software defects: A cost-sensitive approach Building Scalable Failure-proneness Models Using Complexity Metrics for Large Scale Software Systems Excluído The Soft Computing Approach to Program Development Time Estimation Degrees of consciousness for reuse of software in practice: Maintainability, balance, standardization Excluído Excluído Excluído Excluído Excluído Applying event-condition-action mechanism in healthcare: a computerised clinical testordering protocol system (TOPS) Excluído
  • 72. Design of a mission management system for the autonomous underwater vehicle MARIUS Object oriented metrics useful in the prediction of class testing complexity Excluído Excluído Using empirical testbeds to accelerate technology maturity and transition: the SCRover experience Excluído An enhanced technique for generating hybrid coverage test cases using activity diagrams Excluído Adaptive least mean square behavioral power modeling Excluído Simulation-Based Timing Analysis of Complex Real-Time Systems Excluído Automated System Testing Using Visual GUI Testing Tools: A Comparative Study in Industry Excluído An overview of Lutess a specification-based tool for testing synchronous software CARIAL: Cost-Aware Software Reliability Improvement with Active Learning A blended approach to course design and pedagogy to impart soft skills: An IT company's experiences from software engineering course Excluído Excluído Excluído A software falsifier Excluído Real-Time Synchronization on Multiprocessors: To Block or Not to Block, to Suspend or Spin? Excluído NSTB version 2 flight test results A cost model for determining the optimal number of software test cases Deadline analysis of interrupt-driven software Cost excessive paths in cloud based services Knowledge evaluation procedure based on concept maps A trade-off method between cost and reliability OpenRDK: A modular framework for robotic software development Processor allocation in parallel systems Modeling maintenance effort by means of dynamic systems Dynamic model for maintenance and testing effort Experiences in implementation and use of the square root information filter/smoother for orbit determination Achieving composability in NoC-based MPSoCs through QoS management at software level Automatic, Selective and Secure Deletion of Digital Evidence Impact of programming and application-specific knowledge on maintenance effort:A hazard rate model Optimizing and simplifying software metric models constructed using maximum likelihood methods Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Integrating generalized Weibull-type testing-effort function and multiple change-points into software reliability growth models Excluído A Study of Applying Extended PIE Technique to Software Testability Analysis Excluído An Investigation of Software Effort Phase Distribution Using Compositional Data Excluído
  • 73. Analysis Demonstration of AGENDA tool set for testing relational database applications Maximum-Likelihood Estimation of Haplotype Frequencies in Trio Pedigrees Analysis of a software reliability growth model with logistic testing-effort function Optimal Regression Testing Based on Selective Coverage of Test Requirements Work in progress — An investigation of varied game-based learning systems in engineering education Techniques of maintaining evolving component-based software Optimal allocation of testing-resource considering cost, reliability, and testing-effort Excluído Excluído Excluído Excluído Excluído Excluído Excluído Software reliability modeling and cost estimation incorporating testing-effort and efficiency Excluído Optimal release time for software systems considering cost, testing-effort, and test efficiency Excluído Effort-index-based software reliability growth models and performance assessment Excluído A Value Estimation Method for Feature-Oriented Requirements Tracing A code inspection model for software quality management and prediction A defect estimation approach for sequential inspection using a modified capturerecapture model Excluído An integrated diagnostic support system approach to fault isolation in the operational environment Excluído Excluído Excluído Cost modeling process maturity-COCOMO 2.0 Software organization to facilitate dynamic processor scheduling A lightweight software control system for cyber awareness and security Calculation of core loss in a novel transformer design Applying support vector regression for web effort estimation using a cross-company dataset Excluído Available work time estimation Is the need to follow chains a possible deterrent to certain refactorings and an inducement to others? Excluído A change prediction model for embedded software applications Guiding reengineering with the operational profile IT Project Variables in the Balance: A Bayesian Approach to Prediction of Support Costs Early Models for System-Level Power Estimation Using case-based reasoning for generating functional test procedures [Propuesta de utilización del razonamiento basado en casos para la recuperación de procedimientos de prueba funcionales] Monte carlo simulation based estimations: Case from a global outsourcing company Excluído GERT: an empirical reliability estimation and testing feedback tool Reusing Existing Test Cases for Security Testing Static and dynamic software metrics complexity analysis in regression testing Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído
  • 74. Data Mining Techniques for Software Effort Estimation: A Comparative Study OpenSim: Open-Source Software to Create and Analyze Dynamic Simulations of Movement Post-silicon bug diagnosis with inconsistent executions A Time Delay Compensation Method Improving Registration for Augmented Reality A Parallel Genetic Algorithm Based on Hadoop MapReduce for the Automatic Generation of JUnit Test Suites Excluído Excluído Excluído Excluído Excluído The impact of memory and processor in determining the performance of programs Excluído An experience with two symbolic execution-based approaches to formal verification of Ada tasking programs Excluído Virtual Testbed for Assessing Probe Vehicle Data in IntelliDrive Systems Two-Dimensional Software Reliability Models and Their Application Lessons learned during the successful execution of a legacy Automated Test System (ATS) re-host Excluído An Approach to the Modeling of Software Testing with Some Applications Simplified workload characterization using unified prediction Object-oriented legacy system trace-based logic testing Ensuring Long-Term Access to Remotely Sensed Data With Layout Maps CAME tools for an efficient software maintenance Toward Harnessing High-Level Language Virtual Machines for Further Speeding Up Weak Mutation Testing Excluído Process modeling of integrated circuit device technology Evaluation and application of complexity-based criticality models Dynamic feature traces: finding features in unfamiliar code Getting a handle on the fault injection process: validation of measurement tools A primer on object-oriented measurement Web Services Open Test Suites Open Web Services Testing Restructuring unit tests with TestSurgeon Prediction models for software fault correction effort Using a proportional hazards model to analyze software reliability Non-preemptive interrupt scheduling for safe reuse of legacy drivers in real-time systems Exploiting OS-level mechanisms to implement mobile code security An evaluation of three function point models for estimation of software effort System-level metrics for hardware/software architectural mapping A Case Study Using Web Objects and COSMIC for Effort Estimation of Web Applications Genetic Programming for Effort Estimation: An Analysis of the Impact of Different Fitness Functions Excluído A metric framework for the assessment of object-oriented systems From testing to diagnosis: an automated approach Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído
  • 75. An exploratory analysis of system test data Early estimation of the size of VHDL projects An approach toward reuse of engineering models in the automation of system verification ADTEST: a test data generation suite for Ada software systems Software test data generation using program instrumentation Application of vertical test commonality to PALADIN maintenance A knowledge base system used to estimate schedule, effort, staff, documentation and defects in a software development process Excluído Robust thread-level speculation Testing Processes in Business-Critical Chain Software Lifecycle Neural networks application in software cost estimation: A case study Statistically based parametric yield prediction for integrated circuits A HMMER hardware accelerator using divergences Development platform for WIP bond quality testing system Software failure rate and reliability incorporating repair policies From test count to code coverage using the Lognormal Failure Rate Analytical Models for Architecture-Based Software Reliability Prediction: A Unification Framework Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído FPGA Implementation of Abundance Estimation for Spectral Unmixing of Hyperspectral Data Using the Image Space Reconstruction Algorithm Excluído RiTMO: A Method for Runtime Testability Measurement and Optimisation Excluído Debugging effort estimation using software metrics Excluído Architectural-level risk analysis using UML Excluído Factors systematically associated with errors in subjective estimates of software development effort: the stability of expert judgment Excluído Reverse engineering of GUI models for testing The Impact of Irrelevant Information on Estimates of Software Development Effort From scripts to specifications: the evolution of a flight software testing effort Path Coverage Criteria for Palladio Performance Models A Fuzzy Logic Model Based upon Reused and New & Changed Code for Software Development Effort Estimation at Personal Level Excluído Optimized timed hardware software cosimulation without roll-back Using stochastic models to effectively schedule hardware test efforts Software project effort: Different methods of estimation The SDC DAQSim simulation effort The SDC DAQSim simulation effort Software Project Level Estimation Model Framework based on Bayesian Belief Networks Insights in Implementing Collaboration Engineering Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído
  • 76. Interval Type-2 Fuzzy Logic for Software Cost Estimation Using TSFC with Mean and Standard Deviation CPN-a hybrid model for software cost estimation Dealing with Test Automation Debt at Microsoft A vector-based approach to software size measurement and effort estimation Formal analysis of a space-craft controller using SPIN Evaluating Dynamic Software Update Safety Using Systematic Testing CATS-an automated user interface for software development and testing A Practical Model for Measuring Maintainability Planning models for software reliability and cost Modeling eddy current analysis data to determine depth of weld penetration CiCUTS: Combining System Execution Modeling Tools with Continuous Integration Environments Conservative synchronization in object-oriented parallel battlefield discrete event simulations Evaluation of activity monitors to estimate energy expenditure in manual wheelchair users The role of MPI in development time: A case study Performance modeling for systematic performance tuning On Adapting Power Estimation Models for Embedded Soft-Core Processors A source-based risk analysis approach for software test optimization A source-based risk analysis approach for software test optimization Experiences from conducting semi-structured interviews in empirical software engineering research Automatic generation of a software performance model using an object-oriented prototype Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Parameter estimation for software reliability models considering failure correlation Excluído Software Reliability Modeling withWeibull-type Testing-Effort and Multiple ChangePoints Incluído Research on Software Effort Estimation Combined with Genetic Algorithm and Support Vector Regression Excluído Software rejuvenation: analysis, module and applications Investigating available instruction level parallelism for stack based machine architectures Estimation of software defects fix effort using neural networks Evaluating the Quality of Models Extracted from Embedded Real-Time Software Seasonal Variation in the Vulnerability Discovery Process Validating and understanding software cost estimation models based on neural networks Extraction test cases by using data mining; reducing the cost of testing Two-dimensional software reliability measurement technologies Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído
  • 77. Exploratory testing: a multiple case study Software metrics enhance test data generation and productivity measurement Tools and procedures for successful TPS management Using clone detection to identify bugs in concurrent software Empirical validation of relational database metrics for effort estimation Photodiode sensor array design for photovoltaic system inter-row spacing optimization-calculating module performance during in-situ testing / simulated shading Excluído A Formal Approach to Pre-Market Review for Medical Device Software Reengineering legacy application to e-business with modified Rational Unified Process Excluído Full chip false timing path identification: applications to the PowerPCTM microprocessors Can LORAN meet GPS backup requirements? Validation of software effort models Fault localization using visualization of test information Avoiding Irrelevant and Misleading Information When Estimating Development Effort Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído The prediction ability of experienced software maintainers Spectral analysis for characterizing program power and performance Optimal resource allocation and reliability analysis for component-based software applications Excluído Method Study of Software Project Schedule Estimation Guide Assessing software complexity from UML using fractal complexity measure Excluído Prediction of fault-proneness at early phase in object-oriented development Excluído Pitfalls and strategies in automated testing Model-based embedded software development flow Test executive features for improved TPS debug Branch regulation: Low-overhead protection from code reuse attacks Analysis of quality of object oriented systems using object oriented metrics Model-based testing of embedded systems in hardware in the loop environment Experiments with Analogy-X for Software Cost Estimation Optimising Project Feature Weights for Analogy-Based Software Cost Estimation using the Mantel Correlation Excluído Analogy-X: Providing Statistical Inference to Analogy-Based Software Cost Estimation Excluído Hardware/Software Codesign Architecture for Online Testing in Chip Multiprocessors Excluído Discovering complete API rules with mutation testing Return on investment of software quality predictions Assessing uncertain predictions of software quality Are the principal components of software complexity data stable across software products? Excluído Software quality classification modeling using the SPRINT decision tree algorithm The cost of code quality Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído
  • 78. An approach to software project feasibility study using stochastic risk model during proposal preparation Excluído Robustness testing framework for Web services composition Side channel analysis countermeasures using obfuscated instructions Pairwise Testing in the Presence of Configuration Change Cost Development and implementation of a rail current optimization program Demonstrating robust high data rate capability on a software defined radio using antijam wideband OFDM waveforms Excluído How to Find Relevant Data for Effort Estimation? Exploiting the Essential Assumptions of Analogy-Based Effort Estimation AI-Based Models for Software Effort Estimation Modeling search in group decision support systems Runtime control of Ada rendezvous for testing and debugging Applying test automation to type acceptance testing of telecom networks: a case study with customer participation Excluído Using Genetic Search for Reverse Engineering of Parametric Behavior Models for Performance Prediction Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Cost Reduction through Combining Test Sequences with Input Data Domain specific phase by phase effort estimation in software projects Generation of efficient test data using path selection strategy with elitist GA in regression testing Excluído Can we certify systems for freedom from malware Pragmatic study of parametric decomposition models for estimating software reliability growth Excluído Analysis of incorporating logistic testing-effort function into software reliability modeling Photovoltaic reliability model development and validation TPartition: testbench partitioning for hardware-accelerated functional verification The Limitations of Estimation Techniques for efficient wireless communication systems modeling using C++ Automated detection of injected faults in a differential equation solver Software effort estimation with a generalized robust linear regression technique On generating test data from prototypes Evaluating an Interactive-Predictive Paradigm on Handwriting Transcription: A Case Study and Lessons Learned Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Interactive software package for digital signal processing Life cycle cost (LCC) estimating for large management information system (MIS) software development projects Excluído Software diagnosability A Bayesian Net Based Effort Estimation Model for Service Governance Processes Automatic Regression Test Selection Based on Activity Diagrams Excluído Excluído Excluído Excluído
  • 79. Feedback-Directed Test Case Generation Based on UML Activity Diagrams Understanding soft error propagation using Efficient vulnerability-driven fault injection Reuse economics: a comparison of seventeen models and directions for future research Development of fuzzy-logic processing objects for industrial control applications Integrating Model-Based Testing with Evolutionary Functional Testing Software reliability estimation for modular software systems and its applications Sizing and estimating the coding and unit testing effort for GUI systems Applying moving windows to software effort estimation Investigating the use of chronological split for software effort estimation Automated maintenance of avionics software A naive Bayesian Belief Network model for predicting effort deviation rate in software testing Excluído Estimate Test Execution Effort at an Early Stage: An Empirical Study Using prior-phase effort records for re-estimation during software projects A strategy for autogeneration of space shuttle ground processing simulation models for project makespan estimation Incluído Intelligent, adaptive file system policy selection Critical-Path-Guided Interactive Parallelisation DoD/MOD coalition efforts for ATS A parameterized cost model to order classes for class-based testing of C++ applications Excluído Prioritization of Test Cases Using Software Agents and Fuzzy Logic Automatic program instrumentation in generation of test data using genetic algorithm for multiple paths coverage Excluído Talking about a Mutation-Based Reverse Engineering for Web Testing: A Preliminary Experiment Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Dynamic Analysis for Diagnosing Integration Faults make test-zesti: A symbolic execution solution for improving regression testing Integration of embedded, real-time, Ada, operational flight programs with off-line engineering level-of-detail digital models Excluído Efficient Testbench Code Synthesis for a Hardware Emulator System A Multi-step Simulation Approach toward Secure Fault Tolerant System Evaluation VIDA: Visual interactive debugging Studying the fault-detection effectiveness of GUI test cases for rapidly evolving software Comparing effort prediction models for Web design and authoring using boxplots Using an engineering approach to understanding and predicting Web authoring and design Excluído Exploiting the forgiving nature of applications for scalable parallel execution Local vs. global models for effort estimation and defect prediction Validation methods for calibrating software effort models Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído
  • 80. Selecting Best Practices for Effort Estimation Predicated software pipelining technique for loops with conditions Using RFID Technologies to Capture Simulation Data in a Hospital Emergency Department Size-Constrained Regression Test Case Selection Using Multicriteria Optimization Automated calibration aids smooth turnover of new plants A Regression Testing Approach for Software Product Lines Architectures Least squares support vector machines with genetic algorithm for estimating costs in NPD projects Excluído Using designer's effort for user interface evaluation Dynamic output analysis for simulations of manufacturing environments Evolving process simulators by using validated learning Code churn: a measure for estimating the impact of code change U.S. Army Modeling and Simulation Executable Architecture Deployment Cloud Virtualization Strategy Excluído Sensitivity of field failure intensity to operational profile errors Allow plenty of time for large-scale software Using In-Process Testing Metrics to Estimate Post-Release Field Quality Adjustable Cost Estimation Model for COTS-Based Development Excluído Hardware speech recognition for user interfaces in low cost, low power devices Lessons from using Z to specify a software tool Managing OO projects better Assessing the real-time properties of Windows CE 3.0 Transition-based testability analysis for reactive systems Inserting software fault measurement techniques into development efforts Impact of Budget and Schedule Pressure on Software Development Cycle Time and Effort Basic metrics for performance estimation of computers Towards the Integration of Quality Attributes into a Software Product Line Cost Model Excluído Improved testing using failure cost and intensity profiles Reggae: Automated Test Generation for Programs Using Complex Regular Expressions Excluído Quantifying the Effectiveness of Testing Efforts on Software Fault Detection with a Logit Software Reliability Growth Model Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído A Multi-factor Software Reliability Model Based on Logistic Regression Excluído When PIGs Fly - addressing software reliability concerns for the IRIS IP router operating system Excluído A service operations software creation environment for advanced intelligent networks Excluído Is parallelism for you? A Symbolic Execution Tool Based on the Elimination of Infeasible Paths A case study: Developing a complete test program using IEEE 1641 Excluído Excluído Excluído
  • 81. Application and Comparison of Particle Swarm Optimization and Genetic Algorithm in Strategy Defense Game Excluído Path selection in the structural testing: proposition, implementation and application of strategies Excluído A new metrics set for evaluating testing efforts for object-oriented programs Excluído An experiment for evaluating the effectiveness of using a system dynamics simulation model in software project management education Excluído A software-reliability growth model for N-version programming systems New probabilistic measures for accelerating the automatic test pattern generation algorithm Excluído Reducing Corrective Maintenance Effort Considering Module's History Integrating testability analysis tools with automatic test systems (ATS) What makes inspections work? A Fast Algorithm for Nonparametric Probability Density Estimation An experiment measuring the effects of personal software process (PSP) training How not to do agile testing Year 2000 work comes down to the wire Soft-OLP: Improving Hardware Cache Performance through Software-Controlled Object-Level Partitioning Excluído Guide: A GUI differentiator Benefits and limitations of automated software testing: Systematic literature review and practitioner survey Excluído Reliability estimation for a software system with sequential independent reviews Overcoming the challenges in cost estimation for distributed software projects Metrics of software evolution as effort predictors - a case study On determining the software testing cost to assure desired field reliability Effect of variability of a framework upon its testing effort: An empirical evaluation Automated GUI Test Coverage Analysis Using GA Simple and effective techniques for core-region detection and slant correction in offline script recognition Excluído F-14 flight control law design, verification, and validation using computer aided engineering tools Industrial experiences with automated regression testing of a legacy database application Space mission operations DBMS (SMOD) A Mutation/Injection-Based Automatic Framework for Evaluating Code Clone Detection Tools Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Using Web objects for estimating software development effort for Web applications Excluído DAISY: An efficient tool to test global identifiability. Some case studies A Formal Approach for Design of Agent Based Earthquake Management System (EMS) Interface Coverage Criteria Supporting ModelüBased Integration Testing Excluído Excluído Excluído
  • 82. Design for testability in embedded software projects On Equivalence Partitioning of Code Paths inside OS Kernel Components Performance modeling using object-oriented execution-driven simulation A new approach for estimation of software testing process based on software requirements Development of Fuzzy Software Operational Profile Profiling the Operational Behavior of OS Device Drivers A model-based approach for executable specifications on reconfigurable hardware Multichannel dynamic range compression for music signals Pocket Estimator -- A Commercial Solution to Provide Free Parametric Software Estimation Combining an Expert and a Learning Algorithm Excluído Predicting Defects and Changes with Import Relations Accelerating system integration by enhancing hardware, firmware, and co-simulation Discovering determinants of high volatility software A decision theory framework for software fault correction Tool support for collaborative software prototyping A cost-effective approach to testing DevCOP: A Software Certificate Management System for Eclipse Pragmatic prioritization of software quality assurance efforts A micro software reliability model for prediction and test apportionment Standards-software reliability handbook: achieving reliable software Model driven testing of embedded automotive systems with timed usage models Applying the Use Case Points effort estimation technique to Avionics Systems Machine Learning Methods and Asymmetric Cost Function to Estimate Execution Effort of Software Testing Excluído Weighted Least Absolute Value state estimation using interior point methods Reconfigurable hardware SAT solvers: a survey of systems Experiences with Target-Platform Heterogeneity in Clouds, Grids, and On-Premises Resources Excluído A stochastic model of human errors in software development: impact of repair times Excluído Measuring web service interfaces Impact analysis of maintenance tasks for a distributed object-oriented system Keynote Abstract Effort Estimates for Vulnerability Discovery Projects A novel approach to calculate the severity and priority of bugs in software projects 3D recovery with free hand camera motion A comprehensive approach for modeling and testing analog and mixed-signal devices Excluído Machine learning approaches to estimating software development effort Active memory processor: a hardware garbage collector for real-time Java embedded devices Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído
  • 83. Optimal software release using time and cost benefits via fuzzy multi-criteria and fault tolerance Excluído Excluído Excluído Excluído Excluído Software testing effort: An assessment through fuzzy criteria approach Test sequence optimisation: An intelligent approach via cuckoo search Software test effort estimation: A model based on cuckoo search Better testing through oracle selection: (NIER track) Excluído HiPPAI: High Performance Portable Accelerator Interface for SoCs Excluído A virtual instrumentation-based on-line determination of a single/two phase induction motor drive characteristics at coarse start-up Excluído Incremental Workflow Mining with Optional Patterns On the reliability of benefit transfer: case of the Japanese e-health system Framework for modeling software reliability, using various testing-efforts and faultdetection rates The perceived value of authoring and automating acceptance tests using a model driven development toolset Improvement of Software Process by Process Description and Benefit Estimation Resource-aware scientific computation on a heterogeneous cluster A Domain Specific Language for Reconfigurable Path-based Monte Carlo Simulations Excluído Excluído Excluído Excluído Excluído Excluído Excluído Advancements in Distributed Generation Issues Interconnection, Modeling, and Tariffs Excluído Experience from Quality Assurance in Nuclear Power Plant Protection System Software Validation Excluído COM-based test foundation framework Migrating software testing to the cloud Parameterized unit testing: theory and practice The accuracy of fault prediction in modified code - statistical model vs. expert estimation Excluído Internal and External Software Benchmark Repository Utilization for Effort Estimation Implementation of a Software Quality Improvement Project in an SME: A Before and After Comparison Excluído Engineering real-time behavior Soft computing for propulsion control Automated distributed system testing: designing an RTI verification system A progressive software development lifecycle Ensemble imputation methods for missing software engineering data Applying Particle Swarm Optimization to estimate software effort by multiple factors software project clustering Excluído “Plug and test” - software agents in virtual environments An Analysis of Cost-Overrun Projects Using Financial Data and Software Metrics SLIF: a specification-level intermediate format for system design Perceived Effects of Pair Programming in an Industrial Context Estimation of Test Code Changes Using Historical Release Data Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído
  • 84. Automated Test Case Generation of Self-Managing Policies for NASA Prototype Missions Developed with ASSL Excluído Effective Migration of Enterprise Applications in Multicore Cloud Using Best Practices of Software Engineering into a Real Time System Development A low-cost distributed instrumentation system for monitoring, identifying and diagnosing irregular patterns of behavior in critical ITS components Excluído Caspar: Hardware patching for multicore processors An Evaluation of Two Bug Pattern Tools for Java Practical techniques for distributed real-time simulation Quality planning for software development Function Call Flow based Fitness Function Design in Evolutionary Testing CIMDS: Adapting Postprocessing Techniques of Associative Classification for Malware Detection Excluído A new yield optimization algorithm and its applications The Use of Product Measures in Tracking Code Development to Completion within Small to Medium Sized Enterprises Excluído Exploiting WSRF and WSRF.NET for Remote Job Execution in Grid Environments Test forensics: A guide to evaluating TPS transportability Test forensics: A guide to evaluating TPS transportability Smart test program set (TPS) Smart Test Program Set (TPS) Software fault localization based on program slicing spectrum An Architecture-Based Software Reliability Modeling Tool and Its Support for Teaching Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Emulation and enhancement of the Honeywell 2600 automatic test station Excluído Estimating the software development schedules for advanced products Excluído Sensor modeling, probabilistic hypothesis generation, and robust localization for object recognition Excluído Efficient forward computation of dynamic slices using reduced ordered binary decision diagrams Excluído A modified function point method for CAL systems with respect to software cost estimation Excluído Problem identification for structural test generation: first step towards cooperative developer testing Excluído Early Estimate the Size of Test Suites from Use Cases Performance debugging in the large via mining millions of stack traces Improving Effectiveness of Automated Software Testing in the Absence of Specifications Excluído A model of open source software maintenance activities Testing Scenario Implementation with Behavior Contracts Precise identification of problems for structural test generation Excluído Excluído Excluído Excluído Excluído
  • 85. Software Reliability Growth Models with Testing-Effort Using Weighted Attributes to Improve Cluster Test Selection Sentomist: Unveiling Transient Sensor Network Bugs via Symptom Mining A New Strategy for Pairwise Test Case Generation An Agglomerative Clustering Methodology For Data Imputation Profiling file repository access patterns for identifying data exfiltration activities Analysis and enhancement of software dynamic defect models Research and Implementation of Automatic Business Health-Checking Framework Experimental Validation of Channel State Prediction Considering Delays in Practical Cognitive Radio Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Excluído Rapid prototyping of complex interactive simulation systems Excluído A Dynamic Test Cluster Sampling Strategy by Leveraging Execution Spectra Information Excluído Adaptation of high level behavioral models for stuck-at coverage analysis Excluído
  • 86. Apêndice III – Regras de Negócio Sistema Escola Histórico de Versões Data Versão 22/11/2010 1.0 24/11/2010 1.1 Descrição Versão inicial da Especificação de Regras de Negócio Inclusão de restrições de campos Autor Revisor Aprovado por Thiago Silva <nome> <nome> Thiago Silva <nome> <nome> 1. Objetivo O objetivo da Especificação de Regras de Negócio é documentar as regras que são aplicáveis ao negócio, e que direcionam em maior ou menor grau o funcionamento dos Casos de Uso. Em geral, regras de negócio constituem declarações de políticas ou condições que devem ser satisfeitas pelo processamento da aplicação. 2. Regras de Negócio 2.1. Entidade Aluno Uma instância da entidade “Aluno” possui os seguintes campos: cpf, nome, email, nome da mãe, nome do pai, data de nascimento, idade, login e senha. 2.2. Restrições de domínio de campos 2.2.1. CPF O campo “CPF” deve permitir onze posições numéricas e não deve permitir cadastro duplicado. 2.2.2. Nome Campo alfanumérico de 255 posições. 2.2.3. Email Campo alfanumérico de 255 posições. 2.2.4. Nome da mãe
  • 87. Campo alfanumérico de 255 posições. 2.2.5. Nome do pai Campo alfanumérico de 255 posições. 2.2.6. Data de nascimento O campo “Data de nascimento” deve possuir o formato “dd/mm/aaaa”. 2.2.7. Idade O campo idade deve permitir até três posições numéricas. 2.2.8. Login O campo “Login” deve aplicar as mesmas regras do campo “CPF” e não deve permitir cadastro duplicado. 2.2.9. Senha Campo alfanumérico de 255 posições. Os caracteres informados para este campo não podem ser exibidos, isto é, devem ser substituídos por asteriscos durante a digitação. 2.3. Política de acesso ao sistema Tendo em vista que o sistema terá funcionalidades destinadas ao Funcionário e ao Administrador, será necessário que cada usuário seja identificado no momento do acesso.
  • 88. Apêndice VI – Descrição dos Casos de Uso Efetuar Login Histórico de Versões Data Versão Descrição Autor Revisor Aprovado por 1.0 Versão inicial da Especificação de Caso de Uso Thiago Silva <nome> <nome> 22/11/2010 1. Nome do Caso de Uso Efetuar Login. 2. Objetivo Permitir que o usuário se autentique e tenha acesso às funcionalidades do sistema disponíveis para seu perfil. 3. Tipo de Caso de Uso Concreto. 4. Atores Nome Ator Administrador 5. Pré-condições O usuário deve estar cadastrado no sistema. 6. Fluxo Principal P1. Ator acessa a aplicação. P2. Sistema exibe a tela de login. P3. Ator informa nome e senha e confirma. Primário X Tipo Secundário
  • 89. P4. Sistema valida que os dados estão corretos e apresenta as funcionalidades disponíveis para o usuário. 7. Fluxos Alternativos A1. Cancelar Login No passo P2, o ator escolhe a opção “Cancelar” e a aplicação é finalizada. 8. Fluxos de Exceção E1. Usuário Não-Cadastrado No passo P3, o usuário informa um nome não cadastrado no sistema. Após tentar autenticar o usuário, o sistema exibe uma mensagem de erro. E2. Senha inválida No passo P3, o usuário informa uma senha inválida. Após tentar autenticar o usuário, o sistema exibe uma mensagem de erro. 9. Pós-condições Nenhuma pós-condição identificada. 10. Requisitos Não Funcionais Vide documento RNFEscola.doc. 11. Ponto de Extensão Nenhum ponto de extensão identificado. 12. Critérios de Aceite (casos de testes iniciais) 1. Ao final do fluxo principal o sistema deve exibir suas funcionalidades de acordo com o perfil cadastrado para o usuário. 2. No fluxo de exceção E1, o sistema deve exibir a mensagem de erro “Usuário não cadastrado”. 3. No fluxo de exceção E2, o sistema deve exibir a mensagem de erro “Senha inválida”. 13. Freqüência de Utilização
  • 90. Baixa. 14. Interface Visual Não há restrições relacionadas à interface visual. 15. Observações Há regras de negócio para este caso de uso no documento RNGEscola.doc. 16. Referências Não há referências. 17. Anexos Não há anexos. Manter Alunos Histórico de Versões Data Versão Descrição Autor Revisor Aprovado por 22/11/2010 1.0 Versão inicial da Especificação de Caso de Uso Thiago Silva <nome> <nome> 1. Nome do Caso de Uso Manter Alunos. 2. Objetivo Permitir que o ator do sistema possa cadastrar, consultar, alterar e excluir alunos do sistema. 3. Tipo de Caso de Uso Concreto. 4. Atores
  • 91. Nome Ator Administrador Primário X Tipo Secundário 5. Pré-condições O ator deve estar autenticado (logado) no sistema. 6. Fluxo Principal P1. Administrador escolhe a opção “Manter Alunos”. P2. Sistema exibe os alunos cadastrados no sistema. P3. Administrador escolhe a operação a realizar (cadastrar, alterar ou excluir aluno). P3.1. Cadastrar Aluno P3.1.1. Sistema exibe o formulário para preenchimento. P3.1.2. Administrador preenche as informações requeridas e confirma o cadastro. P3.1.3. Sistema valida as informações preenchidas e registra o novo aluno. P3.1.4. Sistema retorna ao passo P2. P3.2. Alterar Aluno P3.2.1. Sistema exibe as informações do aluno, permitindo sua alteração. P3.2.2. Administrador altera as informações desejadas e confirma a alteração. P3.2.3. Sistema valida as informações preenchidas e registra as alterações. P3.2.4. Sistema retorna ao passo P2. 7. Fluxos Alternativos A1. Administrador cancela operação Nos sub-fluxos cadastrar e alterar, caso o ator cancele a operação, o Sistema nada faz e retorna ao passo P2. 8. Fluxos de Exceção E1. Informações preenchidas incorretamente
  • 92. Nos sub-fluxos cadastrar e alterar aluno, quando o Sistema verifica se as informações foram preenchidas corretamente (P3.1.3 e P3.2.3), caso haja violação de alguma regra da entidade, o Sistema mostra uma mensagem indicando a regra violada. 9. Pós-condições Nenhuma pós-condição identificada. 10. Requisitos Não Funcionais Vide documento RNFEscola.doc. 11. Ponto de Extensão Nenhum ponto de extensão identificado. 12. Critérios de Aceite (casos de testes iniciais) 1. Ao final do sub-fluxo “Cadastrar Aluno” um novo aluno deve estar registrado no sistema. 2. Ao final do sub-fluxo “Alterar Aluno” as alterações informadas pelo ator devem estar registradas no sistema. 3. Ao final do sub-fluxo “Excluir Ator” o usuário deve estar excluído do sistema. 13. Freqüência de Utilização Média. 14. Interface Visual Não há restrições relacionadas à interface visual. 15. Observações Há regras de negócio para este caso de uso no documento RNGEscola.doc. 16. Referências Não há referências. 17. Anexos
  • 93. Não há anexos.
  • 94. Apêndice V – Casos de Teste do Sistema Escola Caso de Uso Efetuar Login Cenário 1 - Caso de Teste 1 (efetuar login com sucesso) 1. Acessar a aplicação na url http://localhost:8080/Escola. 2. Sistema exibe a tela de login com os campos “Login” e “Senha”. 3. Informar login = “08862687702” e senha = “thiago” e confirmar. 4. Sistema valida que os dados estão corretos e apresenta as funcionalidades disponíveis para o usuário. Cenário 2 – Caso de Teste 1 (cancelar o login) 1. Acessar a aplicação na url http://localhost:8080/Escola. 2. Sistema exibe a tela de login com os campos “Login” e “Senha”. 3. Escolher a opção “Cancelar”. 4. Aplicação é finalizada. Cenário 3 – Caso de Teste 1 (fazer login com usuário inexistente) 1. Acessar a aplicação na url http://localhost:8080/Escola. 2. Sistema exibe a tela de login com os campos “Login” e “Senha”. 3. Informar login = “133.467.627-50” e senha = “123” e confirmar. 4. Sistema exibe uma mensagem de erro (login). Cenário 4 – Caso de Teste 1 (fazer login com senha incorreta) 1. Acessar a aplicação na url http://localhost:8080/Escola. 2. Sistema exibe a tela de login com os campos “Login” e “Senha”. 3. Informar login = “08862687702” e senha = “teste” e confirmar. 4. Sistema exibe uma mensagem de erro (senha).
  • 95. Caso de Uso Manter Aluno Para todos os Cenários abaixo é necessário que tenha sido executado o Cenário 1 – Caso de Teste 1 - Efetuar Login. Cenário 1 - Caso de Teste 1 (incluir novo aluno) 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Novo. 3. Informar os seguintes dados: CPF: 55478311669 Nome: Joachim Dias Lima Email: lima@gmail.com Nome mãe: Maria Dias Nome pai: João Lima Data de nascimento: 12/02/80 Idade: 30 Login: 55478311669 Senha: lima 4. Escolher a opção Incluir Aluno. 5. Sistema valida que os dados estão corretos e apresenta a lista de alunos cadastrados. Cenário 1 – Caso de Teste 2 (alterar aluno) 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Alterar do aluno Joachim Dias Lima. 3. Informar os seguintes dados: Login: 55478311669 Senha: limaalterado 4. Escolher a opção Alterar Aluno.
  • 96. 5. Sistema valida que os dados estão corretos e apresenta a lista de alunos cadastrados. Cenário 1 – Caso de Teste 3 (excluir aluno) 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Excluir do aluno Joachim Dias Lima. 3. Sistema valida que não existem dependências com outras entidades e efetua a exclusão do aluno Joachim Dias Lima. Cenário 2 – Caso de Teste 1 (cancelar a operação ao incluir aluno) 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Novo. 3. Escolher a opção Voltar. 4. O sistema apresenta a lista de alunos cadastrados Cenário 2 – Caso de Teste 2 (cancelar a operação ao alterar aluno) 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Alterar do aluno Thiago de Lima Mariano. 3. Escolher a opção Voltar. 4. O sistema apresenta a lista de alunos cadastrados Cenário 3 – Caso de Teste 1 (incluir um aluno com CPF inválido) 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Novo. 3. Informar os seguintes dados: CPF: 11111111111111111111 Nome: Joachim Dias Lima Email: lima@gmail.com Nome mãe: João Lima Nome pai: Maria Dias
  • 97. Data de nascimento: 12/02/80 Idade: 30 Login: 55478311669 Senha: lima 4. Escolher a opção Incluir Aluno. 5. Sistema valida que os dados estão incorretos e apresenta a mensagem “Não foi possível converter o valor para um CPF válido!” Cenário 3 – Caso de Teste 2 (incluir um aluno com idade com mais de 3 caracteres) 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Novo. 3. Informar os seguintes dados: CPF: 55478311669 Nome: Joachim Dias Lima Email: lima@gmail.com Nome mãe: Maria Dias Nome pai: João Lima Data de nascimento: 12/02/80 Idade: 300 Login: 55478311669 Senha: lima 4. Escolher a opção Incluir Aluno. 5. Sistema valida que os dados estão incorretos e não permitirá o cadastro. Cenário 3 – Caso de Teste 3 (incluir um aluno com nome com mais de 255 caracteres) 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Novo.
  • 98. 3. Informar os seguintes dados: CPF: 55478311669 Nome: testecommaisde255caracterestestecommaisde255caracterestestecommaisde255car acterestestecommaisde255caracterestestecommaisde255caracterestestecommaisde 255caracterestestecommaisde255caracterestestecommaisde255caracterestestecom maisde255caracterestestecommaisde255caracterestestecommaisde255caracterestes tecommaisde255caracterestestecommaisde255caracterestestecommaisde255caract erestestecommaisde255caracteres Email: lima@gmail.com Nome mãe: Maria Dias Nome pai: João Lima Data de nascimento: 12/02/80 Idade: 30 Login: 55478311669 Senha: lima 4. Escolher a opção Incluir Aluno. 5. Sistema valida que os dados estão incorretos e não permitirá o cadastro. Cenário 3 – Caso de Teste 4 (incluir um aluno com nome da mãe com mais de 255 caracteres) 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Novo. 3. Informar os seguintes dados: CPF: 55478311669 Nome: Joachim Dias Lima Email: lima@gmail.com Nome mãe:
  • 99. testecommaisde255caracterestestecommaisde255caracterestestecommaisde255car acterestestecommaisde255caracterestestecommaisde255caracterestestecommaisde 255caracterestestecommaisde255caracterestestecommaisde255caracterestestecom maisde255caracterestestecommaisde255caracterestestecommaisde255caracterestes tecommaisde255caracterestestecommaisde255caracterestestecommaisde255caract erestestecommaisde255caracteres Nome pai: João Lima Data de nascimento: 12/02/80 Idade: 30 Login: 55478311669 Senha: lima 4. Escolher a opção Incluir Aluno. 5. Sistema valida que os dados estão incorretos e não permitirá o cadastro. Cenário 3 – Caso de Teste 5 (incluir um aluno com nome do pai com mais de 255 caracteres) 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Novo. 3. Informar os seguintes dados: CPF: 55478311669 Nome: Joachim Dias Lima Email: lima@gmail.com Nome mãe: Maria Dias Nome pai: testecommaisde255caracterestestecommaisde255caracterestestecommaisde255car acterestestecommaisde255caracterestestecommaisde255caracterestestecommaisde 255caracterestestecommaisde255caracterestestecommaisde255caracterestestecom maisde255caracterestestecommaisde255caracterestestecommaisde255caracterestes
  • 100. tecommaisde255caracterestestecommaisde255caracterestestecommaisde255caract erestestecommaisde255caracteres Data de nascimento: 12/02/80 Idade: 30 Login: 55478311669 Senha: lima 4. Escolher a opção Incluir Aluno. 5. Sistema valida que os dados estão incorretos e não permitirá o cadastro. Cenário 3 – Caso de Teste 6 (incluir um aluno com e-mail com mais de 255 caracteres) 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Novo. 3. Informar os seguintes dados: CPF: 55478311669 Nome: Joachim Dias Lima Email: testecommaisde255caracterestestecommaisde255caracterestestecommaisde255car acterestestecommaisde255caracterestestecommaisde255caracterestestecommaisde 255caracterestestecommaisde255caracterestestecommaisde255caracterestestecom maisde255caracterestestecommaisde255caracterestestecommaisde255caracterestes tecommaisde255caracterestestecommaisde255caracterestestecommaisde255caract erestestecommaisde255caracteres Nome mãe: Maria Dias Nome pai: João Lima Data de nascimento: 12/02/80 Idade: 30 Login: 55478311669 Senha: lima
  • 101. 4. Escolher a opção Incluir Aluno. 5. Sistema valida que os dados estão incorretos e não permitirá o cadastro. Cenário 3 – Caso de Teste 7 (incluir um aluno com CPF em branco) 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Novo. 3. Informar os seguintes dados: CPF: Nome: Joachim Dias Lima Email: lima@gmail.com Nome mãe: João Lima Nome pai: Maria Dias Data de nascimento: 12/02/80 Idade: 30 Login: 55478311669 Senha: lima 4. Escolher a opção Incluir Aluno. 5. Sistema valida que o campo CPF está em branco e retorna a mensagem de erro: “j_id_jsp_998463668_2:cpfInput: Validation Error: Value is required.” Cenário 3 – Caso de Teste 8 (incluir um aluno com data de nascimento diferente do formato “dd/mm/aaaa”) 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Novo. 3. Informar a data de nascimento com formato diferente de dd/mm/aaaa. 4. O sistema não permite a entrada de dados no campo de data de nascimento diferente de dd/mm/aaaa.
  • 102. Cenário 3 – Caso de Teste 9 (incluir um aluno sem informação de login/senha) 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Novo. 3. Informar os seguintes dados: CPF: 55478311669 Nome: Joachim Dias Lima Email: lima@gmail.com Nome mãe: Maria Dias Nome pai: João Lima Data de nascimento: 12/02/80 Idade: 30 Login: Senha: 4. Escolher a opção Incluir Aluno. 5. Sistema valida que os campos login/senha estão em branco e não permitirá o cadastro. Cenário 3 – Caso de Teste 10 (incluir um aluno com CPF já existente) Cenário 1 – Caso de Teste 1 deve ter sido executado. 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Novo. 3. Informar os seguintes dados: CPF: 55478311669 Nome: Gabi Rose Brant Email: gabi@gmail.com Nome mãe: Sônia Rose Nome pai: José Brant
  • 103. Data de nascimento: 24/08/75 Idade: 35 Login: 28811685583 Senha: gabi 4. Escolher a opção Incluir Aluno. 5. Sistema valida que o CPF informado já existe e não permitirá o cadastro. Cenário 3 – Caso de Teste 11 (incluir um aluno com CPF com letras) Cenário 1 – Caso de Teste 1 deve ter sido executado. 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Novo. 3. Informar os seguintes dados: CPF: jlkjjdshuoolksd Nome: Joachim Dias Lima Email: lima@gmail.com Nome mãe: Maria Dias Nome pai: João Lima Data de nascimento: 12/02/80 Idade: 30 Login: 55478311669 Senha: lima 4. Escolher a opção Incluir Aluno. 5. Sistema valida que os dados estão incorretos e apresenta a mensagem “Não foi possível converter o valor para um CPF válido!” Cenário 3 – Caso de Teste 12 (incluir um aluno com login já existente) Cenário 1 – Caso de Teste 1 deve ter sido executado.
  • 104. 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Novo. 3. Informar os seguintes dados: CPF: 28811685583 Nome: Gabi Rose Brant Email: gabi@gmail.com Nome mãe: Sônia Rose Nome pai: José Brant Data de nascimento: 24/08/75 Idade: 35 Login: 55478311669 Senha: gabi 4. Escolher a opção Incluir Aluno. 5. Sistema valida que o login informado já existe e não permitirá o cadastro. Cenário 3 – Caso de Teste 13 (incluir um aluno com login inválido) 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Novo. 3. Informar os seguintes dados: CPF: 55478311669 Nome: Joachim Dias Lima Email: lima@gmail.com Nome mãe: João Lima Nome pai: Maria Dias Data de nascimento: 12/02/80 Idade: 30
  • 105. Login: 11111111111111111111 Senha: lima 4. Escolher a opção Incluir Aluno. 5. Sistema valida que o login informado é inválido e não permitirá o cadastro. Cenário 3 – Caso de Teste 14 (incluir um aluno com login com letras) 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Novo. 3. Informar os seguintes dados: CPF: 55478311669 Nome: Joachim Dias Lima Email: lima@gmail.com Nome mãe: Maria Dias Nome pai: João Lima Data de nascimento: 12/02/80 Idade: 30 Login: jlkjjdshuoolksd Senha: lima 4. Escolher a opção Incluir Aluno. 5. Sistema valida que o login informado é inválido e não permitirá o cadastro. Cenário 4 – Caso de Teste 1 (deslogar da aplicação) 1. Sistema exibe os alunos cadastrados no sistema. 2. Escolher a opção Desconectar. 3. O sistema retorna para a página de Login.
  • 106. Apêndice VI – Evidências de Teste executados com sucesso Casos de Teste do Caso de Uso Efetuar Login: Cenário 1 - Caso de Teste 1 (efetuar login com sucesso) Login e Senha válidos: Sistema apresenta a lista de alunos cadastrados:
  • 107. Casos de Teste do Caso de Uso Manter Aluno: Cenário 1 - Caso de Teste 1 (incluir novo aluno) Dados válidos preenchidos, aluno Joaquim incluído. Cenário 1 – Caso de Teste 2 (alterar aluno) Senha do aluno Joaquim alterada
  • 108. Cenário 1 – Caso de Teste 3 (excluir aluno) Aluno Joaquim excluído Cenário 2 – Caso de Teste 1 (cancelar a operação ao incluir aluno) Ao clicar em voltar
  • 109. O sistema volta para lista de alunos Cenário 2 – Caso de Teste 2 (cancelar a operação ao alterar aluno) Ao clicar em voltar
  • 110. O sistema volta para lista de alunos Cenário 3 – Caso de Teste 1 (incluir um aluno com CPF inválido) Ao tentar incluir um aluno com CPF inválido, o sistema retorna a mensagem.
  • 111. Cenário 3 – Caso de Teste 7 (incluir um aluno com CPF em branco) Ao tentar incluir um aluno com CPF em branco, o sistema retorna a mensagem. Cenário 3 – Caso de Teste 8 (incluir um aluno com data de nascimento diferente do formato “dd/mm/aaaa”) O sistema não permite a entrada de dados diferente de data no campo
  • 112. Cenário 3 – Caso de Teste 9 (incluir um aluno sem informação de login/senha) Ao tentar incluir um aluno sem informação de login e senha O sistema não permite o cadastro. Cenário 3 – Caso de Teste 11 (incluir um aluno com CPF com letras) Cenário 1 – Caso de Teste 1 deve ter sido executado.
  • 113. Ao tentar incluir um aluno com CPF utilizando letras, o sistema apresenta a mensagem. Cenário 4 – Caso de Teste 1 (deslogar da aplicação) Ao clicar em desconetar
  • 114. O sistema volta para tela de login
  • 115. Apêndice VII – Evidências de Teste reprovados Casos de Teste do Caso de Uso Efetuar Login: Cenário 2 – Caso de Teste 1 (cancelar o login) Não tem opção de Cancelar na tela de login: Cenário 3 – Caso de Teste 1 (fazer login com usuário inexistente) Sistema não exibe mensagem de erro.
  • 116. Cenário 4 – Caso de Teste 1 (fazer login com senha incorreta) Sistema não exibe mensagem de erro. Cenário 3 – Caso de Teste 2 (incluir um aluno com idade com mais de 3 caracteres) Ao incluir idade com 3 caracteres.
  • 117. O sistema inclui o aluno: Cenário 3 – Caso de Teste 3 (incluir um aluno com nome com mais de 255 caracteres) Sistema inclui aluno com nome com mais de 255 caracteres. Cenário 3 – Caso de Teste 4 (incluir um aluno com nome da mãe com mais de 255 caracteres) Ao informar nome da mãe do aluno com mais de 255 caracteres
  • 118. O sistema inclui o aluno. Cenário 3 – Caso de Teste 5 (incluir um aluno com nome do pai com mais de 255 caracteres) Ao informar nome do pai do aluno com mais de 255 caracteres
  • 119. O sistema inclui o aluno. Cenário 3 – Caso de Teste 6 (incluir um aluno com e-mail com mais de 255 caracteres) Sistema inclui aluno com e-mail com mais de 255 caracteres.
  • 120. Cenário 3 – Caso de Teste 10 (incluir um aluno com CPF já existente) Sistema inclui mais de um aluno com mesmo CPF. Cenário 3 – Caso de Teste 12 (incluir um aluno com login já existente) Ao incluir um aluno com um login já existente.
  • 121. O sistema permite a inclusão. Cenário 3 – Caso de Teste 13 (incluir um aluno com login inválido) Sistema permite a inclusão de alunos com login inválido.
  • 122. Cenário 3 – Caso de Teste 14 (incluir um aluno com login com letras) Sistema permite a inclusão de aluno com login composto de letras.
  • 123. Apêndice VIII – Análise de Pontos de Teste (técnica original)
  • 124. Apêndice IX – Análise de Pontos de Teste (planilha SERPRO)
  • 125. Apêndice X – Análise de Pontos de Teste (ferramenta de APT)

×