Introduo a Teste de Software

Arilo Cludio Dias Neto

(ariloclaudio@gmail.com)

Bacharel em Cincia da Computao formado na Universidade Federal do Amazonas,

Mestre em Engenharia de Sistemas e Computao formado na COPPE/UFRJ, e atualmente
est cursando doutorado na rea de Engenharia de Software da COPPE/UFRJ. Possui 5 anos
de experincia em anlise, desenvolvimento e
teste de software. editor tcnico das Revistas SQL Magazine e WebMobile, gerenciadas
pelo Grupo DevMedia.

54

este de software o processo de

execuo de um produto para
determinar se ele atingiu suas especificaes 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 caracterstica
das atividades de teste, dizemos que sua
natureza destrutiva, e no construtiva, pois visa ao aumento da confiana de
um produto atravs da exposio de seus
problemas, porm antes de sua entrega
ao usurio final.
O conceito de teste de software pode
ser compreendido atravs de uma viso
intuitiva ou mesmo de uma maneira
formal. Existem atualmente vrias definies para esse conceito. De uma forma
simples, testar um software significa verificar atravs de uma execuo controlada
se o seu comportamento corre de acordo
com o especificado. O objetivo principal

Engenharia de Software Magazine Introduo a Teste de Software

desta tarefa revelar o nmero mximo

de falhas dispondo do mnimo de esforo,
ou seja, mostrar aos que desenvolvem se
os resultados esto ou no de acordo com
os padres estabelecidos.
Ao longo deste artigo, iremos discutir
os principais conceitos relacionados s
atividades de teste, as principais tcnicas
e critrios de teste que podem ser utilizados para verificao ou validao de um
produto, assim como exemplos prticos
da aplicao de cada tipo de tcnica ou
critrio de teste.

Conceitos bsicos associados

a Teste de Software
Antes de iniciarmos uma discusso
sobre teste de software precisamos esclarecer alguns conceitos relacionados a
essa atividade. Inicialmente, precisamos
conhecer a diferena entre Defeitos, Erros e Falhas. As definies que iremos
usar aqui seguem a terminologia padro
para Engenharia de Software do IEEE
Institute of Electrical and Electronics

V E R I F I C A O, VA L I D A O E TE S T E

Engineers (IEEE 610, 1990).

'HIHLWRpXPDWRLQFRQVLVWHQWHFRPHtido por um indivduo ao tentar entender
uma determinada informao, resolver
um problema ou utilizar um mtodo
ou uma ferramenta. Por exemplo, uma
instruo ou comando incorreto.
 (UUR p XPD PDQLIHVWDomR FRQFUHWD
de um defeito num artefato de software. Diferena entre o valor obtido e o
valor esperado, ou seja, qualquer estado
intermedirio incorreto ou resultado
inesperado na execuo de um programa
constitui um erro.
)DOKDpRFRPSRUWDPHQWRRSHUDFLRQDO
do software diferente do esperado pelo
usurio. Uma falha pode ter sido causada
por diversos erros e alguns erros podem
nunca causar uma falha.
A Figura 1 expressa a diferena entre
esses conceitos. Defeitos fazem parte
do universo fsico (a aplicao propriamente dita) e so causados por pessoas,
por exemplo, atravs do mal uso de uma
tecnologia. Defeitos podem ocasionar a
manifestao de erros em um produto, ou
seja, a construo de um software de forma diferente ao que foi especificado (universo de informao). Por fim, os erros
geram falhas, que so comportamentos
inesperados em um software que afetam
diretamente o usurio final da aplicao
(universo do usurio) e pode inviabilizar
a utilizao de um software.
Dessa forma, ressaltamos que teste de
software revela simplesmente falhas em
um produto. Aps a execuo dos testes
necessria a execuo de um processo de
depurao para a identificao e correo
dos defeitos que originaram essa falha,
ou seja, Depurar no Testar!
A atividade de teste composta por
alguns elementos essenciais que auxiliam
na formalizao desta atividade. Esses
elementos so os seguintes:
%Caso de Teste. descreve uma condio
particular a ser testada e composto por
valores de entrada, restries para a sua
execuo e um resultado ou comportamento esperado (CRAIG e JASKIEL,
2002).
%Procedimento de Teste. uma descrio dos passos necessrios para executar
um caso (ou um grupo de casos) de teste
(CRAIG e JASKIEL, 2002).
%Critrio de Teste: serve para selecionar
e avaliar casos de teste de forma a aumen-

R E Q U I S I TO S

Figura 1. Defeito x erro x falha (Uma verso similar pode ser obtida em http://www.projectcartoon.com/cartoon/611)

tar as possibilidades de provocar falhas

ou, quando isso no ocorre, estabelecer
um nvel elevado de confiana na correo
do produto (ROCHA et al., 2001). Os critrios de teste podem ser utilizados como:
k Critrio de Cobertura dos Testes:
permitem a identificao 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). Ou seja, determinar o percentual
de elementos necessrios por um critrio de teste que foram executados pelo
conjunto de casos de teste.
k Critrio de Adequao 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
critrio. Ou seja, este critrio avalia se os
casos de teste definidos so suficientes
ou no para avaliao de um produto ou
uma funo (ROCHA et al., 2001).
k Critrio de Gerao de Casos de
Teste: quando o critrio utilizado para
gerar um conjunto de casos de teste T
adequado para um produto ou funo,
ou seja, este critrio define as regras e
diretrizes para gerao dos casos de teste de um produto que esteja de acordo
com o critrio de adequao definido
anteriormente (ROCHA et al., 2001).
Definidos os elementos bsicos associados aos testes de software, iremos a
seguir discutir a origem dos defeitos em
um software.

Defeitos no desenvolvimento
de software
No processo de desenvolvimento de
software, todos os defeitos so humanos
e, apesar do uso dos melhores mtodos
de desenvolvimento, ferramentas ou

profissionais, permanecem presentes

nos produtos, o que torna a atividade de
teste fundamental durante o desenvolvimento de um software. J vimos que esta
atividade corresponde ao ltimo recurso
para avaliao do produto antes da sua
entrega ao usurio final.
O tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas
no processo so dois possveis fatores
que aumentam a complexidade dessa
tarefa, e consequentemente aumentam
a probabilidade de defeitos. Assim, a
ocorrncia de falhas inevitvel. Mas
o que significa dizer que um programa
falhou? Basicamente significa que o
funcionamento do programa no est de
acordo com o esperado pelo usurio. Por
exemplo, quando um usurio da linha
de produo efetua consultas no sistema
das quais s a gerncia deveria ter acesso.
Esse tipo de falha pode ser originado por
diversos motivos:
%A especificao pode estar errada ou
incompleta;
%A especificao pode conter requisitos
impossveis de serem implementados
devido a limitaes de hardware ou software;
%A base de dados pode estar organizada
de forma que no seja permitido distinguir os tipos de usurio;
%Pode ser que haja um defeito no algoritmo de controle dos usurios.
Os defeitos normalmente so introduzidos na transformao de informaes
entre as diferentes fases do ciclo de desenvolvimento de um software. Vamos
seguir um exemplo simples de ciclo de
vida de desenvolvimento de software:
os requisitos expressos pelo cliente so
relatados textualmente em um documento de especificao de requisitos.
Esse documento ento transformado

Edio 01 Engenharia de Software Magazine

55

em casos de uso, que por sua vez foi o

artefato de entrada para o projeto do
software e definio de sua arquitetura utilizando diagramas de classes
da UML. Em seguida, esses modelos
de projetos foram usados para a construo do software em uma linguagem
que no segue o paradigma orientado a
objetos. Observe que durante esse perodo uma srie de transformaes foi
realizada at chegarmos ao produto final. Nesse meio tempo, defeitos podem
ter sido inseridos. A Figura 2 expressa
exatamente a metfora discutida nesse
pargrafo.
Essa srie de transformaes resultou
na necessidade de realizar testes em diferentes nveis, visando avaliar o software
em diferentes perspectivas de acordo com
o produto gerado em cada fase do ciclo de
vida de desenvolvimento de um software. Esse ser o foco da seo seguinte.

Nveis de teste de software

O planejamento dos testes deve ocorrer
em diferentes nveis e em paralelo ao
desenvolvimento do software (Figura 3).
Buscando informao no Livro Qualidade
de Software Teoria e Prtica (ROCHA et
al., 2001), definimos que os principais nveis
de teste de software so:
%Teste de Unidade: tambm conhecido
como testes unitrios. Tem por objetivo
explorar a menor unidade do projeto, procurando provocar falhas ocasionadas por
defeitos de lgica e de implementao em
cada mdulo, separadamente. O universo
alvo desse tipo de teste so os mtodos
dos objetos ou mesmo pequenos trechos
de cdigo.
%Teste de Integrao: visa provocar
falhas associadas s interfaces entre os
mdulos quando esses so integrados
para construir a estrutura do software
que foi estabelecida na fase de projeto.

%Teste de Sistema: avalia o software em

busca de falhas por meio da utilizao do
mesmo, como se fosse um usurio final.
Dessa maneira, os testes so executados nos
mesmos ambientes, com as mesmas condies e com os mesmos dados de entrada
que um usurio utilizaria no seu dia-a-dia
de manipulao do software. Verifica se o
produto satisfaz seus requisitos.
%Teste de Aceitao: so realizados
geralmente por um restrito grupo de usurios finais do sistema. Esses simulam
operaes de rotina do sistema de modo
a verificar se seu comportamento est de
acordo com o solicitado.
%Teste de Regresso: Teste de regresso
no corresponde a um nvel de teste, mas
uma estratgia importante para reduo
de efeitos colaterais. Consiste em se
aplicar, a cada nova verso do software
ou a cada ciclo, todos os testes que j
foram aplicados nas verses ou ciclos
de teste anteriores do sistema. Pode ser
aplicado em qualquer nvel de teste.
Dessa forma, seguindo a Figura 3, o
planejamento e projeto dos testes devem
ocorrer de cima para baixo, ou seja:
1. Inicialmente planejado o teste de
aceitao a partir do documento de requisitos;
2. Aps isso planejado o teste de sistema a partir do projeto de alto nvel do
software;
3. Em seguida ocorre o planejamento
dos testes de integrao a partir o projeto
detalhado;
4. E por fim, o planejamento dos testes
a partir da codificao.

Figura 2. Diferentes Interpretaes ao longo do ciclo de desenvolvimento de um software

J a execuo ocorre no sentido inverso.

Conhecidos os diferentes nveis de teste,
a partir da prxima seo descreveremos
as principais tcnicas de teste de software
existentes que podemos aplicar nos diferentes nveis abordados.

Tcnicas de teste de software

Figura 3. Modelo V descrevendo o paralelismo entre as atividades de desenvolvimento e teste de software

(CRAIG e JASKIEL, 2002)

56

Engenharia de Software Magazine Introduo a Teste de Software

Atualmente existem muitas maneiras

de se testar um software. Mesmo assim,
existem as tcnicas que sempre foram
muito utilizadas em sistemas desenvolvidos sobre linguagens estruturadas
que ainda hoje tm grande valia para
os sistemas orientados a objeto. Apesar
de os paradigmas de desenvolvimento
serem diferentes, o objetivo principal
destas tcnicas continua a ser o mesmo:

V E R I F I C A O, VA L I D A O E TE S T E

encontrar falhas no software.

As tcnicas de teste so classificadas de
acordo com a origem das informaes
utilizadas para estabelecer os requisitos
de teste. Elas contemplam diferentes
perspectivas do software e impe-se a
necessidade de se estabelecer uma estratgia de teste que contemple as vantagens
e os aspectos complementares dessas tcnicas. As tcnicas existentes so: tcnica
funcional e estrutural.
A seguir conheceremos um pouco mais
sobre cada tcnica, mas iremos enfatizar
alguns critrios especficos para a tcnica
funcional.

Tcnica Estrutural
(ou teste caixa-branca)
Tcnica de teste que avalia o comportamento interno do componente de
software (Figura 4). Essa tcnica trabalha
diretamente sobre o cdigo fonte do componente de software para avaliar aspectos tais como: teste de condio, teste de
fluxo de dados, teste de ciclos e teste de
caminhos lgicos (PRESSMAN, 2005).
Os aspectos avaliados nesta tcnica
de teste dependero da complexidade
e da tecnologia que determinarem a
construo do componente de software,
cabendo, portanto, avaliao de outros
aspectos alm dos citados anteriormente.
O testador tem acesso ao cdigo fonte
da aplicao e pode construir cdigos
para efetuar a ligao de bibliotecas e
componentes.
Este tipo de teste desenvolvido analisando-se o cdigo fonte e elaborando-se
casos de teste que cubram todas as possibilidades do componente de software.
Dessa maneira, todas as variaes origi-

REQ
nadas por estruturas de condies
soU I S I TO S
testadas. A Listagem 1 apresenta um
cdigo fonte, extrado de (BARBOSA et
al., 2000) que descreve um programa de
exemplo que deve validar um identificador digitado como parmetro, e a Figura
5 apresenta o grafo de programa extrado
Figura 4. Tcnica de Teste Estrutural.
a partir desse cdigo, tambm extrado
de (BARBOSA et al., 2000). A partir do
grafo deve ser escolhido algum critrio
baseado em algum algoritmo de busca
em grafo (exemplo: visitar todos os ns,
arcos ou caminhos) para gerao dos casos de teste estruturais para o programa
(PFLEEGER, 2004).
Um exemplo bem prtico desta tcnica
de teste o uso da ferramenta livre JUnit
para desenvolvimento de casos de teste
para avaliar classes ou mtodos desenvolvidos na linguagem Java. A tcnica de
teste de Estrutural recomendada para
os nveis de Teste da Unidade e Teste da
Integrao, cuja responsabilidade principal fica a cargo dos desenvolvedores
do software, que so profissionais que
conhecem bem o cdigo-fonte desenvolvido e dessa forma conseguem planejar
os casos de teste com maior facilidade.
Dessa forma, podemos auxiliar na reduo dos problemas existentes nas pequenas funes ou unidades que compem
Figura 5. Grafo de Programa (Identifier.c)
(BARBOSA et al., 2000).
um software.
Teste Funcional (ou teste caixa-preta)
Tcnica de teste em que o componente
de software a ser testado abordado
como se fosse uma caixa-preta, ou seja,
no se considera o comportamento interno do mesmo (Figura 6). Dados de entrada
so fornecidos, o teste executado e o
resultado obtido comparado a um re-

Figura 6. Tcnica de Teste Funcional.

Listagem 1. Cdigo fonte do programa identifier.c (BARBOSA et al., 2000)

/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*

01
01
01
01
01
01
01
01
01
02
03
04
05
05
06
07
07
07
08
09
10
10
11

*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/

{
char achar;
int
length, valid_id;
length = 0;
printf (Digite um possvel identificador\n);
printf (seguido por <ENTER>: );
achar = fgetc (stdin);
valid_id = valid_starter (achar);
if (valid_id)
length = 1;
achar = fgetc (stdin);
while (achar != \n)
{
if (!(valid_follower (achar)))
valid_id = 0;
length++;
achar = fgetc (stdin);
}
if (valid_id && (length >= 1) && (length < 6) )
printf (Valido\n);
else
printf (Invalido\n);
}

Edio 01 Engenharia de Software Magazine

57

sultado esperado previamente conhecido.

Haver sucesso no teste se o resultado
obtido for igual ao resultado esperado.
O componente de software a ser testado
pode ser um mtodo, uma funo interna,
um programa, um componente, um conjunto de programas e/ou componentes ou
mesmo uma funcionalidade. A tcnica
de teste funcional aplicvel a todos os
nveis de teste (PRESSMAN, 2005).
Um conjunto de critrios de teste pode
ser aplicado aos testes funcionais. A seguir conheceremos alguns deles.

Tipicamente uma condio de entrada

pode ser um valor numrico especfico,
uma faixa de valores, um conjunto de
valores relacionados, ou uma condio
lgica. As seguintes diretrizes podem
ser aplicadas:
%Se uma condio de entrada especifica
uma faixa de valores ou requer um valor especfico, uma classe de equivalncia vlida
(dentro do limite) e duas invlidas (acima
e abaixo dos limites) so definidas.
%Se uma condio de entrada especifica
um membro de um conjunto ou lgica,
uma classe de equivalncia vlida e uma
invlida so definidas.

Particionamento em classes de
equivalncia

Devemos seguir tais passos para gerao dos testes usando este critrio:
1. Identificar classes de equivalncia (
um processo heurstico)
kcondio de entrada
kvlidas e invlidas
2. Definir os casos de teste
k enumeram-se as classes de equivalncia
kcasos de teste para as classes vlidas
kcasos de teste para as classes invlidas

Esse critrio divide o domnio de entrada

de um programa em classes de equivalncia, a partir das quais os casos de teste so
derivados. Ele tem por objetivo minimizar
o nmero de casos de teste, selecionando
apenas um caso de teste de cada classe,
pois em princpio todos os elementos
de uma classe devem se comportar de
maneira equivalente. Eventualmente,
pode-se tambm considerar o domnio
de sada para a definio das classes de
equivalncia (ROCHA et al., 2001).
Uma classe de equivalncia representa
um conjunto de estados vlidos e invlidos para uma condio de entrada.

Em (BARBOSA et al., 2000) apresentado a aplicao do critrio de particionamento por equivalncia para o programa

<3
#produtos

>80

Fret e Grtis
> =3

Valor comp ra

Cob rar Frete

< =80
Figura 7. rvore de Deciso Grafo de Causa-Efeito.
Condies de Entrada

Classes

Classes

Tamanho t do identificador

(1) 1 )t)6

(2) t > 6

Primeiro caractere c uma letra

(3) Sim

(4) No

S contm caracteres vlidos

(5) Sim

(6) No

Valor da compra

> 60

> 60

<= 60

#Produtos

<3

>= 3

--

Causa

Efeito
Frete grtis

Tabela 2. Tabela de deciso para o programa de compra pela Internet.

58

Um identificador vlido deve comear

com uma letra e conter apenas letras ou
dgitos. Alm disso, deve ter no mnimo
1 caractere e no mximo 6 caracteres
de comprimento. Exemplo: abc12 (vlido), cont*1 (invlido), 1soma (invlido) e a123456 (invlido).

O primeiro passo a identificao das

classes de equivalncia. Isso est descrito
na Tabela 1.
A partir disso, conseguimos especificar
quais sero os casos de teste necessrios.
Para ser vlido, um identificador deve
atender s condies (1), (3) e (5), logo
necessrio um caso de teste vlido que
cubra todas essas condies. Alem disso,
ser necessrio um caso de teste para
cada classe invlida: (2), (4) e (6). Assim, o
conjunto mnimo composto por quatro
casos de teste, sendo uma das opes:
T0 = {(a1,Vlido), (2B3, Invlido), (Z-12,
Invlido), (A1b2C3d, Invlido)}.

Anlise do valor limite

Por razes no completamente identificadas, um grande nmero de erros
tende a ocorrer nos limites do domnio de
entrada invs de no centro. Esse critrio
de teste explora os limites dos valores de
cada classe de equivalncia para preparar
os casos de teste (Pressman, 2005).
Se uma condio de entrada especifica
uma faixa de valores limitada em a e b,
casos de teste devem ser projetados com
valores a e b e imediatamente acima e
abaixo de a e b. Exemplo: Intervalo =
{1..10}; Casos de Teste {1, 10, 0,11}.
Como exemplo, extrado de (BARBOSA
et al., 2000), iremos considerar a seguinte
situao:
"... o clculo do desconto por dependente feito da seguinte forma: a entrada a idade do dependente que deve

Tabela 1. Classes de Equivalncia do programa identifier.c.

Cobrar frete

identifier.c. Iremos apresent-lo como

exemplo do uso deste critrio de teste. Relembrando, o programa deve determinar
se um identificador vlido ou no.

Engenharia de Software Magazine Introduo a Teste de Software

estar restrita ao intervalo [0..24]. Para

dependentes at 12 anos (inclusive) o
desconto de 15%. Entre 13 e 18 (inclusive) o desconto de 12%. Dos 19 aos
21 (inclusive) o desconto de 5% e dos
22 aos 24 de 3%..."

Aplicando o teste de valor limite

V E R I F I C A O, VA L I D A O E TE S T E

convenc iona l sero obt idos cas o s de t e st e s e mel h a nt e s a e st e:

{-1,0,12,13,18,19,21,22,24,25}.

Grafo de causa-efeito
Esse critrio de teste verifica o efeito
combinado de dados de entrada. As
causas (condies de entrada) e os efeitos
(aes) so identificados e combinados
em um grafo a partir do qual montada
uma tabela de deciso, e a partir desta,
so derivados os casos de teste e as sadas
(ROCHA et al., 2001).
Esse critrio baseado em quatro passos, que exemplificaremos utilizando o
exemplo, tambm extrado de (BARBOSA
et al., 2000):
Em um programa de compras pela
Internet, a cobrana ou no do frete
definida seguindo tal regra: Se o valor
da compra for maior que R$ 60,00 e foram comprados menos que 3 produtos,
o frete gratuito. Caso contrrio, o frete
dever ser cobrado.

1. Para cada mdulo, Causas (condies

de entrada) e efeitos (aes realizadas s
diferentes condies de entrada) so relacionados, atribuindo-se um identificador
para cada um.
%Causa: valor da compra > 60 e #produtos < 3
%Efeito: frete grtis
2. Em seguida, um grafo de causaefeito (rvore de deciso) desenhado
(Figura 7).
3. Neste ponto, transforma-se o grafo
numa tabela de deciso (Tabela 2).
4. As regras da tabela de deciso so,
ento, convertidas em casos de teste.
Para a elaborao dos casos de teste,
devemos seguir todas as regras extradas
da tabela. Esse critrio deve ser combinado com os dois outros j apresentados
neste artigo para a criao de casos de
teste vlidos (extrados das regras) e
invlidos (valores foras da faixa definida). Os casos de teste definidos a seguir
refletem somente as regras extradas da
tabela de deciso. Fica como exerccio
pensar nos casos de teste invlidos para
este problema.
%Casos de Teste (valor, qtd produtos,

R EgrQ U I Sgerenciamento
I TO S
resultado esperado) = {(61,2,frete
e anlise de resultados.
tis); (61,3,cobrar frete); (60, qualquer
Apoio ferramental para qualquer ativiquantidade,cobrar frete)}.
dade do processo de teste importante
como mecanismo para reduo de esforo
associado tarefa em questo, seja ela
Outras tcnicas
planejamento, projeto ou execuo dos
Outras tcnicas de teste podem e devem
testes. Aps ter sua estratgia de teste
ser utilizadas de acordo com necessidades
definida, tente buscar por ferramentas
de negcio ou restries tecnolgicas.
que se encaixem na sua estratgia. Isso
Destacam-se as seguintes tcnicas: teste de
pode reduzir significantemente o esforo
desempenho, teste de usabilidade, teste de
de tal tarefa.
carga, teste de stress, teste de confiabilidaAlm disso, importante ressaltar que
de e teste de recuperao. Alguns autores
diferentes tipos de aplicaes possuem
chegam a definir uma tcnica de teste
diferentes tcnicas de teste a serem
caixa cinza, que seria um mesclado do uso
aplicadas, ou seja, testar uma aplicao
das tcnicas de caixa preta e caixa branca,
web envolve passos diferenciados em
mas, como toda execuo de trabalho
comparao aos testes de um sistema
relacionado atividade de teste utilizar
embarcado. Cada tipo de aplicao possui
simultaneamente mais de uma tcnica
caractersticas especificas que devem ser
de teste, recomendvel que se fixem os
consideradas no momento da realizao
conceitos primrios de cada tcnica.
dos testes. O conjunto de tcnicas apresentado neste artigo cobre diversas caracConcluses
tersticas comuns a muitas categorias de
O teste de software uma das atividades
software, mas no completo.
mais custosas do processo de desenvolPara finalizar, podemos destacar ouvimento de software, pois pode envolver
tros pontos importantes relacionados s
uma quantidade significativa dos recursos
atividades de teste que podemos abordar
de um projeto. O rigor e o custo associado
em prximos artigos, tais como processo
a esta atividade dependem principalmente
de teste de software, planejamento e conda criticalidade da aplicao a ser desenvoltrole dos testes e teste de software para
vida. Diferentes categorias de aplicaes
categorias especficas de software, como
requerem uma preocupao diferenciada
aplicaes web. At a prxima!
com as atividades de teste.
Um ponto bastante importante para
a viabilizao da aplicao de teste de
Agradecimentos
software a utilizao de uma infraAgradecemos aos professores Jos Carlos
estrutura adequada. Realizar testes
Maldonado e Ellen Barbosa por terem
no consiste simplesmente na gerao
gentilmente autorizado a publicao deste
e execuo de casos de teste, mas envolmaterial, cujos exemplos utilizados esto
vem tambm questes de planejamento,
fundamentados em seus trabalhos.
Referncias
BARBOSA, E.; MALDONADO, J.C.; VINCENZI, A.M.R.; DELAMARO, M.E; SOUZA, S.R.S. e JINO, M..
Introduo ao Teste de Software. XIV Simpsio Brasileiro de Engenharia de Software, 2000.
CRAIG, R.D., JASKIEL, S. P., Systematic Software Testing, Artech House Publishers, Boston, 2002.
IEEE Standard 610-1990: IEEE Standard Glossary of Software Engineering Terminology, IEEE Press.
PFLEEGER, S. L., Engenharia de Software: Teoria e Prtica, Prentice Hall- Cap. 08, 2004.
PRESSMAN, R. S.,Software Engineering: A Practitioners Approach, McGraw-Hill, 6th ed, Nova York,
NY, 2005.
RAPPS, S., WEYUKER, E.J., Data Flow analysis techniques for test data selection, In: International
Conference on Software Engineering, p. 272-278, Tokio, Sep. 1982.
ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C. et al., Qualidade de software Teoria e prtica,
Prentice Hall, So Paulo, 2001.

Edio 01 Engenharia de Software Magazine

59