UNIVERSIDADEDEPASSOFUNDO

INSTITUTODECINCIASEXATASEGEOCINCIAS CURSODECINCIADACOMPUTAO

ANLISECOMPARATIVADEFERRAMENTASGRATUITAS PARATESTEDESOFTWAREORIENTADOAOBJETOS

LucianoBhler

PassoFundo,novembrode2007.

LucianoBhler

AnliseComparativadeFerramentasGratuitas paraTestedeSoftwareOrientadoaObjetos

Monografia apresentada ao curso de Cincia da Computao, do Instituto de Cincias Exatas e Geocincias da Universidade de Passo Fundo, como requisito parcial para obteno do grau de Bacharel em Cincia da Computao, sob orientaodoMS.AlexandreLazarettiZanatta.

PassoFundo 2007

RESUMO

Neste trabalho inicialmente so apresentados conceitos de testes de software, suas caractersticaseparticularidades.Tambmapresentaumestudodetalhadodetestesorientados aobjetos(OO).Aps,discriminase ferramentas gratuitasqueamparamaatividadedeteste OO. Por fim, descrita a anlise comparativa de algumas ferramentas selecionadas. As anlises e reflexes apontam que nos testes de unidade, a ferramenta TestNG obteve os melhoresresultadospoistevesuacriaobaseadana JUniteabrange funcionalidadesquea concorrente no contempla. J nos testes de cobertura, a ferramenta EMMA demonstrou maioreficinciaporquepermiteageraoderelatriosemmodotextoepossuiexecuoem menor tempo que a Cobertura para atividades equivalentes e, finalmente, nos testes de performance, o JMeter apresentou resultado favorvel devido a existncia de diversos recursos no providos pela WAS, como o caso dos Listeners. Com isso, pertinente a utilizaodeferramentasgratuitasparaaautomaodetestesdesoftware.

Palavraschave:testedesoftwareOO,ferramentasgratuitasdetestesdesoftwareOO.

LISTADEFIGURAS

Figura1. FalhasemSistemasEspaciais ................................................................................ 18 Figura2. Diretrizesparadefiniodeclassesdeequivalncia............................................... 23 Figura3. Partiesdeequivalncia:valoreslimite............................................................... 24 Figura4. Notaoparagrafosdecausaeefeito.................................................................... 25 Figura5. Grafodecausaeefeitodescontonavenda .......................................................... 26 Figura6. Tabeladedecisoparaografodecausaeefeito .................................................... 26 Figura7. Notaodegrafodefluxo...................................................................................... 28 Figura8. Complexidadeciclomtica. .................................................................................... 31 Figura9. Estgiosdeteste. ................................................................................................... 35 Figura10. Testedeunidade ................................................................................................ 36 Figura11. Testedeunidadeutilizaodedriversestubs ................................................. 38 Figura12. Fluxodedadosdafasedetestedeunidadedesoftware...................................... 39 Figura13. Exemplodehierarquiadosmdulos................................................................... 41 Figura14. Testebottomup................................................................................................. 42 Figura15. Testetopdown. ................................................................................................. 44 Figura16. Testesanduche. .............................................................................................. 45 Figura17. Testebigbang. .................................................................................................. 46 Figura18. Interfacedoobjetoestaometeorolgica.......................................................... 61 Figura19. DiagramadeestadodaestaoMeteorolgica. .................................................. 62 Figura20. ExemplosdeseqnciasdodiagramadeestadodaestaoMeteorolgica......... 62 Figura21. Complexidade:OOvs.Funcional. ..................................................................... 63 Figura22. CaractersticasdasferramentasOO.................................................................... 73 Figura23. Critriosdetesteparaferramentasproprietriaselivres..................................... 74 Figura24. Critriosdetesteparaferramentasgratuitas. ...................................................... 75

Figura25. Parmetrosdeavaliaodasferramentas............................................................ 78 Figura26. FrmulasdeConversodetemperatura.............................................................. 79 Figura27. EscalaCelsiuseFahrenheit................................................................................ 79 Figura28. PartiesdeEquivalnciadasescalasCelsiuseFahrenheit. ............................... 79 Figura29. Interfacepararepresentaraentidadetemperatura............................................... 80 Figura30. ClassequerepresentaaescalaCelsius............................................................... 81 Figura31. ClassequerepresentaaescalaFahrenheit. ......................................................... 82 Figura32. ClassedeconversodetemperaturacomerronomtodoconvertToCelsius. .... 83 Figura33. Classedeconversodetemperaturafuncionandocorretamente.......................... 84 Figura34. JUnitClassedetesteTemperatureTr ansfor mer Test..................................... 86 Figura35. TestemanualvlidoparaconversodeFehrenheitparaCelsius. ........................ 87 Figura36. JUnitRelatriodetestedoprojetointeiro. ...................................................... 87 Figura37. JunitRelatriodeexecuodopacote testetermometro................................. 88 Figura38. JunitRelatriodeexecuodaclasseTemperatureTransformerTest........... 88 Figura39. TestNG ClassedetesteTemperatureTransformerTest. ................................... 89 Figura40. TestemanualinvlidoparaconversodeFehrenheitparaCelsius. ..................... 90 Figura41. TestNG Relatriodeprojeto. .......................................................................... 90 Figura42. TestNG Relatriodeclasse. ............................................................................ 91 Figura43. Comparativodasferramentasdetesteunitrio. .................................................. 92 Figura44. ClasseTemperatureTransformerTestparatestedecobertura. ........................ 94 Figura45. EmmaResumodacoberturadetestesdoprojetointeiro .................................. 95 Figura46. EmmaResumodacoberturadetestesdopacote testetermometro. ................. 96 Figura47. EmmaResumodacoberturadetestesdaclasse TemperatureTransformer.java .......................................................................................... 96 Figura48. Cobertura Resumodacoberturadetestesdasclassesselecionadas................... 98 Figura49. Cobertura Resumodacoberturadetestesdopacote testetermometro. ............ 98 Figura50. Cobertura ResumodacoberturadetestesdaclasseTemperatureTransfor mer.99 Figura51. Comparativodasferramentasdetestedecobertura. ......................................... 100 Figura52. JMeter AdicionarThreadGroup. ................................................................... 103 Figura53. JMeter ThreadGroup.................................................................................... 104 Figura54. JMeterHTTPProxyServer........................................................................... 105 Figura55. JMeter TiposdeAssertions. .......................................................................... 106 Figura56. JMeterUniformRandonTimer. .................................................................... 107 Figura57. JMeterRelatrios.......................................................................................... 107

Figura58. JMeterRelatrioAssertionResults ................................................................ 108 Figura59. JMeterRelatrioGraphResults .................................................................... 109 Figura60. JMeterRelatrioAggregateGraph ............................................................... 110 Figura61. JMeterRelatrioViewResultsTree. .............................................................. 111 Figura62. MicrosoftWASBrowserRecorder................................................................ 112 Figura63. MicrosoftWASServidorerequisiesrealizadas. ........................................ 112 Figura64. MicrosoftWASDetalhesderequisio......................................................... 113 Figura65. MicrosoftWASSettings. .............................................................................. 114 Figura66. MicrosoftWASGruposdeusurios. ............................................................. 115 Figura67. MicrosoftWASRelatrioOverview. .......................................................... 116 Figura68. MicrosoftWASRelatrioPageSummary. ................................................. 117 Figura69. Comparativodasferramentasdetestedeperformance. .................................... 119

LISTADEABREVIATURAS

ENIAC:ElectricalNumericalIntegratorandCalculator FTP:FileTransferProtocol HTML:HyperTextMarkupLanguage IDE:IntegratedDevelopmentEnvironment IEEE:InstituteofElectricalandElectronicsEngineers JAR:JavaArchive JPL:JetPropulsionLaboratory JVM:JavaVirtualMachine NIST: NationalInstituteofStandardsandTechnology OO:Orientaoaobjeto SGDB:SistemaGerenciadordeBancodeDados WAS:WebApplicationStress XML:ExtensibleMarkupLanguage

SUMRIO

INTRODUO .................................................................................................................... 11 1. 1.1. TESTESDESOFTWARE.................................................................................... 13 Definies ............................................................................................................ 14 Bugs,falhas,errosedefeitos......................................................................... 15 TesteXDepurao........................................................................................ 16 Objetivosdoteste ......................................................................................... 17 Princpiosdoteste......................................................................................... 19 Testabilidade................................................................................................. 20

1.1.1. 1.1.2. 1.1.3. 1.1.4. 1.1.5. 1.2.

Tcnicasdeteste................................................................................................... 21 Caixapreta.................................................................................................... 21 Particionamentodeequivalncia ........................................................... 22 Anlisedevalorlimite .......................................................................... 23 Grafodecausaeefeito .......................................................................... 24

1.2.1.

1.2.1.1. 1.2.1.2. 1.2.1.3. 1.2.2.

Caixabranca ................................................................................................. 27 Testedecaminho.................................................................................. 29 TestedeFluxodeControle.................................................................... 32 TestedeFluxodeDados ....................................................................... 33

1.2.2.1. 1.2.2.2. 1.2.2.3. 1.3.

Estgiosdeteste ................................................................................................... 35 Testedeunidade ........................................................................................... 36 Testedeintegrao ....................................................................................... 40 Integraobottomup ............................................................................ 41 Integraotopdown.............................................................................. 43 Integraosanduche .......................................................................... 44

1.3.1. 1.3.2.

1.3.2.1. 1.3.2.2. 1.3.2.3.

1.3.2.4. 1.3.3. 1.3.4. 1.3.5. 1.4. 1.5. 2. 2.1. 2.2.

Integraobigbang............................................................................... 45

Testedesistema............................................................................................ 46 Testedeaceitao ......................................................................................... 50 Testedeinstalao ........................................................................................ 51

TestedeRegresso ............................................................................................... 52 ConsideraesFinais ............................................................................................ 53 TESTEDESOFTWAREORIENTADOAOBJETOS .......................................... 54 ConceitosBsicosdeOO...................................................................................... 54 ProblemasProvenientesdoParadigmaOO ........................................................... 56 Encapsulamento............................................................................................ 57 Herana ........................................................................................................ 58 Polimorfismo ................................................................................................ 58

2.2.1. 2.2.2. 2.2.3. 2.3.

EstgiosdeTesteOO ........................................................................................... 59 TestedeClasse ............................................................................................. 60 TestedeIntegrao ....................................................................................... 63

2.3.1. 2.3.2. 2.4. 2.5. 3. 3.1. 3.2. 3.3. 3.4. 4. 4.1.

TcnicasdeTestesOO ......................................................................................... 65 ConsideraesFinais ............................................................................................ 66 AUTOMATIZAODAFASEDETESTES....................................................... 67 FerramentaseEspecificaes ............................................................................... 67 AnliseComparativadasFerramentas .................................................................. 72 CritriodeDescartedeFerramentas ..................................................................... 74 ConsideraesFinais ............................................................................................ 76 ANLISECOMPARATIVADASFERRAMENTAS.......................................... 77 TestedeUnidade .................................................................................................. 78 Definiodocasodeteste............................................................................. 84 Recursosecomparao ................................................................................. 85 JUnit ..................................................................................................... 85 TestNG ................................................................................................. 88 Comparativo......................................................................................... 91

4.1.1. 4.1.2.

4.1.2.1. 4.1.2.2. 4.1.2.3. 4.1.3. 4.2.

Concluses................................................................................................... 93

TestedeCobertura................................................................................................ 93 Definiodocasodeteste............................................................................. 93 Recursosecomparao ................................................................................. 94 EMMA.................................................................................................. 94

4.2.1. 4.2.2.

4.2.2.1.

10

4.2.2.2. 4.2.2.3. 4.2.3. 4.3.

Cobertura .............................................................................................. 97 Comparativo......................................................................................... 99

Concluses................................................................................................. 100

TestedePerformance ......................................................................................... 101 Definiodocasodeteste........................................................................... 101 Recursosecomparao ............................................................................... 102 JMeter................................................................................................. 102 MicrosoftWEBApplicationStress(WAS).......................................... 111 Comparativo....................................................................................... 117

4.3.1. 4.3.2.

4.3.2.1. 4.3.2.2. 4.3.2.3. 4.3.3. 4.4.

Concluses................................................................................................. 119

ConsideraesFinais .......................................................................................... 120

CONSIDERAESFINAIS .............................................................................................. 121 REFERNCIASBIBLIOGRFICAS................................................................................. 123

11

INTRODUO

As progressivas mudanas das relaes sciopolticoeconmicas a nvel mundial tm transformado de forma macia e irreversvel a vida cotidiana das populaes. As transaes bancrias internacionais, a fuso de grandes empresas de setores estratgicos, a criao de blocos econmicos intercontinentais, a popularizao da Internet, entre tantos outros exemplos, so provas de que se est caminhando a passos largos para o apogeu da integrao de poderes. Inegvel o fato que um dos principais itens para a concretizao desteestadoatualousodesoftwares. O constante aumento da gama de reas que possuem softwares como elementos fundamentais de concretizao de planos e projetos pode ser observado atravs dos ltimos incidentesocasionadosporproblemasemsistemasespaciais(AMBROSIO,2007).Asperdas decorrentesdaocorrnciadeerrosprovenientesdedefeitosgeradosnacriaodossoftwares tmvaloresfinanceirosmuitoexpressivos,sendoinconcebvelquetaisaconteam. A responsabilidade que gira em torno do desenvolvimento de softwares e de seus componentes diretamente relacionada funoque este ir desempenhar no meio em que estar inserido. O principal fator para garantir a segurana do funcionamento adequado dos softwares a minimizao da ocorrncia de erros ao nvel mnimo. Isto somente pode ser alcanadomedianteumeficienteplanodetestes. A inexistncia de erros em softwares deve ser sempre almejada, porm no h possibilidade disto concretizarse. O princpio de Pareto, que afirma que para muitos fenmenos,80%dasconseqnciasadvmde20%dascausas,perfeitamenteaplicvelaos problemas encontrados em softwares. Cabe aos planejadores de casos de testes definirem diretrizes para a localizao do maior nmero possvel de operaes indesejveis com o mnimodeesforo,elevandoaconfiabilidadedoprodutofinal.

12

Embora sejam utilizadas tcnicas, critrios e ferramentas ao longo de todo o processodedesenvolvimentodesoftware,comintuitodeevitarqueerrossejamintroduzidos nomesmo,asatividadesenvolvidassoexecutadasporpessoasimperfeitas,sendooresultado de seu trabalho tambm imperfeito. Por isto a atividade de testes tem fundamental importncia para a eliminao de erros existentes. A finalidade dos testes expor defeitos latentesemumsoftwareantesdeesteserentregue(SOMMERVILLE,2003). Considerando que o paradigma Orientado a Objetos (OO) tem obtido crescente aceitao por parte de pesquisadores e desenvolvedores a saber, pelo grande nmero de aplicaes desenvolvidas luz deste, optouse pela linguagem de programao Java por seguir o paradigma OO, alm de ser portvel (independente de plataforma) e no ser uma linguagem paga. O presente trabalho visa analisar algumas ferramentas existentes e os critrios utilizados para testar softwares produzidos a partir deste contexto, tambm descrevendocarnciasencontradasnasferramentasanalisadas,casonecessrio. Umavezqueaetapadetesterepresentaaltimarevisodeespecificao,projetoe codificao, a sua execuo deve ser bem planejada e monitorada, estando a produtividade desta atividade fortemente condicionada utilizao de ferramentas que, aps algumas alteraes do sistema, garantem que o mesmo continue rodando corretamente, proporcionando maior segurana caso alguma alterao seja necessria. Alm disto, a utilizao de ferramentas de testes viabiliza a realizao de testes empricos e auxilia a conduodetestesfuturos. Aseguir,umabrevedescriodaestruturadopresentetrabalho.NoCaptulo1so apresentados conceitos bsicos acerca da atividade de teste de software. Tambm so descritastcnicasdetestedecaixapretaedecaixabranca.Porfim,sodefinidososestgios deteste. OCaptulo2abordaconceitosbsicosdaOrientaoaObjetos(OO),asimplicaes negativasdecorrentesdautilizaodesteparaotestedeaplicaesdesenvolvidasluzdaOO e algumas particularidades relevantes da OO para a fase de testes. Em seguida, mostra os estgios de teste utilizados na OO. A apresentao de tcnicas de testes OO forma a parte finaldocaptulo. NoCaptulo3,descritodeformabreveaimportnciadaautomatizaodafasede testes,dandoseqnciaparatalacatalogaoeapresentaosucintadasferramentasaserem analisadas. Subseqentemente apresentada uma comparao preliminar das ferramentas selecionadas e a metodologia a ser utilizada para o processo da anlise comparativa das ferramentas.

13

1. TESTESDESOFTWARE

A Engenharia de Software tem evoludo significativamente nas ltimas dcadas procurando estabelecer tcnicas, critrios, mtodos e ferramentas para a produo de software.Acrescenteutilizaodesistemasbaseadosemcomputaoempraticamentetodas as reas da atividade humana tem provocado uma crescente demanda por qualidade e produtividade,tantodopontodevistadoprocessodeproduoquantodopontodevistados produtosgerados(MALDONADO,2007,p.3). Aimportnciadotestedesoftwareesuasimplicaesqualidadedosoftwarepodem seranalisadasapartirdaseguinteafirmao:

O desenvolvimento de sistemas de software envolve uma srie de atividades de produo em que oportunidades para injetar a faliabilidade humana so enormes. Errospodemviraocorreratnoinciodoprocesso,ondeosobjetivos...podemser errnea ou imperfeitamente especificados, bem como [em] estgios posteriores de projeto e desenvolvimento... Por causa da inabilidade humana de realizar e de se comunicarcomperfeio,odesenvolvimentoacompanhadoporumaatividadede garantiadequalidade.(DEUTSCHapudPRESSMAN,2002,p.429).

Harrold (2000, p. 1) afirma que processo de teste executado para dar suporte a garantiadequalidadedoprodutodesoftware.SegundoMyers(1979,p.5),aatividadedeteste o processo de executar um programa com a inteno de encontrar erros, sendo, conforme Pressman (2002, p.429), um elemento crtico da garantia de qualidade de software e que representaarevisofinaldaespecificao,projetoegeraodecdigo.

14

Aatividadedetestesdesoftwareumadasatividadesmaisonerosasdoprocessode produodeumsoftware.Estudosindicamquetestesconsomemmaisde50%(cinqenta)do custo de desenvolvimento de software (HARROLD, 2000, p. 1). Na tentativa de reduzir estescustos,tmsidopropostostcnicas,critrioseferramentasqueauxiliamnaconduoe avaliaodotestedesoftware.

1.1.

Definies

Osprofissionaisenvolvidosnaatividadedeprogramaoempenhamseparaproduzir softwares que tenham um funcionamento apropriado em todas as situaes em que forem executados(PFLEEGER,2004,p.270).Porm,arealidadeoutra.Muitassoasrazesque levamosprogramasafuncionaremdeformaanmala.Umadelasestrelacionadaquesto deprazosmaldimensionados,oquelevaexecuodasatividadesconstantesnoprojetoem tempo inferior ao idealmente necessrio, refletindo de forma negativa na qualidade do produto. Outro fator que provoca diferenas entre as sadas reais e as esperadas, geradas pela execuo do programa, a comunicao, tanto entre a equipe de desenvolvimento com o clienteeusuriosquantoentreosmembrosdaequipe.Noprimeirocaso,aspartesenvolvidas vivememrealidadesadversase,muitasvezes,oclientenopossuiseguranasobreoqueele realmente necessita, dificultando o seu contentamento com o software construdo. Entre os membros da equipe, por sua vez, os problemas podem ser causados, por exemplo, pela presena de uma especificao errada ou pela implementao errnea de um algoritmo. A complexidade dos projetos tambm interfere nas caractersticas finais do produto, pois normalmente,exigeaalocaodevriaspessoas,eistoaumentaaprobabilidadedeocorrerem falhas.Sendoassim,aexistnciadedefeitosestcondicionadanosomenteaosoftware,mas tambmsexpectativasdeusurioseclientes. O comportamento inadequado dos softwares tem sido referido sob vrias terminologiasadversas,sendoabordadasalgumasaseguir.

15

1.1.1. Bugs,falhas,er rosedefeitos

Em geral, quando afirmase que determinado software falhou quer dizer que ele no executadaformacomoeraesperado.Assim,falhaoresultadodeumoumaisdefeitosem algum aspecto do sistema, levandoo aoperar de forma diferente da esperada (PFLEEGER, 2004). Segundo o padro IEEE Std 610.121990 (IEEE, 1990), um defeito (fault) em um programa um passo, processoou definio de dados incorreta. Uma falha (failure) ocorre quandoumsistemaoucomponenteproduzumasadadiferentedaesperada.Erro(error )a diferenaentreovalorcomputado,observadooumensuradoeacondioouvalorverdadeiro, especificadoouterico.Eumengano(mistake)umaaohumanaqueproduzumresultado incorreto. O termo bug1 comumente usado para referirse a sistemas que comportamse de formaanmala.Ousodestetermofoipartedaengenhariamecnicaporvriasdcadaspara descreverdefeitosinexplicveisesuaorigematribudaaThomasEdison,quandoproblemas deleituraemseufongrafoforamcausadasporuminseto,em1878.Osurgimentodotermo freqentemente atribudo de forma errnea causa do mau funcionamento no Mark II, em 1945,quandoum insetoficoupresonoscontatosdeumrel.Outramquinaque contribuiu paraousodapalavrafoioENIAC(EletronicNumericalIntegratorandComputer),oprimeiro computadordigitalcompletamenteeletrnico.Seufuncionamentoerabaseadoemvlvulas,e estas atraam muitos insetos. Como dezenas de vlvulas queimavam a cada hora o computador, que ocupava o espao de uma sala, era freqentemente aberto e montes de insetos mortos eram varridos de dentro. Afirmavam que esses insetos provocavam curto circuitos nas placas, levando a falhas nos programas. Utilizar o termo bug designa que o defeito foi inserido por uma fonte externa, fora do controle dos desenvolvedores (WIKIPEDIA).Porisso, muitosengenheiroseprofissionaisdarea negamseautilizareste termo. As terminaes falha, erro e defeito tambm so utilizadas na rea de tolerncia a falhas.Atolernciaa falhasahabilidadedeumsistemacontinuaremoperaomesmo na ocorrnciadefalhas.Jalote(1994)defineostermosconformesegue:

Extradode:http://pt.wikipedia.org/wiki/Bug

16

Falha (failure): ocorre quando o comportamento do sistema desviase do que foi previamente especificado, ou seja, o sistema falha quando no consegue atender ao servio desejado.acausaalgortmicadoerro. Erro(error ):Oestadointernodosistemaditoerrneose,dianteda funcionalidade normalespecificadaparautilizaodosistema,esteestadopodelevaraumdefeito.Erroa partedoestadoqueestincorreta.Seexisteumerronumestadodesistema,entoexisteuma seqnciadeaesquepodeserexecutadapelo sistemaeque conduzirparauma falhade sistema, ao menos que alguma ao corretiva seja empregada. O estado lgico de um elementodiferedovalorintencional. Defeito ou mau funcionamento (fault): a causa de um erro um defeito. Ocorre quandoocomportamentodosistemasedesviadesuaespecificao.Odefeitooqueoser humanovousente.

Estaseqnciapodeserexemplificadadaseguinteforma:umarquivoenviadopara ser impresso, via editor de texto, e a impresso no ocorreu. FALHA pode ser o driver da impressora que se perdeu. ERRO o fato do arquivo no ser transferido para o buffer da impressoraeoDEFEITOfoioarquivonoserimpresso. Devido a no existncia de um consenso na literatura acerca destes termos, neste trabalhoprocurousemanterossignificadosreferentesreadeTolernciaFalhasconforme acimadescritos,salvoemrefernciasatrabalhosdeoutrosautores.

1.1.2. TesteXDepurao

2 Testar oprocessodeexecutarumprogramacomaintenodeencontrarerros.Os

erros em um software podem ser classificados em: erros sintticos, erros semnticos ou lgicos e erros de execuo. O primeiro caso compreende os erros relativos a no conformidade de uma instruo com as regras sintticas. Em linguagens de programao compiladas,esseserrossodetectadosautomaticamentepelocompilador.Nosegundocaso,o programa est sintaticamente correto, mas ocorre um defeito, pois o resultado obtido

SegundoMyers(1979,p.5),Testingistheprocessofexecutingaprogramwiththeintentoffindingerrors.

17

diferente do pretendido. Por fim, os erros de execuo surgem durante a execuo do programa. A depurao, por sua vez, ocorre como conseqncia de um teste bemsucedido. Pressmanafirmaque

[...]o processo de depurao comea com a execuo de um caso de teste. Os resultadossoavaliadoseumafaltadecorrespondnciaentreaexecuoesperadae a obtida encontrada. Em muitos casos, os dados no correspondentes so um sintoma de uma causa adjacente ainda oculta. O processo de depurao tenta relacionarsintomacomcausa,levandoassimcorreodoerro.(2002,p.491).

Portanto, o teste de software visa detectar a presena de possveis erros em um software,abrangendotodosostiposdeerros,enquantoadepuraotemofocoemidentificar, localizarecorrigiroserrosencontrados.

1.1.3. Objetivosdoteste

Para definir os objetivos dos testes de software, necessria uma anlise de alguns fatos ocorridos em virtude da no realizao de testes criteriosamente planejados e organizados. Um exemplo de fracasso de projeto em virtude da no execuo criteriosa de testesocorreuem1999,quandooSatliteClimticoInterplanetrioMarsClimateOrbiter ,ao invs de entrar em trajetria de rbita estvel em Marte, aproximouse demasiadamente do planeta, sendo queimado por sua atmosfera. As equipes independentes da NASA e do Jet

PropulsionLaboratory(JPL)anunciaram,apsinmerasinvestigaes,acausadoacidente:o
erro de trajetria havia sido causado pela aplicao de diferentes sistemas de unidades de medidasemsoftwaresutilizadosnamisso.SegundodivulgadopelaprpriaNASA,esteerro custouU$165milhesaoscofresdaempresa(OBERG,2007).Esteeoutroscasosdefalhas emsistemasespaciaispodemservistosnaFigura1.

18

Fonte: Ambrosio(2007). Figura1. FalhasemSistemasEspaciais

Segundo o National Institute of Standarts and Technology (NIST), perdas causadas

3 porerrosdesistemas nosEstadosUnidosduranteoanode2002somaramnadamenosque

U$ 59.5 bilhes de dlares. O NIST afirma que uma melhor infraestrutura para a rea de testes geraria uma economia de U$ 22.2 bilhes ao pas, ou seja, mais de um tero do montante(NATIONALINSTITUTEOFSTANDARTSANDTECHNOLOGY,2007). De acordo com Neves, o objetivo da atividade de teste pode descrito da seguinte forma:

Segundo o IEEE (1990), software so programas de computador, procedimentos, e documentao possivelmente associada e dados que pertencem operao de um sistema de computador e sistema uma coleo de componentes organizados para realizar uma funo especfica ou grupo de funes, representando todooambienteemqueosoftwareestimplantado.

19

no incio de cada fase verificar se esta etapa do projeto reflete exatamente os requisitosedefiniesdafaseimediatamenteanterior,paracomissogarantirqueo produto encomendado e o gerado pela atividade de desenvolvimento do software sejamosmesmos,atravsdosdiferentesnveisderefinamentodoprojeto verificarsenoexistemerrosdelgicanoprojetoe cdigo,nofluxodedados,no entendimentoderequisitos,decodificao,tipogrficosoudeinterfaceemtodasas fasesdoprojeto identificar e interferir na presena do erro, iniciandose a depurao, sendo que quantoantesfordescobertaafalha,menoscustososerparaadequla teremmenteque,umavezqueerrarhumanoeatividadededesenvolvimentode software um exerccio bastante complexo, os erros existem e devem ser descobertos. Portanto, o sucesso em um teste consiste em descobrir os erros e corrigilos.(2007).

1.1.4. Princpiosdoteste

Antes do planejamento e execuo da fase de testes, necessrio que os princpios bsicosdetesteestejambementendidos,poissoestesqueguiamafasedetestedesoftware. Analogamenteconstruodeumacasa,ondeestapodesermuitoespaosaebonita,masse notiverumalicercefirmenoresistirpormuitotempo,aatividadedetestesdeveserfixada sobprincpiosbsicosquedemcondiesdesustentabilidadeaoprojetodetesteeexecuo domesmo,semosquaisimplicarnoruirdetodaaconstruo. Pressman(2002)sugerealgunsprincpiosdeteste: Todosostestesdevemserrelacionadosaosrequisitosdocliente Ostestedevemserplanejadosmuitoantesdoinciodoteste OprincpiodeParetoseaplicaaotestedesoftware Testecompletonopossvel
4 Otestedevecomearnovarejoeprogrediratoatacado .

Myers(1979)acrescentaoutrosprincpios:
5 Umapartenecessriadeumcasodeteste adefiniodeumasadaouresultado

esperado Oprogramadordeveevitardetestarseuprprioprograma Inspecionecompletamenteosresultadosdecadateste A probabilidade da existncia de mais erros em uma seo de um programa proporcionalaonmerodeerrosjencontradosnaquelaseo
4 5

Ostestesdevemcomearempequenasunidadesindividualmenteeprogredirparadiversasunidadesintegradas. Os casos de teste so especificaes das entradas para o teste e da sada esperada do sistema, mais uma declaraodoquevaisertestado.

20

No planeje nenhum caso de teste sob a suposio de que nenhum erro ser encontrado Testarumatarefaextremamentecriativaeintelectualmentedesafiadora.

1.1.5. Testabilidade

Estudos mostram que testes consomem mais de 50% dos custos de desenvolvimento de software (HARROLD, 2000). Reduzindose a complexidade das atividades de teste, o custodestaatividadetendeadiminuir.Atestabilidadeafacilidadequeumprogramatemde ser testado. Tannouri (2007) compara a testabilidade de software com o trabalho de prospeco de ouro feito antes da minerao, onde estabelecida a probabilidade de que a escavaodedeterminadolocalsejarecompensante.Ogelogopodedizer:Nestevalepode ou no haver ouro, mas se houver ser no topo e em outro local afirmar que: se no encontrar ouro no primeiro palmo desta terra, ento no h ouro. De modo semelhante, a testabilidadeforneceograudedificuldadequeserenfrentadoparadetectarodefeito(IEEE, 1990),ouseja,quantoesforoserdespendidoparacadatesteeseosoftwareexpem suas falhasquandosoinseridasasentradasdeteste,sendoumprogramadealtatestabilidade.Por outrolado,umprogramatembaixatestabilidadequandotendeaocultarasfalhasdetectadas duranteostestes. Pressman (2002, pg. 432) lista um conjunto de caractersticas que levam a um softwaretestvel,conformesegue. Operabilidade:Quantomelhorfunciona,maiseficientementepodesertestado Observabilidade:Oquevocvoquevoctesta Controlabilidade:Quantomaisvocpodecontrolarosoftware,maisotestepode serautomatizadoeotimizado Decomponibilidade: Controlando o escopo do teste, podemos isolar problemas maisrapidamenteerealizarretestagem maisracionalmente Simplicidade:Quantomenoshatestar,maisrapidamentepodemostestlo Estabilidade:Quantomenosmodificaes,menosinterrupesnoteste Compreensibilidade:Quantomaisinformaestemos,maisracionalmentevamos testar.

21

1.2.

Tcnicasdeteste

Pressman(2002,p.435)descrevequeexistemduasformasdetestarqualquerproduto quepassaporengenharia.Naprimeiradelas,oconhecimentodafunoparaqueoproduto foiprojetadoparaefetuarofereceinformaesparaarealizaodetestesquedemonstremque cadafunoestplenamenteoperacional,aomesmotempoemqueerrossoprocuradosem cadafuno.Nasegundaforma,oconhecimentointernodeumprodutoofereceinformaes paratestarsetodasasoperaesinternasestosendorealizadasconformeasespecificaese se todos os componentes internos esto sendo exercitados corretamente. A primeira abordagemchamadadetestedecaixapretaeasegundadetestedecaixabranca. Segundo Pfleeger (2004, p. 277), a viso sobre o objeto que est sendotestado, seja eleumcomponente,umgrupodecomponentes,umsubsistemaouumsistema,podeafetaro modocomoostestessorealizados.Seoobjetoforvistoapartirdeumaperspectivaexterna, comoumacaixapretacujocontedodesconhecido,otesteconsistiremalimentaroobjeto comentradaseobservarseassadascorrespondemquelasesperadas.Poroutrolado,podese observaroobjetoasertestadocomoumacaixabranca,sendoutilizadaaestruturadoobjeto paraplanejaroscasosdeteste. Pressman(2002,p.436)eMyers(1979,p.37)sugeremumaestratgiadetestesonde sejam combinadas as tcnicas de caixapreta e caixabranca, sendo os casos de teste estruturais utilizados como testes complementares, aps os testes funcionais. A seguir, so apresentadasastcnicasdecaixapretaedecaixabranca,respectivamente.

1.2.1. Caixapr eta

Estatcnica,quetambmpodeserchamadadetestefuncional,testecomportamental, testedecaixa fechadaoublackbox,testaoprogramaoupartedele sobopontodevistado usurio, desconsiderando a estrutura interna ou a forma de implementao. Seu comportamento somente pode ser determinado estudandose suas entradas e sadas relacionadas (SOMMERVILLE, 2003). Os casos de teste so desenvolvidos a partir da especificao do sistema. Este o nico tipo de teste possvel quando no se dispe do cdigofonte (AGUIAR, 2007). Koscianski (2006) afirma que o teste de caixapreta

22

particularmentetilparaencontrarproblemas,como:funesincorretasouomitidas,errosde interface,errosdecomportamentooudesempenhoeerrosdeiniciaoetrmino. Segundo Myers (1979, p. 8), para que todos os erros sejam encontrados, devese utilizarocritriodetesteexaustivodeentradas.Estecritrioousodetodasascombinaes possveis de entrada como casos de testes, sendo englobadas as combinaes vlidas e invlidas,oque,namaioriadoscasos,gerariaumnmeroinfinitodecasosdeteste. Parasolucionaroproblemageradopelocritriodetesteexaustivodeentradas,foram definidassoluesquederivemcasosdetestesignificativos,ouseja,omaiornmerodeerros fosseencontradocomumfinitonmerodecasosdeteste(MYERS,1979,p.9).Algunsdestas solues, particionamento de equivalncia, anlise de valorlimite e grafo de causa e efeito, soapresentadasaseguir.

1.2.1.1.

Particionamentodeequivalncia

Particionamentodeequivalnciaummtododetestefuncionalquedivideodomnio de entrada de um programa em classes de dados, das quais casos de teste podem ser derivados. (PRESSMAN, 2002, p.454). Myers (1979) define classes de equivalncia como grupos de dados em que um valor representativo, quando testado, equivalente a qualquer outrovalordesuaclasse. Sommerville(2003)afirmaqueumaabordagemsistemticadostestesparaadeteco de defeitos baseiase em identificar todas as parties de equivalncia que tenham de ser manuseadasporumprograma.Tambmseidentificampartiesemqueasentradasestejam foradaspartiesvlidas,paratestarocomportamentodoprogramacomentradasinvlidas. Os casos de teste so projetados de modo que as entradas e as sadas fiquem dentro dessas parties. Oobjetivoprincipaldestaabordagemsimplificarereduziraquantidadedecasosde teste,sendoselecionadosvaloresrepresentativosdasclassesdefinidas,vlidaseinvlidas,de forma que atravs do teste de um elemento,o comportamento detodo o domnio da classe seja observado. Isto reduz o domnio de entrada e de sada e, conseqentemente, o tempo

23

associadoatividade.Umaclassedepartiopodeenglobar,porexemplo,valoresnumricos
6 referentesaCPF s,quetemformatoetamanhonicos.

AFigura2. demonstracomoasclassesdeequivalnciapodemserdefinidassegundo asdiretrizesapresentadasporPressman(2002).

Condiodeentrada

Quantidade de classes de Quantidade de classes de equivalnciavlidas equivalnciainvlida 2 2 1 1

Intervalodevalores Umvalorespecfico Ummembrodeumconjunto

1 1 1 1
Figura2. Diretrizesparadefiniodeclassesdeequivalncia

Booleana
Fonte: BaseadoemPressman(2002).

1.2.1.2.

Anlisedevalorlimite

Estatcnicaumcomplementodaspartiesdeequivalncia,poisaoinvsdeovalor paratesteserescolhidoaleatoriamente,eleselecionadoapartirdocritriodeidentificao dosvalores localizadosnos limitesdasclassesdeequivalncia,pois,comoPressman(2002, p.456)cita,umgrandenmerodeerrostendeaocorrernasfronteirasdodomniodeentrada aoinvsdenaregiointermediria.Nososomentefocalizadasascondiesdeentrada,os casosdetestesoderivadosconsiderandotambmodomniodesada(MYERS,1979). Sommerville (2003) exemplifica a anlise de valorlimite citando um programa que aceitede4a10entradas,quesonmerosinteirosdecincodgitos,maioresque10mil.As partiesdeequivalncia identificadasparaestasituaoeospossveis valoresdedadosde entradaparatestesoapresentadosnaFigura3.

Cadastro de Pessoas Fsicas. http://www.receita.fazenda.gov.br/Aplicacoes/ATCTA/CPF/

Mais

informaes

em

24

Fonte: Sommerville(2003,p.381) Figura3. Partiesdeequivalncia:valoreslimite

Oscasosdetestedevemporprovaosvaloresfronteirios,tantooslimitesmximoe mnimodapartiodeequivalncia,quantoosvaloresimediatamenteacimaeimediatamente abaixodolimite.

1.2.1.3.

Grafodecausaeefeito

Grafos de causaefeito oferecem uma representao concisa das condies lgicas entreentradasesadasedasaescorrespondentes.Pflegger(2004,p.325)descrevequeas entradas so chamadas de causas e as sadas e transformaes, denominadas de efeitos. A representaogrficadestasrelaeschamadadegrafodecausaeefeito. Myers(1979)afirmaqueastcnicasdeparticionamentodeequivalnciaedeanlise de valorlimite no exploram combinaes de entradas, pois contemplam unicamente a anlise de valores de determinada classe isoladamente. Utilizase, ento,o grafo de causa e efeito. As etapas de criao de um grafo de causaefeito, conforme Pfleeger (2004, p.325), obedecemaseguinteordem.Inicialmente,osrequisitossoseparadosdemodoquecadaum descrevaumafuno.Aps,todasascausaseefeitossodescritosenumerados,tornandose nsdografo.Osnsquerepresentamcausassocolocadosesquerdaeosquerepresentam

25

efeitos,direita,esotraadasasrelaeslgicasnografo,utilizandoanotaoapresentada naFigura4.

Fonte: Pfleeger(2004,p.325) Figura4. Notaoparagrafosdecausaeefeito

Umexemplodautilizaodegrafosdecausaeefeitoparaaanlisedeumavenda, onde um desconto de 10% dado casoo valortotal da compra seja igual ou superior a R$ 50,00eaquantidadedeitensvendidosmaiorque0emenorque30.Estasituaogeraografo representadona Figura5. A entrada1 representaovalortotalda venda ea entrada2a quantidade de itens da venda. A sada 1 define uma venda em que o desconto cedido e somenteirocorrerseovalordeentrada1formaiorouigualaR$50,00eaquantidadede itens da venda for maior que 0 (zero) e menor que 30. A sada 2 representa uma venda efetuadaemqueodescontonocedidoesomenteocorrequandoovalordavendaformenor queR$50,00eaquantidadedeitensdavendaformaiorque0(zero)emenorque30.Asada

26

nmero3mostraumamensagemdeerroeocorrerquandoaquantidadedeitensforiguala 0oumaiorque30.

Fonte: Primria Figura5. Grafodecausaeefeito descontonavenda

Com base nas informaes do grafo construdo, definida a tabela de deciso. A Figura6.atabeladedecisodografodecausaeefeitoapresentadonaFigura5.,utilizadoo exemplo da anlise de venda. Cada coluna da tabela de deciso representa um conjunto de estadosdecausaseefeitos.AcondiodacausamarcadacomVquandoelaforchamada ouverdadeiraecomFquandoforsuprimidaoufalsa.Senohouverdiferenaseacausa for chamada ou suprimida, ser marcada com X. Os efeitos podem assumir P, para indicarpresena,ouA,paraindicarausncia.

Teste1 Causa1 Causa2 Efeito1 Efeito2 Efeito3

Fonte: Primria.

Teste2 F V A P A

Teste3 X F A A P

V V P A A

Figura6. Tabeladedecisoparaografodecausaeefeito

27

N O nmero de combinaes possveis de entradas de 2 , sendo N o nmero de

entradas.Assim,utilizandografosdecausaeefeitoonmerodecasosdetestequedevemser considerados reduzido substancialmente, pois as combinaes desnecessrias so descartadas. Porm, a utilizao de grafos de causa e efeito no prtica para sistemas que incluemdemoras,interaesouloops(PFLEEGER,2004).

1.2.2. Caixabranca

Existem situaes que a utilizao de testes de caixapreta no permite a gerao de um conjunto representativo de casos de teste. Uma dessas situaes apresentada por Pfleeger (2004, p. 278) a partir do exemplo de um programa que aceita como entrada, um valor que representa uma receita bruta e que produz a quantia de imposto de renda devido comosada.Porexemplo,oalgoritmoparaclculodeimpostodependedafaixadoimpostoe dolimitedesta,bemcomodasporcentagensassociadas,sendopartedoprocessamentointerno do programa. O conhecimento adquirido a partir da anlise pelo foco de caixapreta deste programa insuficiente para a derivao de casos de teste adequados. Para solucionar este problema, a estrutura interna do objeto de teste deve ser analisada, sendo esta tcnica chamadadetestedecaixabranca. Otestedecaixabranca,tambmconhecidocomotesteestrutural,decaixaclaraoude caixa de vidro, consiste de uma abordagem de teste em que estes so derivados do conhecimentodaestruturaedaimplementaodosoftware(SOMMERVILLE,2003p.382). Ostestadoresexaminamaestruturainternadoprogramaeosdadosdetestesodirigidospara examinaralgicadoprograma,seminteressenasespecificaesdoprograma(LEWIS,2000, p.20). Koscianski (2006, p. 345) afirma que, em funo dos testes de caixabranca serem projetadosapartirda estruturadocomponente,elespermitemuma verificao mais precisa decomportamentodoproduto. Segundo Beizer (1990), independente do ponto de vista do teste, se funcional ou estrutural,grafosdefluxoumarepresentaobaseadaemcrculos(nodos)esetas(ligaes) so importantes ferramentas conceituais. Conforme Pressman (2002, p. 437), o grafo de fluxo mostraofluxodecontrole lgicousandoanotaoilustradana Figura7.,ondecada construo estruturadatem um smbolo correspondente no fluxo de dados. Myers (1979, p. 20)ePressman(2002,p.437)definemquecada crculo,chamadodendografode fluxo,

28

representaumblocodecomandosquesoexecutadosseqencialmenteecadaseta,chamada aresta, arco ou ligao, indica a transferncia de controle entre segmentos e sempre deve terminaremumn.

Fonte: Martins(2002,p.6) Figura7. Notaodegrafodefluxo

A Figura 7. mostra a notao de grafo de fluxo, divididos em bloco seqencial, de seleo e de repetio. Num bloco seqencial, existe um fluxo de entrada,o processamento seqencial (sem desvios) das instruesrepresentadas pelo n e a posteriortransferncia de controle, sem ocorrncia de desvios. Os blocos de seleo ou condio possuem um n predicado,quecaracterizadoporduasoumaisarestassaindodele,queanalisadeterminada condioetransfereofluxoparaoprximonconformeestadeciso.Exemplosdeblocosde seleo so as estruturas IFTHENELSE e SWITCHCASE. Por sua vez, os blocos de repetio tambm possuem um n predicado, mas o fluxo pode ser desviado para o incio destebloco,quepodeserexecutadoquantasvezesforemnecessrias.

29

1.2.2.1.

Testedecaminho

Sommerville (2003, p. 382), Pressman (2002, p. 436) e Pfleeger (2004, p. 288)

7 definem teste de caminho como uma estratgia de teste estrutural cujo objetivo exercitar 8 todo caminho distinto ao longo do cdigo, pelo menos uma vez, em algum teste.

Sommerville (2003, p. 382) afirma que se todo caminho independente for executado, ento todasasdeclaraesdocdigodevemtersidoexecutadas,etodasasdeclaraescondicionais testadas para os casos verdadeiros e falsos. Myers (1979, p. 9) chama o teste de todas as combinaespossveisdecaminhodetesteexaustivodecaminhos. Comexceodecomponentesmuitotriviaisquenocontenhamloops,aexecuode testesdecaminhosparatodasascombinaespossveisumobjetivoimpossvel,poisexiste uma quantidade infinita de possveis combinaes de caminhos em programas com loops (SOMMERVILLE,2003,p.383).Beizer(1990)ePressman(2002,p.437)apresentamcomo soluootestedecaminhobsico. Segundo Pressman (2002, p. 437), o mtodo de teste de caminho bsico permite ao projetista de casos de testes definir um conjunto mnimo de caminhos de execuo que garantam o exerccio de cada comando do programa pelo menos uma vez durante o teste, atravsdeumamedidadecomplexidadelgica.Essamedidapodeserobtidacalculandosea
9 complexidadeciclomtica dografodefluxodoprograma(SOMMERVILLE,2003,p.384).

Complexidade ciclomtica, conforme Pressman (2002), a mtrica de um software que fornece uma medida quantitativa da complexidade lgica de um programa. Usada no contexto do mtodo de teste de caminho bsico, o valor computado da complexidade ciclomtica define o nmero de caminhos independentes do conjunto bsico do programa e fornece o limite superior de testes que devem ser executados para assegurar que todos os comandossejamexecutadospelomenosumavez. Sommerville(2003,p.384)descrevequeoclculodacomplexidadeciclomtica(CC) dequalquergrafo(G)conectadopodeserefetuadoconformeaseguintefrmula:

SegundooIEEE(1990),umcaminho(path)umaseqnciadeinstruesque podeserrealizadanaexecuo deumprogramadecomputador. 8 Caminhodistintooucaminhoindependenteaquelequeatravessapelomenosumnovoramonografodefluxo (SOMMERVILLE,2003,p.383). 9 PropostainicialmenteporTomMcCabe(MCCABE,1976apudPRESSMAN,2002,p.437)

30

CC(G)=NmerodearestasNmerodens+2

Outras duas maneiras de calcular a complexidade ciclomtica so apresentadas por Pressman(2002,p.440).

10 1. Onmeroderegies dografodefluxocorrespondecomplexidadeciclomtica

2. A complexidade ciclomtica, V(G), para um grafo de fluxo G, definida como:

V(G)=P+1
11 ondePonmerodenspredicados contidonografodefluxoG.

Onmeromnimodecaminhosindependentesparapercorrertodasasdeclaraesdo grafodeexemplo,apresentadonaFigura8.,definidoaseguir: Ografoapresentadopossuiquatroregies(R1,R2,R3eR4). CC(fig.8)=11ramos9ns+2 =4 V(fig.8)=3nspredicativos(1,2e4)+1=4

10

Regiessoasreaslimitadasporarestasens.Areaforadografotambmcontada.(PRESSMAN,2002, p.437). 11 Cadan que contm uma condio chamado de n predicado e caracterizado por duas ou mais arestas saindodele.(Pressman,2002,p.437).

31

Assim,ografodemonstradonaFigura8. possuicomplexidadeciclomticaiguala4.

Fonte: AdaptadodePressman,(2002,p.439). Figura8. Complexidadeciclomtica.

Aps calcular o nmero de caminhos independentes no cdigo atravs da complexidadeciclomtica,oprximopassoaserrealizadoprojetaroscasosdetestepara executarcadaumdessescaminhos,sendoonmeromnimodecasosdetestenecessriopara que todos os caminhos do programa sejam testados igual complexidade ciclomtica do programa(SOMMERVILLE,2003,p.385). Otestedecaminho bsiconolevaem contaonmeroderepetiesexecutadas em umlao,sendonecessriastcnicasquefocalizemexclusivamenteavalidadedeconstrues de lao. Para Pressman (2002, p. 449), laos so a base da maioria dos algoritmos implementadosemsoftware,maspoucaatenolhesdadanaconduodostestes. Beizer(1990)divideoslaosemquatrotipos: Laossimples:ostestesnecessriosparaseraplicadoalaossimplescomlimite deexecuonsoassimdefinidos: 1. Puleolaocompletamente. 2. Apenasumapassagempelolao. 3. Duaspassagenspelolao. 4. mpassagenspelolao(sendom<n). 5. n 1,n,n+1passagenspelolao.

32

Laos aninhados: Conforme Pressman (2002, p. 449), a quantidade de testes possveis cresce geometricamente medida que o nvel de aninhamento cresce, sendo necessrio um nmero de testes impraticvel. Beizer (1990) prope a seguintesoluo: 1. Comearnolaomaisinterno.Ajustarosoutroslaosparaseuvalormnimo. 2. Testarolaocomoumlaosimples 3. Mantero lao testado em um outro valortpico e testaro prximo lao mais externo,mantendoosoutroslaosemseuvalormnimo. 4. Seguirattestartodososlaos.

Ciclos Concatenados: Se os laos forem independentes um dos outros, podese utilizar a abordagem para teste de lao simples. Porm, caso os laos no sejam independentes recomendada a utilizao da abordagem aplicada a ciclos aninhados. Ciclosdesestruturados:nestecaso,ocomandodeveserreprojetadodeformaque reflitaumadastrsabordagensanteriores.

1.2.2.2.

TestedeFluxodeControle

Apesar do teste de caminho bsico ser uma das tcnicas de teste de estrutura mais utilizadas devido simplicidade do seu conceito e aplicao, ela no suficiente por si s (PRESSMAN,2002,p.444).Outrasvariaesdetesteestruturalampliamacoberturadeteste emelhoramaqualidadedotestedecaixabranca. Segundo Domingues (2002), os critrios baseados em fluxo de controle utilizam somenteinformaessobreocontroledaexecuodoprograma,comocomandosoudesvios, para derivar os requisitos de teste. Myers (1979, p. 37) apresenta as principais tcnicas de testedefluxodecontrole. A tcnica de cobertura de comando, tambm conhecida como Todososns, exige quetodososcomandosdevemserexecutadospelomenosumavez.Nacoberturadedeciso todasasestruturasdedecisodevemsertestadasparatodasassuaspossibilidadesdesadas. NocasodedecisodetipoIF,devemsertestadasassadaspositivas(if)eassadasnegativas

33

(else).Estatcnicatambmpodeserutilizadaparadecisesqueenvolvammaisdetrssadas, porexemploestruturasSWITCHCASE.Pontosfracosdestescritriossodemonstradospor Myers(1979,p.38),nosquaiserrosdelgicaededecisonoseriamacusadospeloscasos deteste.Nacoberturadecondio,cadacondio,emumadeciso,deveassumirtodosos resultadospossveisaomenosumavez,sendomaisabrangenteque osanteriores. Detalhes sobre a utilizao combinada destas tcnicas so apresentados por Myers (1979),comoacoberturadedecisoecondio,enoserotratadasnestetrabalho.

1.2.2.3.

TestedeFluxodeDados

Segundo Maldonado (2007, p. 13), os testes baseados unicamente em fluxo de

12 controle no so eficazes para revelar a presena at mesmo de erros simples e triviais ,

mesmoemprogramaspequenos.Martins(2007b,p.6)afirmaqueomodelodetestedefluxo de controle apresenta anomalias quanto ao uso de variveis. As principais anomalias so: o usodevarivelnoinicializada,atribuiodevaloraumavarivelmaisdeumavezsemque tenhahavidoumarefernciaaessavarivelentreasatribuies,aliberaooureinicializao deumavarivelantesqueelatenhasidocriadaouinicializadaealiberaooureinicializao de uma varivel antes que ela tenha sido usada. O teste de fluxo de dados supre estas deficinciasdotestedefluxodecontrole(MALDONADO2007,p.13). Conforme Pressman (2002, p.447), o mtodo de teste de fluxo de dados seleciona caminhos de teste de um programa conforme a localizao das definies e do uso das variveisnoprograma.Martins(2007b,p.5)defineprogramacomoumaseqnciadeaes realizadassobrevariveis,ouseja,ofluxodecontroleacrescidodeinformaessobreondeas variveissodefinidaseondeessasdefiniessoutilizadas. Rapps e Weyuker apresentaram o grafo de DefinioUso (RAPPS E WEYUKER, 2007, p. 274), que consiste em uma extenso do grafo de fluxo, sendo adicionadas informaessobreofluxodedadosdoprograma,associandoospontosdoprogramaondeum valor atribudo a uma varivel, chamado de definio da varivel, e os pontos onde este valorutilizado,chamadodeusodavarivel(MALDONADO,2007,p.13).Cadaocorrncia

12

Os termos simples e triviais so utilizados para definir aqueles erros que no despendem de um esforo considerveldetempoeconhecimentoporpartedotestadorparasualocalizao(FONTE:PRIMRIA).

34

deuma varivelpodeser classificadacomouma ocorrnciadedefinio,ocorrnciadeuso computacionaleocorrnciadeusopredicado(RAPPSEWEYUKER,2007,p.274). Conforme Beizer (1990), a definio de uma varivel ocorre quando aparecer numa declarao de dados (X = 10) ou quando aparecer do lado esquerdo de uma indicao de atribuio. O uso predicativo ocorre quando a varivel utilizada diretamente como argumentoemumusopredicado,afetandodiretamentenofluxodocontroledoprograma.Por fim, o uso computacional quando a varivel aparece do lado direito de uma indicao de atribuio,comopartedeumclculo,quandoumarquivogravadolidoouescrito,eassim pordiante. AsprincipaistcnicasdaabordagemdefluxodedadossoapresentadasporPfleeger (2004,p.288),Beizer(1990)eRappseWeyuker(2007)conformesegue: Teste de caminho definiouso: todo o caminho de definio de todas as variveisparacadausodessadefiniodeveserexecutado. Teste de todos os usos: ao menos um caminho de cada definio deve ser percorridoparatodosseussubseqentesusos.Essasassociaessoestabelecidas entre uma atribuio de valor a uma varivel e o uso posterior desta varivel atravsdeumcaminholivrededefinio,ondeavarivelnosejaredefinida. Testedetodasasdefinies:pelomenosumcaminhodetodadefiniodecada variveldeveserpercorridoparapelomenosumuso,sejaeleusocomputacional ouusopredicado. Testedeusodetodosospredicadosedealgunsusoscomputacionais:paratoda variveletodadefiniodessavarivel,umtesteincluinomnimoumcaminhoda definio para todos os usos computacionais. Se houver definies no cobertas poressadescrio,entosoincludosusosdepredicadosdemaneiraquetodasas definiessejamcobertas. Teste de todos os usos computacionais e de alguns usos de predicados: para toda varivel e toda definio dessa varivel, um teste inclui pelo menos um caminhodadefinioparatodousocomputacional.Sehdefiniesnocobertas poressadescrio,so includosusosdepredicado,de formaquetodadefinio sejacoberta.

35

1.3.

Estgiosdeteste

O teste de software geralmente envolve vrios estgios (Pfleeger, 2004, p. 275). A Figura9.ilustraestesestgioseaseqncianaqualelessoexecutados.

Fonte: Pressman(2002). Figura9. Estgiosdeteste.

Inicialmente so efetuados os testes de unidade, tambm conhecidos como teste de mdulosoutestedecomponentes.Estaprimeiraetapatemcomoobjetivoverificarsecadaum doscomponentesqueirocomporosoftwarefuncionadeformaadequada. Aps finalizada a fase de teste dos componentes, estes so integrados. Esta fase denominada teste de integrao e visa verificar se os componentes do software trabalham juntosdeformaadequada,conformeasespecificaes. O ponto final da integrao dse quando todos os componentes foram integrados, formandoosoftware.Porsuavez,osoftwareagregadoaoutrosfatores(porex.hardwaree usurios),formaosistema(PRESSMAN,2002,p.488).Ocorrementoostestesdealtonvel. Executase o teste de sistema, que uma srie de testes com intuito de assegurar que o sistemarealizaaquiloqueconstaemseusobjetivosoriginais(MYERS,1979,p.110). Depoisdotestedesistema,ondeosistemacomparadoaosseusrequisitos,realizase o teste de aceitao para assegurar aos clientes que o sistema solicitado o que foi desenvolvido(PFLEEGER,2004,p.316).Porfim,osistemainstaladoem seuambientereal

36

defuncionamento,ondesoexecutadosostestesdeinstalao(MYERS,1979,p.119).Estes estgiosdetestesodescritosconformesegue.

1.3.1. Testedeunidade

SegundoPressman(2002,p.475)eLewis(2000,p,82),otestedeunidadefocalizanos menoresblocosconstrudosdeum software:omduloouocomponente.ParaSommerville (2003, p. 376), a fase de teste de unidade tem por objetivo testar o funcionamento de componentes, que podem ser funes ou grupos de mtodos de um mdulo ou de objetos. Myers (1979, p.77) define o teste de unidade como um processo para testar subprogramas individuais,subrotinasouprocedimentos(procedures)emumprograma.ParaBeizer(1990), umaunidadegeralmenteotrabalhodeumprogramadoreconsisteemcemoumenoslinhas de cdigo fonte. O autor afirma que oteste unitrio feito para mostrar que a unidade no satisfaz a sua especificao funcional e/ou que a estrutura implementada difere da estrutura pretendidanoprojeto. Sommerville (2004, p. 382) afirma que, geralmente, os testes de unidade utilizam tcnicasdetesteestruturalparaseremexecutadoseapresentaamaneiradederivaodecasos detesteeexecuodetestedeunidadenaFigura10. Osdadosdetestesoderivadosapartir deumaanlisedocdigodocomponente,eposteriormentesoutilizadoscomoentradapara ostestes,quesoexecutadosegeramassadasdoteste.

Fonte: Sommerville(2003,p.382). Figura10. Testedeunidade

37

ConformePressman(2002,p.478),umcomponentenoumprograma isolado,mas partedeumsoftware.Pfleeger(2004,p.291)citaqueocorremsituaesondeocomponente queestsendotestadopodenecessitardeoutroqueainda no foidesenvolvidoetestado,e situaesemqueocomponentequeestsendotestadodeveserchamadoporoutrodenvel superior,quetambmnofoidesenvolvidoetestado.Emambososcasosdevemsercriados cdigos especiais para que os testes sejam executados. Estes cdigos so conhecidos, respectivamente, como stub e driver (Myers, 1979, p.89), Pressman (2002, p. 278), Sommerville(2003,p.386),Pfleeger(2004,p.291),Beizer(1990). ParaSommerville(2003,p.386),umstubpossuia mesma interfacedocomponente, mascomfuncionalidadelimitadaeumdriver detestesimulaoambientedoscomponentese chamaocomponentequedevesertestado.Pressman(2002,p.478)afirmaquestubs,tambm chamados de pseudocontrolados, servem para substituir os mdulos que so chamados pelo componente a ser testado e que driver , tambm chamado de pseudocontrolador, um programa que aceita os dados do caso de teste, passa estes dados para o componente a ser testadoeimprimeosresultadosrelevantes. AutilizaodedriversestubsexemplificadaporMyers(1979,p.89)naFigura11., que representa um subprograma formado por mdulos (retngulos). No exemplo, o mdulo AchamaosmdulosB,CeD.OmduloBchamaomduloEeomduloD chama o mdulo F. Em determinada situao, supemse que o mdulo B foi desenvolvidoeestparasertestado,pormomduloAeomduloEnoencontramse disponveis ainda. Ento, devese desenvolver um driver que simule o comportamento do mduloAeumstubparasimularocomportamentodomduloEeacoplarambosB, criandoassim,condiesparaqueestesejatestado.

38

Myers(1979,p.90) Figura11. Testedeunidade utilizaode drivers e stubs

Pfleeger define os passos do teste de unidade comparandoo a um exerccio de programaopropostoemaula,procedendosedaseguintemaneira:

Primeiro, voc examina o seu cdigo, revisandoo, tentando identificar defeitos no algoritmo, nos dados e na sintaxe. Pode at mesmo comparar o cdigo com as especificaes e com seu projeto, para assegurar que considerou todos os casos relevantes. Em seguida, compila o cdigo e elimina os efeitos de sintaxe remanescentes. Finalmente, voc desenvolve os casos de teste para mostrar que a entradaapropriadamenteconvertidanasadadesejada.(2004,p.279).

As atividades do teste de unidade apresentadas na Figura 12. , so definidas pelo IEEE(1987)emtrsfaseseoitoatividadesbsicas: a) Execuodoplanejamentodeteste Divididaem(1)planogeraldeabordagem,recursosecronograma,(2)determinaras caractersticasaseremtestadase(3)detalharoplanogeral,estafasetemoobjetivodedefinir o cronograma de testes unitrios detalhadamente, incluindo informaes sobre a abordagem de teste utilizada, os recursos necessrios para a execuo dos testes e as caractersticas do teste.Ascaractersticasdotesteenglobamoestudodosrequisitosfuncionais,oselementosa seremtestadoseasdefiniesdosdadosdeentradaedesada. b) Obteroconjuntodetestes Esta fase dividida em duas atividades, (4) projetar os casos de teste e (5) implementaroplanodetalhadoeoprojeto.Define,dentrooutrosatributos,asespecificaes

39

do projeto de teste unitrios, as especificaes dos procedimentos de teste separadamente e verifica os dados de teste. Caso existam, so utilizadas informaes acerca de testes anteriormenteexecutados(sumriodeteste)paraacriaodoscasosdeteste. c) Mediraunidadedeteste Esta fase dividida em trs atividades, que so: (6) executar os procedimentos de teste,(7)checarresultadose(8)avaliarotestedeesforoeunidade.Nestafase,asunidades soexecutasbaseadasnoscasosdeteste.Asinformaesgeradassoavaliadasepodemser iguais ou diferentes do planejado. Por fim, os dados do teste so coletados, organizados e armazenadospararefernciaereusoemfuturostestes.

Fonte: AdaptadodeIEEE(1986) Figura12. Fluxodedadosdafasedetestedeunidadedesoftware

Acercadacomplexidadedotesteunitrio,Pressmanafirmaque
O teste de unidade simplificado quando um componente com alta coeso projetado. Quando apenas uma funo implementada por um componente, o nmerodecasosdetestereduzidoeoserrospodemsermaisfacilmenteprevistose descobertos.(2002,p.479).

40

Sommerville (2003, p.385) conclui que, aps todos os componentes individuais do programa serem testados, eles devem ser integrados para gerar um sistema parcial ou completo.

1.3.2. Testedeintegrao

O teste de integrao uma tcnica sistemtica para a construo da estrutura do software e que conduz paralelamente testes para a descoberta de erros associados s interfaces. O objetivo integrar as unidades, gerando a estrutura do programa determinada peloprojetoPressman(2002,p.480).Omaiorproblemadaintegrao,segundooautor,soas interfaces,sobreasquaisafirma

Dadospodemserperdidosatravsdeumainterfaceummdulopodeterumefeito imprevisto ou adverso sobre outro subfunes, quando combinadas, podem no produzirafunoprincipaldesejadaimprecisoaceitvelindividualmentepodeser amplificada paranveis inaceitveis estruturas de dados globais podem apresentar problemas.Infelizmente,alistaprossegue.(PRESSMAN,2002,p.479).

Para Sommerville (2002, p.385), a maior dificuldade que surge nos testes de integrao a localizao dos erros descobertos durante o processo. Pfleeger (2004, p.290) afirma que essa integrao deve ser planejada e coordenada de maneira que, mediante a ocorrnciadeumafalha,suponhaseoqueacausou. SegundoMyers(1979,p.89),ostestesdeintegraosodivididosemincrementaise noincrementais. Na integrao incremental, uma configurao mnima do sistema integrada inicialmente e testada. Em seguida, outros componentes so adicionados e novos testes so realizados aps cada adio (SOMMERVILLE, 2003, p.385). Pfleeger (2004, p. 290),Myers(1979,p.89),Sommerville(2003,p.386)ePressman(2002,p.480)apresentam asestratgiastopdown ebottomupeacombinaodestascomorepresentantesdetestesde integraoincrementais.Naintegraonoincrementaltodososcomponentessointegrados e o programa inteiro testado de uma nica vez (PRESSMAN, 2002, p. 480). A essa abordagemdadoonomedebigbang (MYERS,1979,p.89).

41

A Figura 13. apresenta um exemplo de hierarquia de mdulos em um software. Os mdulosdonvelmaisaltocontrolamosdenvelmaisbaixo,chamandoosquandonecessrio utilizarumadesuasfuncionalidades.

Fonte: AdaptadodePfleeger(2004,p.291). Figura13. Exemplodehierarquiadosmdulos.

Pfleeger(2004,p.290)afirmaqueaordememqueoscomponentessotestadosafeta aescolhadoscasosdetesteedasferramentasequeotamanhodosistemainterferenadeciso acerca de qual das estratgias de teste de integrao apresentadas utilizar. A seguir so apresentadasasabordagensbottomup,topdown,sanducheebigbang.

1.3.2.1.

Integraobottomup

A estratgia de teste de integrao bottomup consiste na integrao e teste dos mdulosdenvelinferiornahierarquiaesubseqentesubirnahierarquiademdulos,atque omdulofinalsejatestado(SOMMERVILLE,2003,p.386).Pfleegerdefineestaestratgia afirmandoque

(...)cada componente no nvel inferior da hierarquia do sistema testado individualmente.Osprximoscomponentesaseremincludosnostestessoaqueles que chamam os que foram previamente testados. Essa abordagem seguida repetidamente, at que todos os componentes sejam includos no teste (2004, p. 291).

42

AFigura14.ilustraumexemplodetestedeintegrao.Primeiramentesotestadosos componentes de nvel inferior: E, F e G. Caso os componentes para chamlos no encontremseprontos,sodesenvolvidoseutilizadosdrivers paraarealizaodostestesde cadaumdeles.Opassoseguinteconsisteemtestaroscomponentesdoprximonvelsuperior combinados com os componentes que eles chamam: B (chama E e F), D (chama G)eC.Porfim,todososcomponentessotestadosjuntos.

Fonte: Pfleeger(2004,p.292). Figura14. Testebottomup.

DeacordocomSommerville(2003,p.386),aintegraobottomupnorequerqueo projetodearquiteturaestejacompleto,sendopossvel iniciarostestesemumestgioinicial do processo de desenvolvimento. Pfleeger (2004, p.291) afirma que, no havendo os componentes que chamem os programas de nvel inferior a serem testados, so utilizados

drivers. Myers (1979, p. 98) tambm afirma que para a execuo do teste de integrao bottomup,cadamdulonecessitadeum driver parachamlo.
Quatro passos para uma estratgia de integrao bottomup so apresentados por Pressman(2002,p.482): 1. Componentesde baixo nvel so integradosemagregadosdeformaquerealizem umadeterminadasubfunodosoftware. 2. Um driver desenvolvidoparacoordenaraentradaesadadocasodeteste. 3. Oconjuntodecomponentestestado.

43

4. Osdriverssoremovidoseosagregadossointegrados,movendoseparacimana hierarquiadaestruturadoprograma. Umproblemaprovenientedautilizaodetestedeintegraobottomupapresentado porPfleeger(2004,p.291)econsistequeoscomponentesdenvelsuperiorgeralmentesoos maisimportantes,poiscoordenamasprincipaisatividadesdosistemaenareferidaabordagem de integrao, sero os ltimos a serem testados, postergando a descoberta dos principais defeitosdoprograma.Esteproblemasanadoatravsdautilizaodatcnicadeintegrao

topdown.

1.3.2.2.

Integraotopdown

DeacordocomPfleeger(2004,p.292),aabordagemdetestesdeintegraotopdown o reverso da abordagembottomup. Pressman (2002, p. 480) define o teste de integrao

topdowncomoumaabordagemincrementalparaaconstruodaestruturadeumprograma
naqualosmdulosdealtonvelsoprimeiramentetestados,sendoaintegraorealizadade forma descendente pela hierarquia de controle. Conforme Myers (1979, p. 92), a estratgia

topdowncomeacomomduloinicial,queencontrasenotopodahierarquiadoprograma.
Apsisto,osprximosmdulosvosendointegradosquelesqueforamtestados.Comono existeumaregraparaaescolhadosprximosmdulosaseremintegrados,oautorafirmaque devemseracrescidososmdulossubordinados(chamados)pelosmdulosqueforamtestados previamente. Duranteoprocessode integrao,umcomponentepodechamaroutroqueainda no estejadisponvel,sendonecessrioodesenvolvimentodeum stubparasimularaatividadedo componentequeestfaltando(PFLEEGER,2004,p.292).ConformeSommerville

O programa representado como um componente abstrato nico com subcomponentes representados por stubs. (...) Depois que o componente de nvel superior foi programado e testado, seus subcomponentes so implementados e testadosdamesmamaneira.Esseprocessocontinuaatqueoscomponentesdenvel inferior sejam implementados. E, ento, todo o sistema foi inteiramente testado. (2003,p.386).

44

UmexemploapresentadonaFigura15.Inicialmente,ocomponenteA,localizado notopo,testadosozinhocomosstubsnecessriosparaB,CeD.Apstestado,ele integradocomoscomponentesdoprximonveleoconjuntoA,B,CeDtestado. Casonecessrio,osstubsE,FeGsoutilizadosnestaetapa.Porfim,osistemainteiro testado.

Fonte: Pfleeger(2004,p.292). Figura15. Testetopdown.

Pressman(2002,p.481)afirmaquenaestratgiadetestedeintegraotopdown,os principaispontosdecontroleoudecisosoverificadoslogonoinciodoprocessodeteste. Casoexistamproblemasimportantesdecontrole,essencialquesejamidentificadosomais cedopossvel. Uma desvantagem do teste de integrao topdown a possibilidade de que um nmero elevado de stubs seja necessrio, acarretando muita codificao e problemas em potencial (PFLEEGER, 2004, p. 293). Segundo Sommerville (2003, p. 388), geralmente o desenvolvimento de softwares utiliza uma mistura das abordagens topdown e a bottomup. Essa abordagem combinada, que conhecida como abordagem sanduche, apresentada comoumasoluoparaestesproblemasPressman(2002,p.485).

1.3.2.3.

Integraosanduche

Segundo Pfleeger (2004, p. 294), a abordagem de teste de integrao sanduche umacombinaodasabordagenstopdown ebottomup.Nestaabordagem,osistemavisto comoumsanduche,emtrscamadas:acamadaalvonomeio,acamadadosnveisacimado alvoeacamadadosnveisabaixodoalvo.ConformePressman(2002,p.485),aabordagem

45

topdown utilizada para testar os nveis altos da estrutura do programa e a abordagem bottomuputilizadanosnveissubordinados.
Pfleeger afirma que o teste converge para a camada alvo, escolhida com base nas caractersticasdosistemaeda estruturadahierarquiadecomponentes.(2004,p.294).Um exemplo apresentado pela autora, conforme a Figura 16. , que mostra a utilizao da integraotiposanducheemqueacamadaalvoadomeio,componentesB,CeD.

Fonte: Pfleeger(2004,p.294). Figura16. Testesanduche.

1.3.2.4.

Integraobigbang

De acordo com Myers (1979, p. 89), a abordagem noincremental ou bigbang consisteemtestartodososcomponentesindependentementeeentocombinlosparaformar umprogramaetestloposteriormente. Um exemplo desta abordagem apresentado por Pfleeger (2004, p.293) conforme a Figura17.Todososcomponentessotestadosindependentemente:A,B,C,D,E, FeG.Findoostestesdestes,oscomponentessointegradoseoprogramatestado.

46

Fonte: Pfleeger(2004,p.294). Figura17. Testebigbang.

Myers (1979, p. 90) afirma que a abordagem noincremental a que gera mais trabalho devido utilizao de drivers e stubs para testar os componentes independentes. Outras desvantagens so apresentadas por Pfleeger (2004, p. 293) so: a dificuldade de encontrar a causa das falhas devido integrao total de uma s vez e a dificuldade de distinoentreostiposdedefeitos.

1.3.3. Testedesistema

ConformeMcGregoreSykes(2001,p.344),testedesistemageralmenteserefereao teste para determinar se a aplicao fornece todas as funcionalidades descritas na especificao.Pressmandefinesistemaeostestesrelativosaestedaseguinteforma:

(...)osoftwareapenasumelementodeumsistemabaseadoem computador.Em ltima anlise, o software incorporado aos outros elementos do sistema (p. ex. hardware,pessoaleinformao)eumasriedetestesdeintegraoevalidaodo sistema conduzida. Esses testes saem do escopo do processo de software(...). (2002,p.488)

47

Segundo Myers (1979, p. 110), o teste de sistema tem como propsito particular compararosistemaouprogramacomosobjetivosoriginaisdomesmo.ParaPfleeger(2004, p.313),oobjetivodotestedesistemaassegurarqueelefazaquiloqueoclientequerqueele faa. DeacordocomPressman(2002,p.489),otestedesistemaumasriedediferentes testescomafinalidadedeexercitarporcompletoosistemabaseadoemcomputador.Apesar decadatesteterumobjetivodistinto,todosostestescolaboramparaverificarseoselementos do sistema foram adequadamente integrados e executam corretamente as funes a eles destinadas.Aseguirsotratadasalgunsdosprincipaistiposdetestedesistemaapresentados porMyers(1979),Pfleeger(2004),Sommerville(2003)ePressman(2002).

Teste de funcionalidade: Segundo Myers (1979, p. 108), o teste de funcionalidade um processo de tentativa de encontrar discrepncias entre o
13 programa e suas especificaes externas . Pfleeger (2004, p. 324) afirma que

estes testes tm mais caractersticas de caixapreta, no sendo necessrio o conhecimentodaestruturadoprograma,massimdaquiloqueosistemadevefazer. Paratal,otestefuncionaltemporbaseosrequisitosfuncionaisdosistema.

Testededesempenhooutestedeper for mance:Pressman(2002,p.490)afirma queaossistemasembutidosedetemporeal,nobastacumpriremafunoaque sodestinados,masdevemsatisfazerosrequisitosdedesempenho.Desempenho definido pelo IEEE (1990) como o grau com que um sistema ou componente realizam suas funes dentro de limites relativos a atributos como velocidade, preciso ou uso de memria. Pfleeger define que o desempenho do sistema avaliado em relao aos objetivos de desempenho definidos pelo cliente e expressos nos requisitos nofuncionais. (2004, p. 328). Para Myers (1979, p. 115),oobjetivodotestededesempenhodefinircasosdetestequemostremqueo programanosatisfazseusrequisitosdedesempenho.

13

Especificaes externas so uma descrio detalhada do comportamento do programa do ponto de vista do usurio(MYERS,1979,.108).

48

Testedeestresseoutestedecarga:SegundooIEEE(1990),otestedeestresse conduzido para avaliar um sistema ou componente alm dos limites de suas exigncias especificadas.Pfleeger(2004,p.328)afirmaqueostestesde estresse avaliam o sistema quando, por pequenos perodos, ele levado aos seus limites. Sommerville(2002,p.390)descreveduasfunesparaostestesdeestresse:testar o comportamento de falha do sistema, verificando seo sistema entra em colapso ouapresentafalhasdemenoresproporesmedianteasituaodesobrecargaea causa de sobrecarga no sistema pode acarretar a deteco de erros que no se manifestariam em situaes normais. Myers (1979, p. 113) afirma que, por envolverelementosrelativosatempo,otestedeestressenoaplicvelamaioria dos softwares. Contudo, devem ser aplicados a sistemas de temporeal e de controle de processos crticos, como um sistema de controle de trfego areo. O autor conclui que muitos dos testes de estresse representam condies que possivelmente nunca iro ocorrer em situaes usuais. Porm, se erros so detectadosparaestassituaesatpicas, muitosdesteserrospoderiamocorrerem situaesreais,comumnvelmenordeestresse.

Teste de volume: De acordo com Pfleeger (2004, p. 328), os testes de volume abordamamanipulaodegrandesquantidadesdedadosnosistema.ParaMyers (1979, p. 113),o propsito destestestes mostrar queo programa no consegue manipular o volume de dados especificado nos seus objetivos. Garantese que o sistemareagedemaneiraconvenientemedianteotamanhomximodoconjuntode dados(PFLEEGER,2004,p.329).

Testederecuperao:deacordocomPfleeger,ostestesderecuperaotratam da resposta presena de falhas ou perda de dados, energia, dispositivos ou servios.(2004,p.329).Acercadetestesderecuperao,Pressmanafirmaque

(...)umtestedesistemaqueforaosoftwareafalhardediversosmodoseverifica se a recuperao adequadamente realizada. Se a recuperao automtica (realizadapeloprpriosistema),areinicializao,osmecanismosde verificao,a recuperao dos dados e o reincio so avaliados quanto a correo. Se a recuperaorequerintervenohumana,otempomdioparareparo(...)avaliado paradeterminarseestdentrodelimitesaceitveis.(2002,p.489).

49

Teste de segurana: Pressman afirma que qualquer sistema baseado em computador que administra informao sensvel ou causa aes que podem inadequadamente prejudicar (ou beneficiar) indivduos alvo para invaso imprpria ou ilegal (2002, p. 489). Para Myers (1979, p. 115) teste de segurana o processo de planejar casos de teste que tentem subverter os controles de segurana de um programa. Conforme Pfleeger (2004, p. 329), devem ser testadas caractersticas do sistema relacionadas com a disponibilidade,integridadeeconfidencialidadededadoseservios.Segundo Pressman (2002, p. 489) o teste de segurana bem sucedido quando, dispondodetempoerecursossuficientes,acabarinvadindoosistema,sendoo papel do projetista do sistema tornar o custo da invaso mais elevado que o valordainformaoobtida.

Testedecompatibilidade:Muitosprogramasquesodesenvolvidosnoso completamentenovoselesfreqentementesubstituemalgumsistemaqueno fornece s funcionalidades necessrias (MYERS, 1979, p. 116). Para casos ondeosistema faz interfacecomoutrossistemassonecessriosostestesde compatibilidade (PFLEEGER, 2004, p. 329). A autora prossegue afirmando que atravs destes, descoberto se as funes de interface funcionam de acordocomosrequisitos.

Testedeusabilidade:SegundoMyers(1979,p.114)ostestesdeusabilidade tm como objetivo encontrar problemas relativos ao fatorhumano. Para Pfleeger(2004,p.329),ostestedeusabilidade,tambmchamadosdetestesde fatores humanos, so investigados os requisitos relacionados com a interface do sistema com o usurio como, por exemplo, a ordenao de campos que possuem preenchimento obrigatrio no incio de um formulrio de cadastro. Analisamse as telas de exibio de mensagens, o formato dos relatrios e demaisaspectosrelacionadoscomafacilidadedouso.

50

Teste de configurao: De acordo com Pfleeger (2004, p. 329),ostestes de configurao so responsveis por analisar as diversas configuraes de software e hardware especificadas nos requisitos. A diversidade de pblico a que alguns softwares se destinam gera um nmero de possibilidades de configurao muito grande e, conforme Myers (1979, p. 116), cada possvel configuraodoprogramadevesertestada.

Teste de confiabilidade: Conforme Pfleeger (2004, p. 330), a confiabilidade de um sistema expressa a probabilidade deste operar sem apresentar defeitos sobdeterminadascondiesemumcertoperododetempo.Aprobabilidade definidapeloclculodotempomdioentrefalhas.

Teste de documentao: Os testes de documentao tm como objetivo assegurar que os documentos requeridos foram escritos e verificar se as informaes nelescontidassoconsistentes,precisasede fcilentendimento. (PFLEEGER, 2004, p. 329). Alguns exemplos ilustrados na documentao podemserutilizadosnoscasosdetesteparaosistema(MYERS,1979,p.118).

1.3.4. Testedeaceitao

Findoostestesdesistema,acreditasequeosrequisitosespecificadosforamsatisfeitos pelosistema.Opassoseguinteconsisteemperguntaraosclienteseusuriosseosistemaest deacordocomoesperadoporeles(PFLEEGER,2004,p.337).DeacordocomMyers(1979, p. 103), um erro de software est presente enquanto o programa no funcionar de modo razoavelmente satisfatrio conforme o esperado pelo usurio final. Para corrigir estes erros, soexecutadosostestesdeaceitao. Uma premissa apresentada por Myers (1979, 103), define que o desenvolvimento de software,emsuamaiorparte,umprocessodecomunicaosobreoprogramaeatraduo destasinformaesduranteasetapas,equeamaiorpartedoserrosdosoftwaresoatribudos savarias,aoserroseaorudoduranteacomunicaoeatraduodainformao.Cabeento aousuriofinal,efetuaravalidaodosoftware.

51

Pressman (2004, p. 487) afirma que a validao do software ocorre mediante a execuodeumasriedetestesdecaixapretacomobjetivodedemonstraraconformidade comosrequisitos.Casoosoftwaresejasobencomendaparaumcliente,efetuadootestede aceitao,noqualoclienterealizaavalidaodosoftware.Estestestesrealizadospelocliente podem ser informalmente conduzidos ou planejados e sistematicamente executados. Para Pfleeger(2004,p.316),oobjetivodotestedeaceitaoasseguraraoclientequeoprograma solicitadooquefoiconstrudo. Para softwares fechados, que sero usados por vrios clientes, o autor indica a utilizaodostestesalpha ebeta (PRESSMANN,2002,488).Ostestesalpha soconduzidos emumambientecontrolado,ondeclienteinteragecomosoftwareeodesenvolvedorregistra oserroseproblemasdeuso.Porsuavez,ostestesbeta consistemdainteraodoclientecom osoftwareemumambientenocontrolado,geralmentesemapresenadosdesenvolvedores. Os usurios registram os erros encontrados e relatam estes aos desenvolvedores, que iro efetuarasalteraesnecessriaseliberaroprodutodesoftwareparaabasedecliente. OutrotipodetestedeaceitaoapresentadoporPfleeger(2004,p.338)otesteem paralelo.Otesteemparaleloconsistenaoperaodonovosistemaparalelamenteaoanterior. A transio feita gradualmente, o que permite aos usurios acostumarse com o novo sistemaeadquiriremconfiananomesmo. Aofinaldotestedeaceitao,oclienteinformaquaisrequisitosnoforamsatisfeitos equaisdevemserexcludos,revisadosouincludos(PFLEEGER,2004,p.339).

1.3.5. Testedeinstalao

SegundoPfleeger(2004,p.340),otestede instalaoconsisteem instalarosistema noslocaisondeosusuriosesto.Myers(1979,p.121)apresentaotestedeinstalaocomo um tipo de teste no usual, porque seu propsito no encontrar erros no software, mas encontrarerrosnainstalao. Doisaspectossofocadosnostestesdeinstalao:aintegridadedosistemainstalado eaverificaoquantoasealgumacaractersticafuncionalounofuncionalfoiafetadapelas condiesdolocaldeoperao.(PFLEEGER,2004,p.340).Entreoutrascoisas,oscasosde testedevemverificarparaassegurarqueumconjuntodeopesnecessriasfoiselecionado, quetodasaspartesdosistemaestopresentes,quetodososarquivosforamcriadosetemo

52

contedonecessrioequeasconfiguraesdehardwaresoapropriadas(MYERS,1979,p. 120).Pfleeger(2004,p.340)finalizaafirmandoquequandooclienteestiversatisfeitocomos resultados,otesteestarconcludoeosistemaserformalmenteentregue.

1.4.

TestedeRegresso

Cada alterao realizada em um software pode ocasionar na adio de defeitos anteriormentenoexistentes.McGregoreSykes(2001,p.92)eHarroldeRothermel(1994b, p.14)afirmamqueotestederegressorealizadoemumsoftwarequandoaimplementao modificadasemquehajaalteraonasespecificaesdomesmo. Alguns dos principais usos do teste de regresso so apresentados por diversos autores. Pressman (2002) e McGregor e Sykes (2001, p. 81) apresentam a importncia da utilizaodostestesderegressonocontextodafasedeintegrao,ondecadainserodeum novo componente altera o software. Para Pressman, o teste de regresso consiste na re execuo de um subconjunto de testes que tenham sido utilizados antes da alterao ser efetuada para assegurar que a mudana no tenha produzido defeitos. De acordo com McGregor e Sykes (2001, p. 80), o uso do teste de regresso deve ser aplicado durante as atividades de manuteno do software, assegurando que as funcionalidades permanecem operandocorretamente.OutrousoparaotestederegressoapresentadoporMartins(2006), que sugere que a cada nova utilizao de um componente reusvel sejam executados tais testes. SegundoHarrold(2000)ostestesderegressoconsomematumterodocustototal deumsoftware.HarroldeRothermel(1994b,p.14)afirmamquemtodosseletivosdereteste podem reduzir este custo pela seleo de casos de teste para o programa modificado provenientes de um conjunto de testes j existente. Apesar disto, o teste de regresso no descartaanecessidadedetestesparafuncionalidadesnovasoualteradas(MARTINS,2006).

53

1.5.

ConsideraesFinais

Neste captulo foi apresentada uma viso geral acerca de testes de software, com definies em torno dos objetivos desta fase e as divises existentes entre as tcnicas e estgios de teste. Constatouse a no existncia de um consenso sobre as subdivises das tcnicas estruturais e funcionais de teste, bem como dos estgios de teste entre os autores pesquisados, sendo buscada ao longo do trabalho, a apresentao dos conceitos mais difundidosemencionadosnaliteratura.Concluiseacercadaimportnciadafasedetestesno processo de desenvolvimento de software em vista da reduo de custos envolvidos no mesmo,bemcomonoaprimoramentodaqualidadedoprodutofinalobtido.

54

2. TESTEDESOFTWAREORIENTADOAOBJ ETOS

Neste captulo so apresentadas as tcnicas e estgios de testes de software desenvolvidos sob o paradigma da Orientao a Objetos (OO). Inicialmente so mostrados conceitos bsicos de OO, sendo sucedidos pela descrio de problemas decorrentes da utilizaodesteparadigmaepeculiaridadesdomesmoquedevemserconsideradasnareade testes. Em seguida so descritos os estgios de teste OO, sendo teste de classe, teste de integrao e teste de sistema. Aps, apresenta as tcnicas de teste de software OO e finalizadocomadescriodealgumasconsideraesfinaisacercadocontedoabordadoao longodocaptulo.

2.1.

ConceitosBsicosdeOO

De acordo com Domingues, a orientao a objetos muda o foco do processo de programao de procedimentos para objetos, classes e clusters, alm de incorporar outras caractersticas, tais como, encapsulamento, herana, polimorfismo e acoplamento dinmico (2002,p.15).McGregoreSykes(2001,p.29)afirmamqueaprogramaoOOestcentrada em torno de seis conceitos bsicos: objeto, mensagem, interface, classe, herana e polimorfismo. ParaJacobson(1997,p.44),um objetocaracterizadoporoperaeseumestadoque grava o efeito destas operaes. Martin afirma que um objeto qualquer coisa, real ou abstrata, sobre a qual armazenamos dados e operaes que manipulam os dados (1994, p. 20). A SUN (2007) conceitualiza objetos analisandoos analogamente a objetos do mundo

55

real, que possuem duas caractersticas: estado e comportamento. Por exemplo, ces tm estado (nome, cor, raa, fome) e comportamento (latem, farejam, sacodem a cauda). Na programaoOO,osobjetospossuemconceitosparecidoscomo mundoreal,poispossuem estado e comportamento relacionado. Um objeto armazena os estados nos atributos (variveis)eexpeseuscomportamentosatravsdosmtodosouoperaes(funesparaa manipulaodosatributos). Para que um mtodo seja executado, o objeto deve receber uma requisio. Estas requisies aos objetos so chamadas mensagens (MCGREGOR E SYKES, 2001, p. 32). Vicenziafirmaqueomtodosolicitadopodealteraroestadointernodoobjetoe/ouenviar mensagensaoutrosobjetos(2004,p.10).McGregoreSykes(2001,p.33)apresentamainda trsobservaesacercademensagens: Umamensagempossuiumremetente Umamensagempossuiumreceptor Uma mensagem pode incluir parmetros. Estes parmetros sero usados pelo receptorduranteoprocessamentodamensagem. Os objetos interagem com o mundo exterior atravs de seus mtodos, que so acionados atravs de mensagens. Os mtodos formam a inter face do objeto com o mundo exterior (SUN, 2007). Conforme McGregor e Sykes (2001, p. 33), uma interface uma agregaodadeclaraodeprocedimentos.Procedimentossoagrupadosjuntosporqueeles definemaesrelacionadasaumobjeto. McgregoreSykes(2001,p.34)definemqueumaclasseumconjuntodeobjetosque compartilham de uma base conceitual comum. Para Rumbaugh, uma classe de objetos descreve um grupo de objetos com propriedades semelhantes (atributos), o mesmo comportamento (operaes), os mesmos relacionamentos com outros objetos e a mesma semntica(1994,p.32).McGregoreSykes(2001,p.34)afirmamtambmqueobjetosso oselementosbsicosparaaexecuodeprogramasOO,enquantoclassessooselementos bsicosparaadefiniodeprogramasOO.SegundoDomingues(2002,p.15),umconjunto de classes que cooperam entre si na implementao de determinada(s) funcionalidade(s) chamadodecluster. AprogramaoOOpermitequeasclassesherdemestadosecomportamentosusados emoutrasclasses(SUN,2007).Aestarelaodseonomede herana.ParaMcGregore Sykes (2001, p. 45), herana um relacionamento entre classes que permite a definio de umanovaclassebaseadanadefiniodeumaclasseexistente.Umaclassemaisespecializada herdatodasaspropriedadesda(s)classe(s)maisgenrica(s)(VICENZI,2006,p.11).Aclasse

56

mais genrica (ascendente) chamada de super classe ou classe pai e a classe mais especializada (descendente) chamada de subclasse ou classe filha (JACOBSON, 1997, p. 58). Quando uma classe herda propriedades de mais de uma superclasse, ocorre a relao denominadaheranamltipla(MARTIN,1994,p.28). De acordo com McGergor e Sykes (2001, p. 46), polimor fismo a habilidade de tratarumobjetocomopertencendoamaisdeumtipo.ConformeDomingues(2002,p.16),o termo polimorfismo designa que a mesma operao pode atuar de maneiras distintas em classesdiferentes.Porexemplo,ooperador+podeserusadopararealizaraadiodedois valoresinteiroseparaconcatenarduasstrings. O acoplamento dinmico apresentado por Vicenzi (2004, p. 11) como uma caractersticafortementerelacionadacomopolimorfismoeaherana.Umcomparativofeito pelo autor afirma que em programas procedimentais, o programa deve ser alterado e recompiladosemprequeumanovafuncionalidadeforacrescentada.Atravsdopolimorfismo, possvel serem acrescidos novos mtodos a classes j existentes sem a necessidade de recompilar o programa. Isto possvel pelo uso da tcnica de acoplamento dinmico, que possibilitaquemtodossejamcarregadoseligadosaosoftwareemtempodeexecuo. Oencapsulamento definidoporVicenzi(2004,p.11)comoacapacidadeque um objetotemdeimpedirqueoutrosobjetostenhamacessoaosseusdados.Domingues(2002,p. 16) afirma que o encapsulamento, tambm chamado de ocultamento de informaes, consistenaseparaodosaspectosexternosdeumobjeto,acessveisporoutrosobjetos,dos detalhesinternosdaimplementaodaqueleobjeto,queficamocultosdosdemaisobjetos.

2.2.

ProblemasProvenientesdoParadigmaOO

ConformeDomingues(2002,p.17),aopassoqueconceitospertinentesaocontextoda orientao a objetos, tais como herana, encapsulamento e polimorfismo, facilitam o desenvolvimento de softwares para diversas classes de aplicaes quando comparado programao convencional, eles podem trazer uma srie de problemas para a atividade de teste. De acordo com Binder (2007), aorientao aobjetos apresenta novos desafios para a readetestes.Emboraexistamsimilaridadescomotestedesoftwaresconvencionais,oteste orientadoaobjetotemdiferenassignificativas.Oautorcitacomoprincipaisproblemas:

57

Umaespecializaodeclasse,queherdaaspropriedadesdeumasuperclasse,deve sertestada? Quandopodeseconfiarnosrelatriosdeumobjetonotestadosobreseuestado? Comoverificarocomportamentodeumobjetoquandoseucontroledeestadosest distribudoportodaaaplicao? Oqueumaestratgiaeficazdetesteeestratgiadeintegraodadaaabordagem iterativa,preferidaparaodesenvolvimentoorientadoaobjetos? A seguir, so descritos os principais problemas que podem decorrer do uso das caractersticasdeOO.

2.2.1. Encapsulamento

DeacordocomVicenzi,(2004,p.13),oencapsulamentoomecanismoparacontrole de acesso que define a visibilidade dos atributos e mtodos existentes em uma classe. Ele possibilita a ocultao dos detalhes de implementao, tornando disponvel somente a interface da classe. Segundo Domingues (2002, p. 17), o encapsulamento auxilia a ocultar informaes e a obter modularidade no desenvolvimento do software. McGregor e Sykes (2001, p. 32) afirmam que, em virtude de os objetos ocultarem a informao, s vezes, as mudanasnoobjetosodifceisdeobservar,tornandoaverificaodosresultadosdostestes maisdifcil. O encapsulamento no uma causa de erros, mas pode ser um obstculo para a atividadedetestes.Aatividadedetesterequerumrelatriodosestadoconcretoeabstratode um objeto. As caractersticas do encapsulamento tornam difcil a obteno deste relatrio (BINDER, 1995). Comentando a respeito de testes de componentes de software, Harrold (2000)afirmaqueasoluoseriaaimplementaodemtodosqueobtenhamovalor(get)e queatribuamvalor(set)paracadaumdosatributosdaclasse.

58

2.2.2. Herana

Vicenzi (2004, p.14) afirma que a herana fundamental para a programao OO poiselapermiteareusabilidadeviaocompartilhamentodecaractersticaspresentesemuma classejdefinidaanteriormente.ParaSommerville,autilizaodeheranatornamaisdifcil atarefadeprojetartestesdeclassedeobjeto.Oautorafirmaque

Quando uma superclasse fornece operaes que so herdadas por uma srie de subclasses, todas essas subclasses devem ser testadas com todas as operaes herdadas.Arazodistoqueaoperaoherdadapodefazersuposiessobreoutras operaese outrosatributos,eestespodemtersidomodificadosquandoherdados. Igualmente, quando uma operao de superclasse carregada, a operao de sobrescreverdevesertestada.(2004,p.392).

Harroldetal.(1992)desenvolveramumaestratgiadetestebaseadanahierarquiade heranadasclasses.Arespeitodestaestratgia,Dominguesafirmaqueaidiaidentificar quais mtodos herdados necessitam de novos casos de teste para serem testados, e quais mtodos podem ser retestados, aproveitando os casos de teste elaborados para o teste da superclasse(2002,p.18).Harroldetal.(1992)prossegue,afirmandoque,comautilizao destaestratgia,oesforodetestesignificativamentereduzido.Areutilizaodeconjuntos de testes resulta em economia tempo e permite ao testador concentrar maiores esforos em pontos considerados mais problemticos ou com maior probabilidade de conter erros (VICENZI,2004,p.15).

2.2.3. Polimor fismo

DeacordocomVicenzi(2004,p.17),polimorfismocaracterizadopelapossibilidade de um nico nome (denominado nome polimrfico) denotar instncias (objetos) de vrias classes.SegundoBinder(1995),cadapossvelligaodeumcomponentepolimrficorequer um teste separado. Porm, Vicenzi (2004, p. 17) afirma que o polimorfismo traz indecidibilidadeparaostestes.Oautorcolocaaindaque

59

Uma vez que nomes polimrficos podem denotar objetos de diferentes classes, impossvel,aoinvocarummtodopormeiodeumnomepolimrfico,predizerem tempodecompilaoqualotrechodecdigoqueserexecutado(...).Taldecisos ocorreemtempodeexecuo.

Umcuidadoespecialdevesertomadonodesenvolvimentodoscasosdetesteparaos casos de polimorfismo, pois cada possibilidade de acoplamento de uma mensagem polimrficaumacomputaonica(DOMINGUES,2002,p.18).

2.3.

EstgiosdeTesteOO

DeacordocomPressman(2002,p.622),assimcomonaabordagemfuncional,oteste desoftwaresdesenvolvidossoboparadigmaOOdivididoemtrsetapas,iniciandosecom ostestesdeunidade,progredindoparaotestedeintegraoefindandocom otestedesistema. Entretanto, existem diferenas entre os softwares desenvolvidos sob o paradigma de orientao a objetos e os softwares desenvolvidos utilizandose o modelo funcional que devemserconsideradas.EssasdiferenassoapresentadasporSommerville(2003,p.391): 1. Objetoscomocomponentesindividuaisso,muitasvezes,maioresdoquefunes isoladas. 2. Os objetos que so integrados em subsistemas so, em geral, indevidamente acoplados,enohumnvelsuperiorbvioparaosoftware. 3. Seobjetosforemreutilizados,ostestadorespodemnoteracessoaocdigofonte docomponenteparaanlise.

Emdecorrnciadestasdiferenas,asabordagensdostestesdecaixabrancadevemser adequadas para os testes de classes e abordagens alternativas de integrao devem ser adotadas(SOMMERVILLE,2003p.391).Porm,ostestesdesistemanodiferememnada daqueles desenvolvidos sob outras abordagens, podendo ser utilizadas as abordagens convencionais(PRESSMAN,2002,623). McGregor e Sykes (2001, p. 180), Harrold e Rothermel (1994a, p.154), Pressman (2002, p.622), Sommerville (2003, p. 391) e Jacobson et al. (1997, p. 323) afirmam que no

60

paradigmaOOaunidadebsicadetestesaclasse.Emdecorrnciadestaafirmao,afase detestedeunidadeOOserreferidanopresentetrabalhocomotestedeclasse. A seguir dada uma viso geral acerca dos testes de classe e de integrao sob o paradigmaOO.

2.3.1. TestedeClasse

DeacordocomPressman(2002,p.622),emsoftwaresOOoconceitodeunidadesse modifica.Cadaclasseecadaobjeto(instnciadeumaclasse)encapsulamatributos(dados)e as operaes que manipulam estes dados (mtodos), diferentemente da viso convencional (funcional)dotestedeunidade,emqueumanicaoperaopodiasertestadaisoladamente.O autorargumentaque,devido herana,cadasubclasseque herdaos mtodoseatributosde umasuperclassedevesertestadatotalmente,poisocontextodecadaumadasclassespodeser diferente,estandoosmtodoscondicionadosaocontextonoqualestoinseridos. Segundo Sommerville 2003, p. 391), quando objetos so testados, a cobertura completadetestesdevencluir: 1. testeisoladodetodasasoperaesassociadascomoobjeto 2. estabelecimentoeainterrogaodetodososatributosassociadoscom oobjeto,e 3. exerccio do objeto em todos os estados possveis. Isso significa que todos os eventosqueprovoquemumamudanadeestadonoobjetodevemsersimulados.

Paratal,HarroldeRothermel(1994a,p.156)apresentamtrsnveisparaostestesde classe: Teste intramtodo: cada mtodo testado individualmente. Este nvel de teste equivale ao teste de unidade de procedimentos individuais em linguagens de programaoprocedimentais. Testeintermtodo:testedosmtodosdeumaclassequeinteragementresipara desempenhar funes especficas. equivalente ao teste de integrao em linguagensprocedimentais. Testeintraclasse:testaasinteraesentremtodospblicosfazendochamadasa esses mtodos em diferentes seqncias. Como os usurios podem invocar seqncias de mtodos em ordem indeterminada, utilizado o teste intraclasse

61

para aumentar a confiana de que diferentes seqncias de chamadas interagem corretamente. UmexemplodeumaestaometeorolgicaapresentadoporSommerville(2003).A estao possui apenas um atributo, que seu identificador, e alguns mtodos, conforme mostraaFigura18.

Fonte: Sommerville(2003,p.392). Figura18. Interfacedoobjetoestaometeorolgica.

O identificador uma constante, estabelecida quando a estao meteorolgica instalada, sendo necessrio testlo para verificar se ela foi estabelecida. preciso definir casosdetesteparacadaumdosmtodos:relatar Clima,calibrar,testar,iniciar edesativar. Cada mtodo deve ser testado individualmente, mas em alguns casos, necessria uma seqnciadetestes.Porexemplo,paraqueomtododesativar sejatestado,obrigatrioter executadoomtodoiniciar. A partir do diagrama de estado, apresentado na Figura 19. , so identificadas as seqnciasdetransiesdeestadoquedevemsertestadas.

62

Fonte: Sommerville(2004,p.236). Figura19. DiagramadeestadodaestaoMeteorolgica.

Alguns exemplos de seqncias de estados que devem ser testadas na estao meteorolgicasodemonstradosnaFigura20.

Fonte: BaseadoemSommerville(2003,p.237). Figura20. ExemplosdeseqnciasdodiagramadeestadodaestaoMeteorolgica.

Findoostestesdeclasses,oprximopassoasertomadoaexecuodostestesde integrao.

63

2.3.2. TestedeIntegrao

ConformeMcGregoreSykes(2001,p.238),umsoftwareorientadoaobjetosconsiste numacoleodeobjetosquecolaborampararesolveralgumproblema.Jacobsonetal.(1997, p.330)afirmamquea finalidadedotestedeintegraoverificarseasdiferentesunidades testadas individualmentetrabalhamcorretamentejuntas.Em virtudedosoftwareorientadoa objetos no possuir uma estrutura de controle hierrquica, as estratgias de integrao top

downebottomupnosoaplicveis(PRESSMAN2002,p.623).
UmadasdiferenasprincipaisentreotestedesoftwareOOeprocedimentalreferese complexidadeparaintegraodoscomponenteseapresentadaporWinter(2007)naFigura 21. NocasodosoftwareOO,osnodosrepresentamobjetosepodeminteragirentresiatravs
2 de at n n canais (flechas), enquanto que no desenvolvimento funcional, que segue o

modelodervores,osnodosrepresentammdulosquepodemsecomunicarporsomenten 1canais(flechas).

Fonte: AdaptadodeWinter(1998). Figura21. Complexidade:OOvs.Funcional.

Outra diferena peculiar relevante para a execuo de teste de integrao sob o paradigmaOOadependnciacclica,quedefinidapeladependnciamtuaentreclasses (WINTER,2007). Em decorrncia da diferena de complexidade e da dependncia cclica, Jacobson et al. (1994, p. 330) afirmam que no h somente um teste de integrao, mas so executados diversos testes de integrao. Isto descarta a aplicao do teste de integrao bigbang a softwaresdesenvolvidosluzdoparadigmaOO. Sommerville(2003,p.392)descrevequeemsoftwaresorientadosaobjetososnveis de integrao so menos distintos. O autor cita Murphy et al. que sugerem que grupos de

64

classesqueagememcombinaoparafornecerumconjuntodeserviosdevemsertestados juntos.Elesdenominamaissodetestedeclusters(MURPHYetal.apudSOMMERVILLE, 2003,p.392). LimaeTravassos(2006)afirmamquenotestedeintegraoemsoftwareorientadoa objetos,asclassesdevemserintegradasumadecadavezouempequenosclusters.Combase nisto,os autores apresentam uma abordagem de teste de integrao que permite estabelecer uma ordem de prioridade entre as classes a serem integradas, baseada na anlise de dependncias entre as classes. Se uma classe (cliente) utiliza servios de outra classe (servidora), a classe servidora, que fornece o servio, tem precedncia para ser testada em relaoclassecliente. DeacordocomBinder(2007)existemduasestratgiasbsicasdetestedeintegrao
14 orientadoaobjetos:baseadaem threadsebaseadaemcasosdeuso .Ostestesdethreadsso

baseados no teste da resposta do software a uma determinada entrada ou a um conjunto de eventosdeentrada(SOMMERVILLE,2003,p.393).Umathreadconsistedetodasasclasses necessrias para responder a uma entrada. Cada classe individualmente testada e ento, executase a thread (BINDER, 2007). Os testes de usecase, tambm chamado de teste de cenrio,baseiamsenasdescriesdecenrioenosclustersdeobjetoscriadosparatrabalhar com estas descries, usecases, que se relacionam com o modo de uso descrito nestes cenrios. Segundo Jacobson et al. (1997, p. 330), ostestes de integrao OO so mais bem feitosquandotmporbaseautilizaodeusecases,sendoestesaprincipalferramentaparaa direodosmesmos. Ostestesbaseadosemcenriospossibilitamaorganizaodostestesdeformaqueos
15 16 cenrios mais provveis sejam primeiramente testados e os cenrios incomuns sejam

consideradosposteriormentenoprocessodetestes(SOMMERVILLE,2003,p.393).Oautor saliente ainda que importante assegurar que cada mtodo seja executado em cada classe pelomenosumavez(2003,p.394).

14

Casos de uso (use cases) so cenrios que descrevem as diversas situaes em que os usurios utilizam o sistema.Oconjuntodesses cenriosdescreveafuncionalidadedosistema.(ALMEIDA,2007)Atualmenteso uma caracterstica fundamental danotao em UML (unified modelinglanguage) (SOMMERVILLE, 2003, p. 113).SegundoHolub(2007),umcasodeusoumatarefasimples,realizadaporumusuriofinaldosistema, quetenhaalgumresultadotil. 15 Cenriosmaisprovveissodefinidoscomoasfuncionalidadesdosoftwarequepossivelmenteseroasmais utilizadaspelousuriofinal. 16 Cenrios incomuns so definidos como as funcionalidades do software que sero utilizadas com pouca freqncia.

65

2.4.

TcnicasdeTestesOO

McGregor e Sykes (2001, p. 98) definem que os testes de softwares orientados a objetos podem ser classificados de duas maneiras: baseados na especificao (funcional ou caixapreta)ebaseadosnaimplementao(estruturaloucaixabranca). Conforme apresentado por Beizer (1990), o teste funcional examina o software do pontodevistadousurio.Ousuriodeveser concernidosomentecoma funcionalidadedo software, no importandoos detalhes da implementao. Sendo assim, todos as tcnicas de testefuncionaisutilizadasemprogramasconvencionaispodemseraplicadasparaprogramas OO. A respeito dos testes estruturais, Tschannerl e Martins (2007) afirmam que uma importante diferena do teste procedimental para o teste OO encontrase no fato de as aplicaesOOnoseremexecutadas seqencialmente.Comonenhumaordemde invocao demtodosdefinida,asanlisesdefluxodecontroleedofluxodedadossodificultadas, fazendocomqueastcnicasdetesteestruturalnosejamdiretamenteaplicveis. HarroldeRothermel(1994a)comentamqueastcnicasdefluxodedadosparatestes emprogramasprocedimentaispodemserutilizadasparaotestedemtodosindividuaisepara testesdemtodosdeumamesmaclassequeinteragementresi.Contudo,paratestarmtodos que so acessveis fora da classe e que podem ser utilizados por outras classes, os autores apresentam uma nova representao chamada de grafo de fluxo de controle de classe, que possibilitatestarasinteraesentreestesmtodos.
17 Conformedescrito porMcGregoreSykes(2001,p.32),duranteociclode vida de

umobjeto,esteassumediversosestadosquepersistemparaavidadoobjeto.Umestadopode tornarseinconsistenteepodeseraorigemdeumcomportamentoincorreto.Deacordocom Palavro(2007),umestadodefinidocomosendoumsubconjuntodetodasascombinaes possveisdosvaloresdeatributosdaclasse.CombasenaafirmaodeMcGregoreSykes, Binder (1995) apresenta o teste baseado em estados. Segundo Vicenzi (2004, p. 29), os princpios da tcnica de teste baseado em estados visam modelar o comportamento do
18 softwareouunidadeasertestadacomoumamquinadeestadosfinitos (MEF).Apartirda

17

Ociclode vidadeumobjetotemincioquandoeste criado,prossegueatravsdeumasriedeestados,e terminaquandooobjetodestrudo.(MCGREGORESYKES,2001,p.30). 18 Umamquinadeestadosfinitosumamodelagemdeumcomportamento,compostoporestados,transies eaes.Umestadoarmazenainformaessobreopassado,isto,elerefleteasmudanasdesdeaentradanum estado,noinciodosistema,atomomentopresente.Umatransioindicaumamudanadeestadoedescrita

66

MEFdesenvolvida,podemsergeradasseqnciasdetesteparaavaliar seocomportamento esperadodaMEFobtido. Binder (1995) afirma que o modelo de estado define as seqncias de transio possveis. As transies de estado so resultantes da execuo de mtodos. O autor exemplificaas seqnciasdeestadoscitandoqueuma instnciadevesercriadaantesdeser alteradaouapagada.McGregoreSykes(2001,p.39)comentamacercadaexistnciadepr condiesepscondiesparaaalteraodosestados.Asprcondiesparaumaoperao prescrevem as condies que devem ocorrer antes que a operao possa ser executada. As pscondies, por sua vez, descrevem circunstncias que devem ocorrer depois que a operaoexecutada. Segundo Binder (1995), no teste baseado em estados, os casos de teste devem ser planejados para executar cada transio. Porm, a tcnica no adequada se muitas seqnciasdemtodosdeativaoforemaceitaspelasclasses.

2.5.

ConsideraesFinais

NestecaptuloforamdescritosconceitosfundamentaisdaOOquedevemserconsiderados nafasedetestesdesoftwaresdesenvolvidossoboparadigmadeorientaoaobjetos,devido s diferenas que este gerou para a fase de testes com relao ao paradigma funcional. Abordouse tambm os pontos negativos decorrentes da OO para a fase de testes, sendo apresentados estgios e tcnicas de teste peculiares voltados para tal fim. Entretanto, constatouse a divergncia de idias existentes entre muitos autores acerca dos estgios e tcnicas de teste, sendo apresentados neste trabalho aqueles com maior aceitao dentre as referncias utilizadas. Concluiuse que o teste de software OO requer diferentes tcnicas e estgios em comparao ao teste de software desenvolvido em paradigma funcional em virtudedaspeculiaridadesapresentadasporesteparadigma.

porumacondioqueprecisaserrealizadaparaqueatransioocorra.Umaaoadescriodeumaatividade quedeveserrealizadanumdeterminadomomento(WIKIPEDIA,2007).

67

3. AUTOMATIZAODAFASEDETESTES

Este captulo apresenta inicialmente algumas consideraes acerca da automatizao da atividade de teste de software. Em seguida so listadas as ferramentas a serem testadas com uma breve descrio das mesmas. Aps, so demonstrados os dados preliminares provenientes da anlise comparativa das mesmas sendo baseadas principalmente nas informaes disponibilizadas no site das ferramentas, seguidos por uma descrio da metodologia a ser utilizada na anlise comparativa das ferramentas. Por fim, so descritas algumasconsideraesacercadocontedodestecaptulo.

3.1.

Fer ramentaseEspecificaes

Sommerville (2003, p. 394) descreve que em virtude da atividade de testes ser uma fasedispendiosaetrabalhosa,asferramentasdetestesforamasprimeirasferramentasaserem desenvolvidas.Vicenzi(2004,p.59)afirmaquenaprtica,aaplicaodeumametodologia detestesestfortementecondicionadasuaautomatizao.Domingues(2002,p.21)afirma queaexistnciade ferramentastem fundamental importnciapara arealizaodaatividade deteste. A seguir, apresentada a listagem de ferramentas para a utilizao em teste de softwareOOaseremanalisadascomopartedestetrabalho,comumabrevedescriodecada uma. Estas ferramentas foram selecionadas dentre vrias por serem de cdigo aberto (open

source)sem custoparaaquisioda licenadeusodas mesmasedarem suporteparatestes

68

voltados a aplicaes desenvolvidas sob a linguagem de programao Java com nfase no testedeaplicaesvoltadasparaWeb. Asinformaesacercadestasferramentasforambaseadasnadocumentaoexistente decadauma,obtidasatravsdepesquisanaWorldWideWeb(WWW).
19 J Unit: um framework destinado criao de testes unitrios em linguagem

Java.OJUnitpossibilitaacriaodeclassesdeteste,sendoqueestascontmum oumaismtodosparaarealizaodetestes,quepodemserorganizadosdeforma hierrquica,permitindoqueosoftwaresejatestadoempartesseparadas,algumas integradas ou at mesmo todas de uma vez. O framework tem como objetivo facilitar a criao de casos de teste, alm de permitir a escrita de testes que retenham seu valor ao longo do tempo, ou seja, que possam ser reutilizveis (OLIVEIRA, 2007a). O JUnit pode ser usado mesmo que tenhase disponveis somente o bytecode20 e a especificao do programa. Web site da ferramenta: http://www.junit.org/index.htm.

TestNG: um framework para testes de aplicativos escritos na linguagem de programaoJavaprojetadoparadarsuporteatestesunitrios,testesdeintegrao etestesfuncionais.Permiteotestedemtodos,testesdeclassesisoladamentede outras, testes de integrao, sendo testados aplicativos inteiros formados por diversas classes e pacotes, e testes de todas as funcionalidades do software. Permiteoagrupamentodosmtodosdetesteetambmaespecificaodegrupos quecontmoutrosgrupos.Outrafuncionalidade disponibilizadapeloTestNGa migraodetestesescritosnoJUnitatravsdeclassesespecficasparatalfimsem demandaresforosmuitodispendiosos. Adocumentaoacercadaferramenta,bem comoalistagem, interfacede chamada e funcionalidade dos pacotes, classes e mtodos constantes na mesma, esto disponveis no web site da ferramenta, no qual tambm possvel a

19

Em Orientao a Objetos, framework um conjunto de classes com objetivo de reutilizao de um design, provendoumguiaparaumasoluodearquiteturaemumdomnioespecficodesoftware.Sediferenciadeuma biblioteca, pois esta se concentra apenas em oferecer implementao de funcionalidades, sem definir a reutilizaodeumasoluodearquitetura.(WIKIPEDIA,2007). 20 Bytecode uma forma intermediria de cdigo proveniente da compilao do cdigo de um programa de computador escrito em linguagem de programao Java. interpretado pelas Mquinas Virtuais Java (JVM), sendo esta caracterstica que faz que os programas Java sejam independentes de plataforma, executando em qualquersistemaquepossuaumaJVM(WIKIPEDIA,2007).

69

realizao do download de todas suas verses. Web site da ferramenta: http://testng.org.

Cactus: umframework destinado ao teste unitrio de cdigos Java do lado do servidor e intenta a diminuio do custo de escrita de testes para tal. O Cactus utiliza o JUnit e estende seu uso, de forma que ele testa a integrao dos
21 componentes web com os seus containers , usando o prprio container como

servidor e o JUnit como cliente. O Cactus um projeto pertencente ao Grupo Apache Jakarta (http://jakarta.apache.org). Web site da ferramenta:

http://jakarta.apache.org/cactus/.

Cobertura:umaferramentaJavaquecalculaaporcentagemdocdigoacessada pelos testes. Permite a identificao das partes do cdigo que no esto sendo exercitadas pela execuo dos testes propostos. Calcula tambm a complexidade ciclomticadecadaclasse.PossibilitaaemissoderelatriosemHTMLeXML. Websitedaferramenta:http://cobertura.sourceforge.net/.

Emma:umaferramentaparaanlisedecoberturaemcdigosdalinguagemJava quesuportaacoberturadeclasses,mtodos,linhaseblocosbsicos.Elaapontaa porcentagemdasreasdocdigoque foramexercitadascomostestes.Permite a

22 anlisedearquivos individuais.classoupacotes.jar .Possuiopesdesadade

relatrios nos formatos texto, HTML e XML. Possibilita tambm a juno de dados obtidos em diversas execues. Web site da ferramenta:

http://emma.sourceforge.net/.
23 Findbugs: um software que utiliza anlise esttica para procurar bugs em

cdigos Java e sugere correes para as anomalias encontradas. Possibilita a

21

Container umobjetoquecontmoutrosobjetosquepodemserincludosouremovidosdinamicamente,em tempodeexecuo,diferentementedoqueocorrecomumacomposioondeesterelacionamentofixadoem tempodecompilao(WIKIPEDIA,2007). 22 JARouJavaARchiveumarquivocompactadousadoparadistribuirumconjuntodeclassesJava.Armazena classescompiladasemetadadosassociadosquepemconstituirumprograma.(WIKIPEDIA,2007). 23 OtermobugsutilizadoparadescriodaferramentaFindBugsporqueamesmabaseadanoconceitode bugspatternsquesopadresdecdigoquefreqentementeresultamnaocorrnciadeerros.Osbugspatterns sodivididosnosseguintesgrupos:enganosnautilizaodemtodos,enganogeradoduranteamanutenode um cdigo, erros no uso de operadores booleanos e utilizao de caractersticas complexas da linguagem (FINDBUGS,2007).

70

geraoderelatrioscomagrupamentodosdefeitosporcategoriaouporpacotes. Websitedaferramenta:http://findbugs.sourceforge.net.

PMD:um frameworkqueexaminaocdigodeaplicaesescritasemlinguagem Java em busca de problemas em potencial, como possveis defeitos, cdigo no utilizado,cdigonootimizado,expressesdemasiadamentecomplexase cdigo duplicado. Fornece a gerao de relatrios onde constam os nomes arquivos testadoseoserrosencontradosemcadaum com linksparaa explicaodecada tipo de erro e a possvel soluo destes. Web site da ferramenta: http://pmd.sourceforge.net/.

STAF(SoftwareTestingAutomationFramework):umframeworkprojetadoem torno da idia de reuso e automatizao de casos de teste e ambientes de teste. Voltadoparatestesfuncionais,auxilianaescrita,execuoeanlisedosresultados obtidos atravs da execuo dos casos de teste. Possui interface grfica que permiteomonitoramentodaaplicaoduranteaexecuodostestes.Websiteda ferramenta:http://staf.sourceforge.net/index.php.

Soapui:umaaplicaodesktopescritaemJavacujaprincipalfunoconsumir
24 e testar Web Services . Dentre as caractersticas principais apresentadas pela

ferramenta, destacamse os testes funcionais e de carga. O SoapUI possibilita a criaodeasseresparaidentificarseowebServiceestatendendodeterminado requisitodeperformancedeacordocomasnecessidades.Websitedaferramenta: http://www.soapui.org/.

Grinder: uma ferramenta voltada para testes de carga de aplicaes Java. Permite simular acessos simultneos de forma que podem ser controlados o nmero de mquinas, o nmero de processos e o nmero de threads que sero executadas no teste. Possibilita tambm que a execuo de uma requisio seja

24

Web Service uma tecnologia baseda em XML e HTTP cuja principal funo disponibilizar servios interativos na Web que podem ser acessados (ou consumidos) por qualquer outra aplicao independente da linguagemouplataformaemqueaaplicaofoiconstruda.OSOAP(SingleObjectAccessProtocol)opadro universalutilizadoparaatrocademensagensentreasaplicaesconsumidoraseoWebService.OWebService expe as operaes por meio de um tipo de esquema XML chamado WSDL (Web Service Description Language)(CAETANO,2007a).

71

dependente do resultado de uma resposta anterior. Para exemplificar isto utilizadaumasituaoemqueumarequisiodeumalistadecarrosfeitaaum servidor e aps isto, querse efetuar uma alterao em um carro especfico, mas no se possui o nmero do identificador deste carro. Para obter este dado necessrio realizar uma consulta na resposta anteriormente obtida. O Grinder tambmpermiteaagregaodosdadosobtidosatravsdediversoscasosdeteste nomesmorelatrio. Websitedaferramenta:http://grinder.sourceforge.net/.

J meter:umaaplicaodesktopdesenvolvidaemJavaparaacriaodetestesde performance e testes de carga em diferentes servios de um ambiente servidor,

25 26 27 comoHTTP ,FTP eSGBD .Permiteaexecuodeplanosdetestequepodem

ser configurados graficamente. Umas das funcionalidades disponibilizadas pela ferramenta a definio de threads que servem para criar simulaes de um determinado nmero de usurios que acessam um web site por em perodo definidodetempo,sendopossvelagendarhorriosparaaexecuodasmesmas. Permiteageraodegrficoscombasenosdadosgeradosatravsdasexecues dos casos de teste. O JMeter um projeto pertencente ao Grupo Apache Jakarta (http://jakarta.apache.org ). Web site da ferramenta:

http://jakarta.apache.org/jmeter/.

Microsoft WAS: O Web Application Stress uma ferramenta gratuita da Microsoft (www.microsoft.com) destinada realizao detestes de performance, volumeestressdeaplicaesWeb.Estaferramentapermiteacriaodetestesde forma manual, escrevendose as requisies HTTP, ou de forma automtica durante a navegao pelo browser atravs de um Proxy Server. Web site da ferramenta:

25

HTTP(HyperTextTransferProtocol)ouProtocolodeTransfernciadeHipertextoumprotocoloutilizado paraatransfernciadedadosnaredemundialdecomputadores(WorldWideWeb).Tambmtransferedadosde hipermdia,comoimagensesons(WIKIPEDIA,2007). 26 FTP (File Transfer Protocol) ou Protocolo de Transferncia de Arquivos utilizado emlarga escala paraa transfernciadearquivosentreservidoreseclientes.Paraconectarseaoservidor,ousuriodeveautenticarse informando um nome de usurio e uma senha vlidos, definir os arquivos a serem enviados ou recebidos e efetuarastransaes(WIKIPEDIA,2007). 27 SGBD ou Sistema de Gerenciamento de Banco de Dados um conjunto de programas destinados ao gerenciamento de uma base de dados e possui como principal objetivo retirar da aplicao cliente a responsabilidadedegerenciaroacesso,manipulaoeorganizaodosdados(WIKIPEDIA,2007).

72

http://www.microsoft.com/downloads/details.aspx?FamilyID=e2c0585a062a 439ea67d75a89aa36495&DisplayLang=en.

J system: um framework de testes baseado no JUnit com suporte para a automatizao de testes funcionais de sistema. Foi desenvolvido na linguagem Java e permite a escrita de testes nesta mesma linguagem, alm de prover a capacidadedeexecutar um grupo de testes simultaneamente. A ferramenta

possibilitaavisualizaodostatusdotesteduranteaexecuodomesmoatravs dageraoderelatriosaolongodosprocessosdeteste.Permitequeinformaes adicionaissejaminseridasnosrelatriosetambmimplementaafuncionalidadede enviar automaticamente os relatrios para um servidor, tornandoos disponveis paraoacessoremoto.Websitedaferramenta:http://aquasw.com/jsystem/last/.

3.2.

AnliseComparativadasFer ramentas

A seguir apresentase uma anlise preliminar das ferramentas selecionadas. As avaliaes foram desenvolvidas com base na documentao existente no web site das ferramentasapresentadas.AFigura22.demonstraoresultadofinaldaanliseondeascolunas referentes s caractersticas so: (1) Anlise Esttica, (2) Teste de Unidade, (3) Teste de Integrao, (4) Teste de Sistema, (4.1) Teste de Estresse, (4.2) Teste de Performance, (5) CritriosFuncionais,(6)CritriosdeCoberturadeCdigo,(7)ExignciadeCdigoFontee (8)TestedeRegresso.

73

Fer ramentas (1) JUnit TestNG Cactus Cobertura Emma Findbugs PMD STAF Soapui Grinder JMeter WAS JSystem
Fonte: BaseadoemFranchin(2007,p.77). Figura22.

Caractersticas (2) (3) (4) (4.1) (4.2) (5) (6) (7) (8)

X X X X X

X X X X X

X X

X X X X X X X X X X X X X X X X X X X X

CaractersticasdasferramentasOO.

Analisandose a Figura 22. podese observar que as ferramentas JUnit, TestNG e Cactusoferecemapoioaotestedeunidadeutilizandocritriosfuncionais,sendoqueasduas primeiras tambm propemse a fomentar testes de regresso e as duas ltimas o teste de integrao,funcionalidadesestas(testederegressoetestedeintegrao)quepermitemuma maiorabrangnciadetestessemanecessidadedautilizaodeoutroframeworkparatal.J asferramentasCoberturaeEmmarealizamtestesdecoberturadecdigo,ondesoapontados os trechos de cdigo que so ou no exercitados pelos casos de teste executados, o que propiciainformaesparaumareavaliaodocdigodoprogramatestadooudocasodeteste executado. A anlise esttica do cdigo realizada pela ferramenta Findbugs e PMD, que apontampossveiserrosqueseroocasionadospelaexecuodocdigoavaliado,indicando soluesparaquetaiserrossejamevitados.Otestedesistemaamparadopelasferramentas STAF, Soapui, Grinder, JMeter, Was e JSystem, sendo utilizados critrios funcionais pelas seis.Porsuavez,asferramentasSoapui,Grinder,WASeJMeteramparamreasespecficas

74

do teste de sistema, sendo o teste de estresse apoiado por todas e o teste de performance auxiliadopelaJMeterepelaWAS. Em decorrncia da no existncia de caractersticas comuns a todas as ferramentas apresentadas, as mesmas devem ser agrupadas de modo que seja possvel efetuar as comparaesentreelastendocomoparmetroaspectossimilares.

3.3.

CritriodeDescartedeFer ramentas

Aproposta inicialdestetrabalhotinhaporobjetivorealizarumaanlisecomparativa deferramentaslivresparatestedesoftware.Nomomentoinicialdaetapaprticadomesmo, convencionouse a mudana de ferramentas exclusivamente livres para uma mescla entre solues livres e proprietrias, sendo realizada uma sondagem de quais as ferramentas proprietrias mais utilizadas no mercado. A partir de tal mudana no foco do trabalho, buscouseaobtenodasferramentasproprietriaseforamdefinidososcritriosdetesteque seriamexploradasnotrabalhoconformeaFigura23.mostraa seguir:

CritriodeTestes Unitrios

Fer ramentas JUnit ParasoftJTest

Cobertura

RationalPureCoverage EMMA

Performance

JMeter MercuryLoadRunner

Funcionais

MercuryQuickTestPro RationalFunctionalTester

Fonte: Primria. Figura23. Critriosdetesteparaferramentasproprietriaselivres.

Em virtude da existncia de limitaes de funcionalidade e pelo perodo limitado de prazo disponibilizado pelas licenas trial das ferramentas proprietrias, partiuse novamente para a anlise de ferramentas open source e gratuitas exclusivamente. A utilizao das ferramentas gratuitas no possui limitaes provenientes do tipo de suas licenas de uso,

75

sendo permitida a utilizao de todas as funcionalidades providas pelas mesmas por tempo indeterminado sem infringir nenhuma questo legal, alm de a comunidade de desenvolvedoresqueutilizamestasferramentascompartilharemsuasexperinciasnaInternet eatravsdelivros,tornandoseuaprendizadomenosoneroso. AreadaptaodoscritriossferramentasutilizadaspodeserobservadanaFigura24. Adefiniodocritriodetestesunitriosfoibaseadanaamplaligaodestescomaestrutura orientadaaobjetosdoscdigosfonteemJAVA,sendoostestesdesenvolvidosemclasses.A anlise da cobertura de cdigo foi selecionada com intuito de prover uma extenso utilizao dos testes unitrios, j que seu foco est em definir quanto do cdigo fonte exercitado pelos casos de teste desenvolvidos. Por sua vez, o teste de performance foi escolhido em virtude do constante crescimento da quantidade de aplicaes em ambiente Web,sendofocalizadaaanlisedaperformancedestas.

CritriodeTestes Unitrios

Fer ramentas JUnit TestNG

Cobertura

EMMA Cobertura

Performance

JMeter MicrosoftWebApplicationStress

Fonte: Primria. Figura24. Critriosdetesteparaferramentasgratuitas.

A seleo das ferramentas utilizadas foi baseada mediante pesquisa em sites com
28 contedo destinado rea de testes de software com foco em ferramentas open source

voltadasparaalinguagemdeprogramaoJAVA.Aps,foramrealizadaspesquisasemweb sites de busca para saber quais das ferramentas prselecionadas possuam documentao maisdetalhadaeorganizada.Paraadefiniodasferramentaspesquisadas,identificouseque naobradeCaetano(2007b)temseaferramentaMicrosoftWAS,queapesardenoseropen source gratuita, como alternativa para os testes de performance, sendo selecionada para realizaodestetrabalho.
28

Aanliseinicialparaadefiniodasferramentasbaseouseespecialmentenosseguinteswebsites:Open SourceTestingToolsinJava http://javasource.net/opensource/testingtoolsopensourcetesting.org http://www.opensourcetesting.org/ e JavaOpenSoftware http://www.javaopensoftware.com/opensource/testingtools.

76

3.4.

ConsideraesFinais

Estecaptulodescreveuumabrevejustificativaparaaautomatizaodafasedetestes, demonstrando a importncia da utilizao de ferramentas para tal fim. Observouse a existncia de uma considervel quantidade de ferramentas open source e gratuitas para o auxlio na atividade de testes voltadas para todos os estgios de testes e baseadas nos conceitos das mais diversas tcnicas de teste de software, sendo que nem todas as selecionadas possuem caractersticas semelhantes entre si, visando a anlise de ferramentas quecubramvriosestgiosdeteste.Tambmconstatousequealgumasferramentasutilizam conceitos de anlise esttica, o qual merece um aprofundamento conforme descrito no pargrafoaseguir. Sommerville(2004,p.367)afirmaacercadaanliseestticaqueelanorequerqueo programasejaexecutado,sendopercorridootextodesteereconhecidososdiferentestiposde declaraes. Segundo o autor, as ferramentas de anlise esttica podem detectar se as declaraesdoprogramasobemelaboradas,fazerinfernciassobreofluxodecontroledo programae,emmuitoscasos,calcularoconjuntodetodososvalorespossveisparaosdados do programa. Diferentemente da anlise esttica, a anlise dinmica engloba os testes que necessitamdaexecuodoprograma.

77

4. ANLISECOMPARATIVADASFERRAMENTAS

O presente captulo apresenta a realizao da anlise comparativa das ferramentas selecionadas. Para tal, so descritos os critrios utilizados para a execuo da anlise, bem comoaopassosnecessriosparaaexecuodosexemploseobtenodosdadosapartirdas ferramentas. Oscritriosobservadosparaacomparaodasferramentasforamdetestedeunidade, teste de cobertura e o teste de performance. Para tal, observaramse os parmetros de comparao baseados no Apndice A de Domingues (2002) e Comparison (2007), sendo gerado o documento apresentado na Figura 25. Na primeira coluna so definidos os parmetrosdeavaliaodasferramentasqueseroanalisadoscombasenasrespostasobtidas paraasquestespropostasnasegundacoluna.Estedocumentoserutilizadoparaarealizao daanlisecomparativadasferramentasescolhidasnoscritriosselecionados.

78

ParmetrodeAvaliao Plataformas FacilidadedeInstalao FacilidadedeUso

DescriodoParmetro Quaisasplataformassuportadaspelaferramenta?(Unixe Windows) Ainstalaorealizadadeformadiretaounecessrioalgum softwareouferramentaadicionalparaoseufuncionamento? Ainterfaceapresentadaamigveleintuitiva?necessrio algumconhecimentoextraparaarealizaodaconfiguraoe utilizaodaferramenta? Aferramentapermiteintegraocomoutrasferramentas? Quaisospontosfortesdaferramenta? Aferramentapermiteageraoderelatrios automaticamente?Osrelatriosgeradossodefcil compreenso? Aferramentagerarelatriosquecontenhamdadosestatsticos, grficosoucharts? Adocumentaodaferramentaadequada?Provmosdados necessriosparaobomentendimentodamesma? Existedocumentaoalmdadispostapelofabricanteda ferramenta?
Parmetrosdeavaliaodasferramentas.

Integrao Recursos GeraodeRelatrios

Formatosderelatrios Documentao Documentaoextra

Fonte: Primria.

Figura25.

O equipamento utilizado para a realizao dos testes possui as seguintes configuraes: processador AMD Semprom 3000+, 512 Mb DDR 400 de RAM, placa de vdeoNVIDIAGeForce4MX4000,sistemaoperacionalMSWindowsXPSP2elargurade banda250Mbps. Asferramentasutilizadas,bemcomoosdadosgeradosapartirdaexecuodostestes noscritriosselecionadossoapresentadosaseguir.

4.1.

TestedeUnidade

Os testes unitrios sero realizados com base em um software de exemplo desenvolvido por Oliveira (2007b) que realiza a converso de temperaturas entre as escalas Celsius e Fahrenheit. Para tal, sero utilizadas as tcnicas de teste de caixapreta de particionamentodeequivalnciaacrescidadaanlisedevalorlimiteparadefinirosintervalos devaloresexistenteseosrepresentantesdecadapartioaseremusados.

79

O software de exemplo implementa as frmulas de converso de graus Celsius para FahrenheiteFahrenheitparaCelsiusconformeapresentadonaFigura26.

Fonte: Primria. Figura26. FrmulasdeConversodetemperatura.

Para a definio das parties de equivalncia, necessrio o conhecimento dos valores dos domnios de entrada em graus Celsius e suas respectivas sadas em graus FahrenheiteointervalodeentradaemgrausFahrenheitcomsuassadasemgrausCelsius.Os domniosdeentradaesadadeambasasescalassoapresentadasnaFigura27.

Fonte: Primria. Figura27. EscalaCelsiuseFahrenheit.

A partir dos dados provenientes de ambas escalas, foram definidas as parties de equivalnciaconformemostraa Figura28.

Fonte: Primria. Figura28. PartiesdeEquivalnciadasescalasCelsiuseFahrenheit.

80

Foramdesenvolvidasasclassesparaoconversor,sendoqueaFigura29.representaa
29 interface daentidadetemperatura.

01publicinterfaceTemperature{ 02 publicdoublegetValue() 03 04 publicvoidsetValue(doublevalue)throwsException 05 06 publicdoublegetFREEZE() 07 08 publicdoublegetBOIL() 09 10 publicdoublegetZERO() 11} Fonte: Oliveira(2007b). Figura29. Interfacepararepresentaraentidadetemperatura.

29

ConformeCadenheadeLemay(2003,p.106),asinterfacescomplementameestendemopoderdasclasses,e asduaspodemsertratadasquasedamesmaforma.Masumainterfacenopodeserinstanciada.

81

AFigura30.representaaclassedaescalaCelsius,ondesodefinidasastemperaturas de fuso,deebulioeozeroabsolutodestaescala, bem comoosmtodosde manipulao destesatributos.

01publicclassCelsiusTemperatureimplementsTemperature{ 02 03 privatedoublevalue 04 05 privatefinaldoubleFREEZE=0 06 07 privatefinaldoubleBOIL=100 08 09 privatefinaldoubleZERO=273 10 11 publicCelsiusTemperature(){} 12 13 publicdoublegetValue(){ 14 returnvalue 15 } 16 17 publicvoidsetValue(doublevalue)throwsException{ 18 if(value<ZERO)thrownewException("Nohtemperatu raabaixodozeroabsoluto") 19 elsethis.value=value 20 } 21 22 publicdoublegetFREEZE(){returnFREEZE} 23 24 publicdoublegetBOIL(){returnBOIL} 25 26 publicdoublegetZERO(){returnZERO} 27 28 publicStringtoString(){ 29 returngetValue()+"C" 30 } 31 32 publicbooleanequals(Objectother){ 33 if(otherinstanceofCelsiusTemperature) 34 return(other.getValue()==getValue()) 35 elsereturnfalse 36 } 37} Fonte: Oliveira(2007b). Figura30. ClassequerepresentaaescalaCelsius.

82

A classe da escala Fahrenheit apresentada na Figura 31. , onde so definidos os atributosparaastemperaturasdefuso,ebulioeozeroabsolutodaescalaeosmtodosde manipulaodestes.

01publicclassFahrenheitTemperatureimplementsTemperature{ 02 03 privatedoublevalue 04 05 privatefinaldoubleFREEZE=32 06 07 privatefinaldoubleBOIL=212 08 09 privatefinaldoubleZERO=459.4 10 11 publicFahrenheitTemperature(){} 12 13 publicdoublegetValue(){ 14 returnvalue 15 } 16 17 publicvoidsetValue(doublevalue)throwsException{ 18 if(value<ZERO)thrownewException("Nohtemperatu raabaixodozeroabsoluto") 19 elsethis.value=value 20 } 21 22 publicdoublegetFREEZE(){returnFREEZE} 23 24 publicdoublegetBOIL(){returnBOIL} 25 26 publicdoublegetZERO(){returnZERO} 27 28 publicStringtoString(){ 29 returngetValue()+"F" 30 } 31 32 publicbooleanequals(Objectother){ 33 if(otherinstanceofFahrenheitTemperature) 34 return(other.getValue()==getValue()) 35 elsereturnfalse 36 } 37} Fonte: Oliveira(2007b). Figura31. ClassequerepresentaaescalaFahrenheit.

83

Na Figura 32. apresentada a classe de converso de temperatura entre as escalas contendoumerronomtodoconvertToCelsiusparafinsdaobservnciadocomportamento daferramentamedianteesteequivocodeimplementao.

01publicclassTemperatureTransformer{ 02 03 publicTemperatureTransformer(){} 04 05 publicTemperatureconvert(Temperaturetemp)throwsExcep tion{ 06 if(tempinstanceofCelsiusTemperature)returnconvertT oFahrenheit(temp) 07 elsereturnconvertToCelsius(temp) 08 } 09 10 privateTemperatureconvertToFahrenheit(Temperaturecelsi us)throwsException{ 11 FahrenheitTemperaturef=newFahrenheitTemperature() 12 doublecvalue=celsius.getValue() 13 doublefvalue=1.8*cvalue+f.getFREEZE() 14 f.setValue(fvalue) 15 returnf 16 } 17 18 privateTemperatureconvertToCelsius(Temperaturefahrenhe it)throwsException{ 19 CelsiusTemperaturec=newCelsiusTemperature() 20 doublefvalue=fahrenheit.getValue() 21 doublecvalue=(5/9)*fvalue5*fahrenheit.getFREEZE() 22 c.setValue(cvalue) 23 returnc 24 } 25} Fonte: Oliveira(2007b). Figura32. Classedeconversodetemperaturacomerronomtodo conver tToCelsius.

A Figura 33. corretamente.

representa a classe de converso de temperatura funcionando

84

01publicclassTemperatureTransformer{ 02 03 publicTemperatureTransformer(){} 04 05 publicTemperatureconvert(Temperaturetemp)throwsExcep tion{ 06 if(tempinstanceofCelsiusTemperature)returnconvertT oFahrenheit(temp) 07 elsereturnconvertToCelsius(temp) 08 } 09 10 privateTemperatureconvertToFahrenheit(Temperaturecelsi us)throwsException{ 11 FahrenheitTemperaturef=newFahrenheitTemperature() 12 doublecvalue=celsius.getValue() 13 doublefvalue=1.8*cvalue+f.getFREEZE() 14 f.setValue(fvalue) 15 returnf 16 } 17 18 privateTemperatureconvertToCelsius(Temperaturefahrenhe it)throwsException{ 19 CelsiusTemperaturec=newCelsiusTemperature() 20 doublefvalue=fahrenheit.getValue() 21 doublecvalue=(5*fvalue5*fahrenheit.getFREEZE())/9 22 c.setValue(cvalue) 23 returnc 24 } 25} Fonte: BaseadoemOliveira(2007b). Figura33. Classedeconversodetemperaturafuncionandocorretamente.

4.1.1. Definiodocasodeteste

Paraarealizaodaanlisedealgunsrecursosdisponibilizadospelas ferramentasde teste unitrio selecionadas, foram criadas classes para testar os mtodos de converso de temperatura da escala Celsius para a escala Fahrenheit e da escala Fahrenheit para a escala Celsius.Paratal,seroutilizadasasbibliotecasespecficasparaambasasferramentas,JUnit eTestNG,sendoasclassesdetestedesenvolvidascom estruturaequivalentedecdigo,sendo cadaumaconstrudaindividualmente. Para uma explorao mais detalhada do exemplo de teste, foi utilizada a gerao de relatriosdeambasas ferramentas,osquais apresentamosdadosprovenientesdaexecuo doscasosdetestedesenvolvidosdeformaagregada.

85

4.1.2. Recur sosecomparao

Ambas as ferramentas apresentadas propemse a automatizar a execuo de testes unitriosmedianteacriaodeclassesdetestequeexercitemosmtodosdasclassestestadas. O exemplo utilizado demonstrou a existncia de dependncia entre as classes que foram testadas, o que chamado de cluster , concluindose a partir desta constatao, que estas ferramentaspossibilitamotestedeclustersdeclasses,oqueseenquadracomoumaformade testede integraonaorientaoaobjetos.Istodemonstraque,almdostestesdeunidades isoladas,oJUniteoTestNGpossibilitamaexecuodetestesdeintegrao. Aseguirsoapresentadasalgumasdascaractersticasapresentadaspelas ferramentas JUniteTestNG,seguidodeumaanlisecomparativa.

4.1.2.1.

J Unit

ParaarealizaodostestescomoJUnitnecessrioquesejaadicionadooarquivoda bibliotecadaferramentapastadoprojetodestinadasbibliotecas.Paraaautomatizaodos testes das classes de exemplo, foi desenvolvida a classe de teste

TemperatureTransformerTest baseada em Oliveira (2007b) que pode ser observada na Figura 34. Esta classe contm dois mtodos, ambos destinados a testar a converso de temperaturasdaescalaFahrenheitparaaescalaCelsius.Adiferenaentreambosestanofato dequeoprimeirodeles,testConvertToCels(),utilizarvaloresvlidosdeentradaesadae o segundo, testConvertToCelsIn(), valores invlidos. O objetivo observar qual o comportamentodaferramentamedianteresultadosvlidoseinvlidos.

86

01packagetestetermometro 02 03importstaticorg.junit.Assert.assertTrue 04importorg.junit.Test 05 06publicclassTemperatureTransformerTest{ 07 doublevalido[][]={{32,212,459.4},{0,100,273}} 08 doubleinvalido[][]={{0,213,459.5},{0,100,274}} 09 10 @Test 11 publicvoidtestConvertToCels()throwsException{ 12 Temperaturet=newFahrenheitTemperature() 13 for(inti=0i<=valido.lengthi++){ 14 t.setValue(valido[0][i]) 15 TemperatureTransformertc=new 16TemperatureTransformer() 17 Temperaturef=tc.convert(t) 18 System.out.print("(1)"+valido[0][i]+"=>"+ 19valido[1][i]+"\n") 20 assertTrue(f.getValue()==valido[1][i]) 21 } 22 } 23 24 @Test 25 publicvoidtestConvertToCelsIn()throwsException{ 26 Temperaturet=newFahrenheitTemperature() 27 for(inti=0i<=invalido.lengthi++){ 28 t.setValue(invalido[0][i]) 29 TemperatureTransformertc=new 30TemperatureTransformer() 31 Temperaturef=tc.convert(t) 32 System.out.print("(1)"+invalido[0][i]+"=>"+ 33invalido[1][i]+"\n") 34 assertTrue(f.getValue()==invalido[1][i]) 35 } 36 } 37 }

Fonte: BaseadoemOliveira(2007b). Figura34. JUnit Classedeteste Temper atur eTr ansfor mer Test.

Osmtodosdaclassedetesteapresentadosrealizamaconversodeumatemperatura em Fahrenheit para Celsius. Para tal, foram utilizados vetores contendo a temperatura em Celsius e a temperatura em Fahreneit, tendo um deles, valores vlidos e corretos eooutro, valores invlidos e incorretos. No primeiro valor do vetor vlido, se tem como valor de entrada32(trintaedois)grausFahrenheiteasadaesperada0(zero)Celsius.Otestemanual destesvaloresdsecomaaplicaodafrmuladeconverso,conformeFigura35.

87

Fonte: Primria. Figura35. TestemanualvlidoparaconversodeFehrenheitparaCelsius.

O teste de mesa comprova que a entrada proposta, 32 (trinta e dois), deve gerar a sadaesperada,0(zero). Para melhor visualizao dos resultados dos testes efetuado com o JUnit, devese
30 configurar a gerao automtica de relatrio atravs da biblioteca ANT . Paratal, deve ser

inserido o arquivo buid.xml na raiz do projeto e configurado conforme necessidade. A execuodaclassedetestesgeraumrelatriocomooapresentadonaFigura36.

Fonte: Primria. Figura36. JUnit Relatriodetestedoprojetointeiro.

Este relatrio apresenta no topo o nmero de testes contidos na classe executada, a porcentagemdesucessoobtidabemcomootempototaldeexecuo.Aseguirencontramse ospacotesdasclassesdetestequeforamexecutadoscomosrespectivosdadosprovenientes daexecuo.Clicandosenonomedopacotetesteter mometroabertaapginaderelatrio especficadopacote,comoapresentadonaFigura37.

30

ApacheAntumaferramentautilizadaparaautomatizaraconstruodesoftware.Elasimilarao makedo Unix,masescritanalinguagemJavaefoidesenvolvidainicialmenteparaserutilizadaemprojetosdesta linguagem.umprojetodaApacheSoftwareFoundation,sednoumsoftwarelivre,licenciadosobalicena Apache(WIKIPEDIA,2007).

88

Fonte: Primria. Figura37. Junit Relatriodeexecuodopacote testeter mometr o.

No relatrio do pacote so apresentadas as classes de teste que foram executadas. Clicandosenonomedaclassepodevisualizarseorelatriodosmtodosdaclassedetestee suasestatsticas,comopodeservisualizadonaFigura38.

Fonte: Primria. Figura38. Junit Relatriodeexecuodaclasse Temper atur eTr ansfor mer Test.

No relatrio da classe pode ser observado quais dos testes foram executados e retornaram o valor esperado e quais os problemas existentes naqueles que no obtiveram xito.

4.1.2.2.

TestNG

AcriaodetestescomoTestNGfoiefetuadadaseguinteforma:inicialmenteforam baixados os arquivos necessrios do site do fabricante (http://testng.org) e foi efetuada a instalaodoplugindaferramentanoIDEEclipse.Apsisto,criouseoprojetoobedecendo estrutura apresentada pelo exemplo do conversor de temperaturas, sendo aps isto

89

adicionadapastadebibliotecasdoprojetooarquivotestng5.7jdk15.jar queestpresente juntoaoarquivocompactadobaixadodositedaferramenta. Findadas as configuraes iniciais, criouse a classe de testes

TemperatureTransformerTestquepodeservisualizadanaFigura39.

01packagetestetermometro 02 03importstaticorg.testng.Assert.* 04importorg.testng.annotations.* 05 06publicclassTemperatureTransformerTest{ 07 doublevalido[][]={{32,212,459.4},{0,100,273}} 08 doubleinvalido[][]={{0,212,459.4},{0,99,274}} 09 10 @Test 11 publicvoidtestConvertToCels()throwsException{ 12 Temperaturet=newFahrenheitTemperature() 13 for(inti=0i<=valido.lengthi++){ 14 t.setValue(valido[0][i]) 15 TemperatureTransformertc=new 16TemperatureTransformer() 17 Temperaturef=tc.convert(t) 18 System.out.print("(1)"+valido[0][i]+"=>"+ 19valido[1][i]+"\n") 20 assertTrue(f.getValue()==valido[1][i]) 21 } 22 } 23 24 @Test 25 publicvoidtestConvertToCelsIn()throwsException{ 26 Temperaturet=newFahrenheitTemperature() 27 for(inti=0i<=invalido.lengthi++){ 28 t.setValue(invalido[0][i]) 29 TemperatureTransformertc=new 30TemperatureTransformer() 31 Temperaturef=tc.convert(t) 32 System.out.print("(1)"+invalido[0][i]+"=>"+ 33invalido[1][i]+"\n") 34 assertTrue(f.getValue()==invalido[1][i]) 35 } 36 } 37 } Fonte: BaseadoemOliveira(2007b). Figura39. TestNG ClassedetesteTemperatureTransformerTest.

Aclassedetesteapresentadapossuidois mtodosquerealizamotestedaconverso deumadeterminadatemperaturadaescalaFahrenheitparaaescalaCelsius.Foramutilizados dois vetores contendo temperaturas em ambas as escalas, sendo um deles preenchido com valoresvlidosecorretoseooutrocomvaloresinvlidoseincorretos.Paraexemplificarum

90

testeinvlido,queserexecutadopelomtodotestConvertToCelsIn()edevegerarumerro devidodiferenaentreasadaesperadaeaobtida,ademonstraumtestedemesacomos valores 212 da escala Fahrenheit e 99 da escala Celsius, ambos presentes na posio intermediriadovetorinvalido,sendooprimeirovaloraentradaeosegundoasuarespectiva sadaapsaconverso.

Fonte: Primria. Figura40. TestemanualinvlidoparaconversodeFehrenheitparaCelsius.

Vse que o resultado obtido, 100, diferente do esperado, 99. Por sua vez, o mtodotestConvertToCels()realizaotestedaconversodastemperaturasutilizandovalores vlidos.Ovetorvlidopossui,emsuaposiointermediria,osvalores212comoentradae 100comosada,estandodeacordocomotestedemesa.Aexecuodestestestesutilizando o plugin do TestNG Eclipse produz um relatrio com os dados obtidos, como pode ser visualizado na Figura 41. Neste relatrio podese observar quais os testes executados, o nmerodetestesquenotiveramerroseosquetiveram.

Fonte: Primria. Figura41. TestNGRelatriodeprojeto.

91

Clicandose no nome do projeto ser aberta uma pgina onde podese visualizar os dadosdaclassetestada,conformeFigura42.Nesterelatriopodemservisualizadosonome daclassetestadaeosmtodosnassuasrespectivasannotations.

Fonte: Primria. Figura42. TestNGRelatriodeclasse.

4.1.2.3.

Comparativo

ApartirdaanlisedadocumentaodoJUnitedoTestNGedaexecuodoexemplo apresentado,foidefinidoumcomparativodasferramentas,oqualapresentadonaFigura43.

92

ParmetrodeAvaliao Plataformas FacilidadedeInstalao

J Unit UnixeWindows. Ospluginsgeralmentevem acopladossIDEs.Caso necessrio,emvirtudeda ferramentaserconstitudade umgrupodebibliotecas, bastainserlasnoprojeto quesedesejainstrumentar. Aferramentanopossui interfaceporsetratardeuma bibliotecadecdigo. incorporadopelamaioria dosIDEsmaisutilizados: JBuilder,JDeveloper, EclipseeNetBeans.Porser umabiblioteca,podeser utilizadocomqualquereditor decdigo. Permiteainstrumentalizao daexecuoedageraode relatrioscomoumatarefa daANT. Vastadocumentaoe integraocomdiversos IDEsexistentes.

TestNG UnixeWindows. Ospluginssofacilmente instalveis. Casonecessrio,em virtudeda ferramentaserconstitudade umgrupodebibliotecas,basta inserlasnoprojetoquese desejainstrumentar. Aferramentanopossui interfacepor setratardeuma bibliotecadecdigo. Possuipluginspara osIDEsEclipse,Mavene IDEA.Porserumabiblioteca, podeserutilizadocom qualquereditordecdigo. Permiteainstrumentalizao daexecuoedageraode relatrioscomoumatarefada ANT.

FacilidadedeUso

Integrao

Recursos

GeraodeRelatrios

Sim,medianteconfigurao daANT. Sim,osrelatriossobem intuitivosedefcil compreenso. Sim,estatsticos. Sim.Adocumentaoda ferramentadescreveos recursosdamesma,bem comodaformadeutilizao econfigurao.

Formatosderelatrios Documentao

Documentaoextra
Fonte: Primria. Figura43.

Sim.

Suportaoscdigos desenvolvidosnoJUnitapenas commudanadasbibliotecas utilizadas. Foidesenvolvidaabaseadana JUnit,estendendooseuuso. Sim,medianteousodos pluginsoudaconfiguraoda ANT. Relatriosumtantoconfusos, compresenadeinformaes irrelevantes. Sim,estatsticos. Empartes.Adocumentaoda ferramentadescreveos recursosdamesma,bemcomo daformadeutilizaoe configurao,masdeixaa desejarempartesquanto clarezaparaumacompreenso facilitada. Sim.

Comparativodasferramentasdetesteunitrio.

93

4.1.3. Concluses

As ferramentas de teste unitrio apresentadas neste captulo possuem funcionamento semelhanteporambastrataremsedebibliotecasdecdigoparaacriaodetestesnaprpria linguagemdeprogramaoJava.Contudo,oTestNGfoidesenvolvidobaseadonoJUnit,com propsitodeestenderassuasfuncionalidades.Dessaforma,todocdigoescritoparaoJUnit podesermigradoparaoTestNGsofrendoapenasmudanasdepequenoescopo.Estacriao apartirdaconcorrentetempermitidoaoTestNGestarumpassoafrentedoJUnit,quetem lanadonovasversescomosrecursosjdisponibilizadospeloTestNG. Porsuavez,oJUnitapresentamaiordocumentaoemdecorrnciadesermaisantiga e por ter grande aceitao por parte dos desenvolvedores de software que utilizam a linguagemdeprogramaoJAVA.Outrofatorelevanteaexistnciadediversosframeworks detestequeutilizamoJUniteoestendem,comooCactusporexemplo. ApesardadocumentaoeagrandeaceitabilidadedoJUnit,aTestNGtemdespontado comouma ferramentaqueapresenta inovaes nooferecidaspelaconcorrenteacada nova versolanada,possibilitandoumaabrangnciamaiordefuncionalidadessupridas.

4.2.

TestedeCobertura

A avaliao da cobertura dos testes unitrios e de integrao realizados em um softwarepermiteaconstataodequaisreasdecdigoaindanoforamexercitadasatravs dos testes executados, possibilitando equipe envolvida no projeto a focalizao de novos testesnasreasnocobertas.

4.2.1. Definiodocasodeteste

A realizao da anlise comparativa das ferramentas EMMA e Cobertura ocorreu mediante a configurao das ferramentas de forma individual no projeto de exemplo do

94

conversordetemperaturaseexecuodostestescriadoscomoframeworkJUnit.Aexecuo das ferramentas foi feita com auxlio da biblioteca ANT, sendo o desenvolvimento e configuraodostestesrealizadocomoIDEEclipse.

4.2.2. Recur sosecomparao

realizao

dos

testes

de

cobertura

utilizou

classe

de

teste

TemperatureTransformerTestdesenvolvidanoJUnit,aqualapresentadanaFigura44.
01importjunit.framework.TestCase 02 03publicclassTemperatureTransformerTestextendsTestCase{ 04 publicvoidtestConvert()throwsException{ 05 Temperaturet=newFahrenheitTemperature() 06 t.setValue(32) 07 TemperatureTransformertc=newTemperatureTransformer() 08 Temperaturef=tc.convert(t) 09 assertTrue(f.getValue()==0) 10 } 11}

Fonte: Oliveira(2007b). Figura44. Classe Temper atur eTr ansfor mer Test paratestedecobertura.

A seguir so descritos os passos na criao do teste de cobertura por ambas as ferramentasselecionadaseapresentadosalgunsdosrecursosdisponibilizadospelasmesmas.

4.2.2.1.

EMMA

Para a realizao dostestes de cobertura das classes de exemplo pela classe de teste comoEMMA,deveseadicionarosarquivosemma.jar eemma_ant.jar queencontramse napastalibdoarquivoobtidonositedaferramenta.Feitoisto,passaseparaaconfigurao doEMMAparaexecuojuntamentecomaANT,oquerealizadocomacriaodastarefas de instrumentaoedegeraoderelatriosnoarquivobuild.xml,quedevesercriadona raizdoprojeto.

95

Findadasasconfiguraes,oEMMAexecutadoseguindoseosseguintespassos:no Eclipse, clicar com o boto direito do mouse sobre o arquivo build.xml, selecionar a opo RunaseposteriormenteAntBuild.Natelaapresentada,selecionaraaba Classpath,clicar emUserEntries eemseguidanobotoAddJARs.Selecionartodososjarsdodiretrio lib (emma.jar e emma_ant.jar). Clicar no boto Add External JARs e selecionar o arquivo
junit.jar nosubdiretrio plugins/org.junit4_4.3.1.Clicarem Ok eposteriormenteem Run.

A execuo da ANT gera uma pasta no diretrio do projeto com o nome emma, e dentrodestaestapastarelatrio,ondeficamarmazenadososrelatrioscriados.Abrindose oarquivocoverage.htmlpodeseobservarosdadosdacoberturadostestesdoprojetointeiro conformemostraa Figura45.

Fonte: Primria. Figura45. Emma Resumodacoberturadetestesdoprojetointeiro

Na parte superior do relatrio indicado o percentual de cobertura das classes, mtodos e blocos. Abaixo dessa informao, em Overall Stats Summary, apresentado um resumodaquantidadedepacotesexistentesnoprojeto,bemcomoarquivos,classes,mtodos elinhasexecutveis.Porfim,mostradaaanlisedospacotesdoprojeto,sendoinformadoo percentualdecoberturadasclassesdecadaum,bemcomoseusrespectivosmtodos,blocose linhas. NorelatriogeradopeloEmma,possvelaobtenodedetalhessobreacoberturade cadapacoteclicandosenonomedomesmo.Noexemploapresentadoorelatriodopacote testetermometroconformedemonstradonaFigura46.

96

Fonte: Primria. Figura46. Emma Resumodacoberturadetestesdopacote testeter mometr o.

Da mesma formacomonospacotes,possvel aexploraode maisdetalhesacerca dacoberturadostestesemcadaclassedopacoteselecionado.AFigura47.mostraosdados decoberturadaclasseTemperatureTransfor mer.J ava.

Fonte: Primria. Figura47. Emma Resumodacoberturadetestesdaclasse Temper atur eTr ansfor mer .java

Aslinhas9,16,17,18,19e20apresentamcoloraovermelhanorelatriogeradoe indicamaspartesdocdigoquenoforamexercitadaspeloteste.Jaslinhas4,5,8,11,25, 26, 29, 31 e 32, que apresentam colorao verde no arquivo gerado, indicam as partes de

97

cdigo que foram exercitadas. As demais linhas representam as partes de cdigomorto, sendo reas de cdigo que no so executadas, como os comentrios por exemplo. Esta diferenciao de cores permite uma melhor visualizao da rea de cdigo coberta pelos testes.

4.2.2.2.

Cobertura

A realizao dos testes de cobertura das classes de exemplo atravs do uso do Cobertura dada de acordo com alguns passos. Inicialmente, aps baixar o arquivo coberturax.xsrcdowebsitedofabricanteedescompactlo,deveseadicionarosarquivos contidosnapastalibda ferramentaaodiretriodas bibliotecasdoprojeto.Aps,criaseo arquivo build.xml na raiz do projeto e configurase o mesmo, de forma que o teste de cobertura e a gerao de relatrios sejam realizados de forma automtica juntamente com a execuodaANT. AofinaldasconfiguraesdoCobertura,otesteexecutadoseguindoseospassosa seguirdefinidos:noEclipse,clicarcomobotodireitodomousesobreoarquivobuild.xml, selecionaraopoRunaseposteriormenteAntBuild.Natelaapresentada,selecionaraaba
Classpath,cliqueem UserEntries eemseguidanoboto AddJARs.Selecionartodosos

jarsdodiretrio lib doprojetoecliqueemOk.Aps,clicarnoboto AddExternalJARs eselecionaroarquivo junit.jar nosubdiretrioplugins/org.junit4_4.3.1 dainstalao doEclipse.ClicaremOk eposteriormenteemRun. A execuo da ANT gerar uma pasta de nome cobertura no diretrio do projeto, onde ficam armazenados os relatrios criados. Abrindose o arquivo index.html podese observarosdadosdacoberturadostestesdasclassestestadas,conformemostraaFigura48. No topo do relatrio so listados os testes separados por pacotes (Package), o nmero de classes de cada pacote, a mdia de porcentagem de linhas cobertas pelo teste, a mdia da porcentagemdecoberturadedecisoeamdiadacomplexidadeciclomticadecadapacote.

98

Fonte: Primria. Figura48. Cobertura Resumodacoberturadetestesdasclassesselecionadas.

Paraavisualizaododetalhamentodas informaesdecadapacote,bastaclicar no nomedomesmoeserabertaumapginasemelhantedemonstradanaFigura49.Almdos dadosdopacote,podeserobservadoumresumodosdadosdecadaclasseenvolvidanoteste.

Fonte: Primria. Figura49. Cobertura Resumodacoberturadetestesdopacote testetermometr o.

Damesmaformaqueacontececomospacotes,aoclicarnonomedeumaclasse,ser abertaumapginacontendoosdadosdetalhadosdacoberturadestaeasreasdecdigoque foram exercitadas ou no com os testes realizados. As linhas que possuem a colorao de fundodiferenciada(0,7,8,9,14,16,17,18,19,20e23)indicamasreasdecdigoqueno estosendocobertaspelostestesexecutados.AFigura50.mostraoexemploderelatrioda coberturadetestesdaclasseTemperatureTransfor mer.

99

Fonte: Primria. Figura50. Cobertura Resumodacoberturadetestesdaclasse Temperatur eTr ansfor mer .

4.2.2.3.

Comparativo

Aseguir,naFigura51.,demonstradoumcomparativodasferramentasdeanlisede cobertura estudadas. Os resultados foram obtidos mediante estudo da documentao das ferramentasedaexecuodoexemploapresentado.

100

ParmetrodeAvaliao Plataformas FacilidadedeInstalao

EMMA Unix,Windowseoutras. Aferramentaconstitudade umgrupodebibliotecasque devemserinseridasnoprojeto quesedesejainstrumentar.

Cobertura

FacilidadedeUso

Integrao

Recursos

GeraodeRelatrios Formatosderelatrios Documentao

Documentaoextra
Fonte: Primria. Figura51.

Unix,Windowseoutras. Aferramentaconstitudade umgrupodebibliotecasque devemserinseridasno projetoquesedeseja instrumentar. Aferramentanopossui Aferramentanopossui interfaceporsetratardeuma interfaceporsetratardeuma bibliotecadecdigo. bibliotecadecdigo. Aferramentapodeser Aferramentapodeser utilizadavialinhadecomando utilizadavialinhade oucomotarefadaANT. comandooucomotarefada ANT. Aferramentanonecessitaque Aferramentanonecessita nenhumaalteraoseja quenenhumaalteraoseja efetuadanocdigo. efetuadanocdigo. Sim.Sim. Sim.Sim. Formatostexto,HTMLe FormatosHTMLeXML. XML. Sim.Adocumentaoda Sim.Adocumentaoda ferramentadescreveos ferramentadescreveos recursoseaformade recursoseaformade utilizaodosmesmos. utilizaodosmesmos. Sim. Sim.
Comparativodasferramentasdetestedecobertura.

4.2.3. Concluses

As ferramentas apresentadas possuem grandes semelhanas na maioria dos recursos porelasdisponibilizadas,comoocasodosrelatrios,bemcomoaformadeutilizaodas mesmas,sendoquetantoaEMMAquantoaCoberturanonecessitamdeacessoaocdigo fonte para a obteno dos dados nem para acrscimo de tags ou cdigo especfico para o servioaqueambassepropem. Umadasprincipaisdiferenasestnapossibilidadedageraoderelatriosemmodo textopelaEMMA,emboranoapresentandoumaquantidadesignificativaderecursos,uma formabemsintticadaexplanaodosdadosobtidos.Outrofatorquemostrousefavorvel EMMA a existncia de maior quantidade de documentao, tanto no web site oficial da

101

ferramenta quanto em outros sites, o que demonstra uma maior aceitao por parte dos desenvolvedores. Outro fator relevante foi o tempo de execuo dos testes pelas ferramentas. Com configuraes semelhantes da tarefa ANT para a compilao e gerao dos relatrios e utilizandose a mquina (PC) com as mesmas configuraes, a EMMA levou 4 segundos contra7segundosdaCobertura,sendoumadiferenabastantesignificativa. Com base nas informaes apresentadas, podese observar que as ferramentas possuem uma similaridade considervel. Porm, a maior existncia de documentao, a possibilidadedegeraoderelatriosemformatotextoeomenortempoparaaexecuoda anlisedecoberturademonstramqueaEMMAdetmcertavantagemsobreaconcorrente.

4.3.

TestedePerfor mance

O teste de performance um tipo de teste de sistema que pode ser aplicado em softwares desenvolvidos tanto em linguagem orientada a objetos quanto em linguagens utilizando outros paradigmas de programao. Isto ocorre em virtude do foco dos testes de sistemasernafuncionalidadedosoftwareenonaestruturadocdigodomesmo.

4.3.1. Definiodocasodeteste

Paraarealizaodaanlise,serefetuadaaatividadedeautenticaonowebsiteda Cincia da Computao da Universidade de Passo Fundo (http://www.upf.br/computacao) mediante o preenchimento do campo de usurio e senha e a submisso do formulrio para validao.Apsavalidaoserefetuada,darseoencerramentodasessoatravsdoclique no boto sair. Justificase a escolha do site da Cincia da Computao da UPF por dois motivos:primeirodevidoexistnciadoformulriodeautenticaoparaademonstraoda funcionalidade de armazenamento de dados de usurios e senha pelas ferramentas apresentadas.Osegundo motivodeveseaositeselecionadoserdocursonoqualoautordo presentetrabalhorealizasuagraduao.

102

Em ambas as ferramentas, o teste ser gravado com a utilizao do recurso de gravaoautomticaduranteanavegaopelowebsitedeacordocomospassospropostos. Findo tal atividade, os testes sero configurados de maneira semelhante em ambas as ferramentas, sendo explorados alguns recursos que as mesmas propiciem e os testes sero executados.

4.3.2. Recur sosecomparao

As ferramentas utilizadas para a realizao da anlise comparativa sob o critrio de testedeperformancesoapresentadasaseguir.

4.3.2.1.

J Meter

DevidoaofocodotrabalhoestarvoltadoparaaplicaesWebrodandosoboprotocolo HTTP,foramexploradososrecursosqueaferramentadisponibilizaparatalfim.

103

Para a criao e configurao de um plano de testes, o principal recurso a ser adicionado ao mesmo o Thread Group, conforme mostra a Figura 52.

Fonte: Primria. Figura52. JMeter AdicionarThreadGroup.

AsconfiguraesdoThreadGroupsomostradasnaFigura53.Esterecursopermite a configurao do nmero de usurios virtuais simultneos que sero simulados durante e execuodostestes.Tambmpodeserconfiguradoumperododetempoparaaentradaem atividade dos usurios virtuais, o que evita que todos os usurios comecem a operar no mesmomomento.

104

Fonte: Primria. Figura53. JMeter ThreadGroup

Podese definir quantas vezes um teste ser executado com as configuraes selecionadas.Tambmpodemserdefinidasasdatasehorasdeincioefimdaexecuodos testes. Paraarealizaodagravaodeumtesteduranteanavegao,deveseacrescentarao planodetesteorecursoHTTPProxyServer,quedemonstradonaFigura54.

105

Fonte: Primria. Figura54. JMeter HTTPProxyServer

O objetivo do HTTP Proxy Server capturar e gravar as requisies feitas entre o browsereoservidor(GETePOST)paraqueposteriormenteotestepossaseguirospassos armazenadosdurantesuaexecuo.Paraqueesterecursofuncionecorretamente,necessria aconfiguraodoProxydobrowserutilizado. Outro recurso oferecido pelo JMeter so os Assertions (asseres), que permitem a validao das respostas das requisies HTTP por diversos tipos de parmetros, conforme mostraaFigura55.

106

Fonte: Primria. Figura55. JMeter Tiposde Assertions.

SeroutilizadosostiposResponseAssertioneDurationAssertion.Aprimeirapermite quesejaprocuradoumdeterminadotextonocontedodeumarequisiohttp.Seotextofor encontrado, a assero retornar como verdadeira, do contrrio ser falsa. J a segunda possibilitaavalidaodeumarequisiocombasenotempomximodeduraodaresposta. Casootempoderespostasejasuperioraoesperadoentoaasserofalhar. Paratornaranavegaomaisrealstica,oJMeterpermiteainserodeumTimerque temcomoobjetivo inserirumtempodeparadaentreumarequisioeoutra,simulandoum usuriorealquegeralmentenoentranapgina eclicaautomaticamenteemoutrolink sem observar nenhum componentedapgina,comotextosoufiguras.UmdostiposdeTimer,o Uniform Random Timer, apresentado na Figura 56. Este Timer permite a definio dos perodosmnimoemximodeparadaentreasrequisies.

107

Fonte: Primria. Figura56. JMeter UniformRandonTimer.

Osdadosprovenientesdaexecuodostestespoderoservisualizadosatravsdeum ou mais dos diversos tipos de Listeners (relatrios) que a ferramenta oferece, os quais so mostradosnaFigura57.

Fonte: Primria. Figura57. JMeter Relatrios.

108

Durante a execuo dos testes e ao final da mesma, possvel a visualizao dos resultados obtidos pelos Listeners. Num dos tipos de relatrios do JMeter, o Assertion Results,soapresentadososdadosdasrequisiesHTTPquenoatenderamaosparmetros dasrequisies,comopodeservistonaFigura58.

Fonte: Primria. Figura58. JMeter Relatrio AssertionResults

Porsuavez,orelatrioGraphResultsapresentaumgrficoquedescrevedadoscomo o desvio padro e a taxa requisies realizadas por minuto, como pode ser observado na Figura59.

109

Fonte: Primria. Figura59. JMeter Relatrio GraphResults

31 J o Aggregate Graph demonstra as estatsticas individuais de cada item retornado

dasrequisies,permitindoageraodegrficosde barrasdascolunasdedados,conforme mostraaFigura60.

31

Entendeseporitemtodoequalquerdocumentointegrantedeumapgina,comoporexemploumHTML,um arquivodefolhadeestilos(CSS)ouumafiguraJPG.

110

Fonte: Primria. Figura60. JMeter Relatrio AggregateGraph

Porfim,aFigura61.mostraoViewResultTreequeapresentaumarvoredosdados de todas as requisies realizadas, permitindo a visualizao de todo o contedo da requisio, exatamente como o browser teria recebido no caso de qualquer usurio estar navegandopelosite.

111

Fonte: Primria. Figura61. JMeter Relatrio ViewResultsTree.

4.3.2.2.

MicrosoftWEBApplicationStress(WAS)

ParaacriaodotestedocasodetestedeexemploutilizandoseoMicrosoftWASfoi utilizada a gravao automtica atravs da navegao pelas pginas definidas. Aps selecionaraopodegravaoautomtica,abertaatelamostradanaFigura62.quepermite aseleodasopesdegravaodasrequisiescomotempodeesperaentreasrequisies, agravaodoscookiesdobrowsereagravaodoscabealhosdoservidor.

112

Fonte: Primria. Figura62. MicrosoftWASBrowserRecorder.

Depois de realizada a gravao das etapas da navegao, os dados provenientes das requisiespodemservisualizadosna Figura63.OcampoServer definequalservidorweb foi acessado para a realizao das requisies. Por padro, o WAS atribui a este campo o valor localhost, sendo necessria sua alterao para que oteste funcione corretamente. As requisiesHTTPgravadassoapresentadasnapartedebaixodatela.OWASpermiteque qualquerparmetrodeumarequisiosejaalterado.

Fonte: Primria. Figura63. MicrosoftWASServidorerequisiesrealizadas.

113

Clicandose duas vezes sobre a requisio desejada sero mostrados os dados da requisio,comomostraoexemplonaFigura64.

Fonte: Primria. Figura64. MicrosoftWASDetalhesderequisio.

A Figura 65. mostra o subitem Settings do script de teste gerado onde podem ser configurados o nmero de usurios concorrentes (threads) que sero simulados durante a execuodostestes,bemcomoonmeroderequisiesqueseroefetuadasporcadausurio. NoscamposdoTestRunTimepodeserconfiguradoolimitedetempoparaaexecuodos testes. Outro recurso provido pelo WAS Request Delay que possibilita que sejam definidas paradas por um tempo aleatrio entre as requisies realizadas. Para tal, deve ser marcadoocampoUserandomdelayeatribudososvaloresmximoemnimoquepodem seriguais,casosedesejemanterumintervalofixodetempo.Tambmpodemsersimuladas execuesdetestesemdiversaslargurasdebandasatravsdaseoBandwidth.

114

Fonte: Primria. Figura65. MicrosoftWASSettings.

Em virtude da existncia de reas nos sites que so mais acessados do que outras, como no caso do acesso efetivo atravs da autenticao onde nem todos os usurios que navegarempelositeiroseautenticar,oWASofereceapossibilidadedacriaodegruposde usurios (Page groups) com percentuais de distribuio dos acessos. Para exemplificar tal uso,foicriadoogrupodeusurioslogin,comopodeservisualizadonaFigura66. Apscriadoogrupo,foiatribudosrequisiespertencentesdaautenticaonosite deexemploatoencerramentodasessoogrupodeusurioslogin.

115

Fonte: Primria. Figura66. MicrosoftWASGruposdeusurios.

Aexecuodostestescriadosgeraautomaticamenteumrelatrioemformatotextoda compilao dos dados provenientes da mesma. A Figura 67. mostra um resumo geral da quantidadederequisiesefetuadas,bemcomoaquantidadedebitsenvolvidosnasmesmas.

116

Fonte: Primria. Figura67. MicrosoftWASRelatrio Overview.

No item Page Summary apresentado um resumo da quantidade de acessos e de Kbytes envolvidos nas requisies separados por pgina, conforme pode ser visualizado na Figura68.

117

Fonte: Primria. Figura68. MicrosoftWASRelatrioPageSummary.

O WAS gera outros relatrios, como o resumo das requisies separadas por Page

Groupseaapresentaodosresultadosdetalhadosporpgina,quenoserodemonstrados
aqui.

4.3.2.3.

Comparativo

Com base na documentao estudada e nos testes realizados, foi definido um comparativodasferramentasdetestedeperformance,conformeapresentaaFigura69.

118

ParmetrodeAvaliao Plataformas FacilidadedeInstalao

J Meter UnixeWindows. Apsbaixadooarquivodo websitedaferramenta,basta descompactloeexecutar.

MicrosoftWAS Windows. Baixaseoarquivoinstalador dowebsitedaferramenta, executaseomesmoparaque sejarealizadaainstalaoe executaseaferramenta. Possuiinterfacegrfica amigvel,estandoosrecursos dispostosdeformabem organizada. Asconfiguraesso,emsua maioria,intuitivaseno demandamconhecimentos almdoenvolvidonarea. Nofoipossvelidentificar.

FacilidadedeUso

Integrao

Possuiinterfacegrfica amigvel,estandoos recursosdispostosdeforma bemorganizada. Asconfiguraesso,em suamaioria,intuitivaseno demandamconhecimentos almdoenvolvidonarea. Ofereceapossibilidadede executarostestespormeio deumatarefadoANT. 1.Portabilidade 2.AsAssertions(asseres) permitemavalidaode respostasdasrequisies HTTP,comootempode respostaouaexistnciade determinadotextono contedodapgina. 3.Osdiversostiposde Listeners(relatrios) facilitamavisualizaodos dadosprovenientesdas requisies. Sim.Aajudadaferramenta possuiexplicaodetalhada sobreosrelatrios,oque facilitaacompreenso destes. Relatriosestatsticos, grficosecharts. Adocumentaoda ferramentadescreve detalhadamentecadarecurso damesma,possuindo explicaodecadaitemde menu. Owebsitedaferramenta possuidocumentao explicativaparainstalaoe configurao.

Recursos

1.OsPageGroupspermitem umamaiorsimilaridadecoma realidadequantodistribuio dosacessosasdiversasreas deumaaplicaoWebpois estasnosohomogneas.

GeraodeRelatrios

Sim.Aajudadaferramenta possuiexplicaodetalhada sobreosrelatrios,oque facilitaacompreensodestes. Relatriosestatsticos. Adocumentaodaferramenta descrevedetalhadamentecada recursodamesma,possuindo explicaodecadaitemde menu. Owebsitedaferramentano possuidocumentao.

Formatosderelatrios Documentao

119

ParmetrodeAvaliao Documentaoextra

J Meter Possuivastadocumentao extradevidoaceitaopor partedosdesenvolvedores, inclusiveemlngua portuguesa.

MicrosoftWAS Nopossuimuita documentaoextra,ea existenteestdisponvel somenteemlnguainglesa.

Fonte: Primria. Figura69. Comparativodasferramentasdetestedeperformance.

4.3.3. Concluses

A funcionalidadepropostaporambasas ferramentas,oJakartaJMetereoMicrosoft WEB Application Stress, derealizar teste de performance, de volume e de stress, embora tenha sido abordado somente o primeiro neste trabalho. Entretanto, os recursos disponibilizadosporambaspossuemconsiderveldisparateafavordaferramentaJMeter. Arealizaodetarefasessenciais,comoagravao,configuraoeposteriorexecuo dostestes,demonstrouumcertograudeequivalncia.Porm,osrecursoscomoasAssertions propiciadaspeloJMeterderamlhevantagemsobreaconcorrentedaMicrosoftquedeixoua desejaremambasassituaes. Outro fator que favorece a ferramenta do grupo Jakarta a portabilidade. Por ser desenvolvida totalmente na linguagem de programao JAVA, ela pode ser executada em qualquer sistema operacional que suporte um JVM. J a WAS, por ser da Microsoft, ficou atreladaunicamenteaplataformaWindows,oquejpropiciaaperdademercadoporpartede desenvolvedoresadeptosdosoftwarelivre. O fator documentao tambm pesou a favor do JMeter, que possui documentao anexa ela, como tambm o WAS, mas apresenta no site oficial maior detalhamento dos recursosdisponibilizadospelamesma.Almdisto,ofatodeserumaferramentabemaceitana comunidade de desenvolvimento aumenta a documentao extra, com a produo e disponibilizao de exemplos e explicaes da mesma por parte dos desenvolvedores que a utilizam. Por outro lado, por ser uma ferramenta mais robusta, com mais recursos, e por dependerdeumaJVMpararodar,oJMeterconsomeconsideravelmentemaisrecursosdoque a concorrente de acordo com o medidor de desempenho do Gerenciador de Tarefas do Windows, necessitando de mais recursos de hardware para ser utilizada. Apesar disto, A

120

JMeter apresenta diversos recursos no disponveis na Microsoft WAS, alm de documentaomaisvasta,oquelheconferevantagenssobreaconcorrenteanalisada.

4.4.

ConsideraesFinais

Este captulo demonstrou a anlise comparativa das ferramentas (JUnit, TestNG, EMMA, Cobertura, JMeter e Microsoft WAS) nos critrios de teste de unidade, teste de coberturaetestedeperformance.Notestedeunidade,foramutilizadasasferramentasJUnite TestNG,dasquaisasegundadelasapresentousecomomelhoralternativaparaaexecuode testespoistevesuacriaobaseadanaconcorrenteeabrangefuncionalidadesqueoJunitno contempla. Noteste de cobertura, as ferramentas analisadas foram o EMMA e a Cobertura, apresentandoseconsideravelmentesemelhantesquantosfuncionalidadesprovidas.Porm,o EMMAapresentousemelhoremvirtudedapossibilidadedegeraoderelatriosemmodo texto,almdelevarmenortempoparaacompilaoegeraoderelatrios.Porfim,noteste de performance foram analisadas as ferramentas JMeter e Microsoft WAS, obtendose resultadofavorvelaoJMeter,emdecorrnciadaexistnciadediversosrecursosnoprovidos pelaconcorrente,comoocasodosListeners.

121

CONSIDERAESFINAIS

O principal objetivo da atividade de teste de software diminuir o nmero de erros existentesemum softwareaonvel mnimopossvel.Entretanto,grandepartedoscustosde umprojetodesoftwareconsumidapelaatividadedetestes,mesmoqueestanogarantaa infalibilidadedosoftwareproduzido. Buscando prover a reduo do tempo e dos custos referentes atividade de testes, diversas metodologias de trabalho tm sido propostas por diversos autores, cabendo ao testador definir a partir de quais delas podese obter um teste com maior incidncia de sucesso.Outrofatorquetemcontribudoparaareduodecustosassociadosaostesteso desenvolvimentodeferramentasparatalfim. Considerandose tambm o paradigma OO e a grande aceitao que vem sendo despendidaaestepordesenvolvedoresepesquisadores,fazseindispensvelaavaliaodas ferramentasparatestedesoftwaresOO.Outraapreciaopertinenteacercadoprovimento de alternativas s ferramentas proprietrias de teste que no comprometam a qualidade da atividadedetestes. O presente trabalho buscou identificar ferramentas open source e gratuitas que provenhamauxliosatisfatrioparaaautomatizaodaatividadedetestesparasoftwaresOO semgerarnuspelaaquisiodeferramentasproprietrias.Paraaanlisesegundooscritrios definidos,foramutilizadasasferramentasJUniteTestNGparaostestesdeunidade,EMMAe CoberturaparaostestesdecoberturaeoJMetereoWASparaostestesdeperformance.No primeirocritrio,oTesteNGapresentousecomomelhoralternativadasduasparaaexecuo detestespoistevesuacriaobaseadanaconcorrenteeabrangefuncionalidadesqueoJunit no contempla. No segundo critrio, teste de cobertura, as ferramentas apresentaramse consideravelmente semelhantes quanto s funcionalidades providas. Porm, a EMMA

122

apresentouse melhor em virtude da possibilidade de gerao de relatrios em modo texto, alm de levar menor tempo para a compilao e gerao de relatrios utilizando o mesmo equipamentoemesmasconfiguraes.Porfim,nocritriodetestedeperformance,oJMeter obteve resultado favorvel em decorrncia da existncia de diversos recursos no providos pelaconcorrente,comoocasodosListeners. A partir das anlises realizadas, pode concluirse que possvel e aplicvel automatizaodaatividadedetestedesoftwareOOutilizandosesomenteferramentaslivres. Como trabalhos futuros, pretendese ampliar a anlise comparativa de ferramentas incluindosesoluespagas sgratuitas j analisadasabordandocritrios noexplorados na realizaodopresentetrabalho,taiscomoanliseesttica,testedeintegrao,testedesistema etestesderegresso.

123

REFERNCIASBIBLIOGRFICAS

AGUIAR,Maurcio.TestedeSoftwareeMelhoriadeProcessos.Disponvelem: <http://www.metricas.com.br/DTeste.htm>.Acessoem:02abr.2007. AMBROSIO,AnaMaria.TestedeConformidadeparaSoftwaredeSistemasEspaciais. Disponvelem: <http://www.inpe.br/atifs/documentos/public_nacional/ambrosio_wtd_revisado.pdf>.Acesso em:30mai.2007. ALMEIDA,HyggoOliveirade.OrientaoaObjetos.Disponvelem: <http://webx.sefaz.al.gov.br/posengsoft/documentos/as1/oo.pdf>.Acessoem:22mai.2007. BEIZER,Boris.SoftwareTestingTechniques.2.ed.NewYork:VanNostrandReinhold Company,1990. BINDER,R.V. TestingObjectOrientedSystems:AStatusReport.Disponvelem: <http://www.rbsc.com/pages/onlineix.html>.Acessoem:31mai.2007. CADENHEAD,RogersLEMAY,Laura.Aprendaem21diasJava:ProfessionalReference. SoPaulo:ElsevierEditoraLtda,2003. CAETANO,Cristiano.SoapUI:TestesdeWebServicesRpidoeDescomplicado.Disponvel em:<http://www.linhadecodigo.com.br/artigos.asp?id_ac=1286>.Acessoem:22jun.2007a. CAETANO,Cristiano.AutomaoeGerenciamentodeTestes: AumentandoaProdutividade comasPrincipaisSoluesOpenSourceeGratuitas.2007b. COMPARISON:HTTPDriverTools.Disponvelem: <http://bugs.sakaiproject.org/confluence/download/attachments/7105/HTTP_Test_Tool_Com parison.xls?version=1>.Acessoem:20out.2007. DEUTSCH,MichaelS.,VerificationandValidation ,inSoftwareEngineering(R.Jensen andC.tonies,eds.),PrenticeHall,1979. DOMINGUES,AndrLusdosSantos. AvaliaodeCritrioseFerramentasdeTestepara ProgramasOO.2002.Dissertao(Mestrado) UniversidadedeSoPaulo,SoCarlos,2002.

124

Disponvelem:<http://www.teses.usp.br/teses/disponiveis/55/55134/tde28112002 171043/publico/Dissertacao.pdf>.Acessoem:25out.2006. ERRO,Defeito,FaltaeFalha:Cuidadoaodarnomes.Disponvelem: <http://jcspl.wordpress.com/2006/08/20/errodefeitofaltafalhaerrorfaultfailure/>.Acesso em:28mar.2007. FINDBUGSFactSheet.Disponvelem:<http://findbugs.sourceforge.net/factSheet.html>. Acessoem:23jun.2007. FRANCHIN,IvanGustavo. TesteEstruturalParaPardeProgramasOrientadosaObjetos eaAspectos:CritrioseAutomatizao.2007.Dissertao(Mestrado) UniversidadedeSo Paulo,SoCarlos,2007.Disponvelem: <http://www.teses.usp.br/teses/disponiveis/55/55134/tde30052007 005908/publico/DissertacaoIvanGFranchin.pdf>.Acessoem:20jun.2007. HARROLD,MaryJane.Testing:ARoadmap.In:InternationalConferenceonSoftware EnginneringFutureofSoftwareEngineering,22,2000,Atlanta.Atlanta,2000,p.6172. HARROLD,MaryJaneROTHRMEL,Gregg.PerformingDataFlowTestingonClasses.In: ACMSIGSOFTSymposiumonFoundationsofSoftwareEngineering,2,1994,NovaYork. NovaYork:ACMPress,1994a,p.154163. HARROLD,MaryJaneROTHERMEL,Gregg.SelectingRegressionTestsforObject OrientedSoftware.In:ProceedingsoftheInternationalConferenceonSoftwareMaintenance, 1994.Victoria,1994b,p.1425. HARROLD,MaryJane,MGREGOR,JohnD.,FITZPATRICK,KevinJ.IncrementalTesting th ofObjectOrientedClassStructures.In:14 InternationalConferenceonSoftware Engeneering,1992.p.6880. HOLUB,Allen.OODesignProcess:UseCases,anIntroduction.Disponvelem: <http://www128.ibm.com/developerworks/webservices/library/codesign5.html>.Acesso em:23mai.2007. IEEE IEEEStandardGlossaryofSoftwareEnginneringTerminology.Standard610.12 1990,IEEEComputerSocietyPress,1990. IEEE IEEEStandardforSoftwareUnitTesting.Standard10081987,IEEEComputerSociety Press,1986. JACOBSON,Ivaretal.ObjectOrientedSoftwareEngineering:ACaseDrivenApproach. AddisonWesley,1997. JALOTE,Pankaj.Faulttoleranceindistributedsystems.NewJersey:PrenticeHall,1994. KOSCIANSKI,AndrSOARES,MicheldosSantos. QualidadedeSoftware:Aprendaas metodologiasetcnicasmaismodernasparaodesenvolvimentodesoftware.SoPaulo: NovatecEditoraLTDA,2006.

125

LEWIS,WillianE.SoftwareTestingandContinuousQualityImprovement.BocaRaton: Auberbach,2000. LIMA,GladysMachadoPereiraSantosTRAVASSOS,GuilhermeHorta.Testesde IntegraoAplicadosaSoftwareOrientadoaObjetos:HeursticaparaOrdenaodeClasses. TrabalhoapresentadonoIIISimpsioBrasileirodeQualidadedeSoftware,Braslia,2004. Disponvelem:<http://www.sbc.org.br/bibliotecadigital/download.php?paper=250>.Acesso em:28nov.2006. MALDONADO,JosCarlosetal.IntroduoaoTestedeSoftware.2004.Disponvelem: <ftp://ftp.icmc.usp.br/pub/BIBLIOTECA/not_did/ND_65.pdf.zip>.Acessoem:16abr.2007. MARTIN,James.PrincpiosdeAnliseeProjetoBaseadosemObjetos.RiodeJaneiro: EditoraCampus,1994. MARTINS,ElianeVIEIRA,VanessaGindri.TestedeRegresso.Disponvelem:<http:// www.ic.unicamp.br/~eliane/Cursos/SeminarioTestes/Teste_Regressao.ppt>.Acessoem:11 dez.2006. MARTINS,Eliane.TestesdeSoftware:TestesBaseadosnaImplementao(Fluxosde Controle).Disponvelem: <http://www.ic.unicamp.br/~eliane/Cursos/Transparencias/VVTestes/testescxbranca.pdf>. Acessoem:10abr.2007a. MARTINS,Eliane.TestesdeSoftware:TestesBaseadosnaImplementao(Fluxosde Dados).Disponvelem: <http://www.ic.unicamp.br/~eliane/Cursos/Transparencias/VVTestes/testescxbranca2.pdf>. Acessoem:10abr.2007b. MCGREGOR,JohnSYKES,DavidA.APracticalGuidetoTestingObjectOriented Software.NewJersey,AddisonWesley,2001. MYERS,GlenfordJ..Theartofsoftwaretesting.NewYork:JohnWiley&Sons,1979. NATIONALINSTITUTEOFSTANDARTSANDTECHNOLOGY.SoftwareErrorsCost U.S.Economy$59.5BillionAnnually:NISTAssessesTechnicalNeedsofIndustrytoImprove SoftwareTesting.Disponvelem:<http://www.nist.gov/public_affairs/releases/n0210.htm>. Acessoem:29mar.2007. NEVES,Luciane.Aatividadedetesteduranteociclodevidadosoftware.Disponvelem: <http://www.pr.gov.br/batebyte/edicoes/1999/bb88/atividade.htm>.Acessoem:29mar.2007. OBERG,James.WhyTheMarsProbeWentOffCourse.Disponvelem: <http://www.jamesoberg.com/mars/loss.html>.Acessoem:29mar.2007. OLIVEIRA,EricC.M.Java:TestesUnitrioseJUnit.Disponvelem: <http://www.linhadecodigo.com.br/artigos.asp?id_ac=576>Acessoem:23jun.2007a. OLIVEIRA,DanielQuirino.TestescomJUnit.Disponvelem: <http://www.guj.com.br/java.tutorial.artigo.40.1.guj>.Acessoem:10set.2007b.

126

OSISTEMAInternacional deUnidadeseoSatliteClimticoInterplanetrioMarsClimate Orbiter.Disponvelem: <http://www.ambientequalidade.com.br/artigo_satelite_marcelo.asp>.Acessoem:29mar. 2007. PALAVRO,Indiara.TestedeAplicaesOOBaseadoemEstados.TrabalhoApresentadona IIISemanaAcadmicadoCursodePsGraduaoemCinciadaComputaoda UniversidadeFederaldoRioGrandedoSul,portoAlegre,1998.Disponvelem: <http://www.inf.ufrgs.br/pos/SemanaAcademica/Semana98/indiara.html>.Acessoem:13jun. 2007. PFLEEGER,ShariLawrence.EngenhariadeSoftware:TeoriaePrtica.2.ed. SoPaulo: PearsonBrasil,2004. PRESSMAN,RogerS..Engenhariadesoftware.5.ed. SoPaulo:MakronBooks,2002. RAPPS,SandraWEYUKER,ElaineJ.DataFlowAnalysisTechniquesforTestData a Selection.Trabalhoapresentadona6 ConfernciaInternacionaldeEngenhariadeSoftware, Tkio,1982.Disponvelem: <http://portal.acm.org/ft_gateway.cfm?id=807769&type=pdf&coll=GUIDE&dl=GUIDE&CF ID=20728195&CFTOKEN=32796774>.Acessoem:23abr.2007. RUMBAUGH,Jamesetal.ModelagemeProjetosBaseadosemObjetos.RiodeJaneiro: EditoraCampus,1994. SOMMERVILLE,Ian.EngenhariadeSoftware.6.ed.SoPaulo:AddisonWesley,2003. SUN.Lesson:ObjectOrientedProgrammingConcepts.Disponvelem: <http://java.sun.com/docs/books/tutorial/java/concepts/>.Acessoem:20mai.2007. TANNOURI,PatriciaAline.OqueTestabilidade.Disponvelem: <http://www.linhadecodigo.com.br/artigos.asp?id_ac=923>.Acessoem:30mar.2007. TSCHANNERL,HelbertLuizMARTINS,JeffersonCarlos.TestesdeSoftwareAplicados OrientaoaObjetos.Disponvelem: <http://www.pr.gov.br/batebyte/edicoes/2003/bb136/testes.shtml>.Acessoem:08jun.2007. VICENZI,AuriMarceloRizzo.OrientaoaObjeto:Definio,ImplementaoeAnlisede RecursosdeTesteeValidao.2004.Tese(Mestrado) UniversidadedeSoPaulo,So Carlos,2004.Disponvelem:<http://www.teses.usp.br/teses/disponiveis/55/55134/tde 17082004122037/publico/tese.pdf>.Acessoem:28nov.2006. WIKIPEDIA,TheFreeEncyclopedia.Disponvelem:<http://wikipedia.org>.Acessoem:29 mar.2007. WINTER,Mario.ManagingObjectOrientedIntegrationandRegressionTesting.In: EUROSTAR,6,1998,Munique.Trabalhosapresentados... Disponvelem: <http://arxiv.org/ftp/cs/papers/9902/9902008.pdf>.Acessoem:18mai.2007.