Introdução ao Teste de Software

393 Pages·2007·5.06 MB·Portuguese

by  Marcio Eduardo Delamaro

I
NTRODUÇÃO AO
T S
ESTE DE OFTWARE
I
NTRODUÇÃO AO
T S
ESTE DE OFTWARE
Márcio Eduardo Delamaro
José Carlos Maldonado
Mario Jino
Consultoria Editorial
Sergio Guedes
Núcleo de Computação Eletrônica
Universidade Federal do Rio de Janeiro
4ª Tiragem
(cid:2)c 2007,ElsevierEditoraLtda.
TodososdireitosreservadoseprotegidospelaLei9.610de19/02/1998.
Nenhumapartedestelivro,semautorizaçãopréviaporescritodaeditora,
poderáserreproduzidaoutransmitidasejamquaisforemosmeiosempregados:
eletrônicos,mecânicos,fotográficos,gravaçãoouquaisqueroutros.
Copidesque:
GypsiCanetti
EditoraçãoEletrônica:
MárcioDelamaro
RevisãoGráfica:
MaríliaPintodeOliveira
RenatoCarvalho
ProjetoGráfico
ElsevierEditoraLtda.
AQualidadedaInformação.
RuaSetedeSetembro,111–16oandar
20050-006RiodeJaneiroRJBrasil
Telefone:(21)3970-9300FAX:[phone]
E-mail:[email protected]
EscritórioSãoPaulo:
RuaQuintana,753/8oandar
04569-011BrooklinSãoPauloSP
Tel.:[phone]
ISBN13:978-85-352-2634-8
ISBN10:85-352-2634-6
Nota: Muitozeloetécnicaforamempregadosnaediçãodestaobra. Noentanto,podemocorrererrosdedigita-
ção,impressãooudúvidaconceitual. Emqualquerdashipóteses,solicitamosacomunicaçãoànossaCentralde
Atendimento,paraquepossamosesclarecerouencaminharaquestão.
Nemaeditoranemosautoresassumemqualquerresponsabilidadeporeventuaisdanosouperdasapessoasou
bens,originadosdousodestapublicação.
Centraldeatendimento
Tel.:[phone]
RuaSetedeSetembro,111,16oandar–Centro–RiodeJaneiro
e-mail:[email protected]
site:www.campus.com.br
CIP-BRASIL.CATALOGAÇÃO-NA-FONTE
SINDICATONACIONALDOSEDITORESDELIVROS,RJ
I48
Introduçãoaotestedesoftware/organizaçãoMárcio
EduardoDelamaro,JoséCarlosMaldonado,MarioJino
–RiodeJaneiro:Elsevier,2007–4areimpressão
ISBN978-85-352-2634-8
1.Software–Testes.I.Delamaro,Márcio,1963–.
II.Maldonado,JoséCarlos,1954–.III.Jino,Mario.
07-1623. CDD005.14
CDU004.415.538
27.04.07 15.05.07 001735
Prefácio
Temosnotadoumenormecrescimentodointeresse,porpartedosdesenvolvedores,nasques-
tõesrelacionadasàqualidadedesoftware. Emparticular, aindústriatemdespertadoparaa
extrema importância da atividade de teste que, por um lado, pode contribuir para a melho-
riadaqualidadedeumdeterminadoprodutoe,poroutro,representarumcustosignificativo
dentrodosorçamentosempresariais.
Porisso,torna-seindispensávelque,noprocessodedesenvolvimentodesoftware,sejam
adotadosmétodos,técnicaseferramentasquepermitamarealizaçãodaatividadedetestede
maneirasistematizadaecomfundamentaçãocientífica,demodoaaumentaraprodutividade
eaqualidadeeadiminuircustos.
Um dos problemas que sentimos é a escassez de mão-de-obra especializada nessa área.
Assim, o primeiro objetivo deste livro é servir como livro-texto para disciplinas de cursos
relacionadosaodesenvolvimentodesoftwarecomoCiênciaouEngenhariadaComputaçãoe
SistemasdeInformação.
Acreditamosservir, também, comoumtextointrodutórioparaprofissionaisdaáreaque
necessitam de uma fonte de consulta e aprendizado. Neste livro tal profissional poderá en-
contrarasinformaçõesbásicasrelativasàstécnicasdeteste,bemcomoformasdeaplicá-las
nosmaisvariadosdomíniosetiposdesoftware.
Podemosdividirolivroemtrêspartes. Aprimeira,compostapelosCapítulos1a5,apre-
sentaasprincipaistécnicasdeteste, mostrandoateoriaeosconceitosbásicosrelacionados
a cada uma delas. Sempre que possível, apresenta-se um histórico de como surgiu e como
evoluiu cada técnica. Na segunda parte, que vai do Capítulo 6 ao 9, discute-se como essas
técnicastêmsidoempregadasemdiversostiposdesoftwareediversosdomíniosdeaplica-
çãocomo: aplicaçõesWeb,programasbaseadosemcomponentes,programasconcorrentese
programasbaseadosemaspectos. Naterceiraparte, compostapelosCapítulos10a13, são
tratados temas intimamente relacionados ao teste de software e que devem ser, também, de
interessedosdesenvolvedores: geraçãodedadosdeteste,depuraçãoeconfiabilidade.
Emcadaumdoscapítulosprocuramosdarumavisãorelativamenteaprofundadadecada
umdostemase,também,umavisãodequaissãoosmaisimportantestrabalhosrealizadose
queconstituemoestadodaartenaárea. Umafartalistadereferênciasbibliográficasfoiin-
cluídaparapermitiraosinteressadosoaprofundamentonestaatividadetãonecessáriadentro
daindústriadedesenvolvimentodesoftwareenessetãofascinantecampodepesquisa.
ix
Os autores
Atabelaaseguirindicaosnomesdosautoreseoscapítulosparaosquaiselescontribuíram.
Capítulos
Autores
1 2 3 4 5 6 7 8 9 10 11 12 13
Adalberto (cid:2)
Adenilso (cid:2)
André (cid:2)
Auri (cid:2) (cid:2) (cid:2) (cid:2) (cid:2)
Chaim (cid:2) (cid:2) (cid:2)
Cláudia (cid:2)
Delamaro (cid:2) (cid:2) (cid:2) (cid:2) (cid:2)
Ellen (cid:2) (cid:2) (cid:2)
Jino (cid:2) (cid:2) (cid:2) (cid:2) (cid:2) (cid:2) (cid:2)
Maldonado (cid:2) (cid:2) (cid:2) (cid:2) (cid:2) (cid:2) (cid:2) (cid:2)
Masiero (cid:2)
Otávio (cid:2)
Paulo (cid:2)
Reginaldo (cid:2)
Sandra (cid:2) (cid:2)
Silvia (cid:2) (cid:2) (cid:2)
Simone (cid:2) (cid:2)
Adalberto: Adalberto Nobiato Crespo, pesquisador do CENPRA, Campinas, e professor
adjuntoepesquisadordaUSF,Itatiba([email protected]).
Ades: AdenilsodaSilvaSimão,professoradjuntoepesquisadordoICMC/USP,SãoCarlos
([email protected]).
André: André Luís dos Santos Domingues, doutorando do ICMC/USP, São Carlos
([email protected]).
Auri: AuriMarceloRizzoVincenzi,professordoutorepesquisadordaUNISANTOS,San-
tos([email protected]).
Chaim: Marcos Lordello Chaim, professor doutor do EACH/USP, São Paulo
([email protected]).
Cláudia: Maria Cláudia Figueiredo Pereira Emer, doutoranda do DCA/FEEC/UNICAMP,
Campinas([email protected]).
Delamaro: MárcioEduardoDelamaro,professordoutorepesquisadordoUNIVEM,Marília
([email protected]).
Ellen: EllenFrancineBarbosa,professoraadjuntaepesquisadoradoICMC/USP,SãoCarlos
([email protected]).
Jino: MarioJino,professortitularepesquisadordoDCA/FEEC/UNICAMP,Campinas
([email protected]).
x
Maldonado: José Carlos Maldonado, professor titular e pesquisador do ICMC/USP, São
Carlos([email protected]).
Masiero: Paulo César Masiero, professor titular e pesquisador do ICMC/USP, São Carlos
([email protected]).
Otávio: Otávio Augusto Lazzarini Lemos, doutorando em Ciência da Computação no
ICMC/USP,SãoCarlos([email protected]).
Paulo: Paulo Sérgio Lopes de Souza, professor adjunto e pesquisador do ICMC/USP, São
Carlos([email protected]).
Reginaldo: Reginaldo Ré, professor de 1o e 2o graus e pesquisador da UTFPR, Campo
Mourão([email protected]).
Sandra: SandraC.PintoFerrazFabbri,professoraadjuntaepesquisadoradaUFSCar,São
Carlos([email protected]).
Silvia: Silvia Regina Vergilio, professora adjunta e pesquisadora do DInf/UFPR, Curitiba
([email protected]).
Simone: Simone do Rocio Senger de Souza, professora adjunta e pesquisadora do
ICMC/USP,SãoCarlos([email protected]).
xi
Capítulo 1
Conceitos Básicos
MárcioEduardoDelamaro(UNIVEM)
JoséCarlosMaldonado(ICMC/USP)
MarioJino(DCA/FEEC/UNICAMP)
1.1 Introdução
Paraquepossamostratardeumassuntotãovastoquantoopropostonestelivroénecessário,
primeiro,estabelecerumalinguagemprópria. ComoaconteceemmuitasdasáreasdaCom-
putação e das ciências em geral, termos comuns adquirem significados particulares quando
usadostecnicamente.
Estecapítulotemoobjetivodeestabeleceroescoponoqualorestantedolivroseinsere,
de apresentar os principais termos do jargão da área e introduzir conceitos que serão úteis
durantealeituradorestantedotexto.
1.2 Validação, verificação e teste de software
Definitivamente,aconstruçãodesoftwarenãoéumatarefasimples. Pelocontrário,podese
tornarbastantecomplexa,dependendodascaracterísticasedimensõesdosistemaasercriado.
Porisso,estásujeitaadiversostiposdeproblemasqueacabamresultandonaobtençãodeum
produtodiferentedaquelequeseesperava.
Muitos fatores podem ser identificados como causas de tais problemas, mas a maioria
delestemumaúnicaorigem: errohumano. Comoamaioriadasatividadesdeengenharia,a
construçãodesoftwaredependeprincipalmentedahabilidade,dainterpretaçãoedaexecução
das pessoas que o constroem; por isso, erros acabam surgindo, mesmo com a utilização de
métodoseferramentasdeengenhariadesoftware.
Paraquetaiserrosnãoperdurem,ouseja,paraseremdescobertosantesdeosoftwareser
liberadoparautilização,existeumasériedeatividades,coletivamentechamadasde“Valida-
ção, Verificaçãoe Teste”, ou“VV&T”,com afinalidadedegarantirquetantoo modopelo
qualosoftwareestásendoconstruídoquantooprodutoemsiestejamemconformidadecom
oespecificado.
2 IntroduçãoaoTestedeSoftware ELSEVIER
AtividadesdeVV&Tnãoserestringemaoprodutofinal. Aocontrário,podemedevem
serconduzidasdurantetodooprocessodedesenvolvimentodosoftware,desdeasuaconcep-
ção,eenglobamdiferentestécnicas.
Costumamos dividir as atividadesde VV&T em estáticas e dinâmicas. As estáticas são
aquelas que não requerem a execução ou mesmo a existência de um programa ou modelo
executávelparaseremconduzidas. Asdinâmicassãoaquelasquesebaseiamnaexecuçãode
umprogramaoudeummodelo.
Oobjetoprincipaldestelivro–otestedesoftware–éumaatividadedinâmica.Seuintuito
éexecutaroprogramaoumodeloutilizandoalgumasentradasemparticulareverificarseseu
comportamento está de acordo com o esperado. Caso a execução apresente resultados não
especificados,dizemosqueumerrooudefeito(verSeção1.3)foiidentificado.Alémdisso,os
dadosdetalexecuçãopodemservircomofontedeinformaçãoparaalocalizaçãoeacorreção
detaisdefeitos.
Outras atividades de VV&T não são tratadas neste texto. São atividades importantes e
quepermitemaeliminaçãodeerrosdesdeasfasesiniciaisdoprocessodedesenvolvimento,
oque,emgeral,representaumaeconomiasignificativaderecursos. Algunsexemplosdetais
atividadessãoasrevisõestécnicaseoswalkthroughs.
1.3 Alguns termos do jargão
Nestaseçãoprocuramosidentificaralgunstermosimportantesequeajudarãooleitorame-
lhorcompreenderostextosdospróximoscapítulos.
Na seção anterior dissemos que diversos “problemas” podem emergir durante o desen-
volvimento de software e, em seguida, nos referimos a esses problemas como “erros”. A
literaturatradicionalestabelecesignificadosespecíficosparaesteeoutrostermosrelaciona-
doscomo: falha,defeito,erro,engano. Vamosprocuraridentificarcadaumdeles.
Definimos “defeito” (do inglês, fault) como sendo um passo, processo ou definição de
dados incorretos e “engano” (mistake) como a ação humana que produz um defeito. As-
sim,essesdoisconceitossãoestáticos,poisestãoassociadosaumdeterminadoprogramaou
modeloenãodependemdeumaexecuçãoparticular.
Oestadodeumprogramaou,maisprecisamente,daexecuçãodeumprogramaemdeter-
minadoinstante,édadopelovalordamemória(oudasvariáveisdoprograma)edoapontador
deinstruções. Aexistênciadeumdefeitopodeocasionaraocorrênciadeum“erro”(error)
duranteumaexecuçãodoprograma,quesecaracterizaporumestadoinconsistenteouines-
perado.Talestadopodelevarauma“falha”(failure),ouseja,podefazercomqueoresultado
produzidopelaexecuçãosejadiferentedoresultadoesperado.
Note-sequeessasdefiniçõesnãosãoseguidasotempotodonemsãounanimidadeentreos
pesquisadoreseengenheirosdesoftware,principalmenteemsituaçõesinformaisdodia-a-dia.
Emparticular, utiliza-se“erro”deumamaneirabastanteflexível, muitasvezessignificando
defeito,erroouatéfalha.
O“domínio”deentradadeumprogramaP,denotadopor D(P), éoconjuntodetodos
ospossívesvaloresquepodemserutilizadosparaexecutarP.Porexemplo,vamostomarum
programaquerecebecomoparâmetrosdeentradadoisnúmerosinteirosxey, comy ≥ 0,
1.4. Fasesdaatividadedeteste 3
e computa o valor de xy, indicando um erro caso os argumentos estejam fora do intervalo
especificado. Odomíniodeentradadesteprogramaéformadoportodosospossíveispares
de números inteiros (x,y). Da mesma forma, pode-se estabelecer o domínio de saída do
programa,queéoconjuntodetodosospossíveisresultadosproduzidospeloprograma. No
nosso exemplo, seria o conjunto de números inteiros e mensagens de erro produzidos pelo
programa.
Um “dado de teste” para um programa P é um elemento do domínio de entrada de P.
Um“casodeteste”éumparformadoporumdadodetestemaisoresultadoesperadoparaa
execuçãodoprogramacomaqueledadodeteste.Porexemplo,noprogramaquecomputaxy,
teríamososseguintescasosdeteste: (cid:3)(2,3),8(cid:4),(cid:3)(4,3),64(cid:4),(cid:3)(3,−1),“Erro”(cid:4). Aoconjunto
de todos os casos de teste usados durante uma determinada atividade de teste costuma-se
chamar“conjuntodeteste”ou“conjuntodecasosdeteste”.
A Figura 1.1 mostra um cenário típico da atividade de teste. Definido um conjunto de
casos de teste T, executa-se o programa em teste com T e verifica-se qual é o resultado
obtido. Se o resultado produzido pela execução de P coincide com o resultado esperado,
entãonenhumerrofoiidentificado. Se,paraalgumcasodeteste,oresultadoobtidodiferedo
resultadoesperado,entãoumdefeitofoirevelado. ComosugereaFigura1.1,emgeral,fica
porcontadotestador,baseadonaespecificaçãodoprograma(S(P))ouemqualquerforma
de documento que defina seu comportamento, a análise sobre a correção de uma execução.
Na verdade, o testador na figura está desempenhando um papel que costumamos chamar
de “oráculo”, isto é, aquele instrumento que decide se a saída obtida de uma determinada
execuçãocoincidecomasaídaesperada.
Figura1.1–Cenáriotípicodaatividadedeteste.
1.4 Fases da atividade de teste
A atividadede testeé complexa. São diversosos fatoresque podem colaborar para a ocor-
rênciadeerros. Porexemplo,autilizaçãodeumalgoritmoincorretoparacomputarovalor
dasmensalidadesaserempagasparaumempréstimoouanão-utilizaçãodeumapolíticade
segurança em alguma funcionalidade do software são dois tipos distintos de engano e, de
certaforma,encontram-seemníveisdiferentesdeabstração. Oprimeirotipodeerroprova-
velmenteestáconfinadoaumafunçãoourotinaqueimplementadeformaincorretaumadada
funcionalidade. Nosegundocaso,mesmoqueexistaumacertapolíticadesegurançaimple-
mentada de maneira correta, é preciso verificar se todos os pontos nos quais essa política
deveriaseraplicadafazem-nodemaneiracorreta.
4 IntroduçãoaoTestedeSoftware ELSEVIER
Porisso,aatividadedetesteédivididaemfasescomobjetivosdistintos. Deumaforma
geral,podemosestabelecercomofasesotestedeunidade,otestedeintegraçãoeotestede
sistemas. Otestedeunidadetemcomofocoasmenoresunidadesdeumprograma,quepo-
dem ser funções, procedimentos, métodos ou classes. Nesse contexto, espera-se que sejam
identificados erros relacionados a algoritmos incorretos ou mal implementados, estruturas
de dados incorretas, ou simples erros de programação. Como cada unidade é testada sepa-
radamente, o teste de unidade pode ser aplicado à medida que ocorre a implementação das
unidadesepeloprópriodesenvolvedor,semanecessidadededispor-sedosistematotalmente
finalizado.
No teste de integração, que deve ser realizado após serem testadas as unidades indivi-
dualmente,aênfaseédadanaconstruçãodaestruturadosistema. Àmedidaqueasdiversas
partesdosoftwaresãocolocadasparatrabalharjuntas,éprecisoverificarseainteraçãoentre
elas funciona de maneira adequada e não leva a erros. Também nesse caso é necessário
um grande conhecimento das estruturas internas e das interações existentes entre as partes
do sistema e, por isso, o teste de integração tende a ser executado pela própria equipe de
desenvolvimento.
Depois que se tem o sistema completo, com todas as suas partes integradas, inicia-se o
testedesistema. Oobjetivoéverificarseasfuncionalidadesespecificadasnosdocumentos
de requisitos estão todas corretamente implementadas. Aspectos de correção, completude
e coerência devem ser explorados, bem como requisitos não funcionais como segurança,
performance e robustez. Muitas organizações adotam a estratégia de designar uma equipe
independentepararealizarotestedesistemas.
Alémdessastrêsfasesdeteste,destacamos,ainda,oquesecostumachamarde“testede
regressão”.Essetipodetestenãoserealizaduranteoprocesso“normal”dedesenvolvimento,
massimduranteamanutençãodosoftware. Acadamodificaçãoefetuadanosistema, após
asualiberação,corre-seoriscodequenovosdefeitossejamintroduzidos. Poressemotivo,
énecessário,apósamanutenção,realizartestesquemostremqueasmodificaçõesefetuadas
estãocorretas,ouseja,queosnovosrequisitosimplementados(seforesseocaso)funcionam
comooesperadoequeosrequisitosanteriormentetestadoscontinuamválidos.
Independentementedafasedeteste,existemalgumasetapasbemdefinidasparaaexecu-
çãodaatividadedeteste.Sãoelas:1)planejamento;2)projetodecasosdeteste;3)execução;
e4)análise.
1.5 Técnicas e critérios de teste
PodemosnotarnaFigura1.1que,aosetestarumprogramaP,selecionam-sealgunspontos
específicosdodomínioD(P)paraaexecuçãodeP.Idealmente,oprogramaemtestedeveria
serexecutadocomtodososelementosdeD(P)paragarantirquenãocontémdefeitos. Em
geral, tal abordagem é infactível por causa da cardinalidade de D(P). Por exemplo, no
programa que computa xy, o domínio é formado por todos os pares de números inteiros
(x,y),oqueproduzumconjuntodecardinalidade2n∗2n,ondenéonúmerodebitsusado
pararepresentarumnúmerointeiro. Emumaarquiteturacom32bitsissorepresenta264 =
18446744073709551616. Se cada caso de teste pudesse ser executado em 1 milissegundo,
precisaríamosde5.849.424séculosparaexecutá-lostodos.