Testes de software

117 visualizações

Publicada em

Testes de software

Publicada em: Software
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
117
No SlideShare
0
A partir de incorporações
0
Número de incorporações
10
Ações
Compartilhamentos
0
Downloads
3
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Testes de software

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×