Você está na página 1de 55

UNIVERSIDADE REGIONAL DE BLUMENAU

CENTRO DE CINCIAS EXATAS E NATURAIS


CURSO DE CINCIAS DA COMPUTAO
(Bacharelado)

SISTEMA PARA GERENCIAMENTO DE TESTES


FUNCIONAIS DE SOFTWARE

TRABALHO DE ESTGIO SUPERVISIONADO SUBMETIDO UNIVERSIDADE


REGIONAL DE BLUMENAU PARA A OBTENO DOS CRDITOS NA
DISCIPLINA COM NOME EQUIVALENTE NO CURSO DE CINCIAS DA
COMPUTAO BACHARELADO

EVERTON LUIZ KOLM

BLUMENAU, NOVEMBRO/2001
2001/2-21

SISTEMA PARA GERENCIAMENTO DE TESTES


FUNCIONAIS DE SOFTWARE
EVERTON LUIZ KOLM

ESTE TRABALHO DE ESTGIO SUPERVISIONADO, FOI JULGADO ADEQUADO


PARA OBTENO DOS CRDITOS NA DISCIPLINA DE ESTGIO
SUPERVISIONADO OBRIGATRIA PARA OBTENO DO TTULO DE:

BACHAREL EM CINCIAS DA COMPUTAO

Prof. Everaldo Artur Grahl Supervisor na FURB

Jos Milton da Silva Orientador na Empresa

Prof. Jos Roque Voltolini da Silva Coordenador na


FURB do Estgio Supervisionado

BANCA EXAMINADORA

Prof. Everaldo Artur Grahl

Prof. Marcel Hugo

Prof. Paulo Csar Rodacki Gomes

ii

DEDICATRIA

Dedico este trabalho minha famlia e minha namorada, por compreenderem meus
sonhos e me apoiarem nos momentos mais difceis. Amo todos vocs.

iii

AGRADECIMENTOS

A Deus por ter me guiado, me dando fora e sade para cursar esta faculdade.
Aos meus pais Siegfried e Marli Martins Kolm, pela pacincia e compreenso que
tiveram durante toda a minha vida acadmica.
Ao meu irmo, Cleison Jos por ter aguardado a concluso do meu curso de graduao
antes de iniciar o seu.
A minha namorada Anaclia Fernanda Moretto, pela compreenso que teve durante
todo meu curso de graduao.
Ao meu opa Albano Kolm, ao meu av Alzidio Jos Martins e ao meu tio Fernando
Jos Klock, que infelizmente no esto mais conosco, mas que com certeza estiveram olhando
por mim.
Ao professor e orientador Everaldo Artur Grahl, pela ateno e auxlio dispensados na
elaborao deste trabalho.

iv

SUMRIO
LISTA DE FIGURAS ............................................................................................................ VII
LISTA DE ABREVIATURAS.............................................................................................. VIII
RESUMO .................................................................................................................................IX
ABSTRACT .............................................................................................................................. X
1 INTRODUO ..................................................................................................................... 1
1.1 EMPRESA ...........................................................................................................................2
1.1 OBJETIVOS DO TRABALHO .......................................................................................... 3
1.2 ESTRUTURA DO TRABALHO ........................................................................................ 3
2 TESTE DE SOFTWARE....................................................................................................... 4
2.1 CONCEITOS INICIAIS...................................................................................................... 4
2.2 REALIZAO DOS TESTES .......................................................................................... 7
2.3 TIPOS DE TESTE DE SOFTWARE ............................................................................... 11
2.4 TESTE FUNCIONAL....................................................................................................... 12
2.4.1 TIPOS DE TESTES FUNCIONAL................................................................................ 13
2.4.1.1

TESTE DE VALOR LIMITE .................................................................................. 13

2.4.1.1.1 GENERALIZANDO O TESTE DE VALOR LIMITE ........................................... 14


2.4.1.1.2 LIMITES DE ANLISE DE VALOR LIMITE...................................................... 14
2.4.1.2

TESTE DE ROBUSTEZ.......................................................................................... 15

2.4.1.3

TESTE DE PIOR CASO ......................................................................................... 15

2.4.1.4

TESTANDO A PARTIR DE RESULTADOS ........................................................ 15

2.5 GERENCIAMENTO DE TESTES ................................................................................... 16


2.6 CHECKLIST ..................................................................................................................... 19
2.7 PROCESSO DE TESTE ................................................................................................... 20

3 DESENVOLVIMENTO DO TRABALHO ........................................................................ 22


3.1 REQUISITOS DO PROBLEMA ...................................................................................... 23
3.2 ANLISE DOS REQUISITOS....................................................................................... 233
3.3 ESPECIFICAO ............................................................................................................ 24
3.3.1 DIAGRAMA DE CASOS DE USO ............................................................................... 24
3.3.2 DIAGRAMA ENTIDADE RELACIONAMENTO ....................................................... 26
3.3.3 DICIONRIO DE DADOS............................................................................................ 26
3.4 IMPLEMENTAO ........................................................................................................ 28
3.4.1 MENU PRINCIPAL ....................................................................................................... 28
3.4.2 CONSIDERAES SOBRE A IMPLEMENTAO .................................................. 36
4 CONCLUSES ................................................................................................................... 39
4.1 SUGESTES .................................................................................................................... 40
REFERNCIAS BIBLIOGRFICAS ..................................................................................... 41
ANEXO I DIAGRAMA ENTIDADE RELACIONAMENTO.............................................43
ANEXO II DICIONARIO DE DADOS................................................................................ 45

vi

LISTA DE FIGURAS
Figura 1 Fluxograma do pessoal envolvido nos testes.. ........................................................ 19
Figura 2 - Fluxograma ..............................................................................................................23
Figura 3 Diagrama de casos de uso ....................................................................................... 25
Figura 4 Diagrama entidade relacionamento......................................................................... 27
Figura 5 Tela de abertura do sistema..................................................................................... 28
Figura 6 Tela de cadastro de sistemas .................................................................................. 29
Figura 7 Tela de cadastro de verses..................................................................................... 29
Figura 8 Tela de cadastro de releases.................................................................................... 30
Figura 9 Tela de cadastro de mdulos ................................................................................... 30
Figura 10 Tela de cadastro de rotinas.................................................................................... 31
Figura 11 Tela de cadastro de processos ............................................................................... 31
Figura 12 Tela de cadastro de checklists ............................................................................... 32
Figura 13 Tela de cadastro de checklists de entrada ............................................................. 32
Figura 14 Tela de cadastro de checklists de sada ................................................................. 33
Figura 15 Tela de cadastro de SMSs do processos .............................................................. 33
Figura 16 Tela de cadastro de SMSs.................................................................................... 34
Figura 17 Tela de cadastro de documentos ........................................................................... 35
Figura 18 Tela de exemplo de figura de teste cadastrada no sistema.................................... 36
Figura 19 Tela da ferramenta Benner Builder ....................................................................... 37

vii

LISTA DE ABREVIATURAS
DER

Diagrama Entidade Relacionamento

ERP

Enterprise Resource Planning

SMS

Solicitao de Manuteno de Sistema

VV&T

Verificao, validao e teste

viii

RESUMO
Este trabalho teve como objetivo o desenvolvimento de um sistema para o
gerenciamento de testes funcionais de software, com a utilizao de checklists que facilita o
processo de teste na empresa Benner Sistemas S/A. A utilizao do sistema mostrou uma
reduo aproximadamente de cinqenta por cento, baseado no nmero de erros encontrados
pelos clientes nos sistemas.

ix

ABSTRACT
This work had like object the development of system for the managemente of
funcionals teste of software, with the utilization of checklists that facilitate the process of teste
in the enterprise Benner Systems S/A. The utilization of the system showed a reduction
approximately of fifteen percent, based in the number of errors found for the customers in the
systems.

1 INTRODUO
Com a grande concorrncia que h hoje na rea de software, as grandes empresas de
desenvolvimento esto precisando ter cada vez mais um diferencial em seu produto e um
destes o Teste de Software. A empresa Benner Sistemas S/A de Blumenau estava
necessitando de um software para o gerenciamento do seu teste de software e um padro para
o seu processo de Teste de Software, pois no possuia nenhuma tcnica e nenhum padro para
esses testes. Os testes hoje so realizados pelos prprios programadores e pelo setor de
suporte, que verifica as funes bsicas do sistema e rotinas novas ou alteradas durante uma
verso. A empresa verificou que hoje 30% (trinta por cento) dos problemas identificados
pelos clientes nos sistemas de Recursos Humanos e Corporativo, so problemas que no
foram encontrados por falta de teste. A falta de teste est gerando uma grande quantidade de
retrabalho, o que acaba ocasionando um custo maior e alm de prejudicar a imagem da
empresa frente ao cliente.
De acordo com Presmann (1995), as mudanas so inevitveis quando um software de
computador construdo. As mudanas aumentam o nvel de confuso entre os engenheiros
de software que esto trabalhando num projeto. A confuso surge quando as mudanas no
so analisadas antes de serem feitas, registradas antes de serem implementadas, relatadas aos
que precisam tomar conhecimento delas ou controladas de um modo que melhore a qualidade
e reduza o erro.
Segundo Maldonado (1998), o teste funcional concentra-se nos requisitos funcionais
do software. Atravs dele torna-se possvel verificar as entradas e sadas de cada unidade. O
teste funcional tambm conhecido como teste caixa preta pelo fato de tratar o software como
uma caixa cujo contedo desconhecido e da qual s possvel visualizar o lado externo, ou
seja, os dados de entrada fornecidos e as respostas produzidas como sada. Na tcnica de teste
funcional so verificadas as funes do sistema sem se preocupar com os detalhes da
implementao. O teste funcional envolve dois passos principais: identificar as funes que o
software deve realizar e criar casos de teste capazes de checar se essas funes esto sendo
realizadas pelo software. As funes que o software deve possuir so identificadas a partir de
sua especificao. Assim, uma especificao bem elaborada e de acordo com os requisitos do
usurio essencial para esse tipo de teste.

2
Segundo Paula Filho (2001), mtodo de Caixa Preta tem por objetivo determinar se os
requisitos foram totais ou parcialmente satisfeitos pelo produto. Os testes de caixa preta no
verificam como ocorre o processamento, mas apenas os resultados produzidos.
De acordo com Inthurn (2001), o teste funcional ou caixa preta procura descobrir
basicamente:
a) funes incorretas ou ausentes;
b) erros de interface
c) erros nas estruturas de dados ou no acesso a bancos de dados externos;
d) erros de desempenho;
e) erros de inicializao e trmino.

1.1 EMPRESA
O

estgio foi realizado na empresa Benner Sistemas S/A, cuja principal finalidade

produzir e desenvolver sistemas para aplicaes nas reas de Recursos Humanos e


Corporativo, utilizando as ferramentas de Benner Runner, Benner Builder, Benner Integrator
e Benner Report.
A empresa atualmente desenvolve sistemas para empresas de pequeno, mdio e
grande porte e possui um variado nmero de sistemas para controle de diversas reas, tais
como:
a) Sistema de Recursos Humanos;
b) Sistema Corporativo;
c) Sistema de Turismo e outros.

A Benner Sistemas possui dez analistas e trinta e cinto programadores que esto
distribudos nas reas de desenvolvimento dos sistemas de recursos humanos, corporativo e
turismo. A empresa no possui metodologia de desenvolvimento de sistemas, nem padro de
desenvolvimento. O analista define a proposta de soluo, que seria a definio, em um editor
de textos e utiliza a ferramenta Benner Builder para criar as tabelas e campos na base de
dados ou passa para o programador fazer. Desta forma torna-se muito mais pratico a criao
das tabelas e campos diretamente na base de dados, pois ele pode verificar mais rapidamente
como ficar o layout dos campos na tela do sistema.

1.2 OBJETIVOS DO TRABALHO


O objetivo principal deste trabalho foi desenvolver um software para auxiliar o
gerenciamento de testes funcionais de software na empresa Benner Sistemas S/A.
Os objetivos especficos do trabalho so:
a) criar um processo de testes e incluir checklists para fazer as verificaes de erros;
b) avaliar o impacto da utilizao de um processo formalizado na empresa.

1.3 ESTRUTURA DO TRABALHO


O primeiro captulo apresenta uma introduo ao trabalho, iniciando alguns conceitos
empregados em sua elaborao. So apresentados ainda, os objetivos, a empresa e a
organizao do texto.
O segundo captulo compila a fundamentao terica aplicada no desenvolvimento do
trabalho. Apresenta informaes sobre teste de software, tipos de teste e gerenciamento de
testes. O captulo rene ainda os conceitos sobre qualidade de software.
O terceiro captulo apresenta a especificao do prottipo, onde consta o diagrama de
contexto, diagrama de casos de uso, diagrama de entidade e relacionamento (DER), dicionrio
de dados e o diagrama hierrquico funcional. Tambm no terceiro captulo apresentado o
sistema de gerenciamento de testes funcionais de software.
No quarto captulo so feitas as consideraes finais sobre o trabalho, incluindo
concluses e sugestes.

2 TESTE DE SOFTWARE
Neste captulo sero apresentadas consideraes sobre teste de software, tipos de teste
e gerenciamento de testes.

2.1 CONCEITOS INICIAIS


De acordo com Martin (1991), o teste em software nada mais que a verificao
dinmica do software, ou seja, o processo de executar e observar seu comportamento em
relao aos requisitos acordados em contrato. atravs do teste que se pode detectar a
presena de erros em um programa, embora no se possa predizer a ausncia deles. Isto
equivale dizer que quando o processo de teste no detecta erro, a nica afirmao possvel a
de que o teste pode no ter sido suficientemente completo para revelar os erros existentes e
jamais a de que o programa em questo est correto.
Segundo UNICRUZ (2001), Teste uma rea da Engenharia de Software na qual a
distncia entre a pesquisa de conhecimentos e a prtica atual muito grande. Uma das razes
muitas vezes citadas a quantidade de esforo extra necessrio para o desenvolvimento da
infra-estrutura necessria para um processo de teste compreensivo, tornando-o tedioso, pois
requer a determinao dos dados para teste e dos resultados esperados, a execuo do
programa com os dados selecionados e a anlise dos resultados computados.
De acordo com Inthurn (2001), freqentemente gasta-se muito tempo e dinheiro em
testes e na correo dos erros encontrados, devido especialmente ao fato de vrios erros
somente virem a ser detectados no final do processo de desenvolvimento. Alm disso, sem
uma infra-estrutura (facilidades automatizadas ou no) para a realizao dos testes, torna-se,
por vezes, impraticvel a sua aplicao de forma adequada. Todavia, se a atividade de teste
for executada como parte integrante do desenvolvimento de software, casos de teste podem
ser criados nas diferentes fases do ciclo de vida para testar os produtos da prpria fase e para
serem usados na implementao do cdigo.
A partir da especificao estruturada do sistema (gerada na fase de anlise), deve-se
comear com a atividade de gerao de casos de teste de aceite. Aps a codificao, cada
mdulo ser testado individualmente, bem como sua integrao com o sistema.

5
Primeiramente gerado o plano de teste onde se estabelece a pessoa/grupo responsvel
por testar o sistema e se define procedimentos padres, verificando-se os possveis erros e
comparando os resultados obtidos com os resultados esperados.
Nesta fase so efetuados tambm testes de desempenho, a fim de analisarem o tempo
de resposta do sistema, testes de vias normais, que verificam se o sistema executa
apropriadamente aps uma entrada vlida e finalmente os testes de vias de erro, onde as
entradas fornecidas ao sistema so propositadamente valores no usuais ou errados. Ao final
dos testes efetua-se um relatrio com os resultados obtidos.
Um dos principais propsitos para a realizao de testes pode ser considerado como
sendo a busca por reduzir o risco envolvido na construo e no uso de software com erros.
Apesar de no se conseguir eliminar todo o risco de desenvolver produtos com defeitos, tornase muito importante aumentar o grau de confiana de que se est construindo um produto com
o comportamento desejado. Teste uma das atividades realizadas para garantir a qualidade do
software, sendo de extrema relevncia, por permitir a precauo em relao aos custos
envolvidos com a ocorrncia de falhas e, principalmente, por salvaguardar o seu
funcionamento quando envolve riscos vida humana ou grandes perdas financeiras.
Segundo Maldonado (1997), a atividade de teste deve ser considerada como uma
atividade do desenvolvimento de software. Deve ser feito todo o planejamento, depois partir
para o projeto dos casos de teste, depois executar os testes, colher os resultados e ento
confrontar os resultados obtidos com os esperados. O teste de software nada mais que a
verificao dinmica do software, ou seja, o processo de executar e observar seu
comportamento em relao aos requisitos acordados em contrato. Atravs do teste que se
pode detectar a presena de erros em um programa, embora no possamos predizer a ausncia
deles. Isto equivale a dizer que quando o processo de teste no detecta erro, a nica afirmao
possvel a de que o teste pode no ter sido suficientemente completo para revelar os erros
existentes e jamais a de que o programa em questo est correto.
Conforme Martin (1991), um programa exaustivamente testado se ele executado
com todos os possveis conjuntos de dados de entrada. A aplicao de testes exaustivos pode
garantir a validade de um programa, mas para a maioria dos programas isto no pratico
porque existe um nmero infinito ou incrivelmente grande de possveis conjuntos de entrada

6
de dados. Em vez disso, a correo de um programa usualmente demonstrada atravs do
teste de uma pequena amostra de exemplos cuidadosamente escolhidos.
A tarefa do responsvel pelo teste eliminar condies e falhas de programa
imprevistas e descobrir qualquer implementao das especificaes dos requisitos incorreta
ou incompleta, usando um conjunto razovel de exemplos de testes apropriados.
Embora tenha havido muita pesquisa para se desenvolver uma teoria de testes, so
poucos os resultados animadores. At agora, o teste ainda no tem uma base terica slida.
At mesmo em um ambiente estruturado, o teste orientado apenas por regras heursticas
como as que se seguem:
a) testar todos os comandos do programa e todos os caminhos pelo menos uma
vez;
b) testar minuciosamente as partes do programa mais importantes e mais
intensamente usadas;
c) testar os mdulos individualmente antes de serem combinados. Depois, testar
as interseces dos mdulos;
d) organizar o teste de modo que ele progrida dos exemplos de teste mais simples
aos mais complexos. Isto significa que os testes que envolvam lgica menos
complexa devem ser executados primeiro. Significa tambm que o
processamento normal com entradas vlidas deve ser testado antes de o
processamento excepcional ser checado;
e) calcular os resultados do teste antes de ele ser executado.
A realizao de um teste , em sua essncia, um conceito simples. Ele consiste em
selecionar o que dever ser medido (um atributo ou caracterstica do software); criar entradas
controladas ou situaes de teste (casos) que ponham prova ou revelem algo sobre o atributo
ou caracterstica que ser medida; simular ou executar as situaes de teste e analisar os
resultados, comparando-os a um padro ou comportamento esperado. Considera-se um teste
bem-sucedido quando os resultados observados atendem as expectativas, e mal-sucedido
quando isto no acontece, ou quando uma deficincia detectada.

7
Outra definio de teste dada por Hetzel (1987), de que teste processo de executar
um programa ou sistema com a finalidade de encontrar erros. Esta conceituao faz de
encontrar erros o objetivo principal, pois enfatiza que se nossa finalidade for mostrar que
um programa no tem defeitos, seremos inconscientemente levados a perseguir este objetivo;
ou seja, tenderemos a escolher uma massa de dados que reduza a probabilidade de ocasionar
erros. Por outro lado, se nosso objetivo for demonstrar que um programa tem defeitos, a
massa de dados ter uma grande probabilidade de encontrar erros, e o sucesso do teste ser
maior.
Segundo Fournier (1994), podem ser definidas duas categorias genricas de defeitos:
erros e ambigidades. Erros so falhas no software de aplicao que faro o sistema falhar ou
gerar resultados invlidos. Da, importante identificar o mximo possvel de erros durante o
ciclo de testes e elimin-los antes de entregar o sistema a seus clientes. Para conseguir isso, os
testes devem ser vistos como um processo destrutivo, que executado com a inteno de
encontrar erros.

2.2 REALIZAO DOS TESTES


Na maioria das empresas e para a maioria dos profissionais, a triste realidade a de
que a resposta para o que testar e quando terminar no resultam da aplicao de uma
metodologia sistemtica de teste. As abordagens aleatrias e individualizadas predominam.
comum encontrar dentro de uma mesma empresa uma gama enorme de tcnicas e filosofias
de teste principalmente nas fases iniciais do processo. A experincia tem mostrado que
polticas e padres de teste de software definindo como o trabalho deve ser conduzido, o que
deve ser testado, quem responsvel, e acompanhando a efetividade e o custo dos testes so
coisas raras e no existem em mais de dez por cento das empresas.
De acordo com Fournier (1994), a estratgia preliminar para testar um sistema
inicialmente desenvolvida durante a fase de anlise detalhada. Os principais objetivos do
processo global de teste so definidos com os usurios e devem cobrir os quatro nveis de
teste - os ciclos de teste de unidade, integrao de sistemas, aceitao pelo usurio e a
aceitao pela produo, onde for aplicvel. Outras questes relacionadas com os papis e
responsabilidade de cada grupo envolvido no processo de teste tambm discutidas. Por
exemplo, durante essa fase, tomada a deciso de permitir que a equipe de desenvolvimento

8
execute o processo de teste de integrao de sistemas, em vez de atribu-lo a uma equipe
independente. Durante a fase de projeto, desenvolvida a estratgia detalhada de teste com a
criao de casos de teste efetivos. Finalmente, o ciclo formal de testes oficialmente ativado
durante a fase de implementao. Uma significativa vantagem dessa abordagem o fato de
que o processo de teste de software fica completamente integrado ao ciclo do
desenvolvimento do sistema. Tambm o teste no mais visto como uma atividade que ocorre
somente aps os programas terem sido codificados. Em vez disso, as atividades preparatrias
de teste acontecem em paralelo com as atividades de anlise detalhada (estratgia de teste de
nvel mais alto) e com as atividade de projeto (estratgia de teste detalhada e preparao dos
casos de teste). Essa mudana de foco para os estgios iniciais do processo de
desenvolvimento de software tambm permite que o gerente de desenvolvimento realce certas
questes de teste muito importantes par a administrao tempo necessrio para testar o
sistema de forma apropriada, necessidade de usar ferramentas automatizadas de teste, custos
globais dos testes do sistema e a disponibilidade de recursos de computao adequados para
executar o processo de testes.
Segundo Paula Filho (2001), a atividade de testes uma etapa crtica para o
desenvolvimento de software. Freqentemente, a atividade de testes insere tantos erros em um
produto quanto a prpria implementao. Por outro lado, o custo para correo de um erro na
fase de manuteno de sessenta a cem vezes maior que o custo para corrigi-lo durante o
desenvolvimento. Embora as revises tcnicas sejam mais eficazes na deteco de defeitos, os
testes so importantes para complementar as revises e aferir o nvel de qualidade
conseguido. A realizao de testes , quase sempre, limitada por restries de cronograma e
oramento. importante que os teste sejam bem planejados e desenhados, para conseguir-se o
melhor proveito possvel dos recursos alocados para eles.
De acordo com Pressman (1995), a atividade de teste um elemento crtico da garantia
de qualidade de software e representa a ltima reviso de especificao, projeto e codificao.
A atividade de teste constitui uma anomalia interessante para o engenheiro de software.
Durante as fases de definio e desenvolvimento anteriores, o engenheiro tenta construir o
software, partindo de um conceito abstrato para uma implementao tangvel. Agora, surge a
fase de testes. O engenheiro cria uma srie de casos de teste que tem a inteno de demolir
o software que ele construiu. De fato, a atividade de teste um passo do processo de

9
engenharia de software que poderia ser visto(psicologicamente, pelo menos) como destrutivo,
em vez de construtivo. Os desenvolvedores de software so, por sua prpria natureza, pessoas
construtivas. A atividade de teste exige que o desenvolvedor descarte noes preconcebidas
da corretitude do software que ele acabou de desenvolver e supere um conflito de interesses
que ocorre quando erros so descobertos.
A maioria das empresas realiza pelo menos trs tipos distintos de testes. Os programas
so testados isoladamente e depois grupos de programas so testados num teste de sistema.
Sistemas completos so, por fim, submetidos a um teste de aceitao. Pessoas e equipes
diferentes podem encarregar-se de cada um desses nveis, sendo os testes de aceitao feitos,
geralmente, pelo cliente ou usurio final. Em projetos maiores e mais complexos, outros
nveis de teste podem ser utilizados.
Segundo Maldonado (1997), o processo de software possui trs metas principais:
a) verificar que o software executa como especificado na documentao do projeto;
b) verificar que o software satisfaz todos os requisitos especificados na Especificao
de Requisitos de Software; e
c) fornecer um status do progresso do projeto ao gerente do projeto.
Nesse estgio, vrias estratgias, mtodos e tcnicas de teste podem ser utilizadas, nas
diversas fases de teste: teste de unidade, teste de integrao, teste de sistema e teste de
aceitao.
Segundo Mueller (1998), teste o processo de garantir que um programa se adapta aos
requisitos da especificao e funciona em todos os casos em que se espera que funcione.
O teste consiste em:
a) selecionar um conjunto de dados de entrada com os quais se executar o
programa;
b) determinar a sada que se espera ser reproduzida;
c) executar o programa;
d) analisar os resultados produzidos pela execuo do programa.

10
Conforme Pressman (1995), a atividade de teste de software um elemento crtico da
garantia de qualidade de software e representa a ltima reviso de especificao, projeto e
codificao.
O objetivo projetar testes que descubram sistematicamente diferentes classes de erros
e faam-no com uma quantidade de tempo e esforo mnimos. Se a atividade de teste for
conduzida com sucesso, de acordo com o objetivo estabelecido, ela descobrir erros no
software.
Muller (1998) estabelece uma srie de regras que podem servir bem como objetivos de
teste:
a) a atividade de teste o processo de executar um programa com a inteno de
descobrir erro;
b) um bom caso de teste aquele que tem uma elevada probabilidade de revelar
um erro ainda no descoberto;
c) um teste bem sucedido aquele que revela um erro ainda no descoberto.
Sempre que vai se iniciar um teste, vem a pergunta onde testar? A resposta para esta
pergunta depende da metodologia aplicada para a execuo dos testes. Para os primeiros
testes (teste de unidade e teste de integrao), sugere-se que eles devem ser executados no
ambiente de desenvolvimento (sendo o teste de sistema executado em ambiente alvo em
condies reais de operao), no entanto nada impede que em contrato seja estabelecido que
ele tambm seja executado no ambiente de desenvolvimento, mas sob superviso do cliente.
Outra pergunta que sempre feita quando se inicia um teste, at quando testar?
Corrigir todos os erros de um software anti-produtivo, anti-realista, pois pode levar muito
tempo para fazer o trabalho de correo, e o mesmo perder seu lugar no mercado. Para um
produto possuir um nvel de qualidade aceitvel, o mesmo deve possuir taxas de erros
menores que dez por cento. Pode-se utilizar para medir taxas de erros tcnicas de estimativas
de custos. Tem-se como exemplo a Anlise por Pontos de Funo (FPA), onde para um
determinado nmero de pontos de funes estima-se um determinado nmero de erros,

11
buscando encontrar 90% dos erros estimados. Esta estimativa vai sendo aprimorada medida
que o histrico de desenvolvimento e testes de software da organizao vai evoluindo.

2.3 TIPOS DE TESTE DE SOFTWARE


Um produto software pode ser testado utilizando-se algumas tcnicas, sendo duas as
mais usadas: quando se conhece as funes que foram especificadas para o software executar,
o teste pode ser conduzido para demonstrar a operacionalidade das funes; e quando se
conhece a estrutura interna do software, o teste pode ser conduzido para verificar se todos os
componentes internos, quando exercitados, operam de maneira adequada. Essas duas tcnicas
so conhecidas, respectivamente, como Teste Caixa Preta ou Funcional e Teste Caixa Branca
ou Estrutural.
Teste Caixa-Preta ou Funcional segundo Pressman (1995), os mtodos deste tipo de
teste concentram-se nos requisitos funcionais do software. Ou seja, esse teste possibilita que o
engenheiro de software derive conjuntos de condies de entrada que exercitem
completamente todos os requisitos funcionais para um programa. O teste de caixa preta no
uma alternativa para as tcnicas de caixa branca. Ao contrrio, trata-se de uma abordagem
complementar que tem a probabilidade de descobrir uma classe de erros diferente daquela dos
mtodos de caixa branca. O teste de caixa preta procura descobrir erros nas seguintes
categorias: (1) funes incorretas ou ausentes; (2) erros de interface; (3) erros nas estruturas
de dados ou no acesso a bancos de dados externos; (4) erros de desempenho; e (5) erros de
inicializao e trmino. Ao contrrio do teste de caixa branca, que executado cedo no
processo de teste, o teste de caixa preta tende a ser aplicado durante as ltimas etapas da
atividade de teste, uma vez que o teste de caixa preta deliberadamente desconsidera a
estrutura de controle, a ateno se concentra no domnio da informao.
Teste Caixa-Branca ou Estrutural segundo Pressman (1995), um mtodo de projeto
de casos de teste que usa a estrutura de controle do projeto procedimental para derivar casos
de teste.
Usando mtodos de teste de caixa branca, o engenheiro de software pode derivar os
casos de teste que (1) garantam que todos os caminhos independentes dentro de um mdulo
tenham sido exercitados pelo menos uma vez; (2) exercitem todas as decises lgicas para

12
valores falsos ou verdadeiros; (3) executem todos os laos em suas fronteiras e dentro de seus
limites operacionais; e (4) exercitem as estruturas de dados internas para garantir a sua
validade.
Segundo Rocha (2001), o teste de caixa branca estabelece os requisitos de teste com
base em uma determinada implementao, verificando se atende aos detalhes do cdigo e
solicitando a execuo de partes ou de componentes elementares do programa. Os critrios
pertencentes a essa tcnica so classificados com base no fluxo de controle, no fluxo de dados
e na complexidade.
De acordo com Inthurn (2001), o teste estrutural tem como objetivo verificar se a
estrutura interna da unidade est correta. Esta verificao efetuada atravs de casos de teste
que visam percorrer todos os caminhos internos possveis da unidade e percorrer todos os
caminhos.

2.4 TESTE FUNCIONAL


De acordo com Mueller (1998), o teste funcional tambm conhecido como teste
caixa preta pelo fato de tratar o software como uma caixa cujo contedo desconhecido e da
qual s possvel visualizar o lado externo, ou seja, os dados de entrada fornecidos e as
respostas produzidas como sada. Na tcnica de teste funcional so verificadas as funes do
sistema sem se preocupar com os detalhes de implementao.
Segundo Maldonado (1998), o teste funcional envolve dois passos principais:
identificar as funes que o software deve realizar e criar casos de teste capazes de checar se
essas funes esto sendo realizadas pelo software. As funes que o software deve possuir
so identificadas a partir de sua especificao. Assim, uma especificao bem elaborada e de
acordo com os requisitos do usurio essencial para esse tipo de teste.
Segundo PUCRS, testes caixa-preta so aqueles que encaram o sistema a ser testado
como uma funo que mapeia um conjunto de valores de entrada em um conjunto de valores
de sada sem se preocupar com a forma como esse mapeamento foi implementado. Testes
caixa-preta baseiam-se exclusivamente na especificao de requisitos para determinar que
tipo de sadas so esperadas para um determinado conjunto de entradas.

13
Inicialmente sero apresentadas as tcnicas de teste caixa-preta tradicionais
individualmente. Ao final deste captulo ser apresentado um modelo de plano de testes, bem
como uma estratgia de aplicao das tcnicas apresentadas.

2.4.1 TIPOS DE TESTE FUNCIONAL


Sero apresentados a seguir alguns tipos de teste funcional: teste de valor limite,
generalizando a tcnica de valor limite, limites da anlise de valor limite, teste de robustez,
teste de pior caso, testes a partir dos resultados

2.4.1.1

TESTE DE VALOR LIMITE

A tcnica de teste de valor limite a mais simples das tcnicas tradicionais. Assim
como as demais tcnicas caixa-preta, explora a natureza funcional de um programa para
identificar casos de teste.
Considere como exemplo um programa com 2 variveis, x1 e x2, com limites
claramente determinados:
a <= x1 <= b
c <= x2 <= d
A tcnica de anlise do valor limite foca os limites dos espaos de entrada de maneira
a determinar casos de teste. Este princpio parte da observao de que os erros costumam
ocorrer prximos dos valores limites das variveis de entrada.
A idia bsica da tcnica usar os valores de entrada no seu mximo, logo abaixo do
mximo, um valor nominal, logo acima do mnimo e o valor mnimo para gerar casos de teste.
Normalmente estes valores so nomeados: MIN, MIN+, NOM, MAX-, MAX.
Alm disso, a tcnica do valor limite baseia-se na idia de que uma falha dificilmente
tem origem em mais de um erro. Por esta razo os casos de teste so, em geral, obtidos
fixando-se os valores de todas as variveis de entrada menos uma, em seus valores nominais,
deixando que a varivel escolhida assuma seus valores extremos. Para o caso do exemplo, os
casos de teste seriam: {<x1nom, x2min>, <x1nom, x2min+>, <x1nom, x2nom>, <x1nom,
x2max->,x1nom,x2max+>, <x1min, x2nom>, <x1min+, x2nom>, <x1max-, x2nom>,
<x2max, x2nom> }.

14

2.4.1.1.1

GENERALIZANDO A TCNICA DE VALOR LIMITE

A tcnica bsica de anlise de valor limite pode ser generaliza de duas formas:

pelo nmero de intervalos

pelo tipo dos intervalos


Generalizar pelo nmero de intervalos fcil. Para uma funo de n variveis teremos

4n+1 casos de teste. Generalizar pelo tipo depende da natureza das variveis. Em alguns
casos pode ser necessrio usar enumeraes (exemplo: meses do ano). Em outras situaes as
variveis no tem limites discretos bem definidos (como no problema do tringulo). Neste
caso limites artificiais tem de ser criados. No caso do problema do tringulo pode-se assumir,
por exemplo, que o menor lado admitido 1 e que o maior MAXINT (ou o maior inteiro
possvel de ser representado). Anlise de valor limite no faz sentido, por exemplo, em
variveis booleanas.

2.4.1.1.2

LIMITES DA ANLISE DE VALOR LIMITE

Anlise de valor limite funciona bem quando o programa a ser testado uma funo de
varias variveis independentes que representam conjuntos que tenham uma relao de
ordem, como por exemplo, quantidades fsicas. Anlise de valor limite preocupa-se apenas
com os limites extremos das variveis analisadas de forma independente, no levando em
considerao a semntica das mesmas.
Por exemplo, em uma aplicao que lida com temperatura e presso, extremamente
til testar o que acontece com o programa de controle de uma caldeira quando a temperatura e
presso chegam prximas aos valores limites. J em um programa que lida com nmeros de
telefone, qual seria a utilidade de testar os casos: { 0000, 0001, 9998, 9999}?
A anlise de valor limite a mais limitada e rudimentar das tcnicas de gerao de
casos de teste e por esta razo os casos de teste gerados so igualmente limitados e
rudimentares.

15

2.4.1.2

TESTE DE ROBUSTEZ

Teste de robustez uma simples extenso do teste de valor limite que procura analisar
o que ocorre quando os valores previstos para uma varivel superam ligeiramente o limite
superior (max+) ou ficam ligeiramente abaixo do limite inferior (min-). Neste caso termos
6n+1 casos de teste.
A principal diferena nesse caso diz respeito aos resultados esperados. Exemplo: o que
acontece se o avio exceder o ngulo de aproximao? o que acontece se o elevador estiver
com excesso de carga? o que acontece se o tamanho do arquivo for maior que o tamanho do
disco?

2.4.1.3

TESTE DO PIOR CASO

A anlise do valor limite verifica as variveis isoladamente. O teste do pior caso esta
interessado em verificar o que ocorre quando mais de uma varivel pode assumir valores
extremos simultaneamente. Para tanto consideramos os 5 valores assumidos para cada
varivel no teste de valor limite (min,min+,nom,max-,max) e montamos o produto cartesiano
destes valores. Para n variveis teremos, ento, 5n casos ao invs de 4n+1.
Para as situaes de extrema parania pode-se usar o teste de robustez para o pior caso.
Nessa situao faz-se o produto cartesiano dos valores selecionados para o teste de robustez.
Sendo assim, para n variveis sero 7n testes.

2.4.1.4

TESTANDO A PARTIR DOS RESULTADOS

Existem algumas situaes onde o teste de valor limite (e suas variaes) pode ser
aplicado com melhores resultados se os intervalos de entrada forem definidos com base nas
condies que determinam os valores de sada. Consideremos a seguinte situao: "... o
clculo do desconto por dependente feito da seguinte forma: a entrada a idade do
dependente que deve estar restrita ao intervalo [0; 24]. Para dependentes at 12 anos
(inclusive) o desconto de 15%. Entre 12 e 18 (inclusive) o desconto de 12%. Dos 18 aos
21 (inclusive) o desconto de 5% e dos 21 aos 24 de 3%...".
Aplicando o teste de valor limite convencional sero obtidos casos de teste
semelhantes a este: {0,1,12,23,24}. Mesmo usando o teste de robustez (por se tratar de apenas

16
uma varivel de entrada o teste do pior caso no faz sentido) os valores de teste seriam: {1,0,1,12,23,24,25}.
Note que com estes valores no possvel testar se o programa funciona corretamente.
O primeiro e o ltimo valores correspondem a valores fora de faixa. O segundo e o terceiro
valor testam a primeira faixa de desconto. O quarto valor testa a segunda faixa de desconto e
o quinto e o sexto valores testam a quarta faixa de desconto. Note que no foi gerado nenhum
caso de teste para a terceira faixa de desconto, nem os limites destas faixas esto sendo
testados.
Para resolver esse problema podemos subdividir o intervalo da varivel de entrada de
acordo com as sadas possveis. Desta forma teramos os seguintes intervalos para analisar:
{[0;12], (12;18], (18;21], (21;24] }. Aplicando o teste convencional obteremos os seguintes
casos de teste: {0,1,6,11,12,15,17,18,19,20,21,22,23,24 }. Observe que agora todos as faixas
de desconto esto sendo testadas.

2.5 GERENCIAMENTO DOS TESTES


De acordo com Pressman (1995), em cada projeto de software, h um conflito de
interesses inerente que acontece quando o teste se inicia. As pessoas que construram o
software agora so solicitadas a testar o software. Isso parece inofensivo em si mesmo, afinal
de contas, quem conhece melhor o programa do que seus desenvolvedores? Infelizmente,
esses mesmos desenvolvedores tem interesses subliminares de demonstrar que o programa
isento de erros, que ele funciona de acordo com as exigncias do cliente e que ele ser
concludo no prazo e dentro do oramento. Cada um desses interesses provoca um
abrandamento no sentido de descobrir erros ao longo do processo de testes.
Freqentemente, h uma srie de interpretaes errneas que podem ser
equivocadamente inferidas da discusso anterior:
a) que de modo algum o desenvolvedor de software deve testar;
b) que o software deve ser jogado sobre o muro a estranhos que o testaro
impiedosamente;

17
c) que os responsveis pelo teste se envolvero com o projeto somente quando os
passos de teste estiverem prestes a se iniciar.
Cada uma das observaes incorreta.
A equipe de desenvolvimento do software sempre responsvel por testar as unidades
individuais (mdulos) do programa, para garantir que cada uma execute a funo para a qual
foi projetada. Em muitos casos, a equipe de desenvolvimento tambm realiza testes de
integrao a etapa de teste que leva construo (e teste) da estrutura de programa
completa. S depois que a arquitetura de software est completa que um grupo de teste
independente envolve-se.
Porm, a equipe de desenvolvimento do software no joga o programa para o grupo
independente de teste (Independent Test Group ITG) e afasta-se. A equipe de
desenvolvimento e o ITG trabalham estreitamente unidos ao longo do projeto de software a
fim de garantir que testes cuidadosos sejam levados a efeito. Enquanto a atividade de teste
realizada, a equipe de desenvolvimento deve estar disposio para corrigir erros que sejam
descobertos.
Segundo Hetzel (1987), a maioria dos conhecedores de tcnicas gerenciais concordaria
que so muitos os enfoques e estilos possveis. O melhor enfoque em grande parte fruto
de preferncias individuais, sendo a personalidade e o estilo de comportamento (como o
indivduo influencia as pessoas) os dois fatores crticos para o sucesso. Entretanto, alm dos
aspectos pessoais, h obrigaes e responsabilidades que todo gerente deve assumir de modo
a gerenciar os testes com eficincia.
At aqui, tem-se considerado os testes sob um ponto de vista estritamente tcnico.
Quase no se d ateno aos aspectos gerenciais. O que sabemos sobre o papel da gerncia em
qualquer empreendimento? Em termos simples, a misso da gerncia obter resultado atravs
do trabalho dos outros. Muito j se escreveu sobre os motivos que levam alguns gerentes a
conseguir tanto e outros to pouco. As responsabilidades bsicas so sempre as mesmas.
Praticamente toda a atividade gerencial pode ser agrupada em uma dessas trs esferas amplas
de influncia.

18
A esfera de liderana exige que se apontem os caminhos e se motivem os indivduos
em busca de metas comuns. Incluem-se aqui a definio de objetivos, expectativas e planos. A
esfera de controle concentra-se nos procedimentos que fazem a empresa permanecer no
caminho traado. Ela envolve a monitorao, o follow-up, os relatrios, as avaliaes e o
redirecionamento. A esfera de suporte trata de instrumentos que facilitem o desempenho dos
funcionrios. Ela engloba o treinamento, os mtodos de trabalho, as ferramentas disponveis e
assistncia em geral.
Normalmente, ser preciso empreender um programa de ao equilibrado, abrangendo
as trs esferas para que se obtenham progressos significativos ou duradouros na organizao.
Um exemplo simples: seria obviamente ineficaz tentar implantar uma nova tcnica de teste
(ou qualquer outra tcnica), fornecendo apenas treinamento e suporte tcnico, sem nenhum
envolvimento pessoal, mantendo-se apenas uma esperana otimista de que a nova tcnica
tome de assalto, por milagre, todo o departamento de processamento de dados. Sem exceo,
fundamental a presena de uma liderana ativa e de controles efetivos paralelamente ao
suporte/apoio para que as melhorias desejadas possam ser obtidas. O conceito de programa
de ao equilibrado em todas as trs esferas pressupe que a gerncia disponha de
responsabilidades concretas de liderana e controle (alm de incumbncia restrita de contratar
profissionais e assisti-los de todas as maneiras possveis) que devam ser cumpridas e cobradas
para que seja possvel introduzir e consolidar mtodos de teste eficazes.
Conforme Mueller (1998), as atividades de testes devem ser iniciadas no momento em
que a equipe de desenvolvimento achar conveniente dentro de cada fase do ciclo de vida.
Durante o processo de testes uma srie de pessoas participam de diversas atividades:
a) Gerente de projeto: o agente responsvel pelos assuntos administrativos
relativos ao desenvolvimento do projeto.
b) Gerente Tcnico de Projeto: o agente responsvel pela conduo dos
assuntos tcnicos relativos ao desenvolvimento do projeto.
c) Equipe de teste: o grupo formado por elementos responsveis pela conduo
dos testes e pela garantia de qualidade do projeto.

19
d) Analista: o agente responsvel pelo desenvolvimento ou manuteno dos
mdulos automatizados do sistema de informao.
e) Programador: o agente responsvel pela construo e teste das unidades e
suas adequaes ao projeto fsico.
Figura 1 - Fluxograma do pessoal envolvido com a atividade de testes

Gerente
de projeto

Gerente tcnico
de projeto

Equipe de

Analistas

Programador

Fonte: Mueller (1998)


Teste

2.6 CHECKLIST
Segundo Rocha (2001), dentre as atividade de garantia de qualidade de software esto
as de VV&T (Verificao, Validao e Teste), com o objetivo de minimizar a ocorrncia de
erros e risco associados. O objetivo da verificao assegurar que o software, ou uma
determinada funo do mesmo, esteja sendo implementado corretamente. Verifica-se,
inclusive, se os mtodos e processos de desenvolvimento forma adequadamente aplicados. As
atividade de VV&T envolvem atividades de anlise esttica e de anlise dinmica do produto
em desenvolvimento, que podem ser realizadas de maneira manual ou automatizada,
dependendo da disponibilidade de ferramenta de apoio.
A anlise esttica no envolve a execuo propriamente dita do produto e visa
determinar propriedade do produto vlidas para qualquer execuo do produto final. Na
realidade, a anlise esttica pode e deve ser aplicada em qualquer produto intermedirio do
processo de desenvolvimento. Por exemplo, em nvel de especificao com base em
statecharts. Utilizando-se o conceito de rvore de alcanabilidade, seria possvel verificar se a
especificao consistente, se o produto no tem deadlock etc. revises tcnicas so o

20
exemplo mais clssico de anlise esttica. As revises tem um processo subjacente e devem
ser sistemticas e planejadas. Em geral so conduzidas com base em uma checklist (lista de
verificao ou conferncia) adequada a cada fase ou produto.
A anlise dinmica tambm tem por objetivo detectar defeitos ou erros no software e
envolve a execuo do produto, seja o cdigo propriamente deito ou mesmo uma
especificao executvel. As atividades de simulao e teste constituem uma anlise dinmica
do produto. O teste um elemento usado para fornecer evidncias da confiabilidade do
software em complemento a outras atividades, como o uso de revises e de tcnicas formais e
rigorosas de especificao e de verificao, sendo relevante para a identificao e eliminao
de erros que persistem no software.
Na essncia, as tcnicas de VV&T tem por objetivo identificar a presena de defeitos
ou erros o mais cedo possvel no processo de desenvolvimento e aprender com essa atividade
e evoluir o processo de desenvolvimento, inclusive pela prpria evoluo das tcnicas de
VV&T utilizadas na empresa.

2.7 PROCESSO DE TESTE


O processo de teste antes da implantao deste sistema era feito da seguinte forma:

As rotinas so desenvolvidas pelos programadores e repassadas junto com a


SMS correspondente para o suporte tcnico, para fazer os testes destas rotinas;

O suporte tcnico faz os testes e se ocorrem erros, devolvida a SMS para o


programador indicando o erro que aconteceu;

Enquanto o suporte tcnico no indicar que a rotina est correta, a SMS fica
sendo passada para o programador e do programador para o suporte tcnico.

O processo de teste depois da implantao deste sistema feito da seguinte forma:

As rotinas so desenvolvidas pelos programadores e repassadas junto com a


SMS para o controle de qualidade, para fazer os testes destas rotinas;

21

O controle de qualidade faz os testes e se ocorrem erros, devolvida a SMS


para o programador indicando o erro que aconteceu;

Enquanto o controle de qualidade no indicar que a rotina est correta, a SMS


fica sendo passada para o programador e do programador para o controle de
qualidade.

22

3 DESENVOLVIMENTO DO TRABALHO
Neste captulo sero descritas as atividades desempenhadas em cada fase do modelo de
desenvolvimento de software adotado para construo do trabalho. Tambm sero
relacionados e discutidos os resultados obtidos a partir do mesmo.

3.1 REQUISITOS DO PROBLEMA


Os testes na empresa Benner Sistemas S/A so feitos pelos programadores, que so
verificaes bsicas do sistema, como valores aceitos por um determinado campo. Aps o
trmino do desenvolvimento feita a liberao do programa para que o suporte tcnico das
reas de recursos humanos e corporativo da empresa, que alm de darem suporte a clientes
Benner fazem os testes de processos do sistema, como integrao entre os mdulos, processos
executados pelo sistema como folha de pagamento. Com o nmero crescente de clientes, o
suporte estava ficando com pouco tempo para testar os sistemas, ocasionando muitas vezes a
verificao de erros apenas quando o sistema j esta no cliente, causando um grande problema
para a empresa, pois deveria liberar uma correo para uma verso quem no tinha nem sido
comeado a usar.
Com a verificao deste problema e o crescimento acelerado da Benner, verificou-se
que deveria se ter uma rea ou pessoa na empresa que se dedicasse integralmente ao teste dos
sistemas Benner em cada rea da empresa. A partir disto surgiu idia de realizar um estgio
na rea de teste de software.
Foram feitas reunies semanais entre este autor, o Sr. Roger Wetzel, que o
responsvel pelos treinamentos dos clientes para a utilizao do sistema de Recursos
Humanos e que ir utilizar o sistema de gerenciamento de testes neste setor e a Srta. Regiani
Dalfovo, que a responsvel pelos treinamentos dos clientes para a utilizao do sistema
Corporativo e que ir utilizar o sistema de gerenciamento de testes neste setor. Nas primeiras
reunies foi definida a interface do programa, utilizando a ferramenta Benner Builder para a
definio das tabelas do programa. Com o passar das reunies o software foi tomando forma
com a utilizao da ferramenta Benner Runner para fazer a interface do software, como
mostra o fluxograma da figura 2.

23
Figura 2 Fluxograma

Cadastrar
Sistemas
Cadastrar
Checklist de
entrada

Cadastrar
verses

Cadastrar
Releases

Houve
erro?
N

Cadastrar
Mdulos/Dlls

Cadastrar
Rotinas

Cadastrar
Processos

Corrige
erro

Cadastrar
Checklist
de sada

Houve
erro?

N
Cadastrar
Checklists

Fim

Cadastrar
SMS

3.2 ANLISE DOS REQUISITOS


O fluxograma mostra que o sistema necessitar dos cadastros dos sistemas da Benner,
das verses desses sistemas, das releases dessas verses, os mdulos de cada sistema, as
rotinas de cada mdulo, os processos que so envolvidos por essas rotinas e por fim os
checklists que possuem uma descrio bsica do processo e o cadastro do checklist de entrada
e de que contm os dados de entrada e de sada que sero utilizados para este teste. Se ocorrer

24
um erro, ser cadastrada uma SMS, que indica ao analista ou programador responsvel por
aquele mdulo ou rotina que ele tem um erro para corrigir e devolver a SMS ao testador que
ir verificar se o erro foi corrigido. A SMS o nome dado ao cadastro de um erro que
aconteceu no sistema, no cadastro da SMS indicado o programador, o sistema, o cliente, a
verso do cliente e um resumo do erro que aconteceu.
O sistema de gerenciamento de teste funcional ser um mdulo do Sistema de
Controle das atividades SisCon para ficar integrado com os sistemas utilizados por todos
os diretores, programadores e clientes da Benner. O sistema que esta sendo desenvolvido ser
utilizado e visualizado apenas pelos diretores e pelos testadores.
O sistema de gerenciamento de teste funcional no primeiro momento, ser utilizado
para o gerenciamento apenas dos sistemas de Recursos Humanos e Corporativo, pois so os
sistemas Benner mais utilizados, passando a ser utilizado em todos os sistemas de acordo com
a necessidade da empresa.
O sistema de gerenciamento de teste funcional, o primeiro passo para a implantao
do setor de qualidade de sistemas na empresa, pois a partir deste devero ser desenvolvidos
mais sistemas que auxiliaro os funcionrios que iro testar os sistemas.

3.3 ESPECIFICAO
Esta seo descreve os diagramas para a especificao do software, apresentando o
diagrama de casos de uso, diagrama entidade relacionamento (DER) e o dicionrio de dados.
Utilizou-se para a especificao do prottipo a ferramenta CASE ErWin e o Rational Rose.
Para o desenvolvimento do sistema, utilizou-se o padro de formulrios, botes, cargas
dos sistemas Benner. Em todas as tabelas dos Sistemas Benner possui um campo chamado
handle, que o campo de ligao entre as tabelas.

3.3.1 DIAGRAMA DE CASOS DE USO


O caso de uso identifica e esquematiza graficamente e descreve o comportamento do
sistema. Estes diagramas apresentam uma viso geral nivelada de como o sistema usado, na
perspectiva de um estranho (ator). Este diagrama pode descrever alguns ou todos os casos de

25
uso de um sistema. Na Figura 3 esto representados os casos de uso implementados no
prottipo do trabalho.
Figura 3 - Diagrama de casos de uso

A principal figura ou ator referenciado como testador, ele que far entradas e
receber os resultados em forma de relatrio. Para que seja possvel atender todas as
necessidades do testador, foram criados os seguintes casos de uso:
Cadastrar Tabelas: Este caso trata das informaes cadastrais do aplicativo, atravs
destes cadastros ser possvel partir para os prximos passos do aplicativo. As tabelas
utilizadas para este caso so: Sistemas, Verses, Releases, Mdulos, Rotinas, Atividades,
RotinaProcessos, Checklists, ChecklistEntrada e ChecklistSada.
Realizar Testes: Trata da realizao dos testes, utilizando os checklists que foram
cadastrados. O testador poder realizar os testes baseados em documentos com print-screens
das telas do processo que estar sendo testado.
Gerar SMS: Trata do cadastro de erros encontrados no teste. A SMS ser encaminhada
ao responsvel do mdulo que dever corrigir o erro relatado e devolver a mesma para o
testador, a fim deste verificar se o erro foi corrigido realmente.
Gerar Relatrio de SMSs: Utilizar as tabelas de movimento e cadastro, para gerar o
comparativo gerencial de apontamento de resultados das mtricas.

26

3.3.2 DIAGRAMA ENTIDADE RELACIONAMENTO


O diagrama entidade relacionamento (DER), enfatiza os principais objetivos ou
entidades do sistema e seus relacionamentos.
Como se pode observar, todas as tabelas possuem um campo handle, que na Benner o
campo que indica o registro da tabela, que serve para fazer a ligao entre as tabelas, como
por exemplo, de uma tabela de clientes fosse o cdigo do cliente. Tambm pode-se observar
que todas as entidades possuem obrigatoriedade com relao entidade principal, que a
tabela de sistemas, permitindo um relacionamento de 1 para N ou 1 para 1, ou seja, torna-se
obrigatrio existir um registro pai para que se cadastre um ou mais registros na entidade filho,
como mostrado na figura 4.

3.3.3 DICIONRIO DE DADOS


O dicionrio de dados contm a definio de todos os dados mencionados no DER, as
entidades e seus atributos, incluindo detalhes do formato fsico, como: tipo, tamanho, chave e
descrio do atributo. Gerou-se um relatrio na ferramenta CASE ErWin, utilizada para o
desenvolvimento da modelagem, atravs dos Scripts. No anexo 1 esto descritos as tabelas de
cada entidade com seus respectivos atributos, a primeira coluna mostra o nome das tabelas, a
segunda coluna mostra as campos das tabelas, a terceira coluna mostra o tipo do campo e a
quarta coluna indica se o campo ou no foreign-key.

27
Figura 4 Diagrama entidade relacionamento

28

3.4 IMPLEMENTAO
A seguir so apresentadas as principais telas disponveis para utilizao passo a passo
do prottipo. Com intuito de facilitar a demonstrao e compreenso, ser realizado um teste
do sistema de recursos humanos da Benner Sistemas, que o sistema utilizado para o
gerenciamento dos dados cadastrais e da folha de pagamento dos funcionrios.

3.4.1 MENU PRINCIPAL


Ao executar o aplicativo, ser apresentada a tela de abertura do sistema,
disponibilizando acesso aos demais recursos do prottipo, conforme figura 5.
Figura 05 Tela de abertura

No formulrio indicado na figura 6, sero cadastrados os sistemas Benner que sero


testados utilizando o sistema de gerenciamento. Os sistemas esto cadastrados na tabela
SIS_SISTEMAS, que uma tabela j existente no Sistema de Controle da Benner. A tabela
que conter os dados referentes aos sistemas a tabela QUA_SISTEMAS.

29
Figura 06 Tela de cadastro de sistemas

No formulrio indicado na figura 7, sero cadastrados as verses dos sistemas Benner


que sero testados. As verses esto cadastradas na tabela SIS_VERSOES, que uma tabela
j existente no Sistema de Controle da Benner. A tabela que conter os dados referentes as
verses a QUA_VERSOES.
Figura 07 Tela de cadastro de verses

30
No formulrio indicado na figura 8, sero cadastradas as releases de verses dos
Sistemas Benner que sero testados. A tabela que conter os dados referentes as releases do
sistema a QUA_RELEASES.
Figura 08 Tela de cadastro de releases

No formulrio indicado na figura 9, sero cadastrados os mdulos dos sistemas Benner


que

sero

testados.

Os

mdulos

dos

sistemas

esto

cadastrados

na

tabela

SIS_SISTEMAMODULOS, que uma tabela j existente no Sistema de Controle da Benner.


A tabela do sistema que conter os dados referentes ao mdulos a QUA_MODULOS.
Figura 09 Tela de cadastro de mdulos

31
No formulrio indicado na figura 10, sero cadastradas as rotinas dos sistemas Benner
que sero testadas. A tabela do sistema que conter os dados referentes as rotinas a
QUA_ROTINAS.
Figura 10 Tela de cadastro de rotinas

No formulrio indicado na figura 11, sero cadastrados os processos das rotinas dos
sistemas Benner que sero testadas. A tabela do sistema que conter os dados referentes aos
processos a QUA_ROTINAPROCESSOS.
Figura 11 Tela de cadastro de processos

32
No formulrio indicado na figura 12, ser cadastrado o checklist com uma descrio
bsica do que ser testado nos sistemas Benner. A tabela do sistema que conter os dados
referentes aos checklists a QUA_CHECKLISTS.
Figura 12 Tela de cadastro de checklists

No formulrio indicado na figura 13, ser cadastrado o documento que conter a forma
como dever ser a entrada de dados para a execuo do teste. A tabela do sistema que conter
os dados referentes aos checklists de entrada a QUA_CHECKLISTENTRADA.
Figura 13 Tela de cadastro de checklists de entrada

33
No formulrio indicado na figura 14, ser cadastrado o documento que conter a forma
como dever ser a sada dos dados do teste. A tabela do sistema que conter os dados
referentes aos checklists de sada a QUA_CHECKLISTSAIDA.
Figura 14 Tela de cadastro de checklists de sada

No formulrio indicado na figura 15, ser cadastrado o documento que conter a forma
como dever ser a sada dos dados do teste. A tabela do sistema que conter os dados
referentes aos checklists de sada a QUA_PROCESSOSMS.
Figura 15 Tela de cadastro de SMSs do processo

34
No formulrio indicado na figura 16, ser cadastrado o documento que conter a forma
como dever ser a sada dos dados do teste. A tabela do sistema que conter os dados
referentes aos checklists de sada a SIS_ATIVIDADES.
Figura 16 Tela de cadastro de SMSs

No mdulo ADM sero cadastradas as figuras onde estaro os dados de entrada e de


sada do teste, como mostra a figura 17. Foi definido o seguinte padro para o nome das
figuras: que as figuras que iniciam com a letra E as figuras que contem a entrada de dados
para o teste e que as figuras que iniciam com a letra S as figuras que contem a sada dos
dados do teste. A tabela do sistema que conter os dados referentes aos documentos de sada
a SIS_AJUDADOCUMENTOS.

35
Figura 17 Tela de cadastro de documentos

Selecionando um documento, o usurio ir definir o checklist com figuras, pois desta


forma pode-se utilizar o teste tambm como documentao do sistema. Foi definido desta
forma, pois desta forma as informaes estariam gravadas junto com a base de dados do
sistema e poderiam ser utilizadas como help do sistema. O padro foi definido pelo usurio do
sistema de recursos humanos, pois este usurio o mesmo que faz a documentao e
treinamento deste sistema. O exemplo segue na figura 18.

36
Figura 18 Tela de exemplo de figura de teste cadastrada no sistema

3.4.2 CONSIDERAES SOBRE A IMPLEMENTAO


O banco de dados utilizado foi o MSSql verso 7.0, para a criao das tabelas do
sistema foi utilizada a ferramenta Benner Builder e para a gerao da interface foi utilizada a
ferramenta Benner Runner, que so ferramentas proprietrias da Benner Sistemas. Na figura
19 mostra-se a ferramenta Benner Builder.
Segundo Benner (2001), a ferramenta Benner Runner a ferramenta que apresenta a
interface dos sistemas Benner aos usurios, de acordo com as especificaes elaboradas no
Benner Builder.
Segundo Benner (2001), a ferramenta Benner Builder uma ferramenta de criao e
manuteno das estruturas de dados e interface com o usurio, que pode ser utilizada com os
principais bancos de dados do mercado. gil, fcil e permite atualizaes automticas de
bases de dados de clientes que tiveram seus sistemas modificados para atendimento de
caractersticas e peculiaridades.

37
No anexo 2 contm o script gerado pela ferramenta Benner Builder mostrando como
so gerados os dados da ferramenta para serem utilizados em outras bases de sistemas Benner.
Para a implementao da rotina que faz a cpia de testes que devem ser realizados em
toda verso de sistema que for liberada, foram utilizados alguns componentes padres da
linguagem Delphi 5.0, como os componentes Combo-box e label, e outros da Benner
Sistemas, como os botes para seguirem o padro Benner.
Para desenvolvimento do relatrio utilizou-se a ferramenta Benner Report de gerao
de relatrios proprietria da Benner Sistemas.
Figura 19 Tela da ferramenta Benner Builder

Segue abaixo uma tabela para fins de comparativo de SMSs geradas como correo
antes (at 10/2001) e aps (11/2001) a utilizao do sistema de gerenciamento de testes de
software:

38

Entrada

Todas

Correes

Melhoria

Verificaes

06/2001

83

44

14

25

07/2001

103

64

14

25

08/2001

123

64

27

32

09/2001

177

88

30

59

10/2001

253

107

80

66

11/2001

214

53

71

90

Fonte: Benner Sistemas S/A.

39

4 CONCLUSES
O objetivo do estgio foi alcanado visto que o prottipo atende as atividades de teste
funcional e estrutural pretendidas pela empresa, a partir de relatrios que a diretoria tem
acesso que apontaram uma reduo de cinqenta por cento atravs de um desses relatrios
mostra os erros encontrados pelos clientes nos sistemas. A verificao pode ser feita atravs
do relatrio semanal que a direo da empresa recebe com os erros encontrados pelos usurios
de todos os sistemas Benner, atravs da comparao do relatrio emitido anterior e aps o uso
do sistema de gerenciamento de teste de software funcional, que a direo percebeu a
reduo.
Como a empresa no possua nenhum tipo de formalidade nos testes dos sistemas, este
sistema serviu para mostrar como importante fazer uma boa carga de testes, pois o custo
para a correo de erros que foram encontrados em rotinas antes da liberao para clientes,
bem menor, alm de no gerar problemas relacionados a funes bsicas do sistema.
Com a utilizao de checklists, ficou bem mais fcil a parte de testes, pois pode ser
feita uma breve descrio do que deve ser testado, ficando mais fcil para os testadores
saberem o que esto testando e o os resultados esperados daquele teste, pois neste sistema foi
definido que as telas com os dados de entrada e sada seriam includas no checklist.
Este sistema esta utilizando a tcnica de teste funcional: testar a partir de resultados. A
utilizao desta tcnica mostrou-se eficiente para a situao desta empresa, pois ela no
possua nenhuma tcnica de teste implantada.
A parte de gerenciamento que antes era feita sem saber se uma rotina foi testada, agora
atravs do sistema voc sabe quem testou, quando testou e se ocorreram erros. Assim poder
ser verificado se algum programador est fazendo muita correo de rotinas antigas e novas, e
procurar saber o porque de estar acontecendo isto, se foi por falha na definio da rotina ou no
levantamento dos dados, podendo assim ser cobrado o responsvel real pelo erro.

40

4.1 SUGESTES
Para trabalhos futuros sugere-se o desenvolvimento de um sistema para o teste
estrutural, que possibilite a verificao da execuo do programa, pois desta forma os
programadores poderiam verificar mais rapidamente os erros encontrados no teste das rotinas.
Tambm sugervel a utilizao de outras tcnicas de teste funcional que no seja a de
testar a partir de resultados, para o desenvolvimento de sistemas para o gerenciamento de
teste.
Tambm sugervel a aquisio de outra ferramenta para testes j existente no
mercado.

41

REFERNCIAS BIBLIOGRFICAS
BENNER. Tecnologia, Blumenau. Disponvel em: <http://www.benner.com.br>. Acesso em:
22 ago. 2001.
CANT, Marco. Dominando o Delphi 5 a bblia. Traduo Joo E. N. Tortello. So Paulo:
Makron Books, 2000.
DEMARCO, Tom. Anlise estruturada e especificao de sistemas. Traduo de Maria
Beatriz G. S. Veiga de Carvalho. Rio de Janeiro, 1989.
FOURNIER, Roger. Guia prtico para o desenvolvimento e manuteno de sistemas
estruturados. So Paulo: Makron Books, 1994.
HETZEL, Willian. Guia completo ao teste software. Rio de Janeiro: Campos, 1987.
INTHURN, Cndida. Qualidade e teste de software. Florianpolis: Visual Books, 2001.
MALDONADO, Jos Carlos et al. Gesto de configurao na atividade de teste. In:
Workshop Qualidade de Software, 1., 1997, Fortaleza. Anais do Workshop Qualidade de
Software: SBC, 1997. p. 107-116.
MALDONADO, Jos Carlos. Aspectos Tericos e Empricos de Teste de Cobertura de
Software. In: VI Escola Regional de Informtica, 6., 1998, Curitiba. Anais da VI Escola
Regional de Informtica: FURB, PUC-PR, UCP, 1998. p. 53-86.
MARTIN, James. McClure, Carma. Tcnicas estruturadas e CASE. So Paulo: Makron
Books, 1995.
MULLER, James. McClure, Carma. Tcnicas estruturadas e CASE. So Paulo: Makron
Books, 1995.
PAULA FILHO, Wilson de Pdua. Engenharia de software: fundamentos, mtodos e
padres. Rio de Janeiro: LTC, 2001.
PRESSMAN, Roger. Engenharia de software. So Paulo: Makron Books, 1995.

42
PUCRS. Professor Dr. Flvio Moreira de Oliveira, Porto Alegre. Disponvel em: <http://
http://www.inf.pucrs.br/~flavio/>. Acesso em: 30 nov. 2001.
ROCHA, Ana Regina C. da; MALDONADO, Jos Carlos; WEBER,

Kival

Chaves.

Qualidade de software Teoria e prtica. So Paulo: Prentice Hall, 2001.


UNICRUZ.

Universidade

de

Cruz

Alta,

Cruz

Alta.

Disponvel

em:

<http://dinf.unicruz.edu.br/~facco/projeto.htm>. Acesso em: 30 nov. 2001.


YOURDON, Edward. Anlise estruturada moderna. Traduo Dalton Conde de Alencar.
Rio de Janeiro: Campus, 1990.

43
Anexo I

44

45
Anexo II