CENTRO UNIVERSITRIO EUROAMERICANO UNIEURO CURSO DE PS-GRADUAO LATO SENSU EM ENGENHARIA DE SOFTWARE DISTNCIA

CLEYVISON SOARES SILVA WARLEY DE ARAJO CAMPOS

TESTE DE UNIDADE: PEQUENOS PASSOS QUE GARANTEM A QUALIDADE DO SOFTWARE

Braslia, Setembro/2011.

iii

CLEYVISON SOARES SILVA WARLEY DE ARAJO CAMPOS

TESTE DE UNIDADE: PEQUENOS PASSOS QUE GARANTEM A QUALIDADE DO SOFTWARE

Trabalho de concluso de Curso apresentado como prrequisito parcial para a concluso do curso de Especializao/MBA em Engenharia de Software do Centro Universitrio Euro-Americano Unieuro. Orientadora: Professora Msc. Edna Dias Canedo

Braslia, Setembro/2011.

iv

TESTE DE UNIDADE: PEQUENOS PASSOS QUE GARANTEM A QUALIDADE DO SOFTWARE CLEYVISON SOARES SILVA WARLEY DE ARAJO CAMPOS Aprovada em, ___ / ___ / ____ BANCA EXAMINADORA

Orientadora: Professora Msc.Edna Dias Canedo Centro-Univesitrio Euro-Americano (Braslia DF)

Professor Msc. Milton Padilla Soriano de Mello Centro-Univesitrio Euro-Americano (Braslia DF)

Professor Msc. Cleber Machado Ortiz Centro-Univesitrio Euro-Americano (Braslia DF) CONCEITO FINAL: ___________

DEDICATRIA

Dedico este trabalho a Deus, pois nele busco foras para superar os desafios que a vida impe. A minha famlia, em especial, a meus pais que sempre acreditaram em mim e deram fora para o meu crescimento. A minha namorada e futura esposa Rakel, que sempre esteve ao meu lado emitindo palavras de conforto e incentivo. Ao meu amigo e co-autor deste trabalho Warley de Arajo Campos, que muito se dedicou para sua realizao e sucesso. Cleyvison Soares Silva

Dedico este trabalho primeiramente a Deus, nosso soberano a quem louvo todos os dias, onde busco refgio e foras para vencer todas as minhas lutas. A minha famlia, em especial meus pais que so minha base para tudo em minha vida que sempre estiveram a meu lado me incentivando, mesmo nas horas difceis. Ao meu amigo Cleyvison Soares Silva, pelas horas de dedicao esforos na construo deste projeto. Ao meu amigo Eliezer Spinelli Melo, por ter sanado diversas dvidas no decorrer desse trabalho. A nossa Professora e Orientadora Edna Dias Canedo por ter acreditado em nosso potencial e a todos aqueles que acreditaram nessa conquista. Warley de Arajo Campos

vi

AGRADECIMENTO

Agradecemos a Deus por ter nos dado sabedoria e pacincia para a execuo deste trabalho, nossas famlias que nos viram creditar dias e noites em busca de seu aperfeioamento, nossas namoradas que compartilharam nossos momentos de angstia, aos amigos que nos deram fora e em especial Professora Msc. Edna Dias Canedo, pela orientao e pela pacincia atribuda durante sua execuo, permitindo o sucesso deste trabalho. A estes e a todos os que participaram direta ou indiretamente e que de alguma forma fizeram parte desta longa jornada, contemplando nossas dificuldades. Gostaramos de externar a nossa sincera satisfao, muito obrigado.

vii

O sucesso ir de fracasso em fracasso sem perder entusiasmo. Winston Churchill

viii

RESUMO
Garantir a qualidade de um software ou sistema um objetivo que todos os desenvolvedores e fbricas de software devem buscar. Existem diversas maneiras, tcnicas e mtodos de se verificar e validar um software. Estas podem ser aplicadas em vrias fases de um projeto. Entretanto, j sabido que quanto mais tarde o teste for realizado maior o valor agregado ao seu custo final e maior o tempo gasto para corrigir eventuais problemas, podendo inclusive, atrasar ou inviabilizar a entrega do produto dentro dos prazos e especificaes contratadas com o seu patrocinador ou usurio final. Este trabalho tem por objetivo demonstrar que possvel a realizao testes simples e eficazes, sejam manuais ou automatizados, logo nas fases iniciais de um projeto. Demonstrando que tal procedimento , alm de mais simples, menos dispendioso, fazendo com que se comece a garantir a qualidade do software ainda nos primeiros passos do desenvolvimento. Palavras-Chave: Teste Unitrio, Teste de Unidade, Teste Automatizado, Qualidade de Software.

ix

ABSTRACT
Ensuring the quality of a software or system is a goal that all developers and software factories should seek. There are several ways, techniques and methods to verify and validate software. These can be applied at various stages of a project. However, it is known that the later the test is performed the greater the value added to the final cost and the greater the time spent to correct any problems and may even delay or derail the delivery of the product on time and with contracted specifications your sponsor or end user. This paper aims to demonstrate that it is possible to perform simple and effective tests, whether manual or automated, in the very early stages of a project. Demonstrating that such a procedure is in addition to simpler, less expensive, so if you begin to ensure the quality of the software is in the early stages of development. Keywords: Unit Testing, Automated Testing, Software Quality.

10

SUMRIO INTRODUO..................................................................................................11 1.1 Descrio do Problema.................................................................................12 1.2 Objetivos.......................................................................................................12 1.2.1 Objetivo Geral............................................................................................12 1.2.2 Objetivos Especficos.................................................................................13 1.3 Justificativa...................................................................................................13 1.4 Metodologia..................................................................................................14 1.5 Resultados Esperados....................................................................................14 1.6 Estrutura da Monografia...............................................................................15 2 EMBASAMENTO TERICO.........................................................................16 2.1 Estratgia de Teste.........................................................................................16 3 ESTUDO DE CASO........................................................................................20 3.1 Metodologia do Estudo de Caso...................................................................20 3.2 Introduo ao Estudo de Caso.......................................................................21 3.3 Implementao e Apresentao do sistema...................................................22 4 REALIZAO DOS TESTES........................................................................25 4.1 Testes de Unidade.........................................................................................25 4.1.1 Realizando um Teste de Unidade...............................................................25 4.1.2 Analisando a Classe UsuarioView.java......................................................26 4.1.2.1 Resultados Esperados..............................................................................26 4.1.2.2 Resultados Obtidos.................................................................................26 4.1.3 Testes Unitrios Automatizado..................................................................28 4.1.3.1 Caso de teste 1.........................................................................................29 4.1.3.1.1 Resultados Esperados...........................................................................29 4.1.1.3.2 Resultados Obtidos..............................................................................29 4.1.3.2 Caso de teste 2.........................................................................................32 4.1.3.2.1 Resultados Esperados...........................................................................32 4.1.3.2.2 Resultados Obtidos..............................................................................32 4.1.3.3 Caso de teste 3.........................................................................................36 4.1.3.3.1 Resultados Esperados...........................................................................38 4.1.3.3.2 Resultados Obtidos..............................................................................38 4.2 Resultados e Benefcios Obtidos...................................................................39 CONCLUSO....................................................................................................41 BIBLIOGRAFIA................................................................................................43 APNDICE A Junit.........................................................................................45 ANEXO 1 PLANO DE TESTE.......................................................................48

11

INTRODUO
Com o crescimento exponencial da necessidade do uso da tecnologia e, consequentemente, da utilizao de softwares e sistemas especializados. Tivemos, tambm, o aumento do nmero de desenvolvedores e de fbricas de software. Entretanto, o fato de existirem diversas pessoas ou empresas atuando no desenvolvimento destes produtos, isso por si s, no garantia de qualidade ou tranquilidade para seus patrocinadores ou usurios finais. Em muitos casos, quando o desenvolvedor no se preocupa com a qualidade do produto, este se torna um grande problema. Assim, Qualidade de software um requisito fundamental e determinante quer para o desenvolvedor individual quer para as fbricas. Entretanto, por muitas vezes, devido a vrios fatores e na grande maioria das vezes por questes oramentrias e ou para cumprimento de prazos, alguns desenvolvedores, no valorizam as atividades relacionadas verificao de software, refletindo diretamente em sua qualidade e ocasionando altos ndices de insatisfao por parte do cliente e de retrabalho por parte da equipe. Neste trabalho apresenta-se como qualidade de software pode ser mantida a partir de pequenos testes realizados durante o desenvolvimento do software ou sistema. Executandose o teste de unidade, ou seja, testando a menor unidade do cdigo por vez, conforme sua evoluo, em um processo de desenvolvimento. A execuo desta atividade de verificao do software gera evidncias dos eventuais defeitos existentes, facilitam a correo e permitindo que se tenha como resultado produtos com maior qualidade. Pressman (PRESSMAN, 2006) afirma que O teste oferece efetivamente o ltimo reduto no qual a qualidade pode ser avaliada e mais pragmaticamente erros podem ser descobertos. Mas o teste no deve ser encarado como uma rede de proteo e sabiamente completa: Voc no pode testar a qualidade. Se ela no estiver l antes de voc comear a testar, ela no estar l quando terminar. Segundo Willian, teste uma parte de qualquer esforo responsvel para desenvolver um sistema de software, isso nos faz crer que realizar testes no s muito importante como necessrio. J Kent Beck, acredita que otimismo o risco ocupacional; teste o tratamento, sendo assim no devemos acreditar que um produto concludo em sua totalidade sem defeitos e ainda que ele ir adquirir qualidade, apenas, em sua fase de testes, mas podemos esperar que erros sero corrigidos e a qualidade ser mantida.

12

Diversas so as formas de se testar um produto, estas se iniciam junto com o projeto antes mesmo da existncia de cdigos, at sua entrega ao cliente. Cada uma delas aplicada em uma determinada fase do projeto sempre buscando estabelecer os parmetros de testes e assegurar o produto no apresentou erro, quando aplicado este parmetro. Assim, a execuo de testes medida que o produto vai sendo desenvolvido uma forma de garantirmos que, ao seu trmino, ele seja um produto de qualidade.

1.1 Descrio do Problema

Durante o desenvolvimento de um produto de software, por diversos fatores, a equipe de desenvolvimento pode no dar a devida ateno aos procedimentos de validao e verificao do software. Em alguns casos, esta falta de ateno pode acarretar desde um simples retrabalho, como reescrever um mtodo ou Classe, como pode tambm, inviabilizar a entrega dentro do prazo estabelecido, estouro de oramento e gerar um produto de m qualidade. A no utilizao do processo de verificao, muitas vezes, se d pelo fato de que muitas empresas o entendem apenas como uma atividade a mais, e que pode ser substituda por outros testes, visto que estas organizaes em busca de um processo mais gil e compacto tendem a eliminarem atividades que consideram apenas burocrticas.

1.2 Objetivos

Nesta seo sero mostrados os objetivos Gerais e especficos deste trabalho.

1.2.1 Objetivo Geral

Avaliar o uso dos testes unitrio no Sistema de Locao de Automveis (SisLoCar1)

1

SisLocar um software open-source, disponivel para download em 08 de junho de 2011 no endereo

13

com o objetivo de agregar qualidade ao software.

1.2.2 Objetivos Especficos

Para atender aos objetivos gerais sero realizados teste de unidade nas Classes e mtodos utilizados do sistema. Esses consistem na realizao das seguintes tarefas: (1) garantir que todos os caminhos independentes de um mdulo sejam exercidos ao menos uma vez, (2) exercitar todas as decises lgicas, tanto do lado verdadeiro, quanto do lado falso, (3) executar os ciclos (loops) em seus limites e dentro de seus intervalos operacionais e (4) exercitar estruturas de dados internos para garantir sua validade.

1.3 Justificativa

Para a Engenharia de Software garantir a qualidade de software tem sido um grande desafio. Uma das formas de resolver essa questo realizar a verificao dos produtos gerados anteriormente criao do software. De acordo com Boehm (BOEHM, 1981), problemas encontrados antecipadamente so mais fceis e mais baratos para corrigir, figura 1.1. Figura 1.1 - Custo relativo para corrigir um defeito (BOEHM, 1981).

Portanto, a verificao dos produtos elaborados em cada disciplina do processo de

http://projectkenai.com/projects/sislocar/sources/source/show/trunk?rev=3.

14

desenvolvimento uma prtica que deve ser adotada em todos os projetos. Imbudas no processo de desenvolvimento, as tcnicas de verificao esto relacionadas com os testes de verificao. Reviso, Inspeo, Walkthrough e Peer-Review so as principais tcnicas de verificao aplicadas em projetos. Quando executadas, geram produtos adicionais onde so evidenciadas as no conformidades existentes nos produtos verificados. De forma organizada, dados extrados dos relatrios de aferio tornam-se indicadores para melhoria do processo de desenvolvimento da empresa. A execuo do processo de verificao de extrema importncia, tendo em vista que ela pode ser definida como a primeira parte do processo de teste e prosseguindo de forma paralela ao desenvolvimento. a verificao que fornece a base, para que posteriormente ocorra a validao, que tambm um processo eficaz e indispensvel para um resultado positivo do produto de software, e do projeto como um todo. Face estas afirmativas este trabalho foi desenvolvido para demonstrar de forma prtica, como a verificao pode ajudar os desenvolvedores.

1.4 Metodologia

Na realizao do teste de unidade as Classes sero revisadas em busca de: (1) funes em desuso, (2) variveis repetidas, inacessveis, declaradas fora de escopo, duplicadas e quanto ao seu tipo. Tambm sero verificados os ciclos (loops) nas seguintes condies: (1) teste no limite do ciclo e (2) teste dentro do intervalo vlido do ciclo. Esta fase ser concluda com o exerccio das decises lgicas, tanto do lado verdadeiro quanto do lado falso.

1.5 Resultados Esperados

Ao final deste estudo, espera-se demonstrar como a aplicao dos testes de unidade no processo de software podem contribuir para garantir a qualidade do produto, detectando e corrigindo possveis falhas antes de sua evoluo para a prxima fase de desenvolvimento.

15

1.6 Estrutura da Monografia

Este trabalho est divido em seis captulos. Assim distribudos: O Captulo 1 apresentou: a introduo, seguida o problema a ser solucionado, os objetivos do trabalho, a justificativa para sua elaborao, os itens que sero serem verificados e metodologia aplicada e por fim foram apresentados os resultados esperados. No captulo 2, ser apresentado o referencial terico no qual este trabalho foi baseado. No captulo 3, ser apresentada a Metodologia de Estudo de Caso e o Estudo de Caso propriamente. O Captulo, 4 apresentar as tarefas desenvolvidas neste trabalho e os resultados obtidos em cada uma delas. Por fim, o ltimo captulo destina-se a apresenta a concluso deste estudo

16

CAPTULO 2 2 EMBASAMENTO TERICO

Este captulo apresenta algumas definies encontradas na bibliografia relacionada Engenharia de Software sobre a execuo de teste e qualidade de software.

2.1 Estratgia de Teste

Segundo Pressman (PRESSMAN, 2006), uma estratgia de teste de software integra mtodos de projeto de casos de teste em uma srie bem planejada de passos, que resultam na construo bem-sucedida de um software e sobre testes de unidade explica, cada componente ou unidade executado isoladamente, possibilitando verificar se a informao entra e sai de forma adequada. Shooman (SHOOMAN, 1983) diz, sob vrios aspectos, o teste e um processo independente o nmero de tipos diferentes de teste varia tanto quanto as diferentes abordagens de desenvolvimento. Miller (MILLER, 1977) relaciona a execuo de testes manuteno da garantia da qualidade de software afirmando, a motivao subjacente ao teste de programa afirmar a qualidade do software com mtodos que podem ser aplicados econmica e efetivamente tanto a si temas de grande porte quanto de pequeno porte. O Guia C-BOK (C-BOK, 2007, p 7-1) afirma, muitos testadores no conseguem fazer o teste de forma eficaz e eficiente, porque eles no sabem conceitos bsicos de testes e resume: testes de unidade consiste em testes realizados em um mdulo nico, autnomo ou unidade de cdigo. Para Barti (BARTI, 2002), A qualidade dos processos pode ser medida atravs de
testes aplicados em documentos gerados em cada fase do desenvolvimento. Como cada etapa deve produzir um conjunto de documentos, possvel estabelecer a qualidade nas vrias fases do ciclo de desenvolvimento do software atravs da qualidade dos documentos produzidos. Esses testes so conhecidos como testes de verificao. e Quando as organizaes aplicam inspees e revises

17

tcnicas esto, na maioria das vezes, em busca de erros de padronizao, ou seja, verificando se os documentos e atividade esto sendo feitos dentro de um modelo estabelecido. Apesar de isso ser importante, faz com que o revisor permanea na superfcie do problema..

Myers (MYERS, 2004), nos mostra: uma das vantagens do teste de unidade permitir a introduo de algum paralelismo nos testes, uma vez que as unidades so testadas isoladamente e por isso vrias unidades podem ser testadas ao mesmo tempo. A eficincia dos testes de unidade e mostrada por McDermid (MCDERMIND, 2004), o teste de unidade detecta de 15% a 50% dos defeitos. Pfleeger (PFLEEGER, 2004) demonstra e relaciona a prontificao do componente a execuo dos testes de unidade, um componente pronto significa um componente implementado e com os testes de unidade aprovados, ou seja, componentes individuais funcionando corretamente e atingindo os seus objetivos.. Com relao qualidade, encontramos as seguintes referncias: Segundo Aurlio Ferreira (FERREIRA, 1986), Qualidade - propriedade, atributo ou condio das coisas ou das pessoas capaz de distingui-las das outras e de lhes determinar a natureza. Pressman (PRESSMAN, 1997) diz que: ao se examinar um item baseado em suas caractersticas mensurveis, dois tipos de qualidade podem ser encontrados: qualidade de projeto e qualidade de conformidade. A International Organization for Standardization (ISO), define controle de qualidade como uma a atividade e tcnica operacional que utilizada para satisfazer os requisitos de qualidade (cit. em MCCONNELL, 1994). Segundo Meyrs (MEYRS, 1988) a qualidade do software sofre influncia dos seguintes itens externos a produo: corretude, robustez, extensibilidade, reusabilidade, compatibilidade, eficincia, portabilidade, verificabilidade, integridade e facilidade de uso. Para medir qualidade de software devem-se determinar quais caractersticas medir e como medir. Segundo Sheneiderman (SHENEIDERMAN, 1980) encontramos que Boehm, Brown e Lipow, definem uma rvore de atributos de qualidade de software bem definidos e bem diferenciados, podemos observ-la na figura 1.2. Onde as direes das setas indicam implicaes lgicas. Por exemplo, um programa que fcil de ser mantido deve tambm ser facilmente testado, entendido e modificado.

18

Figura 1.2 rvore de atributos de qualidade de software (BOEHM et al, 1977)

De acordo com Ana Rocha (ROCHA, 2001), um ponto relevante para a conduo efetiva das atividades de verificao o estabelecimento de modelos de erros que captem os erros tpicos, os riscos associados, a frequncia de ocorrncia e outros aspectos, de maneira que a experincia e o conhecimento de desenvolvimento de software de uma equipe ou empresa sejam utilizados para o planejamento das futuras atividades de desenvolvimento. Verificao da qualidade a avaliao contnua da situao de procedimentos, mtodos, condies, produtos, processos e servios, e a anlise dos registros para assegurar que os requisitos da qualidade sero satisfeitos (MILLS, 1994). Carlos Bizzoto (BIZZOTO, 1992) diz a qualidade definida como a totalidade de requisitos e caractersticas de um produto ou servio que estabelecem a sua capacidade de satisfazer necessidades implcitas e explcitas. A ISO 9000-3 uma guia de aplicao da ISO 9001 (NBR 19001) para o desenvolvimento, fornecimento e manuteno de software. A Norma ISO 9001 faz parte da srie de normas ISO 9000, voltadas para a gesto e garantia da qualidade (BENTO, 2000). O Institute of Electrical and Electronic Engineers IEEE divide as atividades de teste em trs fazes e oito atividades bsicas (IEEE, 1986), quais sejam: Execuo do planejamento de teste; o Plano geral de abordagem, recursos e cronograma; o Determinao das caractersticas a serem testadas; e

19

o Detalhamento do plano geral de teste. Obter o conjunto de testes; o Projetar os casos de teste; e o Implementar o plano detalhado e o projeto. Medir a unidade de teste; o Executar os procedimentos de teste; o Checar resultados; o Avaliar o teste de esforo e unidade A figura 1.3 apresenta um diagrama desta diviso. Figura 1.3 - Fluxo de dados da fase de teste de unidade de software (IEEE,
1986)

20

CAPTULO 3

3 ESTUDO DE CASO

Neste captulo apresentada a metodologia do estudo de caso, a descrio dos passos e embasamentos tericos relacionados ao cumprimento do objetivo deste trabalho.

3.1 Metodologia do Estudo de Caso

O desenvolvimento deste trabalho foi baseado em experincias nas quais foram aplicadas o processo de teste, onde de acordo com estudiosos da rea esta parte do processo de desenvolvimento de software garante a qualidade e o sucesso do produto. A partir de pesquisas notamos que nem sempre dada a devida ateno para o processo de validao O desenvolvimento deste trabalho ocorreu em vrias etapas. Inicialmente, foram abordadas questes de qualidade nas quais implicam as vantagens de teste, logo em seguida a partir da consulta a referncias bibliogrficas, realizou-se um aprofundamento especfico, sendo neste momento executados os testes de unidade como fator de garantia para a qualidade do produto de software. Assim, apresentaremos as tcnicas de teste de unidade utilizadas e desenvolvidas para este trabalho. Dentre as tcnicas usadas na automao de teste, destaca-se a Execuo Simblica2 (MCDERMID, 2004), que consiste no processo de atribuir expresses a variveis de um programa enquanto um caminho seguido atravs da estrutura do cdigo. Segundo M. J. Harrold, (HARROLD, 2000) o processo de teste executado para dar suporte garantia de qualidade do produto de software. Conforme Myers (MYERS, 1979), a atividade de teste o processo de executar um programa com a inteno de encontrar erros, sendo, de acordo com Pressman (PRESSMAN, 2006), um elemento crtico da garantia de
2

Execuo Simblica - uma tcnica esttica onde se examina o programa sem execut-lo.

21

qualidade de software e que representa a reviso final da especificao, projeto e gerao de cdigo. Para a aplicao das tcnicas de testes tomou-se como ponto inicial o estudo de caso baseado em um sistema de gerenciamento de locadoras de veculos (SisLoCar). Conforme R. Yin (YIN, 1994), o estudo de caso um questionamento emprico que investiga um fenmeno contemporneo dentro de um contexto de vida real, quando as fronteiras entre fenmeno e contexto no so claramente evidentes e nos quais mltiplas fontes de evidncia so utilizadas. Ainda segundo R. Yin (YIN, 1994), o mtodo do estudo de caso o mais adequado quando se busca o entendimento de uma situao, ou ainda, quando o fenmeno estudado ainda est ocorrendo. Com base nesses fundamentos, para atingir o objetivo deste trabalho em relao ao estudo de caso, a seguinte metodologia foi seguida: Estudo de metodologia de teste; Estudo do impacto do processo de teste no que tange a qualidade de software; Abordagem dos teste de unidade em um determinado cenrio Implementao de um sistema de software; Avaliao da parte formal do cdigo; Escolha da ferramenta JUnit para automatizao dos testes estruturais; Descrio do framework JUnit e suas particularidades, alm de apresentar suas qualidades; Escolha de Classes do sistema para serem geradas Classes de teste, a ferramenta framework; e Localizao e correo de erros existentes no sistema. A escolha para utilizao do framework JUnit partiu do fato desta ferramenta conter mtodos definidos para comparaes de resultados esperados com os resultados obtidos da aplicao que est sendo envolvida no teste.

3.2 Introduo ao Estudo de Caso

22

O cenrio de aplicao dos mtodos de Teste de Unidade consiste em um sistema em um gerencial, desenvolvido para empresas do ramo de locao de veculos, intitulado SisLoCar3. Em sua verso para download no foram disponibilizadas as Classes de testes, objeto essencial para a garantia de sua qualidade. Assim, durante a execuo deste trabalho, visando demonstrar a real importncia e eficcia das mesmas, algumas destas Classes sero testadas e os resultados sero apresentados. O SisLoCar foi concebido com a finalidade de automatizar a gerncia das atividades existentes no ambiente, permitindo o controle computadorizado todo o negcio. Os testes de unidade sero aplicados com foco na parte estrutural do sistema, buscando possveis falhas que, por ventura, no tenham sido identificadas inicialmente. Concomitantemente a este processo, quando localizadas falhas ou simplesmente para melhorar o desempenho, sero propostas solues, que ao serem aplicadas podero proporcionar um sistema com a maior qualidade. Para efetuar o estudo de caso, foram analisadas as funcionalidades que o sistema deve atender. O mtodo aplicado a este estudo consistiu em dividir o teste em duas partes uma avaliando a parte formal do cdigo e outra a parte estrutural de execuo. A escolha deste sistema adveio do fato da no disponibilizao de suas Classes de testes, tornando-o assim um cenrio propcio e passvel de erros. Entretanto, tais tcnicas podem ser aplicadas em qualquer outro sistema.

3.3 Implementao e Apresentao do sistema

Para aplicao e adequao deste sistema a este estudo de caso, tornado possvel a execuo de testes de unidade. Foram necessrias algumas modificaes, tais modificaes permitiram a continuidade deste trabalho e possivelmente tornaram o sistema mais flexvel, pois o propsito principal foi fornecer ao mesmo uma contribuio que o tornasse mais usual, e ao mesmo tempo garantisse sua qualidade.
3

Este sistema pode ser encontrado em http://projectkenai.com e possui licena GPL.

23

Uma das alteraes realizadas consistiu em modificar o SGBD4. Este modificao introduziu a necessidade de mudanas em diversas partes do cdigo do sistema. O SisLoCar apresenta algumas funcionalidades. Estas advm da necessidade de torn-lo um sistema operacional e de fcil utilizao, tornado-o, assim, totalmente vivel e aplicvel a organizaes do ramo de locao veicular. Algumas destas funcionalidades so apresentadas nas figuras 3.1 e 3.2. Figura 3.1 Tela de login do SisLoCar (AURLIO, 2009)

Figura 3.2 Tela Principal do SisLoCar (AURLIO, 2009)

Na tela inicial possvel gerenciar os seguintes componentes: Clientes/Fornecedores; Cidades; Check-Lists; Contas; Contas Contbeis; Funcionrios;
4

O sistema foi concebido para utilizar o SGBD firebird, optou-se por implementar o SGBD MySQL.

24

Marcas; Usurios; e Veculos. Estas funcionalidades possibilitam a manuteno e utilizao do sistema. A existncia destas constitui um sistema de fcil usabilidade e com um propsito que atende as necessidades de profissionais do ramo.

25

CAPTULO 4

4 REALIZAO DOS TESTES

Este Captulo apresenta as aes executadas no desenvolvimento deste trabalho.

4.1 Testes de Unidade

O Captulo 2 deste trabalho apresentou diversas definies para os testes de unidade Cabe agora apresentarmos como, na prtica, eles so realizados.

4.1.1 Realizando um Teste de Unidade

Antes de iniciarmos um teste, devemos saber o que a Classe que iremos testar deve executar, a partir da abstrair possveis erros, criar cenrios de uso e estabelecer a forma como vamos realiz-lo, que pode ser de forma manual ou automatizada. Como sabido o teste de unidade visa garantir a qualidade do software e aprimorar o seu desempenho deste o incio do projeto. Para exemplificar esta ao, realizou-se a inspeo do cdigo. Esta inspeo teve como objetivo localizar, erros de lgica, declarao desnecessrias, funes em desuso (deprecated), pois estes so erros que frequentemente comprometem a qualidade do software, pois podem resultar sadas equivocadas e criar dificuldades de manuteno no software. Neste contexto, as seguintes Classes foram, de forma aleatria, verificadas:
Classe de UsuarioView; Classe de Conexo;

26

Classe de Usurio; e Classe de Marca.

4.1.2 Analisando a Classe UsuarioView.java

Esta Classe responsvel pelas vises do usurio.

4.1.2.1 Resultados Esperados

Localizar erros de lgica ou digitao, importaes desnecessrias e mtodos em desuso (deprecated).

4.1.2.2 Resultados Obtidos

Foram localizados pontos passveis de alterao. No incio da Classe, localizamos a utilizao de uma biblioteca desnecessria, o que pode aumentar o tempo de carregamento, pois, as funcionalidades desta biblioteca no sero necessrias neste momento. A figura 4.1 mostra como foram declaradas as importaes, a figura 4.2 mostra como a Classe ficou aps a correo. Figura 4.1 Importao desnecessria de bibliotecas (SILVA, 2011)

27

Figura 4.2 Importao desnecessria de bibliotecas (SILVA, 2011)

Dando continuidade aos testes, na mesma Classe, foi possvel encontrar um mtodo em desuso getText (), que estava atuando em um campo de texto para receber a senha do usurio. Neste caso, a continuidade deste mtodo no cdigo, poderia afetar a sua segurana, pois, tratava-se de um campo de captura de senhas e uma nova funo para este caso j fora desenvolvida. Assim, efetuou-se a alterao sugerida pela mantenedora da linguagem. As figuras 4.3 e 4.4 demonstram este trecho da Classe. Figura 4.3 Localizao de funo em desuso (SILVA, 2011)

Figura 4.4 Substituio de funo em desuso (SILVA, 2011)

28

Para finalizar esta etapa de testes unitrios, que consistiu apenas na leitura do cdigo, buscou-se erros de lgica e este no foram encontrados. Como sugesto de melhoria, orientou-se a utilizao dos parmetros utilizados pelo javadoc5, visto que apenas o parmetro referente ao autor foi includo, dificultando a interpretao da Classe sem a leitura do mesmo por completo e impossibilitando a gerao automtica da documentao pelos diversos frameworks que utilizam este recuso.

4.1.3 Testes Unitrios Automatizado

Na medida em que o nmero de testes aumenta, torna-se vivel a automatizao dos mesmos. Para tanto existem disponveis diversas ferramentas que proporcionam a automatizao dos testes. Neste trabalho optou-se pela utilizao da ferramenta chamada JUnit. O Apndice A, apresenta uma breve explicao sobre esta ferramenta. Quando nos referimos aos testes unitrios automatizado, o foco no parte do comportamento das dependncias da Classe e sim de como a esta se comporta diante das possveis respostas das dependncias, ou seja, se est realizando o esperado. Com isso, ao se automatizar o teste unitrio, ocorre simulao da execuo de um determinado mtodo da Classe a ser efetivamente testada. Isto realizado passando-se parmetros ao referente mtodo testado definindo tambm o resultados esperado. Para que o teste seja efetivo e vlido, o resultado obtido tem que ser igual ao resultado esperado no qual foi definido. O processo de automatizao exige um tempo considervel, alm disso, deve se avaliar o que deve ser includo na automatizao, pois alguns aspectos podem no ser relevantes. Quando automatizamos o teste, no se pode ter a falsa expectativa de que o esforo humano ser substitudo, pois o testador humano que tem que cri-los, alm de conferi-los para verificar se funcionam satisfatoriamente. Quando se optamos pela automatizao significa que haver uma reexecuo com rapidez dos testes em inmeras vezes da mesma forma, permitindo que bugs sejam encontrados mais cedo implicando na eficcia e na qualidade do produto a ser entregue.
5

javadoc uma ferramenta desenvolvida para facilitar a documentao das Classes, os diversos frameworks utilizam-se destes parmetros para gera de forma automtica a documentao da Classe.

29

Muitas tarefas, alm de exigirem tempo, so desmotivadoras e repetitivas. Ao automatizarmos um teste, estamos assegurando que essas tarefas sero repetidas inmeras vezes na mesma ordem dando mais qualidade e consistncia ao teste. Com o objetivo de testar Classes do sistema SisLoCar e avaliar suas funcionalidades e qualidade foram automatizados alguns testes, estes so apresentados a seguir.

4.1.3.1 Caso de teste 1

Este caso de teste tem o objetivo de verificar se o funcionamento da Classe FBConnection, est de acordo com o previsto e necessrio. Esta Classe responsvel pela conexo do sistema ao SGBD. A Classe FBConnection. O teste consiste em oferecer os parmetros necessrios a para a conexo no SGBD. A figura 8, apresenta a Classe de teste gerada para esta finalidade, onde o objetivo testar o instanciamento, o estabelecimento e o encerramento da conexo.

4.1.3.1.1 Resultados Esperados

Espera-se que a Classe seja capaz de executar as trs etapas para qual foi desenvolvida. Em caso de erros ou falhas localizar os pontos que carecem de correo. Neste caso aps a correo a Classe deve efetivamente desenvolver sua tarefa.

4.1.1.3.2 Resultados Obtidos

Aps a implementao da Classe de testes figura 4.5 e a execuo do framework

Junit, detectou-se que a Classe no foi capaz de estabelecer a conexo com o BD, figura 4.6.

Desta forma todo o cdigo foi analisado. Aps a analise o ponto causador da falha foi localizado e verificou-se que a falha era devido a erro na configurao da porta de acesso ao BD. corrigido, figuras 4.7 e 4.8.

30

Executados novos testes a Classe desempenhou sua funo sem apresentar novos erros ou falhas, figura 4.9. Figura 4.5 Classe de Teste (CAMPOS, 2011)
package sislocar.Connection; import static org.junit.Assert.assertNotNull; import java.sql.Connection; import org.junit.After; import org.junit.AfterClass; import org.junit.Before; import org.junit.BeforeClass; import org.junit.Test; /** * * @author war */ public class FBConnectionTest { public FBConnectionTest() { } @BeforeClass public static void setUpClass() throws Exception { } @AfterClass public static void tearDownClass() throws Exception { } @Before public void setUp() { } @After public void tearDown() { } /** * Test of getConnection method, of class FBConnection. */ @Test public void testGetConnection() throws Exception { FBConnection instance = new FBConnection(); Connection result = instance.getConnection(); assertNotNull(result); } /** * Test of closeConnection method, of class FBConnection. */ @Test public void testCloseConnection() throws Exception { FBConnection instance = new FBConnection(); instance.closeConnection(); assertNotNull(instance); } /** * Test of getInstance method, of class FBConnection. */ @Test

31

public void testGetInstance() throws Exception { FBConnection result = FBConnection.getInstance(); assertNotNull(result) ; } }

Figura 4.6 Resultado teste Classe FBConnection (CAMPOS, 2011)

Figura 4.7 Localizao do erro (CAMPOS, 2011)

Figura 4.8 Correo do erro (CAMPOS, 2011)

Figura 4.9 Resultado aps correo (CAMPOS, 2011)

32

4.1.3.2 Caso de teste 2

A prxima Classe a ser testada refere-se Classe Usurio, o objetivo testar se o cadastro consulta, atualizao e excluso de usurio ocorrem de forma esperada, tal teste importante, pois o sistema pode ter sido implementado com rotinas inconsistentes, fazendo com que, em algum momento essas funcionalidades possam falhar.

4.1.3.2.1 Resultados Esperados

Espera-se que a Classe esteja realizando o cadastramento, a autenticao, a incluso, realizando consultas, atualizaes e excluso de um usurio. Em caso de erro, aps os testes e anlise do cdigo, apontar o local que necessita de correo e em caso de correo que os novos testes no apresentem novos erros ou falhas.

4.1.3.2.2 Resultados Obtidos

Ao executar a Classe de testes, figura 4.10, observou-se que a Classe no estava executando todas as suas funcionalidades, quebrando o teste, figura 4.11. Exigindo assim a

33

anlise e correo do cdigo. Figura 4.10 Classe de teste (CAMPOS, 2011)

package sislocar.BEANS; import static org.junit.Assert.*; import java.util.List; import org.junit.Assert; import org.junit.Before; import org.junit.Test; import sislocar.FACADE.UsuarioFacade; import sislocar.FACADE.UsuarioFacadeImpl; /** * * @author warley */ public class TestarUsuario { private static Usuario USUARIO_TESTE = new Usuario(); UsuarioFacade usuarioService; @Before public void runBeforeEveryTest() { usuarioService = new UsuarioFacadeImpl(); } @Test public void testeCadastra() { USUARIO_TESTE.setIdUsuario(1); USUARIO_TESTE.setApelido("user"); USUARIO_TESTE.setSenha("123"); usuarioService.salva(USUARIO_TESTE); } @Test public void testarAutenticacao(){ Usuario cadastrado; cadastrado = usuarioService.autentica(USUARIO_TESTE.getApelido(), USUARIO_TESTE.getSenha()); Assert.assertEquals(USUARIO_TESTE.getIdUsuario(),cadastrado.getIdUsuario()); } @Test public void testeProcura() { Usuario cadastrado; cadastrado = usuarioService.procura(USUARIO_TESTE.getIdUsuario()); assertEquals(USUARIO_TESTE.getIdUsuario(), cadastrado.getIdUsuario()); assertEquals(USUARIO_TESTE.getApelido(), cadastrado.getApelido()); assertEquals("user", cadastrado.getApelido()); } @Test public void testePesquisaLista() { List<Usuario> cadastrado; cadastrado = usuarioService.lista(); assertTrue(USUARIO_TESTE.getApelido(), cadastrado.containsAll(cadastrado)); } @Test public void testeAtualiza() { Usuario buscadoParaAtualizacao;

34

Usuario buscadoAposAtualizacao; buscadoParaAtualizacao = usuarioService.procura(USUARIO_TESTE.getIdUsuario()); buscadoParaAtualizacao.setApelido("apelido modificado"); buscadoParaAtualizacao.setSenha("senha modificada"); usuarioService.atualiza(buscadoParaAtualizacao); buscadoAposAtualizacao = usuarioService.procura(USUARIO_TESTE.getIdUsuario()); assertEquals(buscadoParaAtualizacao.getIdUsuario(), buscadoAposAtualizacao.getIdUsuario()); } @Test public void testeRemover() { Usuario excluir; excluir = usuarioService.procura(USUARIO_TESTE.getIdUsuario()); usuarioService.remove(excluir); assertNull(usuarioService.procura(USUARIO_TESTE.getIdUsuario())); } }

Figura 4.11 Execuo do teste (CAMPOS, 2011)

Realizada a anlise constatou-se que um usurio vinculado a um funcionrio, e o acesso ao campo usurio na base de dados estava sendo realizando de maneira errada, figura 4.12 e figura 4.13 apresentam o erro.

Figura 4.12 Apresentao do cdigo (CAMPOS, 2011)

Figura 4.13 Apresentao do erro (CAMPOS, 2011)

35

Detectado e corrigido o primeiro erro, figura 4.14, nova rodada de teste foi executada e como se pode observar um novo erro localizado, figura 4.15. Desta vez o framework alerta sobre a possvel localizao do erro e nova anlise do cdigo realizada, figura 4.16, localizado o erro apontado pelo framework, o cdigo corrigido, figura 4.17, e nova bateria de teste realizada e obtemos uma Classe livre de erros ou falhas, figura 4.18.

Figura 4.14 Correo do erro (CAMPOS, 2011)

Figura 4.15 Reexecuo do teste (CAMPOS, 2011)

Figura 4.16 Localizao do erro (CAMPOS, 2011)

Figura 4.17 Correo do erro na Classe de teste (CAMPOS, 2011)

36

Figura 4.18 Reexecuo do teste (CAMPOS, 2011)

4.1.3.3 Caso de teste 3

O prximo teste utiliza a Classe Marca responsvel pelo cadastro de Marca de veculos e tem a funo de cadastrar, consultar, atualizar e excluir uma determinada marca de veculo. O teste visa confirmar que todas estas tarefas esto sendo executadas de forma correta. Apesar de sua semelhana com o teste realizado no item 3.1.3.2, para este devemos nos atentar que uma marca pode esta vinculada ao cadastro de veculo, e este pode sofrer mudanas.

37

A Classe de teste implementada definida um conjunto mnimo de operaes que devem ser testadas, a figura 4.19 apresenta a Classe de teste gerada. Figura 4.19 Classe de teste (CAMPOS, 2011)
package sislocar.BEANS; import static org.junit.Assert.assertEquals; import static org.junit.Assert.assertNull; import static org.junit.Assert.assertTrue; import java.util.List; import org.junit.Before; import org.junit.Test; import sislocar.FACADE.MarcaFacade; import sislocar.FACADE.MarcaFacadeImpl; /** * * @author warley */ public class TestarMarca { private static Marca MARCA_TESTE = new Marca(); MarcaFacade marcaService; @Before public void runBeforeEveryTest() { marcaService = new MarcaFacadeImpl(); } @Test public void testeCadastra() { MARCA_TESTE.setIdMarca(1); MARCA_TESTE.setNome("J3"); marcaService.salva(MARCA_TESTE); } @Test public void testeProcura() { Marca cadastrada; cadastrada = marcaService.procura(MARCA_TESTE.getIdMarca()); assertEquals(MARCA_TESTE.getIdMarca(), cadastrada.getIdMarca()); assertEquals(MARCA_TESTE.getNome(), cadastrada.getNome()); } @Test public void testePesquisaLista() { List<Marca> cadastrada; cadastrada = marcaService.lista(); assertTrue(MARCA_TESTE.getNome(), cadastrada.containsAll(cadastrada)); } @Test public void testeAtualiza() { Marca buscadoParaAtualizacao; Marca buscadoAposAtualizacao; buscadoParaAtualizacao = marcaService.procura(MARCA_TESTE.getIdMarca()); buscadoParaAtualizacao.setNome("marca modificada"); buscadoParaAtualizacao.setIdMarca(1); marcaService.atualiza(buscadoParaAtualizacao); buscadoAposAtualizacao = marcaService.procura(MARCA_TESTE.getIdMarca()); assertEquals(buscadoParaAtualizacao.getIdMarca(), buscadoAposAtualizacao.getIdMarca()); assertEquals("marca modificada",buscadoAposAtualizacao.getNome());

38

} @Test public void testeRemover() { Marca excluir; excluir = marcaService.procura(MARCA_TESTE.getIdMarca()); marcaService.remove(excluir); assertNull(marcaService.procura(MARCA_TESTE.getIdMarca())); } }

4.1.3.3.1 Resultados Esperados

Espera-se que a Classe esteja realizando o cadastramento, a incluso, realizando consultas, atualizaes e excluso de uma marca de veculos. Em caso de erro, aps os testes e anlise do cdigo, apontar o local que carece de correo e em caso de correo que os novos testes no apresentem novos erros ou falhas.

4.1.3.3.2 Resultados Obtidos

Aps a execuo do teste pode-se observar que a Classe executou as suas funcionalidades sem erro ou falhas, assim ela pode ser considerada sem estes, figura 4.20.

Figura 4.20 Execuo do teste (CAMPOS, 2011)

39

4.2 Resultados e Benefcios Obtidos

Atravs dos testes pode-se observar a identificao de alguns erros. Atravs desta identificao foi possvel realizar uma a anlise mais especfica do cdigo para localiz-los e corrigi-los com sucesso. Fica evidente que o teste de unidade capaz de identificar erros e possivelmente no se limita apenas ao que foi exemplificado, pois tais tcnicas vo alm do aqui exposto permitindo assim, sua aplicao e resultados satisfatrios em qualquer sistema, seja-o de grande ou de pequeno porte. No caso de teste 1, podemos observar que o teste de unidade tambm, uma tcnica que mantm a formalidade do cdigo. Pode-se observar, que ao se efetuar a anlise, foi constatada a existncia de um trecho que no estava sendo usado, isso ocorre, na maioria das vezes durante as alteraes ou melhoramentos do cdigo, tais trechos so conhecidos como lixo de cdigo, uma vez aplicada tcnica de teste de unidade, fica fcil e notvel a sua eficincia e importncia na entrega de cdigos limpos, enxutos e eficazes. Com relao aplicao de testes automatizados, foram identificados erros que somente seriam percebidos em tempo de execuo e poderiam tomar mais tempo de anlise e correo caso fossem realizados manualmente. A princpio a localizao deste tipo erro, de forma manual, pode parecer simples, entretanto, muitas vezes, elas consomem um tempo considervel de trabalho e com o auxilio do framework a localizao se torna mais rpida e precisa. A automatizao tem como objetivo oferecer maior praticidade na execuo de testes, j que, uma vez implementado e executado o mesmo pode ser repetido inmeras vezes, atingindo desde as interfaces at as camadas de negcio. Atravs dos exemplos pode-se perceber que a permanncia de erros mitigada e ajuda a garantir que o cdigo composto apenas do que est sendo realmente usado. Outro fator de extrema importncia a reduo de tempo para identificao de impactos em caso de mudanas, pois com o uso de tal tcnica todo o cdigo percorrido, todos os loops, limites e operaes so testados, assim como, as dependncias destas tarefas.

40

Desta forma, atravs da observao dos testes, pode-se verificar a aplicabilidade e a qualidade que os testes de unidade agregam ao produto, tornando notvel a possibilidade de entregas de produtos com qualidade, ganho de tempo e reduo de custos relacionados a retrabalhos.

41

CONCLUSO

Durante o desenvolvimento deste trabalho percebeu-se que na construo, alterao e testes de qualquer componente de um sistema, erros ou falhas podem ocorrer, impedindo sua execuo de forma correta. Percebeu-se, tambm, que a aplicao das diversas formas de teste unitrios existentes, nas menores partes do sistema as Classes pode contribuir para que isso seja evitado, assim em ressonncia com autores renomados como Pressman (2006), Barti (2002), Shooman (1983) entre outros, observou-se que uma boa prtica a execuo destas tarefas. De acordo com as metodologias aplicadas, pode-se dizer que conceito de Teste de Unidade pode ser aplicado amplamente em metodologias geis, pois pode reduzir o tempo gasto no futuro com os testes, visto que cada unidade entregue livre de erros ou falhas, liberando a equipe para testes mais complexos. Nos estudos de caso observou-se que o desenvolvimento de testes para a verificao e comprovao da inexistncia de erros ou falhas nas Classes do sistema no demanda grande tempo contrariando o mito de que testar demorado e at mesmo desnecessrio. A execuo destes testes, conforme observado na execuo deste trabalho garante a minimizao de trabalhos futuros, quando houver mudanas no sistema. Ainda de acordo com observaes realizadas, pode-se concluir que necessria grande ateno ao se modificar um sistema, exemplo disso quando fora realizada a mudana do SGBD, todas as Classes, variveis e parmetros relacionados a esta ferramenta necessitam de reviso e alguma de correes. Com relao automatizao dos testes, conclui-se que uma alternativa de grande utilidade, principalmente em casos onde os testes devam ser repetidos por inmeras vezes. Isso faz com que a equipe ganhe tempo e a tarefa de testar se torne menos cansativa e repetitiva. Ainda relacionado a esta automatizao, outro ponto chave a certeza de que as Classes escritas para tal funo estejam realmente livres de erros ou falhas, pois se verificou que em caso de erro na Classe de teste a ferramenta utilizada pode retornar um falso positivo o que ao invs de auxiliar pode prejudicar o trabalho, demandando tempo em verificaes desnecessrias do cdigo.

42

A implementao de um cdigo limpo outro ponto que se deve observar em um cdigo quando mesmo verificado e certo que apenas com a experincia, possvel a obteno de cdigo limpos e por isso que devemos dar uma ateno a este ponto durante os testes ou verificaes. Um cdigo limpo pode proporcionar melhor desempenho e maior facilidade de manuteno que outro com muito lixo. Tambm se observou que o real entendimento da funcionalidade do sistema com um todo e de suas Classes especificamente, contribuem, sobremaneira para a realizao dos testes, afinal deve-se sempre se ter em mente qual o resultado esperado para um teste e isso s se torna vivel e alcanvel com este entendimento e conhecimento do sistema. Por fim, teste de unidade no gera retrabalho, no eleva o custo e reduz a necessidade de elevao do fator tempo. fato que o teste de unidade tem por objetivo facilitar o desenvolvimento e garantir a qualidade do software e seu valor agregado, conforme observado compensado ao final do projeto.

43

BIBLIOGRAFIA

Pressman, Roger S., Engenharia de Software, 6. ed. McGraw-Hill, 2006. Pressman, Roger S., Software Engineering: A Practitioners Approach, quarta edio, McGrawHill, 1997. Shooman, M. L., software Engineering, McGraw-Hill, 1983. MIller, E., The Philosophy of Testing, (cit em PRESSMAN, 2006). Barti. Alexandre, Garantia da Qualidade de Software. Campus. 2002. C-BOK - CSQA Common Body of Knowledge, Verso 6.2,WorldWide, 2007. NBR ISO/IEC 12119, Tecnologia de informao - Pacotes de software - Teste e requisitos de qualidade, ABNT, 1998. Martins, Jos Carlos Cordeiro, Tcnicas Para Gerenciamento de Projetos de Software, Brasport,2007. PFLEEGER, S.L., Engenharia de Software Teoria e Prtica, 2 edio, Prentice Hall, So Paulo, Brasil, 2004. McCONNELL, S., Code Complete, 2 Edio, Microsoft Press, Washington, Estados Unidos, 2004. MYERS, G., The Art of Software Testing, 2 Edio, John Wiley & Sons, Hoboken, New Jersey, Estados Unidos, 2004. Ferreira, Aurlio B. H., Novo Dicionrio da Lngua Portuguesa, editora Nova Fronteira, 1986. John A. McDermid, Software Engineers Reference Book, Butterworth-Heinemann, 1994. Meyer, B., Object-oriented Software Construction, Prentice-Hall, 1988. Shneiderman, B., Software Psychology: Human Factors in Computer and Information Systems, Winthrop Publishers, 1980. UNIVERSIDADE FEDERAL DE PERNANBUCO, Cassiane de Ftima dos Santos Bueno e Gustavo Bueno Campelo, Qualidade de Software Recife, s.d. Disponvel em: <http://www.cin.ufpe.br/~mrsj/Qualidade/Qualidade%20de%20Software.pdf> acesso em: 08 jun 2011 s 22:30h.

44

BIZZOTO, Carlos E. Negro. Influncia da utilizao de metodologia de desenvolvimento sobre a qualidade do software: um enfoque quantitativo. 1992. 139 f. Dissertao (Mestrado em Engenharia da Produo) Departamento de Engenharia de Produo e Sistemas, Universidade Federal de Santa Catarina, Florianpolis. MILLS, A. Charles. A auditoria da qualidade: uma ferramenta para a avaliao constante e sistemtica da manuteno da qualidade. So Paulo: Makron Books, 1994. BENTO, S. Deisy. Software de apoio ao processo de aquisio segundo normas de qualidade. 2000. ROCHA, Ana R. Cavalcanti da; MALDONADO, C. Jos; WEBER C. Kival. Qualidade de software: teoria e prtica. So Paulo: Prentice hall, 2001. YIN, R. Case study research: design and methods. Londres: Sage Publications, 1994. Harrold, M. J., Testing: A Roadmap, In 22th International Conference on Software Engineering Future of SE Track, 61-72, June 2000. Myers, G., The Art of Software Testing, John Wiley & Sons, New York, 1979. IEEE, IEEE Standard for Software Unit Testing. Standard 10081987, IEEE Computer Society Press, 1986.

45

APNDICE A Junit
O JUnit foi criado por Eric Gamma e Kent Beck como premissa um framework opensource, que fornece suporte na realizao de testes automatizados na programao Java. Umas das qualidades desse framework a sua facilitao perante a criao de cdigo para a automao de testes unitrios com apresentao dos resultados. Ele executa a verificao de cada mtodo de uma Classe, com o objetivo de inspecionar se os mtodos funcionam da forma esperada, exibindo possveis erros ou falhas podendo ser utilizado tanto para a execuo de baterias de testes como para extenso. Algumas vantagens exclusivas dos framework JUnit: JUnit orientado a objetos e livre. Permite a criao rpida de cdigo de teste possibilitando um aumento na qualidade do desenvolvimento e teste; Uma vez escritos, os testes so executados rapidamente sem que, para isso, seja interrompido o processo de desenvolvimento; JUnit checa os resultados dos testes e fornece uma resposta imediata; Na figura abaixo representa a arquitetura do framework Junit. Figura 1 Estrutura do JUnit (FOWLER, 2004)

Classe TestCase:

46

command Permite encapsular um pedido (de teste) como objeto e fornece um mtodo run(). run() Cria um contexto (mtodo setUp); em seguida executa o cdigo usando um contexto e verifica o resultado (mtodo runTest); e por fim, limpa o contexto (mtodo tearDown). setUp() Mtodo chamado antes de cada mtodo, pode ser utilizado para abri uma conexo de banco de dados. tearDown() Mtodo chamado depois de cada mtodo de teste, usado para desfazer o que setUp() fez, por exemplo fechar uma conexo de banco de dados. runTest() Mtodo responsvel por controlar a execuo de um teste particular. Classe TestSuite: Com esta Classe, o desenvolvedor executa um nico teste com vrios mtodos de testes e registra os resultados num TestResult. composite O padro (pattern) permite tratar objetos individuais e composies de objetos de forma uniforme. Este padro requer os seguintes participantes: addTest() Mtodo responsvel em adicionar um novo teste a rotina. Procedimento de Implementao do JUnit Mais adiante em nosso estudo de caso teremos Classes especificas a serem testadas, mas podemos exemplificar de uma forma geral, para que seja notada algumas caractersticas de sua utilizao. Exemplo de como pode-se codificar uma Classe de teste em Java, para se efetuar teste de unidade: O primeiro procedimento efetuar a criao de uma Classe que estenda o junit.framework.TesteCase, sendo o procedimento para cada Classe que ser testada. Import.junit.framework Class.MinhaClasseTest.extends.TestCase{...} O prximo procedimento definir para cada mtodo a ser testado, um mtodo public void test() no test case MinhaClasse: public int Divisao(Object o...) {} MinhaClasse Test: Public void testDivisao()

47

Depois de efetuada a implementao de forma correta das respectivas Classes de teste, estendendo as suas Classes a serem testada, pode se executar o JUnit. Analisando resultado gerado pelo JUnit A identificao do resultado dos teste no JUnit simples de serem identificadas, pois o mesmo podem ser executados em modo grfico. Uma vez executados em modo grfico o sistema pode emitir os seguintes resultado para os mtodos testados: Faixa de cor Verde: corresponde a sucesso; Faixa de cor Roxa: corresponde a falha; Faixa de cor Vermelha: corresponde a Exceo. Figura 02 Possveis resultados na execuo dos testes ( FOWLER, 2004)

Qualquer Classe que contenha testes deve ser um subClasse da Classe TestCase do framewoek de testes. Texto retirado de: Fowler, Martin: Refatorao- aperfeioando o projeto do cdigo existente/Martin Fowler; traduo Acaun Fernandes Bookman, 2004.

48

ANEXO 1 PLANO DE TESTE

PLANO DE TESTES 1 PROPSITO Este documento define o Plano de Teste de Unidade do projeto SisLoCar - Sistema de Locao de Carros, com o objetivo de descrever as atividades e planejamento para a execuo de testes de unidade, assim como os critrios e resultados de aceitao dos testes. 2 ESCOPO A finalidade do Plano de Teste de Unidade reunir todas as informaes necessrias para planejar e controlar o esforo de teste referente a determinadas classes. Ele descreve a abordagem dada ao teste do software e o plano de nvel superior gerado e usado pelos gerentes para coordenar o esforo de teste. Este documento de Plano de Teste referente ao SisLoCar atende aos seguintes objetivos: 1. Identificar informaes de projeto existentes e os componentes de software que devem ser testados 2. Identificar classes no qual devem ter suas unidades testadas (Teste de baixo nvel) 3. Recomendar e descrever as estratgias de teste a serem utilizadas Ainda, este documento tem como escopo, tratar da abordagem de testes caixa branca.

3 PBLICO-ALVO Todos os envolvidos com o processo de testes deste sistema. So eles: Cliente, Programador, Testador, Analista de Testes, Gerente de Testes e Gerente de Projeto. 4 REFERNCIAS [1] Classes do sistema. [2] Requisitos do sistema.

49

5 ITENS A SEREM TESTADOS Item 1 Artefato Arquitetura interna Fase Construo/existente Responsvel Programador

6 RECURSOS 6.1 Ambiente de Teste Software & Hardware O ambiente de teste de unidade, consiste dos mesmos recursos para desenvolvimento. 7 ESTRATGIA DE TESTE 7.1 Teste Unitrio de Cdigo O teste de unidade de cdigo tem como objetivo detectar erros ou defeitos no nvel de Classe do sistema.

Papel do Executor Critrio de sucesso

Desenvolvedor A estrutura interna das classes a serem testadas. Para isso devem ser implementadas estruturas de testes para verificar se os resultados esperados esto sendo atendidos. Funcional Caixa Branca Manual/ Automatizado JUnit

Tipo de Teste Tcnica Tcnica de Execuo Ferramentas de Teste 8 RESULTADO DOS TESTES 8.1 Registro de Bugs

Os bugs sero registrados na planilha do projeto de testes. Ao final de cada ciclo de testes, ser gerado um Relatrio de Testes descrevendo o trabalho realizado. Como os teste de unidade, em sua maioria so executados pelos prprio desenvolvedores, os bugs so sanados em momento de execuo. 9 RISCOS

50

Id Descrio 1

Impacto Probabilidade Plano Contingncia Baixa Tutorial capacitao

de Plano Mitigao

de

Falta de Alto conhecimento na ferramenta JUnit Falta ferramentas ambiente realizao Testes de Alto do para dos

Alta

e Distribudo o plano de testes em verso preliminar em 20/08/2011 Transferncia dos Equipe de testes para a equipe desenvolvimento de desenvolvimento executa os testes