O documento discute os conceitos fundamentais de teste de software, incluindo os diferentes níveis de teste como unidade, integração e sistema. Também explica que defeitos são introduzidos durante o ciclo de desenvolvimento à medida que as especificações são transformadas em código, destacando a importância de testes em cada nível.

1. Testes
ArtigoEngenhariade Software - Introduçãoa Teste de Software
Ao longodeste artigo,iremosdiscutirosprincipaisconceitosrelacionadosàsatividadesde
teste,asprincipaistécnicase critériosde teste que podemserutilizadospara verificaçãoou
validaçãode umproduto.
24
Gostei (45) (5)
Esse artigo fazparte da revistaEngenhariade Software ediçãoespecial.Cliqueaqui paraler
todosos artigosdestaedição
Verificação,Validaçãoe Teste
Introduçãoa Teste de Software
Teste de software é o processode execuçãode umprodutopara determinarse ele atingiu
suas especificaçõese funcionoucorretamente noambiente paraoqual foi projetado.Oseu
objetivoé revelarfalhasemumproduto,paraque as causasdessasfalhas sejamidentificadas
e possamsercorrigidaspelaequipe de desenvolvimentoantesdaentregafinal.Porconta
dessacaracterística dasatividadesde teste,dizemosque suanaturezaé “destrutiva”,e não
“construtiva”,poisvisaaoaumentoda confiançade um produtoatravésda exposiçãode seus
problemas,porémantesde suaentregaaousuáriofinal.
O conceitode teste de software pode sercompreendidoatravésde umavisãointuitivaou
mesmode uma maneiraformal.Existematualmente váriasdefiniçõesparaesse conceito.De
uma formasimples,testarumsoftware significaverificaratravésde umaexecuçãocontrolada
se o seucomportamentocorre de acordo com o especificado.Oobjetivoprincipal destatarefa
é revelaronúmeromáximode falhasdispondodomínimo de esforço,ouseja,mostraraos
que desenvolvemse osresultadosestãoounãode acordo com os padrõesestabelecidos.
Ao longodeste artigo,iremosdiscutirosprincipaisconceitosrelacionadosàsatividadesde
teste,asprincipaistécnicase critérios de teste que podemserutilizadosparaverificaçãoou

2. validaçãode umproduto,assimcomo exemplospráticosdaaplicaçãode cada tipode técnica
ou critériode teste.
ConceitosbásicosassociadosaTeste de Software
Antesde iniciarmosumadiscussãosobre teste de softwareprecisamosesclareceralguns
conceitosrelacionadosaessaatividade.Inicialmente,precisamosconheceradiferençaentre
Defeitos,Errose Falhas.Asdefiniçõesque iremosusaraqui seguematerminologiapadrão
para Engenhariade Software doIEEE – Institute of Electrical andElectronicsEngineers –(IEEE
610, 1990).
• Defeitoé umatoinconsistentecometidoporumindivíduoaotentarentenderuma
determinadainformação,resolverumproblemaouutilizarummétodoouumaferramenta.
Por exemplo,umainstruçãooucomandoincorreto.
• Erro é umamanifestaçãoconcretade um defeitonumartefatode software.Diferençaentre
o valorobtidoe o valor esperado,ouseja,qualquerestadointermediárioincorretoou
resultadoinesperadonaexecução de umprogramaconstitui umerro.
• Falhaé o comportamentooperacional dosoftware diferentedoesperadopelousuário.Uma
falhapode tersidocausada por diversoserrose algunserrospodemnuncacausar uma falha.
A Figura1 expressaadiferençaentre essesconceitos.Defeitosfazemparte douniversofísico
(a aplicaçãopropriamente dita) e sãocausadosporpessoas,porexemplo,atravésdomal uso
de uma tecnologia.Defeitospodemocasionaramanifestaçãode errosemumproduto,ou
seja,a construçãode umsoftware de formadiferente aoque foi especificado(universode
informação).Porfim,oserrosgeramfalhas,que são comportamentosinesperadosemum
software que afetamdiretamente ousuáriofinal daaplicação(universodousuário) e pode
inviabilizarautilizaçãode umsoftware.
Figura1. Defeitox errox falha
Dessaforma,ressaltamosque teste de software revelasimplesmentefalhasemumproduto.
Apósa execuçãodostestesé necessáriaaexecuçãode umprocessode depuraçãopara a
identificaçãoe correçãodos defeitosque originaramessafalha,ouseja,Depurarnãoé Testar!

3. A atividade de teste é compostaporalgunselementosessenciaisque auxiliamnaformalização
destaatividade.Esseselementossãoosseguintes:
• Casode Teste:descreve umacondiçãoparticularasertestadae é compostoporvaloresde
entrada,restriçõesparaa sua execuçãoe um resultadooucomportamentoesperado(CRAIGe
JASKIEL,2002).
• Procedimentode Teste:é umadescriçãodospassosnecessáriosparaexecutarumcaso(ou
um grupode casos) de teste (CRAIGe JASKIEL,2002).
• Critériode Teste:serve paraselecionare avaliarcasosde teste de formaa aumentaras
possibilidadesde provocarfalhasou,quandoissonãoocorre,estabelecerumnível elevadode
confiançana correção doproduto(ROCHA et al.,2001). Os critériosde teste podemser
utilizadoscomo:
o Critériode CoberturadosTestes:permitemaidentificaçãode partesdoprograma que
devemserexecutadasparagarantira qualidade dosoftware e indicarquandoomesmofoi
suficientementetestado(RAPPSe WEYUKER,1982). Ouseja,determinaropercentual de
elementosnecessáriosporumcritériode teste que foramexecutadospeloconjuntode casos
de teste.
o Critériode Adequaçãode Casosde Teste:Quando,apartir de um conjuntode casos de teste
T qualquer,ele é utilizadoparaverificarse Tsatisfazosrequisitosde teste estabelecidospelo
critério.Ouseja,este critérioavaliase oscasosde teste definidossãosuficientesounãopara
avaliaçãode um produtoou umafunção(ROCHA et al.,2001).
o Critériode Geraçãode Casosde Teste:quandoo critérioé utilizadoparagerarum conjunto
de casos de teste T adequadopara um produtooufunção,ou seja,este critériodefine as
regras e diretrizesparageração dos casosde teste de umprodutoque estejade acordocom o
critériode adequaçãodefinidoanteriormente (ROCHA etal.,2001).
Definidososelementosbásicosassociadosaostestesde software,iremosaseguirdiscutira
origemdosdefeitosemumsoftware.
Defeitosnodesenvolvimentode software
No processode desenvolvimentode software,todososdefeitossãohumanose,apesardouso
dos melhoresmétodosde desenvolvimento,ferramentasouprofissionais,permanecem
presentesnosprodutos,oque tornaa atividade de teste fundamentaldurante o

4. desenvolvimentode umsoftware.Jávimosque estaatividadecorresponde aoúltimorecurso
para avaliaçãodo produtoantesda sua entregaaousuáriofinal.
O tamanhodo projetoa serdesenvolvidoe aquantidade de pessoasenvolvidasnoprocesso
são doispossíveisfatoresque aumentamacomplexidade dessatarefa,e consequentemente
aumentama probabilidade de defeitos.Assim, aocorrênciade falhasé inevitável.Maso que
significadizerque umprogramafalhou?Basicamentesignificaque ofuncionamentodo
programa nãoestá de acordo com o esperadopelousuário.Porexemplo,quandoumusuário
da linhade produçãoefetuaconsultasnosistemadasquaissóa gerênciadeveriateracesso.
Esse tipode falhapode seroriginadopordiversosmotivos:
• A especificaçãopode estarerradaouincompleta;
• A especificaçãopode conterrequisitosimpossíveisde seremimplementadosdevidoa
limitaçõesde hardware ousoftware;
• A base de dadospode estarorganizadade forma que não sejapermitidodistinguirostipos
de usuário;
• Pode serque hajaum defeitonoalgoritmode controle dosusuários.
Os defeitosnormalmente sãointroduzidosnatransformaçãode informaçõesentre as
diferentesfasesdociclode desenvolvimentode umsoftware.Vamosseguirumexemplo
simplesde ciclode vidade desenvolvimentode software:osrequisitosexpressospelocliente
são relatadostextualmente emumdocumentode especificaçãode requisitos.Esse
documentoé entãotransformadoemcasosde uso, que por suavezfoi o artefatode entrada
para o projetodosoftware e definiçãode suaarquiteturautilizandodiagramasde classesda
UML. Em seguida,essesmodelosde projetosforamusadosparaa construção dosoftware em
uma linguagemque nãosegue oparadigmaorientadoaobjetos.Observe que durante esse
períodouma série de transformaçõesfoi realizadaaté chegarmosaoprodutofinal.Nessemeio
tempo,defeitospodemtersidoinseridos.A Figura2 expressaexatamenteametáfora
discutidanesse parágrafo.
Figura2. DiferentesInterpretaçõesaolongodociclode desenvolvimentode umsoftware
(Uma versãosimilarpode serobtidaemhttp://www.projectcartoon.com/cartoon/611)

5. Essa série de transformaçõesresultounanecessidade de realizartestesemdiferentesníveis,
visandoavaliarosoftware emdiferentesperspectivasde acordocomo produtogeradoem
cada fase do ciclode vidade desenvolvimentode umsoftware.Esse seráofocoda seção
seguinte.
Níveisde teste de software
O planejamentodostestesdeveocorreremdiferentesníveise emparaleloao
desenvolvimentodosoftware (Figura3).BuscandoinformaçãonoLivro“Qualidade de
Software – Teoriae Prática” (ROCHA et al.,2001), definimosque osprincipaisníveisde teste
de software são:
• Teste de Unidade:tambémconhecidocomotestesunitários.Temporobjetivoexplorara
menorunidade doprojeto,procurandoprovocarfalhasocasionadaspordefeitosde lógicae de
implementaçãoemcadamódulo,separadamente.Ouniversoalvodesse tipode teste sãoos
métodosdosobjetosoumesmopequenostrechosde código.
• Teste de Integração:visaprovocarfalhasassociadasàs interfacesentre osmódulosquando
essessãointegradosparaconstruira estruturado software que foi estabelecidanafase de
projeto.
• Teste de Sistema:avaliaosoftware embuscade falhaspor meiodautilizaçãodomesmo,
como se fosse umusuáriofinal.Dessamaneira,ostestessãoexecutadosnosmesmos
ambientes,comasmesmascondiçõese comos mesmosdadosde entradaque um usuário
utilizarianoseudia-a-diade manipulaçãodosoftware.Verificase oprodutosatisfazseus
requisitos.
• Teste de Aceitação:sãorealizadosgeralmente porumrestritogrupode usuáriosfinaisdo
sistema.Essessimulamoperaçõesde rotinadosistemade modo averificarse seu
comportamentoestáde acordocom o solicitado.
• Teste de Regressão:Teste de regressãonãocorresponde aumnível de teste,masé uma
estratégiaimportante parareduçãode “efeitoscolaterais”.Consisteemse aplicar,acada nova
versãodo software oua cada ciclo,todosos testesque jáforamaplicadosnasversõesou
ciclosde teste anterioresdosistema.Pode seraplicadoemqualquernível de teste.
Dessaforma,seguindoaFigura3, o planejamentoe projetodostestesdevemocorrerde cima
para baixo,ouseja:
1. Inicialmenteé planejadooteste de aceitaçãoa partirdo documentode requisitos;

6. 2. Apósissoé planejadooteste de sistemaapartirdo projetode altonível do software;
3. Em seguidaocorre oplanejamentodostestesde integraçãoapartiro projetodetalhado;
4. E por fim,oplanejamentodostestesapartirda codificação.
Já a execuçãoocorre no sentidoinverso.
Conhecidososdiferentesníveisde teste,apartirda próximaseçãodescreveremosas
principaistécnicasde teste de software existentesque podemosaplicarnosdiferentesníveis
abordados.
Figura3. ModeloV descrevendooparalelismoentreasatividadesde desenvolvimentoe teste
de software (CRAIGe JASKIEL,2002)
Técnicasde teste de software
Atualmente existemmuitasmaneirasde se testarumsoftware.Mesmoassim, existemas
técnicasque sempre forammuitoutilizadasemsistemasdesenvolvidossobre linguagens
estruturadasque aindahoje têmgrande valiaparaos sistemasorientadosaobjeto.Apesarde
os paradigmasde desenvolvimentoseremdiferentes,oobjetivoprincipal destastécnicas
continuaa ser o mesmo:encontrarfalhasnosoftware.
As técnicasde teste sãoclassificadasde acordocoma origemdasinformaçõesutilizadaspara
estabeleceros requisitosde teste.Elascontemplamdiferentesperspectivasdosoftware e
impõe-se anecessidadede se estabelecerumaestratégiade teste que contemple as
vantagense os aspectoscomplementaresdessastécnicas.Astécnicasexistentessão:técnica
funcional e estrutural.
A seguirconheceremosumpoucomaissobre cada técnica,masiremosenfatizaralguns
critériosespecíficosparaatécnicafuncional.
TécnicaEstrutural (ou teste caixa-branca)

7. Técnicade teste que avaliaocomportamentointernodo componentede software (Figura4).
Essa técnicatrabalhadiretamente sobre ocódigofonte docomponente de software para
avaliaraspectostaiscomo: teste de condição,teste de fluxode dados,teste de ciclose teste
de caminhoslógicos(PRESSMAN,2005)
Figura4. Técnicade Teste Estrutural.
Os aspectosavaliadosnestatécnicade teste dependerãodacomplexidadee datecnologiaque
determinaremaconstruçãodocomponente de software,cabendo,portanto,avaliaçãode
outrosaspectosalémdoscitadosanteriormente.Otestadortemacessoao códigofonte da
aplicaçãoe pode construircódigosparaefetuara ligaçãode bibliotecase componentes.
Este tipode teste é desenvolvidoanalisando-seocódigofonte e elaborando-se casosde teste
que cubram todasas possibilidadesdocomponentede software.Dessamaneira,todasas
variaçõesoriginadasporestruturasde condiçõessãotestadas.A Listagem1 apresentaum
códigofonte,extraídode (BARBOSA etal.,2000) que descreve umprogramade exemploque
deve validarumidentificadordigitadocomoparâmetro,e aFigura5 apresentaografo de
programa extraídoa partirdesse código,tambémextraídode (BARBOSA etal.,2000). A partir
do grafodeve serescolhidoalgumcritériobaseadoemalgumalgoritmode buscaemgrafo
(exemplo:visitartodososnós,arcos ou caminhos) parageração doscasos de teste estruturais
para o programa (PFLEEGER, 2004).
Listagem1. Códigofonte doprogramaidentifier.c(BARBOSAetal.,2000)
/* 01 */ {
/* 01 */ char achar;
/* 01 */ int length,valid_id;
/* 01 */ length= 0;
/* 01 */ printf ("Digite umpossível identificadorn");
/* 01 */ printf ("seguidopor:");
/* 01 */ achar = fgetc(stdin);
/* 01 */ valid_id= valid_starter(achar);
/* 01 */ if (valid_id)
/* 02 */ length= 1;

8. /* 03 */ achar = fgetc(stdin);
/* 04 */ while (achar!= 'n')
/* 05 */ {
/* 05 */ if (!(valid_follower(achar)))
/* 06 */ valid_id=0;
/* 07 */ length++;
/* 07 */ achar = fgetc(stdin);
/* 07 */ }
/* 08 */ if (valid_id&&(length>= 1) && (length< 6) )
/* 09 */ printf ("Validon");
/* 10 */ else
/* 10 */ printf ("Invalidon");
/* 11 */ }
Figura5. Grafo de Programa(Identifier.c) (BARBOSA etal.,2000).
Um exemplobempráticodestatécnicade teste é ouso da ferramentalivre JUnitpara
desenvolvimento de casosde teste paraavaliarclassesoumétodosdesenvolvidosna
linguagemJava.A técnicade teste de Estrutural é recomendadapara osníveisde Teste da
Unidade e Teste da Integração,cujaresponsabilidadeprincipal ficaacargo dos
desenvolvedoresdo software,que sãoprofissionaisque conhecembemocódigo-fonte
desenvolvidoe dessaformaconseguemplanejaroscasosde teste commaiorfacilidade.Dessa
forma,podemosauxiliarnareduçãodosproblemasexistentesnaspequenasfunçõesou
unidadesque compõemumsoftware.
Teste Funcional (outeste caixa-preta)
Técnicade teste emque o componente de softwareasertestadoé abordado comose fosse
uma caixa-preta,ouseja,nãose consideraocomportamentointernodomesmo(Figura6).
Dados de entradasão fornecidos,oteste é executadoe oresultadoobtidoé comparadoaum
resultadoesperadopreviamenteconhecido.Haverásucessonoteste se oresultadoobtidofor
igual ao resultadoesperado.Ocomponente de software asertestadopode serum método,
uma funçãointerna,umprograma,um componente,umconjuntode programase/ou
componentesoumesmoumafuncionalidade.A técnicade teste funcional é aplicável atodos
os níveisde teste (PRESSMAN,2005).

9. Figura6. Técnicade Teste Funcional.
Um conjuntode critériosde teste pode seraplicadoaostestesfuncionais.A seguir
conheceremosalgunsdeles.
Particionamentoemclassesde equivalência
Esse critériodivide odomíniode entradade umprograma emclassesde equivalência,apartir
das quaisoscasos de teste sãoderivados.Ele temporobjetivominimizaronúmerode casos
de teste,selecionandoapenasumcasode teste de cada classe,poisemprincípiotodosos
elementosde umaclasse devemse comportarde maneiraequivalente.Eventualmente,pode-
se tambémconsiderarodomíniode saída para a definiçãodasclassesde equivalência(ROCHA
et al.,2001).
Uma classe de equivalênciarepresentaumconjuntode estadosválidose inválidosparauma
condiçãode entrada.Tipicamente umacondiçãode entradapode serum valornumérico
específico,umafaixade valores,umconjuntode valoresrelacionados,ouumacondiçãológica.
As seguintesdiretrizespodemseraplicadas:
• Se uma condiçãode entradaespecificaumafaixade valoresourequerumvalorespecífico,
uma classe de equivalênciaválida(dentrodolimite) e duasinválidas(acimae abaixodos
limites) sãodefinidas.
• Se uma condiçãode entradaespecificaummembrode umconjuntooué lógica,umaclasse
de equivalênciaválidae umainválidasãodefinidas.
Devemosseguirtaispassosparageraçãodos testesusandoeste critério:
1. Identificarclassesde equivalência(é umprocessoheurístico)
o condiçãode entrada
o válidase inválidas

10. 2. Definiroscasos de teste
o enumeram-se asclassesde equivalência
o casos de teste para as classesválidas
o casos de teste para as classesinválidas
Em (BARBOSA etal.,2000) é apresentadoaaplicaçãodo critériode particionamentopor
equivalênciaparaoprograma identifier.c.Iremosapresentá-locomoexemplodousodeste
critériode teste.Relembrando,oprogramadeve determinarse umidentificadoré válidoou
não.
“Um identificadorválidodevecomeçarcomuma letrae conter apenasletrasoudígitos.Além
disso,deve ternomínimo1 caractere e no máximo6 caracteresde comprimento.Exemplo:
“abc12” (válido),“cont*1”(inválido),“1soma”(inválido) e “a123456” (inválido).”
O primeiropassoé a identificaçãodasclassesde equivalência.IssoestádescritonaTabela1.
Condiçõesde Entrada
Classes
Classes
Tamanhot doidentificador
(1) 1 ??t???6
(2) t > 6
Primeirocaractere c é uma letra
(3) Sim
(4) Não
Só contémcaracteresválidos
(5) Sim
(6) Não
Tabela1. Classesde Equivalênciadoprogramaidentifier.c.

11. A partirdisso,conseguimosespecificarquaisserãoos casos de teste necessários.Paraser
válido,umidentificadordeve atenderàscondições(1),(3) e (5), logoé necessárioumcaso de
teste válidoque cubratodasessascondições.Alemdisso,seránecessárioumcasode teste
para cada classe inválida:(2), (4) e (6). Assim, oconjuntomínimoé compostoporquatro casos
de teste,sendoumadas opções:
T0 = {(a1,Válido),(2B3,Inválido),(Z-12,Inválido),(A1b2C3d,Inválido)}.
Análise dovalorlimite
Por razõesnão completamente identificadas,umgrande númerode errostende aocorrernos
limitesdodomíniode entradainvésde no“centro”.Esse critériode teste exploraoslimites
dos valoresde cadaclasse de equivalênciaparaprepararos casos de teste (Pressman,2005).
Se uma condiçãode entrada especifica umafaixade valoreslimitadaemae b,casos de teste
devemserprojetadoscomvaloresae b e imediatamente acimae abaixode ae b. Exemplo:
Intervalo={1..10}; Casosde Teste à {1, 10, 0,11}.
Comoexemplo,extraídode (BARBOSA etal.,2000), iremos consideraraseguinte situação:
"...o cálculodo descontopordependenteé feitodaseguinteforma:aentradaé a idade do
dependente que deveestarrestritaaointervalo[0..24].Paradependentesaté 12anos
(inclusive) odescontoé de 15%.Entre 13 e 18 (inclusive) odescontoé de 12%.Dos 19 aos 21
(inclusive) odescontoé de 5%e dos22 aos24 de 3%..."
Aplicandooteste de valorlimite convencional serãoobtidoscasosde teste semelhantesa
este:{-1,0,12,13,18,19,21,22,24,25}.
Grafo de causa-efeito
Esse critériode teste verificaoefeitocombinadode dadosde entrada.Ascausas(condiçõesde
entrada) e os efeitos(ações)sãoidentificadose combinadosemumgrafoa partirdo qual é
montadauma tabelade decisão,e a partir desta,sãoderivadosos casosde teste e as saídas
(ROCHA etal., 2001).
Esse critérioé baseadoemquatro passos,que exemplificaremosutilizandooexemplo,
tambémextraídode (BARBOSA etal.,2000):

12. “Em um programa de compras pelaInternet,acobrançaou não do frete é definidaseguindo
tal regra:Se o valorda compra formaior que R$ 60,00 e foramcompradosmenosque 3
produtos,ofrete é gratuito.Caso contrário,o frete deverásercobrado.”
1. Para cada módulo,Causas(condiçõesde entrada) e efeitos(açõesrealizadasàs diferentes
condiçõesde entrada) sãorelacionados,atribuindo-se umidentificadorparacada um.
• Causa:valorda compra > 60 e #produtos< 3
• Efeito:frete grátis
2. Em seguida,umgrafode causa-efeito(árvorede decisão) é desenhado(Figura7).
Figura7. Árvore de Decisão – Grafo de Causa-Efeito.
1. Neste ponto,transforma-se ografonumatabelade decisão(Tabela2).
Causa
Valorda compra
> 60
> 60
<= 60
#Produtos
< 3
>= 3
--
Efeito
Cobrar frete
V
V

13. Frete grátis
V
Tabela2. Tabelade decisão parao programa de compra pelaInternet.
2. As regras da tabelade decisãosão,então,convertidasemcasosde teste.
Para a elaboraçãodos casosde teste,devemosseguirtodasasregras extraídasda tabela.Esse
critériodeve sercombinadocomosdoisoutrosjá apresentadosneste artigoparaa criação de
casos de teste válidos(extraídosdasregras) e inválidos(valoresforasdafaixadefinida).Os
casos de teste definidosaseguirrefletemsomenteasregrasextraídasda tabelade decisão.
Fica comoexercíciopensarnoscasos de teste inválidosparaeste problema.
• Casosde Teste (valor,qtdprodutos,resultadoesperado) ={(61,2,“frete grátis”);
(61,3,“cobrar frete”);(60, qualquerquantidade,“cobrarfrete”)}
Outras técnicas
Outras técnicasde teste podeme devemserutilizadasde acordocomnecessidadesde
negócioourestriçõestecnológicas.Destacam-se asseguintestécnicas:testede desempenho,
teste de usabilidade,testede carga,teste de stress,teste de confiabilidadee teste de
recuperação.Algunsautoreschegamadefinirumatécnicade teste caixacinza,que seriaum
mescladodousodas técnicasde caixa pretae caixabranca, mas,como toda execuçãode
trabalhorelacionadoàatividade de teste utilizarásimultaneamentemaisde umatécnicade
teste,é recomendávelque se fixemosconceitosprimáriosde cadatécnica.
Conclusões
O teste de software é umadas atividadesmaiscustosasdoprocessode desenvolvimentode
software,poispode envolverumaquantidade significativadosrecursosde umprojeto.Origor
e o custoassociadoa esta atividade dependemprincipalmente dacriticalidade daaplicaçãoa
serdesenvolvida.Diferentescategoriasde aplicaçõesrequeremumapreocupação
diferenciadacomas atividadesde teste.
Um ponto bastante importante paraa viabilizaçãodaaplicaçãode teste de software é a
utilizaçãode umainfraestruturaadequada.Realizartestesnãoconsiste simplesmentena
geração e execuçãode casos de teste,masenvolvemtambémquestõesde planejamento,
gerenciamentoe análise de resultados.Apoioferramental paraqualqueratividadedoprocesso
de teste é importante comomecanismoparareduçãode esforçoassociadoà tarefaem
questão,sejaelaplanejamento,projetoouexecuçãodostestes.Apóstersuaestratégiade

14. teste definida, tente buscarporferramentasque se encaixemnasuaestratégia.Issopode
reduzirsignificantemente oesforçode tal tarefa.
Alémdisso,é importante ressaltarque diferentestiposde aplicaçõespossuemdiferentes
técnicasde teste a seremaplicadas,ou seja,testarumaaplicaçãowebenvolve passos
diferenciadosemcomparaçãoaostestesde umsistemaembarcado.Cadatipode aplicação
possui característicasespecificasque devemserconsideradasnomomentodarealizaçãodos
testes.Oconjuntode técnicasapresentadoneste artigocobre diversascaracterísticascomuns
a muitascategoriasde software,masnão é completo.
Para finalizar,podemosdestacaroutrospontosimportantesrelacionadosàsatividadesde
teste que podemosabordarempróximosartigos,tais comoprocessode teste de software,
planejamentoe controle dostestese teste de software paracategoriasespecíficasde
software,comoaplicaçõesweb.Até apróxima!
Agradecimentos
AgradecemosaosprofessoresJosé CarlosMaldonadoe EllenBarbosapor teremgentilmente
autorizadoa publicaçãodeste material,cujosexemplosutilizadosestãofundamentadosem
seustrabalhos.
Referências
• BARBOSA,E.;MALDONADO,J.C.;VINCENZI,A.M.R.;DELAMARO,M.E; SOUZA,S.R.S.e JINO,
M.. “Introduçãoao Teste de Software.XIV SimpósioBrasileirode Engenhariade Software”,
2000.
• CRAIG,R.D.,JASKIEL,S. P.,“SystematicSoftware Testing”,ArtechHouse Publishers,Boston,
2002.
• IEEE Standard610-1990: IEEE StandardGlossaryof Software EngineeringTerminology, IEEE
Press.
• PFLEEGER, S. L.,“Engenhariade Software:Teoriae Prática”,Prentice Hall- Cap.08, 2004.
• PRESSMAN,R.S., “Software Engineering:A Practitioner’sApproach”,McGraw-Hill,6thed,
NovaYork, NY,2005.

15. • RAPPS,S.,WEYUKER, E.J.,“Data Flow analysistechniquesfortestdataselection”,In:
International Conference onSoftware Engineering,p.272-278, Tokio,Sep.1982.
• ROCHA,A.R. C., MALDONADO,J.C., WEBER, K. C.et al.,“Qualidade de software –Teoriae
prática”,Prentice Hall,SãoPaulo,2001.
AriloClaudioDiasNeto
É Doutor emEngenhariade Sistemase ComputaçãoformadopelaUniversidade Federal doRio
de Janeiro(COPPE).Possui 6anosde experiênciaemanálisee desenvolvimentode software.É
aindaeditortécnicodaRevistaSQL Magazine,ge [...]
O que você achou deste post? Gostei (45) (5)
+ Mais conteúdosobre Engenhariade software
Todosos comentarios(5)
Meus comentarios
DéboraSoares
Excelente artigo.Me ajudoubastante.Obrigada!
[há +1 ano] - Responder
Caroline ThompsonDe MelloBrito
Muito bomseuartigo,os conceitosestãomuitobemdefinidose corretos!!Me ajudoumuito
com o meuTCC, muitoobrigado!!
[há +1 mês] - Responder
Jose RenatoDa SilvaAlves
Prezado,

16. O conceitode erroe defeitoestãoinvertidos. Erroé um resultadodaação humanae defeitoé
a manifestaçãodoerro.
[há +1 ano] - Responder
AriloCláudioDiasNeto
José Renato,permita-mediscordarde você.
EssesconceitosestãodefinidosnopadrãoIEEE-610, Glossáriode TermosemEngenhariade
Software (http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=159342).
O que você chamou de Erro, na verdade é ENGANO(mistake eminglês),que consiste naação
humanaque provoca umdefeito.
O defeitoé umadeficiênciamecânicaoualgorítmicaexistente emalgumartefatodoprojeto
que se for ativadalevao sistemaauma falha.Um erro é um estadodo programacomo
consequênciadodefeito,ouseja,praonde ele me levouapósafalhaocasionadapelo
existênciadodefeito.
Reforçandoa origemdosconceitos,você pode encontrá-losnolivroIntroduçãoaoTeste de
Software,dosprofessoresMárcioDelamaro,José Maldonadoe MárioJino.
Att's
Arilo
[há +1 ano] - Responder
EliasBatistaFerreira
Gostei doArtigo.
Parece não existirumconsensosobre essasdefinições.NoSylabbusadefiniçãodiferenciaum
pouco:http://www.bstqb.org.br/uploads/docs/syllabus_ctfl_2011br.pdf.
[há +1 mês] - Responder
Conhece aassinaturaMVP?
Publicidade

17. Mais posts
Leiamaisem: ArtigoEngenhariade Software - IntroduçãoaTeste de Software
http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-teste-de-
software/8035#ixzz3iWHJlKe9