métricas para estimativa de esforço em projetos de teste de software
DESCRIPTION
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.TRANSCRIPT
Samanta Cicília de Barros Souza
Métricas para Estimativa de Esforço em Projetos de Teste de
Software
Duque de Caxias
2012
UNIVERSIDADE DO GRANDE RIOPROF. JOSÉ DE SOUZA HERDY
ESCOLA DE CIÊNCIA E TECNOLOGIABACHARELADO 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
UNIVERSIDADE DO GRANDE RIOPROF. JOSÉ DE SOUZA HERDY
ESCOLA DE CIÊNCIA E TECNOLOGIABACHARELADO EM SISTEMAS DE INFORMAÇÃO
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
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 Software2. Teste de Software3. Métricas de Estimativa de Esforço
I. EIN/UNIGRANRIO II. Título (série)
Aos meus pais.
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!
“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
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.
SUMÁRIO1 - 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
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
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
LISTA DE FIGURASFigura 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
LISTA DE TABELASTabela 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
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). 58
Tabela 29: Descrição dos Fatores Técnicos de Ambiente. 59
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.
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
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
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
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
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.
THT=HTP+(HTP∗I PC )
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
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
Baixa 3 A função não contem mais que 5
22
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:
Df=(Ue+Uy+ I +C)20
∗U
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
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:
TPf=Pf∗Df∗Qd
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:
PT=∑TPf +(FP∗Qi)
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
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 Descrição
2 Sistema desenvolvido em uma linguagem de 4ª geração, integrada a um sistema de gerenciamento de banco de dados.
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:
HTP=PT∗Qt∗E
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
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:
IPC=(TE+FG )100
O total de horas de teste (THT) é dado pela fórmula:
THT=HTP+(HTP∗IPC ).
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
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
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 Complexidad
e
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
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:
PCTA=∑ (PCTNAi∗Pi)
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 / desinstalar processos de software.
1,09
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 operar, por exemplo, navegadores, sistemas
1,01
30
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.
Númerodecasos de teste=PF 1,2
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
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
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
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
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:
EA=∑ Ef (d)dias
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:
r=ErmsWEa
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:
T=(1+r)∗( SWEa
)
É 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:
WEa=∑ (EAn∗Ntcn)
∑ Ntcn
35
Já o Erms é dado pela seguinte fórmula, sendo n o número de CETs até o momento:
Erms=√∑ (WEa−Ea)²n
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:
Pt=Pn∗N+Pe∗E
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
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:
PCUA=PCUNA∗[0,65+(0,01∗FTA)]
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:
Esforço=PCUA∗(3ou7,5)
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
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
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
- 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
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
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
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
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
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
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
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
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, pode-
se 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
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
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
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
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
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
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
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
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
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 Depois da Melhoria
TD AR/TR Complex. PF
1 Arquivo Aluno
ALI 9 1 Baixa 7
2 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
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
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
Total 4
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
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 Disponibilidade Classificação Valor da Disponibilidade
Valor da Classificação
Ambiente de Teste
Totalmente Disponível
É primordial 5 4
Documentação de Teste
Totalmente Disponível
É 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
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
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
utilizadas levam em consideração que determinada característica tem peso maior que outra,
62
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
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
63
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
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
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.
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-pontos-
de-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/idoese2007-
aranha_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.
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
%2Fieeexplore.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.
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.
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
Grupo
Número de participantes por 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
Descrição sobre ameaças à validade
do estudo.
Hipóteses nulas do estudo.
Resultados Estatíscos das
Avaliações Empíricas
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.
Apêndice II – Artigos do protocolo de quasi-Revisão
Sistemática
Título StatusA discrete software reliability growth model with testing effort IncluídoA metric suite for early estimation of software testing effort using requirement engineering document and its validation IncluídoA Simple Approach for Estimation of Execution Effort of Functional Test Cases IncluídoA Multi-objective Particle Swarm Optimization for Test Case Selection Based on Functional Requirements Coverage and Execution Effort IncluídoAn experience-based approach for test execution effort estimation IncluídoAn Alternative Approach to Test Effort Estimation Based on Use Cases IncluídoEstimate test execution effort at an early stage: An empirical study IncluídoAn Estimation Model for Test Execution Effort IncluídoOptimal software release using time and cost benefits via fuzzy multi-criteria and fault tolerance IncluídoSoftware testing sizing in incremental development: A case study IncluídoAn Experience-Based Approach for Test Execution Effort Estimation IncluídoMachine learning methods and asymmetric cost function to estimate execution effort of software testing IncluídoThe COTECOMO: COnstractive Test Effort COst MOdel IncluídoOn estimating testing effort needed to assure field quality in software development IncluídoMeasuring Program Similarity: Experiments with SPEC CPU Benchmark Suites ExcluídoEnhancement of Bug Tracking Tools; the Debugger ExcluídoMultidimentional size measure for design of component-based software system ExcluídoA method for a priori implementation effort estimation for hardware design ExcluídoThe personal software process: experiences from Denmark ExcluídoOn the Accuracy of Spectrum-based Fault Localization ExcluídoPractical change impact analysis based on static program slicing for industrial software systems ExcluídoAutomating Function Points analysis based on functional and non functional requirements text ExcluídoPath-based error coverage prediction ExcluídoEstimating the Cost of Developing Customizations to Packaged Application Software Using Service Oriented Architecture ExcluídoA GP effort estimation model utilizing line of code and methodology for NASA software projects ExcluídoMeasuring 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ídoStandard multispectral environment and effects model (STMEEM) ExcluídoTest effort estimation-particle swarm optimization based approach ExcluídoQuantitative Quality Assurance Approach ExcluídoOn the false path problem in hard real-time programs ExcluídoPerformance Evaluation of Windowing Approach on Effort Estimation by Analogy ExcluídoBenefits of a TPS virtual layer ExcluídoRelease planning under fuzzy effort constraints ExcluídoCOTS Integrations: Effort Estimation Best Practices ExcluídoTest Effort Estimation Models Based on Test Specifications ExcluídoTest blueprint: an effective visual support for test coverage ExcluídoState Estimation Simulation for the Design of an Optimal On-Line Solution ExcluídoApplying Test-First and Parallel Processing Techniques to ERP Data Conversion ExcluídoParameter tuning of evolutionary algorithm by Meta-EAs for WCET analysis ExcluídoThe role of modeling in the performance testing of e-commerce applications ExcluídoUsing Evolutionary Testing to Find Test Scenarios for Hard to Reproduce Faults ExcluídoMeasures of testability as a basis for quality assurance ExcluídoReliability-growth analysis for an Ada-coding process ExcluídoTUPUX: An Estimation Tool for Incremental Software Development Projects ExcluídoSingle event upset test structures for digital CMOS application specific integrated circuits ExcluídoTightly-coupled image-aided inertial relative navigation using Statistical Predictive Rendering (SPR) techniques and a priori world Models ExcluídoDoes ""Depth"" Really Matter? On the Role of Model Refinement for Testing and Reliability ExcluídoComparing fault-proneness estimation models ExcluídoMedIGrid: a medical imaging application for computational Grids ExcluídoA Constructive RBF Neural Network for Estimating the Probability of Defects in Software Modules ExcluídoPredicting software defects: A cost-sensitive approach ExcluídoBuilding Scalable Failure-proneness Models Using Complexity Metrics for Large Scale Software Systems ExcluídoThe Soft Computing Approach to Program Development Time Estimation ExcluídoDegrees of consciousness for reuse of software in practice: Maintainability, balance, standardization ExcluídoApplying event-condition-action mechanism in healthcare: a computerised clinical test-ordering protocol system (TOPS) ExcluídoDesign of a mission management system for the autonomous underwater vehicle MARIUS ExcluídoObject oriented metrics useful in the prediction of class testing complexity ExcluídoUsing 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ídoAdaptive least mean square behavioral power modeling ExcluídoSimulation-Based Timing Analysis of Complex Real-Time Systems ExcluídoAutomated System Testing Using Visual GUI Testing Tools: A Comparative Study in Industry ExcluídoAn overview of Lutess a specification-based tool for testing synchronous software ExcluídoCARIAL: Cost-Aware Software Reliability Improvement with Active Learning ExcluídoA blended approach to course design and pedagogy to impart soft skills: An IT company's experiences from software engineering course ExcluídoA software falsifier ExcluídoReal-Time Synchronization on Multiprocessors: To Block or Not to Block, to Suspend or Spin? ExcluídoNSTB version 2 flight test results ExcluídoA cost model for determining the optimal number of software test cases ExcluídoDeadline analysis of interrupt-driven software ExcluídoCost excessive paths in cloud based services ExcluídoKnowledge evaluation procedure based on concept maps ExcluídoA trade-off method between cost and reliability ExcluídoOpenRDK: A modular framework for robotic software development ExcluídoProcessor allocation in parallel systems ExcluídoModeling maintenance effort by means of dynamic systems ExcluídoDynamic model for maintenance and testing effort ExcluídoExperiences in implementation and use of the square root information filter/smoother for orbit determination ExcluídoAchieving composability in NoC-based MPSoCs through QoS management at software level ExcluídoAutomatic, Selective and Secure Deletion of Digital Evidence ExcluídoImpact of programming and application-specific knowledge on maintenance effort:A hazard rate model ExcluídoOptimizing and simplifying software metric models constructed using maximum likelihood methods ExcluídoIntegrating generalized Weibull-type testing-effort function and multiple change-points into software reliability growth models ExcluídoA Study of Applying Extended PIE Technique to Software Testability Analysis ExcluídoAn Investigation of Software Effort Phase Distribution Using Compositional Data Analysis ExcluídoDemonstration of AGENDA tool set for testing relational database applications ExcluídoMaximum-Likelihood Estimation of Haplotype Frequencies in Trio Pedigrees ExcluídoAnalysis of a software reliability growth model with logistic testing-effort function ExcluídoOptimal Regression Testing Based on Selective Coverage of Test Requirements ExcluídoWork in progress — An investigation of varied game-based learning systems in engineering education Excluído
Techniques of maintaining evolving component-based software ExcluídoOptimal allocation of testing-resource considering cost, reliability, and testing-effort ExcluídoSoftware reliability modeling and cost estimation incorporating testing-effort and efficiency ExcluídoOptimal release time for software systems considering cost, testing-effort, and test efficiency ExcluídoEffort-index-based software reliability growth models and performance assessment ExcluídoA Value Estimation Method for Feature-Oriented Requirements Tracing ExcluídoA code inspection model for software quality management and prediction ExcluídoA defect estimation approach for sequential inspection using a modified capture-recapture model ExcluídoAn integrated diagnostic support system approach to fault isolation in the operational environment ExcluídoCost modeling process maturity-COCOMO 2.0 ExcluídoSoftware organization to facilitate dynamic processor scheduling ExcluídoA lightweight software control system for cyber awareness and security ExcluídoCalculation of core loss in a novel transformer design ExcluídoApplying support vector regression for web effort estimation using a cross-company dataset ExcluídoAvailable work time estimation ExcluídoIs the need to follow chains a possible deterrent to certain refactorings and an inducement to others? ExcluídoA change prediction model for embedded software applications ExcluídoGuiding reengineering with the operational profile ExcluídoIT Project Variables in the Balance: A Bayesian Approach to Prediction of Support Costs ExcluídoEarly Models for System-Level Power Estimation ExcluídoUsing 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] ExcluídoMonte carlo simulation based estimations: Case from a global outsourcing company ExcluídoGERT: an empirical reliability estimation and testing feedback tool ExcluídoReusing Existing Test Cases for Security Testing ExcluídoStatic and dynamic software metrics complexity analysis in regression testing ExcluídoData Mining Techniques for Software Effort Estimation: A Comparative Study ExcluídoOpenSim: Open-Source Software to Create and Analyze Dynamic Simulations of Movement ExcluídoPost-silicon bug diagnosis with inconsistent executions ExcluídoA Time Delay Compensation Method Improving Registration for Augmented Reality ExcluídoA Parallel Genetic Algorithm Based on Hadoop MapReduce for the Automatic Generation of JUnit Test Suites ExcluídoThe 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ídoVirtual Testbed for Assessing Probe Vehicle Data in IntelliDrive Systems ExcluídoTwo-Dimensional Software Reliability Models and Their Application ExcluídoLessons learned during the successful execution of a legacy Automated Test System (ATS) re-host ExcluídoAn Approach to the Modeling of Software Testing with Some Applications ExcluídoSimplified workload characterization using unified prediction ExcluídoObject-oriented legacy system trace-based logic testing ExcluídoEnsuring Long-Term Access to Remotely Sensed Data With Layout Maps ExcluídoCAME tools for an efficient software maintenance ExcluídoToward Harnessing High-Level Language Virtual Machines for Further Speeding Up Weak Mutation Testing ExcluídoProcess modeling of integrated circuit device technology ExcluídoEvaluation and application of complexity-based criticality models ExcluídoDynamic feature traces: finding features in unfamiliar code ExcluídoGetting a handle on the fault injection process: validation of measurement tools ExcluídoA primer on object-oriented measurement ExcluídoWeb Services Open Test Suites ExcluídoOpen Web Services Testing ExcluídoRestructuring unit tests with TestSurgeon ExcluídoPrediction models for software fault correction effort ExcluídoUsing a proportional hazards model to analyze software reliability ExcluídoNon-preemptive interrupt scheduling for safe reuse of legacy drivers in real-time systems ExcluídoExploiting OS-level mechanisms to implement mobile code security ExcluídoAn evaluation of three function point models for estimation of software effort ExcluídoSystem-level metrics for hardware/software architectural mapping ExcluídoA Case Study Using Web Objects and COSMIC for Effort Estimation of Web Applications ExcluídoGenetic Programming for Effort Estimation: An Analysis of the Impact of Different Fitness Functions ExcluídoA metric framework for the assessment of object-oriented systems ExcluídoFrom testing to diagnosis: an automated approach ExcluídoAn exploratory analysis of system test data ExcluídoEarly estimation of the size of VHDL projects ExcluídoAn approach toward reuse of engineering models in the automation of system verification ExcluídoADTEST: a test data generation suite for Ada software systems ExcluídoSoftware test data generation using program instrumentation ExcluídoApplication of vertical test commonality to PALADIN maintenance ExcluídoA knowledge base system used to estimate schedule, effort, staff, documentation and defects in a software development process Excluído
Robust thread-level speculation ExcluídoTesting Processes in Business-Critical Chain Software Lifecycle ExcluídoNeural networks application in software cost estimation: A case study ExcluídoStatistically based parametric yield prediction for integrated circuits ExcluídoA HMMER hardware accelerator using divergences ExcluídoDevelopment platform for WIP bond quality testing system ExcluídoSoftware failure rate and reliability incorporating repair policies ExcluídoFrom test count to code coverage using the Lognormal Failure Rate ExcluídoAnalytical Models for Architecture-Based Software Reliability Prediction: A Unification Framework ExcluídoFPGA Implementation of Abundance Estimation for Spectral Unmixing of Hyperspectral Data Using the Image Space Reconstruction Algorithm ExcluídoRiTMO: A Method for Runtime Testability Measurement and Optimisation ExcluídoDebugging effort estimation using software metrics ExcluídoArchitectural-level risk analysis using UML ExcluídoFactors systematically associated with errors in subjective estimates of software development effort: the stability of expert judgment ExcluídoReverse engineering of GUI models for testing ExcluídoThe Impact of Irrelevant Information on Estimates of Software Development Effort ExcluídoFrom scripts to specifications: the evolution of a flight software testing effort ExcluídoPath Coverage Criteria for Palladio Performance Models ExcluídoA Fuzzy Logic Model Based upon Reused and New & Changed Code for Software Development Effort Estimation at Personal Level ExcluídoOptimized timed hardware software cosimulation without roll-back ExcluídoUsing stochastic models to effectively schedule hardware test efforts ExcluídoSoftware project effort: Different methods of estimation ExcluídoThe SDC DAQSim simulation effort ExcluídoThe SDC DAQSim simulation effort ExcluídoSoftware Project Level Estimation Model Framework based on Bayesian Belief Networks ExcluídoInsights in Implementing Collaboration Engineering ExcluídoInterval Type-2 Fuzzy Logic for Software Cost Estimation Using TSFC with Mean and Standard Deviation ExcluídoCPN-a hybrid model for software cost estimation ExcluídoDealing with Test Automation Debt at Microsoft ExcluídoA vector-based approach to software size measurement and effort estimation ExcluídoFormal analysis of a space-craft controller using SPIN ExcluídoEvaluating Dynamic Software Update Safety Using Systematic Testing ExcluídoCATS-an automated user interface for software development and testing ExcluídoA Practical Model for Measuring Maintainability ExcluídoPlanning models for software reliability and cost ExcluídoModeling eddy current analysis data to determine depth of weld penetration Excluído
CiCUTS: Combining System Execution Modeling Tools with Continuous Integration Environments ExcluídoConservative synchronization in object-oriented parallel battlefield discrete event simulations ExcluídoEvaluation of activity monitors to estimate energy expenditure in manual wheelchair users ExcluídoThe role of MPI in development time: A case study ExcluídoPerformance modeling for systematic performance tuning ExcluídoOn Adapting Power Estimation Models for Embedded Soft-Core Processors ExcluídoA source-based risk analysis approach for software test optimization ExcluídoA source-based risk analysis approach for software test optimization ExcluídoExperiences from conducting semi-structured interviews in empirical software engineering research ExcluídoAutomatic generation of a software performance model using an object-oriented prototype ExcluídoParameter estimation for software reliability models considering failure correlation ExcluídoSoftware Reliability Modeling withWeibull-type Testing-Effort and Multiple Change-Points IncluídoResearch on Software Effort Estimation Combined with Genetic Algorithm and Support Vector Regression ExcluídoSoftware rejuvenation: analysis, module and applications ExcluídoInvestigating available instruction level parallelism for stack based machine architectures ExcluídoEstimation of software defects fix effort using neural networks ExcluídoEvaluating the Quality of Models Extracted from Embedded Real-Time Software ExcluídoSeasonal Variation in the Vulnerability Discovery Process ExcluídoValidating and understanding software cost estimation models based on neural networks ExcluídoExtraction test cases by using data mining; reducing the cost of testing ExcluídoTwo-dimensional software reliability measurement technologies ExcluídoExploratory testing: a multiple case study ExcluídoSoftware metrics enhance test data generation and productivity measurement ExcluídoTools and procedures for successful TPS management ExcluídoUsing clone detection to identify bugs in concurrent software ExcluídoEmpirical validation of relational database metrics for effort estimation ExcluídoPhotodiode sensor array design for photovoltaic system inter-row spacing optimization-calculating module performance during in-situ testing / simulated shading ExcluídoA Formal Approach to Pre-Market Review for Medical Device Software ExcluídoReengineering legacy application to e-business with modified Rational Unified Process ExcluídoFull chip false timing path identification: applications to the PowerPCTM microprocessors ExcluídoCan LORAN meet GPS backup requirements? ExcluídoValidation of software effort models Excluído
Fault localization using visualization of test information ExcluídoAvoiding Irrelevant and Misleading Information When Estimating Development Effort ExcluídoThe prediction ability of experienced software maintainers ExcluídoSpectral analysis for characterizing program power and performance ExcluídoOptimal resource allocation and reliability analysis for component-based software applications ExcluídoMethod Study of Software Project Schedule Estimation Guide ExcluídoAssessing software complexity from UML using fractal complexity measure ExcluídoPrediction of fault-proneness at early phase in object-oriented development ExcluídoPitfalls and strategies in automated testing ExcluídoModel-based embedded software development flow ExcluídoTest executive features for improved TPS debug ExcluídoBranch regulation: Low-overhead protection from code reuse attacks ExcluídoAnalysis of quality of object oriented systems using object oriented metrics ExcluídoModel-based testing of embedded systems in hardware in the loop environment ExcluídoExperiments with Analogy-X for Software Cost Estimation ExcluídoOptimising Project Feature Weights for Analogy-Based Software Cost Estimation using the Mantel Correlation ExcluídoAnalogy-X: Providing Statistical Inference to Analogy-Based Software Cost Estimation ExcluídoHardware/Software Codesign Architecture for Online Testing in Chip Multiprocessors ExcluídoDiscovering complete API rules with mutation testing ExcluídoReturn on investment of software quality predictions ExcluídoAssessing uncertain predictions of software quality ExcluídoAre the principal components of software complexity data stable across software products? ExcluídoSoftware quality classification modeling using the SPRINT decision tree algorithm ExcluídoThe cost of code quality ExcluídoAn approach to software project feasibility study using stochastic risk model during proposal preparation ExcluídoRobustness testing framework for Web services composition ExcluídoSide channel analysis countermeasures using obfuscated instructions ExcluídoPairwise Testing in the Presence of Configuration Change Cost ExcluídoDevelopment and implementation of a rail current optimization program ExcluídoDemonstrating robust high data rate capability on a software defined radio using anti-jam wideband OFDM waveforms ExcluídoHow to Find Relevant Data for Effort Estimation? ExcluídoExploiting the Essential Assumptions of Analogy-Based Effort Estimation ExcluídoAI-Based Models for Software Effort Estimation ExcluídoModeling search in group decision support systems ExcluídoRuntime control of Ada rendezvous for testing and debugging ExcluídoApplying 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ídoCost Reduction through Combining Test Sequences with Input Data ExcluídoDomain specific phase by phase effort estimation in software projects ExcluídoGeneration of efficient test data using path selection strategy with elitist GA in regression testing ExcluídoCan we certify systems for freedom from malware ExcluídoPragmatic study of parametric decomposition models for estimating software reliability growth ExcluídoAnalysis of incorporating logistic testing-effort function into software reliability modeling ExcluídoPhotovoltaic reliability model development and validation ExcluídoTPartition: testbench partitioning for hardware-accelerated functional verification ExcluídoThe Limitations of Estimation ExcluídoTechniques for efficient wireless communication systems modeling using C++ ExcluídoAutomated detection of injected faults in a differential equation solver ExcluídoSoftware effort estimation with a generalized robust linear regression technique ExcluídoOn generating test data from prototypes ExcluídoEvaluating an Interactive-Predictive Paradigm on Handwriting Transcription: A Case Study and Lessons Learned ExcluídoInteractive software package for digital signal processing ExcluídoLife cycle cost (LCC) estimating for large management information system (MIS) software development projects ExcluídoSoftware diagnosability ExcluídoA Bayesian Net Based Effort Estimation Model for Service Governance Processes ExcluídoAutomatic Regression Test Selection Based on Activity Diagrams ExcluídoFeedback-Directed Test Case Generation Based on UML Activity Diagrams ExcluídoUnderstanding soft error propagation using Efficient vulnerability-driven fault injection ExcluídoReuse economics: a comparison of seventeen models and directions for future research ExcluídoDevelopment of fuzzy-logic processing objects for industrial control applications ExcluídoIntegrating Model-Based Testing with Evolutionary Functional Testing ExcluídoSoftware reliability estimation for modular software systems and its applications ExcluídoSizing and estimating the coding and unit testing effort for GUI systems ExcluídoApplying moving windows to software effort estimation ExcluídoInvestigating the use of chronological split for software effort estimation ExcluídoAutomated maintenance of avionics software ExcluídoA naive Bayesian Belief Network model for predicting effort deviation rate in software testing ExcluídoEstimate Test Execution Effort at an Early Stage: An Empirical Study IncluídoUsing prior-phase effort records for re-estimation during software projects ExcluídoA strategy for autogeneration of space shuttle ground processing simulation models for project makespan estimation Excluído
Intelligent, adaptive file system policy selection ExcluídoCritical-Path-Guided Interactive Parallelisation ExcluídoDoD/MOD coalition efforts for ATS ExcluídoA parameterized cost model to order classes for class-based testing of C++ applications ExcluídoPrioritization of Test Cases Using Software Agents and Fuzzy Logic ExcluídoAutomatic program instrumentation in generation of test data using genetic algorithm for multiple paths coverage ExcluídoTalking about a Mutation-Based Reverse Engineering for Web Testing: A Preliminary Experiment ExcluídoDynamic Analysis for Diagnosing Integration Faults Excluídomake test-zesti: A symbolic execution solution for improving regression testing ExcluídoIntegration of embedded, real-time, Ada, operational flight programs with off-line engineering level-of-detail digital models ExcluídoEfficient Testbench Code Synthesis for a Hardware Emulator System ExcluídoA Multi-step Simulation Approach toward Secure Fault Tolerant System Evaluation ExcluídoVIDA: Visual interactive debugging ExcluídoStudying the fault-detection effectiveness of GUI test cases for rapidly evolving software ExcluídoComparing effort prediction models for Web design and authoring using boxplots ExcluídoUsing an engineering approach to understanding and predicting Web authoring and design ExcluídoExploiting the forgiving nature of applications for scalable parallel execution ExcluídoLocal vs. global models for effort estimation and defect prediction ExcluídoValidation methods for calibrating software effort models ExcluídoSelecting Best Practices for Effort Estimation ExcluídoPredicated software pipelining technique for loops with conditions ExcluídoUsing RFID Technologies to Capture Simulation Data in a Hospital Emergency Department ExcluídoSize-Constrained Regression Test Case Selection Using Multicriteria Optimization ExcluídoAutomated calibration aids smooth turnover of new plants ExcluídoA Regression Testing Approach for Software Product Lines Architectures ExcluídoLeast squares support vector machines with genetic algorithm for estimating costs in NPD projects ExcluídoUsing designer's effort for user interface evaluation ExcluídoDynamic output analysis for simulations of manufacturing environments ExcluídoEvolving process simulators by using validated learning ExcluídoCode churn: a measure for estimating the impact of code change ExcluídoU.S. Army Modeling and Simulation Executable Architecture Deployment Cloud Virtualization Strategy ExcluídoSensitivity of field failure intensity to operational profile errors ExcluídoAllow plenty of time for large-scale software ExcluídoUsing In-Process Testing Metrics to Estimate Post-Release Field Quality Excluído
Adjustable Cost Estimation Model for COTS-Based Development ExcluídoHardware speech recognition for user interfaces in low cost, low power devices ExcluídoLessons from using Z to specify a software tool ExcluídoManaging OO projects better ExcluídoAssessing the real-time properties of Windows CE 3.0 ExcluídoTransition-based testability analysis for reactive systems ExcluídoInserting software fault measurement techniques into development efforts ExcluídoImpact of Budget and Schedule Pressure on Software Development Cycle Time and Effort ExcluídoBasic metrics for performance estimation of computers ExcluídoTowards the Integration of Quality Attributes into a Software Product Line Cost Model ExcluídoImproved testing using failure cost and intensity profiles ExcluídoReggae: Automated Test Generation for Programs Using Complex Regular Expressions ExcluídoQuantifying the Effectiveness of Testing Efforts on Software Fault Detection with a Logit Software Reliability Growth Model ExcluídoA Multi-factor Software Reliability Model Based on Logistic Regression ExcluídoWhen PIGs Fly - addressing software reliability concerns for the IRIS IP router operating system ExcluídoA service operations software creation environment for advanced intelligent networks ExcluídoIs parallelism for you? ExcluídoA Symbolic Execution Tool Based on the Elimination of Infeasible Paths ExcluídoA case study: Developing a complete test program using IEEE 1641 ExcluídoApplication and Comparison of Particle Swarm Optimization and Genetic Algorithm in Strategy Defense Game ExcluídoPath selection in the structural testing: proposition, implementation and application of strategies ExcluídoA new metrics set for evaluating testing efforts for object-oriented programs ExcluídoAn experiment for evaluating the effectiveness of using a system dynamics simulation model in software project management education ExcluídoA software-reliability growth model for N-version programming systems ExcluídoNew probabilistic measures for accelerating the automatic test pattern generation algorithm ExcluídoReducing Corrective Maintenance Effort Considering Module's History ExcluídoIntegrating testability analysis tools with automatic test systems (ATS) ExcluídoWhat makes inspections work? ExcluídoA Fast Algorithm for Nonparametric Probability Density Estimation ExcluídoAn experiment measuring the effects of personal software process (PSP) training ExcluídoHow not to do agile testing ExcluídoYear 2000 work comes down to the wire ExcluídoSoft-OLP: Improving Hardware Cache Performance through Software-Controlled Object-Level Partitioning ExcluídoGuide: A GUI differentiator Excluído
Benefits and limitations of automated software testing: Systematic literature review and practitioner survey ExcluídoReliability estimation for a software system with sequential independent reviews ExcluídoOvercoming the challenges in cost estimation for distributed software projects ExcluídoMetrics of software evolution as effort predictors - a case study ExcluídoOn determining the software testing cost to assure desired field reliability ExcluídoEffect of variability of a framework upon its testing effort: An empirical evaluation ExcluídoAutomated GUI Test Coverage Analysis Using GA ExcluídoSimple and effective techniques for core-region detection and slant correction in offline script recognition ExcluídoF-14 flight control law design, verification, and validation using computer aided engineering tools ExcluídoIndustrial experiences with automated regression testing of a legacy database application ExcluídoSpace mission operations DBMS (SMOD) ExcluídoA Mutation/Injection-Based Automatic Framework for Evaluating Code Clone Detection Tools ExcluídoUsing Web objects for estimating software development effort for Web applications ExcluídoDAISY: An efficient tool to test global identifiability. Some case studies ExcluídoA Formal Approach for Design of Agent Based Earthquake Management System (EMS) ExcluídoInterface Coverage Criteria Supporting ModelüBased Integration Testing ExcluídoDesign for testability in embedded software projects ExcluídoOn Equivalence Partitioning of Code Paths inside OS Kernel Components ExcluídoPerformance modeling using object-oriented execution-driven simulation ExcluídoA new approach for estimation of software testing process based on software requirements ExcluídoDevelopment of Fuzzy Software Operational Profile ExcluídoProfiling the Operational Behavior of OS Device Drivers ExcluídoA model-based approach for executable specifications on reconfigurable hardware ExcluídoMultichannel dynamic range compression for music signals ExcluídoPocket Estimator -- A Commercial Solution to Provide Free Parametric Software Estimation Combining an Expert and a Learning Algorithm ExcluídoPredicting Defects and Changes with Import Relations ExcluídoAccelerating system integration by enhancing hardware, firmware, and co-simulation ExcluídoDiscovering determinants of high volatility software ExcluídoA decision theory framework for software fault correction ExcluídoTool support for collaborative software prototyping ExcluídoA cost-effective approach to testing ExcluídoDevCOP: A Software Certificate Management System for Eclipse ExcluídoPragmatic prioritization of software quality assurance efforts ExcluídoA micro software reliability model for prediction and test apportionment ExcluídoStandards-software reliability handbook: achieving reliable software Excluído
Model driven testing of embedded automotive systems with timed usage models ExcluídoApplying the Use Case Points effort estimation technique to Avionics Systems ExcluídoMachine Learning Methods and Asymmetric Cost Function to Estimate Execution Effort of Software Testing ExcluídoWeighted Least Absolute Value state estimation using interior point methods ExcluídoReconfigurable hardware SAT solvers: a survey of systems ExcluídoExperiences with Target-Platform Heterogeneity in Clouds, Grids, and On-Premises Resources ExcluídoA stochastic model of human errors in software development: impact of repair times ExcluídoMeasuring web service interfaces ExcluídoImpact analysis of maintenance tasks for a distributed object-oriented system ExcluídoKeynote Abstract ExcluídoEffort Estimates for Vulnerability Discovery Projects ExcluídoA novel approach to calculate the severity and priority of bugs in software projects Excluído3D recovery with free hand camera motion ExcluídoA comprehensive approach for modeling and testing analog and mixed-signal devices ExcluídoMachine learning approaches to estimating software development effort ExcluídoActive memory processor: a hardware garbage collector for real-time Java embedded devices ExcluídoOptimal software release using time and cost benefits via fuzzy multi-criteria and fault tolerance
ExcluídoExcluído
Software testing effort: An assessment through fuzzy criteria approach ExcluídoTest sequence optimisation: An intelligent approach via cuckoo search ExcluídoSoftware test effort estimation: A model based on cuckoo search ExcluídoBetter testing through oracle selection: (NIER track) ExcluídoHiPPAI: High Performance Portable Accelerator Interface for SoCs ExcluídoA virtual instrumentation-based on-line determination of a single/two phase induction motor drive characteristics at coarse start-up ExcluídoIncremental Workflow Mining with Optional Patterns ExcluídoOn the reliability of benefit transfer: case of the Japanese e-health system ExcluídoFramework for modeling software reliability, using various testing-efforts and fault-detection rates ExcluídoThe perceived value of authoring and automating acceptance tests using a model driven development toolset ExcluídoImprovement of Software Process by Process Description and Benefit Estimation ExcluídoResource-aware scientific computation on a heterogeneous cluster ExcluídoA Domain Specific Language for Reconfigurable Path-based Monte Carlo Simulations ExcluídoAdvancements in Distributed Generation Issues Interconnection, Modeling, and Tariffs ExcluídoExperience from Quality Assurance in Nuclear Power Plant Protection System Software Validation ExcluídoCOM-based test foundation framework ExcluídoMigrating software testing to the cloud Excluído
Parameterized unit testing: theory and practice ExcluídoThe accuracy of fault prediction in modified code - statistical model vs. expert estimation ExcluídoInternal and External Software Benchmark Repository Utilization for Effort Estimation ExcluídoImplementation of a Software Quality Improvement Project in an SME: A Before and After Comparison ExcluídoEngineering real-time behavior ExcluídoSoft computing for propulsion control ExcluídoAutomated distributed system testing: designing an RTI verification system ExcluídoA progressive software development lifecycle ExcluídoEnsemble imputation methods for missing software engineering data ExcluídoApplying Particle Swarm Optimization to estimate software effort by multiple factors software project clustering Excluído“Plug and test” - software agents in virtual environments ExcluídoAn Analysis of Cost-Overrun Projects Using Financial Data and Software Metrics ExcluídoSLIF: a specification-level intermediate format for system design ExcluídoPerceived Effects of Pair Programming in an Industrial Context ExcluídoEstimation of Test Code Changes Using Historical Release Data ExcluídoAutomated Test Case Generation of Self-Managing Policies for NASA Prototype Missions Developed with ASSL ExcluídoEffective Migration of Enterprise Applications in Multicore Cloud ExcluídoUsing Best Practices of Software Engineering into a Real Time System Development ExcluídoA low-cost distributed instrumentation system for monitoring, identifying and diagnosing irregular patterns of behavior in critical ITS components ExcluídoCaspar: Hardware patching for multicore processors ExcluídoAn Evaluation of Two Bug Pattern Tools for Java ExcluídoPractical techniques for distributed real-time simulation ExcluídoQuality planning for software development ExcluídoFunction Call Flow based Fitness Function Design in Evolutionary Testing ExcluídoCIMDS: Adapting Postprocessing Techniques of Associative Classification for Malware Detection ExcluídoA new yield optimization algorithm and its applications ExcluídoThe Use of Product Measures in Tracking Code Development to Completion within Small to Medium Sized Enterprises ExcluídoExploiting WSRF and WSRF.NET for Remote Job Execution in Grid Environments ExcluídoTest forensics: A guide to evaluating TPS transportability ExcluídoTest forensics: A guide to evaluating TPS transportability ExcluídoSmart test program set (TPS) ExcluídoSmart Test Program Set (TPS) ExcluídoSoftware fault localization based on program slicing spectrum ExcluídoAn Architecture-Based Software Reliability Modeling Tool and Its Support for Teaching ExcluídoEmulation and enhancement of the Honeywell 2600 automatic test station Excluído
Estimating the software development schedules for advanced products ExcluídoSensor modeling, probabilistic hypothesis generation, and robust localization for object recognition ExcluídoEfficient forward computation of dynamic slices using reduced ordered binary decision diagrams ExcluídoA modified function point method for CAL systems with respect to software cost estimation ExcluídoProblem identification for structural test generation: first step towards cooperative developer testing ExcluídoEarly Estimate the Size of Test Suites from Use Cases ExcluídoPerformance debugging in the large via mining millions of stack traces ExcluídoImproving Effectiveness of Automated Software Testing in the Absence of Specifications ExcluídoA model of open source software maintenance activities ExcluídoTesting Scenario Implementation with Behavior Contracts ExcluídoPrecise identification of problems for structural test generation ExcluídoSoftware Reliability Growth Models with Testing-Effort ExcluídoUsing Weighted Attributes to Improve Cluster Test Selection ExcluídoSentomist: Unveiling Transient Sensor Network Bugs via Symptom Mining ExcluídoA New Strategy for Pairwise Test Case Generation ExcluídoAn Agglomerative Clustering Methodology For Data Imputation ExcluídoProfiling file repository access patterns for identifying data exfiltration activities ExcluídoAnalysis and enhancement of software dynamic defect models ExcluídoResearch and Implementation of Automatic Business Health-Checking Framework ExcluídoExperimental Validation of Channel State Prediction Considering Delays in Practical Cognitive Radio ExcluídoRapid prototyping of complex interactive simulation systems ExcluídoA Dynamic Test Cluster Sampling Strategy by Leveraging Execution Spectra Information ExcluídoAdaptation of high level behavioral models for stuck-at coverage analysis Excluído
Apêndice III – Regras de Negócio Sistema Escola
Histórico de Versões
Data Versão Descrição Autor Revisor Aprovado por
22/11/2010 1.0Versão inicial da
Especificação de Regras de Negócio
Thiago Silva <nome> <nome>
24/11/2010 1.1 Inclusão de restrições de campos 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
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.
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
22/11/2010 1.0Versão inicial da
Especificação de Caso de Uso
Thiago Silva <nome> <nome>
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 AtorTipo
Primário SecundárioAdministrador X
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.
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
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.0Versã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
Nome AtorTipo
Primário SecundárioAdministrador X
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 AlunoP3.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 AlunoP3.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
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
Não há anexos.
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).
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: [email protected]
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.
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: [email protected]
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 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: [email protected]
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.
3. Informar os seguintes dados:
CPF: 55478311669
Nome:
testecommaisde255caracterestestecommaisde255caracterestestecommaisde255car
acterestestecommaisde255caracterestestecommaisde255caracterestestecommaisde
255caracterestestecommaisde255caracterestestecommaisde255caracterestestecom
maisde255caracterestestecommaisde255caracterestestecommaisde255caracterestes
tecommaisde255caracterestestecommaisde255caracterestestecommaisde255caract
erestestecommaisde255caracteres
Email: [email protected]
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: [email protected]
Nome mãe:
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: [email protected]
Nome mãe: Maria Dias
Nome pai:
testecommaisde255caracterestestecommaisde255caracterestestecommaisde255car
acterestestecommaisde255caracterestestecommaisde255caracterestestecommaisde
255caracterestestecommaisde255caracterestestecommaisde255caracterestestecom
maisde255caracterestestecommaisde255caracterestestecommaisde255caracterestes
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
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: [email protected]
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.
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: [email protected]
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: [email protected]
Nome mãe: Sônia Rose
Nome pai: José Brant
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: [email protected]
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.
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: [email protected]
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: [email protected]
Nome mãe: João Lima
Nome pai: Maria Dias
Data de nascimento: 12/02/80
Idade: 30
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: [email protected]
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.
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:
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
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
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
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.
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
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.
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
O sistema volta para tela de login
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.
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.
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
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
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.
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.
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.
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.
Apêndice VIII – Análise de Pontos de Teste (técnica original)
Apêndice IX – Análise de Pontos de Teste (planilha SERPRO)
Apêndice X – Análise de Pontos de Teste (ferramenta de
APT)