TestaProjeto - monografias.poli.ufrj.brmonografias.poli.ufrj.br/monografias/monopoli10010490.pdfMVC - Model-View-Control; COCOMO - COnstructive COst MOdel; RMMM - Risk Mitigation,

Universidade Federal do Rio de Janeiro

Escola Politécnica

Departamento de Eletrônica e de Computação

TestaProjeto

Autor:

_________________________________________________

Tiago Soares Carvalho

Orientador:

_________________________________________________

Prof. Antonio Cláudio Gómez de Sousa, Dr.

Examinador:

_________________________________________________

Prof. Aloysio de Castro Pinto Pedroza, Dr.

Examinador:

_________________________________________________

Prof. Victor Paulo Peçanha Esteves, M.Sc.

DEL

Março de 2014

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

Escola Politécnica – Departamento de Eletrônica e de Computação

Centro de Tecnologia, bloco H, sala H-217, Cidade Universitária

Rio de Janeiro – RJ CEP 21949-900

Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que

poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar

qualquer forma de arquivamento.

É permitida a menção, reprodução parcial ou integral e a transmissão entre

bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja

ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem

finalidade comercial e que seja feita a referência bibliográfica completa.

Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es) e

do(s) orientador(es).

AGRADECIMENTO

Um especial agradecimento a meus pais, Heyder e Tania, que sempre me

apoiaram e que quando faltou energias para continuar esse projeto, sempre me

emprestaram a deles e fizeram de tudo para que tudo que eu precisasse estivesse

disponível para mim. Foram uma inspiração para que eu nunca desistisse.

A minha irmã Julia, pelo apoio e carinho.

Aos meus familiares que sempre acreditaram no meu potencial e sempre

estimularam que eu alcançasse o melhor que eu possa ser.

Aos meus amigos, pelo bom humor e companheirismo que melhoravam os dias

ruins.

A todos aqueles que quando me faltou conhecimento, puderam me ensinar e ter

paciência comigo.

Ao meu orientador neste trabalho, Prof. Antônio Cláudio Gómez de Sousa, pelos

ensinamentos e apoio, e que se mostrou uma pessoa de grande sensibilidade e

compreensão.

Ao Instituto de Pesquisa da Marinha que me deu experiência e um contato maior

com a área de programação e assim, uma visão da aplicação dos ensinamentos.

Ao coordenador do curso de Engenharia Eletrônica e de Computação, Prof. José

Carlos Ribas D’Ávila, pela presteza em ajudar e pela ajuda em uma hora difícil.

Ao meu orientador acadêmico, Prof. Jomar Gozzi, por sanar minhas dúvidas e

me guiar durante o curso, principalmente no início desta caminhada.

A todos os professores da Universidade Federal do Rio de Janeiro, em especial

aqueles do DEL/POLI por terem me tornado um engenheiro capacitado e pronto para

enfrentar os desafios da vida profissional.

RESUMO

Este trabalho descreve o projeto e a implementação de um sistema web de

automação de testes, aumentando a complexidade e variedade de testes que possam ser

utilizados, possibilitando a criação de uma base de testes para futuros projetos. Nesse

sentido, será possível criar uma gama de casos de teste para formados que venham a

lançar mão desta ferramenta e que possuam acesso a um programa open source.

Palavras-Chave: Automação de Teste; Plano de Teste; Caso de Teste; Teste de

Software.

ABSTRACT

This paper describes the design and implementation of a web test automation,

increasing the complexity and variety of tests that can be used, enabling the creation of

a testing ground for future projects. In this sense, it´s possible to create a range of test

cases for graduates who will make use of this tool and having access to an open source

program.

Keywords: Test Automation; Test Plan; Test Cases; Software Testing.

SIGLAS

CMMI - Capability Maturity Model Integration;

UFRJ - Universidade Federal do Rio de Janeiro;

IDE - Integrated Development Environment;

HSQL - Hyper Structured Query Language;

CSS – Cascade Style Sheet;

HTML – Hypertext Markup Language;

BD - Banco de dados;

Java EE - Java Enterprise Edition;

MVC - Model-View-Control;

COCOMO - COnstructive COst MOdel;

RMMM - Risk Mitigation, Monitoring and Management;

ERS - Especificação de Requisitos de Software;

UML - Unified Modeling Language.

JRuby - Implementação da linguagem Ruby para a plataforma Java

Sumário

1 INTRODUÇÃO 1 1

1.1 Tema 1 1

1.2 Delimitação 1 1

1.3 Justificativa 1 1

1.4 Objetivos 2 2

1.5 Metodologia 2 2

1.6 Descrição 3

3

2 AUTOMAÇÃO DE TESTES 4 4

2.1 Introdução 4 4

2.1.1 Regra 10 de Myers 6 6

2.2 Processo de Construção de Software 7 7

2.3 Validação e Verificação 9 9

2.4 Teste de Software 10 10

2.4.1 Teste de Sistemas 11 10

2.4.1.1 Teste de Integração 11 11

2.4.1.2 Teste de Releases 11 11

2.4.1.3 Teste de Desempenho 11 11

2.4.2 Teste de Componente 11 11

2.4.2.1 Teste de Interfaces 12 11

2.4.3 Projeto de casos de teste 12

12

3 PLANEJAMENTO DO PROJETO 13 13

3.1 Apresentação 13 13

3.1.1 Sumário do Projeto 13 13

3.1.1.1 Finalidade,Escopo e Objetivo 13 13

3.1.1.2 Postulados e Restrições 13 13

3.1.1.3 Liberações Parciais 13 13

3.1.2 Sumário de Cronograma e Orçamento 14 14

3.2 Referências 14 14

3.3 Definições 14 14

3.4 Organização do Projeto 15 14

3.4.1 Interfaces Externas 15 15

3.4.2 Estrutura Interna 15 15

3.4.3 Papéis e Responsabilidades 15 15

3.5 Processos de Gerenciamento 15 15

3.5.1 Previsões 15 15

3.5.2 Equipe 16 15

3.5.3 Plano para Aquisição de Recursos 16 16

3.5.4 Plano de Treinamento da Equipe 16 16

3.6 Plano de Trabalho 16 16

3.6.1 Atividades 16 16

3.6.2 Alocação de Recursos 17 16

3.6.3 Alocação de Orçamento 17 17

3.7 Planos de Controle 17 17

3.8 Plano de Gerenciamento de Riscos 18 17

3.8.1 Plano de Encerramento 19 18

3.9 Processos Tecnicos 19 19

3.9.1 Modelo dos Processos 19 19

3.9.2 Métodos, Ferramentas e Técnicas 19 19

3.9.3 Infraestrutura 19 19

3.9.4 Plano para a Aceitação do Produto 19 19

3.10 Plano para os Processos de Suporte 20 19

3.10.1 Plano de Gerenciamento de Configuração 20 19

3.10.2 Plano de Verificação e Validação 20 19

3.10.3 Documentação 20 20

3.10.4 Plano para Assegurar a Qualidade 20 20

3.10.5 Revisões e Auditorias 20 20

3.10.6 Plano para a Resolução de Problemas 20

20

4 ESPECIFICAÇÃO DE REQUISITOS 21 21


4.1.1 Finalidade 21 21

4.1.2 Escopo 21 21

4.1.3 Definições,Acrônimos e Abreviaturas 21 21

4.1.4 Referências 21 21

4.1.5 Resumo 21 21

4.2 Descrição Geral 22 22

4.2.1 Perspectiva do Produto 22 22

4.2.2 Funções do Produto 22 22

4.2.3 Características do Usuário 22 22

4.2.4 Restrições 22 22

4.2.5 Pressupostos e Dependências 23 22

4.2.6 Postergar Requisitos 23 23

4.3 Requisitos Específicos 23 23

4.3.1 Interfaces Externas 23 23

4.3.1.1 Interfaces dos Usuários 23 23

4.3.1.2 Interfaces de Hardware 23 23

4.3.1.3 Interfaces de Software 23 23

4.3.1.4 Interfaces de Comunicação 24 23

4.3.2 Requisitos Funcionais 24 23

4.3.2.1 Diagrama de Casos de Uso 24 23

4.3.3 Diagrama de Classes 31 30

4.3.4 Dicionário de Dados 32 31

4.3.5 Diagrama de Atividades 35 36

4.3.6 Requisitos de Desempenho 35 37

4.4 Atributos 36

37

5 PROJETO DE SOFTWARE 37 39



5.1.2 Escopo 37 39

5.2 Decomposição 37 39

5.2.1 Decomposição em Modulos 37 39

5.2.2 Diagrama Arquitetural 38 40

5.2.3 Diagrama de Entidade-Relacionamento 39 42

5.2.4 Diagrama de Classes 42 45

5.2.5 Diagrama de Pacotes 43 47

5.2.6 Decomposição em Processos Concorrentes 43 48

5.3 Descrição das Dependências 43 48

5.3.1 Dependência entre Modulos e Dados 43 48

5.4 Descrição das Interfaces 44 48

5.4.1 Interfaces dos Modulos 44 48

5.5 Projeto Detalhado 50 52

5.5.1 Projeto detalhado dos módulos 50

5.5.1.1 Projeto detalhado do módulo "Cadastro" 50

5.5.1.2 Projeto detalhado do módulo "Teste" 51

52

6 PLANO DE TESTES 53 55


6.1.1 Identificador 53 55


6.2 Descrição Geral 53 55

6.2.1 Visão Geral 55 57

6.2.2 Suspensão ou Conclusão 55 57

6.2.3 Ambiente 56 58

6.2.4 Riscos e Gerenciamento 56 58

6.3 Especificação dos Testes 56 58

6.3.1 Especificação dos Testes 001 56 58











6.4 Casos de Teste 60 62

6.4.1 Caso de Teste 001 60 62

6.4.2 Caso de Teste 002 61 63

6.4.3 Caso de Teste 003 61 63

6.4.4 Caso de Teste 004 62 64

6.4.5 Caso de Teste 005 63 65

6.4.6 Caso de Teste 006 63 65

6.4.7 Caso de Teste 007 64 66

6.4.8 Caso de Teste 008 65 66

6.4.9 Caso de Teste 009 65 67

6.4.10 Caso de Teste 010 66 67

6.4.11 Caso de Teste 011 67 67

6.5 Procedimentos deTeste 68 68

6.5.1 Procedimento deTeste 001 68 68










6.5.11 Procedimento deTeste 011 75

74

7 MANUAL DE USUÁRIO 77 75


7.2 Funcionalidades Gerais 77 75

7.2.1 Pagina Inicial 77 75

7.2.1.1 Lista de Projetos 77 75

7.2.1.2 Novo Projeto 78 76

7.2.1.3 Editar Projeto 78 78

7.2.1.4 Remover Projeto 78 78

7.2.2 Pagina de Plano de Testes 79 79

7.2.2.1 Lista de Plano de Teste 81 79

7.2.2.2 Novo Plano de Teste 82 80

7.2.2.3 Editar Plano de Teste 83 81

7.2.2.4 Versão Plano de Teste 84 82

7.2.2.5 Remover Plano de Teste 84 82

7.2.3 Pagina de Caso de Teste 85 83

7.2.3.1 Lista de Casos de Teste 86 83

7.2.3.2 Novo Caso de Teste 87 84

7.2.3.3 Editar Caso de Teste 88 86

7.2.3.4 Remover Caso de Teste 89 86

7.2.3.5 Executar Caso de Teste 89 87

7.2.3.6 Resultados do Caso de Teste 90 88

7.2.4 Log de Execução 90

88

8 CONCLUSÃO 91 89

9 BIBLIOGRAFIA 93

10 APÊNDICE 95

Lista de Figuras e Tabelas

Figura 1.1 Modelo Cascata 2

Figura 2.1 Regra 10 de Myers 6

Figura 2.2

Quadro de Testes 9

Tabela 3.1 Atividades do Projeto 16

Tabela 3.2

Plano RMMM 18

Figura 4.1 Casos de Uso do Ator:"Admin" 24

Figura 4.2 Casos de Uso do Ator:"Aluno" 25

Figura 4.3 Casos de Uso do Ator:"Programador" 25

Figura 4.4 Diagrama de Classes 31

Figura 4.5 Diagrama de Atividades 35

Tabela 4.1 Atributos da Classe "Projeto" 32

Tabela 4.2 Atributos da Classe "PlanoTeste" 33

Tabela 4.3 Atributos da Classe "CasoTeste" 33

Tabela 4.4 Atributos da Classe "LogExecucao" 34

Tabela 4.5 Atributos da Classe"CucumberUtil" 35

Figura 5.1 Modulo do Sistema 38

Figura 5.2 Visão macro do diagrama arquitetural do sistema 39

Figura 5.3 DER para a Área “Cadastro” 40

Figura 5.4 DER para a Área “Teste” 41

Figura 5.5 Diagrama de classes real 42

Figura 5.6 Diagrama de Pacotes 43

Tabela 5.1 Operações da Interface “Projeto” 44

Tabela 5.2 Operações da Interface “ProjetosController” 45

Tabela 5.3 Operações da Interface “ProjetoDAO” 45

Tabela 5.4 Operações da Interface “PlanoTeste” 46

Tabela 5.5 Operações da Interface “PlanoTestesController” 46

Tabela 5.6 Operações da Interface “PlanoTesteDAO” 47

Tabela 5.7 Operações da Interface “CasoTeste” 48

Tabela 5.8 Operações da Interface “CasoTestesController” 48

Tabela 5.9 Operações da Interface “CasoTesteDAO” 48

Tabela 5.10 Operações da Interface “LogExecucao” 49

Tabela 5.11 Operações da Interface “LogExecucaosController” 49

Tabela 5.12 Operações da Interface “LogExecucaoDAO” 49

Tabela 5.13 Operações da Interface “CucumberUtil” 50

Figura 7.1 TestaProjeto 77

Figura 7.2 Novo Projeto 78

Figura 7.3 Erro no Novo Projeto 79

Figura 7.4 Projeto Novo feito com sucesso 79

Figura 7.5 Editar Projeto 80

Figura 7.6 Encerrando Projeto 81

Figura 7.7 Plano de Teste 81

Figura 7.8 Novo Plano de Teste 82

Figura 7.9 Plano de Teste feito com sucesso 83

Figura 7.10 Editar Plano de Teste 83

Figura 7.11 Versionar o Plano de Teste 84

Figura 7.12 Removendo Plano de Teste 84

Figura 7.13 Casos de Teste 85

Figura 7.14 Caso de Teste criado com sucesso 86

Figura 7.15 Novo Caso de Teste 87

Figura 7.16 Alterando o Caso de Teste 88

Figura 7.17 Encerrando o Caso de Teste 89

Figura 7.18 Executar Caso de Teste 89

Figura 7.19 Resultados do Caso de Teste 90

1

Capítulo 1

1 - Introdução

1.1 – Tema

Automação de testes.

1.2 – Delimitação

O sistema tem como objetivo auxiliar na detecção das falhas nos projetos em

softwares, entretanto, o mesmo não é capaz de reparar as falhas encontradas.

1.3 – Justificativa

Projetos pequenos são fáceis de criar sem o uso de softwares de automação de testes

especializados. Além disso, o custo para se detectar falhas nesses programas é baixo, além de

que o tempo gasto não é considerável. Entretanto, projetos maiores que geralmente são

aqueles lançados com mais destaque no mercado, facilmente justificam o uso de pelo menos

um software de automação de testes, para detectar as falhas decorrentes de defeitos que são

produzidos durante a construção do programa em si.

Outro fator importante no que diz respeito ao acompanhamento dos testes feitos nos

projetos, mas que às vezes é deixado de lado, é o cálculo do gasto para corrigir os defeitos que

acumulam ao fim do projeto.

Assim, o nível de confiabilidade pode ser verificado, uma vez que ao final dos testes,

pode-se avaliar se o objetivo da função do programa é atingido. Além disso, um software de

automação de testes pode ser útil para auxiliar uma organização a aumentar o seu nível de

confiabilidade, na medida em que permite demonstrar a cada versão do programa, se as metas

estabelecidas nas saídas estão sendo cumpridas.

Baseado nesse contexto, o presente trabalho busca apoiar a automação de testes a fim

de permitir o maior controle e detalhamento de cada finalidade do programa, bem como

auxiliar na indicação de erros na arquitetura, principalmente nos casos em que o grau de

2

complexidade do projeto é elevado, e, portanto, exige o auxílio de outras ferramentas que não

as tradicionais. Também se faz necessário justificar o desenvolvimento da ferramenta neste

projeto através do ganho em termos de confiabilidade com a utilização da automação. E por

fim, há o ganho de conhecimento que a ferramenta pode proporcionar a alunos que queiram

conhecer mais a matéria dos casos de teste.

1.4 – Objetivos

O objetivo geral do projeto é desenvolver um software de automação de testes a fim de

apoiar a confiabilidade de projetos. Dessa forma, têm-se como criar um software para

armazenar os testes a serem cumpridos pelas versões do projeto.

1.5 – Metodologia

O presente projeto de graduação seguiu uma metodologia de Engenharia de Software

orientada a objetos. Dentro dessa metodologia foi escolhida a utilização do ciclo de vida em

módulos. Esse ciclo de vida, também conhecido como cascata, sugere uma abordagem

sistemática e sequencial para o desenvolvimento de software que se inicia em nível de sistema

e progride através das etapas de planejamento, análise, desenho, codificação e integração.

Figura1.1: Modelo Cascata

3

1.6 – Descrição

No capítulo 2 haverá uma breve descrição sobre automação de testes e as técnicas

utilizadas no processo de criação de um software desse tipo.

Em seguida, no capítulo 3, será apresentado o planejamento realizado para que o

sistema pudesse ser concluído.

Os requisitos definidos para o software são apresentados no capítulo 4. Nele constarão

os diagramas de casos de uso para cada grupo de usuário, bem como os casos de uso

detalhados e o diagrama de classes.

Um maior detalhamento do projeto será especificado no capítulo 5, onde haverá seu

modelo de banco de dados, arquitetura de cada módulo definido, as classes e seus principais

métodos.

No capítulo seguinte, serão abordados os testes planejados para validar o que foi

desenvolvido.

Em seguida estarão detalhadas todas as funcionalidades e suas respectivas interfaces,

no manual do usuário, para auxiliar o futuro consumidor na utilização do sistema.

Por fim, o trabalho é concluído no capítulo 8, onde são abordados os resultados

atingidos com seu desenvolvimento, sua importância na utilização na construção de outros

programas e planos para o futuro.

4

Capítulo 2

2 - Automação de Testes

2.1 - Introdução

Quando iniciamos a construção de um software, não há garantias de que este possa

funcionar corretamente. E, potencializando esse problema, a necessidade de programas

maiores causa a ocorrência de mais problemas, estabelecendo uma relação de

proporcionalidade entre o tamanho e a complexidade do projeto com a quantidade de erros

causados pela programação. Idealmente, seria necessário que todo ciclo de construção do

programa fosse testada, assim como cada adição nova de programação, a fim de antever

problemas na combinação dos elementos. Entretanto, isso se torna impossível diante do

número de variáveis a serem checadas e o tempo que uma equipe de programadores tem

disponível. Assim, é importante que a qualidade do teste que venha a ser utilizado para cada

caso fica como peça necessária para um produto final confiável.

As falhas encontradas podem ter origens diversas: uma especificação errada ou

incompleta, requisitos que não podem ser implementados, limitações do hardware ou até

mesmo o simples fato da combinação de elementos que separados funcionariam

perfeitamente. Portanto, essas falhas são a soma de fatores que muitas vezes fogem ao nosso

controle e por isso, são do cotidiano de cada programador.

Assim, testar um programa pode ser visto como uma parcela do processo de qualidade

de software. A qualidade da aplicação de cada caso vai variar para cada sistema, uma vez que

depende dos parâmetros que esses sistemas possuem.

Os atributos qualitativos previstos na norma (IEEE Std 829-1998) são:

Funcionalidade

Confiabilidade

Usabilidade

Eficiência

5

Manutenibilidade

Portabilidade

Para medir se a versão final de um programa atingiu os objetivos traçados em seu

planejamento, devemos observar se: suas especificações foram atendidas, há uma evolução

em relação a versões anteriores, as expectativas do usuário foram atendidas, normas

respeitadas, entre outros fatores. Assim, estabelece-se que a especificação do software diz

respeito ao processo de verificação do software, a expectativa do cliente diz respeito ao

processo de validação do software, sendo discutido os dois processos mais tarde nesse

capítulo.

Toda construção de um programa segue um planejamento feito, estabelecendo uma

metodologia de trabalho. Seguindo como base esse modelo, os conceitos impostos visam à

construção de um software de forma eficaz que garantam uma versão final adequada aos seus

requisitos.

Assim, espera-se que a versão final agrade aos usuários e atinja as expectativas de

quem encomendou o projeto. Observando este aspecto, não faz sentido iniciar a construção de

um produto de software sem ter uma metodologia de trabalho bem solidificada e que seja do

conhecimento de todos os envolvidos no processo. Porém, esse cenário se torna difícil diante

da atual crescente demanda por softwares de qualidade, havendo urgência para a entrega

desses softwares a fim de acompanhar as necessidades do mercado. Este fato pode fazer com

que um planejamento traçado acabe por não ser cumprido, queimando-se etapas.

Independentemente da metodologia de trabalho empregada no desenvolvimento de um

software, para que se obtenha um produto final com o nível de qualidade desejado é

necessária a melhoria dos processos de engenharia de software.

Uma maneira de se assegurar a melhoria de tais processos seria seguir modelos

sugeridos por entidades internacionais. Dentre esses modelos, sejam eles específicos para uma

área ou com uma ampla aplicação, alguns são mais utilizados e tidos como eficientes, como

por exemplo o modelo CMMI (Capability Maturity Model Integration).

Outro fator que influência a qualidade do software é o que diz respeito aos testes que

serão executados. Por isso, todas as metodologias de desenvolvimento de software têm uma

disciplina dedicada aos testes. Assim, atualmente esta é uma tarefa imprescindível, porém

muitas vezes feita de maneira ineficiente, seja pela baixa estimativa do número de testes pelos

programadores, pela falta de tempo ou mesmo pela falta de recursos humanos e financeiros.

6

2.1.1 – Regra 10 de Myers

Glenford Myers, autor do livro "The Art of Software Testing", foi um pioneiro na

incorporação dos testes como parte do planejamento da construção de um software. Myers via

a importância e o impacto que os testes teriam na redução dos custos finais de um programa.

Para provar suas ideias, ele criou a Regra 10 de Myers, que estabelece que o custo da correção

de defeitos é maior quanto mais se demorar em se encontrar o defeito. Ou seja, quanto mais

cedo o projeto incluir um planejamento da inserção de um plano de testes, mais chances de se

economizar custos causados por defeitos.

Figura 2.1 - Regra 10 de Myers

Na imagem acima, podemos observar que um defeito encontrado em produção é

menos custoso se for encontrado nas fases iniciais, como: Desenho, Especificação e

Construção.

Percebe-se que um bom teste feito no início do projeto, onde é feita a análise dos

requisitos e documentação do projeto, resulta em economia de tempo e custo para o projeto,

além de garantir a qualidade dos requisitos e documentos que servirão para construção do

novo sistema.

Além disso, para Myers, há princípios vitais para o teste de software:

- O caso de teste deve definir a saída esperada, de forma a reduzir a interpretação do

critério de sucesso;

http://3.bp.blogspot.com/-xkwnhSuDK8g/TxbtntvA-MI/AAAAAAAAAEk/huoAc2Ycpbk/s1600/custo.JPG

7

- A saída da execução do teste deve ser exaustivamente analisada;

- Os casos de teste devem verificar não somente as condições inválidas de execução,

como também as condições válidas;

- Outro conceito apresentado é utilizar pessoas e organizações diferentes para a

implementação e para a verificação;

- A entidade de teste possui uma visão destrutiva do sistema, em busca de erros,

enquanto a entidade de programação possui uma visão construtiva, em busca da

implementação de uma especificação.

Myers também aborda o esforço para se construir casos de teste com o seguinte

pensamento: Devem-se evitar testes desnecessários, pois a qualidade do teste piora

gradualmente com as iterações de desenvolvimento. Em contrapartida, o teste de regressão

permite quantificar a evolução da qualidade de software, mantendo e executando novamente

testes realizados anteriormente.

O mesmo autor afirma que, diferente do que se poderia considerar o senso comum, a

probabilidade de existência de defeitos num certo trecho de código é proporcional à

quantidade de defeitos já encontradas anteriormente, pois basicamente, defeitos aparecem em

grupos. Trechos específicos de código de um software qualquer estão mais propensos a ter

defeitos que outros.

2.2 - Processo de Construção de Software

Na construção de um software, devemos considerar os seguintes passos:

Levantamento de Requisitos

É o processo para elicitar todos os requisitos que o sistema deverá atender.

Modelagem de Negócios

Estabelece as regras do negócio que o sistema deverá atender.

8

Prototipagem

A especificação é a parte em que descrevemos exatamente as funcionalidades do

software que está sendo construído. Na prática, quando as especificações são bem definidas,

temos programas que conseguem atingir seus objetivos.

Projeto e Arquitetura

A arquitetura de um sistema de software remete a uma representação abstrata daquele

sistema. Arquitetura é ligada à garantia de que o sistema de software irá ao encontro de

requisitos do produto, como também assegurar que futuros requisitos possam ser atendidos.

Especificação de Classes

Especificação para a criação dos diagramas de classe.

Codificação

A transformação de um projeto para um código deve ser a parte mais importante do

trabalho da engenharia de software, mas não necessariamente aquela que exige o maior

tempo.

Manutenção

A manutenção e melhoria de software lidam com a descoberta de novos problemas e

requisitos. Ela pode tomar mais tempo que o gasto no desenvolvimento inicial do mesmo.

Não somente pode ser necessário adicionar códigos que combinem com o projeto original,

mas determinar como o software trabalhará em algum ponto depois da manutenção estar

completa, pode requerer um esforço extra do programador. Geralmente, as manutenções são

para ampliar os sistemas para novas funcionalidades, uma vez que suas funcionalidades

estejam garantidas após a codificação.

Teste

Uma das etapas da construção, podemos estabelecer que todas os passos citados

podem ser testados para que todos executem a função desejada. Podemos ver a

exemplificação disso na figura abaixo:

9

Figura 2.2 - Quadro de Testes

2.3 - Validação e Verificação

Durante a construção de um programa, devemos sempre nos certificar se este está

seguindo as especificações feitas em seu planejamento e se seus resultados são os esperados

por aqueles que encomendaram o software, como citado em itens anteriores. Essas ações

ocorrem, durante o processo de criação do projeto, sendo utilizadas para avaliar cada etapa

atingida pela equipe. Começa-se pela revisão de requisitos, indo para inspeções do código

chegando até o teste do produto final.

A diferença fundamental entre esses dois processos é que a verificação está ligada a

avaliação se o software está conforme suas especificações enquanto que a validação identifica

se as necessidades da instituição foram atendidas. Assim, na soma deles, tem-se o objetivo de

ter uma maior confiabilidade do produto feito, aspecto relevante no mercado de hoje.

O nível de confiabilidade de um produto pode ser avaliado pelos seguintes fatores:

- Função do software: Depende de quão critico o software é para seu ambiente.

- Expectativa do usuário: Tolerância do usuário a falhas apresentadas pelo programa.

- Ambiente do mercado: Deve haver uma analise do cenário, no qual o produto se

insere, avaliando se um preço mais elevado (devido à utilização de verificação e validação)

10

alavancará suas vendas ou se os usuários em questão aceitam um software que apresente mais

falhas.

Com isso, a verificação e a validação têm como uma das abordagens os testes de

software que envolve executar uma implementação do programa com dados de teste.

Examina-se as saídas para verificar se o desempenho é o desejado.

Como localizar os defeitos é um processo demorado, podendo ser até improdutivo, e

nem sempre o teste utilizado especificamente consegue detectar a falha procurada, é

aconselhável usar uma gama de testes diferentes. Entretanto, mesmo com o defeito sendo

corrigido, existe a possibilidade que esta venha a provocar outros defeitos que não estavam

sendo identificados ainda. Além disso, esses testes devem ser feitos a cada nova versão feita,

para se verificar se alguma funcionalidade antiga foi afetada com a adição de novos pedaços

de código. Esse esforço em um projeto de grande porte manualmente exigiria uma equipe

extensa e um grande número de horas que aumentariam os gastos projetados

consideravelmente. Por isso, a ideia da automatização destes testes mostra um modelo

econômico que viabiliza o aumento da confiabilidade de um programa no mercado.

2.4 - Teste de software

Para o melhor funcionamento dos testes, são utilizadas principalmente duas

estratégias: a entrada de dados corretos para se obter as saídas esperadas e o uso de dados

errados para que o sistema se comporte diante destes dados, e verifica-se também aqui se o

sistema responde conforme foi especificado. O objetivo é que assim se detecte alguma falha,

ressaltando que no caso de uso de testes, eles evidenciam sempre a presença de algum defeito,

mas não pode certificar que o software não possui nenhum.

Os principais alvos para os testes seriam as funções acessadas pelo menu do usuário, a

combinação dessas funções e o que foi citado acima. Por isso, se percebe a importância de

uma extensa coleção de dados para que o teste seja o mais completo possível.

11

2.4.1 - Teste de sistemas

Os testes de sistema se baseiam na integração de um par ou mais de componentes que

implementam funções e como eles afetam o sistema como um todo. Existem dois tipos deste

testes: de Integração e de Releases.

2.4.1.1 - Teste de Integração

O foco aqui seria o código-fonte. O código é verificado, fazendo-se uma procura de

um defeito no sistema.

2.4.1.2 - Teste de Releases

As versões que são liberadas do programa vão sendo testadas para se validar se as

funções prometidas estão sendo cumpridas. Muitas vezes, esse tipo de teste pode ser feito

utilizando os próprios usuários a fim de receber um bom feedback.

2.4.1.3 - Teste de Desempenho

Um último teste que pode ser feito a fim de conquistar ainda mais confiabilidade no

mercado seria o de desempenho. Estressa-se o programa em foco com cargas de dados que

vão aumentado, até se chegar à falha do programa. Assim, pode-se medir a resiliência deste

programa.

2.4.2 - Teste de Componente

O teste de componente, também conhecido como teste de unidade, é um processo que

foca mais no teste de defeitos de uma parte específica do sistema.

12

2.4.2.1 - Teste de Interfaces

Há o problema que às vezes os componentes operam sem erros, mas a interface entre

eles pode causar uma falha ao sistema. Essas falhas são divididas em três categorias:

- Mau uso de interface

- Mau entendimento da interface

- Erros de timing

Como esses tipos de falhas são de difícil detecção, é sugerido que se use algumas

estratégias, por exemplo: a de estresse, como citado anteriormente ou o uso de dados que

trabalhem no limite de operação, pois assim as falhas na interface tendem a aparecer.

2.4.3 - Projeto de casos de teste

O projeto de caso de testes é uma parcela do teste de sistemas e outra de componentes,

onde o testador projeta as entradas e saídas que o sistema deve apresentar. Assim, se realiza

uma validação da entrada e da saída, existindo três tipos de projeto.

- Teste baseado em requisitos

- Teste de partições

- Teste estrutural

13

Capítulo 3

Planejamento do Projeto

3.1 - Apresentação

3.1.1 - Sumário do Projeto

3.1.1.1 - Finalidade, Escopo e Objetivo

O presente projeto possibilitará o usuário executar uma série de testes em um software

utilizando um programa para garantir a confiabilidade deste e também adquirirá conhecimento

na área de plano de teste.

3.1.1.2 – Postulados e Restrições

A principal restrição imposta ao projeto será o conhecimento do Cucumber, linguagem

usada para fazer os testes, sendo necessário para o usuário um treinamento mínimo na

questão.

As tecnologias necessárias para o desenvolvimento do sistema serão apresentadas

nesta seção. A linguagem de programação utilizada será o Java pelo fato de ser uma

linguagem orientada a objetos robusta e de sintaxe de simples compreensão. A IDE de

desenvolvimento será o Eclipse (Indigo) sobre a plataforma Java EE e a IDE de compilação

será o Maven. O servidor de aplicação será o Apache Tomcat. Para formatação das interfaces

HTML serão utilizadas folhas de estilo CSS. Para realizar a modelagem de dados será usado o

HSQL.A persistência dos dados será realizada no HSQL, sendo utilizada a biblioteca

Hibernate para realizar o mapeamento entre o BD e a aplicação. Por fim, será usado JRuby

para que possamos operar o Cucumber na máquina.

3.1.1.3 - Liberações Parciais

Neste projeto será seguido o modelo cascata linear-sequencial, no qual primeiramente

é feito o planejamento e em seguida, serão abordados análise, desenho, codificação e

integração do projeto. Teremos como resultados:

14

- Planejamento para o Gerenciamento do Programa

- Especificações de Requesito

- Descrição do Programa

- Plano de Teste

- Manual de Usuário

- Versão Alfa do Sistema

- Documentação Total

3.1.2 – Sumário de Cronograma e Orçamento

O cronograma do projeto seguirá o cronograma do projeto de graduação no que diz

respeito aos prazos de entrega de cada artefato do sistema.

Como se trata de um projeto acadêmico, nenhum custo será necessário. Não existem

custos relacionados a ferramentas pelo fato de todo os softwares utilizados serem gratuitos. O

único custo que será levado em consideração é o de recursos humanos que é sempre o maior

dentro de um projeto.

3.2 - Referências

As referências bibliográficas encontram-se no capitulo "Bibliografia".

3.3 – Definições

Java EE – É uma plataforma Java para aplicações corporativas que fornece diversas

bibliotecas para a implementação de software distribuído, tolerante a falhas e multicamadas.

MVC – É um padrão arquitetural muito utilizado em aplicações web, pois desacopla as

camadas de apresentação e modelo de dados, que conseguem interagir entre si através de um

controlador.

Tomcat – É um servidor de aplicação web open-source para Java criado pela fundação

Apache. É indicado pela Sun como o software de referência para a implementação de Java

Servlets e JavaServer Pages.

HSQL – É um sistema de gerenciamento de banco de dados relacional que utiliza a

linguagem de consulta SQL.

15

3.4 – Organização do Projeto

3.4.1 - Interfaces Externas

O projeto proposto vai ser usado como Projeto de Graduação do curso de Engenharia

Eletrônica e de Computação da UFRJ, sendo orientado pelo professor Antônio Cláudio.

A comunicação entre o aluno e orientador será feita em reuniões e por email quando

necessário.

3.4.2 – Estrutura Interna

A equipe do projeto será composta por apenas um integrante pelo fato do projeto de

graduação ser individual. O responsável pelo projeto irá se comunicar diretamente com o

orientador para obter retorno em relação à auditoria da qualidade do projeto a ser

desenvolvido.

3.4.3 – Papéis e Responsabilidades

Pelo fato do projeto possuirá apenas uma pessoa, este será responsável por todas as

etapas de seu desenvolvimento, desde o planejamento até a codificação do sistema.

3.5 – Processos de Gerenciamento

3.5.1 – Previsões

Para realizar as previsões de gastos do projeto e o tempo necessário para sua

realização, será utilizado o software COCOMO (que estará presente no Apêndice). Será

escolhida a análise por pontos de função para uma linguagem orientada a objeto, que no caso

específico do projeto é a linguagem Java. A previsão de término do projeto será de Março de

2014.

16

3.5.2 – Equipe

A equipe será composta por apenas um integrante, e este possui experiência acadêmica

em banco de dados e em linguagem de programação orientada a objeto. O mesmo será

responsável pela execução de cada fase do projeto descrita no cronograma.

3.5.3 - Plano para Aquisição de Recursos

Como todos os recursos desse projeto são gratuitos, não será necessária a aquisição de

nenhum recurso.

3.5.4 – Plano de Treinamento da Equipe

Como o membro em questão possui apenas conhecimento em C# e pensa em expandir

seu conhecimento em linguagens orientadas a objeto, ele irá realizar esse projeto em Java.

Esse processo de aprendizado levará cerca de 2 a 3 meses através do livro "Head First Java".

Além disso, haverá a necessidade de aprender a usar o Cucumber para ser capaz de executar

os testes.

3.6 – Plano de Trabalho

3.6.1 – Atividades

As atividades previstas para o projeto estão listadas na tabela abaixo:

Atividades Início Fim

1 Estudo do Contexto do Projeto 01/04/13 15/09/13

2 Elaboração da Proposta do Projeto 16/02/14 25/02/14

3 Definição e Estudo das Ferramentas 01/04/13 15/09/13

4 Elaboração do Planejamento 04/05/13 10/12/13

5 ERS e Manual do Usuário (1a versão) 10/12/13 26/02/14

6 Projeto, Plano de Testes e Manual do

Usuário (2a versão) 02/01/14 07/03/14

17

Atividades Início Fim

7 Desenvolvimento e Codificação do

Projeto 15/09/13 07/03/14

8 Testes unitários e de Integração 28/02/14 07/03/14

9 Apresentação da Versão Alfa 17/03/14 17/03/14

Tabela 3.1: Atividades do projeto

3.6.2 – Alocação de Recursos

O recurso do projeto utilizará todo o seu tempo disponível e não haverá um período

fixo de trabalho. Além disso, os recursos necessários para esse projeto serão adquiridos no

estudo das ferramentas.

3.6.3 - Alocação de Orçamento

Como não há necessidade de contratação de licenças ou mão de obra, esse item não se

aplica a esse projeto.

3.7 – Planos de Controle

Controle dos Requisitos

Como os requisitos do projeto serão realizados pela própria equipe, eles pouco

mudarão ao longo do seu desenvolvimento, sendo, portanto, de fácil controle.

Controle dos Prazos

O controle dos prazos será feito de acordo com os prazos estabelecidos no

cronograma.

Controle do Orçamento

Não haverá um plano de controle de orçamento pelo fato de ser um projeto acadêmico.

Controle de Qualidade

O controle de qualidade será realizado pelo orientador do projeto.

Plano de Relatórios

Um relatório será feito para cada artefato requisitado.

Plano de Medidas

A equipe contabilizará o número de horas trabalhadas e o número de linhas de código

escritas para realizar uma comparação com as estimativas feitas pelo COCOMO.

18

3.8 – Plano de Gerenciamento de Riscos

Os riscos identificados serão gerenciados pelo plano RMMM, que consiste em

mitigar, monitorar e gerenciar. Esses riscos são expostos na tabela a seguir.

Risco Categoria Prob. de

Ocorrência Impacto RMMM

Entrega fora do prazo Negócio 50% Crítico RMMM1

Erro de Projeto Negócio 20% Crítico RMMM2

Dificuldade Técnica Técnico 70% Menor RMMM3

Tabela 3.2 - Plano RMMM

RMMM1 - Entrega fora do prazo

o Mitigar:

Estimar um cronograma que possibilite que uma entrega de artefato seja feita dentro

do prazo estipulado.

o Monitorar:

Verificar o andamento das tarefas e o comprometimento entre a medida estimada e

realizada.

o Gerenciar:

Aumentar a carga horária dedicada ao projeto.

RMMM2 – Erro de Projeto

o Mitigar:

Verificar se os diagramas de modelagem do projeto estão corretos.

o Monitorar:

Verificar se o que foi projetado está sendo corretamente aplicado.

o Gerenciar:

Revisar o modelo, voltar a uma versão funcional e corrigir as eventuais falhas.

RMMM3 – Dificuldade Técnica

o Mitigar:

Utilizar ferramentas e tecnologias de conhecimento prévio da equipe.

19

o Monitorar:

Certificar se estão sendo utilizadas as ferramentas e tecnologias mais apropriadas e de

modo correto.

o Gerenciar:

Obter ajuda do orientador, de colegas ou de materias didáticos e referências na

internet.

3.8.1 - Plano de Encerramento

Uma parte da documentação será entregue durante a elaboração do programa, sendo

que a parcela que faltar, será executada após o termino do programa em si e feito os testes

necessários.

Após essa etapa, serão entregues todos os documentos ao orientador para depois haver

uma apresentação sobre o assunto.

3.9 – Processos Técnicos

3.9.1 – Modelo dos Processos

O modelo de processo adotado no projeto é do tipo Cascata. O projeto foi iniciado no

dia da sugestão do assunto que ocorreu em 01/04/2013 e será encerrado com a entrega da

versão alfa que ocorrerá em 17/03/2014.

3.9.2 – Métodos, Ferramentas e Técnicas

O projeto será desenvolvido em linguagem Java, sendo compilado no Eclipse. O

servidor de aplicação será o Tomcat e o banco de dados utilizado será o HSQL, além do uso

do Cucumber. Por fim, haverá o uso do Maven para executar o programa e do JRuby como

peça necessária para o funcionamento do Cucumber.

3.9.3 – Infraestrutura

A infraestrutura da UFRJ e do domicílio do integrante do projeto será utilizada para o

desenvolvimento do projeto. Todas as bibliotecas utilizadas no projeto estão contidas na

plataforma Java EE e no JRuby.

3.9.4 – Plano para a Aceitação do Produto

A aceitação do produto será feita pelo orientador, Antônio Cláudio Gómez de Sousa.

20

3.10 – Plano para os Processos de Suporte

3.10.1 – Plano de Gerenciamento de Configuração

Toda a documentação será feita em formatos DOC e PDF. Os slides que serão

apresentados no seminário serão feitos em formato PPT.

3.10.2 – Plano de Verificação e Validação

A verificação e validação serão realizadas pelo orientador. A equipe ficará

encarregada de seguir as metas e prazos estipulados no cronograma, fazendo com que todo o

processo possa ser inspecionado e validado.

3.10.3 – Documentação

A documentação do projeto será organizada em forma de artefatos a ficarem prontas

até as datas estipuladas pelo cronograma. A equipe será responsável pelas informações

contidas nos documentos. Cabe salientar que não haverá documentos não liberáveis no

projeto.

3.10.4 – Plano para Assegurar a Qualidade

O controle de qualidade será feito pelo orientador através da revisão dos artefatos

entregues e da aprovação da versão alfa do software que será desenvolvido. Sendo assim, o

orientador dará o retorno necessário para assegurar a qualidade do projeto.

3.10.5 – Revisões e Auditorias

As revisões e auditorias serão realizadas pelo professor orientador que inspecionará

cada artefato entregue e indicará a aprovação do documento ou as possíveis pendências a

serem corrigidas.

3.10.6 – Plano para a Resolução de Problemas

O orientador do projeto será procurado em caso de problemas de difícil resolução.

Para problemas menos complexos, a consulta com colegas, a pesquisa em livros e na WEB

será o método utilizado para obter uma resolução.

21

Capítulo 4

Especificação de Requisitos

4.1 – Introdução

4.1.1 – Finalidade

A finalidade desta especificação de requisitos é definir as funcionalidades do software

que será desenvolvido como projeto final da graduação. Essa especificação se dirige ao

orientador, Antônio Cláudio Gómez de Sousa, e à banca avaliadora do projeto de graduação.

4.1.2 – Escopo

O escopo do projeto será determinado pelas funcionalidades que serão implementadas.

O software possuirá a capacidade de executar uma serie de testes manualmente e

automaticamente, aumentando assim a confiabilidade do produto em foco. Com a criação de

planos e casos de teste, poderá ser avaliado a evolução das versões feitas pelo programa

testado. Além disso, o software possibilita a adesão de diferentes projetos, podendo se fazer

uma curta descrição destes e dos testes a serem feitos. Assim, a equipe testadora poderá criar

também um armazenamento dos resultados obtidos ao longo do tempo. Além disso, o uso do

Cucumber abre a alternativa de uma expansão dos testes feitos ao passo que, conhecendo seu

mecanismo, a adição de novos steps é bastante simples.

4.1.3 - Definições, Acrônimos e Abreviaturas

As definições usadas encontram-se no inicio desta documentação.

4.1.4 - Referências

As referências usadas podem ser encontradas no final do documento.

4.1.5 - Resumo

Esse ERS mostra as funcionalidades do TestaProjeto, além de suas capacidades e suas

limitações. As limitações se devem essencialmente ao aprendizado de alguns requisitos

22

necessários para o funcionamento e as gemas do JRuby que devem ser instaladas e para as

capacidades, será apresentado os casos de uso e o diagrama de classes para ficar claro o uso

do programa.

Outras considerações sobre o produto serão apresentadas no Capítulo 7.

4.2 – Descrição Geral

4.2.1 – Perspectiva do Produto

A perspectiva do produto é que ele cumpra os objetivos estabelecidos.

4.2.2 – Funções do Produto

A seguir serão listadas as funcionalidades do produto a serem desenvolvidas.

Novo Projeto

Editar Projeto

Remover Projeto

Novo Plano de Teste

Editar Plano de Teste

Remover Plano de Teste

Incrementar Versão

Novo Caso de Teste

Editar Caso de Teste

Remover Caso de Teste

Executar Caso de Teste

Log de Execução

4.2.3 – Características do Usuário

Os usuários do sistema serão programadores iniciantes que desejam ter conhecimento

na elaboração de testes.

4.2.4 – Restrições

As restrições impostas para o uso do TestaProjeto é o conhecimento necessário para

que os usuários possam executar os testes e ser familiarizado com Cucumber, assim como a

maquina deve possuir uma pasta do cucumber com features,paths e steps estabelecidos.

23

Adicional a esse fato, é preciso haja a instalação do JRuby com as seguintes gemas:

cucumber, webrat e mechanize, além de um navegador web e que o sistema usado seja

Windows.

4.2.5 – Pressupostos e Dependências

Como já citado, há a necessidade do usuário procurar conhecer o básico do sistema do

Cucumber e os requisitos operacionais para que ele rode normalmente na maquina. No

Manual de Usuário, haverá instruções para que seja possível que um programador consiga

criar seus próprios testes, inicialmente.

4.2.6 – Postergar Requisitos

Por se tratar de um projeto acadêmico, não será dada ênfase na questão de segurança

do sistema. Também não haverá a preocupação em desenvolver um design muito rebuscado

para as interfaces WEB. Caso uma versão comercializável do projeto seja desenvolvida, essas

duas questões deverão ser levadas em consideração.

4.3 – Requisitos Específicos

Nesta seção serão mostrados os principais diagramas que compõem o projeto, para um

detalhamento do funcionamento do programa.

4.3.1 - Interfaces Externas

4.3.1.1 - Interfaces dos Usuários

A interface com os usuários será através de uma aplicação web rodada localmente com

elementos gráficos. A página principal é seguida das outras em forma cascata sequencial,

seguindo a especificidade dos testes a serem executados.

Mais detalhes das funciobilidades da interface serão apresentados no Manual de

Usuário.

4.3.1.2 - Interfaces de Hardware

Não se aplica ao projeto, pois este não se conecta a outros hardwares.

24

4.3.1.3 - Interfaces de Software

Para a construção do software, será necessário que haja uma conexão entre o programa

em si e o banco de dados. Para essa função, foi escolhido o Hibernate. A interface entre o java

e o Cucumber é feita pelo JRuby.

4.3.1.4 - Interfaces de Comunicação

A interface de comunicação será a WEB.

4.3.2 - Requisitos Funcionais

4.3.2.1 – Diagrama de Casos de Uso

Figura 4.1: Casos de Uso do Ator “Admin”

25

Figura 4.2: Casos de Uso para o Ator “Aluno”

Figura 4.3: Casos de Uso para o ator “`Programador”

26

A seguir são detalhados todos os casos de uso existentes nos diagramas.

Título: Listar Projetos

Objetivo: Permitir que um usuário visualize os projetos presentes no TestaProjeto.

Pré-condições: N/A

Pós-condições: N/A

Fluxo principal:

1 – Usuário executa o programa.

Fluxo alternativo: N/A

Título: Novo Projeto

Objetivo: Permitir que um usuário crie um projeto.

Pré-condições: Estar no sistema.

Pós-condições: O projeto estar criado.

Fluxo principal:

1 – Usuário executa o programa

2 – Seleciona a opção no menu: “Novo Projeto”

3 – Informa o nome do projeto, a url e uma breve descrição

4 – Salva o projeto desejado.


Título: Editar Projeto

Objetivo: Permitir que um usuário altere as informações de um projeto.


Pós-condições: O projeto estar atualizado com as alterações informadas pelo usuário.

Fluxo principal:


2 – Seleciona a opção no menu: “Editar Projeto”

3 – Altera o nome do projeto, a url, uma breve descrição

4 – Salva as alterações feitas.


27

Título: Remover Projeto

Objetivo: Permitir que um usuário encerre um projeto.



Fluxo principal:


2 – Seleciona a opção no menu:“Remover Projeto”

3 – Confirma a remoção.


Título: Criar Plano de Testes

Objetivo: Permitir que um usuário crie plano de testes para o projeto.

Pré-condições: Estar no sistema

Pós-condições: O plano de teste estar criado.

Fluxo principal:


2 – Seleciona o projeto desejado

3 – Seleciona a opção:“novo Plano de Testes”

4 – Informa o titulo para o plano de testes, uma descrição e a versão

5 – Salva as informações.


Título: Listar Planos de Testes

Objetivo: Permitir que um usuário visualize os planos de testes decorrentes do projeto em

questão.

Pré-condições: Estar no sistema e ter criado um projeto anteriormente.


Fluxo principal:



3 – Os planos de testes serão visualizados.


28

Título: Versionar

Objetivo: Permitir que um usuário mude a versão do Plano de testes.



Fluxo principal:



3 – Seleciona a opção: "versão".


Título: Editar Plano de Testes

Objetivo: Permitir que um usuário editar as informações sobre o plano de testes desejado.


Pós-condições: O plano de teste estar atualizado com as alterações informadas pelo usuário.

Fluxo principal:



3 – Seleciona a opção: "Editar" no Plano de Testes desejado

4 – Edita o título para o plano de testes, uma descrição e a versão

5 – Salva as alterações.


Título: Listar Casos de Teste

Objetivo: Permitir que um usuário visualize os casos de teste de um plano de teste.

Pré-condições: Estar no sistema, ter criado um projeto anteriormente e ter criado um plano de

testes anteriormente.


Fluxo principal:



3 – Seleciona o plano de teste desejado

4 – Os casos de teste desejados serão visualizados.


29

Título: Novo Caso de Teste

Objetivo: Permitir que um usuário crie um novo caso de teste.



Pós-condições: O caso de teste estar criado.

Fluxo principal:




4 – Seleciona a opção:"Novo Caso de Teste"

5 – Informa o título, descrição e o "caso" do caso de teste

6 – Salva as informações.


Título: Editar Caso de Teste

Objetivo: Permitir que um usuário edite um caso de teste.



Pós-condições: O caso de teste estar atualizado com as alterações informadas pelo usuário.

Fluxo principal:




4 – Seleciona a opção "Editar" no caso de teste desejado

5 – Altera o título, descrição e o "caso" do caso de teste

6 – Salva as alterações.


Título: Remover Caso de Teste

Objetivo: Permitir que um usuário remova um novo caso de teste.




30

Fluxo principal:




4 – Seleciona a opção "Remover" no caso de teste desejado

5 – Confirma a remoção.


Título: Executar Caso de Teste

Objetivo: Permitir que um usuário execute o caso de teste desejado.




Fluxo principal:




4 – Seleciona a opção "Executar" no caso de teste desejado

5 – O sistema avisa se o teste foi executado.


Título: Emitir Log de Execução

Objetivo: Permitir que um usuário visualize os resultados do caso de teste desejado.

Pré-condições: Estar no sistema, ter criado um projeto anteriormente, ter criado um plano de

testes anteriormente e executado o caso de teste.


Fluxo principal:




4 – Seleciona a opção "Relatório" no caso de teste desejado

5 – Visualiza os resultados.

31

Fluxo alternativo:




4 – Seleciona o caso de teste desejado

5 – Visualiza os resultados.

4.3.3 – Diagrama de Classes

Uma apresentação mais detalhada das classes e seus atributos estarão no capítulo 5.

Figura 4.4: Diagrama de Classes

32

4.3.4 – Dicionário de Dados

Nessa seção serão mostradas as entidades de dados do sistema e seus atributos, bem como

suas respectivas descrições. Ao final será exibido o diagrama de entidade-relacionamento.

Entidade Projeto

Descrição: É a entidade que possui as variáveis da primeira camada de identificação de um

projeto criado.

Atributo Descrição

Int : id Identificador único do projeto.

String : titulo Titulo ou nome para o projeto.

String : descricao Breve descrição do projeto a ser testado.

String : url Endereço para o site do projeto.

Tabela 4.1: Atributos da Entidade “Projeto”

Entidade ProjetosController

Descrição: É a entidade que representa o controle de qualquer projeto: ela possui as execuções

que operam na camada intermediária, ligando os valores da entidade anterior às funções

apresentadas na interface com o usuário.

Entidade ProjetoDAO

Descrição: É a entidade que executa a ligação da camada "Projeto" do programa com o banco

de dados.

Entidade PlanoTeste

Descrição: É a entidade que representa um plano de teste. É utilizada para definir quais

informações um plano de teste possuirá.

33


Int : id Identificador único do plano de teste.

String : titulo Identificador do projeto a que a versão pertence.

String : descricao Nome da versão.

Int : versao Descrição sucinta da versão.

Tabela 4.2: Atributos da Entidade "PlanoTeste"

Entidade PlanoTestesController

Descrição: É a entidade que contem as funções: Novo Plano de Teste, Editar Plano de Teste,

Remover Plano de Teste e Versionar. Essas funções são diretamente ligadas às apresentadas

ao usuário na pagina.

Entidade PlanoTesteDAO

Descrição: É a entidade que opera os dados ligados a camada "Plano de Teste" com o banco

de dados.

Entidade CasoTeste

Descrição: É a entidade que representa um caso de teste a ser executado.


Int : id Identificador único do perfil de acesso.

String : titulo Nome do perfil de acesso.

String : descricao Informação sobre quais sãos os objetivos do caso de

teste

String : caso Descrição do caso para que o cucumber execute os

passos.

Boolean : deleted Variável necessária para a exclusão lógica.

Tabela 4.3: Atributos da Entidade "CasoTeste"

34

Entidade CasoTestesController

Descrição: É a entidade que controla as funções de um caso de teste, como salvar um caso

novo ou executá-lo.

Entidade CasoTesteDAO

Descrição: É a entidade que possui as funções de consulta dos casos de teste ao banco de

dados quando for necessário a adição de um novo, por exemplo.

Entidade LogExecucao

Descrição: É a entidade que apresenta os resultados obtidos quando o caso de teste é

executado.


Int : id Identificador único do log de execução.

Boolean : Sucesso Identifica se o teste foi bem sucedido.

String : resultado Relatório final sobre o teste.

Tabela 4.4: Atributos da Entidade "LogExecucao"

Entidade LogExcucaosController

Descrição: É a entidade que representa o controle das funções dos logs de execução.

Entidade LogExecucaoDAO

Descrição: É a entidade que representa as funções ligadas a salvar as os relatórios dos logs de

execução.

35

Entidade CucumberUtil

Descrição: Entidade que faz a conexão do java com os passos do cucumber.


String :

FEATURE_FILE_PATH

Caminho para o arquivo de passos.

String : RUN CUCUMBER

PATH

Item que opera o cucumber.

String : CUCUMBER PATH Caminho para o cucumber e java.

Tabela 4.5: Atributos da Entidade "CucumberUtil"

4.3.5 – Diagrama de Atividades

Figura 4.5 - Diagrama de Atividades

36

4.3.6 – Requisitos de Desempenho

Como o software estará rodando localmente, não há a necessidade de alto desempenho

para ele.

Além disso, há a restrição de apenas um usuário poder usá-lo, mas a possibilidade de

haver vários projetos para serem testados guardados.

4.4 - Atributos

O projeto possuirá os seguintes atributos:

Amigabilidade – O sistema deverá ser de fácil utilização mesmo para aqueles que nunca o

utilizaram, pois sua interface é direta e simples.

Manutenibilidade – O sistema deverá ser de fácil manutenção para facilitar a rápida

correção de erros encontrados.

Expansível - Visando o objetivo de se fazer uma base de testes, o sistema possibilita

futuras expansões no sistema, aumentando a quantidade de funcionalidades dele.

37

Capítulo 5

Projeto de Software

5.1 – Introdução


A finalidade deste artefato é definir um desenho para a arquitetura do projeto. Além

disso, esse documento possui diagramas UML que servirão como referência na etapa de

codificação do sistema. Este documento de projeto de software se dirige ao professor

orientador Antonio Cláudio Gómez de Sousa e à banca avaliadora do projeto de graduação.

5.1.2 – Escopo

O escopo do projeto abrangerá os mesmos itens do escopo das especificações de

requisitos, que foram explicitados no item 4.1.2.

5.2 – Decomposição

5.2.1 – Decomposição em Módulos

O sistema será dividido em módulos para facilitar o desenvolvimento do código e

posterior manutenção. Sendo assim, foram planejados dois módulos: módulo de cadastro e

módulo de teste.

O módulo de cadastro envolve toda a documentação sobre as informações do projeto,

com pontos relevantes como funções e atividades:

- Títulos para identificar os casos de teste e os planos de teste

- Descrição dos objetivo a serem traçados no planejamento dos planos de teste

- Versionamento

O módulo de teste envolve a execução dos testes em si e todos os relatórios que serão

emitidos pelo sistema, podendo ser visualizados a qualquer momento. Assim, temos como

funções desse módulo:

- Execução dos casos de teste

- Ligação do Java com o Cucumber

38

- Emissão de Relatórios

Os módulos descritos acima são apresentados na figura abaixo.

Figura 5.1: Módulos do Sistema

5.2.2 – Diagrama Arquitetural

O sistema será desenvolvido no padrão de projeto MVC (Model-View-Controller), por

ser um modelo amplamente usado para aplicações web e que torna mais simples o

desenvolvimento da codificação e posteriormente a manutenção. Através desse modelo é

possível isolar as camadas de interface gráfica, negócios e modelo de dados. Por isso, caso

haja a necessidade de corrigir alguma das camadas, a manutenção ocorrerá de forma isolada, e

não de todo o sistema.

O framework utilizado para executar o MVC será o VRaptor. No contexto desse

framework, a view é composta por uma página web Java (JSP) e por uma classe que contém

os dados dessa página armazenados como atributos de uma classe e as ações implementadas

através de métodos. A comunicação entre o jsp e a classe citada é realizada através de

interceptadores que são responsáveis por realizar "tratamentos" antes que os dados cheguem à

classe, como por exemplo, preencher os seus atributos ou realizar uma validação. Um método

de uma classe então faz a chamada a um controller responsável por executar a regra de

negócio e invocar os repositórios responsáveis pela persistência das classes de modelo. Todos

os repositórios herdam de uma classe de repositórios genérica, a qual implementa as funções

39

de inserção, atualização, deleção e busca através de um critério. Entretanto, a chamada de um

controller a um repositório não é direta. Para isso foi criada uma fábrica de repositórios que

abstrai do desenvolvedor a complexidade de criação dos objetos. Após ter acesso a um

determinado repositório tem-se acesso a todas as operações relativas ao banco de dados.

A seguir são mostradas duas figuras: a primeira contém uma visão macro da

arquitetura em MVC e a segunda contém uma visão mais detalhada já levando em

consideração o uso do Struts2.

Figura 5.2: Visão macro do diagrama arquitetural do sistema

5.2.3 – Diagrama de Entidade-Relacionamento

O diagrama de entidade-relacionamento foi dividido em duas partes para melhorar o

entendimento e diminuir a complexidade do modelo. A primeira parte mostra as entidades

referentes ao cadastro de dados. A segunda parte contém essencialmente os controles para a

execução do teste em si, mostrando a ligação das entidades.

40

Figura 5.3: DER para a Área “Cadastro”

41

Figura 5.4: DER para a Área “Teste”

42

5.2.4 – Diagrama de Classes

Figura 5.5: Diagrama de classes real

43

5.2.5 – Diagrama de Pacotes

Nesse diagrama estão exibidos os pacotes Java utilizados no sistema, principalmente

no que tange a sua arquitetura.

Figura 5.6: Diagrama de Pacotes

5.2.6 – Decomposição em Processos Concorrentes

A decomposição dos processos concorrentes será realizada por meio de threads que

serão gerenciadas pelo servidor web Tomcat.

44

5.3 – Descrição das Dependências

5.3.1 – Dependência entre Módulos e Dados

A dependência entre os dados está demonstrada nos diagramas de classes. As classes

controladoras são classes virtuais que contém a lógica do sistema, portanto são responsáveis

por controlar a participação das demais classes.

5.4 – Descrição das Interfaces

5.4.1 – Interfaces dos Módulos

Nesta seção serão exibidas as principais interfaces dos módulos através das assinaturas

dos métodos existentes nas classes de negócio.

Projeto

Set<PlanoTeste> getPlanos()

void setPlanos(planos : Set<PlanoTeste>)

Integer getId()

void setId(id : Integer)

String getTitulo()

void setTitulo (titulo : String)

String getDescricao()

void setDescricao(descricao : String)

String getURL()

void setURL(url:String)

Tabela 5.1: Operações da Interface “Projeto”

45

ProjetosController

ProjetosController(result : Result, projetoDAO : ProjetoDAO, session

: Session, validator : Validator)

List<Projetos> index()

Projeto novo()

void cadastrar(projeto : Projeto)

Projeto editar(id: int)

void atualizar(projeto : Projeto)

void remover(id : int)

Tabela 5.2: Operações da Interface “ProjetosController”

ProjetoDAO

ProjetoDAO(session : Session)

List<Projeto> listar()

Projeto consultar(titulo : String)

void salvar(projeto: Projeto)

Projeto consultar(id : Integer)

Projeto consultar(titulo : String, id : Integer)

void atualizar(projeto : Projeto)

void remover(id : int)

Tabela 5.3: Operações da Interface “ProjetoDAO”

46

PlanoTeste

Projeto getProjeto()

void setProjeto(projeto : Projeto)

Integer getId()


String getTitulo()




Integer getVersao()

void setVersao(versao : Integer)

Set<CasoTeste> getCasos()

void setCasos(casos : Set<CasoTeste>)

Tabela 5.4: Operações da Interface “PlanoTeste”

PlanoTestesController

PlanoTestesController(result : Result, session : Session,

projetoDAO : ProjetoDAO, validator : Validator,

planoTesteDAO : PlanoTesteDAO)

List<PlanoTeste> index(id : Integer)

PlanoTeste novo(id : Integer)

void cadastrar(planoTeste : PlanoTeste, projeto_id : Integer)

PlanoTeste editar(id : Integer)

void atualizar(planoTeste : PlanoTeste, projeto_id : Integer)

void remover(id : Integer)

void versionar(id : Integer)

Tabela 5.5: Operações da Interface “PlanoTestesController”

47

PlanoTesteDAO

PlanoTesteDAO(session : Session, projetoDAO : ProjetoDAO)

List<PlanoTeste> listar(id : Integer)

PlanoTeste consultaPlanoTesteMesmoNome(titulo : String, id : Integer,

projeto_id : Integer)

void salvar(planoTeste : PlanoTeste)

PlanoTeste consultar(planoTesteId : Integer)

PlanoTeste consultar(titulo : String, projeto : Projeto)

void atualizar(planoTeste : PlanoTeste)


Tabela 5.6: Operações da Interface “PlanoTesteDAO”

CasoTeste

Set<LogExecucao> getLogs()

void setLogs(logs : Set<LogExecucao>)

Integer getId()


String getTitulo()




String getCaso()

void setCaso(caso : String)

PlanoTeste getPlanoTeste()

void setPlanoTeste(planoTeste : PlanoTeste)

Integer getRunTimes()

Boolean getDeleted()

48

void setDeleted(deleted : Boolean)

Tabela 5.7: Operações da Interface “CasoTeste”

CasoTestesController

CasoTestesController(result : Result, session : Session, validator

: Validator, planoTesteDAO : PlanoTesteDAO, casoTesteDAO :

CasoTesteDAO, logExecucaoDAO : LogExecucaoDAO)

List<CasoTeste> index(id : Integer)

CasoTeste novo(id : Integer)

void cadastrar(casoTeste : CasoTeste, plano_teste_id : Integer)

CasoTeste editar(id : Integer)

void atualizar(casoTeste : CasoTeste, plano_teste_id : Integer)


void executarTeste(id : Integer)

Tabela 5.8: Operações da Interface “CasoTestesController”

CasoTesteDAO

CasoTesteDAO(session : Session, planoTesteDAO :

PlanoTesteDAO)

List<CasoTeste> listar(planoTesteid : Integer)

CasoTeste consultar(plano_teste_id : Integer, id : Integer, titulo : String)

void salvar(plano_teste_id : Integer, casoTeste: CasoTeste)

CasoTeste consultar(id : Integer)

CasoTeste consultar(plano_teste_id : Integer, titulo : String)

void atualizar(planoTeste : PlanoTeste)

int remover(id : Integer)

Tabela 5.9: Operações da Interface “CasoTesteDAO”

49

LogExecucao

Projeto getProjeto()

void setProjeto(projeto : Projeto)

Integer getId()


Date getDataExecucao()

void setDataExecucao(dataExecucao : Date)

Boolean isSucesso()

void setSucesso(sucesso : boolean)

String getMensagem()

void setMensagem(mensagem : String)

CasoTeste getCasos()

void setCasos(casos : CasoTeste)

Tabela 5.10: Operações da Interface “LogExecucao”

LogExecucaosController

LogExecucaosController(result : Result, session : Session,

validator : Validator, casoTesteDAO : CasoTesteDAO,

logExecucaoDAO : LogExecucaoDAO)

List<LogExecucao> index(id : Integer)

Tabela 5.11: Operações da Interface “LogExecucaosController”

LogExecucaoDAO

LogExecucaoDAO(session : Session, casoTesteDAO :

CasoTesteDAO)

void cadastrar(log : LogExecucao)

List<LogExecucao> listar(casoTesteId : Integer)

Tabela 5.12: Operações da Interface “LogExecucaoDAO”

50

CucumberUtil

void prepareFeature(testeCaseBody : String)

String executeCucumber()

Tabela 5.13: Operações da Interface “CucumberUtil”

5.5 – Projeto Detalhado

5.5.1 – Projeto detalhado dos módulos

5.5.1.1 - Projeto detalhado do módulo "Cadastro"

O módulo "Cadastro" consiste principalmente na coleta de informações para a

execução do teste. Assim, temos o detalhamento das classes:

- Projeto:

Consiste principalmente em receber as informações passadas pelos usuários e

estabelecer esses dados nas variáveis da entidade. Além disso, gera a id única do usuário e

estabelece a ligação com os "n" Planos de Teste associados a um único projeto.

- ProjetosController:

Com as informações coletadas pela entidade "Projeto", ele executa as funções de

criação, edição e remoção de um projeto, chamando as funções da entidade "ProjetoDAO".

- ProjetoDAO:

A entidade acessa e mexe com as informações guardadas no banco de dados

relacionados a entidade "ProjetoController" e consequentemente, a "Projeto". Tem as funções

de cadastro para conferirem se a informação a ser usada é inédita no banco de dados quando

relacionado ao título e a id, assim, garante que não há elementos repetidos.

- PlanoTeste:

Sendo ligado sempre a uma entidade "Projeto", deve receber a id dessa entidade como

referência. Além desse dado, estabelece o título, descrição, versão e a ligação com n entidades

"CasoTeste".

51

- PlanoTestesController:

A entidade tem as funções a serem executadas na camada View e assim ligar essa

camada ao banco de dados.

- PlanoTesteDAO:

Faz a manipulação de dados em relação a camada "Plano de Teste" no BD. As funções

cadastram novas entradas e se não há conflitos como títulos iguais.

- CasoTeste:

Seguindo o exemplo de entidades anteriores, inclui as variáveis de título, descrição e

principalmente caso, que é a ligação entre os dois módulos.

- CasoTestesController:

A entidade possui as funções de controlar a entrada de dados pela camada View na

pagina de casos de teste.

- CasoTesteDAO:

Grava ou manipula as informações relacionadas aos casos de teste.

5.5.1.2 - Projeto detalhado do módulo "Teste"

O módulo consiste nas entidades responsáveis em executar o caso de teste registrado

no módulo "Cadastro".

- CasoTestesController:

A entidade tem o comando "executar" que aciona o comando pelo prompt de

comando, acionando assim o Cucumber.

- CasoTesteDAO:

Como o 'caso' está gravado no banco de dados, a entidade acessa essa informação para

que a entidade "CasoTestesController" possa passar o 'caso' a ser executado.

- LogExecucao:

Recebe os dados se o 'caso' foi bem sucedido ou não, além e a 'mensagem' apresentada

ao fim do teste para ser apresentado como resultado.

52

- LogExecucaosController:

Faz a ligação entre as entidades "LogExecucao", "LogExecucaoDAO" e

"CasoTesteDAO".

- LogExecucaoDAO:

Grava e coleta as informações recebidas como resultados dos testes executados.

- CucumberUtil:

A entidade possui as features e paths para que os steps possam ser lidos e executados.

53

Capítulo 6

Plano de Testes

6.1 - Introdução

6.1.1 - Identificador

PTSMOP


A finalidade deste plano de testes é fazer a verificação acerca das validações dos

formulários do sistema bem como de suas funcionalidades. Isso permitirá que o sistema seja

entregue com grande parte de seus erros corrigidos, lembrando que este deve ser um processo

iterativo, e que deve contar com o feedback dado pelos usuários.

6.2 - Descrição Geral

Os itens a serem testados serão os seguintes:

Novo Projeto

Critérios de aceitação:

O usuário deve ser capaz de realizar a inclusão de um novo projeto, com os seguintes

atributos: novo título, descrição e url.

Critérios de falha:

O usuário não consegue realizar a inserção.

Editar Projeto


O usuário deve ser capaz de alterar as informações em um projeto.

54


O usuário não conseguir alterar ou as alterações não serem gravadas.

Remover Projeto


O usuário deve ser capaz de remover um projeto.


Ocorrer alguma falha durante o processo.

Novo Plano de Teste


A adição de um novo plano de teste deve acontecer, obedecendo aos fatores limitantes, como

o mesmo nome para dois planos de teste ser proibido.


O novo plano de testes não ser gravado, ter informações incompletas ou repetidas.

Editar Plano de Teste


A alteração das informações serem feitas com sucesso, obedecendo às regras já mencionadas

no item anterior.


As alterações não serem gravadas ou ocorrer algum erro no banco de dados.

Remover Plano de Teste


O item seja removido sem que cause problemas como: erro no banco de dados, eliminação do

projeto conjuntamente ou não ser apagado.


Aconteça algum dos problemas citados acima.

Novo Caso de Teste


A inserção de um novo caso de teste e seus atributos deve ter sua gravação garantida,

obedecendo a fatores como o preenchimento de todos os campos.


Ocasionar um erro no software ou banco de dados. Além disso, as informações gravadas

estarem incorretas.

55

Editar Caso de Teste


As informações alteradas serem gravadas com sucesso.


A alteração das informações acarretar algum problema, como a criação de um novo caso de

teste, preservando o antigo.

Remover Caso de Teste


O caso de teste não esteja mais presente na lista de casos de teste utilizáveis.


O caso de teste e seus logs de execução continuar disponíveis para o usuário.

Executar Caso de Teste


O resultado crie um relatório satisfatório, desde que o "Caso" tenha sido bem escrito.


Não gerar um relatório eficiente.

Emitir Relatórios


Um usuário deve ser capaz de emitir relatórios.


O usuário não conseguir ter acesso aos relatórios.

6.2.1 – Visão Geral

O software em si é uma ferramenta de automação de testes. Para que o programa não

fosse testado duplamente e que não houvesse uma confusão de onde poderia haver erros (se o

programa estaria executando os procedimentos de procura de erro corretamente ou se haveria

realmente algum erro na sessão testada). Assim, houve a opção por testes manuais.

6.2.2 – Suspensão ou Conclusão

Os testes serão suspensos assim que todos os itens forem verificados sem falhas. Os

testes deverão ser retomados no início de cada nova iteração.

56

6.2.3 – Ambiente

É necessário que o ambiente de testes seja o mais próximo possível do ambiente de

homologação do sistema. Para que isso ocorra serão utilizados os seguintes componentes:

- Sistema Operacional Windows

- Servidor Tomcat

- Banco de dados HSQL

- Java instalado

- JRuby instalado

6.2.4 – Riscos e Gerenciamento

Será considerado o apenas o risco de uma indisponibilidade de tempo para procurar

todo os bugs que o programa venha a ter.

6.3 - Especificação dos Testes

6.3.1 - Especificação de Teste 001

Identificador

ET1

Características

Um usuário deve ser capaz de inserir um novo projeto no banco de dados.

Refinamento

O refinamento do teste só será realizado em uma próxima iteração devido à indisponibilidade

de tempo.

Identificador do Caso de Teste

CT1


Identificador

ET2

57

Características

Um usuário deve ser capaz de editar as informações de um projeto.

Refinamento


de tempo.


CT2


Identificador

ET3

Características

Um usuário deve ser capaz de realizar a remoção de um projeto.

Refinamento


de tempo.


CT3


Identificador

ET4

Características

O sistema deve inserir um novo plano de teste sem causar nenhum problema.

Refinamento


de tempo.


CT4

58


Identificador

ET5

Características

Um usuário deve ser capaz de editar as informações de um plano de teste.

Refinamento


de tempo.


CT5


Identificador

ET6

Características

Um usuário deve ser capaz de remover um plano de teste com sucesso.

Refinamento


de tempo.


CT6


Identificador

ET7

Características

Um usuário deve ser capaz de adicionar uma versão a um plano de teste.

59

Refinamento


de tempo.


CT7


Identificador

ET8

Características

A adição de um novo caso de teste deve ocorrer sem falhas.

Refinamento


de tempo.


CT8


Identificador

ET9

Características

Um usuário deve ser capaz de editar os dados do caso teste.

Refinamento


de tempo.


CT9

60


Identificador

ET10

Características

O sistema deve executar a remoção de um caso de teste sem ocorrências de falhas.

Refinamento


de tempo.


CT10


Identificador

ET11

Características

O programa deve executar um caso de teste, apresentando resultados.

Refinamento


de tempo.


CT11

6.4 - Casos de Teste

6.4.1 - Caso de Teste 001

Identificador

CT1

Itens

Criação de um novo projeto

61

Entrada e Saída

Entradas: título, descrição e url.

Saídas: Tela inicial do sistema em caso de autenticação válida; Mensagem de erro em caso

contrário.

Ambiente

Será necessário utilizar um navegador web para realizar o teste.


Identificador

CT2

Itens

Edição de informações do Projeto

Entrada e Saída

Inserção de projeto

Entradas: titulo, descrição e url.

Saídas: Mensagem de inserção bem sucedida em caso de sucesso; Mensagem de erro em caso

contrário.

Edição de projeto


Saídas: Mensagem de edição bem sucedida em caso de sucesso; Mensagem de erro em caso

contrário.

Ambiente



Identificador

CT3

Itens

Remoção de projeto

62

Entrada e Saída




contrário.

Remoção de projeto

Entradas: Link ‘remover’.

Saídas: Mensagem de remoção bem sucedida em caso de sucesso e arquivo fora da lista;

Mensagem de erro em caso contrário.

Ambiente



Identificador

CT4

Itens

Criação de um plano de teste

Entrada e Saída




contrário.

Inserção de plano de teste

Entradas: titulo, descrição e versão.


contrário.

Ambiente


63


Identificador

CT5

Itens

Edição de plano de teste

Entrada e Saída




contrário.




contrário.

Edição de plano de teste



contrário.

Ambiente



Identificador

CT6

Itens

Remover um plano de teste

Entrada e Saída




contrário.

64




contrário.

Remoção de plano de teste




Ambiente



Identificador

CT7

Itens

Versionar plano de teste

Entrada e Saída




contrário.




contrário.

Versionamento de plano de teste

Entradas: Link ‘versão’.

Saídas: Mensagem de versão bem sucedida em caso de sucesso e a versão do plano de teste

aumenta em um; Mensagem de erro em caso contrário.

Ambiente


65


Identificador

CT8

Itens

Criação de caso de teste

Entrada e Saída




contrário.




contrário.

Inserção de caso de teste

Entradas: titulo, descrição e caso.


contrário.

Ambiente



Identificador

CT9

Itens

Editar caso de teste

Entrada e Saída




contrário.

66




contrário.




contrário.

Edição de caso de teste



contrário.

Ambiente



Identificador

CT10

Itens

Remoçao de caso de teste

Entrada e Saída




contrário.




contrário.

67




contrário.

Remoção de caso




Ambiente



Identificador

CT11

Itens

Executar caso de teste

Entrada e Saída




contrário.




contrário.


Entradas: titulo,descrição e caso.


contrário.

Execução de caso

Entradas: Link ‘executar’.

Saídas: Deve gerar um relatório sobre o resultado do caso consistente com o teste feito.

68

Ambiente


6.5 - Procedimentos de Teste

6.5.1 - Procedimento de Teste 001

Identificador

PT1

Finalidade

Realizar o teste descrito pela especificação ET1.

Necessidades Especiais

N/A

Ações

Ao entrar na pagina do sistema, será acionado o link "Novo", serão preenchidos os campos do

formulário de informações que correspondem às entradas especificadas no caso de teste CT1 e

verificado se a saída corresponde à esperada.

Relatórios

N/A


Identificador

PT2

Finalidade



N/A

Ações

Inserção




69

Edição

Selecionar o link "Editar" do menu do projeto, alterar as informações nos campos do

formulário que correspondem às entradas especificadas no caso de teste CT2. Verificar se a

saída é apresentada como de sucesso.

Relatórios

N/A


Identificador

PT3

Finalidade



N/A

Ações

Inserção




Remoção

Selecionar o link "Remover" do menu do projeto. Verificar se a saída é correspondente à

entrada especificada no CT3.

Relatórios

N/A


Identificador

PT4

Finalidade


70


N/A

Ações

Inserção



verificado se a saída corresponde à esperada. Deve-se então acessar a pasta do projeto.

Inserção




Relatórios

N/A


Identificador

PT5

Finalidade



N/A

Ações

Inserção




Inserção




71

Edição




Relatórios

N/A


Identificador

PT6

Finalidade



N/A

Ações

Inserção




Inserção




Remoção



Relatórios

N/A

72


Identificador

PT7

Finalidade



N/A

Ações

Inserção




Inserção



verificado se a saída corresponde à esperada. Deve-se então acessar a pasta do plano de teste.

Inserção




Relatórios

N/A


Identificador

PT8

Finalidade



N/A

73

Ações

Inserção




Inserção




Inserção




Edição




Relatórios

N/A


Identificador

PT9

Finalidade



N/A

Ações

Inserção




74

Inserção




Inserção




Remoção



Relatórios

N/A


Identificador

PT10

Finalidade



N/A

Ações

Inserção




Inserção




75

Inserção




Execução

Faremos uma execução que seja bem sucedida e para tanto, devemos colocar um 'caso' que vá

ter um resultado positivo com o objeto de teste em questão. O relatório gerado deve apontar

esse resultado como especificado no CT11.

Relatórios

N/A


Identificador

PT11

Finalidade



N/A

Ações

Inserção




Inserção




Inserção




76

Execução

Faremos uma execução que force uma falha e para tanto, devemos colocar um 'caso' que vá

ter um resultado negativo com o objeto de teste em questão. O relatório gerado deve apontar

esse resultado como especificado no CT11.

Relatórios

N/A

77

Capítulo 7

Manual do Usuário

7.1 - Introdução

Esse manual foi feito com o objetivo de ajudar os usuários a entender o funcionamento

do "TestaProjeto". Serão observados suas peculiaridades e o uso mais eficiente dele. Cada

ação feita no programa será descrita para especificar o modo correto de se usar.

7.2 – Funcionalidades Gerais

7.2.1 - Pagina Inicial

7.2.1.1 - Lista de Projetos

Ao se iniciar o sistema, o usuário visualizará a figura:

Figura 7.1 - TestaProjeto

Poderá observar a lista de projetos gravados no sistema e as opções disponíveis serão

descritas a seguir. São presentes as seguintes funções:

- Novo Projeto

- Editar Projeto

78

- Remover Projeto

7.2.1.2 - Novo Projeto

Ao acessar a pagina de "Novo Projeto", o usuário cria um novo projeto que ele quer

registrar no TestaProjeto. Nela, há algumas atribuições que devem ser feitas para que o novo

projeto possa ser inserido no banco de dados. Na figura abaixo, podemos observar os campos

a serem preenchidos:

Figura 7.2 - Novo Projeto

Serão descritos os cuidados que se deve tomar ao preencher os campos:

- Nome: Deve-se escolher um nome que não esteja sendo usado por outro projeto. Caso

isso aconteça, aparecerá uma mensagem informando o erro:

79

Figura 7.3 - Erro no Novo Projeto

- Descrição: Há um mínimo de descrição necessária para que o software deixe que o novo

projeto seja salvo.

- URL: Coloca-se o endereço do projeto a ser alvo de teste.

Deve-se lembrar de preencher todos os campos, pois qualquer um deles que fique vazio,

haverá uma mensagem de erro.

Terminando o preenchimento, se salva o projeto, retornando para a página inicial com o

novo projeto criado. Em caso de desistência, há a possibilidade de cancelar a criação.

Figura 7.4 - Projeto Novo feito com sucesso

80

7.2.1.3 - Editar Projeto

Já havendo projetos cadastrados no TestaProjeto, a funcionalidade de edita-los se torna

possível na tela de projetos pelo seguinte link:

Acessando-o, aparecerá a seguinte pagina:

Figura 7.5 - Editar Projeto

Nela, temos as mesmas opções que temos na seção de "Novo Projeto": Título, Descrição

e URL. Os mesmos cuidados exigidos anteriormente devem ser feitos nessa página também,

como por exemplo, digitar o mesmo nome de um projeto existente no banco de dados.

7.2.1.4 - Remover Projeto

Na pagina de "Lista de Projeto", há a possibilidade de se excluir um projeto.

Essa funcionalidade ao ser acionada, será perguntada uma segunda vez se deseja

realmente que este projeto e todo seu conteúdo seja excluído.

81

Figura 7.6 - Encerrando Projeto

7.2.2 - Página de Plano de Testes

Para acessar a pagina de Plano de Teste, deve-se apenas acessar o ícone "pasta" com o

nome do projeto desejado.

7.2.2.1 - Lista de Plano de Teste

Acessando a pagina de Plano de Teste, podemos observar a seguinte página:

Figura 7.7 - Plano de Teste

82

Com o objetivo de uma visualização simples, a página foi feita semelhante a anterior.

Logo, as funcionalidades "irmãs" estão dispostas do mesmo jeito. São elas:

- Novo Plano de Teste

- Editar Plano de Teste

- Versão Plano de Teste

- Remover Plano de Teste

7.2.2.2 - Novo Plano de Teste

Nessa sessão, o usuário pode adicionar um novo plano de teste ao projeto.

Figura 7.8 - Novo Plano de Teste

Como se pode observar na figura acima, há alguns campos a serem preenchidos para que

o sistema possa permitir a gravação do novo plano de teste no banco de dados:

- Nome: Se dá um nome ou título ao Plano de Teste. Deve haver o cuidado de não repetir

de um plano de teste já criado, caso contrário, haverá uma mensagem de erro avisando.

- Descrição: Deve-se fazer uma pequena descrição do plano de teste com o objetivo de se

deixar claro a missão que este plano de teste deve executar.

- Versão: Esse campo vem previamente com o valor zero, admitindo que será a primeira

vez que esse plano de teste será executado. No entanto, há a necessidade que o valor desse

campo seja diferente de zero.

Como na página "Novo Projeto", todos os campos devem ser preenchidos, caso contrário

uma tela de erro aparecerá, impossibilitando o salvamento do novo plano de teste. Salvando

83

as informações, voltará à página inicial de plano de teste, mostrando o novo plano criado. Em

caso de desistência, o usuário pode cancelar toda a operação no botão "Cancelar".

Figura 7.9 - Plano de Teste feito com sucesso

7.2.2.3 - Editar Plano de Teste

Havendo um plano de existente, podem-se editar as informações dele:

Figura 7.10 - Editar Plano de Teste

Como antes, devem-se fazer as alterações nos campos, tendo o cuidado de não deixar

nenhum campo vazio. Escolhendo salvar as alterações, deve-se clicar no botão "Salvar".

84

Desistindo, usa-se o "Cancelar". Nos dois casos, volta-se para a página com a lista de planos

de teste.

7.2.2.4 - Versão Plano de Teste

Figura 7.11 - Versionar o Plano de Teste

Desejando que a versão do plano de teste seja mudada, o usuário pode usar a versão

rapidamente através da opção presente na tela de "Lista de Planos de Teste"

7.2.2.5 - Remover Plano de Teste

Figura 7.12 - Removendo Plano de Teste

85

O usuário querendo se desfazer de um plano de teste, há o botão de remoção deste.

Haverá uma mensagem para confirmar essa opção, que caso confirmado, o plano de teste não

constará mais na lista.

7.2.3 - Pagina de Caso de Teste

Para visualizar os casos de teste associados ao plano de teste, deve-se clicar no ícone

"pasta" ao lado do nome desejado.

7.2.3.1 - Lista de Casos de Teste

Figura 7.13 - Casos de Teste

Nessa página, o usuário encontrará a lista de casos de teste que o plano de teste contenha,

caso este já tenha algum. Há opções disponíveis, como se pode ver na figura abaixo:

86

Figura 7.14 - Caso de Teste criado com sucesso

- Novo Caso de Teste

- Editar Caso de Teste

- Executar Caso de Teste

- Remover Caso de Teste

- Resultados Caso de Teste

7.2.3.2 - Novo Caso de Teste

Selecionada essa opção, há a seguinte visualização:

87

Figura 7.15 - Novo Caso de Teste

Devem ser preenchidos os seguintes campos:

- Nome: Deve ser dado um nome ao caso de teste diferente a qualquer caso de teste

pertencente ao mesmo plano de teste.

- Descrição: Deve ser dada uma rápida descrição dos objetivos que o usuário tem para a

aplicação daquele caso de teste.

- Caso: Nesse campo, deve ser feito em inglês o cenário e os passos que devem ser

seguidos para que o software execute o caso de teste desejado.

Para uma demonstração, temos o seguinte "Caso" abaixo para mostrar como aprendizado:

Feature: Listagem de Projetos Cadastrados

Para que seja possível criar planos de testes, e seus respectivos casos de teste, ao

acessar o sistema, devo ser capaz de visualizar os projetos cadastrados.

Scenario: Lista de projetos cadastrados.

When I go to http://www.google.com.br

When I fill in "q" with "google"

When I press "Pesquisa Google"

Then I should see "Versão brasileira do popular buscador e diretório."

88

O usuário terminando o preenchimento dessas lacunas pode selecionar "Salvar" para

voltar para a tela anterior, gravando as informações, ou "Cancelar" no caso de querer

descartar o que foi feito.

7.2.3.3 - Editar Caso de Teste

Figura 7.16 - Alterando o Caso de Teste

Com casos de teste criados, podemos editar suas atribuições: Título, Descrição e Caso.

Como citado antes, deve-se ter o mesmo cuidado com o preenchimento de todos os espaços e

a não repetição de títulos já usados.

89

7.2.3.4 - Remover Caso de Teste

Figura 7.17 - Encerrando o Caso de Teste

Na tela de "Lista de Casos de Teste", o usuário pode excluir um caso de teste já existente.

Ao lançar mão dessa opção, o sistema perguntará novamente se realmente deve fazer essa

operação, que em caso de confirmação, o artefato em questão será excluído.

7.2.3.5 - Executar Caso de Teste

Figura 7.18 - Executar Caso de Teste

90

O caso de teste estando com as informações corretas, o software irá operar a ação de

testar a URL dada na página de "Projetos" o "Caso" escrito no seu caso de teste. A operação

terminando, o programa dará uma resposta, avisando que está pronto para uso novamente.

7.2.3.6 - Resultados do Caso de Teste

Ao usar essa função, o usuário é levado para a visualização da pagina "Log de

Execução".

7.2.4 - Log de Execução

Nessa sessão, o usuário vai poder ver os resultados de seus testes ao longo das datas, uma

vez que são apresentadas as seguintes informações: Data, Status e Mensagem. O status

informa se o teste foi bem sucedido, enquanto que "Mensagem" dá um pequeno relatório dos

resultados.

Figura 7.19 - Resultados do Caso de Teste

91

Capítulo 8

Conclusão

Este trabalho apresentou o projeto e a implantação de um sistema de automação de

testes. A princípio, todos os objetivos do projeto foram atingidos, pois o cliente, no caso o

orientador do projeto, aprovou a sua entrega final.

Muitos desafios foram propostos ao aluno na elaboração desse projeto, pois este não

tinha experiência na linguagem Java, nem no manuseio de banco de dados. Até por esse

motivo, o projeto se estendeu além das expectativas do aluno, pois foi necessário um período

de adaptação e aprendizado. Além disso, a mentalidade de planejamento e documentação teve

que ser incorporada no sentido de deixar o projeto mais simples e atendendo a demanda

pedida.

Um exemplo dessas dificuldades foi ao final da codificação, o programa não

conseguia rodar corretamente, pois os comandos do Cucumber não eram carregados. Para

solução destes problemas exigiu um tempo que não era esperado e no quando descoberto,

percebeu-se se tratar de falta de gemas especificas do JRuby( Cucumber, webrat e mechanize)

e que havia uma diferença nas versões do java e por isso foi usado o Maven.

Um dos facilitadores para o término deste trabalho foi o uso de softwares gratuitos,

uma vez que maiores gastos, além do tempo dedicado, não foram necessários. Esse tipo de

tática é apreciada, uma vez que as empresas sempre estão procurando cortar gastos.

A arquitetura elaborada para o sistema foi imaginada para ser uma base para

automação de testes, por isso foi feito um esforço extra para que ela fosse simples e robusta,

para que a sua manutenção e seu entendimento fossem fáceis. Até por isso, a escolha do

recurso Cucumber, que através de uma pesquisa feita pelo aluno, mostrou-se uma ferramenta

que pode ser aprendida rapidamente.

O uso de Vraptor e do modelo MVC ajudou bastante no sentido de fornecer uma

estrutura que o aluno teria uma dificuldade se tivesse que começar do zero. Nesse sentido, o

92

Hibernate também poupou tempo, facilitando o acesso ao banco de dados. A utilização do

Eclipse e da linguagem Java se mostraram oportunidades produtivas, pois seus padrões

facilitam a construção de um projeto.

Para o futuro, se espera que haja uma continuação no desenvolvimento dessa

plataforma, uma vez que seria uma ferramenta valiosa para os alunos usarem em seus

projetos. Há o reconhecimento que existe espaço para introdução de melhorias nas

funcionalidades, como um acesso mais restrito, uma interface ainda mais amigável ou novas

funcionalidades que implementem procedimentos de teste. Além disso, a implementação de

algoritmos de OCR seria interessante para o caso de testes de segurança de sites.

Por fim, deixa-se claro que houve um número pequeno de testes feitos no software,

então alguns problemas podem vir a aparecer, mesmo com o esforço feito para que estes não

aconteçam. Há a expectativa que as lições aprendidas durante o desenvolvimento do projeto

não sirvam apenas no âmbito profissional, como o todo que envolve a construção do

programa tenha proporcionado um grande crescimento em todas as áreas de conhecimento do

aluno.

93

Bibliografia

[1] Oliveira, Rafael Braga de

Framework FUNCTEST: Aplicando Padrões de Software na Automação de Testes

Funcionais [Fortaleza] 2007

109 p. 29,7 cm (MIA/UNIFOR, M.Sc., Dissertação de Mestrado, 2007)

[2] ISSN 0103-9741

Monografias em Ciência da Computação

Arcabouço para Automação de Testes de Programas Redigidos em C, Arndt von Staa

[3]. Project Management Institute

“A Guide to the Project Management Body of Knowledge - PMBOK® Guide”, 2000.

[4]. Kendrick, Tom

“The Project Management Toolkit – 100 Tips and Techniques for Getting the Job Done Right”, 2nd

Edition, Amacon Books, 2010.

[5]. Chrissis, Mary Beth / Konrad, Mike / Shrum, Sandy

“CMMI – Guidelines for Process Integration and Product Improvement”, SEI, 2003.

[6]. Pressman, Roger S.

“Software Engineering - A Practitioner's Approach”, McGraw Hill, 2001.

[7]. Sierra, Kathy / Bates, Bert

"Head First Java, 2nd Edition", O'Reilly Media, 2005

[8]. Wynne, Matt / Hellesoy, Aslak

94

"The Cucumber Book", eBook

[9]. Gartner,Markus

"ATDD by Example - A Pratical Guide to Acceptance Test-Driven Development", eBook

[10] https://github.com/

[11] http://pt.stackoverflow.com/

95

Apêndice

Cocomo

96

97

Documents

TestaProjeto - monografias.poli.ufrj.brmonografias.poli.ufrj.br/monografias/monopoli10010490.pdfMVC - Model-View-Control; COCOMO - COnstructive COst MOdel; RMMM - Risk Mitigation,