Post on 11-Nov-2018
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.
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
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).