JOSÉ ANDRÉ DORIGAN FERRAMENTA PARA GERÊNCIA DE … · JVM – Java Virtual Machine JDK – Java...

58
1 JOSÉ ANDRÉ DORIGAN FERRAMENTA PARA GERÊNCIA DE TESTES EM SOFTWARE LONDRINA - PARANÁ 2010

Transcript of JOSÉ ANDRÉ DORIGAN FERRAMENTA PARA GERÊNCIA DE … · JVM – Java Virtual Machine JDK – Java...

1

JOSÉ ANDRÉ DORIGAN

FERRAMENTA PARA GERÊNCIA DE

TESTES EM SOFTWARE

LONDRINA - PARANÁ

2010

2

JOSÉ ANDRÉ DORIGAN

FERRAMENTA PARA GERÊNCIA DE

TESTES EM SOFTWARE

Relatório Final de Estagio Obrigatório apresentado

ao Curso de Ciência da Computação, no

Departamento de Computação da Universidade

Estadual de Londrina, como requisito para a

obtenção do título de Bacharel, sob orientação do

Prof. Dr. Rodolfo Miranda de Barros.

LONDRINA - PARANÁ

2010

3

JOSÉ ANDRÉ DORIGAN

FERRAMENTA PARA GERÊNCIA DE

TESTES EM SOFTWARE

____________________________ Prof. Dr. Rodolfo Miranda de Barros

Universidade Estadual de Londrina

____________________________ Prof. Dr. Mario Lemes Proença Jr.

Universidade Estadual de Londrina

____________________________ Prof. Ms. Elieser Botelho Manhas Jr.

Universidade Estadual de Londrina

4

RESUMO

Este estágio propõe o desenvolvimento de uma ferramenta que facilite a

documentação e o relatório dos testes executados em softwares, ou seja, uma ferramenta

de Gerenciamento de Testes. Com o conceito de Web App, essa ferramenta tem por

objetivo trocar os documentos preenchidos em papel quando uma atividade de teste é

encerrada por uma interface visual simples, com o propósito de facilitar a descrição,

documentação, consulta, recuperação e o relatório dos testes. Vale ressaltar que este

projeto faz parte de um projeto maior que visa o desenvolvimento de um conjunto de

ferramentas de apoio ao processo de desenvolvimento de software.

Palavras-Chaves: Gerenciamento de Testes, Web App, ADS, EJB.

5

SUMÁRIO

1 INTRODUÇÃO ......................................................................................................... 10

2 PROCEDIMENTOS METODOLÓGICOS ........................................................... 13

2.1 MYECLIPSE 8.0 ...................................................................................................... 13

2.2 ENTERPRISE JAVABEANS 3.0 ................................................................................. 13

2.3 JBOSS APPLICATION SERVER 5.1(JBOSS AS) ........................................................ 15

2.4 JDK 1.5 ................................................................................................................. 16

2.5 RICHFACES 3.3.1 .................................................................................................... 16

2.6 POSTGRESQL 8.4.0 ............................................................................................... 16

3 O PROCESSO DE DESENVOLVIMENTO .......................................................... 18

4 CASOS DE USO ........................................................................................................ 22

4.1 ESPECIFICAÇÃO DE CASO DE USO: <MANTER TESTES> ......................................... 23

4.1.1 Descrição ....................................................................................................... 24

4.1.2 Fluxo Básico .................................................................................................. 24

4.1.3 Fluxos Alternativos ........................................................................................ 24

4.1.4 Requisitos especiais ....................................................................................... 25

4.1.5 Precondições ................................................................................................. 25

4.1.6 Pós-condições ................................................................................................ 25

4.1.7 Pontos de Extensão ........................................................................................ 25

4.1.8 Local View ..................................................................................................... 25

4.1.9 Definição dos atributos ................................................................................. 26

4.1.10 Protótipo da Interface ................................................................................. 27

4.2 ESPECIFICAÇÃO DE CASO DE USO: <MANTER CASO DE TESTES> .......................... 27

4.2.1 Descrição ....................................................................................................... 27

4.2.2 Fluxo Básico .................................................................................................. 27

4.2.3 Fluxos Alternativos ........................................................................................ 28

4.2.4 Requisitos especiais ....................................................................................... 28

4.2.5 Precondições ................................................................................................. 28

4.2.6 Pós-condições ................................................................................................ 29

4.2.7 Pontos de Extensão ........................................................................................ 29

4.2.8 Local View ..................................................................................................... 29

4.2.9 Definição dos atributos ................................................................................. 30

4.2.10 Protótipo da Interface ................................................................................. 31

4.3 ESPECIFICAÇÃO DE CASO DE USO: <MANTER PROCEDIMENTOS DE TESTE> .......... 31

4.3.1 Descrição ....................................................................................................... 31

4.3.2 Fluxo Básico .................................................................................................. 31

4.3.3 Fluxos Alternativos ........................................................................................ 32

4.3.4 Requisitos especiais ....................................................................................... 32

4.3.5 Precondições ................................................................................................. 32

4.3.6 Pós-condições ................................................................................................ 32

4.3.7 Pontos de Extensão ........................................................................................ 33

4.3.8 Local View ..................................................................................................... 33

4.3.9 Definição dos atributos ................................................................................. 34

4.3.10 Protótipo da Interface ................................................................................. 34

4.4 ESPECIFICAÇÃO DE CASO DE USO: <MANTER RELATÓRIO RESUMIDO> ................ 35

6

4.4.1 Descrição ....................................................................................................... 35

4.4.2 Fluxo Básico .................................................................................................. 35

4.4.3 Fluxos Alternativos ........................................................................................ 35

4.4.4 Requisitos especiais ....................................................................................... 36

4.4.5 Precondições ................................................................................................. 36

4.4.6 Pós-condições ................................................................................................ 36

4.4.7 Pontos de Extensão ........................................................................................ 36

4.4.8 Local View ..................................................................................................... 36

4.4.9 Definição dos atributos ................................................................................. 37

4.4.10 Protótipo da Interface ................................................................................. 38

4.5 ESPECIFICAÇÃO DE CASO DE USO: <MANTER HISTÓRICO> ................................... 38

4.5.1 Descrição ....................................................................................................... 38

4.5.2 Fluxo Básico .................................................................................................. 39

4.5.3 Fluxos Alternativos ........................................................................................ 39

4.5.4 Requisitos especiais ....................................................................................... 39

4.5.5 Precondições ................................................................................................. 39

4.5.6 Pós-condições ................................................................................................ 40

4.5.7 Pontos de Extensão ........................................................................................ 40

4.5.8 Local View ..................................................................................................... 40

4.5.9 Definição dos atributos ................................................................................. 41

4.5.10 Protótipo da Interface ................................................................................. 42

5 DIAGRAMAS ............................................................................................................ 43

5.1 DIAGRAMA DE ARQUITETURA ............................................................................... 43

5.2 DIAGRAMA DE ATIVIDADES ................................................................................... 44

5.3 DIAGRAMA DE CLASSES ........................................................................................ 44

5.4 DIAGRAMA DE ENTIDADE E RELACIONAMENTO .................................................... 44

6 RELATÓRIO DE TESTES ...................................................................................... 46

6.1 HISTÓRICO DA REVISÃO ........................................................................................ 46

6.2 INTRODUÇÃO ......................................................................................................... 46

6.2.1 Ambiente ........................................................................................................ 46

6.3 CRITÉRIOS DE COMPLETEZA ................................................................................... 47

6.4 ESPECIFICAÇÃO DOS TESTES .................................................................................. 47

6.4.1 Procedimentos de teste .................................................................................. 48

6.5 CASOS DE TESTE E INCIDENTES DOS TESTES .......................................................... 52

6.5.1 Página Teste .................................................................................................. 52

6.5.2 Página Caso de Teste .................................................................................... 53

6.5.3 Página Relatório Resumido ........................................................................... 54

6.5.4 Página Histórico ........................................................................................... 54

6.6 RELATÓRIO RESUMIDO DOS TESTES ....................................................................... 55

7 CONSIDERAÇÕES FINAIS .................................................................................... 56

8 BIBLIOGRAFIA ....................................................................................................... 57

7

LISTA DE FIGURAS

Figura 3.1: Processo de Desenvolvimento 1 .................................................................. 19

Figura 3.2: Interface 1 .................................................................................................... 21

Figura 3.3: Interface 2 .................................................................................................... 22

Figura 4.1: Diagrama dos Casos de Uso 1...................................................................... 23

Figura 4.2: Local View 1 ................................................................................................ 25

Figura 4.3: Protótipo de Interface 1 ................................................................................ 27

Figura 4.4: Local View 2 ................................................................................................ 29

Figura 4.5: Protótipo de Interface 2 ................................................................................ 31

Figura 4.6: Local View 3 ................................................................................................ 33

Figura 4.7: Protótipo de Interface 3 ................................................................................ 34

Figura 4.8: Local View 4 ................................................................................................ 36

Figura 4.9: Protótipo de Interface 4 ................................................................................ 38

Figura 4.10: Local View 5 .............................................................................................. 40

Figura 4.11: Protótipo de Interface 5 .............................................................................. 42

Figura 5.1: Arquitetura Web 1 ........................................................................................ 43

Figura 5.2: Diagrama de Atividades 1...................................................................... Anexo

Figura 5.3: Diagrama de Classes 1........................................................................... Anexo

Figura 5.4: Diagrama ER 1 ............................................................................................. 45

8

LISTA DE TABELAS

Tabela 4.1: Definição dos Atributos 1 ............................................................................ 26

Tabela 4.2: Definição dos Atributos 2 ............................................................................ 30

Tabela 4.3: Definição dos Atributos 3 ............................................................................ 34

Tabela 4.4: Definição dos Atributos 4 ............................................................................ 37

Tabela 4.5: Definição dos Atributos 5 ............................................................................ 41

Tabela 6.1: Histórico da Revisão 1 ................................................................................. 46

Tabela 6.2: Ambiente 1 .................................................................................................. 47

Tabela 6.3: Critérios de Completeza 1 ........................................................................... 47

Tabela 6.4.1: Procedimentos de teste 1 .......................................................................... 48

Tabela 6.4.2: Procedimentos de teste 2 .......................................................................... 48

Tabela 6.4.3: Procedimentos de teste 3 .......................................................................... 48

Tabela 6.4.4: Procedimentos de teste 4 .......................................................................... 49

Tabela 6.4.5: Procedimentos de teste 5 .......................................................................... 49

Tabela 6.4.6: Procedimentos de teste 6 .......................................................................... 50

Tabela 6.4.7: Procedimentos de teste 7 .......................................................................... 50

Tabela 6.4.8: Procedimentos de teste 8 .......................................................................... 50

Tabela 6.4.9: Procedimentos de teste 9 .......................................................................... 51

Tabela 6.4.10: Procedimentos de teste 10 ...................................................................... 51

Tabela 6.4.11: Procedimentos de teste 11 ...................................................................... 51

Tabela 6.4.12: Procedimentos de teste 12 ...................................................................... 52

9

LISTA DE ABREVIATURAS

Web App – Web Aplication

IEEE - Institute of Electrical and Electronics Engineers

STE – Software Testing Enviroments

IDE – Integrated Development Environment

J2EE – Java 2 Enterprise Edition

JSF – Java Server Faces

TI – Tecnologia da Informação

EJB – Enterprise Java Beans

API – Application Programming Interface

ORM – Object Relational Mapping

POJO – Plain Old Java Object

JVM – Java Virtual Machine

JDK – Java Development Kit

SGBDOR – Sistema Gerenciador de Banco de Dados Objeto Relacional

WBS – Work Breakdown Structure

ADS – Ambiente de Desenvolvimento de Software

GPL – General Public License

PMBOK – Project Management Body of Knowledge

MPS-BR – Modelo de Processo de Software Brasileiro

HTML – HyperText Markup Language

CSS – Cascading Style Sheets

XML – Extensible Markup Language

10

1 INTRODUÇÃO

Atualmente, a busca pela melhoria do processo de software se tornou algo

primordial para que empresas desenvolvam produtos com qualidade e dentro de padrões

pré-definidos, facilitando modificações futuras.

A área de Testes de Softwares é fundamental neste processo de

desenvolvimento. Além de utilizar métodos para comprovar que os requisitos

especificados previamente foram cumpridos, e os requisitos não especificados não

constam no software, os testes ajudam o desenvolvedor a mensurar a qualidade de um

software baseando-se no número de defeitos encontrados.

Como em qualquer outra área, os testes necessitam ser criados,

documentados e apresentar a possibilidade de relatar erros encontrados durante a

aplicação. Existem alguns modelos para a documentação, como o IEEE Standard for

Software Test Documentation [3], criado pela IEEE Computer Society, que traz uma

lista de documentos básicos para testes de softwares.

No desenvolvimento de software é necessário criar soluções tecnológicas

utilizando como base os requisitos que o cliente apresenta. A Engenharia de Software

preocupa-se em tratar todos os requisitos para que o projeto obtenha a melhor qualidade

possível, dentro de prazos controlados e com custos compatíveis com o mercado [4].

São necessárias melhorias neste cenário, como por exemplo, a automatização de

algumas fases do desenvolvimento acarretando ganho de desempenho e aumento da

qualidade.

Segundo [6], a qualidade do produto final em um desenvolvimento de

software depende dos métodos, técnicas e ferramentas que o desenvolvedor usa. Uma

escolha mal feita destes pode afetar não só a qualidade como também o custo do

projeto. Por este motivo é de grande importância que projetos sejam feitos obedecendo a

padrões e métricas.

Existem estágios definidos no desenvolvimento, em [2] o primeiro estágio

de um desenvolvimento de software envolve a elaboração de uma proposta para

executar o projeto. A proposta descreve os objetivos do projeto e como ele será

realizado. Em geral inclui também estimativas de custo e programação. Um

11

gerenciamento eficaz de um projeto de software depende de um planejamento acurado

do andamento do projeto.

Ainda sobre o desenvolvimento, podemos citar [8] na questão que trata do

modelo de qualidade de software, quando usamos um modelo podemos medir variáveis

independentes mais cedo do que outras no ciclo de desenvolvimento, mas ainda

precisaríamos medir as variáveis dependentes do processo. Para essas podem-se

predizer seus valores baseando-se nas variáveis independentes dos módulos. Assim,

com os modelos estatísticos podem-se estimar parâmetros para módulos similares

baseando nas variáveis dependentes e independentes de cada um.

A maioria dos projetos segue um cronograma de atividades chamado ciclo

de vida. Os ciclos de vida diferem de um projeto para outro no número de iterações,

fases, métodos de controle e número de protótipos criados. Ao final do ciclo de vida de

um desenvolvimento de software encontra-se a fase de testes, que verifica se o sistema

produzido está livre de erros de programação, lógica e se corresponde aos requisitos

previamente especificados.

Em [1] cita-se que, sobre vários aspectos, o teste é um processo

independente e o número de tipos diferentes de testes varia tanto quanto as diferentes

abordagens de desenvolvimento. Os testes em software podem ser separados em duas

categorias: os que são baseados nas especificações funcionais dos sistemas (chamado de

testes de black-box ou testes de caixa-preta), e os que são baseados nas estruturas

internas dos sistemas (chamado de testes de white-box ou testes de caixa-branca), essas

categorias são utilizadas levando em conta a área do sistema que deseja-se verificar

erros[5].

A Verificação e Validação são nomes dados aos processos de verificação e

análise que asseguram que o software cumpra com suas especificações e atenda às

necessidades dos clientes que estão pagando por ele. A verificação e validação

constituem um processo de ciclo de vida completo, começando com as revisões dos

requisitos e continuando com as revisões do projeto e as inspeções de código até chegar

aos testes dos produtos [2].

Alguns autores como [7], mostram que a evolução dos testes está sendo

baseada em Software Testing Environments (STEs), consistindo em ambientes

automatizados específicos para testes de softwares, buscando maior eficiência e

aumento no número de capacidades dos testes.

12

Ainda que algumas empresas não possuam seu sistema de testes baseados

em automação, é possível automatizar os documentos utilizados na aplicação dos testes

e na documentação dos mesmos. Com isso conseguiríamos aumentar o desempenho,

melhorar a qualidade e facilitar a execução da fase de testes de software.

A ferramenta de Gerência de Testes em Software foi desenvolvida dentro da

Fábrica de Software GAIA, dentro do Departamento de Computação, no Centro de

Ciências Exatas (CCE) na Universidade Estadual de Londrina.

Uma fábrica de software é uma organização que provê serviços de

desenvolvimento de sistemas com alta qualidade, baixo custo e de forma rápida,

utilizando um processo de desenvolvimento de software bem definido e tecnologia de

ponta, além de algumas formas de feedback para reconhecer e lidar com oportunidades

de melhoria do processo [15].

A Fábrica GAIA utiliza um processo de desenvolvimento baseado no

Processo Unificado, iterativo e incremental [16], direcionado a casos de uso e centrado

na arquitetura.

Este trabalho está dividido da seguinte forma: no Capitulo 2 serão

apresentados os conceitos utilizados no desenvolvimento da ferramenta, bem como os

métodos utilizados, no Capitulo 3, será apresentado o modelo de Processo de

Desenvolvimento utilizado. No Capitulo 4 serão apresentados os Casos de Uso da

ferramenta desenvolvida, no Capitulo 5 serão apresentados os diagramas que compõem

a documentação da ferramenta, no Capítulo 6 será apresentado o relatório dos testes

executados para verificar a conformidade e a qualidade da ferramenta, e finalmente no

Capítulo 7 serão apresentadas as considerações finais.

13

2 PROCEDIMENTOS METODOLÓGICOS

Os procedimentos metodológicos apresentados a seguir têm como objetivo

demonstrar todo o ambiente e ferramentas utilizadas desde a arquitetura até o processo

final de testes e implementação.

2.1 MyEclipse 8.0

O MyEclipse 8.0[9] é uma IDE J2EE que foi construído sobre a plataforma

Eclipse e integra soluções proprietárias e open source no ambiente de desenvolvimento.

Ele adiciona ferramentas de banco de dados, um designer visual para web, ferramentas

de persistência, Struts e JSF, e outras características básicas do Eclipse.

Um dos principais motivos da escolha dessa IDE para o desenvolvimento

foi sua capacidade de trabalhar com a persistência de objetos em Banco de Dados. O

MyEclipse oferece outras vantagens como facilidade de adaptação para novos

desenvolvedores e continuidade de desenvolvimento na mesma IDE.

2.2 Enterprise JavaBeans 3.0

Existem várias aplicações de software que executam funções empresariais e

tipicamente envolvem grandes quantidades de dados que são simultaneamente

acessados por muitos usuários. Estas aplicações raramente executam isoladamente. Ao

invés disto, cada uma é normalmente apenas um pedaço do quebra-cabeça da paisagem

do TI de uma companhia, e tem que interagir com as pessoas e com outros sistemas.

Resumindo, o desenvolvimento de aplicações empresariais é um trabalho

difícil. Aspectos como o desempenho, escalabilidade, concorrência e segurança devem

ser contemplados em quase todas as aplicações empresariais, para que as mesmas

cumpram adequadamente o seu papel na empresa.

Em resposta a estes desafios, a especificação do EJB foi introduzida em

março de 1998, para tornar mais fácil a confecção de sistemas empresariais distribuídos

14

orientados a objeto. A especificação e os servidores de aplicação que implementam a

maior parte de estas funcionalidades, tiveram sucesso em atingir estes objetivos. Porém

através dos anos, as falhas do EJB, junto com o advento de alternativas mais simples,

fizeram com que muitos questionassem se o EJB oferece a melhor solução para o

desenvolvimento produtivo de aplicações empresariais.

Falhas do EJB frequentemente citadas incluem o seguinte:

Componentes que queiram tirar vantagem dos serviços empresariais

fornecidos estarão ligados à API EJB;

É uma proposta do tipo tudo ou nada. Mesmo que quisermos apenas um

serviço do EJB, temos que aceitar tudo o que vem com ele;

Componentes do EJB requerem um recipiente (container) e são difíceis

de testar;

Cada EJB requer vários artefatos (interfaces, classes e descritores);

Arquiteturas EJB tradicionais são menos orientadas a objeto e

introduzem "falsos objetos" que têm só estados e nenhum

comportamento.

Alternativas populares para o EJB incluem o seguinte:

Programação Orientada a Aspecto (Aspect Oriented Programming);

Recipientes de peso leve tais como Spring, Pico Container e Hivemind;

Ferramentas de mapeamento objeto-relacional (Object Relational

Mapping - ORM) tais como Hibernate JPA;

.NET como componentes de serviços.

Para solucionar algumas das falhas citadas anteriormente foi criado então o

Enterprise JavaBeans 3.0, ou EJB 3.0[10], que têm por objetivo fornecer aos

desenvolvedores um gerenciamento automático de muitos serviços essenciais aos

aplicativos.

A especificação do projeto público do EJB 3.0, objetiva facilitar o

desenvolvimento e tornar mais simples a alavancagem dos serviços empresariais.

Alguns aspectos do EJB 3.0 incluem:

O modelo de programação POJO (Plain Old Java Object – Antigo

Objeto Java Simples);

15

O framework de persistência leve ORM;

Injeção de dependência;

Comentários Metadata.

Outros aspectos notáveis da especificação EJB 3.0 incluem:

Configuração por exceção;

Eliminação de interfaces de componente;

Eliminação de interfaces home;

Redução do uso de exceções verificadas.

2.3 JBoss Application Server 5.1(JBoss AS)

O JBoss Aplication Server[11] é um servidor de aplicação open source

baseado no J2EE. É o responsável por fornecer a infraestrutura de serviços para a

execução de aplicações distribuídas. Os servidores de aplicação são executados em

servidores e são acessados pelos clientes através de uma conexão de rede.

Existem várias versões JBoss, tais como:

JBoss AS 4.0: um servidor de aplicações Java EE 1.4, possui um container

Apache Tomcat 5.5 embutido como servelt. Ele suporta qualquer Java Virtual Machine

entre as versões 1.4 e 1.6.

JBoss AS 4.2: também funciona como um servidor de aplicações Java EE

1.4, mas implementa o Enterprise JavaBeans 3.0 por padrão. Ele requer o Java

Development Kit versão 5 e junto apresenta o servidor Tomcat 5.5.

JBoss AS 5.1: lançado em 2009, funciona como um servidor de aplicação

Java EE 5. É uma atualização menor do grande lançamento JBoss AS 5.0, que estava em

desenvolvimento a mais de 3 anos e é construído em cima de um Microcontainer JBoss,

contém uma visualização de alguns elementos do Java EE 6.

O servidor JBoss pode ser executado em diversos sistemas operacionais,

incluindo muitas plataformas POSIX (como o Linux, FreeBSD e Mac OS X), Microsoft

Windows e outros, e necessita de uma JVM adequada presente no sistema.

16

2.4 JDK 1.5

O Java Development Kit (JDK) [12] é um pacote básico de ferramentas

oferecidas pela empresa Sun Microsystems para o público em geral. Este conjunto de

aplicações foi concebido para programação de aplicações de software, utilizando

principalmente a linguagem de programação Java.

O poder de aplicações Java pode ser visto no número infindável de

ferramentas destinadas a trabalhar na Internet e também para funcionar em desktop. É

uma das ferramentas obrigatórias para programas Java serem executados.

A nova versão do JDK (1.5) apresenta novas extensões para a linguagem de

programação Java. Uma destas é a introdução de "Generics" (similar aos Templates do

C++). A programação genérica permite que você escreva código que pode ser

reutilizado para muitos tipos de objetos diferentes.

2.5 Richfaces 3.3.1

Richfaces 3.3.1[13] são um conjunto de implementações que constituem

uma biblioteca de componentes para aplicações web utilizando o framework JSF que

atualmente é mantido por JBoss.org. Ele permite a fácil integração de recursos Ajax no

desenvolvimento de aplicações corporativas.

RichFaces é mais do que apenas uma biblioteca de componentes para

JavaServer Faces, pode ser considerada uma extensão do Ajax4jsf com inúmeros

componentes com Ajax “embutido” e com um suporte a Skins que podem deixar as

interfaces da aplicação com um visual padronizado.

2.6 PostgreSQL 8.4.0

O sistema gerenciador de banco de dados objeto relacional (SGBDOR)

PostgreSQL 8.4.0[14] foi desenvolvido como projeto de código aberto e é um dos

SGBDs mais avançados, contando com recursos como: consultas complexas, chaves

estrangeiras, integridade transacional, etc.

17

O PostgreSQL suporta funções de retorno de linha, onde a saída da função é

um conjunto de valores que pode ser tratada muito como uma tabela dentro de

consultas. Agrega funções personalizadas e janelas também podem ser definidas.

Consultas podem ser definidas para executar com os privilégios, quer do

chamador ou do usuário que definiu a função. Funções são muitas vezes referidas como

os procedimentos armazenados, embora haja uma ligeira distinção técnica entre os dois.

Para a administração do Banco de Dados é utilizado o pgAdmin que é uma

ferramenta gráfica gratuita e aberta de administração para o PostgreSQL, que é

suportada em diversos sistemas. O programa está disponível em mais de uma dezena de

línguas.

O primeiro protótipo, chamado pgManager, foi escrita para PostgreSQL

6.3.2 a partir de 1998, refeita e lançada como pgAdmin sob a licença GPL nos meses

mais tarde. A segunda geração (chamado pgAdmin II) foi uma reescrita completa,

lançado em 16 de Janeiro de 2002. A versão atual é pgAdmin III, que foi originalmente

lançado sob a Artistic License e agora está liberado sob a mesma licença do

PostgreSQL. Ao contrário das versões anteriores que foram escritos em Visual Basic,

pgAdmin III é escrito em C ++, usando a estrutura wxWidgets permitindo que ele seja

executado em sistemas operacionais mais comuns.

18

3 O PROCESSO DE DESENVOLVIMENTO

Basicamente, as Fábricas de Software podem ser classificadas em Fábricas

de Programas, Fábricas de Teste e Fábricas de Projetos. As Fábricas de Programas

caracterizam-se por atuarem em apenas uma porção do processo produtivo do software.

Seu objetivo é codificar e testar programas conforme um acordo de níveis de serviços

com o cliente ou usuário. As Fábricas de teste atuam no teste do software verificando e

validando se a codificação está em conformidade com a especificação de requisitos. E

as Fábricas de Projetos, por sua vez, atuam com um pouco mais de abrangência no

processo de produção, englobando além das atividades inerentes à Fábrica de Programas

e à Fábrica de Testes, fases como modelagem de negócio, requisitos, análise e design.

Tem-se também, a chamada Fábrica de Projetos de Software ou Fábrica de

Projetos Ampliada que, além da abrangência da Fábrica de Projetos, atua também na

arquitetura da solução. Seu objetivo é a conceituação do software, preocupando-se em

projetar uma solução em que o software se caracteriza apenas como um dos

componentes.

O processo de desenvolvimento de software compreende um conjunto de

atividades que engloba métodos, ferramentas e procedimentos, com o objetivo de

produzir softwares que atendam aos requisitos especificados pelos usuários ou clientes.

A partir de uma perspectiva de gerenciamento baseada no PMBOK [17], o

Processo de Desenvolvimento de Software da GAIA é dividido em seis fases, cada uma

concluída por um marco principal. A Figura 3.1 apresenta este Processo e a forma como

a Gerência de Comunicação atua com o Processo GAIA, ou seja, em paralelo a este

Processo. Cada fase do processo é composta por atividades, sendo que cada uma destas

atividades são descritas por um fluxo de trabalho composto por tarefas a serem

realizadas pelos atores do processo, gerando artefatos (atas, documentos, código fonte,

planos de testes).

19

Figura 3.1: Processo de Desenvolvimento 1

Análise Inicial: reunião com o cliente para entendimento do problema e definição

do escopo. O número de reuniões é definido pela equipe de analistas, visto que, por

política organizacional [18], a GAIA investe na qualidade deste escopo,

minimizando ao máximo os problemas de falta de entendimento, insatisfações

futuras do cliente pelo fato do sistema não atender suas necessidades, evitando com

isso o retrabalho. O resultado deste investimento é a minimização dos riscos do

projeto. Para cada reunião é gerada uma ata que deve ser assinada por todos os

participantes, firmando o comprometimento de todos os envolvidos e para que os

assuntos tratados sejam disponibilizados eletronicamente a todos os demais

integrantes do desenvolvimento deste produto. Ao término desta etapa, tem-se uma

proposta para o cliente, incluindo o escopo que é representado por uma WBS (Work

Breakdown Structure), premissas, riscos, o prazo (em meses) para o

desenvolvimento e o custo do projeto. Para estabelecimento dos prazos e custos

utiliza-se um banco de dados histórico do desempenho da equipe em projetos

similares;

Análise e Planejamento: Após a aprovação da proposta, deve-se iniciar o

planejamento do projeto, por meio da definição dos casos de uso e das respectivas

especificações, dos riscos e prioridades de desenvolvimento, da expansão da WBS,

da alocação de pessoas, da elaboração do cronograma, do estabelecimento de pontos

20

de controle, do número de iterações e de quais casos de uso serão desenvolvidos em

cada iteração. É gerado um artefato intitulado Plano de Projeto. Vale ressaltar que

esta fase do processo de desenvolvimento da GAIA ocorre de maneira iterativa, ou

seja, após definirmos e iniciarmos a primeira iteração, no término da mesma, caso o

desenvolvimento deva continuar, esta fase é disparada novamente. Nesta fase

também ocorre o estabelecimento do grau de severidade para a aprovação ou não

dos resultados das atividades pelo projeto. O grau de rigorosidade implica

diretamente no controle da qualidade do projeto, ou seja, quanto maior a grau de

rigorosidade, mais rígido é o processo de garantia de qualidade do projeto;

Monitoramento e Controle: Paralelamente a Análise e Planejamento, deve-se

iniciar o monitoramento e controle do projeto, buscando verificar se o que está

sendo feito está de acordo com o planejado, tomando ações corretivas quando

necessário. Esta verificação deverá ser feita nos pontos de controle indicados no

artefato Plano de projeto;

Execução: Nesta fase ocorre a especificação e a implementação dos respectivos

casos de uso e os testes unitários. A especificação dos casos de uso deve ser

verificada e validada. Caso ocorra uma quantidade igual ou superior de não

conformidades aceitáveis para o projeto em questão, a iteração deve ser cancelada e

um novo planejamento deve ser estabelecido levando-se em consideração os atrasos

e as consequências dos mesmos. Após uma análise do resultado dos testes, decide-

se, baseado também no grau de rigorosidade, por corrigir as não conformidades

encontradas e realizar novamente os testes e partirmos para a próxima fase intitulada

Entrega ou cancelarmos a iteração e voltarmos para a fase de Análise e

Planejamento;

Entrega: Esta fase está responsável por executar os testes de integração que, caso

registre um resultado positivo, iniciará a entrega e implantação da parte do produto

desenvolvida até a presente iteração. Se o projeto ainda não terminou, a fase de

Análise e Planejamento é iniciada novamente. Do contrário, a fase de Finalização é

iniciada;

21

Finalização: Nesta faze é realizada um reunião de término do projeto, na qual são

levantadas as lições aprendidas, sendo as mesmas registradas em ata para futuras

consultas e melhorias no processo de desenvolvimento. É gerado um documento

indicando o recebimento do produto pelo cliente e o término do projeto.

Todas as fases do processo foram definidas com o propósito de ser o mais

simples possível, porém mantendo o formalismo para garantir a qualidade do

desenvolvimento nas nuvens.

O processo de desenvolvimento GAIA, onde a ferramenta de Gerência de

Testes foi desenvolvida, também contou com a participação de um analista de Design

que foi posteriormente incluído ao projeto. A função desse analista foi criar um padrão

de interface para todo o ADS (Ambiente de Desenvolvimento de Software), baseando-

se no guia de estilos definido pelo GAIA.

Assim a ferramenta desenvolvida apresenta uma diferenciação entre a

interface final e a utilizada nos protótipos dos casos de uso que serão vistos a seguir. As

figuras 3.2 e 3.3 mostram exemplos da padronização de interface utilizada no ADS

dentro do ciclo de desenvolvimento GAIA.

Figura 3.2: Interface 1

22

Figura 3.3: Interface 2

4 CASOS DE USO

Na Engenharia de Software, um caso de uso (ou use case) é um tipo de

classificador representando uma unidade funcional coerente provida pelo sistema, ou

classe apresentando mensagens trocadas entre os sistemas e um ou mais atores.

Um caso de uso representa uma unidade significante e discreta da interação

entre um usuário e o sistema. Cada caso de uso tem uma descrição o qual descreve a

funcionalidade que irá ser construída no sistema proposto. Pode-se "incluir" outra

funcionalidade de caso de uso ou "estender" outro caso de uso com seu próprio

comportamento.

A seguir, são apresentados os casos de uso da ferramenta desenvolvida,

onde em cada caso de uso são especificados seus fluxos básicos, alternativos, requisitos

especiais, pré-condições, pós-condições, pontos de extensão, local view, definição dos

atributos e protótipo da interface.

Dentro da descrição de cada caso de uso existem figuras que apresentam o

local view representando um diagrama de caso de uso e o Protótipo de Interface que

representa como a interface inicial é planejada.

As tabelas de Definição de atributos apresentam quais os atributos que o

caso de uso em questão necessita para armazenar as informações.

23

A figura 4.1 contém todos os diagramas de caso de uso utilizados no ADS,

para que seja possível o entendimento sobre onde cada ferramenta está incluída dentro

do projeto e quem foi o responsável pela sua criação.

Figura 4.1: Diagrama dos Casos de Uso 1

24

4.1 Especificação de Caso de Uso: <Manter Testes>

4.1.1 Descrição

Esse caso de uso destina-se a cadastrar, manter atualizado e excluir os testes

realizados em projetos de software.

4.1.2 Fluxo Básico

O analista de testes deve preencher todos os campos necessários para poder

cadastrar um Teste, após isso o analista de testes seleciona a opção “Salvar Dados”, o

sistema então valida os campos do formulário e volta à tela inicial.

4.1.3 Fluxos Alternativos

Alterar um Teste Cadastrado: O analista de testes pode alterar um teste já

cadastrado através de uma lista que será mostrada na tela, em seguida clicando no botão

“Alterar Teste”. O sistema mostrará a tela onde as alterações podem ser feitas, após isso

o analista de testes seleciona a opção “Atualizar Dados” e o sistema volta à tela inicial.

Formulário não validado: O sistema pode não validar o formulário de

dados. O analista de testes então deverá corrigir os erros mostrados e selecionar a opção

“Salvar Dados”. O sistema valida os campos do formulário e volta à tela inicial.

Excluir um Teste Cadastrado: O analista de testes pode excluir um teste já

cadastrado através de uma lista que será mostrada na tela, em seguida clicando no botão

“Excluir Teste”, será mostrado um aviso informando que essa operação não poderá ser

desfeita, oferecendo a opção de confirmar e de cancelar. Selecionando a opção

“Confirmar” o sistema exclui o teste selecionado bem como todos os itens associados a

esse teste, após isso o sistema volta à tela inicial.

25

4.1.4 Requisitos especiais

Não possui.

4.1.5 Precondições

Não possui

4.1.6 Pós-condições

Manter Histórico: Após a execução deste caso de uso o sistema estará apto

para executar o caso de uso Manter Histórico.

Manter Casos de Teste: Após a execução deste caso de uso o sistema

estará apto para executar o caso de uso Manter Casos de Teste.

Manter Procedimentos de Teste: Após a execução deste caso de uso o

sistema estará apto para executar o caso de uso Manter Procedimentos de Teste.

Manter Relatório Resumido: Após a execução deste caso de uso o sistema

estará apto para executar o caso de uso Manter Relatório Resumido.

4.1.7 Pontos de Extensão

Não Possui.

4.1.8 Local View

Figura 4.2: Local View 1

26

4.1.9 Definição dos atributos

Tabela 4.1: Definição dos Atributos 1

Nome da variável Tipo Limitações Descrição Interface Obrigatório

id_teste Integer - Indica o id do teste e é a chave primária da tabela. - Sim

descricao String 1 a 50 caracteres Uma descrição curta do teste Campo de texto Sim

objetivos_do_teste String 1 a 300 caracteres Os objetivos que esperam ser alcançados com o teste Campo de texto Sim

escopo String 1 a 300 caracteres Todos os casos de uso e requisitos não-funcionais Campo de texto Sim

referencia String 1 a 300 caracteres Referência de Documentos relevantes ao teste Campo de texto Sim

ambiente String 1 a 300 caracteres Ambiente a ser usado para a realização do teste Campo de texto Sim

itens Lista - Apresenta uma lista com número de ordem, item e

comentários

Tabela Sim

criterios Lista - Apresenta uma lista com número de ordem e critério Tabela Sim

27

4.1.10 Protótipo da Interface

4.2 Especificação de Caso de Uso: <Manter Caso de Testes>

4.2.1 Descrição

Esse caso de uso destina-se a cadastrar, manter atualizado e excluir os Casos

de Teste dos testes realizados em projetos de software.

4.2.2 Fluxo Básico

O analista de testes deve preencher todos os campos necessários para poder

cadastrar um Caso de Teste, incluindo cadastrar entradas e saídas necessárias e os

procedimentos utilizados no caso de teste, após isso o analista de testes seleciona a

Figura 4.3: Protótipo de Interface 1

28

opção “Salvar Dados”, o sistema então valida os campos do formulário e volta à tela

inicial.

4.2.3 Fluxos Alternativos

Alterar um Caso de Teste Cadastrado: O analista de testes pode alterar

um caso de teste já cadastrado através de uma lista que será mostrada na tela, em

seguida clicando no botão “Alterar Caso de Teste”. O sistema mostrará a tela onde as

alterações podem ser feitas, após isso o analista de testes seleciona a opção “Atualizar

Dados” e o sistema volta à tela inicial.

Formulário não validado: O sistema pode não validar o formulário de

dados. O analista de testes então deverá corrigir os erros mostrados e selecionar a opção

“Salvar Dados”. O sistema valida os campos do formulário e volta à tela inicial.

Excluir um Teste Cadastrado: O analista de testes pode excluir um caso

de teste já cadastrado através de uma lista que será mostrada na tela, em seguida

clicando no botão “Excluir Caso de Teste”, será mostrado um aviso informando que

essa operação não poderá ser desfeita, oferecendo a opção de confirmar e de cancelar.

Selecionando a opção “Confirmar” o sistema exclui o caso de teste selecionado bem

como todos os itens associados a esse teste, após isso o sistema volta à tela inicial.

4.2.4 Requisitos especiais

Não possui.

4.2.5 Precondições

Manter Testes: Antes da execução deste caso de uso o sistema deverá ter

executado o caso de uso Manter Testes.

Manter Procedimentos de Teste: Antes da execução deste caso de uso o

sistema deverá ter executado o caso de uso Manter Procedimentos de Teste.

29

4.2.6 Pós-condições

Manter Histórico: Após a execução deste caso de uso o sistema estará apto

para executar o caso de uso Manter Histórico.

4.2.7 Pontos de Extensão

Não Possui.

4.2.8 Local View

Figura 4.4: Local View 2

30

4.2.9 Definição dos atributos

Tabela 4.2: Definição dos Atributos 2

Nome da variável Tipo Limitações Descrição Interface Obrigatório

id_teste Integer - Indica o id do teste e é a chave estrangeira da tabela,

referenciando o id_teste da tabela Teste

- Sim

id_caso Integer - Indica o id do caso de teste e é a chave primária da

tabela

- Sim

itens_testar String 1 a 100 caracteres Quais itens serão testados Campo de texto Sim

entradas_saidas Lista - Lista contendo os campos de entrada e saída e seus

respectivos valores esperados

Tabela Sim

ambiente String 1 a 300 caracteres Especificação de ambiente necessário para o item Campo de texto Sim

procedimentos Lista - Lista contendo os Procedimentos a serem usados no

teste

Tabela Sim

dependência String 1 a 300 caracteres Dependências para execução do item Campo de texto Sim

saida_observada String 1 a 300 caracteres Resultados observados nas saídas dos campos Campo de texto Sim

impacto String 1 a 300 caracteres Conseqüências indesejadas Campo de texto Sim

31

4.2.10 Protótipo da Interface

4.3 Especificação de Caso de Uso: <Manter Procedimentos de Teste>

4.3.1 Descrição

Esse caso de uso destina-se a cadastrar, manter atualizado e excluir os

Procedimentos de Teste dos testes realizados em projetos de software.

4.3.2 Fluxo Básico

O analista de testes deve preencher todos os campos necessários para poder

cadastrar um Procedimento de Teste, após isso o analista de testes seleciona a opção

“Salvar Dados”, o sistema então valida os campos do formulário e volta à tela inicial.

Figura 4.5: Protótipo de Interface 2

32

4.3.3 Fluxos Alternativos

Alterar um Procedimento de Teste Cadastrado: O analista de testes pode

alterar um procedimento de teste já cadastrado através de uma lista que será mostrada na

tela, em seguida clicando no botão “Alterar Procedimento de Teste”. O sistema mostrará

a tela onde as alterações podem ser feitas, após isso o analista de testes seleciona a

opção “Atualizar Dados” e o sistema volta à tela inicial.

Formulário não validado: O sistema pode não validar o formulário de

dados. O analista de testes então deverá corrigir os erros mostrados e selecionar a opção

“Salvar Dados”. O sistema valida os campos do formulário e volta à tela inicial.

Excluir um Teste Cadastrado: O analista de testes pode excluir um

procedimento de teste já cadastrado através de uma lista que será mostrada na tela, em

seguida clicando no botão “Excluir Procedimento de Teste”, será mostrado um aviso

informando que essa operação não poderá ser desfeita, oferecendo a opção de confirmar

e de cancelar. Selecionando a opção “Confirmar” o sistema exclui o procedimento de

teste, após isso o sistema volta à tela inicial.

4.3.4 Requisitos especiais

Não possui.

4.3.5 Precondições

Manter Testes: Antes da execução deste caso de uso o sistema deverá ter

executado o caso de uso Manter Testes.

4.3.6 Pós-condições

Manter Histórico: Após a execução deste caso de uso o sistema estará apto

para executar o caso de uso Manter Histórico.

33

4.3.7 Pontos de Extensão

Não Possui.

4.3.8 Local View

Figura 4.6: Local View 3

34

4.3.9 Definição dos atributos Tabela 4.3: Definição dos Atributos 3

Nome da variável Tipo Limitações Descrição Interface Obrigatório

id_procedimento Integer - Indica o id do procedimento de teste e é a chave

primária da tabela

- Sim

objetivo String 1 a 100 caracteres Objetivo do procedimento Campo de texto Sim

requisitos_especiais String 1 a 100 caracteres Requisitos especiais para esse procedimento Campo de texto Sim

fluxo String 1 a 500 caracteres Fluxo do procedimento detalhado Campo de texto Sim

4.3.10 Protótipo da Interface

Figura 4.7: Protótipo de Interface 3

35

4.4 Especificação de Caso de Uso: <Manter Relatório Resumido>

4.4.1 Descrição

Esse caso de uso destina-se a cadastrar, manter atualizado e excluir um relatório

resumido dos testes realizados em projetos de software.

4.4.2 Fluxo Básico

O analista de testes deve preencher todos os campos necessários para poder

cadastrar um Relatório Resumido, após isso o analista de testes seleciona a opção “Salvar

Dados”, o sistema então valida os campos do formulário e volta à tela inicial.

4.4.3 Fluxos Alternativos

Alterar um Relatório Resumido Cadastrado: O analista de testes pode alterar

um relatório resumido já cadastrado através de uma lista que será mostrada na tela, em

seguida clicando no botão “Alterar Relatório”. O sistema mostrará a tela onde as alterações

podem ser feitas, após isso o analista de testes seleciona a opção “Atualizar Dados” e o

sistema volta à tela inicial.

Formulário não validado: O sistema pode não validar o formulário de dados. O

analista de testes então deverá corrigir os erros mostrados e selecionar a opção “Salvar

Dados”. O sistema valida os campos do formulário e volta à tela inicial.

Excluir um Relatório Resumido Cadastrado: O analista de testes pode excluir

um relatório resumido já cadastrado através de uma lista que será mostrada na tela, em

seguida clicando no botão “Excluir Relatório”, será mostrado um aviso informando que essa

operação não poderá ser desfeita, oferecendo a opção de confirmar e de cancelar.

Selecionando a opção “Confirmar” o sistema exclui o relatório resumido, após isso o sistema

volta à tela inicial.

36

4.4.4 Requisitos especiais

Não possui.

4.4.5 Precondições

Manter Testes: Antes da execução deste caso de uso o sistema deverá ter

executado o caso de uso Manter Testes.

4.4.6 Pós-condições

Manter Histórico: Após a execução deste caso de uso o sistema estará apto para

executar o caso de uso Manter Histórico.

4.4.7 Pontos de Extensão

Não Possui.

4.4.8 Local View

Figura 4.8: Local View 4

37

4.4.9 Definição dos atributos

Tabela 4.4: Definição dos Atributos 4

Nome da variável Tipo Limitações Descrição Interface Obrigatório

id_teste Integer - Indica o id do teste e é a chave estrangeira da tabela,

referenciando o id_teste da tabela Teste

- Sim

id_relatorio Integer - Indica o id do relatorio e é a chave primária da tabela - Sim

contexto String 1 a 300 caracteres Quais os itens testados Campo de texto Sim

variações String 1 a 300 caracteres Variações ocorridas que não estavam previstas nos testes Campo de texto Sim

abrangência String 1 a 300 caracteres Análise da cobertura do teste, indicar possíveis deficiências

nos testes

Campo de texto Sim

sumário_resultado String 1 a 300 caracteres Resumo dos incidentes Campo de texto Sim

avaliação String 1 a 300 caracteres Avaliação global do teste Campo de texto Sim

sumario_atividades String 1 a 300 caracteres Indicar o que ocorreu para cada item Campo de texto Sim

aprovacao Boolean Sim ou Não Se o item testado foi aprovado ou não SelectOneRadio Sim

38

4.4.10 Protótipo da Interface

4.5 Especificação de Caso de Uso: <Manter Histórico>

4.5.1 Descrição

Esse caso de uso destina-se a cadastrar, manter atualizado e excluir um histórico

dos testes realizados em projetos de software.

Figura 4.9: Protótipo de Interface 4

39

4.5.2 Fluxo Básico

O analista de testes deve preencher todos os campos necessários para poder

cadastrar um Histórico, após isso o analista de testes seleciona a opção “Salvar Dados”, o

sistema então valida os campos do formulário e volta à tela inicial.

4.5.3 Fluxos Alternativos

Alterar um Histórico Cadastrado: O analista de testes pode alterar um histórico

já cadastrado através de uma lista que será mostrada na tela, em seguida clicando no botão

“Alterar Histórico”. O sistema mostrará a tela onde as alterações podem ser feitas, após isso o

analista de testes seleciona a opção “Atualizar Dados” e o sistema volta à tela inicial do caso.

Formulário não validado: O sistema pode não validar o formulário de dados. O

analista de testes então deverá corrigir os erros mostrados e selecionar a opção “Salvar

Dados”. O sistema valida os campos do formulário e volta à tela inicial.

Excluir um Histórico Cadastrado: O analista de testes pode excluir um histórico

já cadastrado através de uma lista que será mostrada na tela, em seguida clicando no botão

“Excluir Histórico”, será mostrado um aviso informando que essa operação não poderá ser

desfeita, oferecendo a opção de confirmar e de cancelar. Selecionando a opção “Confirmar” o

sistema exclui o histórico, após isso o sistema volta à tela inicial.

4.5.4 Requisitos especiais

Não possui.

4.5.5 Precondições

Antes da execução deste caso de uso o sistema deverá ter executado um dos casos

de usos descritos à seguir: Manter Testes, Manter Caso de Testes, Manter Procedimentos de

Teste ou Manter Relatório Resumido.

40

4.5.6 Pós-condições

Não Possui.

4.5.7 Pontos de Extensão

Não Possui.

4.5.8 Local View

Figura 4.10: Local View 5

41

4.5.9 Definição dos atributos

Tabela 4.5: Definição dos Atributos 5

Nome da variável Tipo Limitações Descrição Interface Obrigatório

id_historico Integer - Indica o id do histórico e é a chave primária da tabela - Sim

id_idocumento Integer - Indica qual o id do documento que irá salvar o histórico - Sim

tipo_documento String 1 a 10 caracteres Indica qual o tipo de documento que irá salvar o histórico Campo de texto Sim

data Date - Data em que foram feitas alterações Calendar Sim

versão String 1 a 5 caracteres Versão corrente do teste Campo de texto Sim

descrição String 1 a 100 caracteres Descrição do teste feito Campo de texto Sim

autor String 1 a 40 caracteres Autor do teste Campo de texto Sim

42

4.5.10 Protótipo da Interface

Figura 4.11: Protótipo de Interface 5

43

5 DIAGRAMAS

Os diagramas apresentados fazem uso de conceitos de Engenharia de Software

para a modelagem da arquitetura, das atividades, das classes e das entidades e

relacionamentos utilizados na criação da ferramenta.

5.1 Diagrama de Arquitetura

Para a arquitetura utilizamos como base o conceito de Arquitetura Web, assim

propomos a arquitetura descrita abaixo, e visualizada na figura 5.1.

Na Camada de Apresentação é feita a interface para o usuário, com acesso pelo

navegador Web.

A Camada Web é o intermediador entre as camadas de Apresentação e de

Regra de Negócios. Utiliza-se as linguagens de programação JSP, HTML, CSS e o

framework JSF Richfaces.

Figura 5.1: Arquitetura Web 1

44

A Camada de Regra de Negócios é quem contém os métodos e ações que

podem ser acessados pela camada de apresentação graças ao mapeamento XML oferecido

pelo framework JSF.

A Camada de Persistência é onde se utiliza o EJB 3.0, que cria

automaticamente as classes relacionadas a cada tabela do banco de dados (do SGBD

PostgreSQL) vinculando-as com as tabelas através do mapeamento XML.

5.2 Diagrama de Atividades

Uma atividade é o estado de estar fazendo algo: tanto um processo de mundo

real, tal como datilografar uma carta, ou a execução de uma rotina de software, tal como

um método em uma classe.

O diagrama de atividades descreve a sequência de atividades, com suporte para

comportamento condicional e paralelo. Um diagrama de atividades é uma variante de um

diagrama de estados no qual a maioria, se não todos, dos estados é estado de atividade.

A figura 5.2 (Em Anexo) apresenta o diagrama de atividades da ferramenta de

Gerência de Testes.

5.3 Diagrama de Classes

Um diagrama de classes é uma representação da estrutura e relações das classes

que servem de modelo para objetos. É uma modelagem muito útil para o sistema, define

todas as classes que o sistema necessita possuir e é a base para a construção de outros

diagramas.

A Figura 5.3 (Em Anexo) apresenta o diagrama de classes utilizado na

ferramenta desenvolvida.

5.4 Diagrama de Entidade e Relacionamento

O Diagrama de entidade relacionamento é um modelo diagramático que

descreve o modelo de dados de um sistema com alto nível de abstração. É usado para

representar o modelo conceitual do negócio.

45

A Figura 5.4 apresenta o diagrama de entidade e relacionamento utilizado na

ferramenta em desenvolvimento.

Figura 5.4: Diagrama ER 1

46

6 RELATÓRIO DE TESTES

Este é o relatório de testes executados na ferramenta proposta para verificação

de conformidade do que foi produzido com os requisitos iniciais especificados pelos casos

de usos.

6.1 Histórico da Revisão

Tabela 6.1: Histórico da Revisão 1

Data Versão Descrição Autor

30/09/2010 1.0 Teste da Ferramenta de Gerência de Testes André

05/10/2010 1.1 Teste da correção de erros encontrados na revisão anterior André

6.2 Introdução

O objetivo deste teste é verificar e validar a ferramenta de gerência de Testes

em Software, desenvolvida como parte do Estágio Curricular Obrigatório (5EST314), do

curso de Ciência da Computação no ano de 2010 da Universidade Estadual de Londrina.

Este teste é de característica funcional, ou seja, as funcionalidades da

ferramenta proposta devem estar em conformidade com os casos de uso apresentados.

6.2.1 Ambiente

O ambiente em que foram executados os testes, características da máquina

usada para teste, bem como drivers, stubs, arquivos ou bancos de dados criados para os

testes, entre outros são citados à seguir:

Notebook Intel Core 2 Duo 1,66GHz, 2Gb. de Memória RAM,

Navegador Mozilla Firefox 3.6, Windows 7 32 bits

47

A tabela 6.2 apresenta os itens que foram usados:

Tabela 6.2: Ambiente 1

Número

de ordem

Item Comentários

1 Banco de Dados PostgreSQL Foi utilizado um banco de dados para

testes, no servidor remoto de Banco de

Dados do GAIA – Fábrica de Projetos de

TIC.

6.3 Critérios de completeza

Definem-se aqui as condições que devem ser satisfeitas e o estado que deve ser

atingido, para que o conjunto de testes seja considerado bem-sucedido.

A tabela 6.3 apresenta os critérios utilizados na realização dos testes:

Tabela 6.3: Critérios de Completeza 1

Número de

ordem

Critério

1 Todos os campos de cada uma das partes da ferramenta devem ser salvos

corretamente no banco de dados.

2 Todas as alterações feitas em algum campo da ferramenta devem ser salvas

corretamente no banco de dados.

3 No caso de existirem tabelas auxiliares nas telas da ferramenta, cada item

dessa tabela auxiliar deve ser salvo corretamente e ainda estar associado

com a chave primária da tabela principal para que possa ser feito a

rastreabilidade dos itens.

4 As exclusões devem ocorrer de maneira correta e não apresentar erros.

5 Quando um item de uma tabela principal for excluído todos os itens

relacionados a ele nas tabelas auxiliares devem ser excluídos também.

6.4 Especificação dos testes

Nesta parte do documento são descritos os procedimentos e os casos de teste a

serem aplicados. Aqui são registrados, excepcionalmente, os eventos ocorridos durante a

execução dos testes, podendo ser resultados obtidos e anomalias ocorridas.

48

6.4.1 Procedimentos de teste

São definidos aqui os procedimentos associados ao conjunto de testes. As

tabelas apresentam os procedimentos por página da Ferramenta. Foi utilizada a sigla GT

(Gerência de Testes) para a identificação dos testes.

Página Teste

Tabela 6.4.1: Procedimentos de teste 1

Identificação GT_teste1

Objetivo Verificar se a inclusão de um item na página “Teste” da ferramenta é

feita corretamente.

Requisitos

Especiais

Nenhum

Fluxo

Selecionar no menu o item “Teste” que irá abrir a página para cadastrar

um teste.

Preencher todos os campos de texto com o mesmo nome de seu

respectivo outputtext (quando possível), e o mesmo se aplica aos campos

utilizados em tabelas auxiliares.

Clicar em salvar.

Verificar no banco de dados se o item foi salvo corretamente, e se os

itens da(s) tabela(s) auxiliar(es) foram salvos corretamente.

Tabela 6.4.2: Procedimentos de teste 2

Identificação GT_teste2

Objetivo Verificar se as alterações feitas num item na página “Teste” da

ferramenta são salvas corretamente.

Requisitos

Especiais

Deve existir algum item cadastrado anteriormente.

Fluxo

Selecionar no menu o item “Teste” que irá abrir a página para alterar um

teste.

Modificar todos os campos da página, bem como os campos utilizados

em tabelas auxiliares.

Clicar em atualizar.

Verificar no banco de dados se o item foi atualizado corretamente, e se os

itens da(s) tabela(s) auxiliar(es) foram atualizados corretamente.

Tabela 6.4.3: Procedimentos de teste 3

Identificação GT_teste3

Objetivo Verificar se a exclusão de um item é feita de maneira correta e não

apresenta erros.

49

Requisitos

Especiais

Deve existir algum item cadastrado anteriormente.

Fluxo

Selecionar no menu o item “Teste” que irá abrir a página para excluir um

teste.

Clicar em Sim.

Verificar no banco de dados se o item foi deletado corretamente, e se os

itens da(s) tabela(s) auxiliar(es) referentes a ele foram excluídos

corretamente.

Página Caso de Teste

Tabela 6.4.4: Procedimentos de teste 4

Identificação GT_Caso_de_teste1

Objetivo Verificar se a inclusão de um item na página “Caso de Teste” da

ferramenta é feita corretamente.

Requisitos

Especiais

Deve existir um Teste já cadastrado anteriormente.

Fluxo

Selecionar no menu o item “Caso de Teste” que irá abrir a página para

cadastrar um caso de teste.

Preencher todos os campos de texto com o mesmo nome de seu

respectivo outputtext (quando possível), e o mesmo se aplica aos campos

utilizados em tabelas auxiliares.

Clicar em salvar.

Verificar no banco de dados se o item foi salvo corretamente, e se os

itens da(s) tabela(s) auxiliar(es) foram salvos corretamente.

Tabela 6.4.5: Procedimentos de teste 5

Identificação GT_Caso_de_teste2

Objetivo Verificar se as alterações feitas num item na página “Caso de Teste” da

ferramenta são salvas corretamente.

Requisitos

Especiais

Deve existir algum item cadastrado anteriormente.

Fluxo

Selecionar no menu o item “Caso de Teste” que irá abrir a página para

alterar um caso de teste.

Modificar todos os campos da página, bem como os campos utilizados

em tabelas auxiliares.

Clicar em atualizar.

Verificar no banco de dados se o item foi atualizado corretamente, e se os

itens da(s) tabela(s) auxiliar(es) foram atualizados corretamente também.

50

Tabela 6.4.6: Procedimentos de teste 6

Identificação GT_Caso_de_teste3

Objetivo Verificar se a exclusão de um item é feita de maneira correta e não

apresenta erros.

Requisitos

Especiais

Deve existir algum item cadastrado anteriormente.

Fluxo

Selecionar no menu o item “Caso de Teste” que irá abrir a página para

excluir um caso de teste.

Clicar em Sim.

Verificar no banco de dados se o item foi deletado corretamente, e se os

itens da(s) tabela(s) auxiliar(es) referentes a ele foram excluídos

corretamente também.

Página Relatório Resumido

Tabela 6.4.7: Procedimentos de teste 7

Identificação GT_Relatorio_resumido1

Objetivo Verificar se a inclusão de um item na página “Relatório Resumido” da

ferramenta é feita corretamente.

Requisitos

Especiais

Nenhum

Fluxo

Selecionar no menu o item “Relatório Resumido” que irá abrir a página

para cadastrar um relatório.

Preencher todos os campos de texto com o mesmo nome de seu

respectivo outputtext (quando possível).

Clicar em salvar.

Verificar no banco de dados se o item foi salvo corretamente.

Tabela 6.4.8: Procedimentos de teste 8

Identificação GT_Relatorio_resumido2

Objetivo Verificar se as alterações feitas num item na página “Relatório

Resumido” da ferramenta são salvas corretamente.

Requisitos

Especiais

Deve existir algum item cadastrado anteriormente.

Fluxo

Selecionar no menu o item “Relatório Resumido” que irá abrir a página

para alterar um relatório.

Modificar todos os campos da página.

Clicar em atualizar.

Verificar no banco de dados se o item foi atualizado corretamente.

51

Tabela 6.4.9: Procedimentos de teste 9

Identificação GT_Relatorio_resumido3

Objetivo Verificar se a exclusão de um item é feita de maneira correta e não

apresenta erros.

Requisitos

Especiais

Deve existir algum item cadastrado anteriormente.

Fluxo

Selecionar no menu o item “Relatório Resumido” que irá abrir a página

para excluir um relatório.

Clicar em Sim.

Verificar no banco de dados se o item foi excluído corretamente.

Página Histórico

Tabela 6.4.10: Procedimentos de teste 10

Identificação GT_historico1

Objetivo Verificar se a inclusão de um item na página “Histórico” da ferramenta é

feita corretamente.

Requisitos

Especiais

Nenhum

Fluxo

Selecionar no menu o item “Histórico” que irá abrir a página para

cadastrar um histórico.

Selecionar todos os itens pertinentes, além de preencher os campos de

texto com o mesmo nome de seu respectivo outputtext (quando possível).

Clicar em salvar.

Verificar no banco de dados se o item foi salvo corretamente.

Tabela 6.4.11: Procedimentos de teste 11

Identificação GT_historico2

Objetivo Verificar se as alterações feitas num item na página “Histórico” da

ferramenta são salvas corretamente.

Requisitos

Especiais

Deve existir algum item cadastrado anteriormente.

Fluxo

Selecionar no menu o item “Histórico” que irá abrir a página para alterar

um histórico.

Modificar todos os campos da página.

Clicar em atualizar.

Verificar no banco de dados se o item foi atualizado corretamente.

52

Tabela 6.4.12: Procedimentos de teste 12

Identificação GT_historico3

Objetivo Verificar se a exclusão de um item é feita de maneira correta e não

apresenta erros.

Requisitos

Especiais

Deve existir algum item cadastrado anteriormente.

Fluxo

Selecionar no menu o item “Histórico” que irá abrir a página para excluir

um histórico.

Clicar em Sim.

Verificar no banco de dados se o item foi excluído corretamente.

6.5 Casos de teste e Incidentes dos Testes

Serão descritos aqui cada um dos casos de teste listados no tópico

Procedimentos de Teste.

6.5.1 Página Teste

GT_teste1

No teste foram digitados os valores de todos os campos de texto da página

(com o nome de seu respectivo outputtext), existiam dois modalPanel contendo itens que

seriam armazenados em tabelas auxiliares, esses itens foram preenchidos da mesma

maneira, depois foi observado se eles eram salvos corretamente no banco de dados nas

suas respectivas tabelas.

No processo descrito não foram encontradas falhas que fizessem com que o

sistema apresentasse erro. Todos os valores foram salvos corretamente e em suas

respectivas tabelas.

O sistema apresentou uma mensagem confirmando o sucesso da operação.

GT_teste2

No teste foram feitas alterações num item já cadastrado, as alterações foram

salvas com sucesso. O sistema também apresentou uma mensagem confirmando o sucesso

da operação.

53

GT_teste3

Nesse teste é mostrada uma mensagem para que o usuário tenha certeza da

exclusão, pois essa não pode ser desfeita. O sistema excluiu corretamente o teste e todos os

seus relacionamentos.

O sistema apresentou uma mensagem confirmando o sucesso da operação.

6.5.2 Página Caso de Teste

GT_Caso_de_teste1

No teste foi selecionado um teste para o qual se deseja relacionar o caso de

teste, foram digitados os valores de todos os campos de texto da página (com o nome de

seu respectivo outputText), existiam dois modalPanel contendo itens que seriam

armazenados em tabelas auxiliares, esses itens foram preenchidos da mesma maneira,

depois foi observado se eles eram salvos corretamente no banco de dados nas suas

respectivas tabelas.

No processo descrito não foram encontradas falhas que fizessem com que o

sistema apresentasse erro. Todos os valores foram salvos corretamente e em suas

respectivas tabelas.

O sistema apresentou uma mensagem confirmando o sucesso da operação.

GT_ Caso_de_teste2

No teste foram feitas alterações num item já cadastrado.

O sistema apresentou o seguinte erro:

Não foi possível salvar o caso de teste devido à um erro na tabela

auxiliar “Caso_procedimento”.

O sistema apresentou uma mensagem mostrando o erro ocorrido. A mensagem

é simples para que o usuário não se “assuste” com o erro gerado e para que posteriormente

possa ser feita a resolução do problema.

GT_ Caso_de_teste3

54

Nesse teste é mostrada uma mensagem para que o usuário tenha certeza da

exclusão, pois essa não pode ser desfeita. O sistema excluiu corretamente o caso de teste e

todos os seus relacionamentos.

O sistema apresentou uma mensagem confirmando o sucesso da operação.

6.5.3 Página Relatório Resumido

GT_Relatorio_resumido1

No teste foram digitados os valores de todos os campos de texto da página

(com o nome de seu respectivo outputText), não existiam modalPanel, foi selecionado o

item do SelectOneRadio, depois foi observado se os dados foram salvos corretamente no

banco de dados.

No processo descrito não foram encontradas falhas que fizessem com que o

sistema apresentasse erro. Todos os valores foram salvos corretamente. O sistema

apresentou uma mensagem confirmando o sucesso da operação.

GT_ Relatorio_resumido2

No teste foram feitas alterações num item já cadastrado, as alterações foram

salvas com sucesso. O sistema também apresentou uma mensagem confirmando o sucesso

da operação.

GT_ Relatorio_resumido3

Nesse teste é mostrada uma mensagem para que o usuário tenha certeza da

exclusão, pois essa não pode ser desfeita. O sistema excluiu corretamente o relatório.

O sistema apresentou uma mensagem confirmando o sucesso da operação.

6.5.4 Página Histórico

GT_historico1

No teste foram selecionados: qual documento seria usado no histórico, o teste

referente àquele histórico, o autor e foram digitados os valores de todos os campos de texto

da página, não existiam modalPanel na página, depois foi observado se os dados foram

salvos corretamente no banco de dados.

55

No processo descrito não foram encontradas falhas que fizessem com que o

sistema apresentasse erro. Todos os valores foram salvos corretamente. O sistema

apresentou uma mensagem confirmando o sucesso da operação.

GT_ historico2

No teste foram feitas alterações num item já cadastrado, as alterações foram

salvas com sucesso. O sistema também apresentou uma mensagem confirmando o sucesso

da operação.

GT_ historico3

Nesse teste é mostrada uma mensagem para que o usuário tenha certeza da

exclusão, pois essa não pode ser desfeita. O sistema excluiu corretamente o relatório.

O sistema apresentou uma mensagem confirmando o sucesso da operação.

6.6 Relatório resumido dos testes

A ferramenta é formada por quatro páginas que fazem parte do mesmo artefato,

assim essas partes trabalham separadamente, mas estão ligadas através das tabelas de

relacionamento do banco de dados.

As páginas/partes de Teste, Relatório Resumido e Histórico não apresentaram

nenhuma falha em todos os procedimentos realizados, assim podem ser consideradas

aprovadas.

A página/parte de Caso de Teste apresentou uma falha considerada média no

procedimento GT_Caso_de_teste2, não permitindo a atualização do item devido a um erro

em uma de suas tabelas auxiliares. Pode ser considerada aprovada, mas devem ser feitas

alterações para que a página esteja dentro dos requisitos da ferramenta.

56

7 CONSIDERAÇÕES FINAIS

O Estágio, assim como a ferramenta proposta, foi desenvolvido de maneira

coerente e visando a qualidade dos resultados obtidos. Assim, conforme o Plano de Estágio

apresentado em Março de 2010, todas as atividades propostas foram cumpridas e entregues

em suas devidas datas.

O desenvolvimento deste estágio proporcionou melhoria nos conhecimentos

tanto de linguagem de programação quanto nos artefatos de Engenharia de Software. A

experiência obtida, bem como os erros e acertos servirão de lições aprendidas para que os

próximos projetos sejam feitos buscando a melhoria da qualidade do desenvolvimento.

Ainda como parte do desenvolvimento, foi implementada uma página onde

poderão estar disponíveis as outras ferramentas que compõem o ADS, lembrando que essa

página é de caráter extra, bem como a padronização das interfaces das ferramentas

desenvolvidas.

A ferramenta de Gerência de Testes em software está hospedada no servidor do

GAIA e pode ser encontrada em http://gaia.uel.br/ADSWeb/index.faces.

57

8 BIBLIOGRAFIA

[1] PRESSMAN, Roger; Engenharia de software. 6ª Edição, Ed. McGraw-Hill,

2006.

[2] SOMMERVILLE, Ian; Engenharia de software. 6ª Edição, Ed. Pearson

Education, 2003.

[3] IEEE COMPUTER SOCIETY; IEEE Standard for Software Test

Documentation, 1998.

[4] CRESPO, Adalberto N.; SILVA, Odair J.; BORGES, Carlos A.; SALVIANO,

Clênio F.; JUNIOR, Miguel T. A.; JINO, Mario; Uma Metodologia para Teste

de Software no Contexto da Melhoria de Processo, III Simpósio Brasileiro de

Qualidade de Software, 2004.

[5] MALAIYA, Yashwant K.; LI, Michael N.; BIEMAN, James M.; KARCICH,

Rick; Software Reliability Growth With Test Coverage, IEEE Transactions

on Reliability, Vol. 51, Nº. 4, 2002.

[6] FRANZEN, Marcelo B.; BELLINI, Carlo G. P.; Arte ou Prática em Teste de

Software?, REAd – Edição 45 Vol. 11 No. 3, 2005.

[7] EICKELMANN, Nancy S.; RICHARDSON, Debra J.; An Evaluation of

Software Test Environment Architectures. 18th International Conference on

Software Engineering, 2006.

[8] KHOSHGOFTAAR, T.M; ALLEN, E. B.; HALSTEAD, R.; TRIO, G. P.;

FLASS, R. M; Using Process History to Predicty Software Quality. Computer

Journal, Vol. 31, Pg. 66-72, 1998.

[9] MyEclipse 8.0. Documentação e download disponíveis em

http://www.myeclipseide.com

[10] Enterprise JavaBeans 3.0. Documentação, download e especificações

disponíveis em http://java.sun.com/products/ejb/docs.html

[11] JBoss Application Server (JBoss AS). Documentação, download e

especificações disponíveis em http://www.jboss.org/jbossas/downloads/

[12] JDK 1.5. Documentação, download e especificações disponíveis em

http://java.sun.com/javase/downloads/index_jdk5.jsp

[13] Richfaces. Documentação, download de bibliotecas, especificações e

demonstrações disponíveis em http://www.jboss.org/richfaces

[14] PostgreSQL. Documentação, download, especificações e suporte disponíveis em

http://www.postgresql.org.br/

[15] Making the Software Factory Work: Lessons from a Decade of Experience,

http://mockus.us/papers/factory.pdf

[16] KRUCHTEN, P.: Introdução ao RUP - Rational Unified Process. Ciência

Moderna, Rio de Janeiro (2003).

58

[17] Project Management Institute: A Guide to the Project Management Body of

Knowledge – PMBOK® Guide, Pennsylvania, USA (2008).

[18] Associação para Promoção da Excelência do Software Brasileiro: MPS.BR –

Guia Geral. Brasília (2009).