Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett

UNIVERSIDADE DO SUL DE SANTA CATARINA
ANDERSON ANTONIO DO NASCIMENTO DA SILVA
MARIANA BENEDETT SEVERINO

IMPLANTAÇÃO E MELHORIA NA QUALIDADE DE APLICAÇÕES ATRAVÉS DE
UM SISTEMA DE GESTÃO DE TESTES.

Tubarão
2010



Trabalho de Conclusão de Curso apresentado ao Curso
de Graduação em Sistemas de Informação da
Universidade do Sul de Santa Catarina, como requisito
parcial à obtenção do título de Bacharel em Sistemas de
Informação.

Orientador: Prof. Edjandir Corrêa Costa.

Tubarão
2010



Este Trabalho de Conclusão de Curso foi julgado
adequado à obtenção do título de Bacharel em Sistemas
de Informação e aprovado em sua forma final pelo
Curso de Graduação em Sistemas de Informação da
Universidade do Sul de Santa Catarina.

Tubarão, 14 de junho de 2010.

______________________________________________________
Prof. Rafael Avila Faraco.
Universidade do Sul de Santa Catarina

______________________________________________________
Prof. Eder Cachoeira.

______________________________________________________
Prof. Alessandro Zanini.

Dedico este trabalho aos meus pais (José e
Ana) por sempre terem me apoiado e
incentivado não somente para a conclusão
deste projeto, mas como em toda minha vida.
(Anderson)

Dedico este trabalho aos meus pais e toda a
minha família pelo apoio, auxílio e educação,
que me fez chegar até aqui. (Mariana)

AGRADECIMENTOS

Em primeiro lugar a Deus por nos ter dado forças para percorrer esse longo e
dificultoso trajeto, muito importante em nossas vidas profissionais.
A nossos pais devemos gratidão eterna por nos guiarem no caminho certo, pelo
apoio e incentivo que nos ajudou a seguir em frente.
Aos nossos irmãos, familiares e amigos que nos auxiliaram nesse período.
Aos professores e colegas que compartilharam conosco seus conhecimentos e
experiências.
Ao nosso orientador Edjandir Corrêa Costa, que nos ajudou em momentos de
dúvidas, fornecendo ideias que somaram no projeto.

"Não temos em nossas mãos a solução para todos os problemas do mundo; mas,
diante dos problemas do mundo, temos nossas mãos.”(AUTOR DESCONHECIDO).

RESUMO

O propósito deste trabalho é fornecer uma ferramenta contendo um método simplificado que
possa auxiliar na implantação de um processo de Testes de software. A ferramenta dará ao
gerente segurança e capacidade de medir a qualidade do seu produto. Neste trabalho,
especificamente, a ferramenta elaborada pelos acadêmicos será um auxiliar no processo de
Testes de software. A referida ferramenta foi desenvolvida a partir de estudos bibliográficos e
eletrônicos, que serviram de base para a sua construção. A ferramenta em questão atua sob os
níveis G e F do modelo de maturidade de software MPS.BR. A qualidade do software se torna
hoje uma área de extrema importância para as organizações consumidoras que pretendem
garantir o seu espaço no mercado de desenvolvimento de software. Por conta disso, estas
organizações vêm procurando métodos e processos que possam avaliar a qualidade do seu
produto final. A área de Testes se mostra peça chave para a validação e a garantia de que o
produto está apto a ser entregue ao cliente da forma como foi solicitado. Observa-se hoje a
imaturidade que as empresas têm na área Testes. Grande parte delas realiza seus Testes
juntamente com o desenvolvimento de software e, até mesmo, utilizando o usuário final do
sistema, o que não é recomendado pelos conceituados processos de qualidade de software.
Nesse sentido, os autores dessa monografia acreditam na importância dessa ferramenta para o
desenvolvimento de softwares com qualidade.

Palavras-chave: Qualidade de software. Testes de software. Processo de Teste.

ABSTRACT

The purpose of this paper is to provide a tool containing a simplified method that can
assist in the implementation of a process of Testing Software. The tool will give the manager
security and ability to measure the quality of your product. In this work, specifically, the tool
developed by academiwill be a help in the process of Testing Software. This tool was
developed from studies of bibliographic and electronic, which formed the basis for its
construction. The tool in question operates under the G and F levels of maturity model for
software MPS.BR. The quality of the software now becomes an area of extreme importance
for organizations to consumers wanting to ensure their place in the market for software
development. Because of this, these organizations have been searching for methods and
processes that can assess the quality of your final product. The area of Testing proves is a key
piece for the validation and assurance that the product is suitable to be delivered to the
customer as it was requested. It is observed today immaturity that companies have in the field
Tests. Many of them realize their tests along with the development of software and even using
the end user of the system, which is not recommended by reputable software quality
processes. In this sense, the authors of this monograph believe in the importance of this tool
for the development of software quality.

Key words: software quality. Testing softwares. Testing process.

LISTA DE ILUSTRAÇÕES

Figura 1 - Pessoas envolvidas dentro da qualidade .................................................................. 23
Esquema 1 - Sincronismo entre desenvolvimento e Gerenciamento de Qualidade. ................ 24
Quadro 1 - Gerenciamento da Qualidade do Projeto segundo o PMI. ..................................... 25
Quadro 2 - Padrões de produto e de processo .......................................................................... 26
Fluxograma 1 - Fluxo do gerenciamento da qualidade do processo ........................................ 27
Figura 2 - Atributos de Qualidade do software ........................................................................ 28
Esquema 2 - Padrões de intercâmbio de documentos .............................................................. 29
Esquema 3 - Análise de Riscos ................................................................................................ 33
Gráfico 1 - Resultados da avaliação em abrangência - ameaças .............................................. 34
Figura 3 - Localização da qualidade dentro da engenharia. ..................................................... 37
Gráfico 2 - Custo de correções ................................................................................................. 38
Figura 4 - Defeito x Erro x Falha ............................................................................................. 39
Figura 5 - Diferentes interpretações ao longo do ciclo de desenvolvimento de um software. . 42
Quadro 3 - Exemplo de um Caso de Teste simples. ................................................................. 46
Figura 6 - Componentes existentes em Testes caixa preta. ...................................................... 47
Esquema 4 - Representação dos módulos de Teste .................................................................. 50
Esquema 5 - Testes de integração. ........................................................................................... 51
Figura 7 - Componentes existentes em Testes caixa branca. ................................................... 57
Figura 8 - Níveis de refinamento. ............................................................................................. 58
Figura 9 - Laços existentes nos Testes de ciclo. ....................................................................... 60
Esquema 6 - Componentes do modelo MPS. ........................................................................... 63
Diagrama 1 - Visão geral do Processo de Teste. ...................................................................... 73
Diagrama 2 - Visão detalhada do processo de inicialização .................................................... 74
Quadro 4 - Caso de Teste ......................................................................................................... 76
Quadro 5 - Plano de Teste ........................................................................................................ 77
Diagrama 3 - Visão detalhada do processo de Execução. ........................................................ 78
Diagrama 4 - Visão detalhada do processo de Finalização. ..................................................... 80
Figura 10 - Arquitetura de aplicações em padrão de projeto MVC.......................................... 83
Esquema 7 - Arquitetura da aplicação. ..................................................................................... 84
Diagrama 5 - Diagrama de Casos de Uso. ................................................................................ 85

Quadro 6 - Manter Plano de Teste. ........................................................................................... 86
Quadro 9 - Manter Caso de Teste ............................................................................................. 87
Quadro 10 - Executar Plano de Teste ....................................................................................... 88
Quadro 11 - Gerenciar processo. .............................................................................................. 88
Quadro 12 - Manter Usuário e Grupo. ...................................................................................... 89
Diagrama 6 - Diagrama de domínio de Classe. ........................................................................ 90
Quadro 13 - Descrição das classes ........................................................................................... 90
Diagrama 7 - Diagrama geral de pacotes.................................................................................. 92
Diagrama 8 - Diagrama de pacotes entitys. .............................................................................. 93
Diagrama 9 - Diagrama de pacotes repository. ........................................................................ 94
Diagrama 10 - Diagrama de pacotes service. ........................................................................... 95
Diagrama 11 - Diagrama de pacotes DAO. .............................................................................. 96
Diagrama 12 - Pacotes manager. .............................................................................................. 96
Diagrama 13 - Pacotes servlet. ................................................................................................. 97
Diagrama 14 - Diagrama de pacotes infrastructure. ................................................................ 97
Diagrama 15 - Diagrama de pacotes view. ............................................................................... 98
Diagrama 16 - Modelo de ER- Relacionamento entre tabelas. ................................................ 99
Figura 11 - Tela de login ........................................................................................................ 105
Figura 12 - Menu do usuário gerente de teste ........................................................................ 106
Figura 13 - Menu do usuário analista de teste ........................................................................ 106
Figura 14 - Menu do usuário Tester ....................................................................................... 107
Figura 15 - Lista de usuários .................................................................................................. 107
Figura 16 - Cadastro de usuário.............................................................................................. 108
Figura 17 - Lista de grupo de usuários ................................................................................... 108
Figura 18 - Cadastro de grupo de usuário............................................................................... 109
Figura 19 - Lista tipo de teste ................................................................................................. 110
Figura 20 - Cadastro de tipo de teste ...................................................................................... 110
Figura 21 - Lista de prioridade ............................................................................................... 111
Figura 22 - Cadastro de prioridade ......................................................................................... 111
Figura 23 - Lista de plano de teste .......................................................................................... 112
Figura 24 - Cadastro de plano de teste ................................................................................... 113
Figura 25 - Lista de caso de teste ........................................................................................... 114

Figura 26 - Cadastro de caso de teste ..................................................................................... 115
Figura 27 - Lista de ciclos de execução do plano de teste ...................................................... 115
Figura 28 - Execução do plano de teste .................................................................................. 116
Figura 29 - Notas da execução do plano de teste ................................................................... 117
Figura 30 - Filtros do relatório de log de Teste ...................................................................... 117
Figura 31 - Visualização do relatório de log de Teste ............................................................ 118
Figura 32 - Filtros do relatório de Incidentes ......................................................................... 118
Figura 33 - Visualização do relatório de incidentes ............................................................... 118
Figura 34 - Filtros do relatório de sumário ............................................................................. 119
Figura 35 – Visualização do relatório de sumário .................................................................. 119

LISTA DE TABELAS

Tabela 1 - Resultados da avaliação em abrangência por área de processo. .............................. 34
Tabela 2 - Refinamento utilizando Valores-Limites. ............................................................... 54
Tabela 3 - Exemplo de uma tabela de decisão.......................................................................... 55
Tabela 4 - Tabela dos representando níveis do MPS.BR. ........................................................ 64
Tabela 5 - Dicionário de dados entidade usuário. .................................................................. 100
Tabela 6 - Dicionário de dados entidade prioridade. .............................................................. 100
Tabela 7 - Dicionário de dados entidade tipos de Teste. ........................................................ 101
Tabela 8 - Dicionário de dados entidade grupo. ..................................................................... 101
Tabela 9 - Dicionário de dados entidade de ligação entre grupo e usuário. ........................... 101
Tabela 10 - Dicionário de dados entidade plano de Teste ...................................................... 102
Tabela 11 - Dicionário de dados entidade caso de Teste ........................................................ 103
Tabela 12 - Dicionário de dados entidade ciclo de Teste ....................................................... 104
Tabela 13 - Dicionário de dados entidade ciclo de Teste notas.............................................. 104

LISTA DE SIGLAS

BID - Banco Interamericano de Desenvolvimento.
CMMI - Capability Maturity Model Integration
ETM - Equipe Técnica do Modelo.
FCC - Fórum de Credenciamento e Controle.
FINEP - Financiadora de Estudos e Projetos.
IA - Instituições Avaliadoras.
IEE - Institute of Electrical and Electronics Engineers
II - Instituições Implementadoras.
MA-MPS - Modelo de Avaliação - Melhoria de Processo de Software.
MCT - Ministério da Ciência e Tecnologia.
MN-MPS - Modelo de Negocio - Melhoria de Processo de Software.
MPS.BR - Melhoria de Processo de Software Brasileiro.
MR-MPS - Modelo de Referencia - Melhoria de Processo de Software.
MVC – Model View Controler – Padrao de projeto
NIST - National Institute of Standards and Technology
RIA – Rich Internet Application
SOFTEX - Associação para Promoção da Excelência do Software Brasileiro.

SUMÁRIO

1 INTRODUÇÃO................................................................................................................. 16
1.1 OBJETIVOS .................................................................................................................... 17
1.1.2 Objetivo Geral ............................................................................................................. 17
1.1.3 Objetivos Específicos................................................................................................... 18
1.2 RESULTADOS ESPERADOS ........................................................................................ 18
1.3 JUSTIFICATIVA ............................................................................................................ 18
1.4 METODOLOGIA ............................................................................................................ 19
1.5 APRESENTAÇÃO DO DOCUMENTO ......................................................................... 20
2 QUALIDADE DE SOFTWARE....................................................................................... 22
2.1 GERENCIAMENTO DE QUALIDADE ........................................................................ 23
2.1.1 Padrões de Qualidade ................................................................................................. 25
2.1.2 Qualidade do Processo e do Produto. ........................................................................ 26
2.1.3 O planejamento de Qualidade.................................................................................... 27
2.1.4 Padrões de documentação .......................................................................................... 29
2.1.5 Medição e Métricas ..................................................................................................... 30
2.2 SOFTWARE QUALITY ASSURANCE .......................................................................... 31
2.3 ANÁLISE DE RISCOS ................................................................................................... 31
2.4 CONSIDERAÇÕES FINAIS ........................................................................................... 35
3 TESTES ............................................................................................................................. 36
3.1 VISÃO DE TESTES DE SOFTWARE ............................................................................ 36
3.1.1 Conceitos de Testes...................................................................................................... 38
3.1.2 Defeitos do desenvolvimento ...................................................................................... 41
3.1.3 Gerenciamento de Testes ............................................................................................ 43
3.2 REQUISITOS E CASOS DE TESTES ........................................................................... 43
3.2.1 Definindo os requisitos ................................................................................................ 44
3.2.2 Definindo casos de testes ............................................................................................. 44
3.3 TIPOS DE TESTES ......................................................................................................... 46
3.3.1 Teste Funcional............................................................................................................ 47
3.3.2 Testes de Unidade ........................................................................................................ 48
3.3.3 Testes de Sistema ......................................................................................................... 48

3.3.4 Testes de Aceitação...................................................................................................... 49
3.3.5 Testes de Integração .................................................................................................... 49
3.3.5.1 Não Incremental ......................................................................................................... 49
3.3.5.2 Incremental ................................................................................................................. 50
3.3.5.3 Integração Top-down.................................................................................................. 51
3.3.5.4 Integração Bottom-up ................................................................................................. 52
3.3.6 Teste de Regressão ...................................................................................................... 52
3.3.7 Teste de Estresse .......................................................................................................... 53
3.3.8 Análise do Valor Limite ou Fronteira ....................................................................... 54
3.3.9 Tabela de decisão......................................................................................................... 55
3.3.10 Testes de Semântica .................................................................................................... 56
3.3.11 Testes Estruturais ........................................................................................................ 56
3.3.11.1 Técnicas de Testes Estruturais.................................................................................... 57
3.3.11.1.1 Cobertura de Linha de Código ................................................................................ 58
3.3.11.1.2 Cobertura de Caminhos ........................................................................................... 58
3.3.11.1.3 Cobertura de Decisões ............................................................................................ 59
3.3.11.1.4 Cobertura de Condições .......................................................................................... 59
3.3.11.1.5 Testes de Ciclos ....................................................................................................... 59
4 METODOLOGIA UTILIZADA: MPS.BR .................................................................... 62
4.1 NIVEL G – PARCIALMENTE GERENCIADO ............................................................ 64
4.1.1 Gerência de Projetos (GPR) ....................................................................................... 65
4.1.2 Gerência de Requisitos (GRE) ................................................................................... 65
4.2 NÍVEL F – GERENCIADO ............................................................................................ 66
4.2.1 Aquisição (AQU) ......................................................................................................... 66
4.2.2 Gerência de Configuração (GCO) ............................................................................. 67
4.2.3 Garantia de Qualidade (GQA) ................................................................................... 68
4.2.4 Medição (MED) ........................................................................................................... 69
5 DEFINIÇÃO E ELABORAÇÃO DO PROCESSO DE TESTE .................................. 71
5.1 PROCESSO ..................................................................................................................... 71
5.2 FASES.............................................................................................................................. 71
5.2.1 Papéis do Processo ....................................................................................................... 72
5.2.2 Inicialização ................................................................................................................. 74

5.2.3 Execução ....................................................................................................................... 78
5.2.4 Finalização ................................................................................................................... 80
6 DESENVOLVIMENTO DO SISTEMA DE TESTES .................................................. 81
6.1 VISÃO GERAL ............................................................................................................... 82
6.1.1 Arquitetura .................................................................................................................. 82
6.2 MODELO CONCEITUAL .............................................................................................. 84
6.2.1 Diagrama de Caso de Uso ........................................................................................... 84
6.2.2 Descrição dos Casos de Uso ........................................................................................ 85
6.2.2.1 Manter Tipos de Teste ................................................................................................ 86
6.2.2.2 Manter Prioridade ....................................................................................................... 86
6.2.2.3 Manter Plano de Teste ................................................................................................ 87
6.2.2.4 Manter Caso de Teste ................................................................................................. 87
6.2.2.5 Executar Plano de Teste ............................................................................................. 88
6.2.2.6 Gerenciar Processos.................................................................................................... 88
6.2.2.7 Manter usuário e grupo ............................................................................................... 89
6.2.3 Modelo de Domínio de Classe .................................................................................... 90
6.3 PROJETO FÍSICO ........................................................................................................... 91
6.3.1 Diagrama de pacotes ................................................................................................... 91
6.3.2 Modelo E.R. ................................................................................................................. 99
6.3.3 Dicionário de Dados .................................................................................................. 100
7 VALIDAÇÃO DA FERRAMENTA ............................................................................. 105
8 CONCLUSÃO ................................................................................................................. 120
REFERÊNCIAS ................................................................................................................... 122

16

1 INTRODUÇÃO

Com a evolução tecnológica de hoje e a velocidade da comunicação imposta pela
modernização, o fator Qualidade está mais elevado na pirâmide estratégica, tornando-se
fundamental para assegurar a estabilidade de uma empresa. À medida que o acesso ao
conhecimento se torna mais ágil, há também uma preocupação maior com a qualidade de um
produto/serviço oferecido. Comprometimento este que faz com que as empresas busquem por
planos agregando maior qualidade possível em seus projetos, com objetivo de satisfazer as
expectativas do cliente.
Tratando de qualidade de software, pode-se dizer que está ligada diretamente ao
desenvolvimento. Sendo assim, o foco de qualidade de uma aplicação está necessariamente
vinculado à melhoria no processo de desenvolvimento do produto abrangendo conformidade
com padrões, definição de práticas consistentes, garantia de expectativas, Testes, revisões
técnicas, entre outros.
Um dos papéis extremamente importantes desempenhados durante o processo de
desenvolvimento ligado à qualidade do software é o processo de Testes de software. Ele
executa uma análise e verificação, assegurando que o software cumpra com o que foi
especificado durante o período de análise e atenda a necessidade do cliente.
Kruchten, em seu livro The rational unified process, mencionado em Bastos e
outros (2007), propõe que existem pelo menos três dimensões de qualidade que precisam ser
consideradas antes de se iniciar qualquer ciclo de Testes:
 Confiança: o sistema é resistente a falhas durante a execução, isto é, não entra em
loop, não interrompe a execução por falta de recursos, etc.
 Funcionalidade: o sistema se comporta conforme o esperado e definido em seus
requisitos.
 Performance: o sistema tem um tempo de resposta adequado e aceitável, mesmo
quando submetido a um volume de processamento próximo de situações reais ou de
pico.
Entre as décadas de 1970 a 1990, os Testes eram executados pelos próprios
desenvolvedores, com um nível de cobertura bastante reduzido. Muitas vezes, os usuários
finais eram envolvidos nestes Testes. Isto gerava uma grande incidência de erros, que eram
corrigidos no momento em que o sistema já estava em produção, ou seja, no momento em que
esta correção se tornaria mais cara.

17

Os problemas se tornaram maiores a partir do momento em que surgiram as
aplicações para internet e sistemas mais complexos, devido a novas tecnologias. Estes fatores
fizeram com que as organizações começassem a busca pela melhoria na qualidade do software
desenvolvido por seus técnicos. Um dos caminhos seria um processo paralelo para
aprimoramento da atividade de Teste. (BASTOS et al., 2007).
Foi utilizado nesta monografia o conceito de Testes de Molinari (2008), que trata
da gerência, planejamento, controle e execução dos Testes em todos os níveis, de modo a
garantir a implementação (projeto, desenvolvimento e entrega).
Neste trabalho será desenvolvido uma ferramenta auxiliar no processo de Testes.
Aplicada a ela, um modelo de Testes aderente até o segundo nível da metodologia MPS.BR
(Melhoria de processo de Software Brasileiro).

1.1 OBJETIVOS

Serão apresentados neste momento os objetivos referentes ao trabalho
desenvolvido.

1.1.2 Objetivo Geral

Desenvolver, a partir de um estudo sobre processo de Testes, e após uma pesquisa
sobre as ferramentas de Testes já utilizadas, um software para apoio à gestão de Testes,
implementando um processo aderente ao modelo MPS.BR até o nível F.

18

1.1.3 Objetivos Específicos

 Realizar um estudo em Testes de Software e na metodologia a ser utilizada,
verificando sua viabilidade;
 Definir um processo de Testes de software que descreva as atividades a serem
executadas utilizando os conceitos de Testes de software e MPS.BR;
 Realizar a análise e desenvolvimento do sistema a ser criado baseado no processo de
Testes já definido;
 Realizar uma validação da ferramenta desenvolvida.

1.2 RESULTADOS ESPERADOS

Partindo-se das hipóteses de que as ferramentas existentes são poucas, ou seja,
insuficientes para atender à necessidade de gerenciamento do processo de Testes; e de que
elas não oferecem um processo simplificado capaz de auxiliar na implantação do processo de
Testes de software, os acadêmicos envolvidos nesta pesquisa optaram por desenvolver uma
nova ferramenta.
Espera-se que a solução consista em um método simplificado para implantação de
um processo de Testes, atendendo às áreas de Planejamento de Testes, Execução dos Testes e
Análise do Produto testado, assim como as demais figuras envolvidas no processo de Testes.
Por fim, a ferramenta permitirá o acompanhamento do processo por meio de
relatórios que devem auxiliar na tomada de decisão.

1.3 JUSTIFICATIVA

Testar um software hoje vai além de um modismo ou uma “simples prática”.
Afinal, não há outra forma de garantir a funcionalidade de um software sem antes testá-la.

19

Observa-se hoje que, para garantir a qualidade de um sistema, é necessário lidar com vários
fatores que convivem em um ambiente, tais como: client-serves, mainframe e agora a Web.
(MOLINARI, 2008).
Existem hoje, no mercado de trabalho, inúmeros profissionais com experiência em
uma determinada área, executando Testes funcionais em uma rotina que domina, e com isso,
passa a executá-la sempre. Estes são chamados os Testes viciados. É essa a realidade de
muitos analistas de softwares, mas que tende a mudar em breve à medida que se depara com
aplicativos cada vez maiores, em diversos ambientes e de alta complexibilidade.
Um dos principais objetivos na área de Testes é reduzir erros e agregar qualidade
ao software. Para isso, é necessário um processo de Testes que se adapte da melhor forma ao
processo de desenvolvimento e que, além da organização, possa enquadrar os diversos tipos
de Testes cabíveis a cada tipo de aplicação. Cabe aqui um software que englobe estes
requisitos e que possa auxiliar de forma precisa uma empresa que planeja melhorar a
qualidade do seu software, proporcionando um ganho real em seus produtos.
Baseando-se nas ideias acima mencionadas, acredita-se na importância da criação
dessa ferramenta para auxiliar o gerenciamento de Testes em nível empresarial.

1.4 METODOLOGIA

A monografia será desenvolvida basicamente em quatro etapas. Na primeira,
haverá uma reunião da equipe para estruturar a idéia inicial e garantir a sua viabilidade. Após
obter a aprovação da proposta entregue ao professor da disciplina Projetos I, é iniciada a
segunda etapa, que consiste em montar a primeira parte, o Pré-Projeto. Este acontecerá na
seguinte ordem:
a) Pesquisa sobre as metodologias de maturidade de software e gerenciamento de
projetos, conceitos e processos que envolvem o Teste de software;
b) Estudo sobre ferramentas existentes relacionadas à gestão de Testes; Testes
automatizados e planejamento;
c) Estudo sobre as tecnologias que poderão ser aplicadas no desenvolvimento do
software final;
d) Início o pré-projeto que deverá conter os tópicos Introdução e Revisão bibliográfica;

20

e) Entrega da parte inicial do pré-projeto para avaliação.
Na terceira etapa ocorrerão os ajustes:
a) Ajustar o documento conforme erros/sugestões apontadas pelos avaliadores;
b) Iniciar a modelagem nível conceitual do projeto, esta que representa a segunda parte
do Pré-Projeto;
c) Finalizar a modelagem nível conceitual do projeto;
d) Entregar para avaliação o pré-projeto finalizado;
Na quarta e última etapa, após a avaliação e aprovação do Projeto de Conclusão
de Curso I, dar-se-á início à construção da ferramenta.
a) Definição das tecnologias que serão aplicadas no desenvolvimento da ferramenta;
b) Construção do banco de dados, baseado no modelo relacional existente no projeto
conceitual;
c) Construção da aplicação;
d) Validação da ferramenta.

1.5 APRESENTAÇÃO DO DOCUMENTO

Este documento foi dividido e organizado em capítulos para que o leitor possa
compreender melhor o assunto que será abordado.
O capítulo em questão apresenta o problema, o objetivo do trabalho, sua
abrangência e o motivo da sua realização. No capítulo capitulo seguinte, será abordado o
conceito Qualidade de Software, abrangendo sua definição e importância dentro do processo
de desenvolvimento de software. O terceiro capítulo enfatiza os Testes, etapa que compõe o
item “qualidade de software” sendo uma das áreas mais importantes para garantia da
qualidade de um produto. Aborda ainda tipos de Testes, explicando a importância dos casos
de Testes no momento em que é realizado um Teste.
O capítulo quatro apresenta a metodologia utilizada como embasamento teórico
para a definição do processo e a definição do processo em si. Serão citadas as etapas do
processo de gestão de Testes definido, apontando as atividades e papéis que compõem cada
etapa.

21

O quinto capítulo aborda o processo criado, demonstrando todas as etapas
contidas, tais como Inicialização, Execução e Finalização. Cada etapa contém todas as
atividades a serem executadas.
O sexto capítulo apresenta o sistema construído conforme o processo
anteriormente criado e mencionado no capítulo anterior, sua arquitetura e modelagem. Após
isso, será demonstrada a validação do sistema, exemplificando cada etapa do sistema por meio
de suas telas.
Conforme orientação recebida, este trabalho apresentará breves considerações
finais para cada capitulo, pelo fato de cada um deles apresentar uma finalidade diferente.
Por fim, serão apresentadas as considerações finais relativas ao trabalho em sua
totalidade, capítulo no qual serão expostas ideias confirmando (ou não) as hipóteses e
objetivos levantados, bem como as prováveis contribuições deste trabalho na área de
desenvolvimento de software.

22

2 QUALIDADE DE SOFTWARE

De acordo com a NBR ISO 9000:2000 (2000), qualidade é o grau no qual um
conjunto de características inerentes satisfaz os requisitos mencionados. Ou seja, pode-se
dizer que, quando um produto e/ou serviço cumpre com os requisitos levantados atendendo a
necessidade para o qual foi projetado, este produto e/ou serviço possui qualidade.
Rocha acrescenta outras considerações sobre o conceito Qualidade:
No processo de desenvolvimento de software a comunicação da informação passa
por diversas fases e pessoas, e ela pode sofrer transformações o que propicia que
ocorram enganos, interpretações errôneas e outras faltas, que podem desencadear
falhas. Com isso é possível afirmar que ao longo de todo o processo de
desenvolvimento de software, defeitos podem ser inseridos, então se torna
necessário rastreá-los o quanto antes. (ROCHA, 2001, p. 66).

A qualidade de software pode ser definida ainda como a “Conformidade a
requisitos funcionais e de desempenho explicitamente declarados, a padrões de
desenvolvimento claramente documentados e a características implícitas que são esperadas de
todo software profissionalmente desenvolvido.” (PRESSMAN, 1995, p. 724).
Na opinião de Sommerville (2003), atingir um nível de qualidade é o objetivo da
maioria das organizações. Não é aceitável entregar produtos de baixa qualidade e que tenham
que ser reparados após a entrega ao cliente. Assim como qualquer outro produto
manufaturado como um Carro, eletrônicos, eletrodomésticos e computadores, o software é um
produto pelo qual o cliente exige um bom funcionamento. Entretanto, tratar de qualidade de
software não é uma tarefa simples, pois envolve uma série de conceitos complexos e questões
que devem ser avaliadas. Durante o desenvolvimento de um software, é comum encontrar
obstáculos que possam impedir que o software seja entregue conforme sua especificação.
A especificação deve ser orientada em direção às características do produto que o
cliente deseja. Contudo, a organização de desenvolvimento pede também requisitos (como os
requisitos de facilidade de manutenção) que não estão incluídos na especificação.
Não se sabe como especificar certas características de qualidade (por exemplo, a
facilidade de manutenção) de uma maneira que não seja ambígua.
“[...] é muito difícil escrever uma especificação completa de software. Portanto,
embora um produto de software possa atender à sua especificação, os usuários
podem não considerá-lo como um produto de alta qualidade.” Sommerville (2007, p.
458).

23

Com base nas dificuldades, o responsável pela gerência de qualidade do software
e os gerentes de cada área do desenvolvimento trabalham de forma a encontrar melhores
métodos para aplicar às especificações, buscando atender a todos.

Figura 1 - Pessoas envolvidas dentro da qualidade
Fonte: Falbo, 2008.

O Gerente de Qualidade exerce seu papel apoiando todos os envolvidos no projeto
e encorajando-os em sua atividade.

2.1 GERENCIAMENTO DE QUALIDADE

Como foi dito anteriormente, é de responsabilidade dos gerentes a garantia do
nível de qualidade do seu produto. Eles visam criar uma Cultura de Qualidade, aplicando
uma série de padrões e procedimentos que deverão ser utilizados durante a execução de um
projeto. Conforme Sommerville (2003), o gerenciamento de qualidade parte de três atividades
principais:
a) Garantia de Qualidade: O estabelecimento de uma estrutura de procedimentos e padrões
organizacionais.
a) Planejamento de qualidade: A seleção de procedimentos e de padrões organizacionais.

24

b) Controle de qualidade: A definição e a aprovação de processos que assegurem que os
procedimentos e os padrões de qualidade de projetos sejam seguidos pela equipe de
desenvolvimento de software.
O autor acima mencionado ainda afirma que o gerenciamento de qualidade
fornece uma verificação independente sobre o processo. Os projetos finalizados ou produtos
já entregues são posteriormente avaliados por uma equipe de qualidade que deve ser
independente do gerenciamento do projeto, pois desta forma se terá uma visão objetiva do
processo, podendo reportar problemas e dificuldades com mais facilidade à gerência sênior. A
ilustração abaixo apresenta a relação explicitada.

Esquema 2 - Sincronismo entre desenvolvimento e Gerenciamento de Qualidade.
Fonte: Sommerville, 2003.

O gerenciamento de qualidade inclui todas as atividades da organização executora
que determinam as responsabilidades, os objetivos e as políticas de qualidade, de modo que o
projeto atenda às necessidades que motivaram sua realização. É implementado o sistema de
gerenciamento da qualidade através da política, dos procedimentos e dos processos de
planejamento da qualidade, garantia da qualidade e controle da mesma, com atividades
de melhoria contínua dos processos, conduzidas do início ao fim, conforme adequado. (PMI,
2004, p.179). Os itens que compõem o gerenciamento de qualidade estão representados no
quadro abaixo.

25

Quadro 1 - Gerenciamento da Qualidade do Projeto segundo o PMI.
Fonte: PMI, 2004.

2.1.1 Padrões de Qualidade

As atividades e procedimentos que são definidos no gerenciamento da garantia de
qualidade exigem uma estrutura de padrões que devem ser aplicados durante todo o processo
de desenvolvimento. Os dois padrões principais que podem ser definidos são: Padrões de
Produto e Padrões de Processo. O primeiro trata de padrões que se aplicam ao produto,
incluindo estrutura de documento de requisitos, padrões de documentação (como cabeçalho,
itens, nomenclaturas), padrões de codificação, entre outros. Já o segundo define o fluxo do
processo a ser seguido durante o desenvolvimento e validação, incluindo definições de
especificação e uma série de documentos que devem ser gerados durante o fluxo.
(SOMMERVILLE, 2003). O quadro abaixo ilustra esta situação.

26

Quadro 2 - Padrões de produto e de processo

A definição de padrões deve ser analisada para que não ocorram problemas
relacionados a padrões não apropriados. É importante decidir quais os padrões que devem ser
utilizados sem alterações e quais podem ser alterados. (SOMMERVILLE, 2003).

2.1.2 Qualidade do Processo e do Produto.

O propósito da Garantia da Qualidade do Processo e Produto é munir a equipe e a
gerência com uma visão clara sobre os processos e seus produtos de trabalho associados.
(CMMI – DEV , 2003 apud JUNQUEIRA, 2009).
Existe aqui uma nítida ligação entre os dois itens. A qualidade do software é
largamente determinada pela qualidade do processo utilizado, que tem por finalidade a criação
de um produto. Um é diretamente afetado pelo outro. Então, quando um produto final não é
concluído com qualidade, certamente há um fator causador dentro do processo responsável
pelo insucesso no produto final. Nessa situação, é necessária a medição dos atributos de
software, tais como facilidade de manutenção, desempenho da aplicação, funcionalidade,
fatores internos e externos ao processo para que seja realizada a sua melhoria. Para isso, é
importante que sejam realizadas atividades como as revisões e monitoramento no processo.
(SOMMERVILLE, 2003). A seguir, apresenta-se um fluxograma ilustrativo.

27

Fluxograma 1 - Fluxo do gerenciamento da qualidade do processo

2.1.3 O planejamento de Qualidade

Planejamento de Qualidade: “Identificação dos padrões de qualidade relevantes
para o projeto e determinação de como satisfazê-los.” (PMI, 2004, p.179).
Para obter um processo e produto de qualidade, é necessário que se tenha um
planejamento dos objetivos claramente descritos e de fácil compreensão a toda equipe
envolvida no projeto. Ele serve também para avaliar o nível de qualidade que tem o produto.
O planejamento de qualidade inclui um conjunto de ações que fazem com que os
requisitos sejam cumpridos. Esta tarefa não é simples. Segundo o National Institute of
Standards and Technology (NIST), aludido por Sommerville (2003), 80% dos custos de
desenvolvimento de aplicativos se destinam à identificação e à correção de erro. Desta forma,
um projeto realizado com alto padrão de qualidade gera credibilidade com o cliente, bem
como exige menos retrabalho e recursos adicionais.
A elaboração de um Plano de Qualidade é uma atividade gerencial apoiada pela
administração fiel a um conjunto de atividades que compõem o projeto. Ela estabelece
métricas visando custos, prazos e funcionalidades do projeto e a satisfação do cliente com o
produto.
Humprey, referenciado por Sommerville (2003), em seu livro sobre
gerenciamento de software, sugere uma estrutura geral para um plano de qualidade, que
inclui:

28

1. Introdução sobre o Produto: Uma descrição sobre o produto, seu mercado pretendido e as
respectivas expectativas quanto à qualidade.
2. Planos para o produto: As datas importantes para a liberação e as respectivas
responsabilidades referentes ao produto, juntamente com os planos para a distribuição e a
prestação de serviços relacionados a ele.
3. Descrição de processo: Os processos de desenvolvimento e de serviço que devem ser
utilizados para o desenvolvimento e gerenciamento do produto.
4. Metas de qualidade: As metas e os planos de qualidade para o produto, incluindo
identificação e justificativa de importantes atributos da sua qualidade.
5. Riscos e Gerenciamento de Riscos: Os principais riscos que podem afetar a qualidade do
produto e as ações para evitar esses riscos.

Existe uma ampla gama de atributos de qualidade de software em potencial que
devem ser considerados durante o processo de planejamento de qualidade. Em geral, não é
possível para qualquer sistema ser otimizado em relação a todos os atributos, e, assim, uma
parte importante do planejamento de qualidade é selecionar os principais atributos de
qualidade e planejar como eles devem ser obtidos. (SOMMERVILLE, 2003). A figura a
seguir representa os atributos da qualidade de software.

Figura 2 - Atributos de Qualidade do software
Fonte: Desenvolvido pelo autor, 2010.

29

2.1.4 Padrões de documentação

Um documento é a única maneira tangível de representar o software a ser
desenvolvido o processo. desta forma é extremamente importante a definição de um padrão de
documentos de fácil entendimento e objetivo. Na padronização da documentação, deve-se
considerar o processo de documentação (definindo o processo a ser seguido na
documentação); padrões de documentos (os quais regem a estrutura e a apresentação dos
documentos) e os padrões que asseguram que todas as cópias eletrônicas sejam compatíveis.
Embora a documentação deva se adequar a necessidade de projetos específicos, é interessante
que se utilize o mesmo estilo para todos os documentos produzidos, como identificação,
estrutura, apresentação do documento, padrões de atualização de documento.
O esquema abaixo permite visualizar o processo de padrões de intercâmbio de
documentos. Esta prática possibilita a transferência de documentos eletronicamente recriados
em forma original. Podem também limitar as fontes e estilos de texto utilizados (devido a
diferentes recursos, impressoras e displays) e definir convenções do uso de ferramentas.
(SOMMERVILLE, 2003).

Esquema 1 - Padrões de intercâmbio de documentos

30

2.1.5 Medição e Métricas

De acordo com Martinho (2008), o objetivo das medições, métricas e análises é
direcionar a melhoria contínua em todos os parâmetros da qualidade por um sistema de
medição orientado a metas.
A medição visa obter valores numéricos para atributos de um produto e/ou
processo e compara com outros produtos/processos, buscando tirar conclusões sobre a
qualidade do processo, avaliando se os objetivos pré-definidos estão próximos de serem
alcançados. Já as métricas são as medições referentes ao processo ou produto. São geralmente
medidas características como a rastreabilidade, volatilidade, esforço, abrangência, qualidade e
tamanho.
Segundo o WThreeX (2010), para se atingir a medição e métricas de qualidade em
um processo, são necessários alguns elementos, mencionados abaixo.
Os pontos colocados abaixo compõem as medições:
a) Aceite do grau de cumprimento dos padrões do processo, diretrizes e implementação;
b) Atingir o nível de implementação conforme o planejado;
c) Conclusão dos artefatos utilizando as métricas de qualidade do produto descritas
acima.
Os pontos colocados abaixo compõem as métricas:
a) Ser de fácil entendimento, objetivas e fáceis de coletar;
b) Deve ser uma tarefa automatizada, de modo que não interfira nas atividades dos
desenvolvedores;
Tendências e valores absolutos de métricas devem ser usados ativamente pelas equipes
de gerenciamento e de engenharia para informar o andamento e a qualidade em um
formato consistente.
Quanto à seleção de um conjunto mínimo ou mais extenso de métricas, esta
dependerá das características e do contexto do projeto. Se ele for grande ou tiver requisitos
rigorosos de confiabilidade ou segurança e as equipes de desenvolvimento e avaliação tiverem
um ótimo conhecimento sobre métricas, talvez seja útil coletar e analisar as métricas técnicas.
O contrato pode exigir que determinadas métricas sejam coletadas ou a organização pode
estar tentando aperfeiçoar habilidades e processos em áreas específicas. Não há uma resposta
simples que se adapte a todas as circunstâncias. O gerente de projeto deve selecionar o que é

31

apropriado quando o plano de métricas for produzido. No entanto, quando se apresenta um
plano de métricas pela primeira vez, convém manter a simplicidade, em vez de se arriscar e
cometer erros. (WTHREEX, 2010).

2.2 SOFTWARE QUALITY ASSURANCE

A SQA (Software Quality Assurance ou Garantia de Qualidade de Software) está
envolvida em todo o processo de desenvolvimento de software, monitorando e melhorando os
processos e etapas. Ela faz com que os procedimentos e padrões sejam seguidos; identifica e
garante a correção das falhas dentro do projeto.
Segundo Pressman (1995, p. 725) a garantia de qualidade de software abrange:

[...] (1) métodos e ferramentas de análise, projeto, codificação e Teste; (2) revisões
técnicas formais que são aplicadas durante cada fase da engenharia de software; (3)
uma estratégia de Teste de múltiplas fases; (4) controle da documentação de
software e das mudanças feitas nela; (5) um procedimento para garantir a adequação
aos padrões de desenvolvimento de software (quando aplicáveis); e (6) mecanismos
de medição e divulgação.

O acompanhamento do processo de qualidade de software é feito baseando-se nas
métricas que são obtidas por meio de técnicas de verificação e validação como avaliações,
auditorias, inspeções e revisões. Já no produto, os métodos utilizados podem ser feitos por
meio de Testes de software, como Testes caixa preta, caixa branca, Testes funcionais, Testes
de regressão, entre outros.

2.3 ANÁLISE DE RISCOS

Com a crescente demanda por qualidade de software, um processo bem definido é
um fator extremamente importante. Se torna cada vez mais comum a busca por boas práticas e
modelos conceituados como CMMI e MPS.BR. Entretanto, a implantação de um destes
modelos não é tarefa simples, pois deve passar pela política de cada organização, desviando
sua cultura e crenças. A análise de riscos é uma necessidade encontrada hoje nessas empresas,

32

servindo de orientação na fase de adaptação de um processo. Na análise de riscos, são
considerados fatores como a não utilização de boas práticas de desenvolvimento,
considerando que a qualidade do software está diretamente associada à qualidade dos
processos utilizados em sua produção e ao conhecimento técnico que os usuários do processo
têm sobre as práticas definidas. (ESPINHA, 2007).
Segundo Espinha (2007, p. 11):
Risco é a “exposição à chance de perdas ou danos”. Embora exista também uma
chance de alguma coisa sair melhor do que o esperado, o risco geralmente costuma
ser associado a possíveis perdas ou danos. O conceito de risco resulta da incerteza
quanto a eventos futuros e é parte de todas as atividades do desenvolvimento.

A análise de riscos se baseia em uma estratégia de avaliação de todos os ativos do
processo, bem como suas características (itens relacionados ao ativo). Ela extrai de cada ativo,
informações de uma série de elementos que posteriormente auxiliam na tomada de decisão.
Cada componente possui uma um checklist1 associado, composto pelos itens que
deverão ser verificados. Isto para que facilite a identificação do controle e questionários que
serão utilizados para a coleta de dados.
Os elementos que compõem este controle são:
Nome do Controle: a característica do requisito;
Justificativa: conceitos necessários para explicar porque o controle deve ser implementado;
Ameaças: quais os elementos podem não aproveitar da implementação do controle para se
manifestar e causar danos;
Recomendação: fornece razões para implementação do controle;
Referências: referências bibliográficas da ação;
Probabilidade: representa a probabilidade de uma ameaça se manifestar caso o controle não
esteja implementado na organização;
Severidade: indica o grau do impacto negativo na organização, caso uma ou mais ameaças se
manifestem;
Agrupamento: indica a qual agrupamento o controle pertence.
A imagem abaixo a análise de riscos em sua forma geral.

1
Checklist pode ser definido como o conjunto de itens agrupados em uma lista de forma a facilitar a comparação
ou garantir que as ações associadas a eles sejam gerenciadas adequadamente e não sejam esquecidas.

33

Esquema 2 - Análise de Riscos
Fonte: Espinha, 2007.

Por fim, tem-se uma série de informações concatenadas que fornecem apoio ao
gestor do projeto. As ilustrações abaixo apresentam informações que foram extraídas através
do processo de análise de riscos.

34

Tabela 1 - Resultados da avaliação em abrangência por área de processo.


Gráfico 1 - Resultados da avaliação em abrangência - ameaças

35

2.4 CONSIDERAÇÕES FINAIS

A busca pela qualidade de software não está somente no início do projeto, onde é
feito o levantamento dos requisitos; nem apenas no final realizando Testes funcionais. A
qualidade está presente durante toda engenharia do software: processo de desenvolvimento
que é utilizado, bem como as pessoas que estão envolvidas no processo. Podemos considerá-
la como algo subjetivo que pode variar de acordo com as pessoas que estão envolvidas na
avaliação da qualidade.

36

3 TESTES

O presente capítulo aborda os conceitos de testes de software, bem como os tipos de
testes existentes. Além disso, mostra as dificuldades surgidas no processo de desenvolvimento
e meios de solucioná-las.

3.1 VISÃO DE TESTES DE SOFTWARE

Teste de software é o processo de execução de um produto para determinar se ele
atingiu suas especificações e funcionou corretamente no ambiente para o qual foi projetado. O
seu objetivo é revelar falhas em um produto, para que as causas dessas falhas sejam
identificadas e possam ser corrigidas pela equipe de desenvolvimento antes da entrega final.
Por conta dessa característica das atividades de Teste, dizemos que sua natureza é destrutiva,
e não construtiva, pois visa o aumento da confiança de um produto através da exposição de
seus problemas, porém antes de sua entrega ao usuário final. (DIAS NETO, 2007).
O Teste, da maneira como é executado pela maioria das empresas – como uma
etapa do processo do desenvolvimento e, em geral, executado pelos próprios desenvolvedores
e pelos usuários do sistema – serve apenas para garantir que as especificações ou os requisitos
do negócio foram implementados. Como o processo de desenvolvimento cria produtos com
defeito, se faz necessário descobrir estes defeitos. Em um modelo de garantia de qualidade
isso é insuficiente. Quem poderia garantir que um software testado pelos próprios
desenvolvedores está corretamente testado? Com certeza, existem exceções, mas a melhor
forma de testar um software é ter um processo de Teste claramente definido. (BASTOS et al.,
2007).
O Teste é um processo que envolve vários outros processos da engenharia de
software, e ações que vão desde o levantamento de requisitos até a execução do Teste
propriamente dito. (MOLINARI, 2008). A imagem mostrada abaixo ajuda a localizar o
processo de Testes dentro da Engenharia de Software.

37

Figura 3 - Localização da qualidade dentro da engenharia.
Fonte: Molinari, 2008.

A engenharia de software mostra uma ciência, uma área de construção e gerência
do projeto. Quando se passa a enxergar mais fundo, percebemos que há nela uma área de
qualidade. Sabemos que “ir ao encontro das necessidades dos clientes” é a chave para a
garantia de um produto. Porém, isso só é possível mediante técnicas adequadas para garantir o
funcionamento do software. (MOLINARI, 2008).
O autor prossegue, afirmando que os Testes mostram uma visão das falhas na
qualidade externa, aquela que é visualizada, tal qual um sintoma de uma doença. As raízes
dessas doenças estão na garantia interna, no controle por meio de diversos atributos, tais
como: estrutura adequada de programação, usabilidade, padrões de codificação, etc.
Myers (1979), referenciado em BASTOS et al., (2007) criou conceitos sobre
Testes de Software – uma publicação que na época tornou-se uma das bíblias da qualidade de
software. Nesta obra, Myers afirmava que:
 Os Testes unitários podem remover entre 30% e 50% dos defeitos dos programas;
 Os Testes de sistema podem remover entre 30% e 50% dos defeitos remanescentes;
 Desse modo, os sistemas podem ir para produção ainda com aproximadamente 49% de
defeitos;
 Por último, as revisões de códigos podem reduzir entre 20% e 30% desses defeitos.
Abaixo é apresentado um gráfico, elaborado pelos acadêmicos autores dessa
monografia, com base nas ideias de Myers.

38

Gráfico 2 - Custo de correções
Fonte: Elaboração dos autores, 2010.

O gráfico 2 transmite a ideia de que, para garantir maior qualidade em um
produto, é importante levantar a necessidade de cada fase do desenvolvimento para serem
identificados os problemas de forma rápida. Tendo isso aplicado ao processo utilizado, pode-
se reduzir consideravelmente o custo do desenvolvimento, pois se torna fácil identificar uma
falha logo no seu surgimento.

3.1.1 Conceitos de Testes

Segundo Dias Neto (2007), Teste é uma ação que pode ser realizada em diferentes
estágios do desenvolvimento. Seus objetivos diferem de acordo com o estágio.
 Etapas iniciais: expor defeitos para permitir correção;
 Etapas finais: verificar se o sistema atende a especificações.
Para introduzir os conceitos de Testes de software, é importante esclarecer alguns
dos principais itens relacionados a esta atividade, tais como defeitos, erros e falhas. A
diferença entre estes três conceitos seguem abaixo. Elas estão definidas na terminologia
padrão para Engenharia de Software do IEE - Institute of Electrical and Electronics Engineers
– (IEEE 610, 1990 apud DIAS NETO, 2007).

39

Defeito é um ato inconsistente cometido por um indivíduo ao tentar entender uma
determinada informação, resolver um problema ou utilizar um método ou uma ferramenta.
Por exemplo, uma instrução ou comando incorreto.
Erro é uma manifestação concreta de um defeito num artefato de software.
Diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado intermediário
incorreto ou resultado inesperado na execução de um programa constitui um erro.
Falha é o comportamento operacional do software diferente do esperado pelo
usuário. Uma falha pode ter sido causada por diversos erros e alguns erros podem nunca
causar uma falha.
A ilustração abaixo expressa a diferença entre esses conceitos. Defeitos fazem
parte do universo físico (a aplicação propriamente dita) e são causados por pessoas, por
exemplo, através do mal uso de uma tecnologia. Defeitos podem ocasionar a manifestação de
erros em um produto, ou seja, a construção de um software de forma diferente ao que foi
especificado (universo de informação). Por fim, os erros geram falhas, que são
comportamentos inesperados em um software que afetam diretamente o usuário final da
aplicação (universo do usuário) e pode inviabilizar a utilização de um software. (DIAS
NETO, 2007).

Figura 4 - Defeito x Erro x Falha
Fonte: Neto, 2007.

Ao longo de um processo de testes, são abordados elementos que seguem desde a
fase inicial até a entrega de um software, necessários para que se possa conhecer mais a fundo
a área de testes. Os elementos que seguem abaixo foram descritos com base no livro “Testes
Funcionais de Software”, de Leonardo Molinari (2008, p. 56)

40

a) Planejamento de Testes: é o processo de se planejar Testes. O
planejamento pode gerar um ou mais planos de Testes;
b) Plano de Testes: é o resultado do processo de planejamento de Testes. Ele
representa a composição dos requisitos, casos de Testes, cenários de
Testes a serem utilizados, e quaisquer outros documentos que sejam
pertinentes ao planejamento;
c) Requisitos de Testes: são requisitos dos Testes que representam o que deve
ser testado em termos de meta. Um requisito deve gerar um ou mais casos
de Testes;
d) Tipos de Testes: são os tipos de Testes a serem realizados em um
ambiente. Aqui, cada caso de Teste a ser realizado irá referenciar um tipo
de Teste, ou alguma técnica a ser utilizada. Exemplo: Teste de
performance, Teste funcional, Teste de segurança, etc;
e) Casos de Teste: representa o que deve ser testado em detalhes. É a menor
unidade de Teste, o desdobramento natural dos requisitos de Teste. Cada
caso de Teste é composto por um conjunto de passos de Teste;
f) Passo de Teste: é uma ação específica ou um passo para poder realizar um
Teste. Um passo pertence a apenas um conjunto de passos de Teste.
Exemplo: abrir a aplicação, clicar no botão X;
g) Script de Teste: é também conhecido como “script de automação”.
Conjuntos e passos que são executados em uma ferramenta de automação
de Teste. Representa uma ação ou um caso de Teste gerado através da
ferramenta de automação;
h) Cenário de Teste: é um conjunto de casos de Teste ou scripts a serem
executados em uma ordem com o objetivo de executar uma situação de
Teste;
i) Ambiente de Teste: é um conjunto de artefatos lógicos e físicos que
compõe o ambiente onde os Testes serão planejados e executados;
j) Relatório de Teste: é um relatório contendo informações dos Testes;
k) Metodologia de Testes: é um conjunto de técnicas, método e estratégias
que se volta para a criação e execução de um sistema qualquer;
l) Processo de Teste: é um processo qualquer que representa como os Testes
são gerenciados.
Rocha (2001), aponta outro elemento e sua subdivisão:

41

a) Critério de Teste: serve para selecionar e avaliar casos de Teste de forma a
aumentar as possibilidades de provocar falhas ou, quando isso não ocorre,
estabelecer um nível elevado de confiança na correção do produto.
 O critério de cobertura dos Testes: permite a identificação de partes do
programa que devem ser executadas para garantir a qualidade do software e
indicar quando o mesmo foi suficientemente testado (RAPPS e
WEYUKER, 1982, apud ROCHA, 2007). Ou seja, determinar o percentual
de elementos necessários por um critério de Teste que foram executados
pelo conjunto de casos de Teste;
 O critério de adequação de casos de Teste: quando, a partir de um conjunto
de casos de Teste “T” qualquer, ele é utilizado para verificar se “T” satisfaz
os requisitos de Teste estabelecidos pelo critério. Ou seja, este critério
avalia se os casos de Teste definidos são suficientes ou não para avaliação
de um produto ou uma função;
 O critério de geração de casos de Teste: quando o critério é utilizado para
gerar um conjunto de casos de Teste “T” adequado para um produto ou
função, ou seja, este critério define as regras e diretrizes para geração dos
casos de Teste de um produto que esteja de acordo com o critério de
adequação definido anteriormente.

3.1.2 Defeitos do desenvolvimento

No processo de desenvolvimento de software ocorrem muitos defeitos. Embora as
empresas tenham grande preocupação com o uso dos melhores métodos de desenvolvimento,
ferramentas ou profissionais, os defeitos permanecem presentes nos produtos, o que torna a
atividade de Teste fundamental durante o desenvolvimento de um software. Já foi observado
que esta atividade corresponde ao último recurso para a avaliação do produto antes da sua
entrega ao usuário final. O tamanho do projeto a ser desenvolvido e a quantidade de pessoas
envolvidas no processo são dois possíveis fatores que aumentam a complexidade dessa tarefa,
e por consequência, aumentam também a probabilidade de defeitos. Assim, a ocorrência de
falhas é inevitável. Mas o que significa dizer que um programa falhou? Basicamente significa

42

que o funcionamento do programa não está de acordo com o esperado pelo usuário. Por
exemplo, quando um usuário da linha de produção efetua consultas no sistema das quais só a
gerência deveria ter acesso. De acordo com Dias Neto (2007), esse tipo de falha pode ser
originado por diversos motivos, como por exemplo:
 A especificação pode estar errada ou incompleta;
 A especificação pode conter requisitos impossíveis de serem implementados devido a
limitações de hardware ou software;
 A base de dados pode estar organizada de forma que não seja permitido distinguir os
tipos de usuário;
 Pode ser que haja um defeito no algoritmo de controle dos usuários.
Os defeitos normalmente são introduzidos na transformação de informações entre
diferentes fases do ciclo de desenvolvimento de um software. O exemplo abaixo citado por
Dias Neto (2007), expressa de forma clara o ciclo de vida do desenvolvimento:

Os requisitos expressos pelo cliente são relatados textualmente em um documento
de especificação de requisitos. Esse documento é então transformado em casos de
uso, que por sua vez foi o artefato de entrada para o projeto do software e definição
de sua arquitetura utilizando diagramas de classes da UML. Em seguida, esses
modelos de projetos foram usados para a construção do software em uma linguagem
que não segue o paradigma orientado a objetos. Observe que durante esse período
uma série de transformações foi realizada até chegarmos ao produto final. Nesse
meio tempo, defeitos podem ter sido inseridos. (DIAS NETO, 2007, p.56).

A figura abaixo ilustra este exemplo:

Figura 5 - Diferentes interpretações ao longo do ciclo de desenvolvimento de um software.
Fonte: Dias Neto, 2007.

43

3.1.3 Gerenciamento de Testes

Molinari (2008) declara que a gestão da qualidade representa um dos pilares da
Qualidade de Software. Os outros pilares tratam dos elementos gestão de configuração, gestão
de requisitos e Testes.
Gestão de Configuração: trata de gerência, controle e registro dos artefatos que
compõem o software, incluindo aí todo o histórico da mudança do software em si;
Gestão de Requisitos: trata de gerência, controle e registro das necessidades do
sistema (requisitos) e dos usuários em todos os níveis, incluindo aí a rastreabilidade das
necessidades e da sua mudança;
Testes: trata de gerência, planejamento, controle e execução dos Testes em todos
os níveis, de modo a garantir a implementação (projeto, desenvolvimento e entrega) das
necessidades especificadas.
Como dito anteriormente, quanto antes os testes iniciarem, mais barato será a
correção dos defeitos encontrados. O gerente de testes deve trabalhar neste sentido, definindo
e acompanhando o processo para garantir a qualidade do sistema em desenvolvimento. De
modo geral, o processo de teste é representado por ciclos, que são as etapas a serem seguidas
em todo o processo. Para Bastos et al. (2007), o ciclo de testes é representado pelas seguintes
etapas:
 Planejamento
 Preparação
 Especificação
 Execução
 Entrega

3.2 REQUISITOS E CASOS DE TESTES

Nesta seção serão abordados os requisitos e os casos de testes utilizados no
processo.

44

3.2.1 Definindo os requisitos

Para elaborar os casos de testes é necessário primeiramente levantar os requisitos
de testes. Não se deve confundir requisito de teste com caso de teste - este último será
explicado mais adiante. Para criar tais requisitos deve-se definir exatamente o que se deseja
testar em nível macro e em nível detalhado. (MOLINARI, 2008).
Para realizar o levantamento geralmente se tem como base os documentos,
especificações de usuários, necessidades do sistema e os casos de uso. Quanto mais detalhado
for o requisito, mais próximo do caso de testes ele vai ficar. Segundo Molinari (2008), os
requisitos devem possuir algumas características para que este seja bem elaborado, podemos
destacar as seguintes características:
a) Sua escrita deve ser de forma clara e objetiva, não deve de maneira nenhuma conter
ambiguidades em sua descrição;
b) Deve ser único, não pode existir ambiguidade entre requisitos;
c) A descrição deve ser adequada à realidade que ele propõe representar;
d) Seu detalhamento deve ser completo, lembrando que completude não significa texto
extenso, deve conter apenas o necessário.
Os requisitos geralmente estão organizados em uma estrutura hierárquica. Deve
conter um número de identificação único, descrição detalhada, seu status (posição atual no
ciclo de vida de um requisito. Ex.: criado, atualizado, finalizado, implementado, etc.) e suas
dependências para com outros requisitos de Testes. (MOLINARI, 2008).

3.2.2 Definindo casos de testes

Descreve uma condição particular a ser testada e é composto por valores de
entrada, restrições para a sua execução e um resultado ou comportamento esperado (CRAIG e
JASKIEL, 2002, apud OLIVEIRA e PEREIRA, 2007).
Conforme menciona Molinari (2008), os casos de Testes podem ser construídos,
partindo dos requisitos. Nesta forma, o Caso de Teste será dividido em três grupos, chamados
de Cenário de Teste. Isso não significa que cada cenário deverá ser totalmente preenchido em

45

amplitude e profundidade, mas devem ser vistos, pois sua importância pode variar entre os
cenários.
 Cenário de Testes no caminho principal: são os casos de Testes envolvidos
no fluxo normal do sistema-alvo de Teste, ou seja, são os Testes que o
usuário normalmente utiliza;
 Cenário de Testes no caminho alternativo: são os casos de testes que estão
envolvidos no fluxo alternativo da execução da aplicação, são considerados
Testes de menor importância;
 Cenário de Testes de exceção: são os Testes em situações de possíveis
problemas ou exceções que impedem ou atrapalham o funcionamento da
aplicação.
Além das técnicas existentes, é importante também testar os acessos da aplicação
ao banco de dados, para verificar se a aplicação está trabalhando o dado de maneira correta,
ou seja, se o dado foi lido, atualizado, alterado e excluído do banco de dados, certificando
assim a integridade da informação. Para executar essa validação, pode-se criar um caso de
teste para essa função, ou mesmo acrescentar como um passo dentro dos casos de testes
respectivos.
Assim como os requisitos, os casos de testes também possuem algumas
características para que sejam bem elaborados, entre elas podemos destacar as seguintes:
a) Deve ser escrito de maneira objetiva e clara, sem ambiguidades no texto;
b) Assim como acontece nos requisitos, o caso de Teste é único;
c) Sua descrição deve estar adequada à realidade a qual propõe representar, contendo os
passos para realizar o Teste:
d) O caso de Teste deve estar completo;
e) Deve possuir referências de outros casos de Testes, se necessário.
Segundo Pontes (2009) um caso de teste simples deve possuir um objetivo, um
passo-a-passo de como executar o teste, suas pré-condições para iniciar o teste, caso seja
necessário, e o resultado esperado, como o exemplo que pode ser visualizado no quadro
abaixo.

46

Quadro 3 - Exemplo de um Caso de Teste simples.
Fonte: Pontes, 2009.

Entretanto, nada impede que sejam adicionadas mais informações ao caso de
teste, como: ambiente, dados de entrada, cronograma, dependências com outros casos de
testes, entre outras.

3.3 TIPOS DE TESTES

O planejamento do Teste deve prever os tipos e as técnicas que serão utilizadas ao
realizar um determinado Teste. Existem dois tipos básicos de Testes considerados os mais
genéricos: Testes Funcionais e Testes Estruturais. Nenhum destes é completo. Eles se
completam e devem ser aplicados em conjunto. Para cada um destes tipos podemos realizar
inúmeras técnicas criadas para complementar os Testes. (MOLINARI, 2008).
Para Rocha, aludido em Costa (2009), os principais níveis de Testes são:
 Teste de Unidade
 Teste de Integração
 Teste de Sistema
 Teste de Aceitação
 Teste de Regressão.

47

A seguir, abordar-se-á o conceito destes e de outros tipos de Testes, bem como
técnicas de Testes Funcionais e Testes Estruturais.

3.3.1 Teste Funcional

Molinari (2008) define os Testes funcionais como:
[...] o tipo de Teste que tem por objetivo medir a qualidade funcional de
componentes de um sistema. Este tipo de Teste, conhecido também como o Teste
“caixa-preta”, propõe testar a funcionalidade do sistema – entrada e saída de dados -
com uma visão externa da aplicação, de modo a assegurar a funcionalidade do
sistema. Aqui não é considerada a verificação no interior da aplicação (código-fonte,
estrutura).

Os Testes são realizados executando a rotina ou sistema que pretende-se testar
comparando-o com o resultado previamente conhecido. No geral, o termo “Teste funcional”
tente a ficar limitado a Testes unitários. Porém, nada impede de ser aplicada certa
granularidade a um Teste funcional. Podemos testar um componente de um sistema ou
realizar verificações em um arquivo de banco. Abaixo, segue a representação do teste caixa-
preta.

Figura 6 - Componentes existentes em Testes caixa preta.

48

Como no teste estrutural, há diversas técnicas existentes que ajudam a executar
um bom teste funcional. Durante a execução de um checklist ou simplesmente o ato de
homologar uma tarefa, está se realizando técnicas de testes funcionais. Falta apenas o hábito
de estar enfatizando estas atividades para melhorar o processo.
Algumas técnicas existentes são Teste de Valor Limite ou Fronteiras (Boundary
Value Testing), Teste de Particionamento Equivalente (Equivalente Class Testing), Teste de
Regressão, entre outros. Abaixo serão apresentados detalhes de algumas técnicas utilizadas
nos Testes Funcionais. (MOLINARI, 2008).

3.3.2 Testes de Unidade

Este tipo de Teste, também conhecido como Testes unitários, tem por objetivo
explorar a menor unidade do projeto, procurando provocar falhas ocasionadas por defeitos de
lógica e de implementação em cada módulo, separadamente. O universo alvo desse tipo de
Teste são os métodos dos objetos ou mesmo pequenos trechos de código. (ROCHA, 2001
apud DIAS NETO, 2007).

3.3.3 Testes de Sistema

Avalia o software em busca de falhas por meio da utilização do mesmo, como se
fosse um usuário final. Dessa maneira, os Testes são executados nos mesmos ambientes, com
as mesmas condições e com os mesmos dados de entrada que um usuário utilizaria no seu dia-
a-dia de manipulação do software. Verifica se o produto satisfaz seus requisitos. (ROCHA,
2001 apud DIAS NETO, 2007).

49

3.3.4 Testes de Aceitação

São realizados geralmente por um restrito grupo de usuários finais do sistema.
Esses simulam operações de rotina do sistema de modo a verificar se seu comportamento está
de acordo com o solicitado. (ROCHA 2001, apud DIAS NETO, 2007).

3.3.5 Testes de Integração

É uma técnica sistemática para construção da estrutura do programa. O Teste de
integração pode ser considerado como uma extensão lógica dos Testes unitários. Na sua
forma mais simples, duas unidades que foram testadas são combinadas em um componente e
testadas. Um componente neste caso, refere-se a um conjunto integrado de mais de uma
unidade. O objetivo desta técnica é montar estruturas de testes para descobrir erros
relacionados à interface, combinando peças e testando em pares. (Pressman, 1995).

3.3.5.1 Não Incremental

A abordagem chamada de big-bang, onde os módulos são testados isoladamente e
depois integrados de uma só vez. Os conjuntos de erros são difíceis de serem detectados, logo
difíceis de serem corrigidos, pois devido ao tamanho e complexidade do programa, é difícil
isolar as causas de tais erros. Testes não-incrementais são normalmente usados devido às
pressões do dia a dia e os Testes são aplicados para demonstrar uma operabilidade mínima do
sistema. (CAMPOS, 2009).

50

Esquema 3 - Representação dos módulos de Teste
Fonte: Campos, 2009.

3.3.5.2 Incremental

Um software é construído e testado em pequenos segmentos, tornando a correção
de erros mais fácil. A probabilidade de testar completamente a interface do sistema também
aumenta.

51

A figura abaixo representa componentes que foram estruturados de forma
incremental:

Esquema 4 - Testes de integração.

De acordo com Campos (2009), os pontos relevantes desta técnica são:
 O Tester não precisa esperar até que todo o sistema esteja pronto, para iniciar os
Testes;
 Há um menor risco de fracasso geral do projeto, já que cada módulo é verificado antes
e caso algo esteja errado a correção será implementada já no próximo ciclo de Teste;
 A integração dos módulos só é realizada, após eles já terem sido verificados, ou seja,
se algum erro acontecer, a causa provavelmente será a comunicação entre esses
módulos.

3.3.5.3 Integração Top-down

É uma abordagem incremental. Como o nome já diz, a integração dos módulos
acontece de cima para baixo, o que facilita a verificação antecipada dos pontos de decisão e
controle no processo de Teste. (CAMPOS, 2009).

52

3.3.5.4 Integração Bottom-up

Na técnica Botton-up, a integração do sistema começa a partir do nível mais baixo
do software, ou seja, o módulo. O módulo é dito como o mais baixo nível se ele não depende
de outro módulo. A Bottom-Up assume que todos os módulos foram individualmente testados
antes. (CAMPOS, 2009).

3.3.6 Teste de Regressão

Esta técnica de Teste trabalha de modo a testar segmentos já testados após a
implementação de uma mudança na aplicação. Ela tem por objetivo determinar se a
documentação do sistema permanece atual; verificar se os dados e as condições de Teste
permanecem atuais; determinar se as funções previamente testadas continuam funcionando
corretamente após a introdução de mudanças no sistema.
Costa (2009) menciona que os Testes de regressão tratam de executar Testes da
versão anterior, na nova versão de um aplicativo, de modo a se certificar que o que está na
aplicação continue certo.
Um Teste de regressão deve ser executado sempre que o sistema sofre alguma
alteração. Significa aplicar todos os Testes realizados anteriormente para garantir que os
resultados não tenham sido afetados pelas mudanças realizadas, não só na parte alterada,
como os outros segmentos do sistema.
Um ponto negativo do Testes de regressão é o gasto excessivo de tempo e a
repetição das operações, o que muitas vezes contribui para que eles não sejam realizados de
forma completa. Como esses Testes são vitais para garantir a qualidade final do sistema, tem-
se uma excelente justificativa para introduzir a automação de Testes na organização.

53

3.3.7 Teste de Estresse

Neste Teste será avaliado o comportamento do sistema sob condições críticas.
Basicamente, este Teste tem o objetivo de avaliar os limites, ou seja, até quando o software
pode ser exigido e até quais as falhas (caso existam) decorrentes dele, levando em
consideração as restrições. Tais como a memória, número de transações e capacidade da
aplicação. Para Lourenço (2010), este tipo de Teste é indispensável quando se trata de Testes
em aplicações cuja eficiência seja uma característica importante. Exemplos:
 Servidores de arquivos web, que devem atender a solicitação de um grande número de
clientes;
 Aplicações industriais, tais como o controle de uma refinaria de petróleo;
Jogos de Computador, que precisam de um desempenho aceitável para serem viáveis
comercialmente.
Este Teste permite a capacidade de responder à questões como:
 O sistema consegue atingir o objetivo?
 Qual o número máximo de transações realmente possível?
 Se a plataforma de execução se degradar (por exemplo, uma falha parcial de rede, falta
de espaço em disco, etc.), como o sistema se comportará?
A maior dificuldade que se pode ter ao realizar este Teste é preparar a plataforma
para executá-lo. Caso se queira saber a quantidade mínima de memória disponível para que o
sistema funcione, retirar a memória do computador seria uma solução trabalhosa. Para isso,
existem no mercado aplicações que permitem tal avaliação, como WinStress (permite reduzir
artificialmente a capacidade de desempenho do computador conforme configuração desejada.
Possibilita também a variação de parâmetros como carga de CPU, memória disponível,
espaço em disco e carga de rede). Ferramentas como DieselTest e OpenST, permitem testar
um programa simulando um número arbitrário de conexões. (LOURENÇO, 2010).

54

3.3.8 Análise do Valor Limite ou Fronteira

Este Teste utiliza uma seleção dos casos de testes que põem a prova os valores
fronteiriços. São utilizadas extremidades da classe, tendo como variáveis a faixa de valores o
tamanho da estrutura, valores específicos, entre outros extraídos. Ao aplicar um caso de Teste
utilizando esta técnica, é importante gerar entradas ou saídas que coincidem com ambos os
lados de cada fronteira, incluindo o valor da própria fronteira. Segundo Freitas (2009) para se
elaborar esta técnica, deve-se considerar as condições:
 Se uma condição de entrada um intervalo, delimitado pelos valores A e B, os casos de
teste devem ser projetados com valores A e B logo acima e logo abaixo de A e B
respectivamente;
 Se uma condição de entrada especificar uma série de valores, os casos de teste que
ponham à prova números máximos e mínimos devem ser desenvolvidos. Valores logo
acima e logo abaixo do mínimo e do máximo também são testados;
 Aplicar as diretrizes 1 e 2 às condições de saída, por exemplo, supondo-se que uma
tabela de temperatura versus pressão seja exigida como saída de um programa de análise
de engenharia, os casos de teste devem ser projetados para criar um relatório de saída que
produza um número máximo (e mínimo) permissível de entradas na tabela;
 Se estruturas internas de dados do programa tiverem prescritas fronteiras, certificar-se
de projetar um caso de teste para exercitar a estrutura de dados em sua fronteira.
Abaixo, é apresentado um exemplo da técnica.

Tabela 2 - Refinamento utilizando Valores-Limites.

Fonte: FREITAS, 2009.

Esta técnica é simples de trabalhar, e pode ser aplicada para realizar Testes
unitários, de integração ou Teste de aceitação de usuários.

55

3.3.9 Tabela de decisão

A técnica de decisão pode ser aplicada a todas as situações quando a execução do
software depende de muitas decisões lógicas. Ela baseia-se em uma combinação de situações
que devem ocorrer para que uma determinada ação seja tomada, expressa por um determinado
processamento ou por um cálculo. A tabela de decisão contém condições que disparam as
ações, muitas vezes combinações verdadeiras e falsas para todas as condições de entrada, e
ações resultantes para cada combinação de condição. (FREITAS, 2009).
Cada coluna da tabela corresponde a uma regra de negócio que define uma única
combinação de condições que resulta na execução de ações associada com aquela regra.
A cobertura padrão comumente usada em uma tabela de decisão é ter no mínimo
um Teste por coluna cobrindo todas as combinações de condições apresentadas. (FREITAS,
2009). A seguir, é mostrado um exemplo de tabela de decisão.

Tabela 3 - Exemplo de uma tabela de decisão.

.
Fonte: FREITAS, 2009.

No exemplo imaginário acima (Freitas, 2009) a decisão de se aceitar o seguro será
baseado no número de acidentes combinado com o sexo do motorista. Esta suposta
companhia de seguros entende que as pessoas do sexo feminino dirigem com mais cuidado,
como podemos ver na tabela de decisão acima.

56

3.3.10 Testes de Semântica

Segundo Freitas (2009), estes Testes devem ser usados para avaliar telas ou
relatórios têm defeitos de sintaxe e estão em conformidade com o modelo de dados do sistema
(tamanho dos atributos, etc.). Para este Teste deve, também, ser usado um padrão para criação
de telas e relatórios.
Procedimentos:
 Criar uma lista de verificação para as telas e relatórios;
 Definir as telas e relatórios que serão testados;
 Montar os scripts de Teste.
É importante considerar que algumas empresas são bastante rígidas quando se
trata da criação de telas e/ou relatórios.

3.3.11 Testes Estruturais

Os Testes estruturais, ou também chamados de caixa-branca, têm por objetivo
avaliar o comportamento interno do sistema, simulando situações que exercitem todas as
estruturas utilizadas na codificação. Permite um Teste mais preciso em relação aos pontos
críticos do código-fonte. Freitas (2009), afirma que os Testes estruturais devem considerar os
seguintes aspectos:
 Teste de condição;
 Teste de ciclos;
 Teste de fluxo de dados;
 Teste de caminhos lógicos;
 Códigos nunca executados.
A imagem a seguir é uma representação desta técnica.

57

Figura 7 - Componentes existentes em Testes caixa branca.

Testes estruturais são considerados mais complexos e muito diferentes do Teste
de caixa-preta. Ao aplicá-lo, deve-se avaliar a complexibilidade do software e a tecnologia
nele empregada.
Para a utilização deste tipo de Teste é necessário que se tenha um controlador de
Teste que dispare as rotinas na unidade de software, avalie os resultados gerados e compare
com o esperado. Os controladores produzem um log de execução, identificando quais casos
de testes obtiveram sucesso e quais falharam, permitindo a correção dos pontos de não-
conformidade da unidade de software. Esse mesmo processo será executado até que a unidade
não apresente falha na sua estrutura interna. (FREITAS, 2009).
Alguns exemplos de ferramentas já existentes:
 Selenium IDE
 JUnit
 DBUnit
 FitNesse

3.3.11.1 Técnicas de Testes Estruturais

São as seguintes:

Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett

Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (16)

Similaire à Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett

Similaire à Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett (20)

Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett